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:
- 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.