Few days ago I got a question from a security officer for guidance on event and system logging.
What I can recommend: a good guideline and indication is this from OWASP.
You know OWASP is THE reference for software security …. with their OWASP top 10 etc.
Another reference from NIST see below, very handy.
These are fairly complete in terms of guideline.
What you should pay special attention to from a policy point of view is
- Sensitive accounts
- Highly priviliged accounts
- Admin accounts
- Service accounts
- Sensitive systems
- Domain controllers
- Application servers
- Sensitive data
- HR data
- Finance data
- Legal data
Regarding the classification of accounts, check these:
For the users you also have to think carefully about events
- Large volume of failed logons from sensitive users, may indicate
- Denial of service
- Attack on the password database, large volumes of password change attempts …
- Smart password ‘testers’ will stay just below the blocking limit ..
- Successful logons from special accounts at abnormal places or times
- Changing the rights of sensitive accounts
- Promotion of regular users to admins or other sensitive accounts in AD or central database
Make sure you have a data, user and system classification policy.
Define roles and / or categories.
Which objects are “not important”, “not sensitive”, sensitive, important, critical.
The protection must be tailored to the category type.
In addition, you should also write a policy on saving data.
This often poses a logistical problem with disk space.
If you know that sometimes attacks are only detected after 200-300 days, you should be able to do a forensic investigation in that period.
But that does not have to be on live data, if it is in backup, that is also good.
In terms of operational data you have to decide how much should be available immediately, for immediate consultation.
For example, that can be 1 month. (if the system can save so much)
Ensure that a backup can be guaranteed for a year (combination of full / differential and / or incremental backups or virtual snapshots …)
This is not a fixed period, but depending on risk management this may be more or less.
IMPORTANT: Time synchronization
Also make sure that you require NTP time synchronization, so that the clocks are exactly matched to each other on all systems.
Log analysis is impossible without correct timing.
Ensure that logs on source systems cannot be deleted by administrators.
Ensure that the logs following are shielded from system owners;
Ideally, you are obliged to store logs centrally (for example in a SIEM system).
Consider managed encryption of data and backups (not ransomware or malware).
Healthy logging and healthy backups
Make sure to test backups and restores!
Check the logs and backup for malware.
Store logs centrally with sufficient storage capacity, security and backup.
A good management process and regular inspection must become mandatory.
Ensure monitoring for special events or special trends (sudden growth or sudden decrease or disappearance of logs)
Arrange forensic surveillance / detention if a burglary or data breach may need to be reported to the government / DPA / police.
The NIST documentation below provides useful hints and tips about the type of systems, routers, switches, firewalls, servers …
Take into account legislation such as GDPR or ePrivacy or others that impose your obligations (legal, judicial, international, fed gov, …)
View and learn from past incidents and known use cases or accidents, which give a clear hint of what protect first.
PDCA – plan-do-check-act
Require a regular review of the policy and the rules, ensure that the guidelines are updated to the requirements and changing situations.
It is difficult if you find out after the facts that your log is not working properly.
And this is also a reference (NIST)