Threats, Vulnerabilities, and Risk Management

This lecture builds the working core of cyber security. It starts with the exact differences between cyber security, information security, and data privacy, then moves to the common attacks — including two live demonstrations of SQL injection and cross-site scripting on a dummy site. After that comes the defender's toolkit: security functional requirements, attack surfaces and attack trees, threat modeling with STRIDE, vulnerabilities, risk, and finally the controls you deploy in response. The thread that runs through all of it is simple: understand how an attacker thinks, know where your weaknesses are, and put controls in place that make the attacker's job as hard as possible.

3.1 Cyber Security vs Information Security vs Data Privacy

3.1.1 Cyber Security vs Information Security

Cyber security is all about the data you have in place and the systems that are available, and the threats coming at them from external resources — meaning through the internet. The question it answers is how you can shield your data from those external resources, and what sort of technical and organizational controls you can deploy so that the impact from an external source is minimized.

The first hard truth of the field: we can never say any system is 100% secure. There will always be a chance for hackers to penetrate your systems. So the discipline works toward two goals. One, minimize the possibility of an exploit happening to your system as much as possible. Two, in the worst case where that event succeeds anyway, minimize the impact it has on the organization. We pursue these two goals by implementing necessary technical controls.

The overall objective of cyber security is combating cyber crimes and cyber frauds, and also supporting law enforcement. Information security, by contrast, strives mainly against unauthorized entries, altering the data, or undermining access. Cyber security identifies cyberspace threats — the threats that come from the internet — while information security protects your records regardless of your domain. With respect to records, that is what we are trying to secure.

The two fields overlap but answer different questions:

When to pick which: if the threat comes from the internet, you are doing cyber security work; if you are protecting records wherever they live — paper, local disk, or cloud — you are doing information security work. Most real jobs do both.

3.1.2 Data Security vs Data Privacy

Security, as we know, is the CIA triad: confidentiality, integrity, and availability. Privacy refers to something different: the appropriate use and control of the data of individuals. When someone is collecting data, you as the data owner have rights over it — and the newer laws treat that control as a fundamental right. The Digital Personal Data Protection Act (DPDPA), 2023, passed in the Lok Sabha, has this as its primary intention: your data is there, and if it spreads across multiple institutions or multiple platforms without your knowledge or your concern, your privacy has been compromised.

The same agenda shows up in every major privacy regulation: in India the DPDPA Act, in the UK and Europe the GDPR, in Canada the PIPEDA (the Personal Information Protection and Electronic Documents Act), and in the US the HIPAA Act for health-information-related data. Overall, privacy is about your personal information. Whenever an organization wants to access, process, or share that information with a third party, it should ensure that the end owner, the data owner, is aware — knows what is being done with the data, to whom it is being shared, how many ways it is being retained, and if the data needs to be updated or deleted when the organization receives such a request.

3.1.3 Data Subject vs Data Principal

The terminology differs between laws but the objective is the same. GDPR calls the end user the data subject; the DPDP Act calls the same person a data principal. As a data subject or data principal, you should have full rights in ensuring that you know where your data is getting accessed, where it is getting shared and to which vendors, where it is getting stored, and for how many days it is retained in their systems.

That is what data privacy is about, and most of the regulations that have been framed are in line with these data privacy principles. Typically we have a small set of principles, called the OECD principles, which ensure that there is notice to the end user, there is consent from the end user, the data use is limited — it should be used only for the intended purpose — and it should not be transferred to any third party without the consent of the user, and so on.

3.1.4 Privacy Needs Security

If you want to achieve the privacy of your data, security must be there. Without security there is no data privacy. If a server is storing all of your personal information and there are not enough controls, then anybody can see the data. That is the reason security and privacy are always interlinked.

The two worlds also meet different instruments. If an organization wants to go for security, these are the certifications; in terms of privacy, these are the regulations that come into the picture. European countries are more focused on privacy, so their regulations are more stringent compared to other countries.

3.1.5 Authentication, Authorization, and IAM Tools

A quick recap of the identity concepts: accountability, authentication, and authorization. Authentication is all about proving your identity — when you enter your username and your password, you prove that you are the person who is trying to access the system. Then the question becomes what level of access you have been provisioned for; that is where authorization comes in.

To perform this in an organization we have a number of tools available — IAM (identity and access management) tools, with SailPoint as an example. SailPoint is a tool where most companies deploy their critical systems that need to be part of the governance. Whenever a new user joins, or an existing user wants to update their privileges, a request is raised in SailPoint showing that for this application, system, or database, this is the level of access request we have received, and whether you approve or reject. That is how the organization tracks privilege changes.

Real-world: the same request-and-approval pattern is exactly what auditors check — every privilege change must have an approved request behind it. If an auditor asks "why does this ex-employee still have access?" or "who approved this admin account?", the answer has to be a tracked, approved request in the IAM tool, not a vague memory.

3.1.6 What Is a Threat?

A threat is performing a malicious activity with the wrong intention against your systems, which can result in your data not being available, the system being compromised, the security being compromised, confidentiality being lost, or integrity being lost. The formal definition is similar: the intention is malicious — performing a malicious activity that attempts to gain access to your system or network without having the necessary privileges or authorizations in place, or without permissions from the respective owners.

Common threats include social engineering and unpatched software. Unpatched software is worth understanding carefully. Vendors like Microsoft release patches from time to time; a patch is nothing but a set of lines of code that the vendor has developed for a loophole they identified. Once we deploy that executable or code in our systems, we are not prone to those vulnerabilities anymore. A lack of timely patching leaves your systems vulnerable to exactly the loopholes the vendor has already identified — and that is where a hacker takes that as a platform and enters your systems.

3.1.7 Exam Notes

3.2 Common Attacks and the Live Demos

3.2.1 Application-Level Vulnerabilities

The most common attacks reviewed are phishing, social engineering, passing of malware, and SQL injection. SQL injection and cross-site scripting are security vulnerabilities happening at your application level. A vulnerability is nothing but a weakness in your system; that weakness can be at the application level, at the database level, at the OS level, or anywhere. The attacks discussed here focus specifically at the application level, and two of them were shown as simple live demonstrations on a dummy site.

3.2.2 The SQL Injection Demo

The demo site is a user interface where a user enters a sign-in. Normally a user provides a valid username and password to log in. Behind the scenes, the application builds a query something like:

SELECT * FROM users WHERE username = 'admin' AND password = 'secret'

Only if a row matches does the login succeed. Instead of providing legitimate credentials, the demonstration passes a simple SQL query into the username prompt: the username is set to admin and the query ' OR 1=1 is appended. The idea: in SQL, 1 = 1 is always true, so if the query is executed unvalidated, the authentication check passes and the password can be anything.

SELECT * FROM users WHERE username = '' OR 1=1 AND password = 'anything'

SELECT * FROM users WHERE username = '' OR 1=1 -- AND password = 'anything'

The demo did not succeed on the first attempt — the page showed that the username and password were not in sync, meaning the login was rejected. This is a valuable confusion moment, captured in full:

3.2.3 The Cross-Site Scripting Demo

The second demo is cross-site scripting (XSS). Wherever the application has a user-input provision, the demonstration passes a simple script:

<script>alert(document.cookie)</script>

The script pops up an alert that captures the cookie information present in the machine. This is a client-side attack: a small script that gets executed at the client side. The attack path: through phishing or email spam techniques, the attacker injects this script; when a user clicks on it considering it legitimate, the script captures the cookie information. Websites keep users logged in through server authentication based on cookie validation — so whoever holds the stolen cookie can enter as the legitimate user. That is how cross-site scripting succeeds with a very simple script.

Real-world: cross-site scripting is a simple code-injecting attack that allows an attacker to execute JavaScript in another user's browser. If you do it at the client side it is client-side cross-site scripting; if you pass the code to the server and it executes there, it is server-side cross-site scripting. The defense is the same family as SQL injection: treat all input as data, never as code — validate, encode, and sanitize anything a user can type, and set cookies as HTTP-only so scripts cannot read them.

3.2.4 Denial of Service and Distributed Denial of Service

Denial of service (DoS) means continuously making sure that legitimate users cannot access the web server, keeping the server busy with continuous pings — for example using a ping of death or similar tools. Every server has some capacity to accept a number of requests. If you continuously bombard it with requests to infinity, the processing capacity of the server reaches its maximum level, and then you get an error saying the server is busy or unable to respond. At that point legitimate persons cannot access the service.

The naming depends on scale. If you do that to a single system with a single attacking source, it is called denial of service. If you target a single server using multiple systems — a distributed army of machines — it is called a distributed denial of service (DDoS). In practice, attackers build that army by infecting many computers with malware that turns them into a botnet, then ordering the whole network to flood the target at once. Because the traffic comes from thousands of different machines, blocking one source IP does not stop it — which is why DDoS is much harder to defend against than a single-source DoS.

3.2.5 Backdoors and Man-in-the-Middle Attacks

A backdoor technique is having a small executable file installed at your back end as a back door through which authentication can be bypassed.

A man-in-the-middle (MITM) attack happens when communication between a client and a server is not in an encrypted form. A person sits in the middle, captures all the information, can modify the information, and can send requests as if they are sent from a legitimate user. That is the reason nowadays most client-server communications are always established using HTTPS, so that all the communication happens in an encrypted format.

3.2.6 Zero-Day Exploits and the Impact of Successful Attacks

A zero-day vulnerability is a weakness in the system that has no patch and no technical control measure protecting you from that exploit — it is unknown to the vendor, so nothing shields you. If such attacks succeed, the impact can be huge: financial loss, reputation damage, and legal consequences — fines from regulatory bodies. If the system goes down or the data is exposed to hackers, the organization gets penalized.

3.2.7 Industry Applications and Exam Notes

Real-world: the OWASP (Open Web Application Security Project) maintains the well-known top-10 list of application security vulnerabilities, and SQL injection is one among them. The attack works by injecting a SQL query via the input data coming from the client, from the end user, to the application. Once it succeeds, the attacker can read whatever sensitive data is in the database, and once logged into the database, can read, update, insert, delete, or even perform administrative operations.

3.3 Security Functional Requirements

3.3.1 Functional vs Non-Functional Requirements

Requirements can be functional or non-functional. Functional requirements talk about how exactly the functionality of your application needs to be met as per your client requirements. When we talk about security requirements — specifically IT security requirements — these combine both the functional and the non-functional. They need to be satisfied in order to achieve the security attributes of your IT system.

3.3.2 Sources of Security Requirements

Security requirements come from several inputs. First, best practices and standards to follow while developing an application — for example, a three-times password logout policy, or a banking website that should automatically log out when you click refresh or go back. Second, previous risks: considering what risks have happened, you impose those as security requirements in the upcoming product. For example, if the application is accessed from a mobile device, there should be separate isolation between the app being accessed and what is happening inside the mobile device. Third, regulatory requirements — for example, banking applications in India should all adhere to the RBI security norms (the Reserve Bank of India's security and audit requirements for banking applications). Fourth, user needs.

Combine all of these and they become your security requirements. Those requirements are typically requested from the technical side — what are the necessary controls, technical or process-level, that you can show to meet them. From there, solution architects design whatever the architecture is to meet those requirements; that design must contain a security architecture. When we say security architecture, it is not only from the functional perspective — you combine all the security requirements and the necessary controls, and that turns into your security architecture. In addition to your functional requirements, even your security requirements need to be formulated at an abstract level before designing the product.

3.3.3 Abstraction Levels

Security requirements can be formulated at different levels. At the highest abstraction level they basically reflect the objectives. For example, one objective is to ensure confidentiality for all the data that has been classified as confidential according to your data classification procedure or policy. More useful for an architect or designer are the security requirements that describe more concretely what must be done to assure the security of the system and its data — the more detailed the requirements, the better the architect can see how to meet them.

3.3.4 The Four Categories

First, security functional requirements: a security-related description that is integrated into your functional requirement. Typically this also says what should not be able to happen — when you say this needs to be there, that also means you expect this should not happen.

Second, functional security requirements: the security services that need to be achieved by the system under inspection — for example, how the authorization should happen, when the backup should be taken, how the clustering should happen. These requirements can be derived from your best practices, from commitments you have provided to the client, from your organization policies, or from the regulations you must follow.

Third, non-functional security requirements: these come more from the architectural side — how resilient the system should be, what maximum performance you can provide for your systems.

Fourth, secure development requirements: this is about the secure SDLC — whenever you are developing a product, how you inculcate the security requirements in each phase of your SDLC.

3.3.5 Secure Development Requirements and the Secure SDLC

Walk the SDLC with security in mind. When you are gathering functional requirements you should also be able to understand and gather the security requirements. When you are developing the code, think not only of best coding practices but of secure coding practices — for example, never embedding any of the passwords inside the code; there are many such best coding practices one should follow. When the code is developed and you are doing the testing, test not only from the functional perspective but also from the security perspective.

In this way the secure SDLC mechanism ensures that all the security-related requirements are captured — starting from the functional requirements, through developing the code, through testing the code, where testing means both statically and dynamically. These requirements take inputs from all the different stakeholders, and the controls you develop for them become your secure architecture.

3.4 Cloud Service Models and the Attack Surface

3.4.1 SaaS, PaaS, and IaaS

Enterprise IT environments are getting more complex as they move from traditional environments to cloud applications. Three models appear again and again. Software as a service (SaaS) is where the provider just gives us the software; our administration is limited — our job is only to create user accounts, manage those user accounts, and use the features provided. Gmail is a SaaS application: inside Gmail we have Google documents, Excel, and so on. We do not worry about how the backend infrastructure is configured — that responsibility is entirely the cloud service provider's (CSP). At the frontend, creating and deleting email IDs is the end user's responsibility.

Platform as a service (PaaS) provides the provision for developing on a platform. The cloud service provider provides the platform to create or develop code and deploy it in the cloud. We are not worried about the hardware or software we would otherwise need to purchase for developers to write code. The third-party provider delivers the necessary software tools the developer needs, and the provider supplies the required hardware and software on their own infrastructure.

Infrastructure as a service (IaaS) provides infrastructure as a box: based on our requirements we configure the server, configure the email server, establish the communication between a database and an application. The provider just gives an empty box, and it is our responsibility to configure it the way we want.

3.4.2 What Is an Attack Surface?

We discuss the cloud models because everything is connected now. Every asset — any server, any system, any transaction — needs to connect through the internet. Employee efficiency and productivity grow with enterprise IT, but that growth also leads to more opportunities for hackers to find vulnerabilities and try to exploit them.

Take the bring-your-own-device (BYOD) concept: nowadays some companies do not provide organization laptops and instead use BYOD. But if the organization is unable to do an entire security scan of the laptop or desktop you are using to connect to their infrastructure, that device becomes an attack surface platform — attackers can use the loophole present in that laptop or desktop to enter and penetrate your systems. Businesses must be vigilant in taking the necessary steps to understand and protect themselves against these attacks.

To gain unauthorized access to an organization, one could bypass physical security — that is an attack surface. Browsing social network sites with embedded code, or clicking an attachment that gets downloaded, are digital entry points. Attack surfaces also have a physical component: hackers can wreak havoc by plugging an infected USB drive into a machine, or by gaining physical access to a company server room.

3.4.3 Reducing the Attack Surface

Typical entry points: weaknesses in your access control, all the ports that are open in your network, or an enabled USB drive. If you have a large attack surface you are giving more open doors for hackers to enter your network — that is the reason the attack surface should be as minimal as possible. Implementing controls at multiple layers — EDR on the endpoints, network-layer controls, application-level controls, cloud-level controls — reduces the chance of entry through each layer. This is the defense-in-depth idea applied to surface reduction: the more minimal the attack surface, the more secure we are. Having a larger attack surface is generally negative, so we always try to reduce it — attack surface reduction involves a number of ways to reduce the flaws in your environment.

3.4.4 Exam Notes

3.5 Attack Trees

3.5.1 The Attack Tree Model

An attack tree is a model of how an attacker might seek and gain access to your IT asset — your system, network, or application. The mindset: if we are developing anything and placing it on the internet, we want to make it as secure as possible. So we take the mindset of an attacker and ask: how would he bypass my controls?

Take an application that provides username and password login. What are the different ways the username and password can be bypassed? One way: brute force — the attacker tries a number of combinations of usernames and passwords, trying all possible ways, including dictionary-based attacks: if I use a password that is a dictionary word, can the application identify that? While developing the code, if you include password complexity requirements — the password should be a combination of alphanumeric characters, should not be a repetition of your last three passwords, should not be only numbers, should not be only alphabets, should not be any dictionary word — then even if the user enters a dictionary word, the application should not accept it as a password.

A good way to think about it is non-technical: how would a normal thief try to enter a high-profile home? That is his ultimate goal. Then he looks at the possible ways he can achieve it. Then he looks at what sub-problems he must solve to go from one stage to the next. Representing this entire method in tree fashion is the attack tree model — the top represents the final goal, the children represent the reaching of those goals, and the last level represents how you can do it and what problems can be solved.

3.5.2 A Worked Example: Attacking a Laptop

Goal: gain access to the laptop. The children of the root list the methods. Method one: check whether the laptop has been connected to the internet, and whether the person is accessing emails. If he is accessing emails, embed a script in an email attachment — once the script executes on the system, the attacker can access the laptop. Method two: check whether the USB has been disabled. If the USB is not disabled and the user copies data from the USB to the machine, then if there is no security scanning mechanism, a virus can enter the system and the attacker gets access through it. Sub-problems: whatever must be solved so the attack can move from one stage to the next. Suppose ten methods are listed, and analysis shows that four of them can actually succeed in getting the attacker access — that resulting model is the attack tree.

              [Access the laptop]               <- ultimate goal (root)
            /                    \
   [Email attachment]         [USB drive]       <- methods (children)
        |                          |
   (attacker targets a       (USB port enabled?
   user who reads email)       user copies data?
   -> script embedded in       no scanning on the
      attachment executes       machine)
   -> remote access gained  -> virus enters via the
                              copied files and grants
                              access

3.5.3 Purpose of Attack Trees

The purpose of an attack tree is to identify the dangers to a system or a network. It outlines the malicious actor's various techniques for achieving those goals — sending a virus via email attachments, whether the USB is visible or not, whether the system is exposed to the internet or not. Once you know all the possible ways an attacker can get in, as a defender you work the opposite side: you look at what techniques you can implement so you can prevent all of that from happening.

3.5.4 Attack Surface vs Attack Tree

The two models answer different questions. The attack tree models the attacks: the three-stage tree (ultimate goal, methods, sub-problems) showing how a malicious attacker might seek access to your application, system, or network. The attack surface tells you the points where an attacker can enter: weaknesses in access control, open ports in the network, enabled USB drives. Attack tree = modeling the attack paths; attack surface = listing the entry points.

When to pick which: you shrink the surface to remove cheap entries, and you model the tree to understand and block the realistic attack paths — most security programs do both.

3.5.5 Student Questions and Answers

3.5.6 Defense in Depth and the Cyber Security Wheel

Once you know the different ways an attacker can log into your system, application, or network, you implement controls at each layer. At the application level you perform application-level controls. At the network level you run a continuous traffic analyzer — it continuously monitors the traffic; whenever it finds an abnormal request coming from a specific IP address, or a sudden hike or spike in network traffic from different source IPs, your security monitoring tools automatically block it and trigger an alert. At the endpoint level you implement DLP controls, hardware-based security, IoT-level security, and unified endpoint management (UEM). In the old days we had signature-based antivirus — the manager pushed signatures and the signatures kept updating. Current EDRs (endpoint detection and response) work differently: based on how the communication happens between two processes, the EDR finds out whether there is any issue happening. EDR not only detects abnormal activity but also responds to it.

The layers also include: next-generation antivirus; API-level protection — nowadays two applications communicate through APIs, so we must ensure no other API enters and that the necessary protections are implemented; CASB and the web application firewall (WAF) for web communication; and browser isolation — sometimes a browser, browsing certain websites with a plugin like Flash Player, can gain privileges beyond the required level of access and jump into system-level files, so browser-level isolation restricts that access to the browser only. On the data side: malware protection, DLP, BYOD governance, and DRM (digital rights management) — if somebody purchases a licensed copy of a PDF document, the license binds your system's MAC address to it so you cannot open the same document on other machines. ZTN (zero trust network) is the latest: do not trust any system — trust it only after verification, and only then grant access; well-known top vendors have ZTN architecture deployed in their products.

Data security further includes encryption, data loss prevention, anonymization — even if people can access the database, they still cannot see what data is over there — homomorphic encryption, and blockchain-type techniques. And two continuous activities: threat intelligence, where sophisticated tools scan your networks and endpoints for threats — just as countries have threat agencies that continuously monitor incoming threats (India's CERT), your infrastructure has threat intelligence devices that continuously scan systems and networks for abnormal activity; and threat hunting alongside continuous scanning, which is called vulnerability assessment.

3.5.7 Exam Notes

3.6 STRIDE Threat Modeling

3.6.1 What Threat Modeling Does

Threat modeling means we try to model the threats: find the threats, analyze them, prioritize them, and prevent them from happening to our systems, our networks, or our IT environment. We are essentially conceptualizing the risks we face and strengthening our cyber security posture. Threat modeling plays an important role for an organization in identifying the different threats that will come from the outside world.

There are different models. One is the STRIDE model, developed by Microsoft. Another is the MITRE ATT&CK model — a knowledge base of adversary tactics and techniques built from real-world attack observations, organized by stages such as initial access, execution, and lateral movement. Many endpoint EDR systems have one of these threat models embedded at the back end, and based on how movement is happening, the system identifies exactly where the threat is and in which stage it is.

3.6.2 The STRIDE Categories

STRIDE is an acronym: S for spoofing, T for tampering, R for repudiation, I for information disclosure, D for denial of service, and E for elevation of privileges. The claim behind the model: any threat that happens will fall into one of these six categories.

Spoofing involves illegally accessing and then using another user's authentication information, such as their username or password. The model tells you which phase the attacker is in — whether he is in the spoofing phase or somewhere else.

Tampering involves modification of the data — for example, unauthorized changes made to personal data held in a database, or alteration of data as it flows over computers over open networks such as the internet.

Repudiation means you have done something but you are denying it. It is associated with users who deny performing an action without other parties having any way to prove otherwise: a user performs an illegal operation on a system that lacks the ability to trace prohibited operations — there are no logs that prove he is the person who did it.

Information disclosure involves exposure of information to individuals who are not supposed to have access to it. Examples: the ability of users to read a file they were not granted access to, or the ability of an intruder to read data in transit between two computers — information disclosed to unauthorized persons who do not have the privilege to read the data.

Denial of service: a web server is temporarily unavailable or unusable. You must protect against certain types of those threats simply to improve the system's availability or reliability.

Elevation of privileges: privileges are the levels you hold — like in Linux or any system, the guest level, user level, admin level, or super admin level. Here an unprivileged user gains privileged access, thereby having full access to compromise or destroy the entire system. Elevation-of-privilege threats can include situations in which an attacker has effectively penetrated all the defenses you implemented and then becomes a part of your trusted system itself — a genuinely dangerous situation.

3.6.3 Non-Repudiation

Non-repudiation refers to the ability of a system to counter repudiation threats. Example: a user who purchased an item might have to sign for the item upon receipt; the vendor can then use the signed receipt as evidence that the user did receive the package. The signature is the proof the system could not produce on its own.

3.6.4 Using STRIDE as a Method

When you want to think of the possible threats to a system you cannot think randomly — the categories force a systematic walkthrough. For each category, write the category name, say spoofing, and list out all the possible ways it can happen; do the same for tampering, repudiation, information disclosure, denial of service, and elevation of privileges. Once all the possible scenarios are written, you deploy the countermeasures or the controls so the attacker can be defended against all of them.

3.6.5 Threat Models in Industry

Real-world: most security vendors who provide EDRs or threat modeling deploy one of these models at the back end — Microsoft uses the STRIDE model, other vendors use the MITRE ATT&CK model. Take Carbon Black Defense as an example: a collaborative effort of Carbon Black threat engineers mapping endpoint techniques into the MITRE ATT&CK framework, combining next-generation antivirus and endpoint detection and response across a spectrum of attacks, with allow and block decisions when threats are observed. At the national level, CERT (Computer Emergency Response Team) is specific to India, gathering information on threats from multiple sources — that gathering is nothing but threat intelligence.

3.6.6 Student Questions and Answers

3.7 Vulnerabilities and Vulnerability Assessment

3.7.1 What Is a Vulnerability?

A vulnerability is a security weakness in your system — a security loophole. Using those vulnerabilities, a hacker can exploit your system, network, or database. The possibility of a threat exploiting a vulnerability, and the impact of that happening, is the risk to the organization — which is what the next section develops.

Concrete examples of vulnerabilities: the guest account has been enabled on a laptop and has not been disabled; the OS has not been patched up to date; on a server there are unnecessary ports opened even though no services are linked to them. There are many such vulnerabilities. The job of a security team is to perform continuous assessment of the vulnerabilities in systems, applications, and infrastructure and to close those vulnerabilities. If there are weaknesses in the system, those weaknesses become the attack surfaces by which a hacker can exploit the system.

For that reason we always perform vulnerability scans and vulnerability assessments, both internally and externally. Whatever vulnerabilities get listed, we try to remove them; if a service cannot be removed because of a business need, we implement extra necessary controls so the chances of exploiting that vulnerability are minimal.

3.7.2 Common Vulnerabilities

System vulnerabilities can include software flaws or misconfigurations — however you configure your server, if there are misconfigurations those result in vulnerabilities, which create opportunities for unauthorized access or for exploiting the system and compromising it. Some common vulnerabilities include unpatched software, weak passwords, using insecure network protocols, and inadequate security controls — all often targeted by attackers to gain unauthorized access. Having vulnerabilities makes the life of the attacker easy; the objective is always to reduce the number of vulnerabilities to as minimum as possible.

3.7.3 The Three Elements of a Vulnerability

A vulnerability is a flaw that opens you to an attack. The flaw contains three elements: a flaw in your system which gives an attacker access to that flaw, and the attacker has the capability to exploit that flaw. There is a weakness in your system that makes access possible, and with that the attacker exploits the system.

Vulnerabilities occur in whatever components make up the infrastructure: hardware components, software components, network components, at the personnel level, at the physical site level, or at the organizational level. Vulnerabilities are classified according to assets — an asset is anything that has value to the organization: your software assets, your network assets, your hardware assets, and your physical site can all carry vulnerabilities. Other example vulnerabilities: patching issues; sending credentials in clear text; using unencrypted channels — if there is no encryption between two systems, the data will be formed in plain text; and radio frequency emanation.

3.7.4 Mitigating Vulnerabilities

The technical controls that reduce vulnerabilities are the mitigations: having a well-defined patch management process; establishing best practices for hardening of your systems; maintaining enough access control mechanisms through IAM — granting access, modifying access, deleting access, and periodically reviewing access; performing periodic vulnerability assessments, monthly or quarterly, and ensuring that the vulnerabilities identified as high, medium, or low are remediated within the time frames set by your organization; and last but not least, security awareness training — one of the most important administrative controls.

3.7.5 Student Questions and Answers

3.8 Risk Management and Risk Assessment

3.8.1 The Definition of Risk

We know threats and we know vulnerabilities; the next stage is how to manage the risk to the organization. Risk is nothing but the probability of a threat exploiting the vulnerability, and the impact to that organization:

$$\text{Risk}=\text{Probability}(\text{threat exploits the vulnerability})\times \text{Impact}$$

The verbal statement is the same: "risk is the probability of the threat exploiting the vulnerability and what is the impact to that organization." Probability is how likely a given attack scenario is — for example, unauthorized access happening. Impact is the consequence if it does happen. Multiply the two and you get the risk value.

3.8.2 Risk Management vs Risk Assessment

People often confuse risk management and risk assessment as the same thing — they are not. Risk management covers all the stages: identifying the risk, assessing the risk, responding to the risk, and continuously monitoring the risk. If you cover all of these stages, that is your risk management. Risk assessment is only one of the stages — it assesses the risk by identifying, analyzing, and evaluating it, and by giving a rating to it.

Why do risk assessment at all? Your organization has so many assets, and every asset has vulnerabilities. To know which assets, which risks, which vulnerabilities to give preference to, you perform a risk assessment: identify the probability of a threat exploiting a vulnerability and its impact, and come up with a risk value — high, medium, or low.

3.8.3 Qualitative and Quantitative Assessment

Risk assessment comes in two types. Qualitative risk assessment states the risk in terms of high, medium, and low for both probability and impact. Quantitative risk assessment works in numbers: if this event is going to happen, how much is the loss to the organization — number-based calculations.

We do not invent our own standards — we always refer to established methodologies: the ISO 31000 risk management standard, or the NIST SP 800-53 risk assessment model, and there are many other risk management or risk assessment methods one can follow. Either technique — qualitative or quantitative — lets the organization evaluate the high risks so they can be prioritized, because just listing out risks is not important; you need to prioritize. Once you know which are high, medium, and low, you can respond.

3.8.4 Responding to Risk

Responding to a risk means choosing one of four options. Accept the risk: we cannot do anything about this — for example, when onboarding a vendor there is a risk, but there are no alternatives to that vendor, so the business needs to accept it. Transfer the risk: for example, if a cyber attack happens and we need to pay some amount of dollars to our clients, we take a cyber incident plan (insurance) and transfer the risk in those scenarios. Avoid the risk: if outsourcing this brings a risk, stop doing that — stop doing the project itself, stop doing the process itself. Mitigate the risk: do a cost-benefit analysis — for this risk, what technical control do we need to implement; to implement it, what is the cost incurred to the organization; and what is the benefit we get out of it. If the benefit is more than the amount of cost incurred, we implement those technical controls.

3.8.5 The Analysis Phase

Risk assessment is about identifying, assessing, analyzing, and evaluating the risks and their impacts on the security and operations of your systems or networks. In the analysis phase we examine the likelihood and the consequences of the risks, allowing informed decision making and prioritization of the risk management efforts. With risk ratings — critical, high, medium, low — prioritization can be done easily. Without the risk ratings, just computing the impact without a risk value, it is very tough for business stakeholders to know which risk they need to respond to.

3.8.6 Student Questions and Answers

3.9 Security Controls

3.9.1 Physical, Administrative, and Technical Controls

Control is all about implementing measures. In risk mitigation — one of the four risk response techniques — you implement a control. Controls are classified in two independent ways: by category and by how they operate.

By category there are three. Technical controls: technology comes into the picture — you implement necessary technical controls to mitigate risks. Administrative controls: linked to your organization's policies and procedures — you keep changing the policies, keep updating the procedures; these are administrative controls. Physical controls: anything related to physical security is a physical control.

3.9.2 Preventive, Detective, and Corrective Controls

By how the control operates there are five types. A preventive control tries to prevent something from happening — for example, a firewall, or an intrusion detection system combined with an intrusion prevention system (IDS/IPS): it can not only detect but also prevent, so it is preventive.

A detective control tries to detect something happening — for example, a SIEM (security information and event management) system that continuously monitors and detects anomalies.

A corrective control takes corrective action after abnormal activity is found — for example, when abnormal activity is found, the system immediately disconnects the connection. Corrective examples with failures: if the primary server goes down, as a corrective action you redirect the traffic from the backup server; if the primary data backup fails, you take the backup from the secondary backup; if the server crashes, the corrective action is recovery from your backup systems.

A deterrent control makes the hacker afraid before he does something. For example, when someone tries to log into corporate systems or networks, a pop-up message or banner appears: this network is proprietary to so-and-so organization, if you log into the store you will be fined or prosecuted. The banner is a deterrent control — it makes the person trying to do something wrong afraid.

A compensating control acts as an alternative control. In a scenario where there is no control in place, we implement another control that may reduce the risk posture of the organization. The main objective of compensating controls is: whatever weaknesses exist in your existing controls, you try to compensate by adding one more control.

3.9.3 The Compensating Control Example: Segregation of Duties

A standard compensating-control story: the four-eyes principle in financial transactions. Whenever a financial transaction happens, one person reviews it, one person checks it, and one person approves it — that is segregation of duties. Because the organization is small, it cannot have the manpower to do these multiple tasks and achieve segregation of duties. In those scenarios you propose a control that attains the objective of the original control without the extra manpower — for example, an automated approval workflow — and that is a compensating control.

3.9.4 Worked Examples of Controls

One example per control type, with its category:

3.9.5 Student Questions and Answers

3.9.6 Exam Notes and Assignment

Exam Guidance Summary

• The first chapter of the syllabus covers computer security concepts (the CIA triad, threats, attacks, and assets), security functional requirements, attack surfaces and attack trees, and the strategies to implement.
• The syllabus explicitly asks for attack surface and attack tree. Threat modeling (STRIDE, MITRE ATT&CK) is included beyond the syllabus for correlation, and the live demos (SQL injection, cross-site scripting) are for understanding only — none of these extras are syllabus requirements.
• Assignment: the control-classification table — one example for each of preventive, detective, corrective, deterrent, and compensating, plus the physical, administrative, or technical category for each.
• Expect the risk formula — risk equals the probability of a threat exploiting a vulnerability times the impact — and the four risk response options: accept, transfer, avoid, mitigate.
• Understand the difference between risk management (identify, assess, respond, monitor) and risk assessment (one stage inside it, with identifying, analyzing, evaluating, rating).
• Next class: the MITRE ATT&CK model with an APT example mapped against it.
• Microservices is out of the syllabus.

Key Industry Applications

• SailPoint (IAM) — access request, approval, and privilege-change tracking for critical systems.
• Gmail — the everyday example of SaaS, where the cloud service provider owns the backend.
• OWASP — the top-10 application vulnerabilities list; SQL injection is one of them.
• HTTPS — the standard that defeats man-in-the-middle by encrypting client-server communication.
• STRIDE (Microsoft) and MITRE ATT&CK — the threat models embedded in EDR products; Carbon Black Defense as a named EDR example.
• CERT India — national-level threat intelligence, analogous to an organization's threat-intelligence devices.
• ISO 31000 and NIST SP 800-53 — the frameworks used for risk assessment and risk calculation.
• DLP, EDR, UEM, SIEM, CASB, WAF, DMZ, ZTN, SAST/DAST — the layered defense-in-depth controls at network, application, endpoint, cloud, and data levels.
• Privacy law landscape: DPDPA 2023 (India), GDPR (UK/Europe), PIPEDA (Canada), HIPAA (US).