11/8/2012

1

1

The Ohio State University

Steve Romig, Associate Director ‐ Security Operations

November, 2012

1

11/8/2012

2

2

Introduction

11/8/2012

3

3

Game Plan Brief Introduction

A breach?  Us?

Lessons learned from past breaches and near‐misses

Parting thoughts

11/8/2012

4

4

OSU Background Large: 63,000 students, 32,000 FTE, 14 Colleges, 174 Undergraduate Majors, 12,000 courses

Highly Distributed: 100 IT groups, 30 CIOs, 7+ campuses, 891 buildings

Complicated: teaching, research, business affiliates, teaching hospital...subject to HIPAA, FERPA, PCI, FISMA, GLB, etc. etc.

Diverse: you name the technology, we probably have it.  Many OS platforms, software packages, versions, network gear, security gear, etc.  4,000+ web servers, 100+ email systems. Multiple active directory domains and other authentication sources.  Desire2Learn, PeopleSoft, and lots of home‐grown applications.

11/8/2012

5

5

A little about me I am Associate Director of Security Operations for the Enterprise Security group in the Office of the CIO.  My team is responsible for intrusion detection, incident response, logging and monitoring, some firewall support, vulnerability scanning, and various other consulting/investigation work as needed.

I report to Julie Talbot‐Hubbard, our CISO (who also leads our Infrastructure team).  She reports to Kathy Starkoff, CIO and also has a “dotted” reporting line to our Chief Compliance Officer, Gates Garrity‐Rokous.

I’ve been at OSU nearly 30 years.  12 years as a sysadmin/facilities manager, 18 in IT security.  I have had a lot of experience with incident response and forensic computer investigations.

11/8/2012

6

6

A Breach?  Us?

11/8/2012

7

7

A Breach?  Us? Prevention is proactive.  

“Some intruders are smarter than you...intruders are unpredictable...prevention eventually fails” ‐ Richard Bejtlich, The Tao of Network Security Monitoring (and in his blog).

Many have pointed out that the bad guys only need to get it right once, whereas the defenders need to get it right every time.

If you extend that to detection, it isn’t that we’re looking for a needle in a haystack, its that we are looking for an unknown number of needles in multiple haystacks.  If you miss even one...you’ve got a potential breach.

I really like the Verizon Data Breach Investigations Reports ‐ they have good perspective.

11/8/2012

8

8

2012 Verizon Data Breach Investigations Report

11/8/2012

9

9

A Breach?  Us? We deploy a lot of technology to detect/prevent “badness”.  The bad guys know that we do this and actively seek ways to evade detection/prevention. 

Most times there are plenty of indications that something bad has happened.  We don’t always detect the compromise because we are looking for needles in haystacks or because we wrongly think that our preventive controls are effective.

For example: people who think that anti‐malware “protected you” when it “blocks” something bad.

Verizon suggests that instead of looking for needles we should (also) be looking for haystacks.

Example: OSU SQL injection breach several years ago, 14,000 employee records exposed.  This was detected because the web server logs had abruptly increased in size.

11/8/2012

10

10

A Breach? Us?

11/8/2012

11

11

Lessons Learned

11/8/2012

12

12

Lessons Learned Right Urgency/Speed

Regulations and internal procedures impose timelines but haste is the enemy of thorough and correct investigations.  There’s a balance between quick and correct results.

People up and down the stack need to give investigators room to investigate.

Investigations are fluid: questions drive data collection and analysis, which leads to further questions, more data collection, more analysis...

Right Escalation

Mistake #1: failing to escalate an incident to a higher level to “facilitate” cooperation.

Mistake #2: escalating an incident to a level higher than it needs to go.  

11/8/2012

13

13

Lessons Learned Right People

For big incidents, you will probably want to involve: legal counsel, communications experts (both internal and external), IT experts, human resources.  OSU also includes data stewards (HR for employee data, the Registrar for student data) and the OSU police.

Most of these people are only involved in our Data Incident Response Team and participate in deliberations about whether data was exposed, whether we need to notify affected parties, and what sort of communication and protection to provide.  

Some people are “bad” in an emergency ‐ avoid including them in the team.

Ensure that people know their roles and responsibilities and have received adequate training on their duties.  Give them a chance to practice with mock exercises.

11/8/2012

14

14

Lessons Learned Right People

Who should conduct your investigation?  Should you engage external experts?

We’ve done both: we investigate everything using an internal team.  On several occasions we have also engaged external consultants to review the findings of our internal investigations and validate them.  

Forensic computer investigations are hard ‐ they require specialized software, skills and knowledge.  Investigators need practice to hone and maintain their skills.  Do you conduct enough investigations to make it worth your while to have dedicated investigators?

11/8/2012

15

15

Lessons Learned Right Plan

Do you have an incident response plan?  A documented, up‐to‐date plan?  That has been tested?

Do people understand their roles and responsibilities (RACI)?

Do your employees (and contractors, business partners and 3rd party providers...) understand what constitutes a data breach for your enterprise, and who to report it to?

Do first responders know how to avoid destroying evidence?

11/8/2012

16

16

Lessons Learned Right Communication

Ensure that people understand that they should not over‐communicate.  You don’t want to squelch necessary communication, but this should be “need to know” rather than being the subject of water cooler conversations.  

Ensure that people understand who has the authority to talk to the press, to communicate with affected parties, to approve official communication, and when communication plans and decisions will be made and by whom.

Beware e‐discovery!  Attorney‐client privilege won’t always protect your internal communication.

11/8/2012

17

17

Lessons Learned Right Data

Do you have a secure, central log repository and tools to effectively search it as part of incident investigations?

“Secure” as in “unlikely to be subverted by the bad guys”.  Perhaps they can inject false data after they’ve subverted a log source, or prevent a system from sending logs, but they shouldn’t be able to remove past log entries.

“Effectively search” as in able to search all of your data from a single place.

I advocate longer retention periods than many might like.  There are privacy and e‐discovery issues, but when you consider that the time between compromise and discovery can be measured in months (or years!)... 

11/8/2012

18

18

Lessons Learned Right Data

Do you have the right kinds of data?

Server, anti‐malware, intrusion detection, firewall, authentication logs, etc. ‐ of course.

Do you have something akin to netflow logs?  What about Bro?  If you aren’t using Bro, you should be.

Do you use NAT?  Are you logging the mapping between your internal IPs and the external ports?  If not, it is practically impossible to correlate logs with external addresses/ports to the correct internal systems.

Do you log failures, successes?  Source addresses?  In all of your applications? 

11/8/2012

19

19

Lessons Learned Detecting versus Hunting

Detection (and prevention) play an important role in our security strategies.

As Bejtlich points out, prevention eventually fails.

We need hunters.  Some intruders are technologically advanced and persistent.  They are actively working to avoid detection.  The only way you will find them is to employ hunters and arm them with what they need to be effective (data, tools).

Make sure you understand the scope of your incident before you take precipitous action.

I hear often of groups that have repeatedly had to fight off intruders because they didn’t correctly understand the full scope of access that the intruders had to their systems.

Granted, you can’t wait forever.  But the risk is that your systems will remain compromised, and the intruders will change their methodology. 

11/8/2012

20

20

Parting Comments

11/8/2012

21

21

Parting Comments Effective intrusion detection/incident response/security monitoring is proactive

Anything you can do to successfully “hunt” intruders is proactive ‐ you’re detecting badness that you wouldn’t have found otherwise (at least not soon).

Anything you can do to reduce the gap between compromise and detection or detection and mitigation is proactive.

In addition to the usual questions (were we compromised, how, when; was data exposed?) you should also be asking how you could have prevented this incident, how you could have detected it earlier, and how you could facilitate mitigation and the investigation process.  This is proactive.

How do you know whether your “hunters” are effective?

11/8/2012

22

22

Parting Comments Why does my investigator qualify everything he says?  Why won’t he give me a plain yes/no answer?

If you ask “was the system compromised” and I’ve found plain evidence that it was, I can confidently answer “yes”.

If I haven’t found evidence that the system was compromised, is that because the system was not compromised, or did the intruders hide their tracks, or did first responders destroy the evidence?

We can often show that there’s no evidence that a system has been compromised, or that data was not exposed.  But honesty compels us to qualify this: as clever as we are in searching for evidence, the alleged intruder may have been more clever still...

11/8/2012

23

23

Resources

11/8/2012

24

24

Resources The Tao of Network Security Monitoring: Beyond Intrusion Detection, Richard Bejtlich, Addison‐Wesley, 2004

Verizon Data Breach Investigations Reports from 2008 on...excellent reading.

11/8/2012

25

25

Questions?