In the constantly evolving world of information security, words and concepts are often introduced and quickly become the standard vernacular. Sometimes there is disagreement on the definition....or perhaps the definition was never clear to begin with.
As the leading provider of infosec training, education and networking, MISTI is pleased to introduce DeMISTIfying Infosec, a weekly newsletter that aims to define a weekly term from our marketplace. Plus we'll add in a few recommendations or context around the definition so it's easier to apply in your own organization. Click here to join the mailing list.
Is there a term or concept you'd like to see DeMISTIfied? Would you define a term differently? Tweet at us and let us know!
Incident Response Planning
Incident response is the process of reacting to a real or potential data breach or theft. Incident response can be viewed as a set of specific and detailed policies and procedures that are planned in advance, practiced, and deployable when a security incident occurs. Some examples of indicators of an incident include:
- Attempts to gain unauthorized access to a network, system, or data
- Unauthorized use/misuse of a system, network, or data
- Unauthorized changes to system hardware, firmware, or software
- Loss of data (accidental or intentional)
- Unusual/Suspicious network behavior
- Unauthorized modifications to systems, networks, or data
- Denial of service
- Malware or other signs of infection
The first part of incident response (IR) planning is to form an IR committee - including representatives from IT, security, HR, legal, and communications teams—which determines the policies and procedures to be followed during an incident.
Once the policies and procedures have been determined and documented, they should be practiced so that all responders are ready to perform under the pressure of an incident.
After an incident has been discovered, the next step is containment. During the containment process, a technical team comprised of internal and/or external experts works to assess what data, networks, or systems have been affected; the level of damage; any loss of data; indicators of attack, attack methods, or attackers; and any other details that will be useful in determining what went wrong so that controls can be put in place to contain the damage and/or shut down affected systems to prevent further damage.
Once the technical team has a reasonable grasp on the incident, the notification process begins. Notification includes communicating to internal and external parties, and messaging to customers, shareholders, and the press should be prepared carefully and with the assistance of legal and HR teams. Notification to law enforcement may also be required or recommended, depending on the severity of the breach and compliance or legal obligations.
While notification is happening, technical teams (internal and/or external) should be working to eradicate any lingering problems in the system, such as getting rid of malware or vulnerabilities that allowed attackers to get into and manipulate the network.
After systems have been "cleaned" and best efforts to mitigate damage have been completed, the technical teams must begin the process of recovering any lost information and restoring systems shut down during the incident to keep further damage from occurring.
Finally, after the incident response has concluded and systems are back up and running as normal, a review or "lessons learned" should be conducted so that organizations can refine their incident response plan to work more effectively during the next incident.