CISM EXAM PREP - Domain 4B - Incident Management Operations

Welcome back to the CISM exam prep series. Here in domain 4, part B, we'll focus on incident management operations. This means the more hands-on aspects of our incident response, including our incident management tools and techniques, our incident investigation and evaluation methods. We'll look at incident containment. We'll talk through our response communications, basically how we report to and notify our stakeholders, as well as how we escalate in the midst of an incident. And we'll also explore incident eradication and recovery. So, you'll notice a lot of nuance there when it comes to terminology. We'll need to be very familiar on exam day with the difference between containment, eradication, and recovery. We'll wrap with a look at post incident review practices, including our lessons learned that drive continuous improvement in our incident response [Music] program.

In domain 4, part B, we'll be focused on incident management operations. And while you may know me from my exam prep content here on YouTube, in my 9to-5, I'm a cyber security strategist and a VCSO for a regional bank where I'm exercising my cyber security knowledge every day like that which you'll find here on the CISM exam. More importantly, last year I helped thousands achieve cyber security certifications like the CISSP, CCSP, and the Security Plus exams. And I'm bringing that proven formula to you here with the CISM exam. As with all my exam prep courses, you'll find a PDF copy of this presentation available for you in the video description to leverage in your exam preparation as you require. You'll also find a clickable table of contents available in the video description and it should appear automatically on your YouTube video timeline.

So we are in the fourth and final domain which is incident management. And as you probably know at this point, we divide each of those domains into a part A and part B aligning with the syllabus. Today we're looking at the eighth and final installment, domain 4, part B. And just to set the context here, we're in domain for part B, which is incident management operations, which consists of 4B1, which is tools and techniques, investigation and evaluation in 4B2, then incident containment methods, then incident response communications, incident eradication and recovery, and we'll finish up with 4B6, which is post incident review practice. ices and you see the same logical flows we've seen with the other domains. We have incident management readiness where you're doing the planning and the documentation and then incident management operations where we are implementing what we've prepared. And while it is six parts as was part A, you'll find part B is a bit shorter in terms of the content. And in terms of supporting tasks, there's one of the 37 left and it is number 37. conduct post incident reviews to facilitate continuous improvement including root cause analysis, lessons learned, corrective actions and reassessment of risk. So determining what we did well, where do we need to improve and how will we change our response in the future.

So 4B1 incident management tools and techniques. We'll talk about incident management systems briefly. We'll look at some foundational technology you'll want to be familiar with. We'll talk about the structure of the incident response team, their requisite skills, our awareness and education efforts, audits, considerations when we outsource some of these functions. So, enterprises use tools, sometimes commercial off-the-shelf tools, sometimes custom tools or both, and defined processes to manage their security incidents effectively. Automation tends to be key due to the high volume of data that organizations are dealing with.

So, let's talk about the incident management team versus the incident response team. So the incident management team is often the decision-making body where the response team handles the technical response. So they're two separate teams in the enterprise, often a single team in small and medium businesses. For clarity in our discussion here, let's treat the incident management team as the decision makers and the response team as responders, regardless of whether they're separate teams or a single unit. So why use incident management systems? Well, basically modern environments produce massive amounts of logs and security events which makes it virtually impossible to manage them manually at scale. And automated systems will filter, aggregate, and correlate data and alert personnel to potential issues. So they'll do some of that heavy lifting in the filtering, aggregation, and correlation. So we can get the people to looking at potential incidents more quickly. So it gives us faster detection and response, reduce business impact, less downtime, lower financial loss. It's going to help us protect our reputation. But these incident management systems have become standard practice in enterprises.

So there are two categories of incident management systems that the distributed and the centralized. So in terms of distributed we have your network intrusion detection or prevention systems or the hostbased intrusion detection and prevention systems. Now data from multiple points are generally sent to a central repository. Often that centralized system is a SIM, a security information event management system that we've discussed previously which will consolidate logs from many sources into one database. In fact, we have some common expectations of a SIM solution. It will generally normalize the data. It will bring data from disparate sources into a single repository and put it into a common format so we can query across that data. It correlates events to identify incidents in near real time. Prioritizes incidents based on severity and impact. Tracks incidents from detection to closure. It does need proper configuration and ongoing tuning. Generally speaking with a sim, you're going to have a heavier tuning effort in the opening weeks after you first implement that sim. And then it will settle into more of a steady state of a manageable few minutes a day. But this reduces operating costs. It's less manual effort for sure. And as I said, faster detection, better protection for the business. and your NIDs and HIDs data is often sent right over to the SIM. So, this is all going to wind up in one place in most environments.

So, other solutions that may integrate or leverage a SIM solution would include your endpoint detection and response, which focuses on individual endpoints, your laptop, servers, your smartphones. It's going to collect and analyze endpoint data, whether those are processes, files, network activity. It will detect suspicious behavior on those devices and enable response and investigation on the device. Generally also detecting any malware on those systems. Often today you'll hear of the extended detection and response system which has a broader scope than EDR. It integrates data from multiple layers from your endpoints, your network, cloud, email. So really bringing data in from across our services. It's going to give us a unified view of threats across the environment. Like the SIM, XDR generally allows us to query across data from multiple sources. It uses automation and machine learning for advanced detection and response. And then we have managed detection and response which is an outsourced service from a thirdparty provider. And these generally provide 247 monitoring, threat hunting, and response expertise. We'll see these commonly in small and medium businesses where it's perhaps prohibitively expensive to have a full-time staff manning that 24/7 function. But this includes people and processes, not just technology. They will often use some of the same tooling we talked about here, a SIM for example, but there'll be people there and processes for responding to potential incidents up to and including contacting the customer to let them know they believe they have a legitimate incident.

So let's talk about outsourcing considerations because even when we're outsourcing security operations, remember accountability for security always remains with your organization. You can delegate responsibility, you cannot delegate accountability. So, the contract needs to clearly define your service level agreements, especially response times, regulatory compliance duties, particularly important if we're in a regulated industry like health care or financial services, data ownership and privacy, incident identification, alignment for tracking, change management, integration, regular review meetings, methods and juris jurisdiction for conflict resolution. So your contracts will generally say if there is a disagreement often times it will mandate mediation. So discussion with a mediator rather than going right to litigation and should it go into legal proceedings the jurisdiction where those legal proceedings will take place.

So incident response personnel do need to have command of foundational security concepts to be effective in their roles. So if we think about core security principles, your team needs to understand the difference between confidentiality, integrity, availability, access control, authentication, non-repudiation, compliance, privacy. As a security leader, these should already be very familiar to you. If not, you'll want to circle back and get comfortable. But failures here cause incidents. If folks don't understand these basic concepts and what we're protecting, we're going to see problems. Security vulnerabilities and weaknesses. Knowing how attackers exploit systems, it's helpful to understand the types of attacks out there, but also how we protect against them. So misconfigurations are common areas of exploit. So whether that's in cloud services within an operating system on an endpoint or a network device, implementation of design flaws like buffer overflows we see in poorly written software, malicious code, operational errors like a successful fishing attack, and other areas. Those could include physical security gaps or risks that come with implementing new technologies. for example.

So the structure of the incident response team, it's often led by the information security manager or in larger environments, you may see a dedicated incident response manager. It's going to be overseen by a security steering committee, which would generally consist of senior management and may include folks from different business units. You might have some some process owners in there. It can include technical experts as well as potentially external help in smaller organizations especially and your models. You may have a central model which is one team for the whole organization. So that would often include the not only response function but potentially that management function we talked about. Now in larger environments you may see multiple teams for different segments and we could be talking about different business units or different geographies as we may have different requirements in different countries or regions for example. So our regulatory requirements for example might be different in Europe than they are in the United States. And in that distributed model there may be a central team that sets standards or guidelines for those distributed teams. In the outsourced model, we'll have a third party that handles some or all of the incident response functions. But the goal, regardless of the model here, whether it's central, distributed, outsourced, the goal is to mitigate incidents quickly and effectively and to minimize the impact to the business.

So, let's talk team composition. A welldefined incident response plan will outline who does what, ensuring quick action and accountability under stressful circumstances. So key roles and responsibilities would include that security steering group that sets strategy, approves budget and major decisions. The information security or information response manager whether separate roles or that unified role will lead the team will be that liaison with leadership and coordinating response across the team. The incident handler or investigator is the one who executes the plan, analyzes incidents, gathers evidence. We have the IT specialist who provide technical expertise. They may be focused on networks, servers, applications. They're going to help us implement fixes. And then support roles which provide specific expertise and guidance. This could include folks specializing in risk or physical security, our PR team, the legal team or any subject matter experts from whatever whatever area is necessary at the time. And the need for roles is going to vary by not only the organization but the incident type. So we'll certainly have permanent dedicated roles, the incident handlers, the investigators, forensic experts, IT security specialists, and we may have temporary roles as well. So legal, PR, HR, risk management, business representatives, they're going to step in temporarily for specific response actions or opinions or decisions. And some of those permanent those dedicated roles may be outsourced. For example, forensic experts may be in short supply in a smaller company. So we may outsource and contract that expertise from outside the organization. And some of your cyber insurers will actually require notification or potentially some role in or control over communication during an incident. I've actually seen situations in the real world where the insurer requires when an incident has been declared that they are contacted so they can manage communication.

So the response team does need more than just technical expertise. There are certainly those technical skills that are important and some of that conceptual knowledge we talked about, but soft skills are going to be important and this will vary by role but would include communication, leadership, presentation skills potentially. Certainly teamwork, integrity, stress management, problem solving, time management, all good skills for someone working in a time-sensitive role under stressful circumstances. Technical skills will include understanding enterprise systems, the security tools we're working with like the SIM, EDR, XDR, etc. Understanding incident handling methodologies during the different phases, the different operations, containment, eradication, and recovery. You should understand the difference between all three of these for the exam. They're not specific to an incident response framework. And we will discuss all three at length in this session. So you'll know what you need to know before we wrap up here.

So let's talk user awareness, education, and the audit function. So in terms of security awareness programs, we need to emphasize user awareness. Our users are our first line of defense and regular training is important to ensure they are up to date on the latest threats. They should be familiar with fishing attacks, safe browsing techniques, handling our sensitive data securely, and we want to keep that content updated for new threats. For example, we see a lot of talk about the role of AI in security and how attackers are leveraging AI to threaten our organization. So, the content needs to be updated frequently. I like a quarterly cadence for user awareness training. Some organizations will only do it semianually or annually. Not enough in my opinion. But enough of that. Skills assessment. So identifying knowledge gaps within the organization. Understanding where our people need additional role specific training. So we can come in and address those identified gaps. We may use external expertise if needed. It's okay if we don't have the skills inhouse to train that user. We can bring in someone from outside the organization to meet the need. We need to know what we don't know, what we are and are not capable of within our organization. Audits or assessments can verify the effectiveness of our incident management processes, our compliance, our readiness. They can help us to identify gaps for improvement. So, I'm really using that term audit loosely. It could be an internal assessment, but the idea is to identify gaps in our process and our knowledge so we can improve. We can make sure everyone has the skills they need on game day.

All right, let's put what we've learned here to the test with a practice question. So when a possible breach of an organization's IT system is reported, what should be the first action taken by the incident response manager? Is it one to validate the incident? Two, run a port scan on the system, three disable the loon ID, or d investigate the system logs. Okay, so we always need to make sure we know what we're being asked. So, two things are important here. We see what should be the first action taken by the incident response manager and you see it. It mentions when a possible breach has been reported. So, we can cross a couple of things off the list right away. Running a port scan doesn't make sense when we've had a possible breach reported. That's quite a specific action. We're disabling a Loon on ID. That's now potentially interrupting someone's work. That's never going to be the first step. Frequently on the CISM exam, we're going to notice that there is some validation or decision type action before some consideration before we just jump in and take action. So, we can validate the incident or we can investigate the system logs. These are all important activities, but it's really down to which should be first. And so there's really only one right answer here, and that is to validate the incident. So when investigating a possible incident, it should be validated as a live incident. So running a port scan on the system, investigating the logs, disabling the loon ids once the event has been validated are all useful, but there none of those are going to be the first thing we do. So point being, our first step is going to be to do the triage to make sure we have a live incident here.

All right, my friends, that brings us to section 4B2, incident investigation and evaluation. So here we'll touch on response and recovery plans, some foundational concepts. This is going to be a short one. So let's jump in here because every incident includes events, but not every event is an incident. So let's talk about the difference between the two. So an event is any occurrence a login file access a process and you know most events are going to be normal activity. Most events are not anything to be concerned about. An incident on the other hand is an event with potential or actual negative impact on the business or security posture. An incident requires investigation and response. But there's your key difference. Events are normal activity. Incidents are something that require additional investigation and response because they are potential malicious activity or breach. But context is everything. So for example, a login at 3:00 a.m. might be an incident, but it's going to be perfectly normal if the user is traveling. For example, in a live environment, I remember while we were actually in a security meeting, someone received an alert from a user logging on from the Bahamas, which seemed really strange given that person worked in New York. So, they actually stopped what they were doing and called the person and said, "Hey, Don, what are you up to?" And he said, "I'm sitting on the beach in the Bahamas. What do you need?" Well, so he was just checking his email from the Bahamas, but it was a potential incident, so it required a response. In that case, a very simple check. And because context is everything, we have to evaluate events against baselines of normal activity. And when we see a deviation outside of the baseline, we're going to investigate a bit further. It could be as simple as a phone call. It might, on the other hand, require deeper investigation if it's a more technical issue. The decision point is where we will classify an event as an incident based on the potential impact. After we gather relevant information, we validate.

So response and recovery plans must be tested prior to a live incident. Much like disaster recovery plans, as we've talked about, to ensure the incident response team is prepared to execute when the time comes. Real incidents mean potential chaos. plans need to be tested under realistic conditions. Untested plans will fail. You don't want to wait for a real crisis to discover flaws in your plans. So, preparation is absolutely important. Anticipating potential incidents, whether those are cyber incidents, physical security issues. We need well-prepared tested plans for all of these and coordination will be necessary. designating a facilitator or a coordinator to oversee execution, communicate with leadership and make timely decisions. That's your incident response manager or information security manager or you know potentially one person holding both of those roles. But we want to ensure that we have documented practiced response and recovery strategies for different incident types before the time to execute them comes. So you do want to be familiar with a few different areas when you're interpreting questions on this exam. So investigation types we need to touch on admin investigation criminal civil regulatory and industry or industry standard investigations eiscocovery evidence so evidence types evidence rules admissibility the chain of custody the most important element of evidence handling digital forensics I want to make sure that you understand the difference between eiscocovery and digital forensics.

So, let's start with types of investigations. These are pretty straightforward at the end of the day. So, we have administrative investigations that focus on policy violations like employee conduct, for example. We have criminal investigations that are led by law enforcement. They follow strict legal procedures for court evidence that lead to criminal penalties potentially. Civil investigations, which are related to lawsuits, gathering evidence for liability, typically in the form of monetary damages, is what we'll see come out of a civil investigation and subsequent civil trial. Regulatory investigations, which ensure compliance with laws or regulations. These would be around regulations like HIPPA, GDPR, or even contractual standards like PCI, DSS. and industry standards would check adherence to non-regulatory best practices or codes. That would be the least likely of the five to come up.

So let's talk eiscocovery. Eiscovery is the process to identify, preserve, collect, review, and produce electronically stored information for legal or regulatory request. It often follows the electronic discovery reference model which is a standard for eiscocovery. You can read more about it on the EDRM website. It's not going to be tested on the CISM exam. But the focus of eiscocovery is gathering potentially relevant data. It usually does not involve deep technical analysis. It's more about collecting the requested data. So personnel involved in eiscocovery uh can often be just generally trained IT staff or legal support following procedures. They don't have to have deep technical expertise to perform eiscocovery. They're often performing queries with tools that have already indexed data. So they may be just querying across email and document data to gather the requested information meeting a set of search criteria.

So digital forensics on the other hand is a specialized field that involves scientific methods to collect, preserve, analyze and present digital evidence. So definitely a different focus here. So the focus here is often on recovering data including deleted or hidden data, analyzing system artifacts, determining how something happened, preserving evidence integrity for court. So your personnel in the digital forensic space require specialized training tools and expertise. There is a relationship to eiscocovery though because forensics often supports eiscocovery by extracting data in a verifiable manner. So the goal of digital forensic is to collect, preserve and analyze digital evidence correctly for use in a legal process and to preserve the integrity of original evidence for court. So typically that means we will gather and preserve the original unaltered and work on copies of that evidence. Key activities would include preservation. So using write blockers, creating bitby-bit copies or images of a system, calculating hashes to ensure integrity and securely storing the evidence that we have captured analysis. So we might be examining memory. So volatile data, storage media, network traffic, software and malware. So right there you can see some evidence here is volatile. So for example, potential information in memory or in network traffic is going to be volatile. It's going to disappear when a system is powered down. So a digital forensics specialist would know the order of volatility and which evidence they need to go gather first. and they will meticulously log all actions. So considerations here would include being aware of anti-forensic techniques like booby traps or remote wipe put in place by the bad actors, encryption, data sovereignty, legal jurisdiction. They will generally understand any important regulatory items that will guide their efforts to ensure that everything they do to preserve the integrity of this evidence and to put together to reconstruct the sequence of events meets the requirements for the legal jurisdiction where the evidence will be used. But let's go a bit deeper on this though. So let's talk about preservation. So that I said the data needs to be preserved in its original state so it can be produced as evidence in court. So original data has to remain unaltered and pristine as we often say it. So what is a forensic copy? Well, it's an exact sector by sector copy of a hard disk or other storage device taken using specialized software preserving an exact copy of the original disc. That will include deleted files, slack space, system files, executables, documents that have been renamed to mimic system files and executable. They're all part of a forensic image. And we'll use hashes to make sure that the integrity of any copies we make remains intact. So a hash performed before and after collection and examination tells us that it remains intact. Putting a copy of the most vital evidence in a worm drive, write once, read many, will prevent any tampering with the evidence because you cannot delete data from a worm drive. You could also write protect or put a legal hold on some types of cloud storage for example.

So eiscocovery on the other hand is really about identifying, preserving, collecting and and producing that evidence. It's not about the examination. The digital forensics process involves the identifying, the preservation, analyzing and reporting. So that's really digging into and investigating the details of a potential incident where eiscocovery can be just a very ordinary situation that may be tied to a potential legal proceeding, but it also could be something much more mundane. So, we could have eiscocovery related to bad employee behavior. We need to go look and identify Sam's recent activities in email and files because we think he may have uploaded sensitive information to his personal cloud drive or he may have deleted files in bulk, for example. And so eiscocovery might be just gathering information in documents or logs and putting that into a case so it can be used by HR or legal or whomever. But during eiscocovery for example your cloud service providers might be subpoenaed to allow collection review and interpretation of electronic documents and data. generally not necessary because your cloud service providers generally give you the capability to search across the important data in your environment. If we need to go across the boundary of shared responsibility into something managed by the cloud service provider, then there may be a need to step outside there. But to get down to the bottom line in terms of the difference between digital forensics and eiscocovery is forensics involves the use of a forensic expert to protect data integrity to copy, capture, recover that data stored on a device, especially data that might be deleted or hidden or otherwise obiscated. Eiscocovery firms typically don't analyze the data they collect at any depth. It's really more about just capturing that data and maintaining it for whatever proceeding is coming. Forensic investigators have specialized training that enable them to analyze data and they have expertise in protecting data integrity and andor recovering missing or deleted data. But eiscocovery is like I say just about gathering the data.

So what does all of this roll into? Well, with eiscocovery, it might roll into a legal hold where we're protecting any documents that can be used in evidence from being altered or destroyed. This is sometimes called a litigation hold. Two ways of saying the same thing. It's really a core concept of eiscocovery.

So, I want to go a bit deeper on some evidence related concepts including chain of custody. So, chain of custody tracks the movement of evidence through its collection, safeguarding and analysis life cycle. It documents each person who handled the evidence, the date or time it was collected or transferred and the purpose for the transfer. So if anyone looks at that data, moves that data, touches that data, we have a clear chain of custody, every every bit of movement or interaction with that data and a clear reason for why it happened. It confirms appropriate collection, storage, and handling throughout its life from end to end to the day it is used in court. So evidence is any information that's proving or disproving facts. These can be logs, files, hardware, or any other variety of of elements. Let's talk about the types of evidence. We'll just get into this. So we have re what we call real evidence, physical evidence, testimonial evidence which are witness statements, documentary evidence or written records, demonstrative evidence, so visual aid. And there are rules of evidence that are applied in a legal proceeding. We're talking about rules of evidence as they apply in a US court of law. So, there's best evidence, which would mean we prefer original documents over copies. There's the parole evidence rule, which says that a written agreement usually overrides prior verbal discussions. It's called the parole evidence rule. It's a legal principle that prohibits parties from introducing extrinsic evidence like prior oral agreements or written statements that contradict the written contract. So that's not to be confused with a prisoner receiving parole where they are allowed to be released from prison. So the parole evidence rule it's called. There's hearsay evidence which are outofc court statements. They're generally not admissible. There are certainly some exceptions. So this would generally refer to secondhand information. For example, a witness says Susan told me Tom was in town and this is offered to prove that Tom was actually in town. That would be considered hearsay evidence. So different types of evidence. There's best evidence which is the original. Secondary evidence is a copy of that original. Direct evidence proves or disproves an act based on the five senses. Conclusive evidence is incontrovertible. It overrides all other types. Circumstantial evidence is evidence that can infer an act or a crime from other information. So, for example, conclusive evidence would be video footage of John stealing the computer. Circumstantial evidence would be that when the police visited his home, they found the computer in John's house, but they wouldn't necessarily be able to directly prove that he is the one who put the computer in his house. There is corroborative evidence. It's evidence that corroborates or supports other evidence but it can't stand on its own. We can introduce opinions. So both expert and non-expert opinions. We talked about hearsay. Basically verbal evidence generally not based on firsthand knowledge.

So let's talk chain of custody at greater depth. So chain of custody I mentioned refers to the documentation and tracking of evidence from the moment it's collected until it is presented in court or disposed of. So this will include chronological documentation. So a detailed record of where the evidence was, who handled it and when at every step from the initial collection to final disposition to the moment it is presented in that courtroom. preservation of that evidence. Ensuring that evidence is properly stored and or protected from tampering or contamination. Transfer accountability, so recording every time the evidence changes hands, including the reason for that transfer. Access control, limiting and documenting who has access to the evidence. So in a police station for example, any evidence will generally be locked away and there will be someone at a counter or a desk who can check that evidence in and out and record that transfer. And then there's the element of integrity. So maintaining integrity, proving that the evidence presented in court is the same evidence that was initially collected and has not been altered. It ensures integrity, security and traceability of evidence.

So let's talk about evidence admissibility. So the requirements for evidence to be admissible to be allowed that is in a court of law. So to be admissible, evidence must be relevant to a fact or issue in the case. The fact must be material to the case. The evidence must be competent or that is to say legally collected. Evidence is considered competent if it complies with certain traditional notions of reliability. But bottom line, if you hear competent, we're really talking about evidence that was legally collected. And if the chain of custody is broken, evidence is generally thrown out. It's not allowed.

All right. So, we've covered a lot of ground here. Let's test our knowledge with a practice question. If an organization is considering legal action for a security incident on what should the information security manager primarily focus disconnecting all IT equipment involved. So that could certainly be important. Making sure there are no changes to that equipment. Reconstructing the sequence of events also certainly important. Obtaining evidence as soon as possible or D preserving the integrity of this evidence. So where should the security manager primarily focus? Well, there are a couple of things we can knock off the list here because they're definitely not the most important thing regardless of their importance. So disconnecting all IT equipment, not the first step. That's taking an action without potentially some investigation. Uh reconstructing the sequence of events. That's a forensic activity. Also not the most important focus of the information security manager. We also have to remember ro appropriate answers here. Right? So the answer in this case obtaining evidence as soon as possible or preserving the integrity of the evidence. So think about the role of the information security manager as we've discussed it and the answer here is D. Preserving the integrity of the evidence. So the integrity of the evidence is of paramount importance. So following the appropriate forensic techniques to obtain the evidence and a chain of custody procedure to maintain the evidence otherwise it won't be admissible. It won't be accepted in a court of law. So that's really going to be the focus of the information security manager.

All right, that brings us to 4B3, incident containment method. This is a quick one. We'll be focused on the decision to initiate containment. And containment is one of those key terms I mentioned you should know well for exam day. So what is containment? Well, it's immediate action to limit or reduce security incident impact. It's short-term and tactical. It does not fix the root cause. So, let me give you an analogy. Containment is like in an accident situation applying a tourniquet to a wound. It stops the immediate bleeding, but it doesn't heal the wound itself. So key considerations before acting, before initiating containment, we want to tailor the strategy to the specific incident. We want to weigh the benefits, basically stopping damage versus the risk of alerting the attacker of potential escalation. It's critical that we obtain senior management approval for when and how to contain. they really must understand the risks and make a business decision. So, common containment activities, notifying stakeholders and escalating appropriately, capturing volatile memory data before shutdown or disconnection because it's volatile data that will disappear when we shut that system down. performing enterprisewide password resets, updating firewall rules, blocking malicious IPs or domains on our firewall, for example, updating our intrusion detection system signatures, so adding new indicators of compromise. collecting and analyzing logs. So, scoping our incident, really understanding what happened, creating forensic images of affected systems, reverse engineering malware to help understand its function, isolating a system that's been affected. So for example, removing it physically from the network or in some modern EDR XDR software, we can push a button in a portal to isolate that system and entirely prevent any communication or maybe just limit it to core messaging functions. So let me give you an example of system compromise containment. So we might disconnect the infected system from the network, update firewalls to to block attacker IPs and domains, scan the other systems for indicators of compromise to see if there's been any lateral movement. The goal here is to remove attacker access everywhere and to prevent further spread. We're containing the damage. the decision to contain. The focus here is a balance between stopping damage now versus the risk of attacker reaction. So who decides? Well, generally speaking, that's senior management, but with input from legal, the information security manager, the incident management team, potentially experts within the incident response team, so they can strike that balance of, you know, can we safely stop the damage here without a high probability of triggering additional attack or reaction. So the key takeaway here is containment is a critical riskbased decision requiring management approval before the action to limit immediate damage understanding it might alert the adversary.

All right, that brings us to the end of 4B3. Let's test our knowledge with a practice question. What should be the top priority when responding to a major security incident? Is it restoration, containment, documentation, or monitoring? So, what is the top priority? So, there are a couple we can knock out here right away. So, documentation definitely not the top priority. Documentation is helpful, you know, when we're thinking about reconstructing the sequence of events potentially for later legal proceedings. But in the heat of an incident, documentation is not the top consideration, nor is monitoring. So that leaves us with restoration and containment both important. I think you can guess the answer based on where we are. The question will be why. So containment, this is the first priority when responding to an incident because we want to limit the impact. Documentation, monitoring, and restoration are all important, but they should follow containment. The first step is always going to be to validate that incident and contain so we can limit the damage.

It brings us to section 4B4, incident response communication. So we'll talk about notification requirements and some considerations around our communication networks. So incident response communication keeps our stakeholders informed so they can respond effectively. They have the information they need to make decisions and it ensures business continuity. And we have to remember different audiences internal, external, technical, business need different information and different methods of communication. So the communication plan needs to be defined in advance and it should include who needs the information whether those are internal teams, management, legal, PR, external partners, customers, regulators or insurance company. what level of detail we need for each audience. So, we're going to tailor that communication to our audience and how we communicate, whether that's voice, text messages, email, secure chat, some sort of web dashboard, out of bandan channels in case our primary channels are unavailable, but we're tailoring everything about this, including the frequency of updates. So the technical team is probably going to be on a bridge on a team call where they can all communicate in real time where our business executives may prefer an occasional email at regular intervals or text messages. But the how, what, and when will be tailored to each of these audiences. So the keys to effective incident communication include establishing clear authorized channels. This avoids confusion and misinformation. We want to designate a single source of truth. This prevents speculation and conflicting messages. If we know the authorized channel and the who is delivering that information, then there's no confusion about the current and correct information. We want to ensure responders know who provides official updates, how and when they get them. And we want to use secure outofband channels if standard channels like email might be compromised. And we want to integrate and test. So, communication plans are part of our incident response or disaster recovery plan. We want to test it during exercises using templates and pre-approved contact lists. So, notification requirements should be developed and documented as part of the incident response plan. We want to maintain a contact list, a directory that includes our key internal contacts, incident response team, management, subject matter experts, potentially legal, for example, external contacts, vendors, suppliers, recovery sites, off-site storage, insurance, regulators, HR, law enforcement, anyone who needs to be apprised of the current circumstances or advanced notice of our recovery operation needs. Ensure redundancy. We need multiple contact methods for each entry. Phone, cell, text, email, etc. So if a primary channel is down, we have a fall back.

So some additional critical considerations in incident response communications include triggers and timing. So, these are going to be driven by potentially regulations like GDPR or HIPPA or potentially through legal advice, insurer requirements, our public relations strategy. If we're communicating to external parties, we need to know our reporting deadlines. For example, GDPR has a breach notification of 72 hours. Then there are law enforcement contacts to consider in some cases. So senior management make the decision when it comes to law enforcement. Information security does not contact law enforcement without authorization from business leadership. Outsource communication. So we want to ensure processes are integrated if we're using a third-party notification service. And this would again come down to redundancy as well because maybe we have some sort of impact where that third party service is not available.

So here's a breakdown from a slightly different perspective addressing considerations across internal and external stakeholders. So we have the response team. We need secure real-time channels for coordination. Many times you're going to have an incident bridge call where everybody can join and communicate in real time. So your incident response team or disaster recovery team etc. Management will need regular status updates, impact summaries, and business language that gives them the information they need to make riskbased decisions. The wider company, just having general awareness, for example, of a scheduled test will minimize confusion. Then our customers or the general public, we need controlled proactive updates on service impact or restoration if applicable. Think about the types of communication you get if there's a power outage or your cable service is down for your internet. Those types of services will often give you a periodic text message that just apprises you of updated status of estimated recovery time. Then regulators, there may be formal notification requirements in different regulations that you should be aware of. But the incident response plan must detail how the organization will maintain or restore the communications network during an incident. So we want to plan for telecom continuity. So addressing voice, WAN, LAN and third party networks, identifying vulnerabilities, so central office issues, cable cuts, software errors, security breaches, and having backups. We don't want to rely solely on carriers. We need alternatives satellite, wireless, etc. So we have connectivity under circumstances where our primary channels may be down power. So ensuring we have UPS to cover graceful shutdown of our telecom gear. Key takeaways here. We need a predefined tested communication plan with clear authority, secure channels, and stakeholder specific messaging tailored to our audience.

All right, my friends, that brings us to the end of 4B4. Let's test our knowledge with a practice question. When clear evidence of a hacker penetrating the corporate network and modifying customer information is found, who should the information security manager notify first? Customers who may be impacted? Is it B data owners who may be impacted? C. the information security steering committee or D regulatory agencies overseeing privacy. So we have evidence of a hacker penetrating the corporate network and modifying customer information. So when we have evidence of compromise, who should be notified first? Well, when we look at our options here, we know definitely it's not customers. We're not going to notify external parties before internal parties. And that goes for regulatory agencies as well. They're also an external party, right? So we have data owners who may be impacted or the information security steering committee. So both plausible answers. One is objectively better than the other. The answer here is data owners who may be impacted. They should be notified first so they can take steps to determine the extent of the damage and coordinate a plan for corrective action with the incident response team. Other parties are going to be notified later as required by corporate policy and regulatory requirements. We'll certainly notify our business leadership so they can make timely riskbased decisions. But our first contact is going to be to that data owner so we can validate and contain

All right, that brings us to section 4B5, incident eradication and recovery. Two of those other terms along with containment that I mentioned would be very important for you to understand well on exam day. So here we'll focus on the eradication phase and the recovery phase. So really the difference between eradication and recovery will be important for exam day. So let's talk about eradication versus containment. So containment is where we stop the immediate spread. We put out the fire. Eradication is where we remove the cause and the artifacts like fixing the faulty wiring. The goal of eradication is to prevent recurrence where containment was about stopping the immediate spread, containing and limiting the damage. So the key terms here for the incident management portion of the exam is you should know these terms and where they occur in the incident management process. So think about the general process flow, not about specific incident response frameworks or standards. You're not going to be tested on that type of wrote memorization. So let's touch on some key terms here. There's triage, which is the initial assessment and prioritization. Containment where we limit the spread. Mitigation reducing severity and starting the repair actions. Eradication removing incident artifacts, the malware, back doors, the the causal factors. Remediation, where we're fixing the underlying cause, patching a vulnerability, for example. And recovery, where we restore systems to normal, secure operations. We're returning to business as usual. In recovery, the primary goal of the eradication phase is to remove all artifacts of the incident from the organization's network. Common activities to eradicate a security incident would include performing root cause analysis, understanding why it happened, cleanup, removing malicious files, back doors, bad configurations, patching systems, closing down those exploited vulnerabilities, implementing blocks, DNS sinkholes, updating our firewall and intrusion detection system rules, scanning thoroughly to find any remaining indicators of compromise. Remember, we're trying to prevent recurrence here. And if we have a compromised system, often times the best option is to wipe and rebuild so we have a clean system state. We always want to restore from clean backups. We want to use trusted backups from before the incident so we're not potentially restoring compromised files. So bottom line, incident response phases will vary by incident response standard and framework. So whether that's from NIST or SANS or someone else, we'll talk a bit about these in section 4B6, but you really want to focus on understanding the flow that we've talked about here. You don't need to to memorize any specific incident response standards. I'm really trying to give you the key information that aligns with how Isaka covers this from their perspective for their exam.

So, some exam questions might focus on secure disposition of media. That would likely come, I think, from NIST special publication 800-88, which covers guidelines for media sanitization. So, what we're really talking about here is secure eraser or deletion. So NIST defines three methods in this case. So if we look at those from least secure to most secure, we have clearing data which is logical overwrite. That's basic data removal. There's purge which is advanced logical or physical methods making lab recovery infeasible. So crypto shredding would be an example. And then there's destruction, physical destruction where the media is completely unusable. So remember for the exam we want to preserve forensic evidence and we need to maintain its integrity throughout the process and we want to ensure complete removal before recovery. And these methods could come up in the secure data life cycle as well but I wanted to get these three terms out there in case they should pop up on the exam. So let's talk about the recovery phase.

So it's critical that we perform recovery after successful containment and eradication. The goal is to restore operations without reintroducing vulnerabilities. And that's a key decision point there, without reintroducing vulnerabilities. Which means we don't want to rush the process. Hidden threats like back doors and root kits may persist if our recovery is rushed. Properly addressing and remediating the root cause is going to be essential for long-term risk management. So before returning to business as usual, we need to make absolutely sure we have eliminated that root cause. And the exam might actually test your ability to recognize the danger of returning to business as usual too quickly. So be on the lookout for that.

So typical recovery activities would include validating our security baseline, confirming patches, configurations, and controls are in place and configured correctly, monitoring very closely, watching for returning indicators of compromise or new indicators of attack. Proactive hunting, so searching for any missed adversary artifacts and controlled reintroduction. So bringing systems back online only after verification when we know they're clean and functional.

So just some final cautions and key takeaways here. When returning to business as usual without fixing the root cause, it's going to invite repeat incidents. So root cause analysis is essential for both thorough eradication. So finding all attack vectors and artifacts and for secure recovery, avoiding rebuilding vulnerable systems with the vulnerabilities remaining. Key takeaways here. Eradication removes the threat and its cause. Recovery restores operations securely. Both rely on our thoroughness, root cause analysis, and careful validation before returning systems to production. So remember the secure media sanitization terms and forensic preservation concepts we talked about.

All right, that brings us to the end of section 4B5. I want to test your knowledge with a practice question. So, which activity is most likely to increase the difficulty of completely eradicating undetected malicious code? Is it performing a file backup, changing access rules, applying patches, or upgrading hardware? So which activity is most likely to increase the difficulty of completely eradicating undetected malicious code? So which of these activities is going to make it difficult for us to ensure we've completely eradicated malicious code? So when I'm thinking about eradicating files, changing access rules, probably not the most important of these. And upgrading hardware has nothing to do with it. So, performing a file backup or applying patches, which would make it most likely to increase the difficulty, these are both pretty good options. One has a slight edge over the other, and it's performing a file backup. And the reasoning behind it is that if malicious code is not immediately detected, it will most likely be backed up eventually as part of the normal backup process. And while the code might be eradicated from the device somewhere within the incident response process in the eradication effort, it might still remain undetected on a backup, leaving risk of reintroducing the malicious code.

All right, my friends, that brings us to our final section 4B6 post incident review practices. So here post incident, we'll focus on identifying causes and corrective actions, documenting events, establishing legal procedures to assist in post incident activities. We'll touch on requirements for evidence. Really going to be just a quick review for you here and the legal aspects of forensic evidence. So again, just a review. We've already covered this pretty well, but we'll polish this off and make sure you're ready for exam day. So the purpose of post incident review is to capture lessons learned, refine our processes where we see room for improvement, justifying resources to facilitate any improvement activities and to improve our overall security.

So key post incident activities, we want to thoroughly document the incident and response steps. Gather feedback from all involved stakeholders. We want to learn from everyone's perspective what we did right and wrong, whether it's reality or perception. Produce a final report for senior management. Identify process failures and required changes so we can update our procedures. Develop a remediation plan to address the root cause and secure funding and resources for necessary improvements. So the benefits of effective follow-up, well, lessons learned. So and we analyze our successes and failures to strengthen future incident response. Cost calculation. So quantifying incident impact. This supports our budget needs and our budget request and potential legal evidence. There's a proactive shift here. Improved processes reduce reaction time in the future, allowing focus on prevention and driving the review. The information security manager should be the one coordinating the process. This may involve third-party forensic experts if needed, of course, because the information security manager isn't expected to be the all-knowing expert, but they are facilitating, coordinating, and serving as that liaison between the technology and business units.

So, identifying root cause and corrective actions. So analyzing incident sources, external or internal attacks, control failures, asking the key questions, who, what, where, when, why, and how. So the review team typically asks questions like who was involved, what exactly happened, where did the attack originate, when did it occur, and over what time frame? Really getting a a picture of the end to end sequence of events. Why did it happen? Where was our failure? How was the system vulnerable? And was there a specific motivation behind the attack? So the goal here is to identify causes and recommend specific actions to prevent recurrence.

So documentation, as I mentioned, very important, non-negotiable. Accurate detailed records are very important during and after the incident. These will support investigations, legal actions, clarify intent, give us information that will support our future improvements. We want to assign a dedicated role for documentation if possible. Having at least one individual in charge of documentation and evidence preservation, ensures consistency and accuracy. So having one person handle that for a particular incident is generally a good idea for consistency. Think of a security incident like a burglary at your facility. If everyone rushes in, moving objects and cleaning up immediately, not coordinating, crucial evidence can be lost or tainted. So, assigning a specific person to document the scene preserves vital information for investigators. There's a reason on those detective shows you see on television that they don't allow anyone to come in and touch the crime scene before the detectives come in and do their work. Their forensic activities.

So legal integration is very important. So involving legal counsel early, especially for breaches or in regulated industries. Legal input is going to be needed for incident response plan development and testing over time, our response strategy, particularly when there are external parties involved or the possibility of legal action. They can get involved in notifications, again, particularly for external parties and when we have regulatory requirements for attorney client privilege considerations. But incident response plans must define roles, documentation steps, communication protocols, including legal and law enforcement, and we need clear decision points in there. Remember we mentioned that information security never contacts law enforcement without approval from senior management and typically pre-approved notification templates are important, especially for external communications and particularly when regulatory standards are involved. So improper handling destroys evidence and its admissibility in court.

So remember the preservation policy. The information security manager defines the approach. For example, powering a system off versus live memory capture. So the volatility of evidence and the staff handling that preservation must be trained in evidence preservation. Again, the information security manager can coordinate the approach, but they may need to bring in specialists, whether those are internal or externally contracted. Forensic imaging, so using sound tools, write blockers, verifying hashes, before and after capture, securing the original media. So, preserve the original, work with copies is the general rule. And then the chain of custody. We want to meticulously document evidence handling. Who touched it, what they touched, when they touched it, and why they were doing so. Remember, also secure media sanitization terms and forensic preservation. I think you're pretty well indoctrinated in those.

Now then, just to round this out, remember comprehensive documentation. We want to use forms, logs and checklists for legal admissibility. So consistency and completeness will be important. And then evidence retention. So following internal and external policies, consulting legal before discarding evidence if litigation is possible. The the final goal here is to integrate findings into stronger security controls, updated policies and procedures, and better training. So, key takeaways for exam day, focus on lessons learned translating into tangible improvements, whether that's policy, training, process, etc. We want to link review findings to continuous improvement and risk management. And remember the role of legal counsel when we talked about attorney client privilege or notifications, preservation of evidence. They're going to be well-versed in all the above and no forensic evidence handling requirements, imaging, chain of custody, etc. Everything we covered here should be more than you need to know for exam day. And remember, post incident review drives the cycle of security improvement. Continuous improvement is the goal.

All right, my friends, that brings us to the end of 4B6. Let's finish it off with a practice question. What is the primary objective of conducting a post incident review? Is it to identify new incident management tools? B. Develop a business case for the security program budget. We talked about needing budget for potential improvements, right? C. Capture lessons learned to improve the process. or D. Develop a process for continuous improvement. So they're asking us what is the primary objectives. All of these objectives factor to some degree in our post incident review efforts. Which is the primary? Well, there's one I can knock off here because I know it's secondary. Developing a business case for the security program budget would come after we've identified where we need to make improvements and what those improvements look like. So the process of post incident review is geared toward helping us to improve our response in the future. It's not the primary objective. So that leaves us identifying new incident management tools or capturing lessons learned to improve the process. I bet you know the answer here at C. capturing lessons learned to improve the process because that is the main purpose of our post incident review is to identify areas of improvement in the process. Developing the business case for budget and identifying tools may come from analysis, but they're not our primary objectives here.

All right, my friends, that's what I have for you in domain 4 part B. I hope you enjoyed the series. If you have questions as you're preparing for the exam, as always, drop me a question in the comments. Reach out on LinkedIn. Happy to help anywhere I can. I'll look forward to seeing you back on the channel when I roll the series up into that consolidated full course video. And I'll wish you best of luck on the exam. Until we meet again, take care and stay safe.