Overview
Course 2 helped me see cybersecurity less as a collection of separate tools and more as a process for understanding what needs protection, identifying what could harm it, reducing risk, monitoring for problems, and responding consistently when incidents occur.
The course moved through four main areas: security domains and risk, frameworks and controls, cybersecurity monitoring tools, and incident-response playbooks.
What I Learned
The Eight Security Domains
The CISSP security domains helped me understand how the work of cybersecurity can be organized. Instead of treating security as one large responsibility, the domains divide it into different areas of focus.
1. Security and Risk Management focuses on the organization's overall security posture, including security goals, risk reduction, compliance, business continuity, laws, and ethics.
2. Asset Security focuses on protecting and managing valuable physical and digital assets throughout their storage, maintenance, retention, and eventual destruction.
3. Security Architecture and Engineering focuses on designing systems, tools, and processes that protect data and assets. It also introduces principles such as least privilege, defense in depth, fail securely, separation of duties, and shared responsibility.
4. Communication and Network Security focuses on securing physical networks, wireless communications, and connections used in on-site, remote, and cloud environments.
5. Identity and Access Management (IAM) focuses on verifying identities and controlling who is authorized to access physical or digital assets. A major idea here is least privilege: users should receive only the access they need to perform their work.
6. Security Assessment and Testing focuses on evaluating systems and controls to discover weaknesses and determine whether security measures are actually working.
7. Security Operations focuses on monitoring, investigating, managing, and responding to security incidents. This is where logs, SIEM tools, playbooks, incident management, and lessons learned become especially important.
8. Software Development Security focuses on incorporating security throughout software design, development, testing, and release instead of treating security as something added afterward.
What helped me understand the domains is realizing that they are not completely isolated from each other. Protecting an asset might involve access management, network controls, testing, monitoring, and eventually incident response.
Assets, Threats, Vulnerabilities, and Risk
A major part of this course was learning to distinguish concepts that are closely related but mean different things.
An asset is something an organization considers valuable. It can be digital, such as personal or financial information, or physical, such as a server, workstation, or office space.
A threat is a circumstance or event that can negatively affect an asset. Threats can come from inside or outside an organization.
A vulnerability is a weakness that a threat can exploit.
A risk is the possibility of harm affecting the confidentiality, integrity, or availability of an asset. The material describes risk in terms of the likelihood of a threat.
The distinction I want to remember is:
The asset is what I care about. The threat is what could cause harm. The vulnerability is the weakness that makes the harm possible. Risk represents the possibility of that harm affecting the asset.
Organizations can deal with risk in several ways:
Acceptance — accept the risk.
Avoidance — avoid the risk altogether.
Transference — move responsibility for managing the risk to a third party.
Mitigation — reduce the impact of the risk.
This made risk management easier for me to understand. The goal is not simply to find every weakness. The organization first needs to understand its assets and risks so it can decide what action makes sense.
NIST Risk Management Framework
The NIST Risk Management Framework (RMF) provides a structured process for managing security and privacy risks.
The material introduces seven steps:
Prepare → Categorize → Select → Implement → Assess → Authorize → Monitor
Prepare means getting ready to manage security and privacy risks before something happens.
Categorize means considering how risk could affect systems and information, including confidentiality, integrity, and availability.
Select means choosing and documenting appropriate security controls.
Implement means putting the security and privacy plans into practice.
Assess means checking whether the controls were implemented correctly and are meeting the organization's needs.
Authorize involves accepting accountability for the security and privacy risks that remain.
Monitor means continuously observing systems and determining whether existing controls continue to support the organization's security goals.
The important part for me is that risk management is continuous. Implementing a control does not automatically finish the job. It still needs to be assessed and monitored.
Frameworks and Controls
I initially found frameworks and controls easy to mix together because both are used to reduce risk.
The difference is clearer now.
A security framework provides guidelines for developing security plans and managing risk.
A security control is a specific safeguard used to reduce a particular security risk.
So the framework helps answer:
“How should we organize and approach security?”
A control is closer to:
“What safeguard are we actually putting in place?”
The course introduced frameworks including the Cyber Threat Framework, ISO/IEC 27001, NIST RMF, NIST Cybersecurity Framework, and NIST SP 800-53. The Cyber Threat Framework provides common language for communicating about cyber threat activity, while ISO/IEC 27001 provides requirements and guidance for managing information security.
Controls can be grouped into three categories:
Physical controls, such as locks, guards, cameras, and access badges.
Technical controls, such as firewalls, MFA, and antivirus software.
Administrative controls, such as authorization, separation of duties, and asset classification.
The CIA Triad
The CIA triad is a model used to think about security through three goals: confidentiality, integrity, and availability.
Confidentiality means information should only be accessible to authorized users. Least privilege supports confidentiality by limiting access to only what a person needs.
Integrity means information should remain correct, authentic, and reliable.
Availability means authorized users should be able to access information and systems when they need them.
What made the CIA triad click for me is that these are not three unrelated definitions. They are three questions I can ask when thinking about an asset:
Who should be able to access it?
Can I trust that it is correct?
Can authorized people use it when they need it?
These considerations help organizations build and maintain their overall security posture.
NIST Cybersecurity Framework
The material describes the NIST Cybersecurity Framework (CSF) as a voluntary framework of standards, guidelines, and best practices for managing cybersecurity risk.
The supplied lessons explain five core functions:
Identify → Protect → Detect → Respond → Recover
Identify focuses on understanding cybersecurity risks and their effects on people and assets.
Protect involves implementing policies, procedures, training, and tools that reduce threats.
Detect focuses on discovering potential security incidents and improving monitoring.
Respond involves containing, analyzing, and addressing incidents.
Recover focuses on restoring affected systems, data, and assets to normal operation.
I see these functions as a useful high-level picture of security operations: understand the risk, protect against it, watch for problems, respond when something happens, and restore what was affected.
OWASP Security Principles
The OWASP principles showed me that secure systems are not built from one control. Security also depends on the decisions made when systems and processes are designed.
The principles covered were:
Minimize attack surface area — reduce the number of vulnerabilities and possible pathways a threat actor could exploit.
Least privilege — give users only the access required for their work.
Defense in depth — use multiple security controls so protection does not depend on a single defense.
Separation of duties — prevent one person from having enough privileges to misuse an important process alone.
Keep security simple — avoid unnecessary complexity that makes security harder to manage.
Fix security issues correctly — identify the root cause, correct vulnerabilities, and test that remediation actually worked.
The course also introduced:
Establish secure defaults — the default state of a system should already be its secure state.
Fail securely — if a security control fails, it should default to the safer option.
Don't trust services — third-party systems should not automatically be assumed to be secure.
Avoid security by obscurity — security should not depend only on keeping the design or implementation secret.
The bigger lesson for me is that good security design tries to limit what can go wrong before an incident occurs.
Security Audits
A security audit is a review of an organization's controls, policies, and procedures against defined expectations.
Those expectations can come from inside the organization, such as its policies and procedures, or from outside requirements such as laws, regulations, and compliance standards.
An audit is not just about finding failures. Its purpose is to determine whether security practices are working as expected and identify areas that need remediation.
The process introduced in the material follows a logical path:
Define the scope → Perform a risk assessment → Conduct the audit → Create a mitigation plan → Communicate the results
The scope establishes what assets and processes will be assessed. The risk assessment identifies the risks that matter. The audit examines the selected assets and controls. The mitigation plan determines how identified risks should be reduced. Finally, the findings and recommended improvements are communicated to stakeholders.
This also helped connect audits back to frameworks and controls. Frameworks provide guidance and expectations, controls provide safeguards, and audits help determine whether those safeguards and processes are actually doing what they are supposed to do.
Logs: Records of What Happened
Module 3 moved from security planning into the tools used to monitor an organization.
A log is a record of events that occur in systems and networks.
The course introduced three common sources:
Firewall logs record attempted or established incoming and outgoing network connections.
Network logs record devices entering or leaving a network and connections between devices and services.
Server logs record events related to services such as websites, email, or file sharing, including login and account requests.
Logs matter because security teams need evidence of what systems are doing. But an organization can generate far more logs than one person could realistically review manually.
That is where SIEM tools become useful.
SIEM Tools and Dashboards
A Security Information and Event Management (SIEM) tool collects and analyzes log data so security teams can monitor important activity.
Instead of forcing an analyst to manually search through every individual log source, a SIEM centralizes data, supports real-time monitoring and analysis, and can generate alerts about suspicious activity.
A SIEM dashboard presents this information using visual formats such as charts, graphs, and tables. This makes it easier for an analyst to recognize patterns and investigate alerts.
This helped me understand that the dashboard itself is not the source of the information. The logs provide the underlying data; the SIEM collects and analyzes it; the dashboard helps the analyst interpret it.
The course introduced Splunk Enterprise, Splunk Cloud, and Google Chronicle as SIEM solutions.
Splunk Enterprise is self-hosted, Splunk Cloud is cloud-hosted, and Chronicle is cloud-native.
The different dashboards also have different purposes. For example, Splunk includes dashboards for security posture, executive summaries, incident review, and risk analysis. Chronicle includes dashboards for alerts, data ingestion health, indicators of compromise, rule detections, and user sign-in behavior.
I do not need to memorize every dashboard name to understand the main idea: SIEM dashboards help analysts turn large amounts of security data into something they can prioritize and investigate.
Open-Source and Proprietary Security Tools
The course also distinguished between open-source and proprietary tools.
Open-source tools make their source code available and allow users to inspect, modify, and build on the software within its licensing terms.
Proprietary tools are owned by a person or company. Their source code is generally controlled by the owner, and users usually have more limited ability to modify the product.
The material introduced Linux as an open-source operating system and Suricata as open-source network analysis and threat detection software.
Suricata can inspect network traffic, identify suspicious behavior, generate logs, and integrate with SIEM and other security tools.
This corrected the idea that open-source automatically means less capable or less secure. The material shows that both open-source and proprietary tools are used in cybersecurity.
Playbooks and Incident Response
A playbook is a manual containing predefined and current steps for carrying out an operational action.
In incident response, that means analysts do not have to invent a response while an incident is already happening. The playbook provides a consistent process for the team to follow.
An incident response playbook in the course contains six phases:
1. Preparation
Prepare procedures, staffing, roles, responsibilities, and user education before an incident occurs.
2. Detection and Analysis
Detect an event and analyze it to determine whether an incident occurred and how serious it may be.
3. Containment
Prevent the incident from causing additional damage.
4. Eradication and Recovery
Remove the cause and artifacts of the incident, address vulnerabilities, and restore the affected environment.
5. Post-Incident Activity
Document what happened, communicate findings, determine the root cause when appropriate, and apply lessons learned.
6. Coordination
Report and share information throughout the response according to organizational and compliance requirements.
One point I want to remember is that a playbook is a living document. Teams update it when they find failures, when laws or standards change, or when threats and techniques change.
That means incident response does not simply end when systems are restored. What the organization learns from the incident should improve how it handles the next one.
How SIEM, SOAR, and Playbooks Work Together
This was one of the clearest connections in the course.
A SIEM can collect and analyze logs and generate an alert.
The analyst then uses the appropriate playbook to determine what actions should be taken and in what order.
A SOAR tool can automate repetitive security-response tasks generated by tools such as a SIEM. The material gives the example of automatically blocking an account after too many incorrect login attempts, after which analysts can follow a playbook to resolve the issue.
The way I understand their relationship is:
SIEM helps tell me something may be wrong.
The playbook tells me what process to follow.
SOAR can automate some of the repetitive actions within that process.
The human analyst is still important because SIEM security events require analysis and not every situation can or should be handled entirely through automation.
Connecting the Concepts
The biggest thing Course 2 helped me understand is how these individual ideas connect into one security process.
An organization first needs to know what it is protecting: its assets.
Those assets may face threats, and weaknesses in systems create vulnerabilities that threats may exploit. Together, these contribute to risk.
Organizations use frameworks to structure how they manage that risk and controls to reduce specific risks. The CIA triad helps them think about whether confidentiality, integrity, and availability are being protected.
Security principles help make those controls and systems safer by design, while audits help determine whether the organization's controls, policies, and procedures are actually working.
From there, logs record activity across systems and networks. SIEM tools collect and analyze those logs so analysts can monitor activity and detect possible incidents.
When an alert becomes something that needs investigation, the analyst can follow a playbook to detect and analyze the problem, contain it, eradicate the cause, recover affected systems, document what happened, and coordinate the response.
Finally, lessons from the incident can lead to updated controls, policies, procedures, and playbooks.
The overall picture I now have is:
Assets → Threats & Vulnerabilities → Risk → Frameworks & Controls → Monitoring & Detection → Incident Response → Improvement
Security is therefore not only about stopping an attack. It is a continuing process of understanding risk, applying safeguards, monitoring what happens, responding consistently, and improving from what was learned.
What I'm Taking Away From This
Before this course, many of these terms could have sounded like separate pieces of cybersecurity vocabulary. What I understand now is how they support one another.
Frameworks organize security efforts. Controls reduce specific risks. The CIA triad gives security goals to protect. OWASP principles help guide safer security decisions. Audits check whether protections are actually working. Logs provide records of activity. SIEM tools help analysts make sense of those records. Playbooks provide structure when something needs to be investigated and handled.
The most useful lesson for me is that cybersecurity is a cycle rather than a one-time setup. Risks change, systems have to be monitored, incidents need structured responses, and what the organization learns should feed back into stronger controls and better procedures.
That is the foundation from Course 2 that I want to carry forward as I continue learning cybersecurity.