Welcome to Domain nine Incident Response and this module will use the incident Response lifecycle as a structure for examining incident response with up about preparation, detection and analysis, phase containment, eradication and recovery and post incident activities.
For the remainder of this video, we will be defining an incident giving an overview of the incident response lifecycle and I'm gonna have a little soap box speech on incident communications.
An event is any observable occurrence in a system or network. Events include user connecting to a file share server receiving a request from a Web page. Ah user sending an email, even a firewall blocking a connection attempt.
Adverse events are events with negative consequence. Such a system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data and execution of malware.
A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies or standards. Security practices.
Well known examples include an attacker whether it being individual organisation or nation. State commands a botnet to science ah, high volume of connection requests to a server causing that server to crash or become unavailable. This is often referred to as a DDOS attack.
Other examples users are tricked into opening an email that runs malware, which subsequently uses their system to perform unintended activities, or when a user is tricked to exposing sensitive information through a phishing email. I could go on and on with examples, but since you're on cyber, you're probably familiar with these and many, many more incident types,
whether they be nefarious in nature
Here we have the incident response lifecycle. This is based on the NIST specifications 861 Rev two. And this is the way we're going to structure our examination of incident response. Look at preparation, detection and analysis, containment eradication and recovery phase and the post incident activities.
Whether we're talking about a breach or an unintended outage, communication is important, and having the communication plan is even more important. I highly recommend that the individuals responsible for communication also referred to as communication handlers, not be the same as the person responsible for dealing with the incident. I've been personally caught in this pickle.
Nothing is more frustrating than trying to deal with a problem while at the same time being counted from many different parties
for details, updates and status being able to focus on solving the problem while spending mental cycles. Crafting email updates, responding to phone calls and text messages is a lot to put on a single person. At the same time, the CCS K exam doesn't go deep into specifics of incident communication,
but they did such a common problem. I wanted to call it out.
This isn't just in my experience, but it's a shared sentiment with many others that have held a role in technology operations. If you're a manager, make sure there is a communication plan. This could be you doing communicating or somebody else. If you aren't a manager, make a plea to your manager to put something like this in place.
This is particularly important in a cloud situation, since you are often not alone in resolving the incident.
As we examine, each phase of the I R. Lifecycle will speak to particulars of IR in the cloud environment. But as you probably expect, communicating with the cloud provider or communicating with cloud customers if you are a cloud provider is a vital point for handling incident response.
Thank you for listening to my speech now I'll get off my soapbox and will continue to summarize this video. We defined an incident, gave an overview of the incident response life cycle, and then you listen to my soapbox speech about incident communications.