Monitoring of cloud-based data systems

Viranomaisen on huolehdittava, että sen tietojärjestelmien käytöstä ja niistä tehtävistä tietojen luovutuksista kerätään tarpeelliset lokitiedot, jos tietojärjestelmän käyttö edellyttää tunnistautumista tai muuta kirjautumista. Lokitietojen käyttötarkoituksena on tietojärjestelmissä olevien tietojen käytön ja luovutuksen seuranta sekä tietojärjestelmän teknisten virheiden selvittäminen.

Digiturvamallissa tietojärjestelmän omistaja voi vastata tietojärjestelmän lokitietojen keräämisen tarkastamisesta. Organisaatio dokumentoi lokien sisällön tarkemmin niissä tietojärjestelmissä, joiden teknisestä ylläpidosta se vastaa itse. Muissa tietojärjestelmissä omistaja tarkistaa yhteistyössä järjestelmätoimittajan kanssa, että tarvittavat lokit kertyvät.

The development of system logs must keep pace with the development of the system and enable, for example, the necessary resolution of incidents. In connection with the data system list, we describe for which systems we are responsible for the implementation of the logging. For these systems, we document:

• which data is saved on the log
• how long log data is retained

Organization must describe the baseline of normal behaviour for the use of network and data systems, which is used as a starting point for identifying anomalies.

When defining the baseline, the following must be taken into account:

• monitoring the use of data systems during both normal and peak times
• usual times of use, places of use and frequency of use for each user and user group

Monitoring systems must be configured against the baseline to identify anomalous behavior such as:

• unplanned termination of systems or processes
• traffic related to malware or malicious IP addresses or domains
• known attack characteristics (e.g. denial of service or buffer overflow)
• unusual system use (e.g. keystroke logging)
• bottlenecks and overloads (e.g. network queues, latency levels)
• unauthorized access (actual or attempted) to systems or data
• unauthorized scanning of data systems and networks
• successful and failed attempts to access protected resources (e.g. DNS servers, web portals and file systems)
• unusual user and system behavior

Käyttäjien ja ylläpitäjien toimintaa seurataan poikkeuksellisen toiminnan havaitsemiseksi. Turvallisuusluokan I tietojen käsittelyssä suositellaan tehostettua poikkeamien havainnointikykyä, painottaen muun muassa tietojenkäsittely-ympäristön käyttäjien ja ylläpitäjien toiminnan seurantaa.

• On olemassa menettely, jolla kerätyistä tallenteista ja tilannetiedosta (esimerkiksi muutokset lokikertymissä) pyritään havaitsemaan poikkeamia (erityisesti tietojärjestelmän luvaton käyttöyritys on kyettävä havaitsemaan).
• On olemassa menettely, jolla tietojenkäsittely-ympäristön kohteista (hosts, esimerkiksi työasemat ja palvelimet) voidaan havainnoida poikkeamia.
• On olemassa menettely havaituista poikkeamista toipumiseen.

Turvallisuusluokan I tietojen käsittelyssä suositellaan riskiperustaisesti turvallisuusluokkaa II pidempiä säilytysaikoja lokitiedoille (esimerkiksi vähintään 10 vuotta).

Turvallisuusluokan I tietojenkäsittely-ympäristöt ovat tyypillisesti suppeita, koostuen esimerkiksi kaikista verkoista pysyvästi irtikytketyistä päätelaitteista. Toisaalta esimerkiksi 10 vuoden lokikertymän säilyvyys on haastava toteuttaa uskottavasti vain päätelaitteilla, joten tällaisten päätelaitteiden lokienkeräys sekä kerättyjen lokitietojen varmistukset edellyttävätkin yleensä suunniteltua säännöllistä prosessia. Käytännön toteutustapana voi olla esimerkiksi lokitietojen säännöllinen kerääminen irtomedialle, jota käsitellään ja säilytetään sen elinkaaren ajan kuin turvallisuusluokan I tietoa. Lisäksi huomioitava, että mikäli tietojärjestelmän pääsynhallinta tai esimerkiksi toimien jäljitettävyys nojautuu fyysisen turvallisuuden menettelyihin, myös näistä syntyviä tallenteita saattaa olla perusteltua säilyttää ja hallinnoida turvallisuusluokan I mukaisilla menettelyillä.

Turvallisuusluokan II–III tiedon käsittely on rekisteröitävä sähköiseen lokiin, tietojärjestelmään, asiarekisteriin tai tietoon (esimerkiksi dokumentin osaksi). Teemasta on olemassa suositus VM 2021:5: Suositus turvallisuusluokiteltavien asiakirjojen käsittelystä.

TL III ja TL II käsittely-ympäristöissä vaatimus voidaan siten, että toteutetaan alla mainitut toimenpiteet:

• Relevantille henkilöstölle on laadittu selkeät ohjeet lokitietojen keräämiseen, luovuttamiseen sekä seurantaan liittyen.
• Keskeiset tallenteet säilytetään vähintään 5 vuotta, ellei lainsäädäntö, suositukset tai sopimukset edellytä pitempää säilytysaikaa. Tallenteita, joilla on esimerkiksi poikkeamatilanteiden selvittelyn tai viranomaistoiminnan rikosoikeudelliselta kannalta hyvin vähäistä merkitystä, voidaan säilyttää lyhyemmän ajan, esimerkiksi 2-5 vuotta.
• Lokitiedot varmuuskopioidaan säännöllisesti.
• Samalla turvallisuusalueella olevien olennaisten tietojenkäsittelyjärjestelmien kellot on synkronoitu sovitun ajanlähteen kanssa.
• On olemassa menetelmä lokien eheyden (muuttumattomuuden) varmistamiseen.
• Syntyneiden lokitietojen käytöstä ja käsittelystä muodostuu merkinnät.

Tilanteissa, joissa on tarve tuoda tietoa ei-luotetuista järjestelmistä jotain muistivälinettä käyttäen, huomioidaan lisäksi yleensä turvallisuusluokasta II lähtien myös muistivälineen kontrolleritason räätälöinnin uhat.

Kaikki tiedon sisääntuonnin ja ulosviennin käyttötapaukset on tunnistettu. Turvalliset toimintatavat on määritetty, ohjeistettu ja valvonnan piirissä. Turvallisten toimintatapojen piiriin sisältyy tarvearviointi järjestelmien USB-porttien ja vastaavien liityntöjen käytölle.

USB-porttien ja vastaavien liityntöjen käytön tapauskohtaisiin ehtoihin voi sisältyä esimerkiksi, että järjestelmään voi kytkeä vain erikseen määritettyjä luotettavaksi todennettuja muistitikkuja (ja vastaavia), joita ei kytketä mihinkään muuhun järjestelmään. Tapauskohtaisiin ehtoihin voi sisältyä esimerkiksi järjestely, jossa vain organisaation tietohallinnon jakamia muistivälineitä voidaan kytkeä organisaation järjestelmiin, ja että kaikkien muiden muistivälineiden kytkeminen on kielletty ja/tai teknisesti estetty.

Tilanteissa, joissa on tarve tuoda tietoa ei-luotetuista järjestelmistä jotain muistivälinettä käyttäen, tapauskohtaisiin ehtoihin sisältyy usein myös määrittelyt siitä, millä menetelmillä pienennetään tämän aiheuttamaa riskiä. Menetelmänä voi esimerkiksi olla ei-luotetusta lähteestä tulevan muistivälineen kytkeminen eristettyyn tarkastusjärjestelmään, jonne siirrettävä tieto siirretään, ja josta siirrettävä tieto viedään edelleen luotettuun järjestelmään erillistä muistivälinettä käyttäen.

Organisaatio on tunnistanut lokitietojen keräämiseen liittyvät vaatimukset ja varmistanut niiden perusteella lokitietojen keräämisen ja seurannan riittävyyden.

Lokitiedot tulee kerätä tietojärjestelmän käytöstä ja tietojen luovutuksista, mutta tietojen kerääminen on sidottu tarpeellisuuteen. Jos tietojärjestelmästä luovutetaan rajapintojen tai katseluyhteyden avulla salassa pidettäviä tietoja tai henkilötietoja, tulee luovuttavassa järjestelmässä kerätä luovutuslokitiedot sen varmistamiseksi, että tietojen luovuttamiselle on ollut laillinen perusteensa. Lisäksi käyttölokitiedot tulee kerätä ainakin tietojärjestelmistä, joissa käsitellään henkilötietoja tai salassa pidettäviä tietoja.

When utilizing cloud-based data systems, the organisation should request information from the service provider to find out monitoring capabilities of each system.

When offering cloud services as a service provider, the organisation should provide monitoring capabilities and related documentation proactively to the customer. This includes e.g. capability to monitor if the service is being used as a platform or a vector to attack others or capability to monitor for data leaks in the service.

The organization shall have pre-planned, clear policies for each of the different security systems for situations where logging or other access controls are suspected of failing. These situations must be reported to the appropriate and responsible party without delay.

The process must take into account at least the security systems relevant to the organisation's digital security (e.g firewalls, IDS / IPS, anti-malware, access control).

Synchronizing clocks between different systems allows for good interoperability, as well as easier tracking of problem situations and perception of event flows.

An organization must use a reliable source to adjust and synchronize time, at least for systems that are critical to its operations.

The organization has to technically make sure that logs are in read-only state for all users who have write-privileges - including admin rights.

Removing logging or editing them can only be possible through carefully considered policies, which ensure segregation of duties, and when needed, break glass style emergency measures.

When implementing a management process, the organization should consider a centralized log management system and SIEM-integration for real time monitoring.

Lokeja suojataan luvattomilta muutoksilta ja häiriöiltä (esim. tietojen muokkaaminen tai säilytyskapasiteetin ylittyminen) mm. seuraavin toimintatavoin:

• Keskeiset tallenteet säilytetään vähintään 2-5 vuotta, ellei lainsäädäntö tai sopimukset edellytä pitempää säilytysaikaa.
• Lokitiedot varmuuskopioidaan säännöllisesti.
• Samalla turvallisuusalueella olevien olennaisten tietojenkäsittelyjärjestelmien kellot on synkronoitu sovitun ajanlähteen kanssa.
• Syntyneiden lokitietojen käytöstä ja käsittelystä muodostuu merkinnät.

The logs are protected from unauthorized changes to the data and from malfunctions, which are e.g.:

• changes to the message types that can be saved
• editing or deleting log information
• exceeding log storage capacity, which can result in transactions being overwritten or not logged

The organization must be aware of the logs that accrue from the use of different data systems, whether generating the logs is the responsibility of the organization or the system provider. Logs record user actions as well as anomalies, errors, and security incidents.

The adequacy of log should be reviewed regularly. If necessary, log should be usable to determine the root causes for system incidents.

Often, security tools provide a way to set alert policies when something potentially dangerous happens in an organization's environment. For example, Microsoft 365 has built-in alert policies to alert you to abuse of administrator privileges, malware, potential internal and external risks, and data security risks.

The organization must identify security-related events in data systems and the environments in which they operate. To respond to changes related to these events, alarm policies must be created.

Alarm policies need to be actively monitored and modified based on experience.

Security systems (e.g. firewall, malware protection) often have the ability to record a log of events. At regular intervals, make sure that a comprehensive log is accumulated and try to identify suspicious activity. The log is also useful in investigating disturbances or violations.

The organization must have a procedure for reviewing event logs for rule violations and other noticeable problems with in compliance with legal and organizational provisions.

The organization should also protect the integrity of the event logs (e.g. by separate environment).

Organization should use tools that support both manual and automated searches, including criteria-based searches. The tool should be able to automatically collate data from different sources to more easily determine whether an incident is genuine, as well as its scope and nature.

These operations and processes can be implemented with SIEM (Security information and event management). SIEM solutions use analytics tools, technology and algorithms (e.g., newer SIEM solutions employ applied machine learning) to help detect unknown threats and abnormalities in the security-relevant data. Also SIEM solutions allow organizations to modify already existing (which usually come pre-configured) and add criteria-based alerts to match known threats. These things will help detect threats earlier.

Use a standardized log format. This simplifies integration between logs and third-party log analysis tools, making it easier and, in some cases, even possible.

The organization must log admin and security logs from used devices and services.

These logs record actions taken by system administrators and privileged users. They help monitor changes to system configurations, user access rights, and other critical settings. By keeping these logs, an organization can audit administrative activities and ensure accountability.

Security logs capture events related to the security of systems and data. This includes login attempts, firewall activities, intrusion detection system alerts, and antivirus actions. Monitoring these logs helps identify suspicious activities that could indicate a security breach or an internal threat.

Continually assess whether the collected data, both security-relevant monitoring data and obtained threat information from relevant sources, is sufficiently relevant and detailed.

Only relevant monitoring data should be collected and preserved, and if necessary, reconfigure the monitoring in line with the strategy. All collected data which no longer has operational or security relevance should be removed.

Organisation must identify which laws and regulations it needs comply with. Based on these laws and regulations, the organisation determines a strategy and guidelines for data logging and analysis.

The following things should be described in the strategy and guidelines:

• Purpose and usage of collected data
• Which data to collect
• How the data is stored
• Retention period for collected data
• Informing relevant stakeholders data-related requirements mandated by laws and regulations.

Organisation must identify which laws and regulations it needs comply with. Based on these laws and regulations, the organisation determines a strategy and guidelines for data logging and analysis.

The following things should be described in the strategy and guidelines:

• Purpose and usage of collected data
• Which data to collect
• How the data is stored
• Retention period for collected data
• Informing relevant stakeholders data-related requirements mandated by laws and regulations.

Organization should use tools that support both manual and automated searches, including criteria-based searches. The tool should be able to automatically collate data from different sources to more easily determine whether an incident is genuine, as well as its scope and nature.

These operations and processes can be implemented with SIEM (Security information and event management). SIEM solutions use analytics tools, technology and algorithms (e.g., newer SIEM solutions employ applied machine learning) to help detect unknown threats and abnormalities in the security-relevant data. Also SIEM solutions allow organizations to modify already existing (which usually come pre-configured) and add criteria-based alerts to match known threats. These things will help detect threats earlier.

Organization should use tools that support both manual and automated searches, including criteria-based searches. The tool should be able to automatically collate data from different sources to more easily determine whether an incident is genuine, as well as its scope and nature.

These operations and processes can be implemented with SIEM (Security information and event management). SIEM solutions use analytics tools, technology and algorithms (e.g., newer SIEM solutions employ applied machine learning) to help detect unknown threats and abnormalities in the security-relevant data. Also SIEM solutions allow organizations to modify already existing (which usually come pre-configured) and add criteria-based alerts to match known threats. These things will help detect threats earlier.

Continually assess whether the collected data, both security-relevant monitoring data and obtained threat information from relevant sources, is sufficiently relevant and detailed.

Only relevant monitoring data should be collected and preserved, and if necessary, reconfigure the monitoring in line with the strategy. All collected data which no longer has operational or security relevance should be removed.

Anomalies must be reported to the relevant parties in order to develop the following activities:

• auditing
• security assessment
• identification and monitoring of technical vulnerabilities

Organization's data systems and network must be monitored to detect abnormal use. When anomalities are detected, the organization must take the necessary measures to assess the possibility of security incident.

The monitoring should utilize tools that enable real-time or regular monitoring, taking into account the organization's requirements. Monitoring practices should be able to manage large amounts of data, adapt to changing threat environment, and send alerts immediately when necessary.

Inclusion of the following sources in the monitoring system should be considered:

• outbound and inbound network and data system traffic

  li>

• access to critical data systems, servers, network devices and the monitoring system itself
• critical system and network configuration files
• logs from security tools (e.g. antivirus, IDS, IPS, network filters, firewalls)

Organization must also establish procedures for identifying and correcting "false positive" results, including tuning monitoring software for more accurate anomaly detection.

Vulnerabilities in third-party or open source libraries must be monitored, scanned, and reported in the same style as other vulnerabilities.

The organization must define policies to identify required updates in applications that use external libraries. Surveillance scans can be automated with specialized tools.

It also makes sense for an organization to monitor overall communication about vulnerabilities.

The organization must have pre-planned, clear policies for situations where logging or other access controls are suspected of failing. These situations should be reported to the appropriate authority without delay.

Different types of situations should have their own policies. Monitoring errors can be caused by software errors, log saving errors, log backup errors, or memory overflows.

The organization must have the ability to monitor and report on actions related to encryption and encryption key management.

When abnormal activity is detected it must be handled in accordance with incident management processes.

By monitoring the amount of information shared in cloud services, efforts can be made to identify risks that could lead to unauthorized disclosure of information. With respect to files one may e.g. monitor:

• Which employees share the most files in the cloud services?
• How often DLP policies have issued alerts?
• How often the warnings issued by DLP policies are ignored?
• How much important information is in other cloud services - beyond the reach of DLP control?

System logs often contain a wealth of information, much of which is irrelevant to security monitoring. In order to identify events relevant to security monitoring, consideration should be given to automatically copying appropriate message types to another log or to using appropriate utilities or audit tools to review and resolve files.

Security systems are the data systems that are in place to protect the information we have, not so much to process it.

We regularly evaluate the operation of different security systems and the need for new systems.

The necessary personnel are regularly trained in the use of selected security systems.

Archive and sign logs digitally at regular intervals to ensure log integrity.