Around the same time that Professor Luckham and his team was working on CEP applications in network management and security management, I was leading efforts to build network and security management control centers for the United States Air Force.  In the beginning, dating back to 1994, my Internet-related work was for Air Combat Command (ACC), working out of ACC headquarters at Langley Air Force Base.

In 1997, I lead a technical team that developed countermeasures against an actual distributed Internet-based attack on the Langley AFB SMTP email infrastructure.  This attack was documented in a technical paper, E-Mail Bombs and Countermeasures: Cyber Attacks on Availability and Brand Integrity, IEEE Network Magazine, Vol. 12, No. 2, pp. 10-17, March/April 1998.  In addition, this attackand countermeasures I designed was featured in Popular Science Magazine in an 1998 article, War.Com and other news channels.  I also published a number of related papers on this topic.

Our team used a rule-based approach for countermeasures against massive email bombs attacks on the Langley Air Force Base email infrastructure.   We called this rule-based system, BombShelter. and it was written in PERL.  I developed both the original software architecture and the original working prototype for BombShelter (in two days) and then we turned the software over to our team who used the rule-based approach for daily attack countermeasures.

I watched for days, and then weeks, as my team designed rules, and the attackers wrote new attacks that circumvented the rules.  Some folks in the Pentagon used to say that I “lead the effort to fight the first war in cyberspace”.   It might have have been the first cyberwar, I am not sure, but it was certainly the first publicly documented cyberwar.  There is no doubt about this.

Without getting into all the historical footnotes and significance of this cyberwar that was fought with experts and rule-based systems, I would like to jump to an important conclusion.

Rule-based systems are useful, but have limited functionality and scaleability in most complex event processing applications.

Rule-based systems are human resource intensive because rule-based systems cannot learn and adapt on their own, humans learn and then write new rules.  This is how rule-based systems work.

This is the motivation behind why I spend a lot of time to search for new, more efficient and adaptive methods as alternatives to rule-based systems.   After extensive research, I published a series of papers on the future of intrusion detection in the Internet.  Intrusion Detection Systems & Multisensor Data Fusion - Creating Cyberspace Situational Awareness [1], helped lead an evolution in Internet security, particularly in the area of network-based intrusion detection systems (IDS).

In my published research work, motivated by limitations with rule-based approaches, I used the same mature functional model that is used to process missile attacks, control global air traffic, and other complex event processing applications in physical space; but I applied these concepts to cyberspace.

Around the same time, Professor Luckham and others were working on similar problems, all related to real-time detection and response to threats in cyberspace.  They were also funded by the US government.

Sidebar: Stream processing of transaction- based systems (databases), another area of interest, was focused on a totally different problem, which was the low latency processing of straight-thru processing in databased-oriented systems.   These stream processing systems were, and remain however,  rule-based systems.  The problems we were trying to solve in cyberspace, however, cannot be efficiently and pragmatically solved by rule-based systems alone.  Only relatively simple scenarios can be efficiently detected by rule-based stream processing systems.

The vast majority of complex event processing classes of problems require rules plus advanced algorithms that can learn and adapt in real-time.    I know this, not from reading papers or taking university classes on rule-bases systems, but from working on some very challenging operational problems in real-time.    This is why I remain interested in complex event processing and why I continue to elaborate on why rule-based systems have limitations.

Over the past decade exploitation techniques have been developed and refined to the point that very little expertise has been needed to successfully exploit software vulnerabilities.  These refinements have lowered the bar for attackers and drastically increased the probability that an attack will be successful.  This has led to the need for mitigation techniques that can prevent or otherwise reduce the reliability of a given exploitation technique.  In relation to one another, we can think about exploitation techniques as attempting to drive the probability of successful exploitation to 100%, whereas mitigation techniques attempt to drive the same probability to zero.  While probability gives us a nice measure for the effectiveness of a mitigation technique, it doesn't give us immediate insight into the specific problems being solved by mitigations or the techniques that are being used to solve those problems.

Understanding the problems that are solved by mitigations is what provided the motivation for the presentation I will be giving at BlueHat.  Many of the materials in this presentation were taken from my work with Leviathan Security Group and have been repurposed to focus on taking attendees on a journey through the technical evolution of the mitigation techniques developed by Microsoft.  This evolution is illustrated in terms of the problems each mitigation technique is attempting to solve, the methods used to solve them, and how well each mitigation has stood the test of time thus far.  The journey itself starts first with /GS and ends with a glimpse of the mitigation techniques we might expect to see in the future. 

Blogger: Dan Blum

It is no surprise for us to hear loose lips flapping in India about a capability to decrypt Blackberry and other carrier traffic.

After all, we’ve done basic threat analysis for years and it was only months ago that I was brought into a company-wide CISO meeting at a U.S. defense contractor to help them hash out their travel policy for mobile devices. Going into the meeting, I knew their policy restricted taking devices to a list of countries considered dangerous – but there was an exemption for BlackBerries.

Our research uncovered that BlackBerry is pretty secure in most respects. It has transport encryption along with optional password protection, remote kill, disk encryption, and S/MIME encryption. Viruses have not flourished on this functionally limited and closed platform. Few if any third party add on programs are required for additional protection. Nonetheless, I went into the meeting prepared to talk with the CISOs about the risks and security limitations of life on BlackBerry.

Was the BlackBerry exemption reasonable? At the time, BlackBerry transport encryption was not known to have been broken (to be fair, the article listed above still qualifies as rumor, not certainty of breakage). However, I pointed out that it is dangerous to assume well-equipped attackers like military or intelligence organizations can’t crack transport encryption. And even if they haven’t cracked the BlackBerry network and whole disk encryption features, sophisticated adversaries have other attack paths. Check out Neal Stephenson’s excellent book Cryptonomicon for a description of how a talented adversary might “see” your keystrokes and screen images through a motel room wall, for example.

If one of your employees – such as a key scientist, project manager, or executive – is targeted for surveillance and is carrying sensitive data through certain countries, one could argue that he or she had better undergo serious counter-intelligence training.  Learn to spot and shake tails, sneak into dark alleys for that BlackBerry fix. Learn to paper the closet with layers of aluminum foil and send messages in the dark. Defend that BlackBerry with encryption, long passphrases, and kung fu. But unless James Bond is running your company, I doubt this is what your executives have in mind for the next business trip!

Assuming your organization’s lower level employees are like needles in a haystack and won’t be bothered could be an exercise in wishful thinking. It is always possible that nation states are monitoring some or all of the airwaves. Not so long ago the NSA had a massive a covert surveillance program in place. Years before the government was reportedly snarfing up terabytes of emails and crunching them through a program called Carnivore. And of course, selective monitoring of people on watch lists continues on a large scale. This is just the surveillance we know about in the U.S. We suspect there’s more behind the scenes and especially in countries such as China. Even if you train your non-specifically-targeted low level employees to write and speak in search-keyword-free code, the carnivore programs of the world are pretty good at sniffing out those interesting needles – such as descriptions of your business plans, manufacturing processes, and trade secrets.

Sound paranoid? I admit that I don’t know what the probabilities of being targeted or monitored are – just that it can happen. It’s the height of arrogance to believe that a nation state can’t get your information if they’ve targeted it and you’re within their borders. And it’s dangerous to rely on security by obscurity when medium or high consequence information must be protected.

What can be done? If key personnel can't dispense with the BlackBerry (or any other email device) during international travel to those countries where information may be most at risk, they (the users) should limit communications to what they’d feel comfortable uttering over a potentially-monitored telephone call. Controlling incoming communications – messages sent by others – is a harder problem. Until data loss prevention (DLP) products become more contextually sensitive about the travel issues, it may be best not to synchronize the BlackBerry with the overseas user’s home mailbox. Instead, have the user give out a temporary address for the BlackBerry and warn senders to be discreet.