Session 334 Incident Management. Jeff Roth, CISA, CGEIT, CISSP

Transcription

1 Session 334 Incident Management Jeff Roth, CISA, CGEIT, CISSP

2 SPEAKER BIOGRAPHY Jeff Roth, CISA, CGEIT Jeff Roth has over 25 years experience in IT audit, security, risk management and IT Governance experience in public and private sectors. Over this time, Jeff has developed specific focus on certification and accreditation assessment and Information system security engineering for critical infrastructure reviews for high impact federal, state and local governments. This includes specialized security, ethics and fraud investigation support to inside/outside legal counsel, ethics officers, corporate security and the NASA Office of the Inspector General at Johnson, Kennedy, Marshall and Stennis Space Centers. Most recently Jeff has been a contributor to ISACA s COBIT Task Force - COBIT 5 for Security upcoming publication.

3 Session Agenda Incident detection, identification and recording Goals Methods and Techniques Recognized investigative techniques and diagnosis Determine the correct resolution and recovery processes for your environment Establish and evaluate your organizations incident management framework Good References for Incident Management Practices

4 Session Goals How to develop and establish incident detection, identification and recording capabilities Recognized investigative techniques and diagnosis to be used within the incident id management processes Determine resolution and recovery techniques that should be in your incident management toolkit Establishing and evaluating incident management frameworks best for your organization Where to go for further guidance related to incident management

5 Setting the Stage Organizing Oga gan effective ect ecomputer security incident response capability (CSIRC) involves several major decisions and actions. Establishing an organization specific definition of the term incident so that the scope of the term is clear. What services the incident response team should provide Consider which team structures and models can provide those services, and select and implement one or more incident response teams. Incident response plan, policy, and procedure creation

6 Setting the Stage Incident response is needed because attacks frequently compromise personal and business dt data. Citi Critically success factors are: Rapid, effective and efficient response when security breaches occur Systematic response to incidents that provides a consistent incident handling processes repeatable and reliable see you in court Ensuring the appropriate actions are taken as required by organizational, industry and regulatory entities. Benefits include: Minimize loss or theft of information and disruption of services caused by incidents. Use information gained during incident handling to better prepare for handling future incidents and to provide stronger protection for systems and

7 Incident Detection, Identification and Recording

8 Incident Detection, Identification and Recording Definitions 1 An event is any observable occurrence in a system or network. Examples of typical events include: A user connecting to a file share, a server receiving a request for a web page, A user sending , A firewall blocking a connection attempt. Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data. 1 NIST Special Publication , Computer Security Incident Handling Guide

9 Incident Detection, Identification Definitions 1 and Recording A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable tbl use policies, i or standard dsecurity practices. Examples of incidents are: Targeting DDOS A botnet sends high volumes of connection requests to a web server, causing it to crash. PHISHING Users are tricked into opening a quarterly report sent via that is actually malware; running the tool has infected their computers and established connections with an external host. Data Breach An attacker obtains sensitive data and threatens that the details will be released publicly if the organization does not pay a designated sum of money. 1 NIST Special Publication , Computer Security Incident Handling Guide

10 Incident Detection, Identification and Recording Definitions 1 A computer security incident id is a violation i or imminent threat of violation of computer security policies, acceptable usepolicies, or standard security practices. Examples of incidents are: Piracy A user provides illegal copies of software to others through peer to peer file sharing services. Unauthorized access or incorrectly set access privileges to file shares High risk network probing activity detected by IDS/IPS systems Your industry definitions??? 1 NIST Special Publication , Computer Security Incident Handling Guide

11 Incident Detection, Identification and Recording First the CSIR team must have mechanisms and processes in place to detect signs or indicators of an incident. Automated detection capabilities include network based and hostbased IDPSs, antivirus software, and log analyzers. Incidents may also be detected through manual means, such as problems reported by users. End of Day security checks of printers and processing locations Deep, specialized technical knowledge and extensive experience are necessary for proper and efficient analysis of incident related data.

12 Incident Detection, Identification and Recording Signs of an incident fall into one of two categories: A precursor is a sign that an incident may occur in the future. If precursors are detected, your organization may have an opportunity to prevent the incident by enhancing its security posture to prevent an attack. Web server log entries that show the usage of a vulnerability scanner An announcement of a new exploit that targets a vulnerability of the organization s mail server A threat from a group stating that the group will attack the organization. An indicator is a sign that an incident may have occurred or may be occurring now.

13 Incident Detection, Identification and Recording Signs of an incident fall into one of two categories: An indicator is a sign that an incident may have occurred or may be occurring now. There are many examples: Network or Host based intrusion detection sensor alerts Antivirus software alerts Repeated user account unauthorized access attempt log entries Integrity checking detects static or sensitive system or files changes An administrator sees a large number of bounced s with suspicious content. A network administrator notices an unusual deviation from typical network traffic flows.

14 Incident Detection, Identification and Recording In order to make incident identification more effective there are the following methods that can be employed: Profile Networks and Systems Understand Normal Behaviors Create a Log Retention Policy Perform Event Correlation Keep All Host Clocks Synchronized Maintain and Use a Knowledge Base of Information Use Internet Search Engines for Research Run Packet Sniffers to Collect Additional Data Filter the Data.

15 Incident Detection, Identification and Recording Due to time constraints and need to act, you will not be able to review and analyze all the indicators; at minimum the most suspicious activity should be investigated. Filter out categories of indicators that tend to be insignificant. Filtering strategy is to show only the categories of indicators that are of the highest significance. NOTE Filtering does run the risk, because new malicious activity may notfall into one of the chosen indicatorfilters

16 Incident Detection, Identification and Recording The CSIR team must maintain records about the incident: The current status of the incident (new, in progress, forwarded for investigation, resolved, etc.) A summary of the incident Precursors and/or Indicators related to the incident Other incidents related to this incident Actions taken by all incident id handlers on this incident id Impact assessment(s) related to the incident Contact information for other involved parties (e.g., system owners, system administrators, management and legal) Evidence gathered during the incident investigation and inventory of this evidence Comments from incident handlers

17 Recognized Investigative Techniques and Diagnosis The process for performing digital forensics comprises the following basic phases 2 : Collection: identifying, labeling, recording, and acquiring data from the possible sources of relevant data, while following procedures that preserve the integrity of the data. Examination: forensically processing collected data using a combination of automated and manual methods, and assessing and extracting data of particular interest, while preserving the integrity of the data. Analysis: analyzing the results of the examination, using legally justifiable methods and techniques, to derive useful information that addresses the questions that were the impetus for performing the collection and examination. 2 NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

18 Recognized Investigative Techniques and Diagnosis The process for performing digital forensics comprises the following basic phases 2 : Reporting: reporting the results of the analysis, which may include describing the actions used, explaining how tools and procedures were selected, determining what other actions need to be performed (e.g., forensic examination of additional data sources, securing identified vulnerabilities, improving existing security controls), and providing recommendations for improvement to policies, procedures, tools, and other aspects of the forensic process. 2 NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

19 Recognized Investigative Techniques and Diagnosis Before we go any further Does your organization have the requisite skills and assets to accomplish CSIR investigations and analysis/diagnosis? Organizations should ensure that their policies contain clear statements addressing all major forensic considerations, such as legal lreview of investigative tools, techniques and processes, contacting law enforcement, performing monitoring, and conducting regular reviews of forensic policies and procedures. 2 NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

20 Recognized Investigative Techniques and Diagnosis Critical to success factors when examiningdata from data files are as follows. Examine copies of files, not the original files. Preserve and verify file integrity. Rely on file headers, not file extensions, to identify file content types. Have a forensic toolkit for data examination and analysis Integrity controls over: the platforms where the tools are stored Platform image Tool(s) images Verifiable patching

21 Recognized Investigative Techniques and Diagnosis Fundamentalsfor Operating Systems OS data exists in both non volatile and volatile states. Non volatile data refers to data that persists even after a computer is powered down, such as a file system stored on a hard drive. Volatile data refers to data on a live system that is lost after a computer is powered down, such as the current network connections to and from the system and data stored in RAM 2 NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

22 Recognized Investigative Techniques and Diagnosis Fundamentalsfor Operating Systems Proper tools must be employed to examine both volatile and non volatile data. As an example Filtering tools automate the process of examining swap and RAM dump files by identifying text patterns and numerical values that might represent phone numbers, names of people, e mail addresses, Web addresses, and dother types of critical tca information ato 2 NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

23 Recognized Investigative Techniques and Diagnosis Fundamentalsfor network forensics: Reconstructing events by replaying network traffic Visualizing the traffic flows and the relationships among hosts Building profiles of typical activity and identifying significant deviations Searching application content for keywords 2 NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

24 Recognized Investigative Techniques and Diagnosis The sheer volume and scope of tools and techniques needed to properly capture, analyze and diagnosethe incident go far beyond the time allowed for this session. More information can be found at: NIST Special Publication , GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

25 Resolution and Recovery Processes for Your Environment Once your Incident Response Team has contained the incident, typical recovery actions may include: Eradication of quarantined threat to eliminate components of the incident, such as deleting malware and disabling breached user accounts. At times eradication is either not necessary or is performed during recovery. In recovery, administrators restore systems to normal operation and (if applicable) remediate vulnerabilities to prevent similar incidents. Restoring systems from clean backups or even rebuildingsystems from scratch Replacing compromised files with clean versions Installing patches

26 Resolution and Recovery Processes for Your Environment Once your Incident Response Team has contained the incident, typical recovery actions may include: (continued) Changing passwords Tighteningnetwork network perimeter security Higher levels of system logging or network monitoring Once a target has been successfully compromised, the word spreads among hostile threats and the same or like resource in another location in your organization will often be attacked again. Reporting requirements must be coordinated in accordance with your organization s policies and procedures there should be no delays

27 Resolution and Recovery Processes for Your Environment Lessons Learned Each incident response team should evolve to reflect new threats, improved technology, and lessons learned. This meeting held within several days of the end of the incident. Exactly what happened, and at what times? How well did staff and management perform in dealing with the incident? id Were the documented dprocedures followed? Were they adequate? What information was needed sooner? Were any steps or actions taken that might have inhibited the recovery? What would the staff and management do differently the next time a similar incident occurs?

28 Resolution and Recovery Processes for Your Environment Lessons Learned (continued) How could information sharing with other organizations have been improved? What corrective actions can prevent similar incidents in the future? What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

29 Establishing and Evaluating Incident Management Framework Policy Elements High level organization wide directive governing incident response, and should include the following key elements: Statement of management commitment (Tone at the Top) Purpose and objectives of the policy Scope ofthe policy (to whomand what it applies and under what circumstances) Definition of computer security incidents Organizational structure Roles and responsibilities

30 Establishing and Evaluating Incident Management Framework Policy Elements continued: Levels of authority to include the authority of the incident response team to confiscate or disconnect equipment and to monitor suspicious activity The requirements for: Reporting certain types of incidents External communications i and information i sharing (e.g., what can be shared with whom, when, and over what channels) Prioritization or severity ratings of incidents Performance measures Reporting and contact forms.

31 Establishing and Evaluating Incident Management Framework Plan Elements Formal, focused, tailored and coordinated roadmap for implementing the incident response capability. The incident response plan should include the following elements: Mission Strategies and goals Senior management approval Organizational approach to incident response How the incident response team will communicate with the rest of the organization and with other organizations Metrics for measuring the incident response capability bl Roadmap for maturing the incident response capability How the program fits into the overall organization

32 Establishing and Evaluating Incident Management Framework Procedure Elements Based on the incident response policy and plan. Standard operating procedures (SOPs) consist of: Specific technical processes Tools and Techniques Checklists Threat and risk assessment Escalation checklist System specific procedures Forms used by the incident response team...document in a timely, accurate and correct manner

33 Establishing and Evaluating Incident Management Framework SOPs need to be adequate to provide reasonable assurance that the following are meet: Organizational priorities are addressed. Minimize errors, particularly those that mightbe caused by incident handling tempo and stress. SOPs should be: Tested to validate their accuracy and usefulness Under controlled distribution to all team members. Training needs to be provided for all prospective SOP users

34 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Number of Incidents Recorded Caution when looking at numbers take care to investigate why number counts decrease or increase The number of incidents handled may decrease because of better network and host security controls, not because of negligence by the incident response team. May increase due to increased employee and customer y p y awareness

35 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Number of Incidents Recorded continued Optimal use as a measure of the relative amount of work that the incident response team had to perform, not as a measure of the quality of the team.

36 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Number of Incidents Recorded continued Produce separate incident counts for each incident category. Subcategories also can be used to provide more information. i Growing number of incidents performed by insiders need for background investigations for personnel Misuse of computing resources and stronger security controls on internal networks

37 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Time Per Incident: Total amount of labor spent working on the incident Cycle time from the beginning of the incident to incident discovery, to the initial impact assessment, and to each stage of the incident handling process (e.g., containment, recovery)

38 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Time Per Incident: Length of time for the incident response team to respond to the initial report of the incident Length of time to report the incident to management and, if necessary, appropriate external entities (e.g., Outside Legal Counsel, Law Enforcement, US CERT).

39 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Objective Assessment of Each Incident Examine logs, forms, reports, and other incident documentation for compliance with incident response policies i and procedures Were precursors and indicators of the incident documented?

40 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Objective Assessment of Each Incident Did the incident caused damage before it was detected? Was adequate root cause analysis performed to include the vector of attack, the vulnerabilities exploited, and the characteristics of the targeted or victimized systems, networks, and applications?

41 Establishing and Evaluating Incident Management Framework Evaluating your organization s CSIRC can include the following areas of focus: Objective Assessment of Each Incident Is the incident is a recurrence of a previous incident? If so why did it happen again? How were estimated monetary damage calculated from the incident (e.g., information and critical processes negativelyaffected affected by the incident)?

42 Summary Identify incident detection and recording CSIR team must have mechanisms and processes in place to detect signs or indicators of an incident Deep, specialized technical knowledge and extensive experience are necessary for proper and efficient analysis of incident related data. Recognize investigative techniques and diagnosis Your organization must have the requisite skills and assets to accomplish CSIR investigations and analysis/diagnosis Your organizations should ensure that their policies contain clear statements addressing all major forensic considerations, such as legal review of investigative tools, techniques and processes, contacting law enforcement, performing monitoring, and conducting regular reviews of forensic policies and procedures.

43 Summary Determine resolution and recovery Once a target has been successfully compromised tag your it, and your adversary know it. Reporting requirements must be coordinated in accordance with your organization s policies and procedures there should be no delays

44 Summary Establish and evaluate incident management framework Defined and documented CSIR Policy, Plan and SOPs Processes must be measureable Performance measures need to based on your environment s critical features and processes

45 Good References for Incident Management Practices National Institute of Standards and Technology (NIST) Special Publications Special Publication , Computer Security Incident Handling Guide Special Publication , Guide to Malware Incident Prevention and Handling Special Publication , 86, Guide to Integrating Forensic Techniques into Incident Response

46 Good References for Incident Management Practices OMB Memorandum M , Safeguarding Against and Responding to the Breach of Personally Identifiable Information, May 2007

47 Questions?

48 Collaborate Contribute Connect The Knowledge Center is a collection of resources and online communities that connect ISACA members globally, across industries and by professional focus - under one umbrella. Add or reply to a discussion, post a document or link, connect with other ISACA members, or create a wiki by participating in a community today!