Last week I attended the RSA Conference, the largest information security conference in the world. Alan Turing was the conference mascot and the question “what would Turing do” was frequently asked. Turing was a brilliant computer scientist, considered the father of modern computing, capable of seeing the math in everything and envisioned an age when machines would be as intelligent as humans. He devised what is known as the Turing test, used to gauge the capabilities of artificial intelligence. We’ve all taken Turing tests, they’re used to guarantee that a human is on the other end of an application or communication stream. For example when you register for a gmail account you see an image that is obfuscated in a way that only humans can decipher, this is called a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Therefore if the text in the image is read correctly entered there must be a human on the other screen reading it. This is an example of a Turing test.

For more information http://en.wikipedia.org/wiki/Captcha

The theme of the keynote presenters seemed to be a call for information centric security. I think this is appropriate considering they were presenting at a conference hosted by a company that was founded by (and named after) cryptographers who invented the most widely used asymmetric encryption algorithm (RSA) today. Cryptography has always served the purpose of two of the three premises of the information security triad - confidentiality and integrity (the third being availability which, it could be argued, cryptography inhibits). The need to protect information should not obviate the need to continue to protect the infrastructure. We are dependent on the infrastructure for the storage and transit of information and need to protect it.

Compared to last year there appeared to be fewer Network Admission/Access Control (NAC) vendors, fewer Data Loss Prevention (DLP) vendors and fewer Network Behavior Analysis (NBA) vendors. The newest technology based on an old idea is application whitelisting. Application whitelisting changes the logic used by many endpoint security solutions which today allow everything and deny the known bad. Instead application whitelisting denies everything and allows the known good. In an age where more malware is created than legitimate software it makes sense to invert the logic.

I am not Infosec Sellout.

Sometimes Hollywood gets it right. For instance, in the movies no matter how hard you try to run, the bad guys will find you. You can’t ever really hide.

As an industry, we sometimes try to run from hackers. We move from Internet Explorer to Firefox; from Windows to Linux; from IIS to Apache. But history is clear. You can run, but you can’t hide. The latest evidence? Mozilla, the alleged antidote to Explorer, was deemed vulnerable.

Of course Mozilla is vulnerable - it’s software, isn’t it? Granted, it may have fewer vulnerabilities. More importantly, it’s not as widely distributed, so it doesn’t get picked on as much. But, it is software and software is vulnerable. Switching from Explorer to Firefox might dodge a few bullets but it doesn’t reduce in the slightest the level of vigilance required. What does that mean?

We need to run toward the danger - headlong, full-tilt, all out - so that we can understand it and create countermeasures to protect ourselves from it. This is the stuff that keeps me awake at night. Where do we run out to meet the enemy? Where do we wait for them to get closer so we can see what they are doing? How do we better understand the structural flaws of applications or components that may lead us to vulnerabilities?

There are tools emerging like CVSS that will help. But even a system like this will have limitations. There will be lots of data on a handful of ubiquitous applications and nothing available on the thousands of custom built proprietary applications used by most businesses - Internet banking applications, web content management systems, customer service ticketing, business process monitoring, internal human resource applications, etc.

The bottom line - advising our users to switch browsers or implementing new applications on Linux will only delay the inevitable and may create a false sense of security. Keep your vigilance high. Learn everything you can about the latest threats and vulnerabilities. And never, ever assume that you can hide.

As CTO of a security company, I get my fair share of opportunities to dig deep into the technology looking for solutions. But I also find myself in the position of explaining technology to a wide variety of audiences. In fact, one of the most persistent requests I get is for easy to understand analogies for what we, as a company, do.

My new favorite is - not surprisingly - straight from my life. I’ve recently joined my local volunteer fire brigade (much to the chagrin of our CEO and board). Fire fighters are a great model for outsourcing a critical function. You may not have put much thought into “hiring” them, but just try to get insurance or a home loan in an area without fire service.

Furthermore, even though firemen only get attention when they are fighting fires, they spend their most critical time talking to people about how to avoid fires. Don’t stack flammables. Look out for frayed wires. Check your smoke detectors.

And their industry is regulated, too. Inspectors check for sprinkler systems, fire exits and extinguishers. Don’t have ‘em? You’ll get fined and then shut down.

But no one is running their own fire department unless they are very specialized or isolated, like a chemical plant or an oil rig. Even those fire fighting units are only for first response - if they can’t handle it, in comes the local fire department.

So, this is my new analogy for what we do: SecureWorks is like your local fire department. We spend a lot of time working to prevent fires. We watch the weather for lightning and droughts (viruses and Trojans). We watch the news for arsonists or angry, torch-wielding villagers (hackers and regulators!). We cruise the streets looking for power lines that get too close to tree limbs (intrusion prevention and vulnerability assessment). We conduct fire drills and inspections at schools and offices (professional services). We check the hydrants (firewall management). We help old ladies get cats out of trees (customer service). And we stay ready so that if a fire starts, it never gets to be a big fire (24×7 security monitoring and response). We even tell you how the fire began and if it was intentional (incident analysis and forensics).

And we do all this, so you don’t have to.

When the marketing folks asked me if SecureWorks “needed” a blog, I hesitated. There are lots of good security sites out there for general news, we already have a good system in place for sharing information with our clients through our Security Operations Center, and our PR team does a fine job of getting information to the general public.

But, as I look at our network of clients and the vast amount of data available from our attack database, I realize that having a way to share new or unfinished ideas and respond to issues outside of our service coverage would be useful to us and (I think) useful to other security professionals and the general public. In fact, this even serves to do something I’ve already been charged to do inside the company - stir the pot.

We have some excellent resources to share. A team of security professionals and experts, ranging from operational analysts to researchers and developers. A group of professional consultants and risk experts with a broad background dealing with compliance and security issues in corporations. Finance, marketing and sales folks with insight into justifying and explaining security to just about any audience. Data on millions and millions of attacks. Visibility into thousands of security audits and assessments. And a network with live data to test and validate hypotheses.

This is only the beginning - we’ll have a lot of growing to do in terms of what information we feel comfortable sharing and what people might want from this site. But consider this the first step!