Guideline Event Logging
* Concept version [machine translated]:
1. Guaranteeing logging
The principle of "logging by design" is always applied within a high security area.
Which means that at the start of the construction of a infrastructure or service the requirements for "Logging" are determined from the statutory perspective, management, security and possibly other needs.
It is essential that the data that is processed by means of logging is complete, correct and traceable at all times.
It is therefore essential that logging clearly complies with:
1. Completeness
All essential information about acts and exceptions (error messages) end up with certainty in logs.
- Think of the fact that the central log management system and / or the log API gateway process can be temporarily unavailable.
- Also think of ChangeManagement registration.
2. Tracability
The information in the logs can also be interpreted longer after the event, within the correct wider context.
3. Reliability
If log information is used for detection and prosecution, it must be demonstrable that all information is verifiable correctly.
4. Consistency
Specifically named fields must have exactly the same meaning in all log sources and processing. If that is not the case, the central log processing system must be known which abnormalities there is to guarantee the traceability.
Example:
If in Log-Source A) The "User" field is filled with which user name has been entered by 1 specific person, such as 'admin'.
In Log-Source B) The "User" field is automatically filled with a system process ID like "admin",
instead of the name of who has been connected to that system with their unique own authentication ID.
Then there is a misunderstanding about the meaning of the information in the log messages.
In addition, the following points are important for generating and processing log messages:
a) IT processes that do processing must be able to share information about relevant events.
This sounds like a matter of course, but there are systems / products / components that have no possibility to have information about events registered.
For example, a low-budget managed switch, where network administrators must adjust settings that must be registered.
For example, an external / 'cloud' service whereby the supplier does not offer a possibility to register all relevant events, or does not permit that log messages are continuously sent to a logging service that is under 100% full own management within the walls of the case law.
When choosing IT infrastructure components, it is essential to equip such poor components.
b) For the processing of messages, those messages should be sent to a central processing site.
This creates adjacent chains. Where as much as possible must be prevented that log messages can be lost.
B1) Wherever possible, one should ensure that if a part of the chain is temporarily not functionally available, the component that generates messages that can also (have a room) store until the chain is functional again.
On servers it is therefore good to temporarily store log messages from all local components by default on the server itself, even if those components / services transfer all messages to the central processing site via the network.
B2) It is desirable that log messages are not sent blind. So that a form of receipt verification is adjusted.
This can also be arranged that after a temporary failure of one of the chain elements, the messages that have not yet been sent yet are transferred.
If the component itself that synchronization cannot perform, for example, the central logging system could try to retrieve the missing messages if reports appear to be missing,
B3) It can of course also happen that the logging process fails on the IT component itself.
To prevent interruption from being unnoticed by disruption, there are 2 standard methods.
B3.1) By ensuring that central active system monitoring is adjusted, with which all relevant processes are continuously monitored.
B3.2) By ensuring that a so-called Heartbeat process is active, which has sent a standard message with fixed intermediate pose via the same chain as the primary service process.
Which means that the central processing system can detect that or something is wrong with the source, or that the system has been assigned consciously (if a 'shutdown' message is received).
In addition, the following points are important for the guarantee of the content of the log messages:
a) a cryptographic checksum hash.
To be able to check whether the content is still the same.
Note: It is important that the checksum contains a secret element, so that adjusting / counterfeit is not easy.
Adjusting log information unnoticed can also be made as good as impossible. By making a separate total checksum about all recorded checksums within a time plane, and that verification information in a separate (WRITE ONLY) location where IT management also has no access. -> CISO "Need to Know" Level Access Only.
b) a sequence number.
To be able to trace whether messages have been lost.
Note: The field length can be limited by for example, restarting the count once a day.
c) Time of the event.
Where possible in standard format [YYYY-MM-DD, hh:mm:ss.(ms) UTC]
Note: The clocks of all logging systems within a security domain must be synchronized with one reference, UTC.
From systems for which circumstances the time display in log messages is not equal to UTC, it must be observed with certainty which deviation is there.
A deviation is reasonably clear from systems that directly send log messages to a central processing system. But with systems where the logging is only stored locally, there must also be traceable afterwards, which the possible time registration deviation was when each log message was recorded. The deviation can be traced from Network Time Protocol logs on the same system.
d) Source of event notification.
For example, name of the system + name of the application or the process.
e) the event.
What happens / used / add / adjust / removed.
f) The result of the act.
For example: Completed / Error / Unknown.
To be able to see if the operation is not only applied for.
g) the required information to reduce an incident to a high degree of certainty to a natural person or source.
Note: It is highly dependent on the circumstances in which a service that generates logging exists,
Whether all the necessary information must be in a log message, or that it can be removed from the context with other information available from the central logging system.
After all, it may be that a certain service as part of a chain does not receive any information about what the actual source or natural person is.
As far as possible, a log control contains data that can lead to the breaking or circumventing protection.
Consider, for example, cases where a user must accidentally enter a password in a username field, as the username is logged.
This is prevented by encrypting such information in messages.
It is advisable to have the to log to be assessed by the privacy and security officers.
Example Log message:
# 0f00xt, 600,2021-04-01 11:11:11.05 UTC, "IAM.AD :ZMPDC006", "User VPN Login: Duijzerjw@wsl30185999: 10.68.97.23", "Credentials Accepted".
Protection of log data against access by unauthorized.
It may never be that, for example an (ActiveDirectory; LDAP ; IAM; authorization data DB) administrator can also give management access to storage systems on which the logging of such authorization systems are collected. Also because an attacker maybe able to access the same username/password or SSO administrator data via other systems.
That is why it is important to not link the systems that receive log messages for storage and processing to any central authentication service, but use a system local own 2 factor authentication mechanism.
It is also necessary that the logging and SIEM systems must also be accessible, also if there is a malfunction or incident that puts the central authentication services or parts of the WAN out of control.
See Hardening Hardening Guide <Link> To ensure the security of the services and servers themselves.
Een concreet infrastructuur voorbeeld:
Invoegen [ Tekening / Schema {{Notitie: Beter plaatje er bij ]
+ In een datacentrum hangt een fysieke server in een 19" rack.
++ Op die server draait als basis een Operating System
+++ Binnen het OS draait een Virtual Machine Hypervisor
++++ Daar binnen draaien een aantal virtual machines
+++++ Een daarvan is een Web service + Applicatie server + Applicatie waarmee mensen via het publieke internet informatie over de ******* kunnen opzoeken.
* detail invulling kan zodra er antwoord gekomen is van ***@... waar een SOC medewerker naar verwezen heeft voor inhoudelijke details over hoe logging is ingericht binnen de org.
> Welke informatie zou gelogd moeten worden.
.....
> Hoe worden de log berichten gemaakt.
Door een applicatie, of een separaat proces of systeem.
... <in afwachting van antwoord op deze vragen..
> Hoe worden de log berichten verwerkt.
Worden de berichten ******* vanuit het systeem via het netwerk verstuurd naar de eindbestemming.
Of zitten er tussenstappen tussen, en zo ja welke.
......
> Hoe zijn de log berichten terug te vinden.
.........
> [Toevoegen: logging flow diagram ]
Om de logging te realiseren in een complexe infrastructuur met meerdere zones en partijen, is het van belang om stil te staan bij de vraag: Hoe komen log-berichten vanuit een bron naar een centrale opslag en verwerking systeem.
