Veronica Schmitt
Veronica Schmitt started to wear an implantable cardiac device when she was 19. A few years ago, although the small defibrillator appeared to be working properly, she felt sick. "I kept passing out, and I went to a hospital, and once they had to resuscitate me," she says. "That was not supposed to happen."
Her doctor pulled out the data the device was logging and said that everything was alright. She shouldn't worry—maybe it's just stress.
Schmitt, who is now in her early 30s, has always been passionate about technology, so she didn't buy into this. Instead, she looked at her other device that logged health data, her smartwatch, pulling out XMLs and doing data analysis. She proved that the two gadgets showed contradictory information and asked her doctor to prescribe her additional medical tests.
Those tests proved that she was indeed sick, and that her implantable cardiac device was malfunctioning. Schmitt went into surgery to extract the device and get a new one, which changed her life. "My hands were warm; my cheeks were red. I wasn't gray in the face anymore," she says. "If I didn't know how to look at logs and data, I'd probably be dead."
After she recovered, Schmitt became obsessed with logs. She analysed different devices and tried to understand how she could improve log keeping. She is now the leading voice of a movement that aims to help everyone build better logs focused not only on performance but also on security. "We don't do monitoring the way we should," she says.
Building better logs
Schmitt took inspiration from two books she read by Gene Kim, The Unicorn Project, and The Phoenix Project. She realised that poorly designed logs are "a byproduct of how dysfunctional organisations are in terms of security, development, and operations or having silos."
Since large entities move slowly and are reluctant to change, Schmitt focuses on developers, trying to influence how they work. "I'm trying to speak in the language that makes developers excited, but also makes logs cool, ‘cause logs suck," she says.
Most developers admitted that they were not trained in designing logs. They simply recorded information that was relevant to them, focusing on performance. Few thought about security and logged data that would be needed in the event of a breach.
To help them, Schmitt designed a benchmark spreadsheet that took inspiration from the NIST security standards. Developers can take their application logs and score them to see if they are doing a good job when it comes to integrity, performance, and security. Better logs make it easier to distinguish between critical data and noise, and if they update theirs according to the recommendations, they will be more prepared when dealing with a security incident.
Schmitt also created a list of five philosophies for designing logs.
1. Logs should be simple, structured, and detailed enough
First, logs should be simple and should retain the minimum amount of data that does the job, Schmitt says. Anyone briefly looking over them should be able to understand what they contain. "The logs should not be seen as a cache of information," she wrote on her blog. They should rather be seen as "a source of information that is simplified to only contain that which is necessary."
She also calls for consistency when designing logs. Some developers, for instance, prefer to use local time when logging date and timestamps, while others go with UTC. This can break a forensic researcher's timeline. "The larger the team, often, the more disconnected the logs," she says.
To address this issue, organisations can plan the structure and the format of the logs. They can start by asking a couple of questions: "Are these logs going to be used for enrichment purposes within a SIEM solution?" Or, "What is the purpose of the events you choose to monitor? Are they more related to debugging, error handling, security events, or future forensic incidents?"
Asking these kinds of questions is relevant not just to developers, but also to companies that want to catch potential threats, says Nick Carstensen, product manager for security and integrations at log management solution Graylog. "Our key philosophy is to know what you are trying to accomplish and ensure you are collecting the logs to meet your goal," he says.
2. Create metadata
Some data developers work with can be sensitive and should not be logged. "There are many things to consider, including whether you should have the information at all or perhaps simply reconsidering how you print your log statements to deal with these types of data," Schmitt wrote.
One way to make the process more streamlined is to tag data as public or private, having specific definitions within the organisation of what these words mean. "When you know a variable contains potentially sensitive user information, mark it as secret explicitly," Schmitt wrote. "Building in the controls required to identify what type of information your variables may contain gives you the power to set the rules about when they are, or can be, disclosed."
When logs are stored on a device that’s outside the organisation's control, they should only include public information. If they have sensitive information, the organisation might face serious consequences in the event of a breach.
Read more on the next page...
