Deciding how and when to tell the public about vulnerable computing processes is a crapshoot at best. The currently preferred method has those in the know keeping quiet about flaws until there are fixes. The processor vulnerabilities code-named Meltdown and Spectre are perfect examples.
“The Meltdown and Spectre flaws… were originally revealed privately to chip companies, operating-system developers, and cloud-computing providers,” writes Peter Bright in the January 5, 2018 Ars Technica article Meltdown and Spectre: Here’s what Intel, Apple, Microsoft, others are doing about it. “That private disclosure was scheduled to become public sometime next week, enabling companies to deploy suitable patches, workarounds, and mitigation.”
Bright continues, “With researchers figuring out one of the flaws ahead of the planned reveal, the schedule was abruptly brought forward, and the pair of vulnerabilities were publicly disclosed on Wednesday [January, 3, 2018], prompting a rather disorderly set of responses from the companies involved.”
Something else to consider: Withholding vulnerability information from the public makes less sense knowing the digital underground has individuals just as capable of finding flaws as the researchers who independently found Meltdown and Spectre. And unlike the researchers, it is a pretty safe bet that those with ill intentions are not likely to go public with their findings unless it is an advantage for them to do so.
SEE: Information security incident reporting policy (Tech Pro Research)
Solutions seem nebulous right now
Not unexpectedly, there is significant confusion about what is fixed and what is not. The slide in Figure A is from a SANS presentation given on January 4, 2018 by Jake Williams, SANS analyst and certified SANS instructor.
It appears that Meltdown has a cure, and it has been rolled out to users. However, a fix for Spectre (page 15) is not coming anytime soon. And that is yet another problem considering bad actors now know there is an exploit available to them capable of capturing information stored in a computer’s memory.
The question then becomes: What can those responsible for an organization’s security do to limit the chance of falling victim to attacks based on Spectre–and let’s not forget Meltdown, considering that even if a patch is available, it has to be installed, and that does not happen immediately?
What about logging?
Logging is a reactive defense, but it still affords security personnel the ability to determine if any abnormal blips are occurring or have occurred in the computing infrastructure. “Logs are an essential aspect of understanding what is occurring in an organization’s network infrastructure and applications,” writes Brian Todd in his SANS security white paper Creating a Logging Infrastructure. “Log events help analysts understand the health of the network and give insight into many types of issues.”
To ensure we are on the same page, logging, according to Todd, is the process of collecting information from various sources. “During the collection process, the logging infrastructure is storing this information–which is composed of data known as ‘events’–in a particular format,” writes Todd. “The events are the discrete pieces of information that tell analysts what is happening with the network, on a host, or with specific applications.”
Next, Todd defines what analysts consider an event according to The CEE Editorial Board, 2010:
“An event is a single occurrence within an environment, usually involving an attempted state change. An event typically includes a notion of time, the occurrence, and any details that explicitly pertain to the event or environment that may help explain or understand the event’s causes or effects.”
SEE: Cybersecurity in an IoT and mobile world (free PDF) (ZDNet/TechRepublic special report)
What to log?
Todd suggests that nearly everything running within a network can be considered a log source. These are some of the more important sources.
- Events: State changes related to system health and operating systems, including CPU utilization, memory utilization, network bandwidth, and hardware physical properties.
- Authentication and authorization: These logs are critical for detecting attacks throughout the infrastructure as well as knowing which users are logged in and when they log in and log out.
- Firewalls, IDS, and IPS: Event information related to devices defending the perimeter is needed to understand the security of a network and to perform forensic investigations.
- Endpoint security: This includes antimalware, application control, file-integrity monitoring, and forensic information about detected malware, installed programs, and patches.
- Network infrastructure hardware and services: Logs–in particular, those related to DHCP and DNS events–are used to monitor and troubleshoot network issues as well as detect network attacks.
- Applications: Event logging that includes information about databases, on-premise applications, and cloud-based applications will show who has access to them and what commands they run on the applications.
Automation is the key
In years past, all the above logs had to be touched by humans, and that quickly becomes an impossible task from the sheer number of events being logged. “Security engineers have tools, such as security information and event management (SIEM), to tie events together and correlate events from across the company’s network,” writes Todd. “A SIEM can process the logs and provide insight into what is happening within the organization’s network infrastructure and applications.”
Todd adds that SIEM tools provide insight into issues related to authentication, privilege escalation, and vulnerabilities. This is useful for network management, intrusion detection, forensics investigations, and meeting legal requirements.
SEE: Intrusion detection policy (Tech Pro Research)
An ever-changing environment
Historically, bad actors attack and security professionals defend ad infinitum, leaving end users and organizations caught in the middle. It is not the best solution, but having a well-tuned logging infrastructure may be the only game in town, especially when attack methodology and vulnerabilities are kept secret.
Note: Meltdown was independently discovered by three groups–researchers from the Technical University of Graz in Austria, German security firm Cerberus Security, and Google’s Project Zero. Spectre was found independently by Project Zero and independent researcher Paul Kocher.