Security Automation: Security Nirvana or Just a...

A SANS WhitepaperWritten by Jerry Shenk

October 2015

Sponsored by Symantec

Security Automation: Security Nirvana or

Just a Fad?

©2015 SANS™ Institute

Security breaches have become so frequent that often, they don’t even make news. Inside these organizations, however, there’s plenty of panic—and an urgent need to detect breaches more quickly, reduce dwell time and impact, and prevent future incidents. When breaches do become public, panic and costs skyrocket. In addition to the cost for items such as credit monitoring and reputation repair, there’s also the risk of competitive company secrets being revealed. In some of the recent cases such as U.S. Office of Personnel Management (OPM)1 and Ashley Madison,2 lives could be put in jeopardy.

Although detecting and blocking an attack seems basic, the majority of organizations don’t detect advanced attacks for days, weeks or months after the fact. In the SANS Institute 2015 incident response survey, 50% of more than 500 respondents said it took two days or longer to detect breaches, and others noted much longer detection times.3

As the threat landscape has evolved, practitioners now can choose from a growing number of tools: firewalls to block traffic, IDS/IPS to detect threats on the wire and perform behavioral analysis, and to protect and monitor the endpoint and email systems.

Other tools monitor various pieces of the network and antivirus systems and also communicate with other antivirus systems around the globe, comparing signatures. Intrusion detection and prevention systems connected to cloud-based analysis services can compare attack information, malware hashes, DNS requests and other indicators of compromise.

If remediation is so important, and if good monitoring tools already exist, why is there such a delay in detecting attacks? Even with all of this technology, organizations typically do not have a way to coordinate data. For example, how do we get intrusion detection systems to talk to email and endpoint protection tools, and pull in information from the endpoint?

As an example, an administrative login to an endpoint, followed by a blocked outbound port and then a steady stream of encrypted data from that same endpoint on another port might be an indication of a security breach—but it is likely that no one will notice. The deluge of uncoordinated information results in what the Council on CyberSecurity’s “Critical Security Controls” paper4 calls the “Fog of More.”

If these indicators are kept in their isolated silos of information, they don’t show the full impact of a breach that has happened and the data that’s being stolen. This paper explores how automating detection and analysis can help shorten detection time, improve detection methods, and provide alerts on only the top-priority issues.

SANS ANALYST PROGRAMSecurity Automation: Security Nirvana or Just a Fad?1

Introduction

1 www.washingtonpost.com/news/the-switch/wp/2015/09/23/opm-now-says-more-than-five-million-fingerprints-compromised-in-breaches2 https://en.wikipedia.org/wiki/Ashley_Madison3 www.sans.org/reading-room/whitepapers/analyst/maturing-specializing-incident-response-capabilities-needed-361624 www.counciloncybersecurity.org/critical-controls

Too Much Data, Too Little Action


As Figure 1 illustrates, detection time often takes too long. Similar results were reported

in this year’s SANS Institute survey on incident response.5

Figure 1. Rates at Which Detection Typically Occurs6

Several factors combine to create these delays.

Layered Security

Primary among the issues contributing to delayed incident response (IR) time is layered

security, one of the current network design standards. Layered security, an absolute

necessity, achieves its purpose of making it difficult for an attacker to get into the

network without being detected. What it also does, however, is bombard IT departments

with information they don’t need and aren’t likely to spend time analyzing.

In an attempt to enhance the layers of the network, protection typically starts by

blocking some traffic with next-generation firewalls that can block content. Email is

often scanned for malicious patterns, hostile attachments and undesirable content.

5 www.sans.org/reading-room/whitepapers/analyst/maturing-specializing-incident-response-capabilities-needed-361626 www.verizonenterprise.com/DBIR/2015

In the Verizon Data Breach Investigations Report, 60% of compromises took place in a matter of minutes, yet detection took minutes for 34% of survey respondents and

hours for 31%. For 25%, it took days, weeks or months.

40%

30%

20%

10%

0%

34%took minutes

25%took days,

weeks or months

31%took hours

Too Much Data, Too Little Action (CONTINUED)


This layered security approach can provide some benefits. In the SANS paper, “Layered

Security: Why It Works,”7 SANS addresses why relying on a single device to protect a

network isn’t practical and doesn’t work as well as using multiple layers of security. Most

of today’s networks have layers, too: firewalls, IDS/IPS, VLANs, access control lists, file

permissions, behavioral analysis, antivirus, monitoring of URL and IP address reputation,

and endpoint security systems. Layered security can be compared to a medieval castle

sitting in a large clearing (layer 1) on a hill (layer 2) with a moat (layer 3) with a gate, a

drawbridge, archers on the wall, buckets of hot oil, and weapons.

But, just as airplanes make most of the castle’s defenses look silly today, attacks via

email, web attacks and attacks on internal devices fly right by many of the standard

protections. Many attacks are even carried through the front door by the guards and

attendants because they look like legitimate deliveries. The layers are still necessary, but

it’s no longer realistic to assume that we have all the doors closed. We can no longer

block at the edge; we need to act as though the attack force has already entered, and

we need to monitor what happens inside the network. These disparate layers need an

automated way to communicate at some level to share information. Otherwise, there’s

no way to connect the dots that signal an attack.

Network Monitoring

Inherent complications in modern network monitoring also add to delayed IR. In many

networks, people are allowed to carry personal devices (known as BYOD—“bring-

your-own-device”) into the network or take managed devices outside of it. Also, more

workers than ever use company PCs or other devices outside of the enterprise for email,

web browsing and more. In a recent SANS survey on the mobile workforce,8 30% of

employees accessed corporate resources and applications from an unmanaged device.

Additionally, users often use personal storage devices such as USB sticks in and out of

the network without any restrictions.

Network monitoring can catch malware only when a device is actually on the network.

In contrast, endpoint monitoring is necessary when devices are off the network and

once malware has entered the network and begun to move laterally within the network

to find its next target. Both are likely necessary for effective security, but as with other

elements of the layered defense approach, the information must be coordinated for

effective response.

7 www.sans.org/reading-room/whitepapers/analyst/layered-security-works-348058 www.sans.org/reading-room/whitepapers/analyst/securing-portable-data-applications-mobile-workforce-35947

Too Much Data, Too Little Action (CONTINUED)


File Monitoring

If a monitoring system sees a file, the hash of that file can be checked against a database

of known good and bad or malicious files. Sometimes this process is carried out in the

cloud to leverage the combined information from millions of attack sensors located

throughout the world. If the file is unknown, it can undergo a cloud-based execution

analysis, and if needed, it can be executed in a safe, controlled environment, often called

a sandbox.

This sandbox typically runs in a virtual environment. Some malware is aware of these

virtual environments and will shut down if it detects signs of sandbox operation. Ideally,

the execution analysis should detect this premature termination and pass the execution

off for further scrutiny, such as “bare metal” execution analysis. In an ideal situation,

this analysis happens quickly so that: 1) the end user isn’t inconvenienced by a delay in

receiving the file, and 2) the process shuts down before any malware that made it to the

desktop migrates to other machines or starts to send data off the network.

Data Siloing

Another factor in breach detection delays is data siloing. For years, SANS has advocated

for collecting data. Now, many organizations have more data than they can handle; they

collect data from firewalls, IDS/IPS, anti-malware, endpoint management systems and

other system services. The problem is that these systems often do not communicate with

one another, and it takes time to sort through all that data, correlate it and determine

what’s valuable. Some information that comes through an IDS might be valid and point

to dangerous activity, but if the threat has been handled by some type of endpoint

security or an end user who didn’t open an attachment, the IT department could waste a

lot of time running down a problem that, in fact, doesn’t even exist.

By automating the process of detecting security incidents, we can respond more

quickly, but we need to solve the problem of false positives. By linking network analysis,

email analysis and endpoint analysis, it may be easier and quicker to detect and verify

incidents before sending out alerts.

All of this layered protection and additional tools help detect breaches but require

manual correlation and threat expertise. Most security systems aren’t getting all the

pieces yet. Or, they are getting the information but it’s scattered over a few isolated

dashboards and separate reports. Ideally, network, email and endpoint monitoring would

combine the relevant data and automatically make decisions about the highest priority

security events while deprioritizing threats that have been handled. With more intelligent

alerts, IT staff could focus their time on the most significant risks and potential impact.

We need quicker detection of suspicious events during the attack stage and the ability to determine the scope and scale of the attack after the breach has happened.

First, though, let’s differentiate between an attack and a data breach. For the purpose of this paper, an attack is some action that demonstrates a malicious intent. These attacks could be as simple as an attempt to log into a firewall with the username of root when that username doesn’t even exist. Port scanning, viewing websites, and other reconnaissance activities are not counted as attacks because—by themselves—they don’t demonstrate malicious intent, although in combination with actual attacks and certainly with any breach, they are valuable for supporting forensic analysis.

A data breach is where the network is compromised and data is actually stolen from the victim. The data breach begins the moment any data leaves the victim, whether the attacker uses it at that point or not. In many cases, such as in the recent Ashley Madison incident, the data breach happens days, months or years before the data is used.

The reality of the current Internet is that attacks are happening all the time. Most attacks launch whatever the attacker can muster at whatever victim can be found without regard to the validity of the attack or the value of the target. Tracking down every attack wastes system and personnel resources. It makes business sense, therefore, to try to track down only those that are truly relevant.

For example, if there is a Cisco ASA firewall on the Internet with SSH enabled on the default port (port 22), there will be repeated attempts to log in as root and a variety of other usernames with various passwords. These attacks don’t stand a chance of working if the login name is not root (and it probably isn’t). In another example, Linux-based web servers are constantly attacked with Windows-specific exploits, which simply won’t work. Security personnel should be spending the most time on attacks that are relevant.

Data breaches happen because the attacks that matter are hiding in plain sight in the noise of attacks that don’t matter. In many data breach cases, the attack traffic and even the subsequent indicators of compromise (IOC) existed in the logs but were ignored or missed. This is not a new problem; quotes about the Pearl Harbor attack indicate there was access to critical intelligence data in plenty of time to limit or eliminate the destruction, but it was lost in a sea of irrelevant data. More recently, an analysis of the Target breach of credit card information data showed the attack could have been blocked if the available information had been acted on—but it was lost among less relevant data.

Effective breach detection takes work, and it takes time—time that responders don’t have, given the priorities of business, legal and operational activities. To detect breaches earlier, organizations need the time and training to analyze the data, the tools to help them quickly prioritize the most important data, and a way to coordinate this data. Automation may be the solution.


Chasing What Matters

Data breaches happen

because the attacks that

matter are hiding in plain

sight in the noise of attacks

that don’t matter.

Automating processes that are complex, contain multiple variables, or are especially

subject to human error is nothing new, and the time has come to look at how

automation can help detect security breaches more quickly and efficiently than current

methods. This is especially true with advanced threats that may try to sneak traffic out by

using encryption, long and slow connections, or many small connections.

In fact, automation is a key feature of the CIS Critical Security Controls.9 Nearly every

control in the Critical Security Controls Framework includes some type of recommendation

for automation. Figure 2 presents a basic framework behind the CIS Controls.

Figure 2. Basic Tenets of the Critical Security Controls


Next Steps in Automated Monitoring: Putting the Pieces Together

9 www.cisecurity.org/critical-controls.cfm

PREVENTKnow your systems: Assess and patch

RESPONDScope, contain

IMPROVEReuse intelligence for future prevention

RECOVERRemediate threat/Restore operations

DETECTNetwork/Applications/Endpoints

BREACHBreach is inevitable = Be ready to respond

“Assume something is compromised and operate as safely

as possible anyway.” -Stephen northcutt, SAnS InStItute

Critical Security Controls Framework

Next Steps in Automated Monitoring: Putting the Pieces Together (CONTINUED)


Step 1: Take Inventory

Prevention is the best strategy. The first step toward that goal is to conduct an inventory.

If you don’t know what you have, you can’t prevent attacks against it. The inventory

should include all hardware, software and locations of data. After an organization has an

inventory of the network, it is then possible to prioritize attack traffic. For example, if an

organization is a total Windows shop and a Linux attack is detected, that’s probably not a

big problem.

The hardware and software inventory should be automated so that changes in the

network can be detected quickly. Inventory changes every time there is an operating

system update, application update, new system installation, or system removal—in other

words, inventory is changing all the time. Whenever a device is added or an application

changes, the network changes, and the inventory must reflect that change.

Even devices that may not be considered traditional IT devices need to be included in

inventory. The IoT has brought many new devices to the network, and many of these

devices were not developed with security as a priority. Some of these devices connect

wirelessly, and some get plugged into the network. The Open Web Application Security

Project (OWASP) devotes an entire section of its website to IoT.

In a SANS survey on IoT,10 70% of respondents relied on manual discovery, and many

indicated, “I have no idea,” when asked about the number of IoT devices on their

network. Even traditional devices such as wireless routers, desktop switches and

additional computers that are connected to the network without IT support often have

serious security implications. Automated inventory will help keep track of both planned

and unplanned changes to the network.

The network inventory can be leveraged so that malicious traffic detected on the

network, coming through email, or just showing up on a workstation (via email, the Web

or a USB device) can be compared with the particular vulnerabilities of the workstation,

as well as other devices on the network and lists of known good and bad files.

Two primary options can be used for automated inventory collection: active and passive.

Using a combination of both will best achieve an up-to-date inventory of the network.

Tip: Don’t be too quick to

discount attacks against

equipment you think you

don’t have—you might have

Internet of Things (IoT) devices

that you don’t even know

about but that are vulnerable.

10 www.sans.org/reading-room/whitepapers/analyst/securing-internet-things-survey-34785



The first method actively scans the network periodically and stores the results, keeping

track of when devices appeared on the network, what operating systems they are

running, what ports are open, what software is related to those ports, and other

pertinent information. The second option passively monitors network traffic to collect

similar information. Passive monitoring can be done at network chokepoints to track

what devices are communicating and what software they are using. There are many

subtle differences in communication that will identify hardware, software and even

specific software versions. It is also possible to poll the network’s

switches and routers to track the MAC addresses that are in use.

The second critical control in the CSCs is the software inventory. This

control requires that organizations actively monitor their networks

to ensure that only authorized software is in use. Some endpoint

management suites can fill this need. Some systems include whitelists

of common business applications and can be augmented with

applications specific to the organization. Many organizations choose

to build workstations and servers from common images that can be

quickly rebuilt if an unauthorized modification is detected.

If an automated inventory management system is not available, a

manual system is better than nothing. The security scanner Nmap

is widely used in security auditing and general network discovery, and it can be

downloaded free,11 with versions for all current, common operating systems. Network

scans can be run across an entire infrastructure from one location.

After you have conducted an inventory (either automated or manual), it should be

reviewed to determine whether the discovered items match what was expected.

Deviations will almost certainly be found, and they should all be researched.

IT staff should manually update the inventory by adding information about the value

of each item to the organization. These values should reflect the value of the data and

the value of processes that the resource makes possible. One example of a high-value

resource would be a server with PII such as name, address, Social Security number,

credit card numbers, etc. A different type of high-value item might be a computer that

maintains the temperature of a critical metal-treatment bath. The value of items is highly

dependent on an understanding of the organization and can’t be totally automated, but

valuation is necessary for prioritizing remediation efforts.

11 https://nmap.org/download.html12 The basic concepts of these questions should be considered in the light of a broader risk assessment, but for this paper,

the scope is limited to risks from a hostile party.

Questions12 to Ask About Each Item in Inventory

• If an attacker gained control of this item, could confidential information be immediately available? (example: text file with administrative passwords)

• If an attacker gained control of this item, would confidential information be available in the near term? (example: administrative password hash)

• If an attacker were to render this system inoperable, would internal processes be able to continue?

• If an attacker were to render this system inoperable, would our organization’s customer service be affected?

Confidential information varies

depending on the industry.

Examples include customer

information, personally

identifiable information (PII),

HIPAA information, proprietary

manufacturing processes or

formulas.



Step 2: Monitor Traffic

Monitoring network traffic is another key piece for detecting advanced threats. IDS and

IPS constantly monitor the network for signs of malicious traffic. In most cases, these are

standalone systems that have their own dashboard.

Monitoring DNS traffic is a valuable part of network traffic analysis because attacks

often need to make outbound connections to steal the data, and this activity often uses

DNS. Some malware makes a lot of failed DNS calls, and this shows up in DNS logs. DNS

analysis can also be combined with other network activity as supporting evidence.

Endpoint monitoring is another valuable indicator of a breach. Most endpoint monitors

also have their own dashboards. They can collect information about files on the

computers and compare the hashes of those files with databases that contain hashes for

files with known good and known bad reputations. They can also send unknown files for

further analysis.

Step 3: Combine Analyses

The next step is to combine the analyses of inventory, network traffic analysis, and

endpoint monitoring. When malicious attempts are detected, the endpoints can be

monitored to determine what, if any, impact was made and even whether the endpoint

detected and deleted the attack. The network can also be monitored for IOCs, such as

large file transfers, a high number of outbound connections or connections that last

longer than normal.

Many attacks take advantage of missing patches. In fact, the Verizon Data Breach

Investigations Report for 201513 states that 99.9% of the exploited vulnerabilities

were compromised more than a year after the vulnerability had been published.

Organizations want to claim that they were exploited by something new but generally

that’s not the case. In this author’s security testing for companies, the two most common

issues are missing patches and default configurations. Most data breaches could have

been avoided simply by keeping up with patches on all connected systems.

13 www.verizonenterprise.com/DBIR



Endpoint management can bring value to automated security management because it

keeps track of what is happening at the workstation, including inbound and outbound

connection attempts, software that is running on the system, and software versions and

patch levels. If the workstation data can be integrated with network threat detection

technologies, email monitoring and threat prevention services, the alerts can be better

tuned. Better tuning can help personnel identify the most important issues and help

them avoid having to run down attacks that aren’t relevant or have already been

mitigated by other processes. When an organization understands what its resources

are, it is in a good position to monitor the network. In most organizations, substantial

outbound traffic is limited to a few devices. Any large outbound transfer by other

devices could indicate a data breach and should be researched.

To get started with network monitoring, a number of IDS/IPS solutions are available.

Another starting point is to monitor the traffic through the edge firewall or other

network chokepoints to detect any sudden increase in traffic that could indicate

a successful data breach. Some firewalls have the ability to log every connection

they process to show the length of the connection and the amount of data that was

transferred. For an organization that isn’t doing much monitoring, any of these ideas can

be a simple, inexpensive way to get started with network monitoring.


Conclusion

Security breaches are happening too frequently, and studies show that often they are

not being detected for days, weeks and months. These breaches are costly to all involved

parties. Organizations are collecting more data than ever before, but they still aren’t

stopping attacks and aren’t even catching the breaches after they happen.

The key to stemming the tide of these compromises is to detect attacks as soon as

possible and quickly move to contain and remediate the attack. The key to timely

resolution is to truly understand the network by creating and maintaining an inventory

of devices, software, and critical data and then correlating network traffic with

information from network security, email and endpoint monitoring. Network monitoring

is most effective when automation is used across security layers to correlate and

prioritize incidents so that high-value assets with high-confidence alerts are quickly

dealt with to stop data theft.

Jerry Shenk serves as a senior analyst for the SANS Institute and is senior security analyst for

Windstream Communications, working out of the company’s Ephrata, Pennsylvania, location. Since

1984, he has consulted with companies and financial and educational institutions on issues of network

design, security, forensic analysis and penetration testing. His experience spans networks of all sizes,

from small home-office systems to global networks. Along with some vendor-specific certifications,

Jerry holds six GIAC certifications—all completed with honors—and five with Gold certifications: GCIA,

GCIH, GCFW, GSNA, GPEN and GCFA. He also holds the CISSP certification.


About the Author

Sponsor

SANS would like to thank this paper’s sponsor:

Security Automation: Security Nirvana or Just a...

Documents

Transcript of Security Automation: Security Nirvana or Just a...