<metaproperty="og:title"content="Security Incident - Spearhead Systems Incident Response Documentation"/>
<metaproperty="og:site_name"content="Spearhead Systems Incident Response Documentation"/>
<metaproperty="og:description"content="A collection of information about the Spearhead Systems incident response process. Not only how to prepare new employees for on-call responsibilities, but also how to handle major incidents, both in preparation and after-work."/>
<metaname="twitter:title"content="Security Incident - Spearhead Systems Incident Response Documentation"/>
<metaname="twitter:description"content="A collection of information about the Spearhead Systems incident response process. Not only how to prepare new employees for on-call responsibilities, but also how to handle major incidents, both in preparation and after-work."/>
<p>As with all major incidents, security ones will also involve a Team Leader, who will delegate the tasks to relevant resolvers. Tasks may be performed in parallel as assigned by the TL. Contact one at the earliest possible opportunity.</p>
<p>Stop the attack as quickly as you can, via any means necessary. Shut down servers, network isolate them, turn off a data center if you have to. Some common things to try,</p>
<ul>
<li>Shutdown the instance from the provider console (do not delete or terminate if you can help it, as we'll need to do forensics).</li>
<li>If you happen to be logged into the box you can try to,<ul>
<li><code>kill -9</code> any active session you think is an attacker.</li>
<li>Change root password, and update /etc/shadow to lock out all other users.</li>
<li><code>sudo shutdown now</code></li>
</ul>
</li>
</ul>
<h2id="cut-off-attack-vector">Cut Off Attack Vector<aclass="headerlink"href="#cut-off-attack-vector"title="Permanent link">#</a></h2>
<p>Identify the likely attack vectors and path/fix them so they cannot be re-exploited immediately after stopping the attack.</p>
<ul>
<li>If you suspect a third-party provider is compromised, delete all accounts except your own (and those of others who are physically present) and immediately rotate your password and MFA tokens.</li>
<p>Identify the key responders for the security incident, and keep them all in the loop. Set up a secure method of communicating all information associated with the incident (internal Chat is one option). Details on the incident (or even the fact that an incident has occurred) should be kept private to the responders until you are confident the attack is not being triggered internally.</p>
<li>The security and site-reliability teams should usually be involved.</li>
<li>A representative for any affected services should be involved.</li>
<li>A Team Leader (TL) should be appointed, who will also appoint the usual incident command roles. The incident command team will be responsible for keeping documentation of actions taken, and for notifying internal stakeholders as appropriate.</li>
<li>Do not communicate with anyone not on the response team about the incident until forensics has been performed. The attack could be happening internally.</li>
<li>Give the project an innocuous codename that can be used for chats/documents so if anyone overhears they don't realize it's a security incident. (e.g. sapphire-unicorn).</li>
<p>Any instances which were affected by the attack should be immediately isolated from any other instances. As soon as possible, an image of the system should be taken and put into a read-only cold storage for later forensic analysis.</p>
<ul>
<li>Blacklist the IP addresses for any affected instances from all other hosts.</li>
<li>Turn off and shutdown the instances immediately if you didn't do that to stop the attack.</li>
<li>Take a disk image for any disks attached to the instances, and ship them to an off-site cold storage location. You should make sure these images are read-only and cannot be tampered with.</li>
</ul>
<h2id="identify-timeline-of-attack">Identify Timeline of Attack<aclass="headerlink"href="#identify-timeline-of-attack"title="Permanent link">#</a></h2>
<p>Work with all tools at your disposal to identify the timeline of the attack, along with exactly what the attacker did.</p>
<ul>
<li>Any reconnaissance the attacker performed on the system before the attack started.</li>
<li>When the attacker gained access to the system.</li>
<li>What actions the attacker performed on the system, and when.</li>
<li>Identify how long the attacker had access to the system before they were detected, and before they were kicked out.</li>
<li>Identify any queries the attacker ran on databases.</li>
<li>Try to identify if the attacker still has access to the system via another back door. Monitor logs for unusual activity, etc.</li>
<p>Using forensic analysis of log files, time-series graphs, and any other information/tools at your disposal, attempt to identify what information was compromised (if any),</p>
<ul>
<li>Identify any data that was compromised during the attack.<ul>
<li>Was any data exfiltrated from a database?</li>
<li>What keys were on the system that are now considering compromised?</li>
<li>Was the attacker able to identify other components of the system (map out the network, etc).</li>
</ul>
</li>
<li>Find exactly what customer data has been compromised, if any.</li>
<p>Based on the data that was compromised, assess the risk to other systems.</p>
<ul>
<li>Does the attacker have enough information to find another way in?</li>
<li>Were any passwords or keys stored on the host? If so, they should be considered compromised, regardless of how they were stored.</li>
<li>Any user accounts that were used in the initial attack should rotate all of their keys and passwords on every other system they have an account.</li>
<p>Once you are confident the systems are secured, and enough monitoring is in place to detect another attack, you can move onto the forensic analysis stage.</p>
<ul>
<li>Take any read-only images you created, any access logs you have, and comb through them for more information about the attack.</li>
<li>Identify exactly what happened, how it happened, and how to prevent it in future.</li>
<li>Keep track of all IP addresses involved in the attack.</li>
<li>Monitor logs for any attempt to regain access to the system by the attacker.</li>
<p>Communicate internally only once you are confident (via forensic analysis) that the attack was not sourced internally.</p>
<ul>
<li>Don't go into too much detail.</li>
<li>Overview the timeline.</li>
<li>Discuss mitigation steps taken.</li>
<li>Follow up with more information once it is known.</li>
</ul>
<h2id="liaise-with-law-enforcement-external-actors">Liaise With Law Enforcement / External Actors<aclass="headerlink"href="#liaise-with-law-enforcement-external-actors"title="Permanent link">#</a></h2>
<p>Work with law enforcement to identify the source of the attack, letting any system owners know that systems under their control may be compromised, etc.</p>
<ul>
<li>Contact local law enforcement.</li>
<li>Contact FBI.</li>
<li>Contact operators for any systems used in the attack, their systems may also have been compromised.</li>
<li>Contact security companies to help in assessing risk and any PR next steps.</li>
<p>Once you have validated all of the information you have is accurate, have a timeline of events, and know exactly what information was compromised, how it was compromised, and sure that it won't happen again. Only then should you prepare and release a public statement to customers informing them of the compromised information and any steps they need to take.</p>
<ul>
<li>Include the date in the title of any announcement, so that it's never confused for a potential new breach.</li>
<li>Don't say "We take security very seriously". It makes everyone cringe when they read it.</li>
<li>Be honest, accept responsibility, and present the facts, along with exactly how we plan to prevent such things in future.</li>
<li>Be as detailed as possible with the timeline.</li>
<li>Be as detailed as possible in what information was compromised, and how it affects customers. If we were storing something we shouldn't have been, be honest about it. It'll come out later and it'll be much worse.</li>
<li>Don't name and shame any external parties that might have caused the compromise. It's bad form. (Unless they've already publicly disclosed, in which case we can link to their disclosure).</li>
<li>Release the external communication as soon as possible, preferably within a few days of the compromise. The longer we wait, the worse it will be.</li>
<li>Figure out if there is a way to get in touch with customers' internal security teams before the general public notice is sent.</li>
<li><ahref="https://technet.microsoft.com/en-us/library/cc700825.aspx">Responding to IT Security Incidents</a> (Microsoft)</li>
<li><ahref="http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=7153">Defining Incident Management Processes for CSIRTs: A Work in Progress</a> (CMU)</li>
<li><ahref="https://www.first.org/conference/2008/papers/killcrece-georgia-slides.pdf">Creating and Managing Computer Security Incident Handling Teams (CSIRTS)</a> (CERT)</li>
