Without information security processes, you are flying blind

The aim of the Security Analogies Project is to help spread the message of information security and its importance in the modern world. By drawing parallels between what people already know, or find interesting and how these relate to information security, the industry can increase understanding and support across the whole of society. As for me, I find that the world of aviation lends itself to many information security analogies.

One recent tragic event that we can hope to learn from is a May 2014 accident. On that day, a Gulfstream IV-SP corporate jet was destroyed in a takeoff accident at Bedford-Hanscom Field in Massachusetts. All four passengers and three crew members were killed in the accident.

In Bedford and the Normalization of Deviance, professional pilot Ron Rapp writes that the accident report is one of the most disturbing he’s ever laid eyes on. What happened? The highly experienced crew attempted to takeoff with the equivalent of the brakes on. The aircraft exited the end of the runway and broke apart, and the ensuing fire killed all aboard.

While Rapp’s analysis is written by a pilot for pilots, there is a lot in it that is highly relevant for IT and information security professionals. Particularly around complacency and human error.

Two of the more devastating outcomes of the report is that there are five Gulfstream checklists which must be run prior to flying. The pilots ran none of them. The cockpit voice recorder and pilot interviews revealed that checklists simply were not used. This was not an anomaly, it was standard operating procedure for them.

Rapp writes that obviously the gust lock was not removed prior to flying. This is a very big, very visible, bright red handle which sticks up vertically right between the throttles and the flap handle. It’s hard to miss the gust lock handle protruding six inches above the rest of the center pedestal. But it’s also the precise reason there are checklists and procedures in the first place.

While processes can be used as a method for improvement, if they are not followed, the results can be catastrophic. Bedford shows that it’s not only important just to have processes, they must be followed also.

Information security processes

So what does all this mean for information security? The ability to have a comprehensive set of information security processes can be of great benefit. Enterprises may want to consider developing a catalog of security processes. By formalizing information security processes, some of the benefits that can be obtained include:

• process improvement and optimization
• easier continuity of operations in the event of turnover
• can reduce redundancy
• ability to audit security tasks

Once the core set of processes has been defined, the specific processes are then prioritized and documented and the security process catalog is created. The formalization and creation of such a set of processes improves process maturity, which in turn can improve the effectiveness and efficiency of the overall set of information security tasks.

Where to start? For those venturing down this for the first time, the following methodologies provide initial sets of processes that can be used to start your own security process catalog:

• ISO/IEC 27001 ISMS (Information security management system)
• ISACA COBIT (Control Objectives for Information and Related Technology)
• ITIL security management

Based on the above, many firms will create processes at a high-level starting around:

1. Firewall management
2. user provisioning
3. patch management
4. access control
5. password management
6. incident response
7. malware protection
8. software development
9. incident response
10. disaster recovery/business continuity planning

Process planning and framework

Creating a process framework doesn’t mean simply writing a set of processes and then just dumping them on the corporate Intranet.

Process formalization is the starting point for security process and program maturity. With that, consider the following advice from Gartner about a process framework:

• Develop a security process portfolio that represents the desired state process environment
• Ensure you allocate time and resources for security process formalization.
• Selectively prioritize processes from this portfolio for assessment and formalization
• Formalize these processes via ownership allocation, assessment of existing processes, procedures and activities, formal definition, and resource allocation.
• Treat security process management as a dedicated management discipline, tasking process owners with the responsibility for improving overall security process performance.

Even with the best set of processes, complacency and human error can obviate all of its benefits. But even with those challenges, the benefits of good processes are compelling.

Ultimately creating a security process catalog is about efficiencies. The worst thing you can do is make process formalization becoming the end-goal, rather than have it being the means to your effective information security program.