SIEM Blog

NitroSecurity and Rockwell worked together to release several IDS signatures in conjunction with Rockwell’s own patch, in a joint effort to plug a vulnerability in RSLogix and FactoryTalk that was first identified by Luigi Auriemma in September, 2011.

The IDS rules, which have been released as part of the Quickdraw effort by digital bond, are proof of what can be accomplished when control systems vendors and security vendors work together. Rockwell has been able to respond rapidly from the start: with an immediate advisory, followed by a patch to address the vulnerability. Understanding the need for layered defense, they embraced the third-party development of IDS rules as well, which is commendable. It’s exactly what I would expect from Rockwell, who has a lot of cyber security talent in house and continues to keep one eye focused on control systems cyber security.

For those who watch SIEM Blog for SCADA-related posts, you may be interested to know that my new book “Industrial Network Security” is now shipping. The book gives an overview of industrial networking designs and protocols, an introduction into information security controls, and then addresses how to apply one to the other.

Well, SecureWeek’s way comes, anyway. Stop by to read my first in a series of critical infrastructure security columns. I’m enjoying the column and look forward to covering topics there that I wasn’t able to fit into my book.

What is a SIEM?

The Smart Grid as represented in NISTIR 7628 ... all it needs is meatballs.

What is a Smart Grid?

The Smart Grid (Simplified)

What does SIEM have to do with Smart Grid?

So what’s so special about the Nitrosecurity Smart Grid/SIEM announcement?

As many of you may be aware of the password management service LastPass may have be compromised and they have forced all users of this service to reset their master passwords.  This sort of information definitely gains my interest and led me to begin thinking about what this means and what a service like this is doing to protect this very sensitive information.

This is what I know based off the blog posting disclosure of information on the LastPass website.  A network traffic flow anomaly was detected on a non-critical system which then in turn lead them to further investigate their network.  During this investigation they discovered the same sort of anomaly on a database server.  This anomaly was characterized by them as “more traffic was sent from the database compared to what was received on the server”.  They also identified that their Asterisk phone server was a little more open to UDP traffic then it should have been.  And last but not least LastPass tells us that there were no indications of tampering such as adding new users to a system, or source code modifications on any of their systems according to their initial investigation. There really isn’t much to go on here from a real in-depth stand point, but in my own opinion there is enough to go on to make a few logical assumptions about what security precautions are in place and the level of monitoring LastPass is performing.

The first thing I want to talk about is the network anomaly.  Based off the characteristics disclosed by LastPass I am going to assume LastPass is performing some sort of network flow monitoring such as Netflow or IPFIX.  I would also assume this is the extent of their network traffic monitoring capabilities since they did not have any details into what data was actually transferred other than size.  Network flow monitoring provides a summarization of network transactions occurring on a network such as what IPs talked, what ports were used, how many total bytes were transferred, and the protocol that was utilized.  Network flow monitoring can’t provide the details of what information was actually in the transfer, what applications facilitated the transaction, or what users were involved.  This is concerning to me in that LastPass does not appear to have a technology like database activity monitoring or an application monitoring solution in place.  It appears that the assumption that only master passwords were possibly compromised is solely based off the amount of bytes being transferred in the anomaly detected via network flows.  The question that immediately comes to my mind is how accurate is that assumption without having visibility into the data that was transferred.  Could it be that only the master passwords were possibly compromised for say a large number of people which would result in X bytes or could it be all passwords stored in the encrypted data blobs for say a small set of people would result in the same X bytes of data being reported.  Without knowing what database tables were touched or what the database transaction looked like I fear that the assumption has a chance to be inaccurate.  Here is what really struck me as odd or stood out to me within the disclosure.

“We know roughly the amount of data transferred and that it’s big enough to have transferred people’s email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn’t remotely enough to have pulled many users encrypted data blobs.”

This in my mind supports that the assumption that it could have been say a large number of users were affected by having their master password and associated information compromised or it could be that only a small subset of people had a more in-depth data compromise.  What does that really mean though?  Well if in fact only the master passwords were compromised then LastPass implemented a good mitigation strategy forcing everyone to change their passwords.  Now on the other hand if it was only a small group of people that had their entire password data blobs compromised this mitigation strategy doesn’t work.  Just changing your master password doesn’t update the possibly hundreds of sites a user is storing passwords for within LastPass.  To effectively mitigate against this second scenario LastPass would have to rely on users and administrators for any and all services these users were storing passwords for to force a password change on those individual systems and/or services.  Do you see the difference here?

The second thing I want to talk about within the disclosure that is of interest to me is the following statement:

“For those of you who are curious: we don’t have very much data indicating what potentially happened and what attack vector could have been used and are continuing to investigate it. We had our asterisk phone server more open to UDP than it needed to be which was an issue our auditing found but we couldn’t find any indications on the box itself of tampering, the database didn’t show any changes escalating anyone to premium or administrators, and none of the log files give us much to go on.”

Let us start with the database server and it not showing any changes to it and none of the log files not giving them much to go on.  This to me is also concerning in that it kind of sounds like no remote log monitoring is enabled and possibly the correct level of auditing or logging of the database and applications may not be configured.  The second concerning part is the Asterisk phone server based off them even taking a look at it has access to the database server in that it can at least possibly route data to it.  Why I make this assumption is why would they add this to the disclosure and/or even really look at this server if it couldn’t possibly be a hopping point into the more critical database server.  I would be really surprised if the UDP misconfiguration is what actually allowed the compromise to occur, but we will have to wait for more details before we can confirm that.  With that I think the following statement makes it clear that this critical database server storing all the treasures in the form of password hashes, salts, usernames, and email addresses is accessible by a few non-critical hosts.

“Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. These happen occasionally, and we typically identify them as an employee or an automated script. “

The question I have here is why are non-critical machines even capable of interacting with the database server?  This appears to be the norm with scripts and employees executing commands or performing actions against the database server from time to time.  If it is in fact the norm I would recommend rethinking this, as it only broadens the attack avenues into the critical database server storing the treasures.

Now I don’t want to sound all negative here either, as I am only interpreting the limited amount of data that has been released through their initial blog posting and using that data to make some assumptions which could turn out to be completely wrong and/or inaccurate.  We will have to wait on more information from LastPass to see how far off or how accurate my assumptions are here.

I do applaud LastPass for two specific things.  First they went public with this information releasing some of the details of the attack and with that information being released they kicked off a very inconvenient mitigation strategy in which they had to have known would upset a few customers.  This is admiral by all means!  Secondly if you just happened to have read the  2011 Verizon Data Breach Report you would know that LastPass beat the average time span seen from a possible compromise to discovery of the compromise in that they discovered this within a day of the anomaly and not weeks or months later.  I can’t say for sure that the anomaly was caused by the initial compromise, but if it was kudos to LastPass for discovering it so quickly.  We will have to wait on more details to be released to be sure that the anomaly was in fact the initial compromise and not some follow on activity that identified an existing longer term compromise.

In concluding this blog posting I would love to hear some feedback on few points or questions.

1. Should services like this one offered by LastPass be subject to standards or regulations much like the credit card processing companies are under PCI?  Although services like this don’t store say credit card sensitive data they do in fact store the keys to that type of data, so should they be mandated to a set of standards or requirements?
2. What expectations do consumers have for a service provider like this one when it comes to protecting these sensitive keys to the gateways that define our online identities?
3. What does LastPass have to do to gain the general consumers trust back or have they already done this with their current mitigation and disclosure strategy?

Tomorrow ill be presenting at the ICSJWG, on “Obtaining Situational Awareness Across Isolated Systems.” So what does ‘obtaining situational awareness across isolated systems’ mean?  Well, ’situational awareness’ should be a well-known term by now; it’s used in almost every presentation in almost every security conference (at least the ones I’ve attended).  It means that you need to be aware of whats around you, so that you can assess your situation so that you can in turn make a decision and react.  I’m pretty sure that it originated as a military term, but it’s very suitable in the context of information security, and of industrial cyber security especially.

The ‘disparate systems’ are networks — both enterprise networks supporting business functions, and industrial control networks supporting DCS and process control.  They’re ‘disparate’ for two reasons.  First, These networks are isolated (or at least they should be — hasn’t everyone been paying attention?).

Second, some of these networks don’t speak Cybersecurity.  That is, they don’t run standard ‘IT’ protocols.  They may not even run over Ethernet, and if they do, it’s likely to be some real-time Ethernet variant like EthernetIP or SERCOS — something designed to support the migration of legacy field bus protocols into the modern age of networking. Finally, even if you wanted to monitor logs from your PLCs or RTUs, you’d be out of luck because I’m not aware of a PLC that produces a log for you to monitor.

So how can you centrally monitor more than one network at a time, when they’ve been purposefully isolated from each other, and speak different languages?

Worst case, you have just two of these networks to monitor across: the IT and OT networks; one for business functions, and one for SCADA and ICS.  Best case (for your security that is) there are many isolated groups,each clearly demarcated from the other with strict access controls in place to protect it from some other compromised system in some other zone.  You have to monitor, because that’s the only way to know what’s gong on around you, and you have to then analyze and correlate all of that data together in order to know whats really a threat so that you can make an intelligent decision and then act upon in.

Well, in cyber security terms, that means that your collecting logs for analysis, usually by a SIEM or Log Management product.  Logs are sent (usually) over UDP port 514. No encryption, so authentication, nada. So your situational awareness just broke your functional isolation, breaking your access policies and idling anyone involved in compliance efforts around NERC CIP, ISA-99, the NRC, etc.

The answer? Well, there are two.  For the first, the answer is easy in concept though perhaps a bit challenging in deployment (but worth it IMO): Configure your SIEM to collect logs in a distributed manner using multiple log collectors, and place one such collector in each secure zone.  So far so good, because now you don’t need to open up an insecure UDP port for each zone.  Next, implement a secure method of aggregating each isolated collector together.  One option is to use unidirectional gateways (data diodes), so that the stream of logs can’t be used as a backchannel attack vector.  Another is to open a secure hole in the ESP – one that is well defined (only allowing the collector to talk to the SIEM, and to nothing else … I know that the Nitro SIEM will onLy accept data from a validated source, and assume other SIEMs must do this as well), is encrypted, and requires authentication.  While you’re at it, you might as well make that ‘hole’ a logical diode as well, by adding the necessary firewall or IPS rules to deny all inbound traffic from the SIEM back to the collector.

For the second challenge, the answer is similarly simple in concept.  Hw do you collect logs from systems that don’t produce logs or speak the protocols understood by the SIEM?  The answer is, you don’t.  There are already systems in place that do that.  If you have a DCS, you have at least one data historian, and likely more than one.  These devices are already tracking what goes on in the OT world, and is essentially producing a ‘log’ of that activity.  So here’s the idea: you take your Historian data and feed it into your SIEM.  That might include all set points for critical systems, the status of safety systems, or just about anything. Now you can see the cause of an attack (the hacks that are inbound through the enterprise towards the ICS) as well as the effect of the attack (the end result of a SCADA breach that has been used to sabotage a process).

The most classic example of how this provides ’situational awareness’ is, of course, Stuxnet.  Stuxnet’s complete attack progression included:

• entry of malware into SCADA network zones using a variety of methods, including walk-in infections via USB and a variety of network vectors
• mutation of malware to propagate itself, look for specific target devices, and even cover it’s tracks by deleting malware code where no target was found
• once the target was found, Stuxnet used profibus command functions to write malicious code to a PLC (again, while also covering it’s tracks)
• once the PLC is modified, it looks for target conditions and, when found, sabotages them

Full situational awareness therefore requires that you be aware of the full situation in the enterprise network (where network-based Stuxnet inceptions could originate), within SCADA networks (where it may be walked in via USB, or where it might be seen inbound from the enterprise network), and the control system network.  Without the final piece,  the awareness of the total attack is incomplete, and there is no indication what system(s) might have been affected, what proceeds might haves changed, etc.

There’s been a lot of news recently around two batches of SCADA security vulnerabilities that were recently released: one from Luigi Auriemma consisting of 34 vulnerabilities against Siemens, Iconix, 7-Tech, and DATAC devices; and one from the Russian firm Gleg, which includes 22 modules for Canvas, including 11 SCADA 0-days.

Because of Nitro’s role as a SCADA security research company,  many in the  media, including Fox News, Business Week, CRN, eWeek, and others have contacted us to help them understand the realities of this situation.

Why is this even Important?  Vulnerabilities are released everyday …

True, but SCADA and Enterprise vulnerabilities differ in both context and consequence.

They differ in context because, unlike enterprise networks, you cant just download and apply a patch.  With an industrial control system, you’re dealing with finely-tuned, high-efficiency, real-time automated processes. You cant change these systems without careful regression testing.  So any newly discovered vulnerability is a serious concern.

They differ in consequence because of what SCADA is about.  SCADA is a supervisory component to industrial control systems.  SCADA isn’t just about electric companies, or national defense, or cyber war.  It can be about those things, but SCADA systems are used for monitoring and management of a very wide range of industrial processes.  Any automated manufacturing facility — whether the product is a cookie, clean water, electric energy, medicine, mass transportation, or almost anything — uses SCADA systems to some degree.

If you exploit such a process, you’re going to impact efficiency and profitability (for the cookie manufacturer), public health (for the pharmaceutical manufacturer) or national security (for bulk energy producers, nuclear facilities, etc.).  All of those consequences outweigh the average enterprise threat.

And these Systems are Vulnerable?

This shouldn’t be news, but SCADA systems are not secure.  At last year’s Blackhat, Jonathan Pollet of Red Tiger projected a chart in front a live audience, showing the results of hundreds of real vulnerability assessments in real industrial networks.  The SCADA portion of that network was the most vulnerable by far, and many of those vulnerabilities were well-known operating system vulns, some that had been known about for months or even years.

What that research also showed was that only about 12% came from SCADA zones, and less than half a percent from the actual controller networks—most were attributed to operations DMZ networks.  So, the introduction of a slew of SCADA vulnerabilities is a significant increase in the number of known vulnerabilities.  Now, consider where SCADA systems fit in the grand scheme of an industrial system.  Think of a computer that’s connected to a regular Ethernet, TCP/IP network on one side, and a specialized command-and-control network on the other.  IT’s the perfect spot to infect if you want to cause problems in the ICS.

The first network is well understood, but the second isn’t — at least not outside of ICS circles. So, I’ll simplify: imagine a network that was designed to send commands to devices, which would then obey those commands, in order to automate a complex process. The control systems operate on “when the temperature reaches a low threshold, turn on the burner” types of inputs and outputs.  It’s logic driven, carefully measured and planned and controlled.

The SCADA systems are an important cog in that machine: it stands for Supervisory Control and Data Acquisition; it collects data from the control system for this purpose, and it is therefore a direct attack vector into that control system.  In other words: if the SCADA systems are compromised, the ICS is at risk.  I won’t regurgitate Stuxnet specifics again – but that’s exactly what it did.  it wormed it’s way into the SCADA systems, propagated into the ICS, and sabotaged a specific process.

So What’s Being Done About it?

Luckily, a lot is being done about it.  First — the fact that vulnerability research is being performed at all is a good thing.  These 50 or so vulnerabilities are just the tip of the iceberg — we can expect that as SCADA is scrutinized more heavily, there will be more and more vulnerabilities revealed.

When they do, that’s when companies like NitroSecurity, Emerging Threats, the OISF, Digital Bond, and others all need to work together.  We’ve done it once — the Luigi exploits are fully detectable using standard IDS signatures thanks to an amazing joint effort between the Nitro Threat Analysis Center (NTAC) and the minds at ETPro.  With Digital Bond’s help, these signatures are being made easily available to a large community of industrial operators.

It’s significant for a few reasons: companies working together instead of vying for some advantage?  Openly releasing valuable IP for the good of the industry versus for profit?  What year is this, anyway?  Well, in industrial control systems, it’s the 90’s.  As George Hulme over at Information Week points out, Industrial Control Systems are the new Windows XP.  The systems are largely immature (from a security standpoint). However, the threat landscape has matured considerably — with the Stuxnet recently raising the bar significantly.  Now, there’s a new wave of threats approaching.  A concerted effort of security pros are in a familiar race: to secure an ever-widening chasm of vulnerabilities.

Lessons learned, best practice recommendations, and general discussions/debates concerning the leaking of classified and sensitive information from the U.S. federal government to Wikileaks has hit an all time high over the last few weeks.  With all this information circulating and the massive media coverage around this incident it may be tough to really decipher what is and is not the problem and what it all means in terms of how do we begin to address data leakage of this type.  To be perfectly up front and honest with regards to this posting and this particular incident there is no one size fits all solution to this problem and as many of us are seeing with other’s that have covered this topic there is no bullet proof solution at this time for sensitive data leakage.  This is why, in my opinion, sensitive data leakage has to be addressed at multiple levels and with multiple collaborating technologies to provide the widest or most complete prevention and detection strategy possible.

To address this specific incident we need to understand in a general sense what happened and who was involved.  The individual who was responsible for the leaking of this sensitive and classified data was an insider that had access to a wide range of sensitive and classified data per his job role as an Intelligence Analyst.  It is extremely important to understand that this individual requires access to this wide range of sensitive and classified data to effectively perform his job and has been cleared by a background screening process that deemed this person as a trustworthy individual.  This individual for one reason or another decides to abuse these privileges and downloads massive amounts of sensitive and classified data to his workstation.  He then smuggles this sensitive and classified data out of a secured area by recording it on several re-writeable CD and/or DVDs labeled as popular music artists to avoid any suspicions of what may or may not reside on these disks.
Now that we have a general sense of what the scenario entailed let’s look at some of the common mechanisms and technologies associated with data leakage prevention and monitoring.

One of the first thoughts by many when it comes to sensitive data protections is the usage of encryption, but in this situation encryption is really not applicable in preventing the data leakage.  Remember that the insider in this case required access to sensitive and classified data to perform his job as an Intelligence Analyst therefore this insider would also most likely be in possession of the appropriate encryption keys and/or mechanisms to decrypt the data.  Encryption prevents the disclosure of data only when the individual viewing the data does not have the appropriate keys and/or mechanisms to decrypt the data.  In many cases encryption is utilized to protect data from snooping.  An example of snooping is when an attacker is somehow successful at intercepting a data transmission between the sender and its intended recipient.  Another example of how encryption can be successfully utilized to prevent data leakage is by protecting sensitive data from accounts that require access to the file but don’t require the ability to decrypt the file for reading.  This is common for administrator accounts and accounts used to perform maintenance tasks such as creating access control lists and/or performing backup operations.  Since file level backups and access control lists can be effectively carried out without the need to decrypt the file encryption makes sense here.

Access control includes three key areas or capabilities: authentication, authorization, and auditing.  In most of the coverage I have read with regards to this specific data leakage case the majority of the attention has been centered on the authorization of the user and whether or not this authorization process was correct and/or an effective implementation of access control.  In my opinion based on a post 9/11 environment where intelligence changes at a very rapid rate and the possible consequences for an Intelligence Analyst not having access to pertinent data the authorization is not the real issue here.  I am not saying that the implementation in this scenario could not have been improved upon and/or implemented more effectively.  Obviously using things such as better data classification and possibly a tighter implementation of when authorization for certain sets of data should expire to ensure that authorization is not always maintained based off an initial need to access the data, but removed when it is no longer needed could provide some substantial positive improvements for preventing attacks like this one.

The bigger issue I see in this scenario is that the auditing trail may have or may not have existed and if it did exist it was not effectively being implemented into an operational process for detection and correlation of data leakage attacks.  This is really not all that surprising to me, as my past experiences working with the government has shown that all though their policy intentions may appear to have good intentions these policies are hardly ever interpreted into a realistic operational implementation.  This is directly related to things such as turning auditing on globally to ensure every single event and/or action is being logged resulting in mountains of data that cannot be easily correlated and/or operationally monitored.  Now the logging all this data is not really an insurmountable task, as it can be solved with massive storage devices, but turning this data into operational actionable items can be an issue.  If you have ever turned on global auditing of object access in a Windows environment you know what I am speaking about, but just in case let me tell you that a simple Windows file server that is only sporadically accessed can generate millions of events a day.  Now scale these million of events per a low usage file server into the Wikileaks scenario for which every file server within the government’s network is generating millions of events a day.  The resulting data set would likely result in billions of events a day turning operational monitoring tasks into a nightmare that probably cannot be done effectively.

Now if we did a little bit of filtering and/or tuning of this audit policy we may actually be able to turn this seemingly impossible task into a real operational win.  What I mean by this is we can still log everything per the requirement to a centralized log management solution, but additionally if we also apply some filtering to what is being sent to a Security Information and Event Management (SIEM) for correlation and risk management we would also see some major operational awareness and monitoring improvements.  With regards to this specific data leakage scenario the logging of sensitive data access would be one of the key events needed by a SIEM for correlation and risk management.  Events such as system uptimes, primary tokens being assigned to a process, or the successful running of a backup process could likely be filtered out and handled effectively by a log management solution for reporting and auditing.  Not to say these events are not important but I would prefer to see events such as system restarts, new processes being started, and failures of backup services over what I would classify as normal operational events as a trade off to improve my operational monitoring capabilities.   It really isn’t a trade off at all since the logs can be referenced and queried at anytime using a log management solution which in most cases is also directly integrated within the same user interface as SIEM.

With all file access being logged to a SIEM we will still be generating massive amounts of events which is why the proper SIEM selection criteria needs address the requirement of being able to handle billions of events and still be operationally usable.  What does this mean, well the data within the SIEM should still be searchable, normalized, and correlated in a reasonable amount of time.  The reasonable amount of time should be defined by your operational requirements and in this scenario I would venture to say the federal government would probably have a minute’s requirement versus an hour’s or day’s requirement.  This of course severally limits possible SIEM solutions, but that is a whole other issue entirely.

Once this data is logged to a SIEM what exactly would we want to look for that may have aided in detecting this data leakage attack while it was on going?  Before I answer this let me state that one of the key elements of any effective SIEM is its capability to perform the accurate and dynamic base lining of an environment.  Most SIEMs will attempt to do this by having an administrator define a set of variables for which they believe would be normal base line characteristics.  This would include things such as rates for which data is accessed, usage times, and other general usage characteristics.  This implementation is doomed for failure since environments such as the federal governments do not typically stay static in nature and tend to change over time.  This is why an effective SIEM solution must calculate dynamic baselines and avoid using manually entered and/or calculated data.  Now to answer the initial question of what to look for, well we would want to look for and/or have the SIEM parse out and alert on unusual user behaviors such as but not limited to the following:

• 10% increase in number of total files accessed over the total number of files accessed in our dynamic baseline by a single user.
• Access to any file that has not been accessed by another end user in X amount of time.  X would be something like 10-20% increase in the dynamic baseline calculated by the SIEM.
• Any access above the dynamic baseline related to the distribution of categories accessed by a single end user.  An example of this would be an Intelligence Analyst that accesses a wide range of topics/categories of files of seemingly unrelated content defined by operation names, geolocations, or even document storage locations.
• 10% increase in the volume of data accessed by any single end user over the dynamic baseline.

These are just a small subset of what we could look for and/or correlate with an effective operational SIEM implementation.  These would of course result in some set of false positives, but it would provide any security analyst monitoring an operational SIEM with a smaller subset of data to start his or her investigation or review of possible security related issues.  Additionally a good SIEM implementation would aid in narrowing this sub set of data even further with correlation capabilities such as being able to generate a correlated event with a higher severity rating when more than one of the previous alerts were triggered by a single end user.

The adjustment of severity ratings is another key ingredient of a successful SIEM implementation charted at effectively dealing with this data leakage scenario.  Characteristics of the file, user, and or system generating these file monitoring events should be taken into consideration when it is processed by a SIEM.  For example we know that the data classification within the Wikileaks scenario was generally classified as secret and the person accessing this data was an Intelligence Analyst, so these two factors could be used to create a specific severity rating for further base lining and anomaly detection.  An example rule could be but not limited to the following:

• 10% increase in total severity in X amount of time from the dynamic baseline by an end user.  X could be definable as minutes, hours, days, months or years depending upon the environment.  Starting out I would suggest minutes, hours, and days but months and years could provide some interesting results that maybe flying under the radar.
• 10% increase in the average severity in X amount of time form the dynamic baseline by an end user.  Again X could be definable as minutes, hours, days, months, or years.
• 10% increase in total or average severity in X amount of time from the dynamic baseline by the file classification.

These events or alerts would also generate a set of false positives, but would greatly reduce the amount of data a security analyst would need to process to conduct their investigation.  The real key to all of these rules is the generation of a dynamic baseline, as I stated earlier no operational environment such as the federal governments is going to remain static and it will in fact change overtime.  These changes must be taken into consideration without troubling an end user to populate what they believe is and is not the real baseline.

Another area of auditing within access control that may have aided in identifying this issue is with detecting of information being transferred to some sort of external media by the end user.  In the Wikileaks scenario the detection of writeable media being inserted into the end users system or the execution of a media writing application could have been correlated with any of the anomaly based rules we previously mentioned to correlate and generate a higher severity alert within the SIEM.  Of course this could still result in a sub set of false positives, but I would venture to say that since most secured environments specifically ban the usage of any removable media an event in this category should set off some higher severity alerts requiring immediate investigation.

In summary there are in fact methods that can be utilized to aid in detecting and possibly preventing scenarios such as this one with the federal government and Wikileaks, but it requires a substantial investment and commitment from the implementers of such a solution.  Even after implementation these solutions require maintenance and constant monitoring.  I will go out on a limb here one more time before I close out this blog posting and say that organizations such as the federal government can afford to commit the resources needed to pull this off effectively if they chose to do so.

Many of us as security professionals charged with deploying and maintaining security solutions to protect our infrastructures have grown to understand that a well thought out defense in layers strategy is required.  This concept or requirement is really nothing new to us, but what may be changing is how we define the layers within this strategy and what technologies are included in this strategy.  As attackers have diversified their capabilities to include an arsenal of application layer attack vectors and obfuscation techniques it may be time for us to rethink our defense layers as well.  Traditionally these defense layers consisted of technologies such as a network firewall, intrusion detection/prevention system, host based firewalls, antivirus software, and host based log monitoring solutions.  Now if you already have all of these layers in place your way ahead of most organizations and/or enterprises out there, but are these layers effective at detecting the application layer attacks that are commonly being used against us today?  The answer is not really, but they do have their place in the overall defense in layers strategy so do not go and throw these devices out of your defense strategy anytime soon.  This is where an additional layer of defense is needed and the implementation of technologies such as network based application behavioral analysis and/or application data monitoring can positively impact your effectiveness for detecting these more sophisticated attacks.

If you are one of the few that have already ventured out to investigate the application layer solutions space you may very well be aware of the fact that there are at a high level two basic technologies being offered.  The first set of technologies fit within the network based application behavioral analysis category and the second set fit within the application data monitoring category.  If you are like me you may be asking yourself what is the difference or why does it matter?  With those questions in mind let me try to explain the differences and similarities while still limiting this discussion to a few blog postings and not a dissertation.  The first area we will look at is how protocols are identified and/or classified by these technologies.

The methods for identifying or classifying an application layer protocol tend to be based off of a set of three common metrics.  The first metric is the mapping of well known ports to a service or application.  These well known port mapping assignments are assigned by the Internet Assigned Numbers Authority (IANA) and can be found here: Port Numbers.  This method is the least reliable and I previously wrote a blog post on this subject titled Network Flow Monitoring and Application Awareness, which describes some of the restrictions with utilizing this metric for application mappings.  Another great source of information for just how ineffective the mapping of well known ports to a service is Robin Sommer’s thesis titled: “Viable Network Intrusion Detection in High-Performance Environments”, specifically section 3.3.3 Traffic Diversity.   The second metric utilized is a statistical analysis of the traffic and its characteristics such as packet sizes, connection durations, data volumes, number of packets per flow, and numerous other traffic characteristics.  If you are truly interested in this area I would recommend reading the following documents: Class-of-Service Mappings for QoS: A Statistical Signature-based Approach to IP Traffic Classification, Profiling Internet Backbone Traffic: Behavior Models and Applications, and Internet Traffic Classification Using Bayesian Analysis Techniques. The third method utilized for application classification and identification is a set of pattern matching signatures that inspects packet payloads for protocol and application patterns.  This is probably the second most common method utilized after the well known port mappings and literally looks for common components of a protocol that can be used to identify it.  For example it is common for the HTTP protocol to be identified or classified by inspecting the payload for client requests such as HEAD, GET, and POST and also looking for the HTTP server response message status line.

The robustness and accuracy of a network based application behavioral analysis and application data monitoring solutions is directly related to how well the solution has blended these three common mythologies and can vary greatly from solution to solution.  In general network flow analysis solutions tend to limit themselves to only utilizing the well known port mappings for classification.   Network behavioral analysis solutions tend to blend the well known port mappings and a set of pattern matching signatures.  Application data monitoring solutions on the other hand tend to blend all three methods and provide the most robust and accurate identification of not only network protocols but application identification and classifications.  To understand why each of these solutions selected to implement some and/or all of these methods in a hybrid approach for identifying and classifying application protocols we really should walk through their basic use cases.

Network flow analysis solutions tend to focus on traffic analysis use cases.  These use cases range from network capacity planning and monitoring to security related focuses for identifying who talked to who and how the conversation was carried out.  Within these two large use cases the specific application layer details are really not all that important, so the common mapping of well known ports to services meets most if not all of the general requirements in this area.  One of the most common sets of reports generated within network flow analysis solutions would be Top Talkers refined by protocols, ports, source addresses, destination addresses, and byte counts.

Network behavioral analysis solutions tend to focus on communication anomaly detection use cases which have a greater need for classifying and identifying the protocols and applications being seen on a network.  These use cases range from the monitoring usage of peer to peer applications that tend to utilize a dynamic range of ports all the way to the detection of a protocol on an unusual port such as seeing HTTP traffic on a port other than port 80.  Both of these use cases require a hybrid identification strategy of both the mapping of well known ports to services and pattern matching signatures.  Some of the common reports generated from network based application behavior analysis solutions are peer to peer application usage, general application usage, protocol usage, and network communication anomalies such as protocols seen on odd ports or illegal usage of TCP flags.

Application data monitoring solutions tend to focus on the analyses of the applications and their associated content, which is why they require the most robust and accurate identification and classification of application layer protocols.  Use cases for application data monitoring span a wide range from the monitoring of sensitive data flowing across a network all the way to detecting anomalies in both the communication protocols and the applications utilizing these protocols.  Since the detection of anomalies within the communication of network traffic is really just an encapsulation of the feature set found within a network based application behavioral analysis solution it is relatively straight forward to point out that application data monitoring solutions support most of the network based application behavioral analysis use cases by design.  Application data monitoring solutions have the additional requirement to completely understand and decode application specific specifications that ride on top of the common network communication protocols to support the detection of sensitive information and anomalies within these specific applications and their payloads.  Some of the common reports that can be generated from an application data monitoring solution would include the same set of reports found within the network based application behavioral analysis solution with the addition of things such as usage tracking and anomaly detection of specific applications and the contents of these applications.

With all of this information we can now see that there are in fact a few differences between network based application behavioral analysis solutions and application data monitoring solutions when comparing how these technologies identify and classify the applications and protocols they examine within network communications.  In summary network based application behavioral analysis solutions identify and classify applications and protocols utilizing a combination of well known port mappings and a set of pattern based signatures. Application data monitoring solutions utilize this same combination of well known port mappings and a set of pattern based signatures, but also add in statistical analysis in examining the characteristics of the traffic to increase its capabilities and accuracy.  This subtle difference may not appear to have a dramatic affect on the capabilities of these two technologies and at first glance may seem almost irrelevant, but it does in fact have a distinguishing affect and we will look at this in the next part of this blog posting series.

Since our original media advisory and blog post on Stuxnet, NitroSecurity has released several detection signatures for its Intrusion Prevention and Application Data Monitoring products.

NitroGuard IPS signatures include:

• Two rules (Nitro ID 1012332 and 1012333) that detect the Stuxnet Trojan making attempted connections to an MS SQL Server Database using the default “hidden” Siemens password. We put them out in the SCADA rule set, with a default policy of “Alert”.
• Four rules (Nitro ID 1012334 through 1012337) to detect .LNK files and .PIF files being transferred over WebDAV. These rules are set to “Reject” by default.
• Two rules to generically detect CPL LNK files (Control Panel LNK files) on any port. These rules are be set to “Reject” by default

The  NitroView ADM (application data monitor) was updated with:

• A rule to detect  LNK files over any supported protocol and also within ZIP, TAR and GZ archives as well as in encoded email attachments and other document types that support link files.

While Siemens has issued tools for local detection and cleaning of Stuxnet on July 22, NitroSecurity encourages a defense-in-depth strategy, and urges its utility customers to implement these new detection capabilities immediately, to help mitigate infection and to protect against possible future variants of Stuxnet that may attempt to bypass detection by using alternate delivery mechanisms for infected .LNK files.

ESET has already discovered a new non-SCADA payload delivered by the windows .LNK exploit, which was originally used to deliver Stuxnet. The new payload is a keystroke logger, more information is available at ESET’s blog