Re: Business Continuity Plans for an Information Security Office

[Jim Dillon <Jim.Dillon () CUSYS EDU>]

To take Steven's thoughts a step further,

 

It is also critically important to have strategic and senior management
granting criticality direction as part of a well developed BIA.  It is
unfortunate that the BIA's that do exist are often sponsored by IT
departments and not management.  Ask any department, any function what
is critical and they'll all have an opinion.  In the event of a larger
scale interruption however, you cannot afford to sort out the loudest
screams - decisions must be made on a criticality and business process
basis.  In the best imagined approach the BIA would exist whether or not
IT was involved, and IT's position would be one relegated to supporting
the items identified as "critical" in the BIA.  What part does IT play
in those processes deemed critical?  Instead the BIA efforts are often
skewed towards IT supported processes only, and real criticality is
masked by the desire to serve all customers, given all customers can
find something "critical" in their operation.  Reality says that in the
worst cases, certain programs, schools, even whole campuses may simply
cease to exist as a reaction to the rare event.  That is a call that is
difficult to make in the middle of a crisis if the consideration has not
already occurred.  

 

Said more simply, IT should be one of many service functions that
designs recovery and continuity plans based on a business oriented (not
IT oriented) BIA.  Approval, testing, and evaluation must then involve
the managers and providers of those services and data items that are
critical, based on the BIA.  That's the first order of business GIVEN a
large scale disastrous event.  Certainly recovery capability and plans
will exist and should for the more common, lesser impact events, but a
proper view of criticality is instructive in right sizing a solution for
every event.  Even small events can have wide-spread high-impact
consequences.  In one case I was involved in a small office fire at the
opposite end of the office building destroyed all 70+ computing devices
as well as telephones, copiers, fax machines and other equipment over a
period of 2 to 3 months.  The acids in the smoke damaged the gold leads
in most of the circuitry of the modern equipment and despite an attempt
to clean all these devices at a fairly high cost, every one of them had
to be replaced.  This is not of the scale of a Katrina event, but the
consequences were nearly as severe, just spread out a bit.

 

The root of it all is still that whether you plan for a large scale or
smaller scale event, your resources will only be responsibly applied
when your objectives and requirements are well defined.  Most of us
never get that part done well and thus our plans suffer no matter what
scale we focus on.  It is possible to expend too much energy on recovery
of systems that are not that important and critical to the institution,
and this happens often because we don't have good criticality direction
- rather we try to be good citizens and support it all equally.
Criticality is key to either large scale or small scale events. Only a
few of us carry the signature authority and granted responsibility for
that level of decision making, yet we tend to operate our recovery
analysis and plans far below that organizational level.

 

Don't mistake me as saying lower levels of the organization are not
involved, or IT shouldn't be active in the process.  These groups must
be involved, but in league with and in support of strategic decision
making, as "disaster" events are rare, highly impacting by definition.
Strategic input is far too rare, and in my observation most plans go
overboard on less important systems and the most critical do not get the
degree of support/testing/assurance they require.

 

Best regards,

 

Jim

 

*****************************************

Jim Dillon, CISA, CISSP

IT Audit Manager, CU Internal Audit

jim.dillon () cusys edu

303-492-9734

*****************************************

 

 

________________________________

From: Lovaas,Steven R [mailto:Steven.Lovaas () COLOSTATE EDU] 
Sent: Wednesday, January 10, 2007 11:31 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Business Continuity Plans for an Information
Security Office

 

Good discussions so far on this.

 

A useful approach is to look at continuity planning not from the
perspective of individual disasters or occurences, but to analyze which
processes/pieces of your organization are critical.

 

So, rather than imagining what would happen if a tornado hit your server
room, consider which applications are mission-critical and categorize
them in terms of how long they can be down and have business still
function. Once you have a grid of criticality and
downtime-survivability, then you can plan for outages no matter what
causes them.

 

Steve

 

==============================================
Steven Lovaas, MSIA, CISSP
Network Security Manager
Academic Computing & Network Services
Colorado State University
970-297-3707
Steven.Lovaas () ColoState EDU
============================================ 

 

 

________________________________

From: James Moore [mailto:jhmiso () RIT EDU] 
Sent: Wednesday, January 10, 2007 10:56 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Business Continuity Plans for an Information
Security Office

Brad raises a good issue that is part of the bigger picture of BCP for a
university, at least our university.  

 

We have a lot of small groups.  We are more like a city.  Sometimes, key
people have no backup.  It seems that we live with a lot of aggregate
risk coming from the wide range of functions supported.  My guess is
that most of the time, there has been some conscious or unconscious
decision to allow significant impact to segments of business function,
as opposed to moderate impact to general business functions (i.e.
benefits of specialization are high, all specializations will not be
lost simultaneously = most customers happy, most of the time).  This of
course means that processes and infrastructure must be analyzed
carefully for single points of failure.

 

But, musings aside, Brad, thank you for your analysis.  I am definitely
using it.

 

Thanks,

 

Jim

 

________________________________

From: Brad Judy [mailto:Brad.Judy () COLORADO EDU] 
Sent: Wednesday, January 10, 2007 11:49 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Business Continuity Plans for an Information
Security Office

 

I want to toss in a reminder here that while it is important to plan for
possible larger scale events, it is also important to plan for the more
common small scale events.  Too often in IT and higher ed (particularly
after Katrina et al), large scale plans are developed and plans for
smaller scale common events are not.  

 

The reality for most IT security offices (and many groups in general) is
that the most likely business continuity scenario is the abrupt loss of
a key staff member (via job departure, illness, lottery winnings, etc).
Most security offices are small groups and the loss of a single staff
member might amount to an immediate 50% loss in capabilities of the
group.  

 

Naturally, security offices are also at least partially reliant on
technology assets, so the loss of assets should be addressed as well.  

 

With some good attention on BCP right now, I'd hate to see focus only on
the large scale events and have folks fail to document procedures or
policy for smaller scale events.  I'm putting together a list of basic
common scenarios that I think every IT group on our campus should have a
plan to address in addition to their large scale event plans.  

 

Brad Judy

 

IT Security Office

Information Technology Services

University of Colorado at Boulder

 

________________________________

From: James Moore [mailto:jhmiso () RIT EDU] 
Sent: Tuesday, January 09, 2007 3:44 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Business Continuity Plans for an Information
Security Office

I admit that my own business continuity plans were on my "to do" list
for longer than I would like.    Does anyone have or know of a template
that I can start with for business continuity planning of the
Information Security Office.

 

The easy thing is to say that we have to do the same things that we
always do, but differently.

 

Risk Assessment - Only a subset of functionality will come back on line.
Some will have been reviewed for risk, and others not.  There will have
to be some dynamic risk assessment.

 

Communications - The natural thing to do is to relax security in the
different environment so that as much functionality as possible can be
achieved.  Users find allies, etc.  Communications will need to
integrate with Business Continuity communications, but still will have a
role to guide people to safe business resumption.  Communications to
executive leadership is also regular, but concentrates on service
restoration.

 

Budgets / Administrative - Need to continue, as resources are available.

 

Strategic - May be for rebuilding.  Or may shift to standards
enforcement for existing standards.

 

Investigations / Forensics - Needed for when things go wrong, and are
noticed

 

This is a high level.  And what I wondered is if anyone had a detailed
business continuity plan for their office/role.

 

Thanks

 

Jim

- - - -
Jim Moore, CISSP, IAM
Information Security Officer
Rochester Institute of Technology
13 Lomb Memorial Drive
Rochester, NY 14623-5603
(585) 475-5406 (office)
(585) 475-4122 (lab)
(585) 475-7950 (fax)

"We will have a chance when we are as efficient at communicating
information security best practices, as hackers and criminals are at
sharing attack information"  - Peter Presidio