Veronica Schmitt
3. Keep logs clean and focused
Logs are mostly analysed when things go wrong. The rest of the time, they tend to be ignored. The volume of store information expands, and sometimes minor design flaws propagate. Logs "grow with the application," Schmitt says. "[Y]ou will accumulate useless logs or logging debt."
When logs include too much worthless data, they don't have a lot of value for researchers. Schmitt suggests looking at logs as applications grow. Developers who aim to produce clean code should also want to have clean logs, she says. She recommends testing logs regularly using a benchmark to prevent them from getting too bulky.
4. Prepare for being breached
Almost every application or organisation will be compromised at some point and it should log accordingly, trying to help future investigative teams analyse those incidents. Schmitt examined many logs during the past few years and found that they often include information with little value, such as uneventful status checks or system checks, which clutter the relevant data. She tells developers to avoid logging normal behavior and instead focus on changes and exceptions. "You should be far more concerned with logging when things go wrong," she wrote.
Logs should also focus on vulnerable areas. If, for instance, an application could potentially suffer injection attacks, developers should build extra logging controls to detect those faster.
Companies, too, should think ahead and plan for the worst-case scenario. "Getting the logs off the system in real-time will allow for the reconstruction of what happened in the breach and the extent of spread after an initial attack," Carstensen says. "Incident responders will start at the known data point of a breach (IP, host, file name) and then try to understand what happened prior to it."
Good logs help investigators see if the malicious file was downloaded via the web or spread from another host on the network. Then, they can search in the past to see if there were similar issues.
In the event of an attack, the worst thing that could happen is to discover that crucial information is missing. "Not having the logs required to uncover how they did it is frustrating," said Grant Ongers, co-founder of application security consulting company Secure Delivery, who works with Schmitt. "When digital forensics are asked to look into a potential breach, if there are no logs that focus on the security events that may have occurred, then there are no answers to give the CISO," he says. "And the CISO has no answers to give to the board or the relevant data protection or regulatory authority."
According to Ongers, there's even something worse than that: "If you have no security-related logs, or the ones you have are unreliable or otherwise unusable, then even discovering that a potential breach happened is impossible," he says.
5. Store logs for secure access
Designing good logs is one thing. Storing and securely accessing them is another. While investigating breaches, Schmitt learned that there is often "an unreasonable amount of trust" people put in the technology they use. Her advice is to "trust no device, no system, and no method of transmission."
Often, if the device that stores logs is a user's mobile device or laptop, the organisation that developed the app has little control, and it’s best if it plays it safe. "There should never be any information in the logs that can be used to derive additional information about how the application functions, authenticates, or endpoints it communicates with," she says.
Logs should contain just enough information for the debugging process to work and should not include the elements that could be considered sensitive, because they might fall in the wrong hands. "Many breaches occur because we assign a high level of trust to internal services and members of the organisations," she wrote. "Many breaches occur from within, not necessarily from outside. Logs contain valuable information that any attacker might want to have access to."
Carstensen agrees that organisations need to be wise when deciding who can access the logs and how. They should limit access to a minimal number of people and take measures to prevent log manipulation. Specifically, he recommends "removing the ability to delete logs unless approved by two separate people." He also pointed out that companies should meet all the compliance regulations that apply to them. In addition, he advocates for encrypting archived logs because they might have sensitive data.
Why we need to pay more attention to logs
There’s an old saying that governs forensics, the Locard's exchange principle: When a criminal operates somewhere, they will do two things: bring something into the crime scene and take something from it. Both should be seen in logs and should be used as evidence.
This is why keeping good logging should be a part of any organisation's security strategy, Schmitt says. Ongers seconds that, saying that often developers are a key part of the solution. "Security needs to be built in by design, during development," he says.
Schmitt plans to continue teaching computer experts to see logs from the incident responder's perspective, telling them to log fewer things, but to make the process more efficient. "The biggest thing is just simplifying logs," she says. "It's taking these complex amounts of information and reducing them."
