The Prequel
To be honest, I'm not entirely new to the concepts of cybersecurity. Data privacy acts, standards, and policies such as ISO, HIPAA, GDPR, FERPA, and others are already familiar to me. I'm also familiar with threats, vulnerabilities, risks, and common cyberattacks. I learned about them while studying for my bachelor's degree in Information Technology. Although honestly, once you enter the field of IT, you'll come across these topics almost immediately since security is one of the most important parts of IT. I had already learned some of them way back.
The Beginning
Before I started the course, there was only one goal for me: to become a penetration tester and an ethical hacker. I liked the idea of breaking into systems, writing scripts to penetrate them, and understanding how systems work by breaking them.
However, starting this course, I was immediately introduced to what cybersecurity actually means.
Cybersecurity, or security, is the practice of ensuring confidentiality, integrity, and availability of information by protecting networks, devices, people, and data from unauthorized access or criminal exploitation.
Cybersecurity protects organizations and the people they serve, and we, security analysts, are some of the people responsible for making that happen. As a security analyst, it is our responsibility to protect computers, networks, and information from threats and vulnerabilities using security frameworks and controls.
Security Frameworks & Controls
A security framework gives organizations guidelines for managing cybersecurity risks. They act as a blueprint that organizations can follow to protect their business. Controls, on the other hand, are the actual safeguards used to reduce those risks, such as passwords and access controls, encryption, antivirus, monitoring, security policies, and secure system configurations.
The basic process of a framework is to identify security goals, create guidelines, implement security processes, and monitor the results.
Beyond the basics, there are more established frameworks, standards, and regulations such as NIST CSF, CIS Controls, GDPR, HIPAA, and others. Different organizations have different security responsibilities depending on what they do and what kind of information they handle.
What I take from this is that security is not just installing an antivirus or blocking an attack when it happens. There has to be a process behind it. If I were working as an analyst, I would need to understand what the organization is trying to protect first, what risks exist around those assets, what controls are already in place, and whether those controls are actually working.
This also changed how I look at the CIA triad: confidentiality, integrity, and availability. Before, I mostly treated them as definitions to remember. Now I see them more as questions I could use when looking at a system. Who should be able to access this information? Can I trust that the information has not been changed? Will the people who need the system still be able to use it when they need it?
How I Imagine the Work of a Security Analyst
The course also gave me a clearer picture of what a security analyst actually does. Before this, when I thought of cybersecurity, my mind immediately went to hacking. Now I see that a large part of security work is actually monitoring, investigating, documenting, and responding.
An analyst might spend time looking through security alerts and logs, checking suspicious activity, examining network traffic, or trying to understand why something unusual happened. A failed login by itself might mean nothing, but hundreds of failed attempts followed by a successful login could be something worth investigating. The important part is not just seeing the event but understanding the surrounding context.
This is where tools such as SIEM platforms, logs, network protocol analyzers, Linux, SQL, and Python start to make sense to me as a whole. They are different tools, but they all help an analyst answer the same kinds of questions: What happened? Where did it happen? Who or what caused it? Is it normal? And what should I do next?
I can imagine using a SIEM to notice an alert, checking the logs connected to it, looking at network traffic if necessary, using SQL to search stored information, or using Python to automate repetitive parts of the investigation. Linux would also naturally be part of that environment since many servers and security tools run on it.
The course did not really teach me how to master these tools yet, but it gave me an idea of why I would use them.
Security Is Also About People
Another thing I already knew but understood better from this course is that not every attack starts with someone technically breaking into a computer. Sometimes the easiest way into a system is through a person.
Phishing and other forms of social engineering are good examples. An attacker may not need to find a complicated vulnerability if they can simply convince someone to give them their password or open something malicious.
For me, this means that protecting an organization is not only about securing computers and networks. People are also part of the security of a system. Policies, access controls, awareness, and knowing when something looks suspicious are just as important as the technical controls behind them.
Responsibility
One part of cybersecurity that I think becomes more important the more access you have is ethics.
A security analyst may have access to logs, accounts, systems, personal information, or other data that normal users cannot see. Having the technical ability to access something does not automatically mean I am allowed to access it.
If I were working inside an organization, I would have to know the boundary between what I can do and what I am authorized to do. I should only access information necessary for my work, follow the organization's policies, document what I do, and escalate things properly when needed.
This is especially important to me because I am still interested in penetration testing and ethical hacking. The word ethical is what separates authorized security testing from simply breaking into someone else's system.
What I Took From Course 1
I started this course thinking that cybersecurity was mostly about attacking systems so I could learn how to defend them. I still want to learn penetration testing and ethical hacking, but Course 1 gave me a wider view of the field.
A security analyst does not spend the whole day trying to hack something. They protect assets, monitor systems, investigate suspicious activity, work with security controls, follow frameworks and policies, document what happened, and help the organization reduce its risks.
The biggest thing I learned from this course is probably that cybersecurity is not one tool, one attack, or one job. It is a continuous process of understanding what needs to be protected, identifying what could go wrong, putting controls in place, watching for problems, and responding when something happens.
And if I eventually become a penetration tester, I think understanding this side of cybersecurity will still matter. Breaking into a system can show that a weakness exists, but understanding the organization, the risk behind that weakness, and how it should be fixed is what actually makes the finding useful.