Implementing Vulnerability Management

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.

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=1331
582450&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
 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
 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

Implementing Vulnerability Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Implementing Vulnerability Management

Similar to Implementing Vulnerability Management (20)

More from Argyle Executive Forum

More from Argyle Executive Forum (20)

Recently uploaded

Recently uploaded (20)

Implementing Vulnerability Management