Cybersecurity Emergency Guidance

Introduction ⫘

Should a cybersecurity emergency occur, Secureworks Incident Response is available to support your organization. It is always best to have a response plan in place and tested before a cybersecurity emergency occurs to enable effective and efficient response. Response plans provide perspective of all the moving technical and non-technical components of incident response processes and articulates roles, responsibilities, and the urgency in which activities need to be completed.

The recommendations below can help guide you as you establish incident response plans or seek assistance from Secureworks.

Cybersecurity Emergency Symptoms and Indications ⫘

Cyber Incidents come in many different forms and there are certain signs that a cybersecurity emergency is underway or has taken place. Although no single indicator conclusively shows that a cybersecurity emergency has occurred or is taking place, observing one or more indicators prompts the observer to investigate events more closely.

While addressing what initially appears to be an operational issue, it is possible that a cybersecurity emergency could be uncovered. For this reason, it is important to watch for the presence of these indicators and escalate issues or events that display them to incident response and analysis resources to determine appropriate next steps.

Potential cyber threat indicator sources include:

• Cybersecurity software and devices (e.g., IDS, IPS, DLP, SIEM, antivirus and spam software, file integrity monitoring software, monitoring services)
• Logs (e.g., operating system logs, service and application logs, network device logs, and network flows)
• Publicly available information (e.g., information on new exploits, information exchange groups, third party organizations, governments)
• People from within your organization
• Third parties (e.g., Customers, suppliers, IT providers, ISPs, partners, and government agencies)

At the highest level, the concerns surrounding Cyber Incidents all relate back to ensuring the confidentiality, integrity, and availability of systems and information. Below are exemplar indicators for each of these properties. It is not intended to be a comprehensive list, but to provide guidance with some indicators that additional investigation could be warranted.

Cyber threat indicators or symptoms of compromise include:

• Unusual traffic to or from a host
• Network or host intrusion detection alerts
• A third party contacting the organization to advise that a host appears to be involved in some attack activity (e.g., law enforcement, service provider, a peer organization, etc.)
• Unexpected access attempts to critical files (e.g., protected files or network shares)
• Presence of .zip, .rar, .tar, and other types of unidentified or unexpected compressed files
• Unexplained account usage (e.g., a typically idle account in use, account in use from multiple locations at once, commands that are unexpected from a particular user, large number of locked-out accounts)
• Hardware that is completely or partially missing (i.e., a system was opened, and a particular component removed)
• Vendor or third-party connections made to the environment without prior consent and/or a trouble ticket
• A threat from a group stating that the group will attempt to compromise the organization.
• Existence of unauthorized or unexpected tools, applications, or other files
• New files or directories with unusual names (e.g., binary characters, leading spaces, leading dots)
• System configuration changes, including process/service modifications or additions, unexpected open ports, system status changes (restarts, shutdowns), changes to log and audit policies or data
• Network interfaces set to promiscuous mode
• New user account or groups created
• Modifications of critical files, timestamps and privileges, including executable programs, OS kernels, system libraries, and configuration and data files
• Unexplained account usage (e.g., a typically idle account in use, account in use from multiple locations at once, unexpected commands from a particular user, large number of locked-out accounts)
• Unusual operating system or application log messages
• Unauthorized new hardware (e.g., attacker connects an unauthorized network device or unauthorized removable media)
• Antivirus software alerts
• User reports of system unavailability, instability, or abnormal slowness
• Automated service/system monitoring alerts
• Significant changes in system resource usage (e.g., CPU, memory, network bandwidth utilization)
• Unexplained connection losses
• Large number of connections to a single host
• Asymmetric network traffic patterns (e.g., large amount of traffic going to the host, little traffic coming from the host)

Response Team Recommendations ⫘

When a cybersecurity emergency occurs, all participants should:

• Stay calm.
• React in accordance with previously developed plans and processes. Consider designating an incident commander with clear levels of authority for decision making and supervision of internal and external activities for incident response, business continuity, and crisis management.
• Continuously evaluate the level of internal and external support required to enable appropriate response and enlist additional internal and external resources as required.
• Prepare for enlisting outside support by:
  • Identifying characteristics of the affected systems, to include operating system, application details, and business purpose.
  • Providing network diagrams, logs, and malware samples
  • Collecting artifacts like network packet captures, network flow logs, or potentially related phishing emails
  • Preserving digital media in a forensically sound manner
  • Documenting actions taken
• Consider designating an internal project manager to track all activities, decisions, and action items for all response participants.
• Consider having the entire engagement protected by the legal privilege and work product doctrine through internal or external legal counsel.
• Consider any customer or third-party requirements if insurance claims are pursued. Consider appropriate arrangements for legal hold notifications or actions.
• If third party organizations need to be presented with incident response findings, consider their position on the issues, purpose, and concerns for any liability.
• Consider making staffing schedules and work rotations to cover potential 24x7 support requirements until the incident is under control.
• Discuss the need to power down, keep alive, or disconnect from the network the compromised system. Also, review backup and/or rebuilding options.
• Determine the need for emergency maintenance windows to make forensic copies of affected system.

Secureworks will provide a chain of custody document for any digital media images that need to be physically collected for digital forensic analysis efforts during the course of an engagement.

Secureworks can provide options for the transport of any digital media images, such as media sanitization, returning, and/or transfers to a preferred third party, such as legal counsel or archiving services.

Preparing for a Secureworks Scoping Call ⫘

Cyber Incidents may be reported at various stages, including when complete information or facts are not available. Gathering as much information as possible will help expedite assistance to your organization. When a cybersecurity emergency is suspected, answers to the following questions will help determine the appropriate course of action to receive assistance from Secureworks.

1. Indications or symptoms of cyber intrusion activity (i.e., "What brought this to your attention? What was your first indicator? Who discovered the issue and when?").
2. Sources of the indications or symptoms of cyber intrusion activity (e.g., "This was reported to us by the Secureworks SOC. Our anti-virus solution alerted to the presence of malware.").
3. Current status (choose one):
   • Critical: business outage, confirmed data exfiltration, or compromise of critical infrastructure
   • High: business hindrance, suspected data exfiltration, or suspected compromise of critical infrastructure
   • Medium: previous cyber intrusion that may not be mitigated
   • Low: due diligence analysis or analysis of a previous cyber intrusion that has been mitigated
4. Type of affected assets (e.g., systems, networks, data) with operating system and application information
5. Response actions that have already been performed
6. Network and data flow topology to include:
   • Logical location of affected systems (e.g., ICS/SCADA, ITAR, PCI, or critical infrastructure enclaves)
   • Accessibility to/from other network assets (e.g., internet, data centers, ICS/SCADA zones, or other critical assets, protocols allowed to and from the affected asset(s))
7. Affected site location(s) with city/state/country Information

Lessons Learned Process ⫘

The lessons learned phase of the incident response life cycle is often one of the most neglected and potentially important aspects of responding to an incident. Capturing and actioning lessons learned is critical to avoiding or limiting the impact of future incidents and should be clearly codified within the incident response plan.

The incident response plan should define temporal requirements (i.e., how quickly lessons learned should be conducted), the responsible party for performing lessons learned, and, if needed, an update process for the incident response plan.

If requested and as a part of Secureworks’ Proactive services, Secureworks can perform the lessons learned process for the organization, which may be beneficial to provide an independent perspective.

During the lessons learned process, notes and other documentation from the incident are essential; ergo, it is important for the organization to capture notes and other documentation throughout the incident.

Should the organization conduct their own lessons learned process, common questions to ask include:

• 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 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?

Source: NIST SP 800-61R2: Computer Security Incident Handling Guide