Skip to content

RSA and The “New Normal” of Cybersecurity – Part 3

March 24, 2011

Knowing how ALL the security data is related

by John Linkous

Last week, RSA announced that a successful advanced persistent threat (APT) attack against the company’s infrastructure has resulted in the exfiltration of data that could potentially be used to reduce the effectiveness of RSA’s wildly popular SecurID two-factor authentication products.  While we don’t yet know what was compromised (A token seeding database? Future product design data? We may never know…) or who conducted the attack (China? The Anonymous group?), we do know one thing: the perception of the effectiveness of “secure” authentication and encryption has been deeply shaken.  The fallout from this compromise will likely be swift, and significant.

In my previous post I offered three things that organizations can do to mitigate these complex, advanced threats.

Having Access to All Security Data

Knowing How All the Security Data is Related

Near-Real Time Visibility to Make Effective Decisions.

In this post, I wanted to provide a little more detail on each of these topics.  In this post I want to look at how an organization can know how ALL the security data in it’s network is related.

Collecting these many different types of security data is, of course, the first step to situational awareness.  But as importantly, you need to be able to see how these many different pieces of information are related; cross-correlation is the second component needed to address situational awareness.  For example, on a typical Monday morning, a security operations center (SOC) for a large enterprise may see hundreds of failed logons to servers and workstations.  The question becomes: how many of these are simply fat-fingered credentials, and how many are part of a broad-based attack, perhaps an APT? In most SOC environments, there are not enough personnel available to track down the root cause of each failed logon, resulting in SOC personnel simply clicking “acknowledge” in their console — but of course, that is not security. Answering that question requires correlating these failed logons with other information to find the proverbial needle in the haystack (if one exists).  A security engineer needs to be able to quickly correlate each failed logon (which is event-based data), with other non-event data.  The SOC engineer needs to be able to ask, “How many of these failed logons have occured on a system that experienced an unauthorized configuration change, and is communicating on the network using unusual ports/protocols?” (a tell-tale sign of a network worm, or other types of malware).  Unfortuantely, even if the organization has multiple point tools to collect all they data (SIEM, NBA/SPI/DPI, end-point AV, config management agents, etc.), these individual point tools do not talk to each other.  Something else needs to exist “above” these tools to provide correlation.  That something is a situational awareness platform can provide.

Do you know how all of the security data in your network is related?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: