Recently in Strategy Category

With the summer approaching rapidly, it is time to start working on my next strategic plan. As a refresher from business school: strategic planning is the process by which an organization's long-term goals and objectives are identified and documented. Exactly how long "long-term" actually is depends on your environment. In my case, working of a three year strategic plan seems to make the most sense.

Goals are much like policies; they should be broadly defined, describe a desired outcome, be to the point, and (in most cases) be technology-neutral.

Information security strategic plans must not exist in a vacuum. Instead, the information security organization is typically part of a larger unit (IT, Internal Audit, etc.), which in turn is part of the overall organization. Any goals and objectives that are defined in the information security plan should be in alignment with those organizational goals.

In order to develop an effective information security plan that will be carried by the organization as a whole, it is often best to develop the plan top-down. In other words, start with the organization's goals and derive your information security goals from them. It is completely acceptable to identify some information security goals that are not derived directly from your organization's strategic plan, but the information security goals should never be in conflict with the organization's goals.

Goals are made specific by defining realistic and measurable objectives. Each objective typically leads to one or more initiatives that play a role in achieving the objective. By measuring how well initiatives are achieved, a picture forms of how well goals are realized.

Last week was the last week of my SANS mentor class for Hacker Techniques, Exploits and Incident Handling. Hopefully my students will try out for certification and pass gloriously.

As always, we wrapped the 10-week teaching cycle up with the ever-entertaining capture-the-flag (CtF) session that really drives home a few key points. In a previous blog post (computer security badness hierarchy. January 13, 2009), I argued that when we focus on our responsibility for securing information technology (as part of a much larger socio-economic information system), information security practitioners really only have to worry about a few types of things: Bad Users, Bad Configuration, and Bad Software.

Most CtF's are completely in line with my hierarchy and by using tools such as nmap and metasploit and by leveraging exploit code that is readily available in places like the Offensive Security Exploit Database (formerly known as Milw0rm), most challenges in "hack labs" can be solved easily.

The major exploitable categories are typically credential re-use (bad users), unpatched software (bad software), running unnecessary services (bad configuration) and lack of port filtering (bad configuration), and can be found on most (if not all) enterprise networks. Of course, there are many more attack vectors (think "Web" and "end-point").

As a security practitioner, there are few tools more valuable than a well-designed and fully implemented vulnerability management program. When possible, it is nice to drop the $100K+ to purchase one of the commercial suites, but by ensuring that all your computers (servers, desktops and laptops) are configured according to a hardening template and that they receive all patches in a timely fashion is already a major gain. Put on top of that a decent (current) anti-malware package, and you have a nice start.

Do not underestimate the complexity of "just" doing this. If you haven't started this yet, get going. If you have started, but don't think you're done: welcome to the club ;)

If you are embarking on such a project, think about collecting some metrics about how well you are doing it so you can measure progress and define success. Think of numbers like: percentage of end-points that have been patched appropriately, percentage of end-points with current anti-malware software, average lag between publication of vulnerabilities and completion of roll-out, number of end-points in compliance with the hardening template, etc.

Some time in the past, it seems that my work has shifted mostly from doing (what I consider) actual work to talking and writing about actual work.

Although I spend much of my time writing or reviewing documents and sitting in meetings, every now and then a call comes in that usually starts with something along the lines of "Something interesting happened and I think you may be interested in it". That phrase will send me right over to my incident response documentation toolkit and I start taking notes. Being responsible for incident response management gives me that one escape that everyone should have.

Most incidents can be dealt with as a matter of routine and can typically be addressed by help desk and system administrators. Such calls usually result in a quick resolution and happy customers. In my role (CISO-like) I care mostly about proper execution of previously defined security procedures and about getting some good reporting out of this process. That reporting will then be used to drive process improvements.

Not all calls can be resolved by relying on procedures that are documented in detail. Sometimes you can tell that it will be a good one, just based on the caller ID of the person who reports the event to you. Other times, you'll know in the first minute of the conversation that something interesting is going on. In those cases, having a documented incident response plan will be invaluable.

Your incident response plan may not give very detailed instructions for such odd cases, and that is fine. In such cases, your plans should give you the guidance to determine what to do and know that your actions have been previously discussed with key executives and that they have their support.

If your computer security incident response team (CSIRT) is activated, you want to things right the first time. For incident types where it is impossible, impractical or just too expensive to developed detailed incident response procedures, I have found it very useful to document some incident types, such as "Unauthorized information disclosure", and provide a basic strategy, roles and responsibilities, and reporting forms for these incidents. Rather than focusing on the cause of the incident, my planning revolves around the outcome. This approach is sometimes referred to as an all-hazards approach. An analogy is that in your response planning, you don't really care what started the fire, but you do care about how to fight it.

Incidents like this are meant to be addressed by the CSIRT and for a successful tactical and operational execution they rely heavily on the expertise and training of the incident handlers. I typically use the following boiler template when developing general response templates for CSIRT incidents:

1. One or two pages on general response strategy, including explicit assignment of some basic responsibilities. For example, one of the first steps in the identification and notification phase will be "CISO will send heads-up notice to CIO after initial report has been received".

2. A master checklist containing one or two pages of actionable items that cover the entire response process. Action items can be: a) Determine law-enformcement involvement. b) Assess and document scope of breach. c) Close case. Checklist must have enough space to check off the items, add comments, and record dates/times. Completed checklists will be used as input to writing up the post-incident report.

3. Some basic reporting forms. I tend to conclude my identification phase with a written report that outlines initial findings in a convenient one-page format that I can use to update key stakeholders. The initial incident report will be used as input to writing up the post-incident report.

4. Timeline forms that can capture date/time and actors of all actions that take place affecting the response. All actors are required to maintain their own timeline forms and they are also used as inputs for the post-incident report.

Approaching an incident response in this way, where a basic strategy is known ahead of time and "maintaining excellent notes" is embedded in the response is a key for successful reporting and process improvements.

My boss pointed me at an article in CIO magazine today. The article's title, The Unspoken Truth About Managing Geeks, was interesting enough to catch my attention. After reading it, I decided to put a reference up here in the hope that, even if it just came to one person's attention, the message conveyed in this work would spread wider.

See, for those of us who work in IT, there is nothing more frustrating than things (that we feel are important) are not getting done at all, or getting done in a backwards way. Much has been written about that already, and I am sure that everyone has their own war stories. The article's author, Jeff Ello, added another dimension to this.

"While everyone would like to work for a nice person who is always right, IT pros will prefer a jerk who is always right over a nice person who is always wrong. Wrong creates unnecessary work, impossible situations and major failures. Wrong is evil, and it must be defeated. Capacity for technical reasoning trumps all other professional factors, period"

The article introduces a few stereotypes that can be useful for IT managers: ego, victim mentality, insubordination, credit whoring, and antisocial behavior.

Other quote:

"What executives often fail to recognize is that every decision made that impacts IT is a technical decision. Not just some of the decisions, and not just the details of the decision, but every decision, bar none."

As a result of this observation, IT people spend a lot of time, money, and resources to fix problems that should have been done right the first time, but occurred because IT was not sufficiently involved in the decision making process.

The article hit home on many different points. Go forth and read it!