(c) 2007 Charles G. Gray 1

TCOM 5253 / MSIS 4253

Survey of Current Practices

6 September 2007

Charles G. Gray

IT Risk Management,Planning and Mitigation

(c) 2007 Charles G. Gray 2

First there was Og(The Caveman)

• Og’s assets– A home (the cave)– Tools (spears, slings, throwing stones)– Technology (“fire rocks”)– Expertise (how the “fire rocks” work)– Protective clothing (animal skins)– A Co-worker (A trusted friend)

(c) 2007 Charles G. Gray 3

Og Thinks About Hunting• Threats

– Marauding animals– Unfriendly neighbors– “Friends” who cannot be trusted– Thieves (“fire rocks” or animal skins)– An earthquake (might destroy the cave)– A flood – A lightning strike– Others??

(c) 2007 Charles G. Gray 4

Og’s Choices for the Hunt• Leave the cave and “assets” and go

hunting

• Carry everything he owns along on the hunt

• Hide assets both inside and outside of the cave

• Hide assets inside the cave and roll a rock in front of it.

• Hire a guard, and use a BIGGER rock

(c) 2007 Charles G. Gray 5

Og’s Plan• Hide some assets inside the cave

• Disperse some assets outside the cave, but hidden (even from his co-worker)

• Enlist his co-worker’s help– Find a really big (two-man) rock to block the

cave entrance– Stay on guard in Og’s absence

• Pay would include a share of the kill from the hunt

(c) 2007 Charles G. Gray 6

Og’s Descendents of Today• Many follow Og’s first choice

– Leave everything “as–is” and go away• “Plan M” – make it up as you go along

– Limited physical security (only a “small” rock)– Technology unsecured– Many “neighbors” can get into the cave– Thieves can roam at will inside systems– Many “back doors” left unsecured– Don’t account for water lines and flooding

(c) 2007 Charles G. Gray 7

The Result?• Hackers may access the network• Thieves may steal physical assets• Disgruntled employees may plant software

“bombs”• Valuable corporate information may be

compromised– Patents– Trade secrets– Business plans

• An earthquake may destroy the business

(c) 2007 Charles G. Gray 8

Two Possible Approaches• Reactive

– Wait until some “incident” occurs, and then try to deal with it (“Plan M”)

• Always in the “fireman” mode• Always behind the “power curve”

• Proactive– Implement controls in advance to preclude or

limit damage from an “incident”– Reduce the damage due to attack,

exploitation or catastrophe

(c) 2007 Charles G. Gray 9

The Reactive Approach

• Protect human life and safety

• Contain the damage

• Assess the damage

• Determine the cause

• Repair the damage (you hope!)

• Review response actions

(c) 2007 Charles G. Gray 10

Protect Human Life• Always the first priority

• Account for all employees

• Can’t shut off computers controlling life support systems (hospitals, etc.)

• Maintain IT capabilities for medical systems (hospitals, clinics, etc.)

• Evacuate any areas where fire control systems have discharged (Halon, etc.)

(c) 2007 Charles G. Gray 11

Contain the Damage• Protect data, hardware and software

• Decide to shut systems down, or not– Keeping systems up may result in more

damage– A judgment call based on experience

• Actively monitor any intruder’s actions

• Save all server log files

• Physical security (storms, earthquakes, etc.)

(c) 2007 Charles G. Gray 12

Assess the Damage• Duplicate copy hard disks of any servers

that were attacked (for forensic use later)• Determine the extent of the damage

– Implement a contingency plan (hope you have one!)

– Restore normal business operations (if possible)

• Advise applicable law enforcement agencies

• Advise the corporate legal department– Sue, or be sued?

(c) 2007 Charles G. Gray 13

Determine the Cause

• Determine the target of the attack

• Which vulnerabilities were exploited?

• Review system configuration– Patch level, system logs, audit logs/trails

• What other resources might have been affected?

• Make a second disk copy if necessary for more investigation

(c) 2007 Charles G. Gray 14

Repair the Damage• The business continuity plan should

include the restoration strategy• An incident response team should be

activated (hope you don’t have to build one “on the fly”

• Implement contingency procedures to limit further damage

• Mitigate whatever vulnerabilities existed to begin with prior to returning affected systems to service

(c) 2007 Charles G. Gray 15

Document the Incident• Time-annotated diary of

when/where/who/how and “why”, if possible– Detailed record of events– “Time stamps” are important

• “What did they know, and when did they know it?”– The lawyers will want the details

• Copies of all system logs

• Memo of ALL phone calls/contacts

• Record of all personnel on-site or called in– Automated entry/exit log preferred

(c) 2007 Charles G. Gray 16

Review Response Actions• Review all documentation• Prepare a detailed “after action” report

– Summarize for senior management

• Identify successes and mistakes– “Lessons learned”

• Evaluate the effectiveness of the incident response plan

• Look for opportunities for improvement• Iterate the incident-response planning

process

(c) 2007 Charles G. Gray 17

The Proactive Approach

• Develop and implement controls to:– Reduce risk of malicious software– Lock out attackers– Avoid accidental misuse

• Establish policies to mitigate damage– Natural disasters– Human error

• Continue incident response planning

(c) 2007 Charles G. Gray 18

Risk Prioritization• Quantitative RM

– Usually long term, and costly– Calculate objective numeric values– Estimate cost of exposure– Estimate cost of any controls contemplated

• Qualitative RM– Usually faster/cheaper than quantitative RM– Relative, rather than objective values– Results can be vague

(c) 2007 Charles G. Gray 19

Quantitative RM Benefits

• Risks prioritized by financial impact

• Assets prioritized by financial value

• Management of risk by ROI

• Explicit monetary values and probabilities

• Accuracy increases over time (more experience)

• Requires skill and experience on the part of team members

(c) 2007 Charles G. Gray 20

Quantitative RM Drawbacks• Values based on subjective opinions of

participants• Time consuming process to reach

consensus• Complex calculations• Results are in monetary terms only

– Difficult for non-techies to interpret

• Process requires expertise – Not easily coached

(c) 2007 Charles G. Gray 21

Qualitative RM Benefits

• Visibility of risk ranking

• Easier to reach consensus

• Not necessary to quantify threat frequency

• Not necessary to determine financial value of assets

• Easier to involve people who are not experts on security or computers

(c) 2007 Charles G. Gray 22

Qualitative RM Drawbacks

• May not be enough differentiation between important tasks– Everything becomes “first priority”

• Investment difficult to justify in the absence of cost/benefit analysis (CBA)

• Results are dependent on quality of the team– Experience with security issues– Commitment to the process

(c) 2007 Charles G. Gray 23

A Hybrid Approach• Apply selected elements of both

quantitative and qualitative processes

• Qualitative triage of all identified risks– Quantitative analysis to obtain a “short list”

• Proposed solutions presented to the security steering committee

• Process owners implement controls/solutions

• Verify the expected degree of protection

(c) 2007 Charles G. Gray 24

An Ongoing Process

• Start the cycle again

• Hone processes based on experience– Incorporate incident response results

• Frequency based on business needs, not the IT department wishes– Small companies may do it only annually– Large companies may have a large and

dedicated full-time staff

(c) 2007 Charles G. Gray 25

Risk Management must become a “way of life” – not just some book on the shelf