[BreachExchange] Without information security processes, you are flying blind

Audrey McNeil audrey at riskbasedsecurity.com
Thu Mar 31 20:30:51 EDT 2016


http://www.csoonline.com/article/3049971/leadership-management/without-information-security-processes-you-are-flying-blind.html

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:

Firewall management
user provisioning
patch management
access control
password management
incident response
malware protection
software development
incident response
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:

1. Develop a security process portfolio that represents the desired state
process environment
2. Ensure you allocate time and resources for security process
formalization.
3. Selectively prioritize processes from this portfolio for assessment and
formalization
4. Formalize these processes via ownership allocation, assessment of
existing processes, procedures and activities, formal definition, and
resource allocation.
5. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160331/80d7c3ed/attachment.html>


More information about the BreachExchange mailing list