Things that security auditors will nag about, Part 1: #NoLogs

This the first part of our blog series "Things that security auditors will nag about and why you shouldn't ignore them". In these articles, Nixu's security consultants explain issues that often come up when assessing the security of web applications, platforms and other computer systems.

The existence and storing of logs is a basic thing that our security consultants will check in platform audits or ask during threat modeling workshops. Very often, the answer is that little or no logs get collected. Even if there is some logging in place, it is stored only locally for a week or so. This is not secure enough. In this blog post, I will explain you why.

Who needs logs anyway?

Logging is not just a compliance issue. Although failing to provide logs may result in serious legal issues and get you in the newspaper in the wrong light, there are many other reasons for logging. The main purposes are

• debugging;
• keeping an audit trail; and
• investigation and forensics in case of security breaches.

For you own convenience when developing software, proper logging helps you in pinpointing where or when the erroneous behavior happens. If the basic application logs are not sufficient you might need special debug log with more details.

Audit logs may be needed to meet certain compliance or security requirements. But don't forget that they are also for your and your user's convenience: "Aha, it was you who changed that code!" or "Hey, it wasn't me who logged in from this location, maybe my password is compromised?" For logs to be helpful, you also need to review them periodically.

Regulation may define how long you have to keep certain log records, if you are handing for example personal, financial, medical or work time related information. You need to be aware of which laws apply to you.
Another thing to consider when adjusting log retention period is your ability to detect breaches. Sadly, on average it usually takes months, sometimes even years, before an unauthorized access to a system gets noticed. According to FireEye's annual M-Trends threat report from 2017, the median time from compromise to discovery was 146 days in 2015 and 99 days in 2016. Despite the significant drop in global median statistics, your default 1-4 weeks worth of logs is not sufficient: Even six months of logs may not be enough for investigating how the attackers got in, what did they do and what data has been compromised. No forensics team can help you if there's not enough evidence.

Remote log server is the way to go

Even if you have enabled the relevant application and system logs, you can't just go on keeping them only in your web server or database server.

First of all, your hard disk may get full. That's why you should have a separate log partition.

The second reason is to prevent tampering of logs. Of course, the file permissions on log files should deny that non-administrative users cannot delete or overwrite logs. But if an attacker can get admin access (or your administrator has turned to the dark side), you should send your logs to a remote log server where they are more safe and where you can have more storage.

The Center of Internet Security (CIS) Benchmarks are a good source of information also on log related security settings for multiple operating systems, servers and network devices. The benchmarks, available as free downloads for registered users, also have instructions on implementing the recommended features.

The story of Goldilocks and log levels

Many times, logging resembles the story about Goldilocks and the Three Bears. Remember the story where the little girl, Goldilocks, entered a house in the woods? She tasted porridge, sat on sofas and tried to find a bed to sleep in, and always the options were too big, too small, too hot, or too cold. The same thing often happens with logs.

Too small

Most often, the logging configurations I see are insufficient. There are no logs collected at all or they are kept for a week at maximum. Not all relevant data is collected, which means that:

• incident response is hard or impossible;
• the audit trail is insufficient; and
• debugging problems is hard.

Too big

This is something I've sometimes struggled with trying to debug faulty computer systems or when auditing applications.
Too many details are logged, like user name and password ( ! )  in access logs. Logging personally identifiable information is regulated. If you need to do so, you also need to ensure that only the authorized people are allowed to see the logs. You also have to keep a log of accessing those logs.

If too much debug information is written in the log, such as all protocol parameters when establishing a connection, it will result in huge amounts of data within short periods of time. It's hard times going through all those logs if there's no log management available. Too much logs can also clog up your SIEM momentarily (yes, seen that too!).  If there are cases when you need all those tiny little details (excluding passwords and PIN codes), set up different log levels. Separating different logs into different files is also a good idea.

Just right

Your logs are "Just right", when

• logs are gathered from a long enough time period (remember to check any regulatory requirements for this);
• logs are protected from tampering;
• logs have sufficient details for debugging or forensics;
• sensitive information has been sanitized;
• logs from different sources are synchronized (NTP + timezone information);
• you have an audit trail; and
• non-repudiation requirements are met, meaning that no one can deny later on that they didn't do something.