Implementing Vulnerability Management

Derek Milroy

2

Vulnerability Management Functions Continuous Process Of:

– Discovery of Missing Patches/Governance for Patch Management.

– Discovering Misconfigured Systems/Governance for Configuration Management.

– Discovering Vulnerabilities in Applications/Services. – Prioritizing the remediation of Vulnerabilities

discovered throughout the environment. – Discovery of Rogue devices/Governance for Change

Management. – Verification of agent based technology deployments. – Compliance Reporting for all the above. – Assist with IOC hunting? (OVAL checks etc.)

3

Vulnerability Management Cycle

Scanning

Remediation

Reporting

This is a continuous process

4

Information to Gather Pre-Implementation

Awareness of the following: – Products and Operating Systems in your environment

(Network discovery will give you a real inventory to compare to what you thought you had.) Phone Systems (non-VOIP) Shop Floor Control Systems SCADA

– How your network is segmented – Regulatory Requirements – Standards Requirements (PCI)

5

Beginning Scanning Take a baseline

– Don’t panic on the first set of results – High Medium Low – Low usually addressed via hardening – Keep the baseline scan options simple – don’t crash systems

The baseline will be important to determine deployment phases.

Baseline as much of your enterprise as possible, especially server and Internet facing segments

VM Solutions: QualysGuard, Foundscan, nCircle, Tenable, Rapid 7, eEye, Harris Stat, LANGuard, Nessus, SNSI, etc.

Change Controls for First Scans

Be careful of using aggressive scanning first off.

6

Do the Math If you need to scan 1000 workstations (knowing that

workstation scans need to take place during normal business hours) and it takes an average of 10 minutes per workstation, the scan time would be approximately 167 hours of scan time (threading would decrease this).

Testing is needed in your specific environment to

determine true scan times and impact of scanning traffic.

Run Wireshark on some hosts, especially workstations. You will then get an idea for the traffic a full, authenticated scan, generates.

7

Root Cause Analysis 1st Step: Gather inputs from the issue.

– Gather Host/Application information application name version patch level port usage information

– Was the application disrupted, a system service, or the entire operating system?

– What had to be done to recover from the outage? Service restart or host reboot?

2nd Step: Verify that the issue was caused by the scan. – Hopefully the product you are using documents each host’s scan time. – If issue with a specific port than still scan “rest” of host(s)

3rd Step: Place a support call with the application vendor or development team.

– Verify that the environment is supportable. – Verify that all patches have been applied to the application for "Denial of

Service" and "Buffer Overflow" problems. 4th Step: If the issue is not resolved by the application vendor, engage

Support from your scanning vendor.

8

Scan Logistics Scan by segments. Time of Scans is Important:

– Servers within datacenters are typically scanned off-hours. If scans are performed during Administrator’s maintenance windows,

systems may be missed due to reboots from patching etc. – Workstation segments are typically scanned during the day so most

systems are active. – Remote sites, even though they typically have Domain Controllers

and File/Print servers, are typically scanned during the day in order to catch all the workstations.

Scans for Internet facing Systems are different than Internal scans: – Trusted vs. un-trusted – Amount of ports – Brute Forcing

9

Scanning Frequencies Server/Datacenter Segments

– Weekly

Internet Facing Systems: – Monthly at a minimum – Work to make them weekly

Workstations:

– Monthly, Twice a Month, or Weekly - depending on the size of the environment

Reference: QualysGuard Best Practices Presentation version 1, (which I authored).

More Thoughts on Scanning Range based vs. inventory based… lost the

binary thinking for remote sites if budget challenged…

Wireless Segments? Without continuous scanning, detection of

rogues is spotty at best.

10

11

Remediation

Could be:

– Hardening – Patching – Architecture Changes – Technology /Tool Implementations

12

Making Scan Results Actionable Use separate ticketing system provided by Vulnerability Management

Solution?

Integrate Vulnerability Management Solution with your existing help desk solution?

Manually enter Tickets into your Enterprise Solution?

Don’t worry, information picked up by scans can be found by almost anyone.

– Internet Data Freely Accessible – Insiders are a concern for a reason

Artifact Alert: You need to maintain reports on remediation performed

to prove that action is being taken as a result of your vulnerability management program

13

Using in-product Ticketing Systems

When tickets are created for vulnerabilities determined to be false positives, can be moved to a Hold Queue until the detection is fixed by the vulnerability management platform vendor.

The hold queue can also used to store tickets that are in the process of having exceptions (risk sign-off) granted.

The ticketing system within “Insert-Product-Here” may not, distinguish between vulnerabilities that must be addressed via patches vs. vulnerabilities that must be addressed via configuration changes.

– You may need to account for this via explanations in your scorecards/reports etc. if this is the case.

Do not generate tickets for Zero day exploits that have no patch and/or

workaround. This means items that have been ticketed are actionable, as opposed to aggregate vulnerability data.

CVSS vs. Metasploit based Prioritization?

CVSS – Base, Temporal, – http://www.first.org/cvss

Is it available in Metasploit, Core Impact, or Canvas, or common exploit kits?

Is this tracked within your solution?

14

15

Which Host is More Vulnerable?

Host A has Three Remotely Exploitable Vulnerabilities – Canned Exploit Available for None of the

Three Vulnerabilities

Host B has One Remotely Exploitable Vulnerability – Exploit available in Metasploit

16

How About Now?

Host A has Three Remotely Exploitable Vulnerabilities – Canned Exploit Available for None of the

Three Vulnerabilities

Host B is fully patched and hardened. – But it has a Blank Administrator Password!!!

Prioritizing based on Location and/or Data Criticality

Where’s the critical Data? – Um, you mean besides in .xls on every end

point? – How about on the systems you’re never

allowed to patch? Internet facing – still low hanging fruit Data Centers – still a large amount of data

concentrated there Workstations – APT – M$ back in 2000

– They are often inside of perimeter defenses…

17

18

Data Must be Actionable

Specific .xls extracts may be needed to focus remediation efforts.

Do not provide extraneous data. Focus not only on what should be fixed, but what can be fixed. It is not always feasible to address everything all at once. Work with the teams responsible for remediation as you determine targets etc. (Critical vulnerabilities vs. Moderate – Hardening related items vs. patch related.

19

Tuning Results No matter what solution you pick, scans or reports will

need to be tuned. It is important to make sure you remediate critical items. It is equally important that you do not ticket/report on too many items.

– Start with ticketing remotely exploitable vulnerabilities that can be fixed

by applying missing patches and critical configuration items like: anonymous FPSE extension access, anonymous world writeable ftp directories, etc.

– Do not send out reports that have thousands of vulnerabilities that have no fixes i.e. Zero day M$ Vulnerabilities awaiting patches.

– Tune out vulnerabilities with non-running kernels ?

– After everyone is comfortable with the remediation process, you can focus on the less critical items. Items contained in most scanners “low priority vulnerability” section can typically be addressed via hardening. It is not practical to think that you will be able to fix everything a scanner is capable of finding. As with all security endeavors, vulnerability management is about risk management, tradeoffs etc.

20

Metrics

Drive Behaviors

Track Progress / Show Work Done

21

Metrics Worst to Use?:

– Average Vulnerabilities per Host – Typically, this is the first metric to be broadcast. This metric does

not necessarily accurately depict risk (more slides on this in a minute)

– Even though there are issues with this metric, it may still be used if tracked over time to show remediation progress, not to show risk.

Not Much Better

– Vulnerabilities by Platform…Unless Split by Operational Regions

Best – Overall Vulnerability Status – Believe it or not, a stoplight report works well for Aggregate

Vulnerability Reporting

22

Scorecard Concepts Scorecards are intentionally kept at an aggregate level.

Detailed reporting can lead to a scenario where by the time

the reports are out, people could have performed remediation.

Scorecards are a high level status, not a means to make vulnerability data actionable.

If your solution is properly operationalized, the actionable data is in the hands of the personnel that will perform the remediation's long before the scorecard is generated…

23

The New Green? Due to patch release cycles, it is nearly impossible to keep up with all

patches for all products etc. Especially in larger environments. – Vulnerability vs. patch reporting?

Maybe report on patch deployment via a patch management tool? Or have the team performing the remediation's (mainly patching?) generate a

report that filters out vulnerabilities related to patches not in the current deployment cycle?

Involvement by platform teams in reporting is a further way to operationalize your vulnerability management program.

– Risk register vs. vulnerability management reporting? Teams performing remediation need attainable targets. Maybe show

green for OS patching that shows the deployment of critical security updates is occurring within 30 days.

– Maybe split out third party applications and items like Java? – Maybe make a focused effort for something like Adobe and report on it

separate from OS and core service (web, ftp, etc.) security patching?

24

Patch Reporting Remove Zero days, there’s no patch for them…

Focus on the recent set of patches that are due and older security

patches separately?

Always subject to the cat and mouse game, especially for M$. – Almost every month, patches are released for Microsoft. Each month, servers are

scanned. This means that there will always be X number of vulnerabilities (in this case patches) showing up on reports (in an integrated ticketing system, this would make there always be overdue tickets). If you have 1000 servers and Microsoft releases an average of two critical vulnerabilities each month , all vulnerability (and patch) reports would show at least 2000 critical vulnerabilities - even if you are patching each month. Put another way, due to the frequency of patch releases, it is extremely unlikely to ever reach a steady state of zero vulnerabilities.

Special Purpose Reports

For follow-up scans For analysis of new technologies

25

Simpler Scorecard?

Critical Vulnerabilities

<1 Month 2-3 Months > 3 Months <1 Month 2-3 Months > 3 Months

Windows 5 5 12 6 4 12

Network 3 3 15 3 2 14

26

Slice by team, platform, etc. Show number of systems Show increases vs. decreases

July August

Maybe another slide with a stacked bar chart showing trending for a few Months…

27

Adding Context to Reports Sample Statements: The overall vulnerability counts reflect configuration

issues as well as vulnerabilities that must be fixed by patching.

The overall vulnerability counts reflect Zero-Day exploits, for which there are no patches. They are reported on the scorecard as they represent a risk to the environment.

There will always be two to three Critical Vulnerabilities per host due to the amount of patches released each month from Microsoft and the frequency of scanning i.e. scans will run and report vulnerabilities associated with patches that are still being tested. Do NOT send a slide with just numbers. Even if you are

present to explain things, it may get forwarded on…

28

Using Canned Reports – In the realm of Vulnerability Management, it is impossible

to generate a report with numbers only that will have true meaning. It will always be advisable and necessary to add analyst comments to reports before sending them out.

– People in various Business Units/Lines of Business have software tools that generate numbers to assist in making recommendations. I doubt analysts in the Business Units blindly obey the numbers their software programs generate. IT is no different. Specifically, all Vulnerability Management reports should be reviewed by a qualified analyst and context added prior to distributing reports.

– Remember what you are trying to tell via the report. Providing graphs and numbers just to do so can lead to misunderstandings of what and how your vulnerability management program is doing.

29

Maintenance No matter which product you implement,

maintenance will be required to maintain accuracy of scanning and reporting. – Purging data on hosts that have been de-commissioned

or when a different OS lives at an IP. Commission and de-commission processes (Remedy?)

– Whoever runs the tool must be in the loop for all VLAN additions and removals. Commission and de-commission processes (Remedy?)

– If the product’s checks do not auto-update this will need to be done regularly, as often as possible.

– Reporting and scanning “group” maintenance

30

CMM Defined http://en.wikipedia.org/wiki/Capability_Maturity_Model

There are five levels defined along the continuum of the CMM and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief".

– Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a

new or undocumented repeat process. – Repeatable - the process is at least documented sufficiently such that

repeating the same steps may be attempted. – Defined - the process is defined/confirmed as a standard business process,

and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). – Managed - the process is quantitatively managed in accordance with

agreed-upon metrics. – Optimizing - process management includes deliberate process

optimization/improvement.

31

Sample CMM

CMM 1 CMM 2 CMM 3 CMM 4 CMM 5

No solution documentation Scans sporadic

based on individual requests Canned reports or

very little customization No trend reporting No report archival Trusted scanning

not used for Internal Scans Scan ranges not

validated No integration with

other tools

Very little documentation Scans scheduled

regularly but not automated Minor

customizations to canned reports Trend reporting, no

context added No report archival Trusted scans

used internally but authentication not validated in all cases Excessive

exceptions in scan ranges No integration with

other tools

First revision of documentation set in place Scans scheduled

and notified when they do not run Reports

customized Trend reporting,

with context/analysis, in place Report archival in

place Trusted scans in

place Exception

validation beginning Integrated with

IDPS and ELM tools

Documentation actively maintained Scans scheduled

and notified when they do not run Reports

customized Trend reporting,

with context/analysis, in place Report archival in

place Trusted scans in

place Exception

validation complete and a process in place for exceptions Integrated with

GRC tools

Perfection Attained Capitalizing on

new features when they are released Automating

discovery of rogue servers, Internal and External

32

Process Documentation Scan Profiles – The scan profiles used for scanning will be thoroughly documented. Naming Conventions – Naming conventions for Users, Groups, Appliances, Reports, etc. will be

documented. Device Group Maintenance – Process and procedures for maintaining groups used for scanning and

groups used for reporting. Product Maintenance – Product update procedures. Scanner restarts. System/Application Outages – Process for investigating when it appears that scanning activity caused

a disruption in service for a system or application. Auth Verification – Process for investigating and resolving UNIX, Windows, Network Device, etc.

authentication failures associated with scans. Report Generation – Process for scorecard reporting. Procedures for generating reports used to

analyze/prioritize remediation efforts. Scan Process – Document Groups scanned and the frequencies they are scanned. Exceptions – Document process for scanning and reporting exceptions. Document the reasons for all

scanning exceptions. Purging – Document procedures and frequencies for purging data. Architecture – A document that shows the locations of the scanner devices and the ports needed for

the scanner appliances to communicate with the central console. Documentation should also be gathered on all firewalls that have rules that allow for scanning activities.

Inventory – This could be a spreadsheet that will list all devices, their physical and network locations, and support/maintenance information.

Tracking Feature Requests / Product Issues / Support tickets – This could be a spreadsheet with three tabs. Bi-Monthly or Quarterly meetings should be scheduled with a “insert vendor name here” resource to review all open requests.

Roles and Responsibilities – Identify personnel that will have access to the product and document roles used to grant access. A periodic account validation procedure may also need to be included in this document.

Note: Standardized, repeatable, and actively maintained processes and procedures require a certain amount of documentation to ensure consistency across humans.

33

Security Tools

Install vs. Implementation Install a Product

– No real plan – Wing it, never read the manual – Reactive

Implement a Solution – Planning – Read the manual, do further research etc. – CMM, Structure, documentation – Policy, process, procedure, i.e. the boring stuff

34

35

Source Vulnerability Management !?!

Should be at CMM3 1st

Still need context specific to your environment.

What do you really get? – Onshore vs. offshore

Security Incident Response Process

Derek Milroy – CISSP, CISA derek d0t milroy at g mail

@dpmilroy

What is a Security Incident? An assessed event of attempted access, unauthorized access, or an

information attack on an automated information system. It can include, but is not limited to, unauthorized probing and browsing; disruption or denial of service; altered or destroyed input, processing, storage, or output of information; use of rogue devices – Example: rogue wireless devices, or changes to information system

hardware, firmware, or software characteristics with or without the users' knowledge, instruction, or intent.

– Includes items such as virus and malware outbreaks

Remember “DUI” – Destruction of information – Unauthorized - access, use, disclosure, modification – Interference with system operations in an information system

37

How is it Different Than a Privacy Incident?

A Privacy or Data Security Event occurs when there are facts that point to the possibility of an unauthorized or inappropriate collection, use, access, disclosure, modification and/or exposure of Company Information that is not Publicly Available Information

Events that have been confirmed as actual breaches of Company Information are referred to as Privacy Incidents

Examples – Lost of Stolen Equipment with Company Information – Confidential personal information being leaked (e.g. SSN#)

38

Incident Classification

Event Severity Level Event Characteristics

5 SEVERE

o Successful penetration or denial-of-service attack(s) detected with significant impact on agency operations:

o Very successful, difficult to control or counteract o Large number of systems compromised o Significant loss of data o Loss of mission-critical systems or applications o Significant risk of negative financial or loss of public

confidence

4 HIGH

o Penetration or denial-of-service attack (s) detected with limited impact on agency operations:

o Minimally successful, easy to control or counteract o Small number of systems compromised o Little or no loss of data o No loss of mission-critical systems or applications o Widespread instances of a new computer virus or worm that

cannot be handled by deployed anti-virus software o Small risk of negative financial or loss of public confidence

• Incident Response Process is Triggered based on Incident Classification

39

Incident Classification

3 ELEVATED

o Significant level of network probes, scans and similar activities detected, indicating a pattern of concentrated reconnaissance:

o Penetration or denial of service attack(s) attempted with no impact to agency operations

o Widespread instances of a known computer virus or worm, easily handled by deployed anti-virus software

o Isolated instances of a new computer virus or worm that cannot be handled by deployed anti-virus software

2 GUARDED

o Small numbers of system probes, scans, and similar activities detected on external systems

o Intelligence received concerning threats to which agency systems may be vulnerable

1 LOW (Normal)

o Small numbers of system probes, scans, and similar activities detected on internal systems

o Isolated instances of known computer viruses or worms, easily handled by deployed anti-virus software

40

Types of Incidents Of the three categories below, typically the top category will have a

separate process due to the nature of Human Resources driven investigations and the need for greater confidentiality.

Human Resources Related Incidents – Inappropriate web usage. These types of incidents are typically investigated

by the team managing the web content filtering solution. – Inappropriate use of Company data. – Intentional Data Leakage.

Confidential Leakage Incidents

– Inadvertent data leakage can be handled by the team managing the DLP solution? Could be the security team or violations may be queued for review by managers.

– Theft of company data. – Sometimes a physical issue, print outs, backup tapes, etc.

Attack Related Incidents

– When a person or team is trying to compromise systems to steal data or disrupt services.

– Malware related falls here …

41

Incident Response (IR) Process

The following steps will be performed when a security incident is reported and an incident handler from the Incident Management team has been assigned. – Preparation – Identification – Containment – Eradication – Recovery – Follow-up / Lessons Learned

Incident response teams are composed of BU A and BU B resources as deemed appropriate to the incident.

Team members must respond to and resolve all incidents reported by the Incident Management team.

Incident Response Process is Triggered based on Incident Classification

42

How is an Incident Communicated?

During a Security Incident Response communication will be handled by a Gold and Silver Team Gold Team

– The gold team consists of leaders in the organization deemed critical to the Security Incident Response.

– A Management bridge will be convened for use by leaders for status updates and to address findings that result in the need for leadership decisions to be made or coordinated with business partners.

– The management bridge will be opened, as determined necessary, by its participants.

Silver Team – The Silver team will be comprised of individual from teams that support affected platforms as

well as other subject matter experts (SMEs) that may be brought in as needed – A technical bridge will be open for technical resources that are actively working on the

investigation

The Silver team must have at least two personnel assigned, in order to adhere to security best practices.

43

Roles and Responsibilities Gold Team

– Determine if a security incident is severe enough to engage non-U.S. Cellular resources for assistance – Provide direction as to the use of emergency change controls etc. – Provide risk and business context to the proposed solutions from Silver Team – Provide approval for any changes that may have business impacts

Silver Team – Provide technical direction to resolve incident – Provide Incident Coordination – Ensure that the incident report is filled out in detail – Ensuring Silver Team conference bridges have been established – House centralized copies of Incident Response forms and procedures – Gather evidence needed in a forensically sound fashion – Ensure chain of custody is established and maintained for any evidence gathered – Work with 3rd-Party resources as needed as part of response

ACME Incident Management – Ensuring Gold Team conference bridges have been established – Facilitate status calls – Maintain communication and escalation points of contact – Determine and notify appropriate Gold Team members for each incident

44

After Action Review It is important to fully document lessons learned and make

items from that list actionable where appropriate. – Lessons learned can highlight issues that need to be

added to user awareness training.

– Lessons learned may also highlight needed policies, policy changes, and Security Incident Response tool and process enhancements that are needed.

– Lessons learned are also about evaluating the environment’s countermeasures or lack thereof.

45

SAMPLE IR Forms All forms are consolidated into one spreadsheet (attached below).

46

47

Cheat Sheets

SANS

http://zeltser.com/cheat-sheets/ http://packetlife.net/library/cheat-sheets/

48

Maintaining Awareness

Mailing lists – if you must – NOTE: SANS portal account etc. still highly useful/relevant

RSS Feeds – OK

Twitter – HAS REPLACED ALL ELSE

49

Maintaining Awareness of Threats Old Way?

SANS @ RISK The Consensus Security Vulnerability Alert (http://www.sans.org/newsletters/risk/)

Focus-MS (http://www.securityfocus.com/archive)

Full Disclosure (https://lists.netsys.com/mailman/listinfo) Microsoft Security Bulletins (http://www.microsoft.com/security)

NTBGTRAQ (http://www.ntbugtraq.com/)

Pen Test (http://www.securityfocus.com/archive)

Secuina (http://secunia.com/)

SF-MS-News (http://www.security-focus.com/newsletters)

SF-News (http://www.security-focus.com/newsletters)

Vulnwatch / Vulndiscuss (http://www.vulnwatch.org/subscribe.html) (When posting to lists use an anonymous address. Don’t use an out of office

assistant on the account used for reading messages.)

http://www.securitywizardry.com/radar.htm

50

RSS Sample

I have a file that can be imported into Firefox and Internet Exploder, not tested with Chrome yet. https://sites.google.com/site/dpmilroy/staying-informed

Twitter Observations on Twitter:

I catch news etc. on Twitter often before on the RSS feeds. I will paste in a

sample below that I saw a while back. Media handling policies for organizations potentially needed an update the day this was posted.

On whatever phone/tablet I am using, I set the app to pull vs. push so I look through updates when I want to. Clicking to the web pages/blogs the tweets reference also seems to work well on all devices.

For the desktop I use the WEB BASED TweetDeck. I know a few people with Mac’s and they use TweetDeck to. Tweet deck is fully configurable and you can make it so the tweets are not a distraction.

DO NOT LOCK YOUR ACCOUNT – it defeats the entire purpose – do be sure to comb through all the options, it takes less than 10 minutes.

51

Start Here: (Chicago Biased)

52

BurbSecNorth @BurbSecNorth ENISA @enisa_eu BurbSecWest @BurbSecWest Chicagoland Security @chicurity

BSidesChicago @BSidesChicago

ISACAChicago @ISACAChicago ISSA International @ISSAINTL Visa Security @VisaSecurity

Microsoft MMPC @msftmmpc Microsoft Security Verified account @msftsecurity

OWASP Chicago @OWASPChicago

BurbSec @BurbSec

ISSA Chicago Chapter @issa_chicago

TWC Breaking Verified account @TWCBreaking

Microsoft Privacy @MSFTPrivacy

HTCIA @HTCIA

BBC News US Verified account @BBCNewsUS

Chisec @ChiSec THOTCON! @thotcon IRISS @irisscert

NIST Verified account @usnistgov

ISACA International Verified account @ISACANews

SANS ISC Fast @sans_isc_fast Infosecurity @InfosecurityMag

Hack In The Box @hackinthebox

(ISC)2 @ISC2 Shadowserver @Shadowserver

CSOonline @CSOonline

briankrebs @briankrebs SANS Institute @SANSInstitute PCI SSC @PCISSC OSVDB @OSVDB

FIRST.Org @FIRSTdotOrg US-CERT @USCERT_gov packet storm @packet_storm SCMagazine @SCMagazine

Randy Franklin Smith @randyfsmith

Cisco Security Verified account @CiscoSecurity

owasp Verified account @owasp

keydet89 @keydet89

USA TODAY Verified account @USATODAY

Johnny Kelly @stormchaser4850

Reuters Business Verified account @ReutersBiz

CBS Chicago Verified account @cbschicago

NBC Chicago Verified account @nbcchicago

WGN TV News Verified account @WGNNews

Branden Williams @BrandenWilliams

SANS ISC @sans_isc

Breaking News Verified account @BreakingNews

BBC Breaking News Verified account @BBCBreaking

NPR News Verified account @nprnews

Wall Street Journal Verified account @WSJ

CNET News Verified account @CNETNews

BBC News (World) Verified account @BBCWorld

BBC Technology @BBCTech CNN Breaking News Verified account @cnnbrk

EFF Verified account @EFF

53

Golden Rule of First Responders

54

Process References/Resources

Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps – http://www.amazon.com/Visible-Ops-Security-Operations-

Objectives/dp/0975568620

ITILv3 Foundations – Book - http://www.amazon.com/Foundations-IT-Service-

Management-Course/dp/1463635346/ref=sr_1_3?s=books&ie=UTF8&qid=1331582450&sr=1-3 – Have not read, took a course myself.

References Incident Response – Investigating Computer Crime - Kevin Mandia, Chris Prosise (ISBN:

0072131829)

Real Digital Forensics – Keith J. Jones, Richard Bejtlich, and Curtis W. Rose (ISBN: 0321240699)

Detecting and Removing Trojans and Malicious Code from Win2k - H. Carvey September 18, 2002 http://online.securityfocus.com/infocus/1627

Win2K First Responder's Guide - H. Carvey September 5, 2002 http://online.securityfocus.com/infocus/1624

Windows XP Professional Security - Chris Weber and Gary Bahadur (ISBN: 0072226021)

Anti-Hacker Toolkit – Keith J. Jones, Mike Sherma, & Bradley C. Johnson (ISBN: 0072222824)

Windows Forensics: A Case Study, Part One -Stephen Barish http://online.securityfocus.com/infocus/1653

NIST Special Publication 800-61 Revision 2 – Computer Security Incident Handling Guide

SANS Incident Handling Forms: http://www.sans.org/incidentforms/

SANS Computer Security Incident Handling Step-by-Step

SANS Course SEC504: Hacker Techniques, Exploits & Incident Handling

55

56

QA

Questions? If you have any questions you think of later

send an e-mail to: – derek d0t milroy at g_mail

Best effort for answers, usually within a week or so.

Thank You

Derek Milroy derek d0t milroy at g_mail

@dpmilroy https://sites.google.com/site/dpmilroy