Like the butler in classic murder mysteries, we’re quick to suspect the person with unfettered access, and that’s often the proverbial “red herring”. The 2011 Verizon Data Breach Investigations Report (DBIR) provides system administrators with a statistical alibi.

“For the second year in a row, it is regular employees and end-users—not highly trusted ones—who are behind the majority of data compromises. This is a good time to remember that users need not be super users to make off with sensitive and/or valuable data.”

Verizon also reports that the internal threat has reached an all-time low of 17%, and notes that regular employees accounted for 85% of the “insider” breaches. Finance/accounting and executive management also represented a fairly healthy percentage of data loss, but the venerable System/Network Administrator was the culprit in only 3% of their investigations. The Verizon team speculated that the while these people do have the “keys to the kingdom,” perhaps someone changed the locks.

Lies, Damn Lies and Statistics
Before we get too excited about these numbers, we need a little context. Verizon is quick to point out that the “all-time low” of illicit insider activity (internal agents) is “not so much a decrease in internal agents as much as a comparatively huge increase in external agents.” In fact, the number of attacks attributed to insiders actually doubled in this year’s report.

While statistically you’re about five times more likely to be breached from the outside, it would be foolish to take your eye off what’s happening on the inside. Regardless of the “origin”, the target is the soft, chewy, center of your network. A common mistake is for organizations to focus exclusively on the perimeter with firewalls, IDS/IPS, WAF, etc. and unwisely conclude that they’re secure.

Real-Time Visibility
We recently blogged on the topic of visibility (“Barracuda: Got SIEM?”) in response to speculation that Barracuda Networks might have been breached because of a lack of layered defenses. Our point was that it’s far more likely the breach was simply a lack of visibility. That’s not to say that getting visibility is simple, but it’s critical to ensuring that your products, policies and procedures are actually working.

So how do you combat the insider threat, or the external threat that has established a beachhead inside your network? Yes, SIEM is the answer. No, this is not a blatant product pitch. Assuming you already have layers of defenses and employ best practices in areas like least privilege, the missing piece is real-time analysis. Let me be clear - I’m not talking about Log Management, and if you have any doubt about that, please read this: “Log Management: Bad News, Good News”

Close the Gap
What a true SIEM solution provides is real-time log “analysis” and event correlation. This is the process that provides context to what’s happening, and it is the only practical way to gain “actionable” insight into the activity on your network. There is simply no other technique, process, policy, procedure or technology that comes anywhere close to SIEM in its ability to close the gap between detection, containment and remediation. Let’s face it, the goal is to detect the break-in, not investigate the murder.

The leather-clad Trinity, of Matrix fame, runs an Nmap port scan against a target IP address, detects a vulnerable SSH service and, a few keystrokes later, has root access to the power grid. This is the view many hold of the cyber threats we face, but the 2011 Verizon Data Breach Investigations Report (DBIR) tries to downplay this scenario and paints a distinctly different picture.

“Similar to previous years, we continue to observe that in over half of cases, an attacker
needs a minimum of “days” to successfully find and compromise data.”

From Leather Pants to Dragon Tattoos
Let’s hope you’re not the target of the fictional heroines of hackerdom, but the Verizon quote above is only “half” the story. Verizon’s analysis also reveals that 33% of the breaches succeeded in “minutes”, and another 14% in “hours”.

This is precisely why TriGeo lives by the mantra “seconds count”.

With so many breaches progressing quickly from “point of entry to compromise”, why does the Verizon team “believe that organizations would be better served to focus less on the ‘real-time’ methods of detection, and more on the ‘this week’ methods.”?

It’s my view that suggestion is born out of sheer frustration, and the reluctant acceptance that some detection, discovery and containment is better than none. We noted in our blog post “Log Management: Bad News, Good News”, that the Verizon team found that none (zero, zilch, nada) of the breaches they investigated were detected with the aid of log analysis – real-time or otherwise.

A little damage goes a long way
Given Verizon’s findings, they’ve clearly set the bar pretty low and concede that the short-term goal is to move the discovery timeframe from weeks and months to days. The net result will be to “significantly reduce the damage done to your organization.”

This understandable, if misguided, advice is likely based on the assumption that real-time analysis is expensive, complex and generally out of reach – especially, for the midmarket audience that needs it most. This is arguably the reality with enterprise Security Information and Event Management (SIEM) products that come with six and seven figure price tags, require full-time administration and take months to deploy.

If that was your only alternative, I’d be inclined to agree – a little damage is better than a lot, but any data loss can still destroy your reputation and your organization.

This is Not Hollywood
You’re not “a few keystrokes away” from being a victim. Even the breaches that are successful in minutes-to-hours generate a lot of noise associated with their probes and failures. The attacks that take days, weeks or even months to succeed leave even more evidence in their wake. Evidence that is meaningless if you’re not watching.

Real-time log analysis is available, affordable and purpose-built for the midmarket – the new “growth market” for attacks, according to the Verizon report. It’s time to set the bar much higher, and get your own tattoo: “Don’t Tread on Me”.

In a half-hearted attempt at humor, the authors of the DBIR do try to make the point that things “are only looking up from here.” I wish that were true. The reality is that we’re actually far more likely to remain in single digits for years – unless the attitude on log management and “analysis” (air quotes) changes dramatically.

Most compliance initiatives require log files be collected, and there’s no shortage of security experts and educational institutions promoting the many benefits and use cases for logs. So, it should come as no surprise that in the breach investigation report they found (again this year) that “good evidence of the breach usually exists in the victim’s log files…” We’re apparently doing a good job collecting log data which has been useless in detecting, much less preventing, breaches.

Do the Math

If…

• The evidence of a breach is present in the logs
• The average time to breach a network is measured in days-to-weeks
• The average time to detect a breach is measured in weeks-to-months
• And zero breaches are detected via logs

How long does it take to realize that log management alone is not the answer?

The fact is that we’re dealing with massive amounts of information, and the “store and search” approach may help you achieve some level of compliance (today), but it does little to improve your security posture. Most organizations simply don’t have the time or expertise to search through millions (or billions) of daily log lines. When they do search, many will admit they have no idea what they’re searching for and give up.

Solve the Problem
We can increase (dramatically) the number of breaches detected and prevented, and next year’s report could tell an entirely different story. The “first step” is to admit there IS a problem and the next step is to give us a call.

The conviction of Albert Gonzales, and 20 year prison sentence for his role in the TJX and Heartland Payment System Breaches, was just one of several big wins for the agency that’s noted in the report. Of course, where vast sums of money are at stake, cybercriminals will evolve and evade.

In 2010 the DBIR notes a shift from massive credit card fraud to the much more targeted “Account Takeover” (ATO) attack. Leading the way was Zeus and related malware that’s built specifically to capture the login credentials to online banking. Once these credentials are acquired they’re used to initiate transfers from the victim’s account to one or more “mule” accounts which the attacker also controls. In some cases 10’s of thousands and even 100’s of thousands of dollars disappear in a matter of minutes.

There are some well publicized defensive measures you can take with regard to ATO, and we’ll touch on some of these in an upcoming post, but for now it’s important to note that this is a very lucrative attack and one that’s pointed squarely at midmarket organizations – particularly midmarket executives.   Your networks are considered easy prey, and you are easy to identify - think social media, and linked-in profiles.

The Secret Service is working to address this threat and in cooperation with a number of agencies and the Financial Services Information Sharing and Analysis Center (FS-ISAC), they’ve created the Account Takeover Task Force.

While they may not need to “take a bullet” for us, we know that defending financial systems is a complex task that spans the globe, so we just wanted to take a moment to recognize their efforts and say, “Thanks”.

The annual Verizon Data Breach Investigations Report (DBIR) is making headlines, generating tweets and motivating blog posts – like this one. Weighing in at 74 pages, it’s a significant report, and if you’re serious about getting a “state of the union” handle on network security, I encourage you to read it (several times).

In our commentary on the report, we’ll spare you the mind-numbing graphics, and focus on the insights and opportunities. You’ll find that most of the conclusions are not new, but the direction things are trending is something you need to know – especially, if you’re struggling to align your security budget with where it can be most effective.

We’ll be writing a series of posts centered on the report that blend their research with our experience and unique midmarket view. Is there a target painted on your back? Would your systems, processes or policies have prevented or detected these breaches? These are some of the questions we’ll explore and help you answer.

This is precisely why we ask the question: Got SIEM?
The Barracuda announcement noted that their web application firewall was “unintentionally placed in passive monitoring mode” and that “after approximately two hours of nonstop attempts” a SQL injection vulnerability was discovered and the breach ensued.   Clearly this activity was evident in the logs and uncovered during the post-breach forensic analysis.   It “could” have been detected while in progress, alarms “could” have been sounded, and frankly, if TriGeo had been monitoring the activity, the attacker “could” have been blocked long before the breach was successful.

Defense in Depth?
An SC Magazine article on the Barracuda breach, and others, suggests that the breach “highlights the importance of defense-in-depth.”  They’re missing the point.   The firms involved in these breaches already have layers of defense – probably far more than most.   What appears to be missing is visibility.   We make the mistake of relying on the technology to do its job without acknowledging that nothing is perfect, that people make mistakes, and that vulnerabilities will always exist.   The layered approach is critical – it can slow the attacker down.  They may get past one layer easily and struggle considerably longer on the next (for hours, days, even weeks), but eventually they will succeed.

Trust but Verify
So what’s the answer?  SIEM.  No, this isn’t a product pitch.   It’s simply a reality check.  SIEM exists for a reason.  It was developed to provide visibility and context, and the best SIEMs provide actionable intelligence.    There’s a reason that HP just paid 1.5 billion dollars for SIEM technology.   The network tools we all own are powerful tools and when used in concert, they can be a formidable defense, but the operative word is “can.”   They can be very effective, but are they?  If you’re not monitoring what’s happening on your network, you really have no idea.   Did an administrator misconfigure something when applying the latest update?   It happens.   Will you know if it does?

Recently, we announced our partnership with Rapid7, a company that philosophically has a lot in common with TriGeo. In the world of 140-character thoughts, the short version is: don’t get caught in risk paralysis, focus on actionable intelligence.

There’s a place for signature-based anti-virus, even if it’s just cleanup. There’s a place for Patch Tuesdays (or Mondays, or…). There’s a place for traditional vulnerability scans. There’s a place for PCI, HIPAA, and other compliance measures. All of those things exist to assist in the straightforward process of reducing your attack profile. If I only have anti-virus, I’m more likely to catch something; if I patch, I’m less likely to catch a virus that is more than a year old; if I scan, if I’m compliant, I meet a pre-existing standard.

So, you’ve patched, you’ve scanned, you’re PCI compliant, and you still get breached…

Unfortunately, this is the world we live in, where attacks rely on social engineering and data exfiltration, or use zero-day attacks that have no signature/patch. And frankly, 100% patch coverage is incredibly difficult.

So, where could you have made an improvement? One word…visibility.

A lot of Vulnerability Assessment tools will be happy to tell you something like, “you are running an insecure version of OpenSSH.” What they don’t tell you is, “but you don’t have that option enabled in your sshd_config so it doesn’t matter” - or, in English, “but that can’t be exploited, so I’m going to make it less important.” Even thinking about a typical patch scan, you might learn that you’re missing 10 patches, but what does that mean to your actual exposure, does it really increase the likelihood of a breach? It’s up to you to prioritize, investigate, collect your evidence, and, frankly, argue with your auditor or internal staff/management. I suppose one could argue that’s “actionable intelligence” - however, it’s your job to do the “action” and gather the other 90% of the “intelligence.”

There are a ton of really cool security tools out there and lots of innovation that have real use cases in real networks – tools like DLP (Data Leak Prevention), DAM (Database Activity Monitoring), WAF (Web Application Firewall), and even IAM (Identity/Access Management) and PIM (Privilege Identity Management). List of TLAs aside, navigating this landscape is horribly difficult unless you know where your issues are in the first place. This whole problem leads to a “risk paralysis” where we get stuck in this never-ending loop of, “I don’t know how to know if that technology solves enough of the problem to justify my time/dollars, so I’m going to table it and come back.” One of those technologies really could have saved your bacon, some would have just been throwing mud at the wall and hoping it sticks.

How do you know?

One of the first presentations at RSA was titled “Mature SIEM Implementations at Five Years: If We Knew Then What We Know Now” (also discussed over at Dark Reading).

It’s always interesting to hear real-world case studies, and this one shines a pretty big spotlight on the complexity of many Enterprise SIEM deployments. This complexity not only leads to long deployment cycles, but also failed implementations, frustrated IT and security staff, wasted time, and honestly, less buy-in from management that SIEM delivers real business value.

Here are some of the interesting highlights and misconceptions about SIEM deployments:

• Most of the mentions of SIEM at RSA, were very large-scale, enterprise-focused. Statements like “engage your SAN team,” conversations about Oracle deployments, minutes spent discussing custom code and “prioritization algorithms,” and comments about the number of incidents your “analysts” can handle are intimidating if you’re going into a SIEM pilot project/evaluation as a large enterprise (or deploying to a division of a large enterprise).

Let’s face it – talk like this scares the pants off of the SME! (See The Midmarket View for additional commentary on Enterprise versus Midmarket SIEM perspectives).

• The presenters recommended a six-month “infancy” stage when implementing SIEM. Their suggestion: try to accomplish as little as possible, as successfully as possible. Focus primarily on collecting data (they also mentioned turning off 95% of the defaults out of the box).

Are you serious? I’m not sure about any of you, but if I told my management they had to wait six months to get anything out of an investment on the scale of many SIEM products (relative to the size of the business), I’d have a serious uphill battle ahead.

• The presenters were spot on with their statement that the goal is to “add context to data and make it actionable”.

But why can’t we eat the elephant one bite at a time? A more reasonable approach: identify the problems you’re trying to solve with your SIEM implementation, and start with the easy (easier) ones. Learn as you go. Think iteratively, but on a smaller scale – the reality is that a lot of us are resource-strapped and it may take six months to become confident in a system, but most of us also can’t wait that long see real value and a return on the investment.

• During the session I also heard about the complexity of pricing models when looking at SIEM, and recommendations that you might want to outright negotiate pricing that factors in your growth and future deployment options, not to mention accounting for the services engagement that might be required.

That’s only part of the story. The challenge to the customer is to see the total cost of ownership: is the product you’re investing in appropriate for your environment? Do you understand the initial and ongoing commitment in time and dollars? This isn’t new, but SIEM can be a tough nut to crack – it’s not something we’re already familiar with, so we have a challenge when it comes to understanding something new AND making a good decision.

• Despite the difference in size, there are some interesting commonalities in the value proposition for SIEM for both the enterprise and SMEs. Examples of use cases for SIEM were mentioned in not just the SIEM-specific presentation, but also in presentations where SIEM was mentioned in relation to IDS, AV, and DLP.

These examples are present in every size organization: peer to peer or botnet activity, ancient viruses, access to unexpected ports from unexpected locations, data exfiltration, third-party breaches, phishing attacks. The reality is you don’t need a six month deployment or complex implementation or SIEM X.0 to detect most of this stuff.

If we can identify 80% of the breaches with 20% of the complexity (at 20% of the cost and in 20% of the deployment time) – I call that a success.  Your implementation can always grow to use those cool features on the glossy pages that may (or may not) be useful, but in the meantime is your data is walking out the front door?

The SIEM Revolution starts with the customer. SIEM as a market has matured to the point that if the enterprise products are still doing things wrong after 10 years, they deserve to be called on it.  As we face more complex, more distributed, and more targeted threats, there’s no reason to settle for the same old thing.

What do we see as we look forward, not just into 2011, but beyond?

Cloud, cloud, cloud: Top of the list, let’s just get it out of the way. We actually heard a couple of times from presenters at RSA (even speaking on unrelated topics) that they were asked to be sure to talk about cloud computing/security, so we know it’s already at the forefront of peoples’ minds (whether you want it to be or not). The concepts of cloud computing and cloud-based services are not so new anymore, and some really neat uses have come out of it (like cloud-based AV signature development, and the cloud-based fuzzy network perimeter). Auditors will learn how to incorporate it into their frameworks, vendors will learn how to deal with it, and we’ll still be left with a lot of data and a lot of tools we have to manage.

Multi-vector attacks are becoming the norm. From WikiLeaks to Stuxnet to the Verizon Data Breach Investigations Report, we keep seeing threats combine their powers to form a more complex attack. Social engineering and phishing, malware deployment, malware download, zero-day attacks, botnets, keyloggers, USB devices, physical security breaches… the possible ways to combine these attacks leave us wondering not if, but when we’ll be breached. The challenge is to think big and to understand and protect what’s important.

Mobile and user-owned devices have become more common. Smartphones and user-provisioned machines represent two things IT hates: a lack of control and a lack of visibility. One of the speakers at RSA had an interesting slide, moving us in time from mainframes all the way to the current mobile (and cloud) computing models that have challenged our concept of what’s important.

The next phase requires us to think not just about the endpoint, but what it is about the endpoint (and our network, and our data) that we’re trying to protect. Focusing on the data, not just the nodes on our network, helps us prioritize and look at how other technologies (like DLP) really fit into that landscape. Most IT/security environments will have to face multiple issues - securing what they can control down to the endpoint, identifying the risk of what they can’t, and addressing issues that also represent physical security and access concerns.

The market for vulnerabilities continues to move from quantity to quality. We’ve all heard about the Advanced Persistent Threat (APT) - which apparently has topped the list of top 10 security concerns for CIOs in a kind of “squeaky wheel” effect. As pointed out in a Friday presentation on Cyber Security Trends for 2011, the reality is most of us don’t have classified, life and death data that we’re protecting against a WikiLeaks-style exposure. What we do have is business-specific information (healthcare records, credit card data, intellectual property) and business process information (details on strategic advantages, sales and contract processes) that could both be exposed and used against us in creative ways.

Attackers are looking toward things like account credentials that provide continued access rather than a massive one-time breach of credit card numbers. Tools that focus on the data become more important - forcing IT/security to think more about the business and to really become part of the business processes themselves. Maybe auditors will join us in thinking this way, too - it’s not just about compliance, it’s about securing the business.

What do you see as you look forward, not just into 2011, but beyond?
There’s always a wealth of information presented at IT/security conferences and RSA is no exception. It’s hard to sum up a week-long tour of information security into a few quick blog posts, but we’d love to hear your thoughts. For those of you who attended the RSA conference (or just read all of the press, shared slides/notes, and any videos), what were your takeaways as the current and future problems of IT/security as we know it? What should have been on our list that we missed?

As I sat through days of RSA presentations, I started to tally up the obvious disconnects, mixed messages and faulty assumptions that you hear from enterprise vendors as they try to re-frame the discussion for the midsize universe.   Here’s three of the biggest:

Assumption #1: IT and security teams are separate, diverse entities.
During the presentation of a real-world case study on malware, the presenter described a classic SME environment when he said, “there are two of us, and neither of us are security experts.”  That’s two, not-quite security people responsible for IT and the security of 500 desktops, 50 servers, 6 offices and 44 remote access sites - with more on the way.   This midmarket IT team will have trouble identifying with phrases I’ve heard this week at RSA like “engage your SAN team” and “security analysts” (both from the Mature SIEM presentation).

Assumption #2: IT has time.
I know, the enterprise IT teams are busy, too, there’s no shortage of work.  But, things like product evaluations, testing, extensive due diligence, intense development - these are luxuries that the midmarket IT team simply can’t afford. These folks are trying to solve a problem. They’re trying to find a vendor that will help get them as close to a solution as possible and deploy it quickly without a huge development process – or a ton of services.  In a presentation on IDS/IPS, Richard Stiennon mentioned “most analysts can handle 3-4 specific tasks a day” – if that’s true of an “analyst” what does it mean for someone also responsible for all of IT?

Assumption #3: IT isn’t versatile.
In the enterprise world, moving objectives through the organization, getting buy-in, purchasing, and implementing solutions is a long process. New technologies like cloud-based solutions are approached with caution while they are proven in smaller business units, test environments, and limited pilot projects. Smaller organizations can be more versatile and are more focused on finding something that solves their problem. Those “two guys in IT” trying to mitigate malware infections implemented a cloud-based solution to route their risky traffic through the external network first – a solution they took from evaluation to purchase to implementation in 2 weeks.

We see situations like this every day. There are products on the market made for the enterprise and most of the attention from the vendors is focused on enterprise clients.  I understand it – these organizations are household names, but the majority of the business of the world is done through midsize companies.   Interestingly, there’s also a lot of talk about the convergence of IT and security, pushing security “down the stack,” and the proliferation of user-owned devices making security everyone’s issue. It sounds like those midmarket IT teams that are wearing IT and security hats are just ahead of the curve – that’s all.