No items found.

Creating and maintaining an access control policy

Critical
High
Normal
Low

To ensure authorized access and prevent unauthorized access to data and other related resources, the organization has defined and implemented clear rules for managing physical and logical access.

Rules are implemented and enforced through several different tasks, but are also combined into an access control policy for clear communication and review.

Regular reviewing of data system access rights

Critical
High
Normal
Low

Data system owner determines the access roles to the system in relation to the tasks of users. The compliance of the actual access rights with the planned ones must be monitored and the rights reassessed at regular intervals.

When reviewing access rights, care must also be taken to minimize admin rights and eliminate unnecessary accounts.

Use and evaluation of password management system

Critical
High
Normal
Low

The password management system allows the user in a registration situation to decide how complex a password is to be set this time and to remember it on behalf of the user.

When using the password management system, e.g. the following principles:

  • the system will force the use of unique passwords in the future
  • the system warns the user to change old recurring passwords
  • the system forces you to choose passwords that are complex enough, of high quality
  • the system forces the user to change the temporary password the first time they log on
  • the system forces you to change the password that may have been compromised in the data leak
  • the system prevents the same passwords from being reused
  • the system keeps password files separate from other data and strongly encrypted

Defining and documenting accepted authentication methods

Critical
High
Normal
Low

The organization has predefined authentication methods that employees should prefer when using data systems.

When using cloud services, the user can often freely decide how he or she authenticates with the service. A single centralized authentication account (such as a Google or Microsoft 365 account) can help close a large number of access rights at once when the main user account that acts as the authentication method is closed.

Use of multi-factor authentication for important data systems

Critical
High
Normal
Low

Systems containing important information should be logged in using a multi-authentication logon, also known as either “two-factor”, “multi-factor” or “dual factor” authentication.

For example, when first logging in with a password, a one-time authentication code can also be sent to the user as a text message. In this case, he has been identified by two factors (knowing the password and owning the phone).

Biometric identifiers (eg fingerprint) and other devices can also be used for two-stage authentication. However, it is worth considering the costs and implications for privacy.

Tietojenkäsittely-ympäristön toimijoiden tunnistaminen (TL III, ST III-II)

Critical
High
Normal
Low

Tietojenkäsittely-ympäristöjen toimijoiden tunnistamiselta edellytetään seuraavia lisätoimia:

  • Käytössä on vahva, vähintään kahteen tekijään perustuvaa käyttäjätunnistus
  • Päätelaitteet tunnistetaan teknisesti (laitetunnistus, 802.1X, tai vastaava menettely) ennen pääsyn sallimista verkkoon tai palveluun, ellei verkkoon kytkeytymistä ole fyysisen turvallisuuden menetelmin rajattu suppeaksi (esim. palvelimen sijoittaminen lukittuun laitekaappiin turva-alueen sisällä).

Tietyissä tilanteissa sähköisiä tunnistusmenelmiä voidaan korvata fyysisen turvallisuuden toimilla (esim. pääsy järjestelmään vain tiukasti rajatulta ja fyysisesti suojatulta alueelta, kuten lukittu laitekaappi, jota valvotaan vahvalla tunnistamisella). Nojattaessa fyysisen turvallisuuden menettelyihin, tulee myös fyysisen turvallisuuden menettelyjen täyttää jäljitettävyydelle asetetut vaatimukset erityisesti lokitietojen ja vastaavien tallenteiden säilytysaikojen suhteen. Tällöin varsinainen järjestelmään tunnistautuminen voi olla esim. käyttäjätunnus-salasana -pari.

Tietojärjestelmien tärkeimpien ylläpitotehtävien valvonta ja eriyttäminen (TL III)

Critical
High
Normal
Low

Tietojärjestelmien kriittisimpiä ylläpitotehtäviä valvotaan riittävällä tarkkuudella.

Tarvittava tarkkuus valvonnassa ja tehtävien eriyttämisessä riippuu merkittävästi kyseessä olevan tietojärjestelmän käyttötapauksista. Useimmissa järjestelmissä riittävä eriyttäminen on toteutettavissa järjestelmän ylläpitoroolien ja lokien valvontaan osallistuvien roolien erottelulla toisistaan. Yleinen valvontamekanismi on myös vaatia kahden tai useamman henkilön hyväksyntä järjestelmän kriittisille ylläpitotoimille.

Käyttäjätunnusten lukittuminen toistuvista epäonnistuneista tunnistuksista

Critical
High
Normal
Low

Käyttäjien käyttäjätunnukset lukittuvat tilanteissa, joissa tunnistus epäonnistuu liian monta kertaa peräkkäin.

Tietojärjestelmien turvallisuusluokiteltujen tietojen erittely

Critical
High
Normal
Low

Limiting access rights in accordance with the principle of least rights can reduce both intentional and unintentional actions, as well as the risks caused by, for example, malware.

Security-classified information in information systems is separated according to the principle of least rights by means of user rights and system handling rules or by other similar procedures.

Separation can be carried out:

  • separation at the logical level (e.g. servers virtualization and restricted network disk folders)
  • with reliable logical separation (e.g. approved encrypted virtual machines on customer-specifically reserved physical disks of the disk system, and approved encryption of data or communication on shared network devices)
  • with physical separation (physical disks reserved per data owner devices) (also suitable for higher security categories)

Hallintayhteyksien rajaaminen turvallisuusluokittain

Critical
High
Normal
Low

Hallintayhteydet on rajattu turvallisuusluokittain, ellei käytössä ole turvallisuusluokka huomioon ottaen riittävän turvallista yhdyskäytäväratkaisua.

Henkilökohtaiset tunnukset hallintayhteyksien käytössä

Critical
High
Normal
Low

Järjestelmien ja sovellusten ylläpitotunnuksien on oltava henkilökohtaisia. Mikäli henkilökohtaisten tunnusten käyttäminen ei kaikissa järjestelmissä tai sovelluksissa ole teknisesti mahdollista, edellytetään sovitut, dokumentoidut ja käyttäjän yksilöinnin mahdollistavat hallintakäytännöt yhteiskäyttöisille tunnuksille.

Hallintayhteyksien rajaaminen

Critical
High
Normal
Low

Hallintayhteydet on rajattu vähimpien oikeuksien periaatteen mukaisesti.

Hallintayhteyksien vahva tunnistaminen julkisessa verkossa

Critical
High
Normal
Low

Hallintapääsyn julkisesta verkosta tai muun käytettävän etähallintaratkaisun tulee edellyttää vahvaa, vähintään kahteen todennustekijään pohjautuvaa käyttäjätunnistusta.

Hallintayhteyksien suojaus on eräs kriittisimmistä tietojärjestelmien turvallisuuteen vaikuttavista tekijöistä. Tietojärjestelmiä, jotka eivät sisällä kriittisiä tietoja, voi kuitenkin olla perusteltua pystyä hallinnoimaan myös fyysisesti suojattujen turvallisuusalueiden ulkopuolelta. Tällöin etähallinta on tarpeen suojata etäkäyttöä kattavammilla turvatoimilla.

Authentication of identities and binding to user data

Critical
High
Normal
Low

The organization verifies the identity of users and associates them with user information. These should also be confirmed before any interaction.

Identity verification must be performed according to pre-written and approved rules.

Access rights are managed by the principle of the least privilege

Critical
High
Normal
Low

Access to the organisation's systems is granted and managed according to principle of least privilege. No further access will be granted to the user when necessary.

The permissions will be checked and the need will also be reduced if the user has the rights user needed to perform the tasks but no longer needs them.


Limitation of privileged of utility programs in relation to offered cloud services

Critical
High
Normal
Low

When offering cloud services, the organisation should specify the requirements needed for use of utility programs in relation to the cloud service it provides.

Organisation should make sure that the use of utility programs that can bypass normal operating or security procedures is limited to authorized personnel. The use and usefulness of these utility programs should be reviewed regularly.

Limitation of privileged utility programs

Critical
High
Normal
Low

Privileged utility programs are applications that require system or administrative privilege to do their jobs. Different kinds of utilities can include system utilities (e.g. malware protection), storage utilities (e.g. backup), file management utilities (e.g. encryption) or others (e.g. patching).

If use of privileged utility programs is permitted, the organisation should identify all privileged utility programs, also ones that are used in its cloud computing environment.

Organisation should ensure utility programs don’t interfere with controls of data systems hosted in any way (on-premises or cloud).

Features and instructions for access management in offered cloud services

Critical
High
Normal
Low

When offering cloud services, the organisation should provide the technical implementation to enable the customer to manage the users access rights to their account.

The organisation should also provide instructions and specifications for the use of the user management (e.g. help articles, FAQs), e.g. related to available authentication methods, single sign-on capabilities and different admin actions.

Features and instructions for user registration and de-registration in offered cloud services

Critical
High
Normal
Low

When offering cloud services, the organisation should provide the technical implementation to enable the customer to manage the user registration and deregistration to the service. 

The organisation should also provide instructions and specifications for the creation / deletion of users (e.g. help articles, FAQs), e.g. related to different user levels, user invitation process and different admin actions.

Secure management of de-activated or expired user IDs

Critical
High
Normal
Low

De-activated or expired user IDs should never be re-used for other users.

This is relevant as a general administration principle for self-developed cloud services and all other utilized data systems, where other maintenance may be provided by a partner organization, but access / user ID management by the organization itself.

Total record of authorized users for offered cloud services

Critical
High
Normal
Low

The organization should maintain an up-to-date record of users who have authorized access to offered cloud services.

There should be a profile for each user that contains a set of data necessary (e.g user ID and other authentication information) to implement technical controls for providing authorized access.

Managing user privileges

Critical
High
Normal
Low

The organisation must manage all of it’s users and their privileges. This includes all third party users, which have access into the organisations data or systems.

The organisation must remove users entirely or remove privileges from them when they are no longer needed e.g when employee role changes.

Reviewing password practices on password protected systems

Critical
High
Normal
Low

To protect from e.g brute force attacks the organisation must use at least one of the following practices:

  • Account is locked after 10 failed login attempts
  • Limit for login attempts in 5 minutes is 10

In addition the following password practices should be in place:

  • Minimum length of a password should be at least 8
  • Passwords don’t have maximum length
  • Password is changed when it’s integrity is suspected or known to be compromised

Changing default passwords

Critical
High
Normal
Low

The organisation must change the default passwords on all of its devices (e.g. computers, network devices). The changed passwords must be hard to guess.

Minimizing and monitoring log data access

Critical
High
Normal
Low

The organization has to limit log access to authorized personnel only. Logs must log when they have been viewed and those logs have to be kept so, that log views can be identified.

Using unique user names

Critical
High
Normal
Low

The organization must use unique usernames in order to associate users and assign responsibility for them.

Shared usernames are not allowed and users are not allowed to access information systems until a unique username is provided.

Approval process that includes the customer for high-risk administrator rights

Critical
High
Normal
Low

The organization must have policies and procedures in place that allow the customer to participate, if possible, in the process of approving high-risk administrator rights.

Roolipohjaisista käyttöoikeuksista poikkeamien käsittely

Critical
High
Normal
Low

Poikkeamat roolikohtaisista oikeuksista tulee asianmukaisesti hyväksyä ja dokumentoida.

Instructions for reporting changes affecting access rights

Critical
High
Normal
Low

Supervisors have been instructed to notify the owners of data systems in advance of significant changes in the employment relationships of subordinates, such as promotions, discounts, termination of employment or other changes in the job role.

Based on the notification, a person's access rights can be updated either from the centralized management system or from individual data systems.

Rules and formal management process for admin rights

Critical
High
Normal
Low

Admin rights are managed through a formal process aimed at limiting the allocation of admin rights and controlling their use.

Regarding admin rights:

  • expiration requirements are defined
  • admin rights are granted only to usernames not used for normal everyday use
  • normal day-to-day use may not be performed with an admin account

Defining and documenting access roles

Critical
High
Normal
Low

The organization implements role-based access control with predefined access roles for the various protected assets that entitle access to the associated asset. Strictness of the access roles should reflect the security risks associated with the asset.

The following should be considered to support access management:

  • how much information each user needs access to
  • how widely the user should be able to edit data (read, write, delete, print, execute)
  • whether other applications have access to the data
  • whether the data can be segregated within the property so that sensitive data is less exposed

Enabling multi-factor authentication for all users

Critical
High
Normal
Low

Multi-factor authentication (MFA) helps protect devices and data. To apply it, users must have more information in the identity management system than just an email address - for example, a phone number or an attached authenticator application (e.g. Microsoft, Google, or LastPass Authenticator).

Use of dedicated admin accounts in critical data systems

Critical
High
Normal
Low

Especially in the main identity management systems (e.g. Microsoft 365, Google), administrator accounts have very significant rights. These accounts are often the target of scammers and attacks because of their value. For this reason, it is useful to dedicate administrator accounts to administrative use only, and to not use these accounts for everyday use or, for example, when registering with other online services.

Using multi-factor authentication for admins

Critical
High
Normal
Low

Multi-factor authentication (MFA) is required for administrators in the organization's key data systems.

For example, when first logging in with a password, a one-time identification code can also be sent to the user as a text message. In this case, he has been identified by two factors (knowing the password and ownership of the phone).

Biometric identifiers (e.g. fingerprints) and other devices can also be used for multi-stage authentication. However, it is worth considering the costs and implications for privacy.

Avoiding and documenting shared user accounts

Critical
High
Normal
Low

Shared accounts should only be allowed if they are necessary for business or operational reasons and should be separately approved and documented.

If shared accounts are used for admin purposes, passwords must be changed as soon as possible after any user with admin rights leaves their job.

Managing shared user credential through password management system

Critical
High
Normal
Low

One way to manage the risks associated with shared usernames is to manage the shared password and its users directly through a password management system.

In this case, it is possible to act in such a way that, for example, only an individual person actually knows the password and the persons who use it.

Analyzing authentication processes of critical systems

Critical
High
Normal
Low

The system or application login procedure should be designed to minimize the potential for unauthorized access.

The login process should therefore disclose as little information about the system or application as possible so as not to unnecessarily assist an unauthorized user. Criteria for a good login procedure include e.g.:

  • logging in does not reveal the associated application until the connection is established
  • the login does not display help or error messages that would assist an unauthorized user
  • logging in will only validate the data once all the data has been entered
  • login is prevented from using fatigue attacks
  • login logs failed and successful login attempts
  • suspicious login attempts are reported to the user
  • passwords are not sent as plain text online
  • the session does not continue forever after logging in

Need to know -principle in access management

Critical
High
Normal
Low

The need-to-know principle grants access only to information that an individual needs to perform his or her task. Different tasks and roles have different information needs and thus different access profiles.

Separation of tasks means that conflicting tasks and responsibilities must be separated in order to reduce the risk of unauthorized or unintentional modification or misuse of the organisation's protected assets.

Secure identification of systems with admin-rights

Critical
High
Normal
Low

The organization must use digital certificates or other similar arrangements to achieve a strong level of authentication equivalent to multi-step authentication for system identities handling maintenance rights or sensitive information.

Käyttöoikeuspyyntöjä hyväksyvien henkilöiden ja roolien määrittely

Critical
High
Normal
Low

Organisaatio on määritellyt roolit, joissa toimivat henkilöt voivat hyväksyä käyttöoikeuspyyntöjä. Organisaatio on lisäksi määritellyt, kuinka dokumentoidaan muut henkilöt, jotka voivat hyväksyä käyttöoikeuspyyntöjä.

Centralized record of user's access rights to data systems

Critical
High
Normal
Low

The organization maintains a centralized record of the access rights granted to each user ID to data systems and services. This recording is used to review access rights at times of employment change or in the onboarding process of new colleagues joining the same role.

Implementing formal access control processes

Critical
High
Normal
Low

To ensure that authorized users have access to data systems and to prevent unauthorized access, the organization has defined formal processes for:

  • User registration and deletion
  • Allocation of access rights
  • Reassessment of access rights
  • Deleting or changing access rights

The implementation of these things must always take place through a defined, formal process.

Preventing outdated authentication methods

Critical
High
Normal
Low

By blocking the use of outdated authentication methods, we can make it more difficult for attackers to gain unauthorized access. For example, in a Microsoft 365 environment, Office applications in the 2013 model support outdated authentication methods by default (for example, Microsoft Online Sign-in Assistant), but you can prevent this by creating a policy that prevents these outdated authentication methods.

Credentials are not transmitted via email

Critical
High
Normal
Low

Credentials should be securely transmitted to users. delivery of a password or through unprotected external party (plaintext) e-mail message should be avoided.