This security analytics blog was written by expert and author Dan Sullivan (@dsapptech) who outlines three use case scenarios for security analytics tools and explains how they can benefit the enterprise.
If there were any doubts about the sophistication of today’s cyber threats, the 2014 attacks on Sony Corporation put them to rest. On November 22, 2014, attackers hacked the Sony network and left some employees with compromised computers displaying skulls on their screens, along with threats to expose information stolen from the company. Sony, by all accounts, was the subject of an advanced persistent threat attack using exploits that would have compromised the majority of security access controls.
The scope of the attack forced employees to work with pen, paper and fax machines, while others dealt with the repercussions of the release of embarrassing emails. The coverage around the Sony breach may rightly leave many organizations wondering if their networks are sufficiently protected and — of particular interest here — whether security analytics software and tools could help them avoid the fate of Sony.
The short answer is, yes. Just about any business or organization with a substantial number of devices — including desktops, mobile devices, servers and routers — can benefit from security analytics software.
It is important to collect as much useful data as possible to supply the security analytics tool with the raw data it needs to detect events and alert administrators. So before deploying a security analytics tool, it helps to understand how such a product will fit within an organization’s other security controls and the gaps it will help fill in typical IT security use cases.
Compliance is becoming a key driver of security requirements for more businesses. In addition to government and industry regulations, businesses are implementing their own security policies and procedures. To ensure these regulations, policies and procedures are implemented as intended, it is imperative to verify compliance. This is not a trivial endeavor.
Consider for a moment how many different security controls may be needed to implement a network security policy that is compliant with various regulations and security standards. For instance, anti-malware systems might scan network traffic while endpoint anti-malware operates on individual devices. Then there are firewalls, which are deployed with various configurations depending on the type of traffic allowed on the sub-network or server hosting the firewall. Identity management systems, Active Directory and LDAP servers — meanwhile — log significant events, such as login failures and changes in authorizations. In addition to these core security controls, an enterprise may have to collect application-specific information from other logs. For example, if a salesperson downloads an unusually large volume of data from the customer relation management (CRM) system, the organization would want to know.
It is important to collect as much useful data as possible to supply the security analytics tool with the raw data it needs to detect events and alert administrators.
When companies have a small number of servers and a relatively simple network infrastructure, it may be possible to manually review logs. However, as the number of servers and complexity of the network grows, it is more important to automate log processing.
System administrators routinely write shell scripts to process files and filter data. In theory, they should be able to write scripts in awk, Perl, Ruby or some other scripting language to collect logs, extract data and generate summaries and alerts. But how much time should system administrators invest in these tasks?
If they write a basic script that works for a specific log, it may not easily generalize to other uses. If they want a more generalized script, it will likely take longer to write and thoroughly test. This presents significant opportunity costs for system administrators who could better spend their time on issues more closely linked to business operations.
This is not to imply that the functionality provided by these scripts is not important — it is very important, especially when it comes to the kind of data required for compliance. The question is how to most efficiently and reliably collect log data, integrate multiple data sets and derive information that can help admins make decisions about how to proceed in the face of potentially adverse events.
Security analysis tools are designed to collect a wide variety of data types, but there is much more to security analytics than copying log files. Data from different applications and servers has to be integrated so organizations can view a unified timeline of events across devices, for example. In addition, these solutions include reporting tools that are designed to help admins focus on the most important data without being overwhelmed with less useful detail. So, in a nutshell, the economic incentive of security analytics vendors is to provide solutions that generalize and relieve customers of the burden of initial development and continued maintenance.
- Security event detection and remediation
The term “connecting the dots” is often used in security and intelligence discussions as a metaphor for linking-related — but not obviously connected — pieces of information. Security expert Bruce Schneier wrote a succinct post on why this is a poor metaphor: In real life the “dots” and their relation to each other is apparent only in hindsight; security analytics tools do not have mystical powers that allow them to discern forthcoming attacks or to “connect the dots” auto-magically.
A better metaphor is “finding needles in a haystack,” where needles are significant security events and haystacks are logs, network packet and other data about the state of a network. Security analytics tools, at a minimum, should be able to alert organizations to significant events. These are defined by rules, such as a trigger that alerts the organization to failed login attempts to administrator accounts or when an FTP job is run on the database server outside of normal export schedules.
Single, isolated events often do not tell the whole story. Attacks can entail multiple steps, from sending phishing lures to downloading malware and probing the network. Data on these events could show up in multiple logs over an extended period of time. Consequently, finding correlated events can be very challenging, but it is something security analytics software can help with. It is important to emphasize that security analytics researchers have not perfected methods for detecting correlated events, however. Organizations will almost certainly get false positives and miss some true positives.
These tools can help reduce the time and effort required to collect, filter and analyze event data, though. Given the speed at which attacks can occur, any tool that reduces detection and remediation time should be welcomed.
In some ways, computer forensics — the discipline of collecting evidence in the aftermath of a crime or other event — is the art of exploiting hindsight. Even in cases where attacks are successful and data is stolen or systems compromised, an enterprise may be able to learn how to block future attacks through forensics. For example, forensic analysis may reveal vulnerabilities in an organization’s network or desktop security controls they did not know existed.
Security analytics tools are useful for forensic analysis because they collect data from multiple sources and can provide a history of events before an attack through the post-attack period. For example, an enterprise may be able to determine how an attacker initially penetrated its systems. Was it a drive-by download from a compromised website? Did an executive fall for a spear phishing lure and open a malicious email attachment? Did the attacker use an injection attack against one of its Web applications?
If an organization is the victim of a cybercrime, security analytics tools can help mitigate the risk of being a victim to multiple forms of the same type of exploits in the future.
The need for incident response planning
In addition to the use cases outlined above, it is important to emphasize the need for incident response planning. Security analytics may help enterprises identify a breach, but it cannot tell it how to respond — this is the role of an incident response plan. Any organization contemplating a security analytics application should consider how it would use the information the platform provides. Its security practice should include an incident response plan, which is a description of how to assess the scope of a breach and what to do in response to an attack.
A response plan typically includes information on how to:
- Make a preliminary assessment of the breach;
- Communicating details of the breach to appropriate executives, application owners, data owners, etc.;
- Isolating compromised devices to limit damage;
- Collecting forensic data for evidence and post-response analysis;
- Performing recovery operations, such as restoring applications and data from backups; and
- Documenting the incident.
Security analytics tools help detect breaches and collect data, but it is important to have a response plan in place prior to detecting incidents. Enterprises do not want to make up their response plan as they are responding to an incident. There is too much potential for error, miscommunication and loss of evidence to risk an ad hoc response to a security breach.
Deploying security analytics software
For organizations that decide to proceed with a security analytics deployment, there are several recommended steps to follow, including: identifying operations that will benefit from security analytics (e.g. compliance activities); understanding the specific tasks within these operations, such as Web filtering and traffic inspection; determining how the security analytics tool will be deployed given their network architectures; and identifying systems that will provide raw data to the security analytics tool. These topics will be discussed in further detail in the next article in this series.