What to do in the event of a cyber security incident

If you’re in Security or IT operations and you find yourself in the middle of a cyber-security incident, you have a very important role to play. Response teams will likely be relying on you to collect the information they need to determine the source and extent of a breach. Following are some of the key points F-Secure’s Incident Response recommends internal teams cover when dealing with an incoming incident.

What data do I have to support response?

Identify sources of data that might be useful:

• Domain/Server logs
• Web proxy logs
• Email server logs
• Network flow data from firewalls, packet capture devices, etc
• Application logs (SAP, SharePoint, cloud services etc)
• VPN authentication logs
• Physical security logs (card access etc)

Determine where these are stored:

• On endpoints and appliances?
• Centrally aggregated (SIEM, etc.)?
• Combination of both?

What won’t I have tomorrow?

Logs and other potentially useful data captured from networks are transient and may be lost as time passes or due to user actions. Are these:

Stored centrally?

• Check storage limitations, due to disk space or licensing
• Some data may be sent to an aggregation point, but discarded due to configuration – review this.

Only present on endpoints or appliances?

• Check and increase log storage limits – you want to keep captured data as long as possible.

In both cases:

• Increase logging levels if possible – gather as much potentially useful data as is realistic.
• Determine an archiving strategy – this may involve periodic exports from SIEM or network appliances, or constant retrieval of local logs from the server(s).

Where am I not looking?

Events related to an incident may show up in more than one data source. Move your focus beyond the point of detection / initial data source. For example:

Scenario: DLP detection of potentially malicious actions on endpoint

• Domain logs: Which accounts have been authenticating to the endpoint? Which other endpoints have these accounts been authenticating to? Authentications to other systems and services from this endpoint?
• Internal firewall logs: Network communication between suspect endpoint and other machines?
• AV logs: Any recent antivirus warnings or events?
• Proxy logs: What has this endpoint or user been contacting on the Internet? If there is anything unusual, is it used anywhere else?

Scenario: Compromised web application

• DMZ firewall: Anomalous connections from DMZ to the rest of the network?
• Domain logs: Unexpected sessions to other servers in DMZ?
• Outgoing proxy: Connections to the Internet from within DMZ?
• NetFlow: Connections to other servers in DMZ?

Am I considering the consequences of each action?

Actions taken during an incident may affect the outcome in unexpected ways. Therefore:

• Keep communications related to the incident away from the potentially compromised network – the attacker/s may be watching (includes email, collaboration platforms [SharePoint, Confluence, etc.], helpdesk ticketing systems, etc).
• Do not be tempted to “have a quick look”. Any actions risk changing and destroying artefacts valuable to an investigation.
• Refrain from switching off potentially infected endpoints, rather disconnect from the network. Memory contents may be valuable during the investigation.
• Don’t independently run malware scans, remove, relocate or upload malware to internet malware scanners. Let the response team know where new findings arise and advise on the best approach.
• Delayed responses allow more time for additional damage – quick reporting of incidents and response to them could be hugely beneficial.