Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CISA] CISA4: Security Incident Response and Forensic Investigation
Transcript
- Hey, welcome to VoraPrep Audio. Glad you could join me. So let’s talk about that moment nobody wants to face. It’s two in the morning, and an alert fires off. Ransomware. It’s actively encrypting files on a server that runs your company’s entire shipping operation. What happens in the next few hours... that's the difference between a minor headache and a full-blown, multi-million dollar disaster that makes the news. For you, as an IS auditor, your job isn't to run in and start pulling cables. Your job is to make sure the company has a solid, well-rehearsed plan for that moment. You're assessing their resilience, because these kinds of threats? They're not an 'if,' they're a 'when.' The single most important thing to get straight on this topic is your role versus the incident response team's role. An IS auditor is like a referee in a big game. You're there to observe, to make sure the team follows the rules and plays effectively, but you never, ever grab the ball and try to score a touchdown yourself. If you jump in and start containing the incident, you've crossed a line. You’ve lost your independence. How can you objectively audit a process you were just a part of? You can't. So remember that: you are the reviewer, not the responder. This is a huge point on the CISA exam. Okay, so what does a good response look like? Most organizations follow a framework, and the one you really need to know is from the National Institute of Standards and Technology, or NIST. It breaks the whole process into four phases. The first phase is Preparation. This is all the work you do before the bad thing happens. It’s about having the fire extinguishers inspected, the escape plan posted on the wall, and everyone knowing where to meet outside. As an auditor, you'll check if they have a formal Incident Response Plan. Is there a designated team—usually called a CSIRT, or Computer Security Incident Response Team—and have they actually been trained? Are their tools, like security monitoring software, actually working? You’re asking: are they *really* ready, or is this just a plan gathering dust on a shelf? Then comes Detection and Analysis. This is the smoke alarm going off. The first job is to figure out if it's a real fire or just burnt toast. The security team has to validate the alert, figure out what’s happening, how bad it is, and how far it’s spread. When you're auditing this, you're looking at the evidence. You're reviewing the logs and the incident tickets to answer questions like: How fast did they figure out this was a real threat? Did they grasp the full impact, like what data was stolen or which systems were hit? Was there a clear process for saying, "Yep, this is a real incident, time to escalate"? Once it's declared a real incident, we move into the hands-on phase: Containment, Eradication, and Recovery. Think of it in three simple steps. First, Containment. This is all about stopping the bleeding. You have to keep the problem from getting worse. That might mean taking one laptop off the network, or maybe segmenting an entire part of the business to isolate the threat. It’s a balancing act—you have to stop the attack without completely shutting down the business if you can help it. Next is Eradication. This is where you actually remove the threat. You find the attacker's malware, you get rid of their backdoors, you kick them out and lock the door behind them. And finally, Recovery. This is about carefully bringing the cleaned systems back online and getting back to business as usual. As an auditor, you’ll be looking at the documentation later to see if their actions made sense. Was the containment effective? Did they truly get rid of the threat? Or did they just patch the obvious hole and leave a backdoor wide open? The last phase is Post-Incident Activity, and you could argue it's the most important one. This is the "lessons learned" meeting. After the fire is out and everyone's safe, the team gets together and asks the hard questions. What went wrong? Why did it happen? What weaknesses in our defenses did this attack expose? The goal is to create real, actionable steps to get stronger. Your job as the auditor is to make sure this meeting actually happens and that it leads to real change. Are they tracking the action items? Is that feedback loop actually working? Because a good organization doesn't just survive an incident; it learns from it. Now, when you see these questions on the exam, here's a simple way to break them down. First, figure out which of those four phases the scenario is in. Is it before, during, or after the incident? That's your biggest clue. Second, remember your role. Are you the auditor or the responder? The right answer for one is often the wrong answer for the other. Third, if the question asks for the *first* or *best* action during an active attack, the answer is almost always containment. Stop the damage. You don't start writing a report or analyzing the root cause when the building is on fire. You get everyone out. And finally, if the question involves evidence, you have to protect its integrity. This brings us to digital forensics. Think of digital forensics as the work a crime scene investigator does, but for computers. The number one rule is that you *never* work on the original evidence. Ever. You make a perfect, bit-for-bit copy—called a forensic image—and you do all your analysis on that copy. How do you prove the copy is perfect? With something called a hash. A hash is like a unique digital fingerprint for a file or a drive. If even one tiny bit of data changes, that fingerprint changes completely. So, you create a hash of the original hard drive, and you create a hash of your forensic image. If they match, you've got a perfect copy. You also have to maintain the chain of custody. This is just a log, a piece of paper, that documents every single person who handled the evidence, when they handled it, and why. If that chain is broken, the evidence could get thrown out in court. It's that serious. There's also a principle called the order of volatility. You collect evidence from the things that will disappear the fastest. Data in the computer's memory—the RAM—is incredibly volatile. The second you turn off the power, it's gone forever. Data on a hard drive, though, will stick around. So, you always collect the contents of RAM *before* you power down the machine to make an image of the hard drive. It's just a logical sequence of collecting the most fragile evidence first. Let's walk through a quick example. A hospital’s security system alerts that a ton of patient records are being copied to a personal cloud account by an employee on their last day. A week later, you're the auditor reviewing the report. The team did the right things. They first detected the alert and analyzed it, confirming it was sensitive patient data. Then, containment. This was their first priority. They immediately cut the employee’s network access, suspended their accounts, and blocked the cloud storage site at the firewall. They stopped the bleeding. After that, they moved to eradicate the threat by working with Legal and HR to secure the employee's devices. Later, in the post-incident meeting, they found a weakness. The system should have *blocked* that transfer, not just sent an alert. So they created an action item to fix that rule. They also decided to change the offboarding process so that access is cut *before* an employee's last day, not at the end of it. As the auditor, your main recommendation would focus on that preventive control. The response was good, but the incident shouldn't have been possible in the first place. A tempting wrong answer on an exam might be "the first step should be to wipe the employee's laptop." But you know that's wrong, right? Wiping the laptop would destroy all the evidence. The correct move is always to preserve the evidence by imaging the drive first. If the NIST phases feel like a lot to juggle, a lot of people use the mnemonic PICERL. That’s P-I-C-E-R-L. Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. It’s a slightly different breakdown, but it covers the same core ideas and can be really helpful for recall. The biggest pitfall here, and I'll say it again because it's that important, is confusing your role as an auditor with the role of the responder. If you start giving orders or reconfiguring firewalls during an incident, you've made a huge mistake that compromises your objectivity. Observe, review, and report. That’s your job. And my exam-day tip for you is simple: if you're in an active incident scenario and you need to pick the *first* action, look for the answer that contains the damage. Look for containment. So, to wrap this all up: your role as an auditor is to evaluate the incident response process, not do it. You need to know the four NIST phases, especially the importance of Preparation before an incident and Lessons Learned after. And when it comes to forensics, always protect the evidence, maintain that chain of custody, and work on a copy. Studying all these interconnected pieces is exactly what we focus on at VoraPrep. If you want to see how this all fits together with practice questions and more lessons, check out the app. VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. You can get started over at Vora Prep dot com. It's free to try. Alright, that's it for today. Keep up the great work. You've got this.