February 2010 Archives

This is a service announcement for product/service vendors.

As an information security executive, I appreciate all the work you do. The products and services that you develop are feature-rich and help me secure my environment, and I appreciate partnering with you to make that happen.

However, there are some rules that you need to follow:

1. Do not cold-call me and within 30 seconds ask me what my budget is. I'm not going to tell you what I am willing to pay if I don't have a previous working relationship with you and have sufficient confidence in your ability to provide me with a reasonable value proposition. I appreciate the fact that you want to make money, and it is in my best interest that you do. I realize that you will not be around the next time I need you if I do not let you make a profit. I do not mind paying for a product or service that is provided well.

2. Without having any knowledge of my environment, do not tell me that what I have been doing is ineffective and too expensive. It is an insult to my abilities to deliver value to my organization.

3. Do not claim that commercial products are always better and cheaper than open source alternatives. I realize that open source products also need to be maintained and that I need product-specific skills in order to operate them. If what you offer can be operated by somebody who's skill set is limited to operating a toaster, I probably do not want to do business with you.

4. Sometimes your call is not convenient. If I let you go to voice mail, do not call back three times in the following five minutes.

5. Don't schedule a follow-up phone call with a sales engineer if I do not explicitly agree to that.

Thank you for your attention.

The more I read and learn about the health care domain, and especially the public health arena, the more I find similarities between public health and information security. Take the following example from the CDC web site:

Public Health Surveillance has been defined as the ongoing, systematic collection, analysis, and interpretation of data (e.g., regarding agent/hazard, risk factor, exposure, health event) essential to the planning, implementation, and evaluation of public health practice, closely integrated with the timely dissemination of these data to those responsible for prevention and control.  -- Source: http://www.cdc.gov/ncphi/disss/nndss/phs/overview.htm

Sounds familiar? This is exactly what corporate security folks do all day! We have people systematically watching our systems and networks and we make sure that the things that they find on it are analyzed and appropriate actions are taken.

In public health care, a surveillance system provides an epidemiologist with eyes and ears on the ground. That is something we, as information security professionals, also need. We need to partner with our helpdesks to detect deviations from the normal call patterns. We need to partner with our field support techs to make sure that they tell us about policy violations they may encounter and we need to team up with the physical security teams to make sure that proper access controls and intrusion detection systems (as in: motion sensors, break-in alarms, etc.) are in place AND are being monitored.

Start building your information security surveillance system!

It is time we start step up our game and improve the way that we learn from other domains. Epidemiology has been around for a while, and they do a lot of cool stuff.

It is no secret that I am a SANS mentor and a GIAC Gold adviser. Yet, I am honored and extremely pleased to recently be named a Security Thought Leader by the SANS Institute. Of course, I will do my best to live up to the (raised) expectations that comes with such a designation! Read Stephen Nortcutt's interview with me here.

I was recently asked to prepare a 30-40 minute lecture for high school students. The point of the lecture is to explain what we try to accomplish in information security, and to convince them to enroll in our Computer Science program. After thinking this over for a bit, I realized that presenting to high school kids is not that much different than presenting to c-level management. Here is my rationale:

• Short attention span
• Little or no interest in details
• Focus on outcome, rather than on how the outcome is created
  
• Think they already know all there is to know
  

So, taking these observations into account, I must divide my presentation in two or three subtopics, each of which does not exceed 10-15 minutes. I must focus primarily on the show effect (what vs. how) and I must work around the fact that they think they know everything, yet they do not.

When presenting, always ending with that one catch-phrase that you want the audience to remember is good practice. Whether that catch phrase is "give infosec more money" or "enroll in the program" is irrelevant.

Initially, I thought that a nice Metasploit demo might be just want we needed to end the presentation. What is cooler than showing how to own a networked box in under five minutes? Not much, right? Well; true as that may be, high school kids do not live in the world of complex command-line invocations and text-based output. Running a Metasploit demo is one thing, but explaining what it actually means is another. Would the audience, that is used to living in world that predominantly consists of Facebook, Twitter and text messaging, understand the coolness of complete pwnage via a text-based interface? Doubtful.

So, taking it from there, I moved to browser-based stuff. Everyone will be used to having a browser at their fingertips and demonstrating a SQL-injection attack that can be used to retrieve private information would be something they understand. Oh wait-- private information is mostly worthless for most teenagers. They'll pretty much tell you everything you want to know right on their public profiles. While the attack would be successful, and I would show how to list out people's home addresses and/or credit card numbers, that would be of little or no value to them.

Clearly, I need to spend more time on this. Password cracking? Maybe, if that password can be used to do stuff with their Facebook accounts. Denial-of-service? Now, there is an interesting one. Taking away their access may be one thing, but showing how to DoS an individual's cable modem may not be necessarily the wisest move to do.

Any suggestions among my readers? I'd love to hear your thoughts on this. What can you tell a 17-year old that would capture their interest in a way that would be sufficient to at least let them consider to enroll in your program?