IRP on a Budget

Editor's Notes

• #5: NIST SP 800-53r4 - Security and Privacy Controls for Federal Information Systems and Organizations An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. NIST SP 800-61r2 Computer Security Incident Handling Guide An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and 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. This guide addresses only adverse events that are computer security related, not those caused by natural disasters, power failures, etc. A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. Examples of incidents are: An attacker commands a botnet to send high volumes of connection requests to a web server, causing it to crash. Users are tricked into opening a “quarterly report” sent via email that is actually malware; running the tool has infected their computers and established connections with an external host. 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. A user provides or exposes sensitive information to others through peer-to-peer file sharing services.
• #7: The Health Insurance Portability and Accountability Act (HIPAA) Security Rule
• #8: CSC #19 – “Protect the organization’s information, as well as its reputation, by developing and implementing an incident response infrastructure (e.g., plans, defined roles, training, communications, management oversight).” NIST 800-53r4 IR-1 – Incident Response Policy and Procedures IR-2 – Incident Response Training IR-3 – Incident Response Testing IR-4 – Incident Handling IR-5 – Incident Monitoring IR-6 – Incident Reporting IR-7 – Incident Response Assistance IR-8 – Incident Response Plan IR-9 – Information spillage Response IR-10 – Integrated Information Security Analysis Team NIST 800-61r2 draft– responding quickly is critical to minimizing the impact
• #9: Top Three Threat Actions: Hacking Malware Social
• #10: 82% into network in minutes OR LESS 21% start exfiltration data in MINUTES
• #13: Preparation Preparing to Handle Incidents Preventing Incidents Detection and Analysis Attack Vectors Signs of an Incident Sources of Precursors and Indicators Incident Analysis Incident Documentation Incident Prioritization Incident Notification Containment, Eradication, and Recovery Choosing a Containment Strategy Evidence Gathering and Handling Identifying the Attacking Hosts Eradication and Recovery Post-Incident Lessons Learned Using Collected Incident Data Evidence Retention
• #14: PREPARING Communication Resources: Contact information for team members and others within and outside the organization (primary and backup contacts), such as law enforcement and other incident response teams; information may include phone numbers, email addresses, public encryption keys (in accordance with the encryption software described below), and instructions for verifying the contact’s identity On-call information for other teams within the organization, including escalation information
• #15: PREPARING Communication Resources: Contact information for team members and others within and outside the organization (primary and backup contacts), such as law enforcement and other incident response teams; information may include phone numbers, email addresses, public encryption keys (in accordance with the encryption software described below), and instructions for verifying the contact’s identity On-call information for other teams within the organization, including escalation information Incident reporting mechanisms, such as phone numbers, email addresses, online forms, and secure instant messaging systems that users can use to report suspected incidents; at least one mechanism should permit people to report incidents anonymously Issue tracking system for tracking incident information, status, etc. Smartphones to be carried by team members for off-hour support and onsite communications Encryption software to be used for communications among team members, within the organization and with external parties; for Federal agencies, software must use a FIPS-validated encryption algorithm War room for central communication and coordination; if a permanent war room is not necessary or practical, the team should create a procedure for procuring a temporary war room when needed Secure storage facility for securing evidence and other sensitive materials Hardware and Software: Digital forensic workstations and/or backup devices to create disk images, preserve log files, and save other relevant incident data Laptops for activities such as analyzing data, sniffing packets, and writing reports Spare workstations, servers, and networking equipment, or the virtualized equivalents, which may be used for many purposes, such as restoring backups and trying out malware Blank removable media Portable printer to print copies of log files and other evidence from non-networked systems Packet sniffers and protocol analyzers to capture and analyze network traffic Digital forensic software to analyze disk images Removable media with trusted versions of programs to be used to gather evidence from systems Evidence gathering accessories, including hard-bound notebooks, digital cameras, audio recorders, chain of custody forms, evidence storage bags and tags, and evidence tape, to preserve evidence for possible legal actions Analysis: Port lists, including commonly used ports and Trojan horse ports Documentation for OSs, applications, protocols, and intrusion detection and antivirus products Network diagrams and lists of critical assets, such as database servers Current baselines of expected network, system, and application activity Cryptographic hashes of critical files to speed incident analysis, verification, and eradication Jump Kit - For example, each jump kit typically includes a laptop, loaded with appropriate software (e.g., packet sniffers, digital forensics). Other important materials include backup devices, blank media, and basic networking equipment and cables. PREVENTING If security controls are insufficient, higher volumes of incidents may occur, overwhelming the incident response team. This can lead to slow and incomplete responses, which translate to a larger negative business impact (e.g., more extensive damage, longer periods of service and data unavailability). Risk Assessments: -Ongoing RA should identify threats for each system/application. Each risk should be prioritized, and the risks can be mitigated, transferred, or accepted until a reasonable overall level of risk is reached. Another benefit of conducting risk assessments regularly is that critical resources are identified, allowing staff to emphasize monitoring and response activities for those resources. Host Security: - Hardened standard builds, patching process, and principle of least privilege. Audit Logging – collection, alerting, review Network Security: Securing all connection points Monitoring connections Malware Prevention: Host level (workstation + server) Application level (email, web proxy, etc.) Application clients (email client, instant messaging, etc.) User Awareness Training: Policy and Procedure review Sharing of “Lessons Learned” from incidents
• #16: It is not feasible to develop instructions for every incident. We need to be generally prepared for any incident, and focus additional efforts on the most common attack vectors. Attack Vectors: Removable Media: USB, CD/DVD, peripherals Attrition: DDoS, brute force authentication pages (passwords, Captchas, etc.) Web Attack: cross site scripting. Typically addressed in OWASP Top 10 Email: Attachments or links with malicious code Impersonation: Spoofing, Man in the Middle, rogue WAPs, SQL injection on web app Improper Usage: Violations of Acceptable Usage Policy – loss of sensitive data, illegal activities, etc. Loss/Theft Equipment: laptops, removable media, mobile devices, authentication tokens, etc. Signs of an Incident: These should be developed in house to identify what Indicators would be most applicable. Automated possibilities: IDS/IPS, AV/Anti-Malware, SIEM/Log analyzers, file integrity monitoring, 3rd party monitoring (watching for IPs or domain name in know malicious activity) Manual: user reported errors or anomalies Need a way to sort through the volume of reports, and have the appropriate level of understanding and expertise to make these signs actionable. Sources of Precursors and Indicators: Signs of an incident fall into one of two categories: precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. Typical Precursors (rare): 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. Some common indicators (extremely common): A network intrusion detection sensor alerts when a buffer overflow attempt occurs against a database server. Antivirus software alerts when it detects that a host is infected with malware. A system administrator sees a filename with unusual characters. A host records an auditing configuration change in its log. An application logs multiple failed login attempts from an unfamiliar remote system. An email administrator sees a large number of bounced emails with suspicious content. A network administrator notices an unusual deviation from typical network traffic flows. Incident Analysis Some systems can help automate some of the analysis leg work, but this is not an adequate substitution for experienced staff. Validation should follow a pre-defined process Once validated, the IRP should be enacted, with prioritization being based off the initial analysis. Efficiencies in analysis: Profile the Networks and Systems – understand the normal characteristics. File checksums, bandwidth usage. This is difficult to use when used alone. Understand Normal Behaviors – Frequent log reviews to help identify what is standard, and make the unusual stand out. This process will also validate the accuracy of log sources, and aid in initial analysis. Log Retention – Many incidents not caught right away, we will need historical logs to review to determine the scope of the incident. NIST SP 800-92 Guide to Computer Security Log Management provides additional guidance. Event Correlation – Tracing footsteps – see username in an application log, perhaps it can tie back to an IP from the firewall. An IDS may alert of an attack, and the local server log may confirm or deny success. NTP Synchronization – is no synchronization correlation can be extremely difficult Knowledgebase – detail out significance and validity of precursors and indicators that IRP team can reference. Should be easy to search and use. OSINT – google search of uncommon ports or IPs may help identify a common attack Packer Sniffers – need to be tuned to collect a management amount of data. Consider privacy implications. Focus efforts on most suspicious activity first Consider third parties, internal and external (SMEs, security staff, contractors, US-CERT, etc.) Incident Documentation As soon as an incident is suspected, the team (or analyst) should start recording all facts. Logbooks, laptops, cameras, audio recording are all possible. System events Conversations Observed changes in files All steps taken until resolution, including timestamps, supporting documentation obtained during investigation and resolution. Helps to have two people, one to work while the other records Status updates should be documented and communicated, typically ticketing system can be used. Be careful as this data will be extremely sensitive (exploitable vulnerabilities, recent breaches, etc.) The current status of the incident (new, in progress, forwarded for investigation, resolved, etc.) A summary of the incident Indicators related to the incident Other incidents related to this incident Actions taken by all incident handlers on this incident Chain of custody, if applicable Impact assessments related to the incident Contact information for other involved parties (e.g., system owners, system administrators) A list of evidence gathered during the incident investigation Comments from incident handlers Next steps to be taken (e.g., rebuild the host, upgrade an application).
• #17: Choosing a Containment Strategy Containment is important before an incident overwhelms resources or increases damage. Most incidents require containment, so that is an important consideration early in the course of handling each incident. Containment provides time for developing a tailored remediation strategy. For example, the strategy for containing an email-borne malware infection is quite different from that of a network-based DDoS attack. Organizations should create separate containment strategies for each major incident type, with criteria documented clearly to facilitate decision-making. Potential Damage to and theft of resources Need for evidence preservation Service availability (e.g., network connectivity, services provided to external parties) Time and resources needed to implement the strategy Effectiveness of the strategy (e.g., partial containment, full containment) Duration of the solution (e.g., emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution). Sandbox to monitor potentially OK - if an organization knows that a system has been compromised and allows the compromise to continue, it may be liable if the attacker uses the compromised system to attack other systems. Handlers should not assume that just because a host has been disconnected from the network, further damage to the host has been prevented. EXAMPLE – ping hosts, if no response, encrypt the entire drive. Evidence Gathering and Handling Primary focus is to resolve the incident, but don’t forget about potential legal proceedings. Evidence should be collected according to procedures that meet all applicable laws and regulations that have been developed from previous discussions with legal staff and appropriate law enforcement agencies so that any evidence can be admissible in court. This includes chain of custody for physical transfers. A detailed log should be kept for all evidence, including the following: Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) addresses, and IP addresses of a computer) Name, title, and phone number of each individual who collected or handled the evidence during the investigation Time and date (including time zone) of each occurrence of evidence handling Locations where the evidence was stored. NIST SP800-86 Guide to Integrating Forensic Techniques into Incident Response can be useful. Identifying Attacking Hosts Although this information can be important, incident handlers should generally stay focused on containment, eradication, and recovery. Identifying an attacking host can be a time-consuming and futile process that can prevent a team from achieving its primary goal—minimizing the business impact. Validating the attacking host IPs address - A failure to respond does not mean the address is not real—for example, a host may be configured to ignore pings and traceroutes. Also, the attacker may have received a dynamic address that has already been reassigned to someone else. Researching host through search engines - Performing an Internet search using the apparent source IP address of an attack may lead to more information on the attack—for example, a mailing list message regarding a similar attack. Knowledge base / Incident Database – try to identify similar attacks Monitoring Possible Attacker Communication Channels – C&C usually uses IRC. Also, attackers may congregate on certain IRC channels to brag about their compromises and share information. However, incident handlers should treat any such information that they acquire only as a potential lead, not as fact. Eradication and Recovery Removing malware Disabling breached user accounts Identifying the mitigating exploited vulnerabilities Restore systems to normal operation Should be a phased approach based on priority
• #18: Lessons Leaned Often overlooked, people return to business as usual. Each of these incidents should help the team identify new threats, improve technology, and lessons learned. Should be mandatory after significant incidents, and periodically to cover multiple minor incidents. Typical questions: Exactly what happened, and at what times? How well did staff and management perform in dealing with the incident? Were the documented procedures 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? How could information sharing with other organizations have been improved? What corrective actions can prevent similar incidents in the future? What precursors or indicators should be watched for in the future to detect similar incidents? What additional tools or resources are needed to detect, analyze, and mitigate future incidents? Output can be useful in improving IRP training documentation. All policies and procedures impacted should be updated as well. Follow-up reports can be stored in Knowledge Repository to help with future incidents similar in nature. Using Collected Incident Data Collect data to use it, not simply collecting because it is there. Useful Metrics: Number of Incidents Handled – measures work performed, not quality, may help get additional resources for controls. Can also break into sub-categories to get trending information. Time per Incident – Total labor time / Time to discovery, impact assessment, and each stage of the process / response time to initial report / time to communicate to external parties (US-CERT, law enforcement, etc.) Objective Review – review for adherence to establish policies/procedures / damage before detection? / was root cause identified and remediated? / recurrence of previous incident? / estimated monetary damage Subjective Review – team member self review / review of team members / review policies and procedures against requirements and best practices / Evidence Retention Factors to consider when identifying retention period/schedules: Prosecution – may be needed in legal proceedings, and that could take years Data Retention – retention policy may say purge email 180 days – does the impact the Incident data set? (General Records Schedule 24 says IRP data for 3 years) Cost – depending on how much data is being retained, the added cost can be substantial
• #19: MITRE Cyber exercise planning playbook https://www.mitre.org/sites/default/files/publications/pr_14-3929-cyber-exercise-playbook.pdf NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
• #20: Ransomware Playbook article https://www.demisto.com/playbook-for-handling-ransomware-infections/