Like I mentioned in a previous blog, I’m going to share bits and pieces of the lessons I pick up along the way as I earn my certification. I figured this is going to help me remember these valuable learnings, while giving a preview of the course discussions to would-be certificate earners. I started chronicling this journey only recently—just as I finished Course 5 (it’s an 8-course certification program)—so I will be alternating between giving insights into my current learnings and sharing about past ones.
Now on to this week’s lessons.
Course 6 of the certification, divided into four modules, is all about Detection and Incident Response. The first part (Module 1) gives an overview of the process of network monitoring, detecting security incidents, responding to incidents, and the tools used for the processes. These tools include intrusion detection systems (IDS), intrusion prevention systems (IPS), endpoint detection and response (EDR) apps, security information and incident management (SIEM) tools, and security orchestration, automation and response (SOAR) solutions.
Now that’s a load more acronyms than I can remember without consulting my notes; but believe me, when you get to know what each of these do, you’ll see how these tools can effectively help strengthen an organization’s security posture. One of these days, I’ll write a proper guide on the key differences of these tools.
So what are the most interesting things I got from this module?
For one, being a cybersecurity analyst is something akin to being a crime scene investigator. Once a security incident is detected, the incident response plan kicks into action. This means putting on your investigator’s cap, and then writing out the details—the 5 W’s of an incident investigation:
- Who triggered the incident;
- What happened;
- When the incident took place;
- Where the incident took place;
- Why the incident occurred.
Related to this, the first Course 6 activity was quite easy: writing a 5-Ws entry into the incident handler’s journal, the standard documentation for an incident investigation. It’s like the grown-up and cybersecurity version of Blue’s Clues’ handy-dandy notebook. Kidding aside, obviously, a lot more note-taking and analysis goes into investigating a security incident, hence all the tools needed.
What else stood out for me? It’s something that lecturer (and Principal Security Strategist for Google Cloud) Dave mentioned in one of the first few videos: “All security incidents are events, but not all events are security incidents.”
When you’re not yet entrenched in cybersecurity work, like us course-takers for instance, it’s easy to think that given the right tools and knowledge, discovering a potential malicious activity should be fairly straightforward. But the truth is, there could be a lot of events, i.e. observable occurrences, that can be found in logs―an employee changing a password, a legitimate user added―and these would not indicate that a security incident is happening or has happened.
I therefore believe it takes a lot of patience and attention to detail to get it right. And experience too. But then that’s something you’d have to work at to achieve…hence the need to consistently do hands-on work. It’s difficult to be trusted with that type of work though, when you don’t have the experience. It’s a vicious cycle I know.
At any rate, the good thing about the Google Cybersecurity Certification is that you’re given chances to practice the technical aspect of the job. For Course 6 for example, there are Qwiklabs activities for capturing packets using tcpdump, and examining Suricata (an IDS/IPS tool) logs, to name a few labs. So you get to do hands-on work, without the real-life repercussions of actual data breaches or DDoS attacks. You can even use the results of your lab work as additional items in your portfolio.
That’s why I can’t wait to dive into the last three modules where I get to see actual applications of the theoretical overview given in the first part. My thoughts for that would then be the Course 6 Part 2 of this blog post.
Lastly, I like how Fatima, a tech lead in Google’s Detection and Response Team, likens detection and response to a sort-of performance. Here’s how she puts it in her video:
“Working in detection is really like an artist preparing for a show. We spend all this time developing all of these signatures to detect hackers, and then one day, it’s time for the show. You get that same nervous energy and you question whether you’re ready for the performance or not, but you really don’t have a choice. The hackers are going to come and you have to be ready for them.”
Well, I better go get ready for that show. See you in the next post.