Information Security Refresher

Disclaimer: Images were generated with AI. The written content is entirely my own.

Introduction

Information Security is the area that encompasses the protection of all data and information systems from unauthorized access, use, disclosure, disruption, modification or destruction. It primary objective is the CIA Triad, which we will explain in a moment. Whereas cybersecurity is a subset of InfoSec, which focuses specifically on protecting data that is in electronic form. It encompasses technologies, processes, and practices designed to protect networks, devices, programs, and data from attack, damage, or unauthorized access via digital means.

To make it easier to understand, information security is like guarding a pizza from your roommate. You lock the door, hide the slices and set rules for who can have a slice. While cybersecurity is the cameras, sticky note saying “Do Not Touch”, digital lock and maybe some ninja AI robot trying to stop the person from getting the prize… until it gets prompt-injected and lets them take a slice anyway.

Circling back to the CIA Triad, let’s dig deeper. The concept is built on three principles: confidentiality, integrity and availability.

Confidentiality means protecting data from unauthorized access. Only users with proper authorization get a pizza slice.

Integrity focuses on maintaining the accuracy, reliability and consistency of data. It ensures that when someone goes for a slice, the pizza hasn’t turned into an apple pie.

Finally, availability ensures that data and resources are accessible when needed. In other words, authorized users can get their pizza slice whenever they are hungry.

Enforcing CIA Triad

Now that we understand the core concepts that information security uses to protect a business, let’s dwell into a way to actually enforce it. That’s where AAA framework comes in: Authentication, Authorization and Accounting.

Authentication verifies who you are (are you allowed to have a pizza slice ?), Authorization determines what you can do (can you take a slice or just look at it?), and Accounting tracks what happened (who ate how many slices and when). AAA turns the goals of confidentiality, integrity, and availability into something we can actually control and monitor in practice.

What are we protecting against?

In the real world, systems, people and processes aren’t perfect, they have vulnerabilities, which are weaknesses that can be targeted by threats. When a threats meets a vulnerability, we get risks - the chance that our CIA principles are compromised. In simple terms: how easy is it for our arch-enemy to get a slice of pizza?

Vulnerability, as mentioned earlier, is the weakness in a system, network or process that can be exploited to compromise on of the CIA principles. It exposes the organization to threats. For example, leaving the door to the room where the pizza is stored unlocked.

A threat is the potential danger to the information or systems. In the real world, this could be malware, phishing, denial-of-service attacks. In our metaphor, it’s the suspicious person watching the room with binoculars, the weak password protecting the pizza safe, or even the rusty door hinges that might fail.

When a threat and vulnerability come together, they create Risk - the likelihood of exploiting and the potential impact. In other words, is that person with binoculars actually planning to steal the pizza, or just birdwatching?

To monitor what’s happening in an environment, we rely on logs. Logs are records action within a system. They help with troubleshooting, visibility, and security. If the safe could record who accessed it, when the door was opened, and whether anything unusual happened, those records would be logs.

From these logs, we identify security events. Occurrences that may be relevant to safeguarding information. For example, a message saying the pizza is still warm is an event, but not security-relevant. However, a record showing someone accessed the safe is.

When an event causes harms or represents a confirmed compromise, it becomes a security incident. For example, if Bob was in Japan a few minutes ago and is now accessing the pizza safe in New York, that’s an incident.

Finally, alerts are notifications generated by the devices or personnel indicating a potential security issue or suspicious activity. If someone fails to enter the pizza safe password 50 times, that should trigger an alert.

Security Controls

To manage this lifecycle, we implement security controls to prevent, detect and respond to threats. These controls are layered through a defense-in-depth strategy. Many people compare this to slices of Swiss cheese - each layer has holes, but when stacked together, the gaps are covered.

But you could also think of it like layers of an onion, an artichoke - or any food you like, as long as it has layers or holes you can stack to cover each other’s gap. These analogies change over time, so maybe swiss cheese get replaced one day. Maybe it becomes a dragon fruit…although at that point, we’ve probably lost the plot, and the pizza.

We have a few different types of controls which help structure our defenses.

Administrative controls are policies and procedures that guide how the organization operates. This includes security policies, management procedures, incident response plans - or how to get coffee securely from the new coffee machine.

Next we have Technical Controls. These are technology-based protections such as firewalls, EDRs, IDS and 2FA. Think of them as the extra safeguards on the coffee machine to prevent a coffee junkie form taking over and producing unlimited coffee.

Physical controls include surveillance cameras, biometrics, fences and locks - anything that prevents physically access. In our example, this is the door protecting the room where the coffee machine is located.

Additionally, we also classify controls based on what they do.

Preventive controls aim to stop incidents from happening. For example, only IT staff access to the coffee machine - since, clearly, they need it the most. Examples include IPS, ACLs and, Firewalls.

Detective controls help identify suspicious or malicious activities. Imagine a bell that rings every time someone tries to access the coffee room. IDS, SIEM, logs and cameras fall into this category.

Corrective controls reduce the impact of an intrusion and help restore systems. This includes backups, incident response plans, patch management - and, of course, an emergency reserve of coffee beans.

Deterrent controls discourage attackers from attempting or continuing an attack. This could be warning signs, visible cameras, physical barriers, or even an HR announcement reminding not to leave the coffee machine on after hours.

Finally, we have compensation controls. These are alternative measures used when primary controls fail or aren’t feasible. For example, if the main access control system for the coffee room fails, an alarm might trigger when the door is force open.

Risk

Now that we understand the controls we can implement, the next question should be: how do we decide what to prioritize? Not everything has the same importance.

Risk is defined as the combination of probability (likelihood) and the impact, often represented in a matrix where these two elements form the axes. An example can be seen in the image below.

To illustrate, imagine a web server with a moderate probability (likelihood) of compromise due to its technologies and patch management practices. If the impact is minor (low) - because it does not represent significant loss to the company - then, based on the above risk matrix, the overall risk would be classified as moderate.

This process is applied across the organization’s entire attack surface, assigning different risk levels to systems and assets, which helps prioritize security efforts and resource allocation.

This leads us to risk treatment strategies. Based on the calculated risk, we can choose one of the following approaches:

Acceptance

We acknowledge the risk and decide not to act on it, usually because the potential impact is low or the cost of mitigation would be higher than the damage.

Transference

We shift the risk to a third party. For example, moving a local service to a SaaS solution transfers part of the infrastructure risks to the provider.

Avoidance

We eliminate the risk by removing the vulnerable element. For instance, replacing a system that is constantly exposed to vulnerabilities with a more secure alternative.

Mitigation

We reduce the risk to an acceptable level. For example, replacing password-based authentication with SAML - both carry risk, but at different levels.

A dedicated section on risk will be covered later, but for a SOC-focused context, this level of understanding is sufficient.

Now, let’s move on to Security Policies.

Security Policies

Security policies can be implemented at any stage of an organizations lifecycle, but they should be dynamic, evolving as the environment changes and as new technology and processes are adopted.

Ideally, they should be introduced early - alongside the growth of the organization. The earlier they are established, the easier and more cost-effective they are to design and enforce. Delaying their implementation often leads to increased complexity and higher costs later on.

With that in mind, there are many different types of security policies that can be implemented, depending on the organizations needs. Some of the most common include:

Acceptable Use Policy

Defines what is allowed within the organization when using company resources. For example, are the customer service employees allowed to use the company computers to stream their favorite movies? If so, are there restrictions - like limiting content to appropriate material, or making sure Sponge Bob keeps his pants on?

Password Policy

Defines how authentication should be handled, including password length, complexity, and rotation requirements. For example, can Bob from finance use “1234password” or “M0masboy” ? (Spolier: no, and Bob needs a talk.)

Data Classification Policy

Determines how data should be categorized and handled within the organization. Should we follow a standard like Traffic Light Protocol (TLP), or define our own model? How many classifications levels do we need - and do really need one just for pizza night ?

As a rule of thumb, organizations typically define at least the following levels: Public (can be shared freely), Internal (restricted to employees), Restricted/Need-to-know (limited to a specific group) and Confidential/tops secret (highly sensitive, limited to key personnel).

It’s also important to use clear and intuitive naming. So, calling your classifications “mountain-white”, “cat-orange,” “grass-green”, and “deep-black” might sound creative, but it’s not very helpful.

Access Control List (ACLs)

Now that we’ve been through a many of the basics of information security, let’s finish strong with Access Control List (ACLs). These define who can access what, when and under which conditions - whether systems, physical locations or data. Simplifying it: who gets the pizza, when and where.

Let’s review a few models.

Discretionary Access Control (DAC)

The owner of the resource decides who gets access. This provides flexibility, but has weaker security. Linux file permission is an example. “I bought the pizza. I decide who eats it”.

Mandatory Access Control (MAC)

Access is enforced by a central authority using classifications that users can’t override. Common in Military and government environments. “The pizza council has spoken. Only people in the third circle and above can eat pizza. The fourth circle may observe… from a safe distance.”

Role-based Access Control (RBAC)

Access is based on roles (admin, analyst, user, Karen), and users inherit permissions from those roles. Widely used in enterprise and IAM systems like AWS and Azure. “Pizza for all cybersecurity analysts. No pizza for marketing”

Attribute-based access control (ABAC)

Access decisions are based on attributes such as user, resource, and context. This allows very granular and dynamic control, but can be complex to manage. “Finance AND location = office AND time = business hours → Pizza slice”

Rule-based Access Control

Access is determined by system-enforced rules, often combined with other models. Examples include firewall rules, time-based access, and geolocation restriction. “10 minutes of pizza access for anyone wearing a blue t-shirt”

Identity-based Access Control (IBAC)

Permissions assigned directly to individual users. Simple, but hard to scale. “Bob is the only one who can get pizza”

Finally, while not an access control model itself, the principle of Least Privilege should be applied across all models. The idea is to grant only the access necessary - no more, no less.

Just Enough Access (JEA): only minimal permissions is given to the users.

Just-In-Time (JIT): Privilege are granted only for the time needed to perform a task.

Separations of Duties: no single user has full control over critical processes.

Privilege Creep: the gradual accumulation of unnecessary access over time (and something we want to avoid).

After this refresher and reviewing the basics of information security, feel free to check out SOC Anatomy here = )

References

TCM SOC101 - https://tcm-sec.com/academy/security-operations-soc-101

HTB - SOC PATH - https://academy.hackthebox.com/app/paths/390/details

LetsDefend - SOC rooms - https://app.letsdefend.io/path/soc-analyst-learning-path

Blue Team Handbook - https://www.amazon.com.br/Blue-Team-Handbook-Condensed-Operations