Cybersecurity: The Good, the Bad and the Ugly

Recently, I’ve contributed two articles to AOL Government, reviewing two of the key problems with cybersecurity legislation:

• Closing the Gap Between Cybersecurity and Privacy.  While the federal government has focused heavily on security, the fact is that privacy at the federal level is getting left woefully behind.  This article identifies what federal legislators can do to close this gap, and ensure that security and privacy are addressed in lock-step.
• Feeding Frenzy: The Problem with Federal Cybersecurity.  The U.S. government is languishing in dozens of cybersecurity-related bills, none of which seem to be coming to fruition.  Why?  This article identifies why the log-jam exists, and what can be done to fix the problem.

Check them out, and let us know what you think!

Leaving Las Vegas

FOCUS 2010 has now come and gone, and once again McAfee has put on a stellar event.  Great logistics, good venue, and most of all, excellent content.  Some brief observations on the week:

As mentioned in our last post, it’s getting harder and harder to figure out what some security vendors’ products actually do, because everyone is chasing the business problem du jour.  Encryption companies, DLP companies, SIEM vendors, and lots of other point product vendors are selling themselves as “PCI compliance solutions” and “cybersecurity solutions”, and everybody is throwing the terms “Enterprise” and “Platform” into the mix.  Of course, not everyone’s solution is a platform, and there are likely relatively few that are truly enterprise-grade software.  What makes an enterprise-ready platform? I’m glad you asked…

• Scalability.  A vendor can’t legitimately claim to be an “Enterprise” anything if their product doesn’t scale.  This means both scaling “deep” (to support thousands, or even tens/hundreds of thousands, of whatever it is that their product touches, whether it’s hosts, devices, apps, databases, or users.  Scalability also means scaling “wide”, across geographically disparate networks that are the hallmark of enterprise customers; if a security product can support 50,000 serrvers in a single data center, that’s great — but can it support 100 data centers around the globe with 500 servers each, with the same level of performance?

 

• Extensibility.  A fixed-function product that doesn’t provide a lot of flexibility is not a “platform”.  A platform provides a framework for a particular function or group of functions, and can easily be modified to extend capabilities to new data sources, or new additional functionality.  A great example of this from this show this week was McAfee’s ePolicy Orchestrator (ePO) — ePO is most definitely a framework: it comes with excellent out-of-box functionality and integration with other McAfee products, but also has well-documented API’s for extension, a tremendous user support community, and lots of readily-available code examples to demonstrate how it’s done.

 

• Granular Security Controls.  If vendors want their products to be used across the enterprise, they need to ensure that their product has appropriate access and administrative controls; if a vendor’s solution is used by both Network Operations and Security Operations, for example, then the product needs to have granular security (such as ACLs) to ensure appropriate separation of duty across business functions.

Another observation: customers are smart, and many of them have been burned by vendors’ promises not kept.  Countless customers dropped by the eIQ booth this week and regaled us with stories of products that vendors promised would scale (but didn’t… see “Enterprise” above…), wouldn’t support their technologies (see “Platform” above…), and/or wouldn’t solve the business problems they were experiencing due to lack of scope and visibility (a problem that SecureVue has solved for many a customer).  As technology vendors, we need to recognize that our customers keep the lights on; if we’re not helping them solve a business problem — not just providing them with a “technology checkbox” so they can say, “yes, I have DLP/SIEM/NAC/IDS/etc.” - then we’re doing them (and ourselves) a disservice.

Ruminations on McAfee FOCUS 2010: Day 1

Well, Day 1 of McAfee FOCUS in sunny Las Vegas has come and gone, and as I prep to head back over to the Sands Expo Center for Day 2′s activities, here are some observations from the first day on the floor:

• Security point products are a commodity now.  Hardly any vendor is hawking their technology as a point tool to address a specific problem: vulnerability assessment tools, encryption tools, SIEM tools, and everyone else under the sun is upping their marketing game by referring to themselves as a “platform”, and/or “enterprise software”.  The market is embracing the notion that individual point tools are useful to solve specific problems, but they’re not going to provide insight into the “Big Picture” of security and compliance across the enterprise on their own.  Of course, eIQ has been preaching this for years, and has the first and most advanced solution on the market to actually achieve it.  Imitation really is the sincerest form of flattery…

 

• McAfee really does have a great partner program.  Although yesterday was the first day of the FOCUS event, Monday was the Developer’s Conference, limited to partners with technologies that integrate tightly with McAfee’s ePO, DLP, AV, and other solutions.  A dozen rooms at the Expo Center were filled with McAfee engineers, product managers, and other hands-on technologists who provided candid insight into McAfee’s technologies and product roadmaps, while not shying away from some seriously hardball questions.  Yesterday, on the first day of FOCUS proper, McAfee SIA program reps were all over the floor, making introductions for partners, ensuring our booths were in order, and putting partners with complementary technologies directly in touch with each other.  I’ve seen a lot of “partner programs” from enterprise technology vendors, but McAfee’s really takes it to heart.

 

• Former President Bill Clinton can really draw a crowd.  The line to get into the ballroom to see the former president speak was several thousand deep, and stretched out into the Grand Canal at the Venetian.  He brought some formidable insight into global politics as we move deeper into the 21st century; although he didn’t touch specifically on cybersecurity, industrial/infrasructure sabotage (a la Stuxnet) or technological threats, he did setup a decent “global picture” of what leads to the motivation behind the people who might launch these types of attacks.

Cryptology, Digital Futures and the Commander-in-Chief



It could be a plot summary for the latest Dan Brown thriller – but it’s not.  It is, in actual fact, just some of the attractions at this year’s McAfee #FOCUS10  Security Conference in Las Vegas.

This year’s featured keynote speaker is former U.S. President Bill Clinton.  For many of you, this might be a stretch — after all, politicians are not known for their technical savvy – but it’s not as far fetched as you might think.  Not only was Bill Clinton President during the period that saw the mass adoption of the Internet as we know it today, but his privilege as Commander-in-Chief yields a unique perspective into both physical and virtual threats to the nation’s [and arguably the world’s] security.  I would also argue that his role as President enables him to offer an insight for the modern enterprise CISO: developing contingencies for increasing and ever-changing risks; collecting and analyzing threat data across a large, distributed enterprise; and building teams of knowledgable professionals to deal with it all.

While the former President’s keynote will undoubtedly get top billing, we’re also looking forward to presentations from some of the pre-eminent McAfee security experts.  A couple that caught our eye are:

• The McAfee Vision for Securing the Digital Future, presented by Worldwide CTO and Executive Vice President, George Kurtz
• The Global Threat Intelligence Difference, presented by Mike Gallagher – McAfee’s SVP and CTO – Global Threat Intelligence

We’ll be tweeting live from both sessions at www.twitter.com/eiqnetworks so look out for our updates.

Configuration Data: The Emperor’s New Clothes

Recently at eIQ, we’ve been meeting with some potential customers who have been comparing our SecureVue platform to log management and SIEM tools.  Certainly, that comparison has merit; like LM/SIEM tools, we capture and correlate log and event data from operating systems, network devices, applications, and databases.  Interestingly enough, we’re also seeing these customers really beginning to embrace the idea that log data is simply not enough to address many security threats, or meet compliance with a host of regulations, best practices, and frameworks.  This is great news; we’ve been preaching this for years now, and it’s great to see our competitors finally accept, however grudgingly, that they need to start capturing and correlating more than just log data.

What’s disturbing, however, is hearing these same potential customers say to us, “SIEM vendor [x] sent us over their data sheet, and they collect configuration data just like you guys do…” obviously, the FUD and “creative marketing” are in full gear at some of our competitors.  Let’s be clear: log-based configuration data is not true configuration data.  Any LM/SIEM vendor who tells their customers that they can achieve effective security and/or compliance solely by piecing together configuration-related events, without actively querying systems for configuration data, is doing their customers a tremendous dis-service, and potentially placing them at risk.

But why, you might ask?  Can’t you log just about everything related to system configurations, from installed applications and services, to hardware and device changes?  Yes… and no.  Like many things, the problem with log-based configuration data is in the details:

• What if Logging is Disabled? While basic logging is enabled by default on most operating systems, logging services can be disabled by malicious users and rogue applications. Attackers know that organizations rely heavily on log data for security, and will disable logs whenever possible to cover their tracks.
• What if Logging of Configuration Data is not Enabled? By default, many different types of security information are not logged – for example, changes to Windows registry settings, and events associated with many different UNIX daemons. In addition, most firewalls, routers, and other devices do not have any configuration auditing enabled by default. To capture this information, a system administrator must forcibly enable logging of this data, and ensure that enough log space is available to store it.
• What if Required Configuration Data Cannot be Logged? Certain types of security configuration data simply have no native mechanism for logging, such as Windows registry access control settings. To capture this data in logs, system administrators must build “adapters”, “connectors” or other shim-type solutions to capture this data – if this can even be done for the configuration data required.
• What if Historical Log Data Doesn’t Reflect Actual Configurations? Log data can only piece together individual events that “should” represent the current state of what a system looks like. But does this reflect the actual and current system configuration?
• What if Logs Become Full? Systems and network devices maintain a finite space for log data. Enabling certain high-volume log events, such as system performance metrics, can rapidly fill up available log space, causing the system to either begin over-writing log data or – even more dangerously – begin dropping information that can’t be written to full logs.

And of course, capturing real configuration data is still only half the story; to be really useful, security solutions that collect both log and configuration data need to be able to correlate them; if a potential attack occurs on a system — a large number of failed logons, or perhaps an IDS event suggesting a system compromise – it’s critical to be able to correlate this with changes on the system over time.

LM/SIEM solutions are getting better with time; vendors are finally listening to customers who are demanding comprehensive solutions that address a broad range of security data, not just logs and events.  But it’s critical to understand that different vendors mean different things when they say that they collect “configuration data” — choose wisely.

Ten Reasons Log Data is Not Enough #8: Reacting FASTER

Can you react as fast as The Flash?

So here’s the thing. As we’ve been talking about (and I’m assuming you are bored with the topic already), log data is not enough. One of the key reasons we usually overlook is the reality that logs are a BACKWARD looking indicator. If it’s in the logs, it’s already happened and therefore you may be too late to stop an attack which already happened. Unless you have a time machine, that is.

Now to be clear, looking backwards is very important. Doing a post-mortem after any kind of incident is absolutely critical. And the log data is critical for forensics purposes to figure out what happened and ensure a data breach is contained and the damage controlled. But unfortunately, by the time your logs see something, it’s already happened and therefore it’s fairly unlikely you’d be able to intervene and stop the attack.

For many years (back from my Security Incite days), I’ve been talking about this concept of REACTING FASTER. My contention was that you can’t get ahead of the threat, so you better be able to figure out what’s happening so you can remediate and contain the damage. You can’t do that with logs. But you can react EVEN faster if you are looking at these other data types. For instance, by correlating the data you get from configuration assessment and performance metrics, combined with the events – you are more likely to catch something that is happening, than if you were just looking at the logs themselves.

It’s a concept known very well to lawyers of all shapes and sizes. Despite your potential disdain for all things legal (especially if you’ve had a disclosure event), the need for corroborating evidence makes a lot of sense. It turns out that having information to corroborate the attack vector and root cause is key to being able to react faster. I’ve yet to meet a security professional who’s told me he/she has too much time. We don’t get to finish everything on our list every day, so we need to work smarter and that means reducing the number of false positives and also investigating only the alerts that present the greatest threat to your environment. If you can prioritize more effectively, your security will improve – guaranteed.

It reminds me of my days in the anti-spam business. We wouldn’t rely on just one detection method to determine if a message was crap. We’d use over 50 different techniques and analyze the results to get a more statistically relevant answer. That’s what eIQ does with all the additional data types. It allows customers to get closer to the truth before spending a lot of time going down the proverbial rat hole.

And saving time is a good thing for everyone.

 

More thoughts on “After the Breach”

A couple of days ago, the folks at McAfee put up a very good blog post really delving into the specifics of what to do when you find a data breach. To be clear, there are few days for a security professional that are more important than QUICKLY identifying the root cause of the breach, fixing what can be fixed, and taking down what can’t. Remember, it’s about containing the damage and living to fight another day.

But let’s level set up front. Breaches happen TO EVERYONE. If you have been doing security for any length of time, your networks/systems will be compromised. That’s the nature of the beast. That’s why in my book on building a security program, “The Pragmatic CSO” I advocated a process to define incident response and stressed the importance of documenting and practicing that process.

Interestingly enough, the McAfee post highlights some things about investigation and recovery that are not as commonly known as they should be. First that the attackers are usually long gone before you discover the issue. That does happen sometime, but for those that implement a philosophy of “react faster,” and monitor their key systems (which you need to do for PCI compliance anyway), the hope is that you do catch the bad guys “in the act.”

Secondly, you CAN’T TRUST logs. That’s right, log management is something that eIQ does and I’m still here saying you can’t trust the logs entirely. Why? Because a savvy attacker is going to shut down logging. Or they are going to tamper with system logs. Only by externalizing the log files and supplementing with additional data types can the logs truly become useful. That’s right – log data is not enough.

To be clear, when you are investigating a breach and trying to contain the damage – more data is better than less data. I’m not saying at all that logs aren’t important. I’m saying that you need as much corroborating evidence as you can gather. Anything to validate the attack vectors and more accurately piece together what happened.

The McAfee post goes on to highlight the steps of an incident response plan (identify the breach, contain the damage, make sure it doesn’t happen again) and those recommendations are good. I’d also highlight the need to do an incident post-mortem, document the findings and make sure the situation is discussed at all levels of the organization. Breaches happen, there is no shame in that. But not learning from each successful attack and improving your organization’s ability to defend itself is the real sin.

eIQcast Episode 22: Update on PCI

Discussions about PCI-DSS rules this year have focused on how effective the guidelines really are at preventing theft of credit card data. Recent survey data indicates merely following PCI does not protect a wide range of protected data.

In the newest episode of the eIQcast, eIQneworks Product Evangelist John Linkous provides an update on PCI compliance and how far it goes to actually keep credit card data secure.

Running time: 10:38

Direct Link: http://eiqcast.podOmatic.com/entry/2009-10-28T13_09_11-07_00

The Best Security Reacts Quickly to Change

I’m certainly not above lifting verbatim research that I believe is helpful to security and compliance practitioners. And the title of this post was lifted from Gartner’s John Pescatore’s post entitled “Who Moved My Soap – The Best Security Reacts Quickly to Change.” Now I could go forth with all sorts of don’t drop the soap in DisneyWorld jokes, but that would obscure the real point, which is not about Pescatore’s hygienic preferences.

Security professionals are not driving the ship. The business folks are. So security folks that are resistant to the ebbs and flows of business will not be successful. We have to face the reality that we (as security professionals) need to adapt our defenses both to the actions of our adversaries, as well as the reality of our businesses. Budgets come and go, projects are re-scoped, and priorities change. That’s business. That’s life. Deal with it.

But you cannot adapt in a vacuum. In order to react quickly (which sounds very similar to my personal REACT FASTER mantra), an organization needs to understand what they are looking for. That means they need to be monitoring as much as they can, establishing what is “normal” in their environment and then watching for what is NOT normal. Things change all the time, but if you don’t know HOW they are changing, there is no way you’ll be able to understand WHY things have changed, and therefore you’ve got no shot to address the issue…before it’s too late.

Oh yeah, did I mention I’m a big fan of security monitoring?

ReadySpace Selects eIQ to Drive Managed Security Service

Yesterday, eIQ announced that ReadySpace, a global services provider headquartered in Singapore, has selected eIQ SecureVue as the basis for a new set of managed security services focusing on real-time security posture and compliance automation. ReadySpace’s head of managed services, David Loke, had this to say about SecureVue:

“During our evaluation in a controlled environment, ReadySpace found that eIQnetworks solutions identified, within 3-Clicks, thousands of different attacks on our servers which had subsequently been infected by viruses that other security products would have completely missed. SecureVue, with 2 more Clicks then reported the extent of the infection, successfully identifying that our servers had become the attackers,” said David Loke, head of managed services at ReadySpace. “We agree that log data is not enough to manage the security for our hosted customers, which include well-known brands such as eBay and Singapore Airlines. There is a need to look at and consistently correlate far more information to provide managed service customers with complete visibility. eIQnetworks’ SecureVue provides exactly that.”

I couldn’t have said it better myself. Our competitive win over other SIEM and log management vendors at ReadySpace really highlights the power of using SecureVue in a managed services model. MSSPs can start with a simple security monitoring service and layer on additional services (like compliance reporting, correlation, performance management, and network behavioral analysis) for an increased price. The cost of the SecureVue platform is covered by the first service sold and the rest is PURE PROFIT. It’s a very powerful model for service providers looking to broaden their service offerings to customers.

We are pleased that ReadySpace has joined the eIQ family and are looking forward to working with them to solve their customer’s joint security and compliance problems.

You can check out the full release here.