Going Deeper Into Security Operations
The first course gave me a wider understanding of what cybersecurity actually is and what a security analyst is responsible for. This course felt different because instead of introducing me to the field, it started showing me how organizations actually manage security risks and how analysts work around them.
A lot of the concepts here were new to me, especially when it came to frameworks, security controls, SIEM tools, logs, dashboards, and playbooks. This time I wasn't really comparing them to things I already knew. I was mostly trying to understand how these different parts connect and how I would actually use them if I were working as a security analyst.
Managing Security Through Frameworks and Controls
One of the biggest things I learned from this course was that cybersecurity inside an organization needs more structure than simply finding vulnerabilities and fixing them.
Frameworks provide that structure.
The NIST Cybersecurity Framework helped me understand this more clearly. Instead of treating security as one large problem, it gives an organization a way to organize its security activities around Identify, Protect, Detect, Respond, and Recover.
What makes more sense to me now is that these functions are connected. An organization cannot properly protect something if it does not know what assets it has. Detection depends on having the right monitoring and controls in place, while response and recovery depend on having processes prepared before an incident happens.
The course also went deeper into security controls, which made frameworks feel more practical to me. Controls are the actual safeguards used to reduce risks. Things such as access controls, password policies, encryption, firewalls, backups, antivirus, monitoring, and physical security are examples of controls that can be implemented to protect an organization.
This gave me a better way to think about frameworks.
A framework can tell an organization what areas need attention, while controls are the actual measures used to address those risks.
I also encountered security principles and organizations such as NIST and OWASP, which showed me that cybersecurity is not based on one universal checklist. Different organizations and frameworks provide guidance for different security concerns, but they all help organizations approach security in a more structured way.
The CISSP security domains also helped me look at cybersecurity more broadly. Security does not only involve networks and computers. It also includes things such as risk management, assets, access, operations, software, communication, and how security itself is tested and maintained.
I don't think I need to memorize every domain just for the sake of memorizing them. What matters more to me is understanding that when working in cybersecurity, a problem can come from almost anywhere in an organization. A vulnerability could be technical, but it could also come from bad access management, weak policies, poor asset management, or even how software was developed.
Putting the Framework Into Practice
The part that made the frameworks and controls feel more real was the internal security audit activity.
Instead of simply learning what security controls were, I had to use them to evaluate a fictional organization, Botium Toys, and determine whether the company currently had specific controls and compliance practices in place.
The audit required me to look at the organization's assets and risk assessment, then use that information to work through a controls and compliance checklist.
I had to consider controls such as least privilege, disaster recovery, password policies, separation of duties, firewalls, intrusion detection, backups, antivirus, encryption, password management, physical security, and monitoring.
The audit also introduced a different side of security that I had not focused on as much before: compliance.
The checklist connected the organization's security posture to requirements such as PCI DSS, GDPR, and SOC, including protection of payment information, encryption, secure password practices, protecting EU customer data, data classification, privacy procedures, access policies, and maintaining confidentiality, integrity, and availability.
This activity made me understand why security analysts need to think beyond individual vulnerabilities.
A company might have a firewall and antivirus installed and still have major security problems because of weak access controls, missing backups, poor password management, inadequate policies, or improperly protected sensitive data.
The audit made me look at security more from the perspective of:
What does the organization have, what risks does it face, what controls are currently in place, and what is still missing?
That is a much broader way of looking at security than simply looking for a vulnerability.
I documented the audit separately as a practical piece of work, while this journal focuses more on what the activity taught me about applying frameworks, controls, and compliance requirements.
Seeing What Is Happening Inside a System
Another big part of this course was understanding how analysts actually see what is happening inside an organization.
Almost everything a system does can produce some kind of record. A login attempt, a connection to another device, a file being accessed, a service starting, or an application failing can all leave information behind in logs.
Individually, these events might not mean much. The important part is being able to connect them.
For example, one failed login is probably normal. But if the logs suddenly show hundreds of failed login attempts from the same source, followed by a successful login, that becomes something I would want to investigate.
This is where SIEM tools, logs, dashboards, and alerts start working together.
A SIEM collects security information from different systems and puts it into one place where analysts can search through it, monitor activity, and identify patterns. Instead of manually checking the logs of every computer, firewall, server, or application separately, the analyst can use the SIEM to get a much wider view of what is happening.
The dashboard then becomes more like the analyst's overview of the environment. It can show alerts, unusual events, trends, and other information that might need attention.
What I learned from this is that an analyst probably spends a lot of time looking for context.
An alert itself does not automatically mean an attack happened. It tells me that something happened that might be worth investigating. I would then use the information available to figure out whether the activity is normal, suspicious, or actually malicious.
I imagine the process would usually start with an alert, then I would look at the related logs, compare what happened before and after the event, identify the affected system or user, and try to understand what actually happened.
Following a Process During an Incident
Another thing that became clearer to me is that analysts are not supposed to simply react however they want whenever something happens.
Organizations use playbooks, so there is already a process for handling certain security incidents.
A playbook gives the analyst a set of steps to follow when responding to an event. Depending on the situation, this might involve gathering information, confirming whether an incident actually happened, containing the problem, escalating it to someone else, documenting what happened, and eventually helping restore normal operations.
I think this becomes especially important during serious incidents.
If an organization was being attacked, that would probably be one of the worst times to start deciding from scratch what everyone should do. Having a playbook means that the response has already been thought about before the incident happens.
At the same time, I don't see a playbook as something that replaces thinking. An analyst still needs to understand what is happening and make decisions based on the situation. The playbook simply gives them a structure, so important steps are not forgotten.
I can imagine myself using it almost like a checklist during an investigation. I would still analyze the situation, but I would have something guiding me on what needs to be checked, what should be documented, and when something needs to be escalated.
What I Learned About the Analyst's Workflow
This course gave me a much clearer picture of what security monitoring and incident handling might actually look like.
I now imagine the work of an analyst as a continuous cycle of watching the environment, reviewing alerts, checking logs, investigating unusual activity, following procedures, documenting findings, and helping improve security afterward.
The frameworks tell the organization how security should be managed, while tools such as SIEM platforms, logs, and dashboards help analysts see what is happening, and playbooks help them decide what to do when something happens.
That connection is probably the most useful thing I learned from this course.
Before this, I understood these things separately. I knew what a log was, I had heard of SIEM tools, and I understood that organizations had security policies and procedures. What I did not really understand was how all of them would work together during normal security operations.
Now I can imagine it more clearly.
Something unusual happens in the environment. The activity creates logs. The SIEM collects those logs and detects something suspicious. An alert appears on the dashboard. The analyst investigates the event using the available information, determines whether it is actually a threat, and if necessary follows the appropriate playbook to respond to it.
It is a simple example, but it helped me understand what the actual work might look like.
What I Took From Course 2
What I Took From Course 2
Course 2 made cybersecurity feel less theoretical to me.
The first course helped me understand what cybersecurity protects and what a security analyst is responsible for. This course started showing me how that responsibility is actually organized and carried out inside an organization.
Security frameworks give structure to how risks are managed. Security controls turn those ideas into actual safeguards. Compliance requirements add another layer by defining how organizations should protect certain types of information and systems. Tools such as SIEM platforms, logs, alerts, and dashboards then give analysts visibility into what is happening across those environments, while playbooks give them a process to follow when something needs to be investigated or responded to.
The internal audit activity helped connect all of this for me. Instead of looking at security as individual tools or vulnerabilities, I had to look at an organization as a whole and ask what assets it has, what risks it faces, what controls are already in place, what requirements apply to it, and what gaps still need to be addressed.
The biggest thing I learned is that security analysts are constantly trying to turn information into a decision. A log is only information. An alert is only a warning. A framework is only a structure. A control is only a safeguard.
The analyst still has to look at everything together, understand what actually matters, decide what needs attention, and determine what should happen next. That is probably the part of the job that interests me the most so far.