One thing is clear: the traditional approach to protecting Enterprise and Government networks is no longer effective.  In an environment where there are no defined attack signatures security analysts and system administrators are continually looking for the proverbial needle in the haystack as they attempt to spot an attack.  Once they’ve done this, manually correlating data from multiple point products in time consuming and painstaking work – in reality, many organizations only find the vector and target of a breach when the attacker[s] publicly announce details. If there is no announcement it’s likely that many will never know the full extent of an attack!

This must change – and change quickly.  Some would argue that it’s already happening.  At June’s Mobile Computing Summit in California the term Situational Awareness (the ability to collect and correlate all network security data in real time)was on everybody’s lips – we predict that by the end of the year it’ll be in their networks.

We predict Situational Awareness will be the watchword for security professionals between now and the end of the year.

The dramatic increase in the use of smartphones and tablets has required many security professionals to fundamentally rethink their security policies. Issues like employees using their own devices [rather than corporate issue ones], a variety of mobile operating systems, and devices using a combination of fixed, wireless and cellular networks are posing all sorts of new challenges for Enterprise Security Analysts.  We agreed with Jack that these addressing these challenges was a top priority for both Enterprises and Government agencies, and that an increasing number of large organizations are quickly realizing that failing to protect their business against modern cyber threats poses a clear and present risk to their long-term prosperity.

Jack and I also discussed the recent Mobile Computing Summit, where I participated in a panel discussion on privacy and compliance.  The term Situational Awareness was on the lips of a large majority of attendees and, while many acknowledged that they needed greater visibility of their security position across their entire network, they still struggled with how to define it.  This must, we agreed, change – and quickly.  Advanced Persistent Threats to Enterprise networks will wait for no mobile device.

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.

In the latest episode of the eIQcast, Mike discusses his thoughts about the latest Black Hat show, the leading attack vectors (like SSL, iPhones, and web apps), and other assorted topics with Ross Levanto.

Running time: 9:51

Direct Link: http://eiqcast.podomatic.com/entry/2009-08-03T10_05_30-07_00

Events in 2009 provide further proof that PCI compliance is not enough to secure credit card information, yet PCI compliance is a major driver of technology purchases each and every day.

If the need-to-have products for PCI compliance are not enough for security, what are the nice-to-have products that can make an enterprise far more secure?

In the latest episode of the eIQcast podcast series, Ross Levanto asks eIQnetworks Product Evangelist John Linkous for his thoughts on the question. In the process, they discuss the features and functionality that IT and security teams can investigate as part of PCI compliance projects to greatly enhance the security of their systems.

Running time: 8:59

Direct Link: http://eiqcast.podomatic.com/entry/2009-06-05T07_07_13-07_00

In the latest episode of eIQcast, Host Ross Levanto and eIQnetworks Product Evangelist John Linkous analyze Hathaway’s comments and the industry’s reaction to them. The report Hathaway recently completed and sent to the President has not been made public; it’s expected that many of her recommendations will emphasize the need for ongoing monitoring of networks and security controls, as well as the need for the White House to step up its management of IT security across the entire government.

Editor’s note: This episode was recorded on Friday, May 1, and therefore references the RSA Conference that ended on April 23.

Running time: 10:57

Direct Link: http://eiqcast.podOmatic.com/entry/2009-05-04T08_49_21-07_00

Unfortunately Visa and MasterCard are making all of us play the same game of late. There have been recent rumors running rampant (alliteration anyone?) about another data breach of a credit card processor (coverage: SCMag, Dark Reading). Allegedly on the scale of Heartland and that is bothersome. Especially when we can’t get any information from the banks or payment card brands. So we are forced to call is “Breach X” for the time being.

So in the absence of any real data, what can we do to make sure nothing is compromised? Let’s take two paths, the first is for you personally (and your employees) and the other is for your company.

Personal Protection Plan

There is a high likelihood that your credit card data has been compromised as a result of either Heartland or Breach X. If you are lucky, then your bank will just issue another card and you’ll need to go change all your numbers and update all your e-commerce sites and the like. It’s a hassle, but it’s not that big a deal.

If you aren’t lucky, they won’t and you’ll have a compromised card on the street. That’s why you should be monitoring your personal credit accounts on a daily basis. Each of your credit card companies have a web site and you can log in daily and check the recent transactions. This is a great habit to get into.

By the way, as a “value add” the corporate security team can do training for employees on things like identity theft and private data protection. These kinds of tips may come second nature to you (as a security professional), but certainly not to the rank and file. You can win a lot of credibility points internally by turning these massive breaches into an educational opportunity.

Corporate Protection Plan

If you accept credit cards, data being stolen from a payment process isn’t your problem, right? In the strict sense, yes – but that is a pretty myopic view.

We need to learn about these attack vectors and make sure that it’s not going to happen to us. That means we probably want to start monitoring (or even blocking) unauthorized outbound connections. Rich Mogull has a great post on that.

You probably want to monitor your network traffic as another layer of defense, and also your systems to ensure malware or unauthorized configuration changes haven’t been made.

And most of all, you need to call your issuing bank and yell at them. It’s unacceptable that Visa and Mastercard have been sitting on this breach because the payment processor can’t get their act together. Whoever Breach X happened to should be out of business this time next week.

Yes, that’s harsh, but in this kind of environment, when customer trust is at an all time low and people are struggling – to not come clean and come clean quickly is just ridiculous. There is nothing like a public execution to keep everyone focused on doing the right thing in the event of a breach.

Now will the real [Breach X] please stand up?

Running time: 11:35

Direct Link: http://eiqcast.podOmatic.com/entry/2009-02-12T06_33_03-08_00

Moreover, the FAA appears to have responded to this incident in an appropriate way, by disclosing early, identifying the specific details of data that was breached, and (most importantly) identifying the problem on their own, without having the FBI or another three-letter-acronym agency do it for them long after the fact.  While the data that was breached was highly personal in nature (including both unencrypted and encrypted data on current and former FAA employees), this wasn’t a breach of air traffic control systems.  All in all, this incident was handled in a pretty professional manner.

However, regardless of how it was handled, the fact that this breach occured in the first place points to the criticality of proactive security.  While it’s good to be able to know (perhaps from a forensic analysis of event logs, system configuration changes, and other security-related data) that the data breach occured (especially in a timely manner), it wasn’t timely enough to actually prevent the breach from occuring at all.  To effectively address this kind of breach before critical data egresses from the environment, organizations need to get ahold of all of the relevant security data across the environment.  While we don’t know the exact profile of this particular breach (insider? low-and-slow attack that breached a network perimeter device? Brute-force credential attack against a web app?), we do know that in almost every case, it’s not enough to use only one source of data — such as log/event data, vulnerability scan results, system configuration data, and network flow data – to identify the problem; instead, it requires immediate correlation across all of these different silos of data, and an alerting capability that can identify the subtle nuances of attack profiles to ensure that security professionals get the information they need, without being downed by a sea of unrelated data.  And that, of course, is where point security solutions fail.

Ah, the Heartland breach continues to generate opportunities for us to get on the soapbox and talk about PCI compliance vs. security. The latest to appear is at Retail Info Systems News. Here is a little snippet (so I can make Anton a bit more crazy today).

“The message coming from the Heartland Payment Systems Breach is loud and clear. It’s reinforcement of what seemed to be evident from the Hannaford Bros. breach last year. PCI is not enough. Merchants have been relying on PCI as a crutch. Comply with the 12 requirements and credit card data is secure.

Of course, anyone that has been in the security business for a while knows the folly of thinking that any set of requirements and controls will truly create security. Throughout my 20 years in the industry, that just hasn’t been the case. Attackers are good and getting better. They are launching innovative attacks and rendering our defenses moot.

To be clear, there is value in the 12 requirements set forth by the PCI Security Standards Council. The PCI-DSS does a good job of laying the foundation for security, but just like you don’t live just on a foundation and expect to stay warm and dry in the winter, you can’t just rely on your security foundation for protection.”

You can check out the entire piece on the RIS site.