Cyber Security

Cyber Security: Fundamentals, Threats, and Attacks

Published: 2026-08-16

Level: postgraduate

Audience: Postgraduate students in Cyber Security

# Cyber Security: Fundamentals, Threats, and Attacks

2.1 How This Course Runs — A Knowledge Exchange, Not One-Way Teaching

2.1.1 The Format of the Session

Why does a security course begin by talking about the room instead of the subject? Because security is a conversation between practitioners, not a lecture with a passive audience.

This course is run as an interactive, knowledge-exchange session rather than a teacher-student exercise. Everyone in the room comes from a different background — a person from QA may do manual or automation testing, a developer writes code, another works in support — and each of those backgrounds has something to contribute to the security conversation. The person leading the session works in the industry, so it is more like two practitioners talking than one person lecturing. Because of that, questions do not need to stay inside the syllabus: if something about cyber security is not in the course but is on your mind, it can still be asked and discussed.

The mix of backgrounds is not a coincidence — it is the point. Security touches every role:

A developer writes the code that either invites or blocks attacks.
A QA/test professional runs the checks that can catch a flaw before it ships.
A support person is the front line who sees what users actually experience, including the complaints that hint at a security incident.

Each of these vantage points sees a different slice of the same system, and the course is designed so those slices can be exchanged openly.

Who is leading the session? The person leading the session brings roughly sixteen years in the cyber security domain. The path started as an IT security person, then moved into VAPT (vulnerability assessment and penetration testing) and application security, and the last two years were spent in governance, risk, and compliance (GRC) doing third-party audits and ISO external audits. That person is also a legal graduate and currently supports legal operations in an organization, which matters for this course because privacy law and security governance show up repeatedly in the material. About twelve to thirteen of those years were hands-on in the domain.

That combination — hands-on technical work plus a legal education — explains why the course repeatedly crosses from technical controls into law and regulation: the DPDP Act, the GDPR, and audit obligations are not side topics here, they are part of the same picture.

For each topic in the syllabus, a textbook will be provided as reference material, and the prepared session content is expected to cover the majority of the syllabus.

The format matters for how you study: treat each session as a discussion you can enter. If a security question is outside the syllabus, it is still welcome — and the syllabus itself will be supported by a reference textbook per topic.

2.1.2 Why Cyber Security Is Buzzing, and the Shift Into It

Cyber security has been the most buzzing word in the industry for the last six to seven years, and for the last two years the interest has reached its highest levels. That is why so many people are adapting to it: developers ask how to move into security, people in testing look for a path in, and people in support look for a way over.

Think of it as a wave hitting every shore of the software industry at once. The demand is not for a new specialty that replaces existing skills — it is for the same skills with a security layer added on top. The easiest way to see that is through the developer's path.

Take a developer as the example. A developer writes code against the functional requirements received from a client, and the typical SDLC (software development lifecycle) runs through requirements gathering, development, testing, integration testing for multiple modules, pre-production testing, and finally deployment to the production environment. That is the SDLC everyone knows. Secure SDLC is the same lifecycle with cyber security knowledge injected into it. Instead of developing the code purely against the functional requirements, the developer thinks from the security perspective while building.

What changes in a secure SDLC? The phases stay the same — requirements, build, test, integrate, pre-production, deploy — but each phase gains a security question. During requirements, you ask which regulations apply to the data. During build, you ask how a malicious input could break this function. During testing, you add security test cases, not just functional ones. Security is not a phase you bolt on at the end; it is a lens applied to every existing phase.

Worked example — a simple employee web form. You build a simple web form that collects employee data — first name, last name, physical address, mobile number, and so on. A functional-only approach collects the data and stores it. A secure approach adds, during requirements gathering, the regulatory requirements that apply to that data. India recently passed the DPDP Act (Digital Personal Data Protection Act), a buzzword all over LinkedIn, which regulates any personal information held in digital format. In a secure SDLC, the form would add a consent tab or an extra questionnaire: before the data is collected, and before the form shares it with subcontractors or third-party vendors, does the employee's consent exist?

Functional requirement: "Collect employee name, address, and mobile number."
Security question added at the same phase: "Who are we allowed to share this with, and did the employee agree?"
Result: the form ships with a consent mechanism, not as an afterthought but as part of the requirements.

Sense-check: the data being collected is the same; the difference is that the system now asks permission before it takes and reuses the data — which is exactly what a data protection law demands.

Pitfall: treating security as the last phase. A common trap is to build the form first and add "security" during pre-production testing. The problem: the consent requirement is a data-design decision, not a bug that can be fixed by a test case. If the form was built without a consent flow, the fix means re-engineering the data flow — expensive and late. Secure SDLC exists precisely so that the security question is asked at the phase where it can still shape the design.

Real-world: this is exactly the shift that VAPT firms, product companies, and banks look for when they hire developers into application security roles — the same coding skill, plus an awareness of secure SDLC. The hiring signal is not "security expert" but "developer who already thinks about consent, validation, and exposure while writing normal code."

2.2 Privacy versus Security — Data Ownership and Data Protection Law

2.2.1 Security Means Protecting Assets

What is the very first question any security program asks? Not "which firewall should we buy?" but "what do we own?"

The word security in the IT world always has an object: security is about securing something, and in IT that something is called an asset. An asset is anything that has value to the organization — it can be a laptop, or the data sitting in a storage server, or anything else of value.

The asset-first rule. The first step in any security program is knowing how many assets you maintain and what they are. You cannot protect what you have not listed — an unlisted server is an unprotected server. Once you know your assets, you can move to the next step: deciding what controls protect each asset, usually based on the value of the asset. A database of customer records gets stronger controls than a spare office printer, because its loss hurts more. Since most data now lives in the cloud, the question becomes what level of controls you deploy for the data coming from your cloud systems.

The reference material frames the same idea as a risk assessment: identify the assets (hardware, software, data, communication lines), take inventory of the threats, find the vulnerabilities, and then choose the controls your budget allows. Every security decision downstream depends on this inventory.

2.2.2 Privacy: You Own Your Data

Privacy is about the rights of the data owner. You own your own personal data, and maintaining privacy over it is a fundamental right.

The ownership picture. Privacy means you, as the data owner, hold the full control over the data: to whom it is shared, for how many days it is shared with that person or vendor, whether that vendor is allowed to pass it on to some other third party, and when it can be deleted. Anything revolving around the data — any action taken on it — should be decided by the data owner, not by the organization holding it. The organization may hold the data physically, but the rights over it stay with you.

India: the DPDP Act. India's DPDP Act (Digital Personal Data Protection Act) was created precisely for this. It defines three categories of persons with clear roles and responsibilities:

Data principal — the person whose data it is; the owner of the data.
Data fiduciary — the entity that collects the data (for example, the company running the website).
Data processor — the entity that processes the data on behalf of the fiduciary.

The law gives the citizens of India power over how organizations handle their data: the fiduciary's roles and responsibilities are defined, and the provisions of the act make sure the data owner keeps full responsibility and control over who gets the data, for what purpose, and when it can be deleted.

Europe: the GDPR. Europe has the same idea under the GDPR (General Data Protection Regulation), enforced by the European Union in 2018. The GDPR terms are data subject (the person), controller (the entity deciding how and why data is processed), processor (who processes on the controller's behalf), and sub-processor. European citizens are concerned about their data being accessed, processed, or stored in countries other than the EU, which they do not trust. So the GDPR requires that organizations in countries outside the EU implement enough technical and organizational measures. The EU has listed about 8 to 10 countries it considers equal to European countries in terms of security measures. If data is transferred to any country outside that list, the transfer happens through standard contractual clauses or a data processing agreement, which contractually require enough technical and organizational measures. A processor that processes data under GDPR must implement enough technical controls to protect the security of the data.

How the two laws name the same roles. The vocabularies differ but the roles line up: India's data principal is Europe's data subject; the data fiduciary behaves like the controller; the data processor is the processor in both. When a company operates in both jurisdictions, it has to map one set of terms onto the other — a small example of why privacy compliance is largely a translation exercise between legal regimes.

Related to this is the principle of purpose limitation, one of the OECD privacy principles: data may be used only for the purpose for which it was collected. The word purpose is the operative one: the law does not ban the data's existence, it binds the data to the reason it was collected.

2.2.3 The Bank Example: Violating Purpose Limitation

Worked example — the bank and the telemarketer. You open an account in a bank such as HDFC and share your first name, last name, business address, and phone number for the single purpose of opening the account. The bank then sells that data to a telemarketing company whose job is to sell credit cards, and the telemarketers keep calling you with credit card offers.

Step by step:

Purpose declared: the data is collected to open the account.
Data collected: name, last name, business address, phone number — the minimum needed for that purpose.
Transfer: the bank shares the data with a third party, the telemarketer.
New use: the telemarketer uses it for credit card offers, a purpose you never signed up for.
Verdict: the purpose limitation principle has been violated — the data was taken for opening an account, but it was used for another purpose, without your consent. That is where privacy is lost.

Final answer: the bank violated purpose limitation, and your privacy as the data owner was breached even though the bank kept the data technically secure. Sense-check: the harm here is not that the data was read by an unauthorized person, but that it was used by an authorized holder for an unauthorized purpose.

Also note the relationship between the two ideas: privacy cannot be achieved where there is a security failure. If the data you handed over leaks, your privacy is gone no matter what rights you hold on paper. Rights protect you against misuse; security protects the data from escaping your control in the first place — privacy needs both.

Q: How does privacy differ from confidentiality? A: Confidentiality is about accessibility — it says who may access the data and who should not. Privacy is about the rights of the individual in protecting their data. In the bank example, confidentiality asks whether an unauthorized person can read your account data, while privacy asks whether the bank was allowed to share your data with the telemarketer at all — you never consented to that sharing, so your privacy was violated even though the data may have stayed confidential between the bank and the telemarketer. One-line check: confidentiality = "who can open the safe?" privacy = "did they have the right to put the data in that safe's hands?"

Real-world: this is why privacy engineering is its own job family now. Banks and fintechs hire privacy analysts specifically to map data flows against DPDP Act and GDPR obligations, and the standard contractual clauses and data processing agreements are the legal vehicles used in cross-border data transfers. The skill is not "know the law" alone — it is drawing the flow of data through systems and finding where the purpose and consent requirements break.

2.3 The CIA Triad — Confidentiality, Integrity, and Availability

What single frame explains most security scenarios you will ever read about? The CIA triad — and no, it is not a spy agency.

The first and most important frame in cyber security is the CIA triad — triad means a triangle. Security is not only about protecting the confidentiality of data. Security is an interlink between three properties: confidentiality, integrity, and availability. If any one of the three fails, information security has been compromised. This is a hard rule the whole course leans on: whenever a scenario is discussed, ask which leg of the triad it breaks.

The three also map to concrete mechanisms. Confidentiality is achieved with encryption: even if an accidental, unintentional disclosure happens, people still cannot view what is inside the data. Integrity is achieved with enough hashing algorithms, so there is no chance of modification or alteration of the data. Availability is achieved with enough backups — for example, servers running at 99.99% uptime — so legitimate users can access a specific service whenever they want.

Think of the triad as a three-legged stool: the data can stand only while all three legs hold. Knock out any one leg — the data is readable by the wrong person, or altered without approval, or unreachable when needed — and the whole meaning of "secure data" collapses.

Leg	Question it answers	Mechanism that achieves it	Failure example
Confidentiality	Who may read it?	Encryption, access credentials	Unauthorized person reads the data
Integrity	Is it exactly what it should be?	Hashing, digital signatures	Data modified without approval
Availability	Can legitimate users reach it when needed?	Backups, redundancy	Server floods, legitimate users blocked

2.3.1 Confidentiality

Confidentiality means the data is accessible only to authorized individuals. Authorized or legitimate persons can read it; everyone else cannot. If an unauthorized person reaches the data, confidentiality has been lost.

The plain-text origin story. The classic example: in the old days, all communication between a client and a server traveled in plain text. Anyone in the middle who captured the data could read exactly what was inside. If the same data is encrypted using an encryption algorithm, the person who captures it lacks the key, and the data reads as garbage. That is how encryption achieves confidentiality: restricting readable access to whoever holds the key.

The everyday mailbox example. Another everyday example: your credit card statement arrives in your Gmail inbox. Your Gmail is configured on four or five devices — your mobile, your laptop, a friend's mobile, and so on. Can you open the bank statement directly on any of them? No — the mailbox is protected by a password (often a combination of your name and a date), and only the person who knows it can view the statement. Restricting access to data based on credentials the end user holds is confidentiality.

Confidentiality applies to all three states of data. The same rule — only authorized people can read it — must hold no matter where the data is:

Data at rest — data stored on a server, for example a database server. Protect it with encryption at the storage layer and access controls on the server.
Data in transit — data moving between client and server. This is why everything should use HTTPS instead of HTTP: the transfer happens in encrypted form, so if a man in the middle captures it, it is not readable and confidentiality is achieved.
Data in use — data being used by applications; when two applications talk to each other through an API, that communication must also happen in a secure manner.

One state is easy to forget: data in use, because it sits in memory while an application works on it. An attacker with code running on that machine can read what the application is reading.

Real-world: AES and Triple DES are the encryption algorithms named for encrypting data; HTTPS is the transport-level practice; and the controls can sit at different layers — at the network layer you restrict access by IP address, at layer 2 (data link) by MAC address, at the transport layer by port numbers, and there is the newer zero trust idea: trust nobody; verify before granting access.

The weak points — where confidentiality fails on its own. Two classic failure points come from the professor's discussion:

Weak passwords. A password control with no complexity set — even a dictionary word — is a loophole, because dictionary attacks and other automated attacks can generate and try passwords at high speed. The control exists, but it is a broken one.
Default vendor credentials. Default vendor credentials are public knowledge: a quick search reveals the default username and password of common router and modem brands. If those defaults are never changed, an attacker can reach the router in admin mode, and confidentiality fails.

Takeaway: a control that is configured weakly is the same as no control at all from an attacker's point of view.

2.3.2 Integrity

Integrity means data inside databases cannot be deleted or updated without prior approval or authorization.

What integrity covers. If data is deleted or updated without the data owner's knowledge, that is lack of message integrity — a compromise of the data, where a third party enters the database server and changes the data as it pleases. Integrity also means consistency: the data in the primary database and the secondary database must match, and the value received must be trustworthy — a value coming from a specific server must not have been modified along the way.

The control analogy from the session. A home-life analogy: when the kids are not listening to you, you create a control — you will complain to their school teacher if they do not follow the rules. A control appears exactly when a situation is going out of control. The same logic applies to data: when someone might modify existing data, you need a control that keeps the data in line. The threat of the teacher keeps the children in line; the hashing control keeps the data in line.

Worked example — tampering with a transfer. You send an email asking the recipient to transfer 100 rupees from A to B. A man in the middle joins the conversation between source and destination and alters the value: 100 becomes 1000, or 10000.

Step by step:

Sender intends: transfer ₹100 from account A to account B.
Data enters the wire: the message "transfer 100" travels source → destination.
Interception and alteration: the man in the middle reads the message and changes the amount.
Receiver acts: the recipient executes the transfer of the altered value — ₹1000 or ₹10000.
Result: the exact value you intended to send has been changed in between the delivery of the message. That is a failure of integrity.

The same story appears again later with a payment of 500 rupees being tampered with and turning into 5000. Anywhere the value of the data has been changed by unauthorized tampering, integrity loss has happened. Final answer: integrity failure — the data is no longer what its owner intended. Sense-check: nobody stole the message and nobody destroyed it; they modified it, which is exactly the integrity leg of the triad.

How do you actually achieve integrity? The remediation question — all transactions are online now, so how do you actually achieve integrity? The answer that came up in the session is hashing: you pass the entire plain text through a hashing algorithm and it generates a hash value. The receiver takes the received data, passes it through the same hashing algorithm, and generates its own hash value. If the two hash values differ, the data changed during transit, and integrity has been compromised. Digital signatures extend the same idea with authentication of the sender.

Q: What mechanism or technique achieves integrity? A: Hashing. The source passes the whole plain text into a hashing algorithm and gets a hash value. The receiver inputs the received data into the same algorithm and gets another hash value. The two are compared; if the data was changed in transit, the hash changes, and the mismatch tells you integrity was compromised. A digital signature is the related mechanism that ties the hash to a sender. Key mental model: the hash is like a fingerprint of the message — any change to the message produces a different fingerprint, so a matching fingerprint proves the message survived untouched.

2.3.3 Availability

Availability means data and services are accessible and usable by legitimate, authorized users whenever they need them, without compromise or destruction. The systems must keep running up and working as expected.

Why availability is a business conversation. If there is only one system and it goes down, how does anyone know? The customer success team (the CSMs) reaches out: "We are so-and-so, we are excited about your onboarding." If the primary server has gone down, you need an alternative so the business is not impacted. For a single server you can create dual redundancy — a twin system that takes over when the primary fails. In the service level agreement (SLA) you define an uptime commitment for your server: 98 percent, or 99 percent, or 100 percent. A hundred percent is not realistically achievable — there is always a small glitch — so you always hold a commitment with your vendor: what is the uptime of my system, and if it goes down, is there a backup mechanism immediately available.

Availability thinking introduces two planning numbers:

RTO (recovery time objective) — how quickly the system needs to be up and running after a failure. "If the server dies at 10 AM, we must be live again by 2 PM" is an RTO.
RPO (recovery point objective) — how much data loss the business can tolerate; for how many days you can run the business even though some data has been lost. "If we lose the last day of transactions, that is acceptable; losing a week is not" is an RPO.

When you review the availability of any system, you look for the possible ways things can go wrong that would impact the system, which is a business impact analysis (BIA): how much will the business be impacted if a particular system goes down. Backups are then configured daily, weekly, or quarterly according to policy, and a redundancy site lets the data be brought back if the primary site goes down. The RTO tells you how fast to recover; the RPO tells you how much data you are allowed to lose; the backup schedule must satisfy both.

Worked example — the ping of death. A web server's job is to serve services to legitimate users.

Normal state: the server processes transaction requests from legitimate users.
Flood: an attacker continuously sends ping commands at the server, flooding it with traffic it must answer.
Resource exhaustion: the server's capacity is consumed by the flood of pings.
Effect on the legitimate user: when a legitimate user tries to access it, the server throws an error: "server is busy" or "server is down".
Result: the legitimate person cannot perform their transactions because the server cannot process the transaction request. That is a lack of availability.

Final answer: availability failure. Sense-check: the data was never read (confidentiality intact) and never modified (integrity intact) — but the system became unreachable on demand, which breaks the third leg. There are N number of attacks that make systems unavailable — denial of service, system shutdown — and they all fall under availability.

2.3.4 Student Questions and Answers

Q: How does availability impact security? A: Security is not all about protecting confidentiality. It is a triad — an interlink between confidentiality, integrity, and availability. If any one of the three fails, information security has been compromised. Take ransomware: a cipher algorithm converts your plain text into cipher text, turning a readable message into an unreadable one. The ransomware then demands payment of X amount to release the encrypted data — the person attacking has the key. Now the legitimate person cannot view the data at all. Lack of timely access to data for a legitimate person is also treated as a security failure, under the availability leg of the triad. A system must be available to legitimate users; if it is not, you have an availability problem, and availability is part of security. That is why backups are taken daily, weekly, or quarterly as configured, so that if the primary system goes down, the redundancy site keeps the business running as usual.

Ransomware is the perfect classroom example because it sits inside the triad's logic: the attacker does not need to steal anything — locking the data away from its owner is already a security failure under availability.

Q: Is it correct that the system must be available to legitimate users, and that availability can be hit by distributed attacks? A: Yes. A DDoS attack — distributed denial of service — is one of the N number of attacks that make your system unavailable, along with system shutdowns. Everything that blocks timely access for legitimate users comes under availability. The distributed part matters: instead of one machine flooding the server, many machines flood it together, which is far harder to block by blacklisting a single source.

Recap: the CIA triad is the lens of the whole course — every scenario you meet, ask first which leg it breaks. Encryption serves confidentiality, hashing serves integrity, backups and redundancy serve availability — and a failure of any one leg is a security failure, period.

2.4 The Three A's — Authentication, Authorization, and Accountability

Once you know the data is what it should be (integrity), readable only by the right people (confidentiality), and reachable when needed (availability), one question remains: who gets in, and how far?

The main job of security — whether computer security or network security — is protecting the information inside your laptop and protecting assets from unauthorized access: making sure only legitimate, approved users can access the data. That job is summed up in the three A's: authentication, authorization, and accountability.

The three A's in one line each:

Authentication — proving who you are. (Identity check: are you really this user?)
Authorization — what level of access you have been granted. (Permission check: what are you allowed to touch?)
Accountability — tracing who did what after the fact. (Audit check: the logs can point at a specific person.)

The order is a pipeline: a system cannot decide what you may do (authorization) until it knows who you are (authentication), and it cannot hold you responsible (accountability) unless it records what you actually did.

2.4.1 Student Questions and Answers

Q: What do the three A's stand for in security terminology? Someone guessed "accounting". A: Not accounting — accountability. The three A's are authentication, authorization, and accountability.

Authentication is the first step: proving who you are. If I enter the credentials linked to my username and the credentials in the database match, I get authenticated.
Authorization comes next: what level of access have I been granted? Being a visiting faculty member at the institute does not mean full access to the whole network — I am given access only to the folders relevant to my subject. The level of access is approved based on roles and responsibilities.
Accountability is the last one: if something goes wrong, the audit logs in the system let you trace back and identify who did what — any transaction can be traced to a user ID, and that user is accountable for it.

Why was "accounting" a natural but wrong guess? Because it sounds like the other two words — but it is a business activity (bookkeeping), not a security property. The correction matters beyond vocabulary: a security team needs to know who did what — and that is exactly what the audit logs give, so the word accountability names the property those logs exist to support.

Worked example — the payroll portal. The payroll example makes authorization concrete.

Authentication: a user ID is created for you and linked to your name and password. You log in with your credentials; the system verifies them and authenticates you.
Authorization: once you reach the payroll site, you do not get full access to it: you can see your own payslip and your Form 16, a handful of options — you cannot go in as admin, and you cannot see other employees' payroll.
Accountability: every transaction you make is tied to your user ID in the logs.

Final answer: the portal authenticates you, then limits you to your own records — that is authorization: it defines what level you are authorized to do. Sense-check: you passed step 1 (proving who you are) but did not automatically gain step 2's full powers; the level of access is a separate decision.

The campus analogy. A campus analogy: you enter the campus, show your ID card, and the physical security allows you in. That does not mean you can enter every floor or every restricted access area. You cannot walk into the data center, and you cannot enter specific project areas that only the people working on that project can enter. If the organization supports a development project for an HSBC client, only the people working on that project have access to that area — the rest of the employees do not. That segregation is what you see in offshore development centers (ODCs). So the campus authenticated you, but inside, your authorization is limited. One badge got you through the gate; it did not give you every door.

2.4.2 Auditability and Why Logs Matter

Auditability is the property that supports accountability. Whatever you do, if well-established logs exist, then tomorrow — when you want an instant review or need to trace back an event — the logs let you audit it. If there are no logs, you do not know who did what: auditability is impossible and accountability fails. Logs are the prerequisite for both.

Pitfall: authorization without accountability is a blind spot. A system can perfectly authenticate users and limit their access, yet still be unsafe if it records nothing. The classic failure: an employee's account is used to make changes, no log exists, and nobody can say who sat at that keyboard. The lesson: the three A's are a chain — authentication starts the chain, authorization limits the action, and accountability only exists if the logs captured it. A gap in any link breaks the whole audit story.

Real-world: audit logs are exactly what internal audit and third-party ISO external audits pull up when they review access activity; without them, neither accountability nor auditability can be shown. When an external auditor asks "who touched this system and when?", the only acceptable answer comes from logs — which is why log retention and review are themselves control requirements, not optional extras.

Recap: authentication proves identity, authorization grants the right level of access (roles and responsibilities decide it, not the person), and accountability traces every transaction to a user ID through audit logs. Remember the correction: it is accountability, not accounting.

2.5 Computer Security, Network Security, and Cyber Security

Is "network security" the same thing as "cyber security"? The terms are used interchangeably in headlines — but they name different scopes, and the differences decide where you place your defenses.

Security is one term, but it shows up under many names — network security, cyber security, computer security, infrastructure security, endpoint security — and it is worth asking why so many kinds exist and where the lines are drawn.

2.5.1 Three Kinds of Security

Three kinds of security, three scopes:

Network security protects the network. Networks can be protected by the firewall, by an IPS (intrusion prevention system), by an IDS (intrusion detection system), by NAC (network access control), and similar tools. The objective is the people and systems that need protection: the policies and procedures kick in there.
Cyber security protects your assets from the external unit or from damage caused by an external system. Securing the system from cyber attacks is exactly why it is called cyber security.
Computer security protects the systems and the data — the safety of your data, services, and resources.

One-line split: computer security guards the machine itself, network security guards the roads between machines, and cyber security guards everything from external attackers.

Broader still, the field spans infrastructure security and the security operations center (SOC) with its SOC analysts, who watch the monitoring systems day to day. The SOC is where all three scopes meet in practice: the analysts watch the network, the endpoints, and the cloud posture from one room.

2.5.2 Layering Security at Different Layers

Where security applies depends on where it happens: if you are protecting at the network level, that is network security; if you are protecting at layer 7, application-layer security comes into the picture. The same control logic changes layer:

If you allow or block entry of data using IP tables (internet protocol tables), you restrict access purely by IP address — that is the network layer, layer 3.
If you restrict access to the system purely by the MAC address of the laptop — the physical address — that is layer 2.
If you restrict connection establishment by port numbers, that is the transport layer.

Q: What is ZTP (zero trust)? A: Zero trust is a brand-new technology that is coming into the picture — the idea of trusting nobody and verifying before granting access. It is completely new territory. For now, the advice is to first focus on the syllabus, and these new technologies can be covered as a discussion after the core topics.

Zero trust flips the old perimeter mindset: instead of "trusted inside, untrusted outside," it treats every request — even from inside the network — as unverified until proven. You will meet this idea again in the course, so the one-liner to carry forward is: trust nobody, verify before granting access.

2.5.3 Defense in Depth

Defense in depth means deploying multiple controls at different layers so that an asset is protected by several independent lines.

Worked example — the layered house. Example: you deploy a physical security guard at the gate of the campus, another security layer at the basement, and one more at the house itself. For a person to enter, they pass multiple layers of protection. They can be captured the moment they enter by the CCTV camera, or captured at the next checkpoint. In this way you set up multiple layers of defense or protection around the asset using multiple controls.

Walking the attacker through the layers:

Layer 1 — the gate: the guard challenges every entry.
Layer 2 — the basement: a second checkpoint limits who goes deeper.
Layer 3 — the house: the final door only opens for the few who made it this far.
The net: CCTV at each layer records every attempt, whether it succeeds or not.

Final answer: no single control has to stop the attacker — each layer must be bypassed, and each bypass risks being caught on camera. Sense-check: the attacker's cost (effort and detection risk) multiplies with every layer, which is exactly the goal.

The same pattern applies to access: at every level there are bypass possibilities, and each extra layer forces an attacker to bypass one more control. Nobody can ever say "my system is 100 percent secure" — the honest statement is that you are doing maximum effort to prevent unauthorized access and to make exploitation as hard as possible.

The honest claim about security. The phrase "100 percent secure" is a myth: the attacker only needs to find one hole, while the defender must close all of them. Defense in depth does not promise to stop every attack — it promises that any successful attack must cross several independent lines, which shrinks the attack surface. Deploying multiple controls at multiple layers reduces the attack surface of the system: most vulnerabilities get eliminated and the surface that can be attacked shrinks.

Real-world: defense in depth is the standard posture of banks and product companies; you rarely see a single control protecting anything important. The same idea shows up again in the discussion of how an external attacker works — every extra layer forces the attacker to spend more effort and make more noise.

Recap: computer, network, and cyber security protect different scopes — machine, connections, and external threat. Controls apply at different layers (IP at layer 3, MAC at layer 2, ports at transport). Defense in depth layers independent controls so no single failure — and no single bypass — exposes the asset.

2.6 Assets, Threats, Vulnerabilities, and Controls

What is the chain that turns a weakness into a breach? Four words — asset, threat, vulnerability, control — and the whole course is built on tracing them in order.

2.6.1 Assets and What a Threat Is

Take a Windows server: it is an asset. Look at it from an IAM (identity and access management) perspective — the current way credentials are stored in a database server. What are the threats to it? An attack is someone trying to steal the data, or someone trying to modify the data; that modification can be done by an internal employee just as easily as by an external source.

The word threat is a generic dictionary word: a threat is something harmful that may happen to a person, a country, and so on. If there is always a threat from a neighboring country, that country is in trouble. In IT, the same idea applies to systems.

Threat versus attack — the distinction that matters. A threat is the potential for harm — the possibility that something bad happens. An attack is what happens when the threat is actually carried out. The neighboring country is a threat when it merely has hostile intentions; it is an attack the moment its soldiers cross the border. In IT, the threat is the possibility that someone steals or modifies your data; the attack is when they actually try.

Worked example — parliament and the unchecked gate. Consider the example of someone entering parliament and performing an illegal activity, something they were not supposed to do.

The event: a person walks into parliament and carries out an activity they were not authorized to do.
The question: why did this happen at all?
The root cause: lack of proper control — no proper checks at the gate. Anyone could walk through because nobody challenged them.
The security label: that absence of checks is a vulnerability — a weakness in the system that the person exploited.

Final answer: the incident happened because of a control failure — the gate had no proper checks, and the absence of checks is a vulnerability. Sense-check: no technical hack was needed; the weakness was administrative — the entry control did not exist.

2.6.2 Vulnerabilities

A vulnerability is a security weakness that exists in your system.

The parliament analogy. In the parliament example, the weakness was the gate with no proper checks. The analogy given: when we have weaknesses in our bodies, doctors prescribe tablets and we use them; the same way, when a system has weaknesses, we try to identify them before they are exposed publicly. Managing those internal or external vulnerabilities is a large part of what this course discusses. The body is vulnerable without the tablets; the system is vulnerable without the control. A failure of control creates a weakness, and a weakness is a vulnerability.

Where do vulnerabilities live in a system? The typical system runs a three-tier architecture: a front-end application, a middleware layer, and the backend. The security question is: in which plane is there a chance of unauthorized entry? If a server accepts whatever request hits it, with no proper checks on the request, that is a failure of control. A failure of control tries to exploit the weaknesses in the system; if the control itself is not working, it creates a weakness, and a weakness means a vulnerability in the system.

One more point on threat sources: a threat to a country like India does not need to come from an unfriendly neighbor. Internal weaknesses in the security system may be exactly what let a person enter. The same holds for organizations: the attacker may already be inside. The most dangerous threat is not always the loudest one from outside — an insider who is already past the perimeter has a head start.

2.6.3 Controls

To overcome vulnerabilities, you apply controls. Controls come in two classification schemes:

1. By category — what kind of measure it is:

Physical — the level of security you maintain at the physical level (guards, CCTV, doors).
Administrative — setting up policies and making sure a least-privilege model and need-to-know basis are deployed instead of directly granting access.
Technical — technology-related controls (firewalls, encryption, monitoring tools).

2. By functionality — what the control does in time:

Preventive controls stop something from happening.
Detective controls detect something that is happening.
Corrective controls fix things after the fact.
Deterrent controls scare or discourage a person from doing wrong.

Policies as the management layer. A policy is the management tone toward an issue. If something needs to change or be updated in an organization, it is the responsibility of the managing director of the company; when the organization head says something must be followed, the employees follow it. That is a policy: the management's direction, which becomes the reference for all organizations — internal and external — to understand the security and privacy obligations currently in force. The policy is applied to the classes of confidentiality, integrity, and availability: whether you want to enforce 20 percent, 50 percent, or 80 percent of the policy happens through how the policies are configured on the existing devices, and employees in the organization then follow those configured policies. The policy states the rule; the configured controls decide how much of the rule is actually enforced.

Exam note: the two control classification schemes — physical/administrative/technical versus preventive/detective/corrective/deterrent — are the kind of contrast that shows up in questions on controls. Practice classifying any given control under both schemes: a firewall is technical (category) and preventive (function); a CCTV camera is physical and detective; a backup-and-restore process is technical and corrective; a warning banner is administrative and deterrent.

Real-world: the asset → threat → vulnerability → control chain is the skeleton of every risk assessment. You list the assets, identify what threatens each, find the weaknesses, and then choose controls — and that four-step loop is what auditors (internal, third-party, ISO) verify when they review an organization.

2.7 Cyber Threats — Sources, Types, and Impact

What makes an action a cyber threat rather than just a technical glitch? The answer is one word: intention.

2.7.1 What Counts as a Cyber Threat

A cyber threat is any act — a malicious act, meaning there is a malicious intention behind it — that tries to gain access to a network or a computer without authorization, without permission from the legitimate owner or data owner.

The defining feature is malicious intent. Any malicious activity intended to perform an unauthorized action is a cyber threat. The word malicious does the work: a program that crashes by accident is a bug; the same program deliberately crafted to crash the system is a threat. Cyber threats can damage a single system, or they can affect a whole network or the information it contains.

A threat can be carried out in many ways: inserting malware, sending a phishing email, launching a denial of service, social engineering, SQL injection. All of these find the weaknesses — the vulnerabilities — in the system, exploit them, and compromise the security of the systems. Notice the connection back to the previous section: every threat travels along a vulnerability to reach its target.

2.7.2 Threat Sources

Anyone with a bad intention can perform cyber threats. Named sources: business competitors, hackers, and rogue employees. It does not matter which category the person comes from; what matters is the intention to damage systems.

A competitor wants your market data, a hacker wants notoriety or money, a rogue employee wants revenge or a payout — different motives, same category of act. This is why threat modeling never asks only "who?" but always "what do they want, and what would they do to get it?"

2.7.3 Malware Families: Virus, Worm, and Trojan

Virus, worm, and Trojan are all sets of lines of code — but the objective of each is different:

The three families, by objective:

A Trojan is a line of code that captures the information on the laptop and shares it to some other person. It arrives disguised as something useful — the name comes from the wooden horse of Troy: it looks like a gift, but soldiers are hiding inside.
A worm is also a set of lines of code, but its objective is to self-propagate among the entire system, making the system down, hung, or otherwise unusable. The worm's special talent is spreading itself from machine to machine without needing a carrier file.
A virus is code written with the main objective of damaging a system file or program file. Like a biological virus, it replicates by attaching itself to other programs.

The professor's one-liner to remember: they are all lines of code, but each has a different objective — stealing information (Trojan), spreading and disabling (worm), damaging files (virus). Keyloggers belong to the same family — code that records what is typed.

Pitfall: using the names interchangeably. In everyday talk people say "I got a virus" for any infection — but the three families behave very differently. A Trojan does not replicate; it hides. A worm does not need a host file to spread; it uses the network itself. A virus needs to attach to a program. If you identify the wrong family, you look for the wrong behavior on the system and miss the attack.

Social engineering means calling a person and making them provide the information you are requesting. It is one of the easiest ways in, because a finance person or a non-IT person often does not understand the importance of checking whether an email comes from a legitimate person.

Worked example — the phone call. A caller claims to be from the company's IT help desk, mentions the name of a real system administrator (information they gathered earlier — maybe from a social profile), and asks a finance employee to "verify" their username and password, or to confirm the payroll server address.

Gather: the attacker learns one or two real names from public sources.
Contact: the attacker calls or emails a finance or non-IT person, not a technical one.
Pressure or urgency: the request sounds routine — "help me verify" — so the target does not stop to check legitimacy.
Extract: the target volunteers the information.
Result: no exploit needed — the human handed over the access.

Final answer: a social engineering success; the technical controls were never even tested. Sense-check: the weakest link was not a software bug but a person who had no reason to doubt a plausible-sounding request.

Attackers will always try to target a C-level executive or someone from a non-IT background, because those people are less focused when they work with IT systems — and that makes the attack easy. The defense that matters here is not a firewall: it is awareness training and the habit of verifying identity through an independent channel.

2.7.5 Impact of a Successful Threat

When a threat succeeds, the damage shows up in several forms: data loss, financial damage, privacy violation, disruption of operations, and reputation damage. Reputation damage is the chain where it hurts the most: when the news is public that a company's data has been lost, there is a reputation loss, and a reputation loss directly results in the failure of the business.

Why reputation is the deepest damage. Data can be restored, fines can be paid, operations can be resumed — but the trust of customers cannot be bought back with a patch. The chain: breach becomes news, news becomes reputation loss, reputation loss becomes customers leaving, and lost customers become a failed business. This is why breach-response teams plan the announcement as carefully as the technical recovery.

Real-world: this is why breach-news cycles cost companies more than the fine — the market and customer reaction follows the reputation damage.

Recap: a cyber threat is any act with malicious intent to access a system without authorization; sources are anyone with bad intention (competitors, hackers, rogue employees); malware families differ by objective (Trojan steals, worm propagates, virus damages); social engineering targets people rather than systems; and the deepest impact of a successful threat is reputation damage that can fail the business.

2.8 Threat Modeling — MITRE ATT&CK and Attack Frameworks

An attack is not one event — it is a sequence of stages. And if the stages are known in advance, the defenders can say exactly where an attacker currently stands.

2.8.1 Phases of an Attack

To analyze attacks, the industry uses frameworks, and the framework named in the session is MITRE ATT&CK. Each stage of an attack has its own phase.

The phase idea. Monitoring systems integrate these frameworks so that you can know which level the hacker is at: is he in the initial phase, is he in the exploitation phase, has he reached the escalation mode — meaning he already holds admin privileges — or is he doing exfiltration, the data leaving the system and going outside the network? Exfiltration means the attacker has already done everything: gained access, gained admin access, and is now in the process of extracting data from the system to the external world.

The stages in order:

Initial access — the attacker first enters the system (a phishing link clicked, a vulnerability exploited).
Exploitation — the attacker uses a weakness to run code or misuse a system.
Escalation — the attacker raises privileges until they hold admin-level control.
Exfiltration — the attacker moves data from inside the network to the outside.

The power of a framework like MITRE ATT&CK is that it names every step in between — not just these four, but the full chain of tactics and techniques attackers actually use. Most security product companies develop their products using one of these threat models. With continuous monitoring, the system can easily trace out and identify which stage an attack is in — exploit stage or exfiltration stage — so that the response can match the phase.

Worked example — reading the stage from the alert. A SOC analyst sees an alert that a database server has started sending large amounts of data to an external address. Reading it through the framework:

What happened: data is leaving the network to an address outside the organization.
Which phase is this? Not initial access (no entry yet) and not exploitation (no payload at work) — the attacker is past access and privilege steps.
Verdict: this is the exfiltration phase.
Right response: block the outbound transfer and trace back — the attacker has already been inside for a while.

Sense-check: identifying the phase matters because containment during exfiltration is different from containment during initial access — here the priority is stopping the data flow and cutting the path the attacker used, not just patching the entry point.

2.8.2 Countermeasures

What would be the countermeasures — the security measures — against these threats?

The countermeasure toolkit from the session:

Implementing controls at the access level.
Continuously monitoring the network, which can be done with IDS (intrusion detection system) or IPS (intrusion prevention system) — these are the technical controls for preventing these sorts of threats. The IDS watches and reports; the IPS watches and blocks.
Providing continuous security awareness training to all employees.
Regularly checking the systems for security: a monthly scan or a quarterly scan with security tools, identifying any vulnerabilities that exist in the system.
Ensuring the level of access granted is the minimum needed, and periodically reviewing user access using SailPoint or similar tools, to make sure the right people have the right level of access.

Deploying these controls — physical, administrative, or technical — definitely reduces the attack surface of the system: most vulnerabilities are eliminated and the attack surface shrinks.

Real-world: SailPoint is an identity governance tool used for exactly this — periodic access reviews (certifications) where managers confirm or revoke employee access. MITRE ATT&CK is the de facto industry standard used by SOCs to describe attacker behavior. When you read a breach report that says "the attacker moved laterally using technique X," the language of that report comes from these frameworks.

Recap: attack frameworks like MITRE ATT&CK let monitoring systems place an attacker in a phase — initial access, exploitation, escalation, exfiltration — so the response can match the stage. Countermeasures: access-level controls, continuous monitoring (IDS/IPS), security awareness training, regular scanning, and least-privilege reviews (SailPoint).

2.9 Types of Cyber Attacks

If the CIA triad is the map of what can break, the attack types are the ways attackers actually break it. The syllabus overview names seven common attacks that appear at the application layer: malware, denial of service, session hijacking, phishing, SQL injection, zero-day attacks, and DNS tunneling. The session then walks through the major attack types in detail, starting with the long-term and the silent ones.

2.9.1 Advanced Persistent Threats (APT)

An APT — advanced persistent threat — is a network attack in which an unauthorized person gains access to the network and stays there very silent, without being detected, for a long period of time.

Worked example — the disguised file. The example: the attacker has entered your laptop but has changed a file name in such a way that the file looks like part of your program files.

Entry: the attacker gains access to the laptop through some initial foothold.
Disguise: instead of acting loudly, the attacker renames their malware so it blends into the program files directory — sysupdate.exe next to real system files, for instance.
Silence: the file sits there, behaving like part of the system, for weeks or months.
Result: nobody can trigger or identify whether an attack has really happened or not.

Final answer: an advanced persistent threat in action — advanced in technique, persistent in time. Sense-check: the attack's power comes from being unremarkable; a loud attack gets cleaned up, a quiet one survives.

The three words each carry a meaning: advanced (sophisticated methods), persistent (long dwell time), threat (a real actor behind it, often state-sponsored or well-funded).

2.9.2 Backdoor Attacks

A backdoor is a method of bypassing your normal authentication and gaining access at the OS level or the application level. Instead of passing your credentials — the username and password you use to log in — the attacker enters through a backdoor mechanism rather than a direct mechanism.

Worked example — the secret path. An attacker installs a small malware through a phishing email, which infects the laptop with a Trojan.

Phishing email: a convincing email is opened, and the attached malware infects the machine with a Trojan.
First entry: the Trojan gives the attacker a foothold on the server.
Build the backdoor: instead of bypassing the normal controls, the attacker — the moment he enters the server — creates another path for himself to enter whenever he wants. That is the backdoor: a secret path only he knows.
Hide it: he changes the way he entered by creating a system-identified name that is unknown to anybody.
Steady access: once he has access through the backdoor, the attacker can change whatever he wants to change in the system.

Final answer: a backdoor attack — the attacker negated the normal authentication procedure and gained repeated remote access. Sense-check: the login page is irrelevant now; the attacker no longer needs it, because his own private door exists.

The building analogy. In normal life there are "backdoors" to corporate buildings — an alternative way of entering the premises without going the legitimate way. The cyber backdoor is the same idea: a type of malware that negates your normal authentication procedure for access to a system, and as a result grants remote access to resources — application servers, databases, or file servers. A typical example is a backdoor Trojan, which includes file inclusions that exploit a vulnerability. Ideally, nobody knows the backdoor exists unless a deep scan is performed — which is why detection relies on deep scanning and behavioral monitoring rather than the usual login checks.

2.9.3 Buffer Overflow

Buffer overflow is an attack that belongs to people from a coding background. Programming languages set boundaries for the buffer. A buffer is a temporary storage area. When code tries to manipulate the memory that is allocated — when it writes beyond the buffer's capacity — data leaks out of the buffer, which leads to corruption of the data or overwriting. The name says it: the buffer overflows.

The water-glass picture. Think of a buffer as a glass of fixed size. The program promises to pour only what fits — but if it pours more than the glass can hold, the water spills over the edge and soaks whatever sits nearby on the table. In memory, "soaking the table" means overwriting the memory that belongs to neighboring data or even the code that controls what the program does next. The name says it: the buffer overflows.

A buffer overflow is a simple code error in a program that enables hackers to exploit the loopholes, steal data, or access corporate systems. It typically happens when the program is waiting for user input — in those scenarios, a user can input more than the buffer holds, and the overflow happens.

Pitfall: assuming 'big input' is handled somewhere. The professor's warning: buffer overflows typically happen when the program waits for user input. A login field, a search box, a file name — anywhere the programmer assumed a reasonable length without checking. The fix direction is input validation: never trust that input will stay inside the allocated size; check the length before copying it into the buffer.

2.9.4 Man-in-the-Middle Attacks

In a man-in-the-middle attack, the sender is A and the receiver is C, and B is in between. All the communication happening between A and C is captured by B and can be modified by B. The attack intercepts and relays the messages between the two parties who believe they are communicating directly with each other.

The mail-forwarding picture. A writes a letter to C and posts it. B — who works at the post office — opens the letter, reads it, changes the amount, reseals it, and delivers it. Both A and C believe the letter traveled straight from hand to hand. The same illusion happens on the wire: A and C each believe they talk directly, but every packet passes through B, who can read and alter it — which is exactly how the 100-rupee transfer became 1000 in the integrity example.

The defense follows directly: if the communication between the two parties is in encrypted form — an unreadable format — then even if the man in the middle exists, he cannot understand what the two points are communicating. Encryption does not stop B from seeing the packets; it stops B from making sense of them or altering them undetected.

2.9.5 Denial of Service and Distributed Denial of Service

A denial of service attack wants to ensure that legitimate users cannot access or process the systems they are supposed to use. If the attack successfully prevents authorized users from accessing a server or a website, that is a denial of service attack. If the attack is done from one system, it is a single denial of service; if it is done from multiple systems, it is a distributed denial of service (DDoS) — instead of one system attacking the server, multiple systems try to make the server down.

Single versus distributed. The service is denied in a distributed way, making the service unavailable. The scale is the difference: one attacking machine can be blocked by blacklisting its address, but hundreds or thousands of machines (often a botnet of hijacked systems) flood the target together, and blocking them one by one is impractical. The ping of death example (flooding a web server with ping commands until legitimate users get "server is busy" errors) is a denial of service in action.

2.9.6 Cross-Site Scripting (XSS)

Cross-site scripting is more about programming. In a form, where there is a field for the user to enter whatever data they want, an attacker who is able to execute their malicious script — and the script's output is populated immediately in the user's browser — has performed cross-site scripting.

Worked example — the injected script. Imagine a review section on a shopping site where anyone can post text that other users will see.

Find the entry: the attacker finds the text field that echoes user input back to other users' browsers.
Inject: instead of a normal review, the attacker types script code into the field.
Execute: every visitor who views the page runs the script in their own browser.
Effect: the script can steal the visitor's session cookie, redirect them to a fake login page, or read what they type.

Final answer: cross-site scripting — the site trusted the input and ran it as code. Sense-check: the victim's browser is doing the damage with data the site itself served, which is why the attack is so hard for users to detect.

XSS can be classified by where the code executes: when the malicious code is executed client-side, it is called client-side cross-site scripting. The defense follows the same principle as buffer overflow: the input must not be trusted — the application should treat user-supplied text as data, never as code.

2.9.7 SQL Injection

SQL injection means injecting SQL queries so that you can bypass the SQL database's authentication. Instead of entering your username and password, you enter SQL queries, and if you are able to bypass the SQL server, that is a SQL injection attack.

Worked example — the always-true login. A login page builds its query by pasting the username and password fields directly into a SQL statement. Instead of a normal username, the attacker types something like ' or '1'='1.

Normal query built by the page: SELECT * FROM users WHERE username = '' AND password = ''
Attacker input: username field gets ' or '1'='1, password field gets the same.
Query the server actually runs: the WHERE clause now contains or '1'='1 — and 1=1 is always true.
Result: the database returns a matching row, and the login succeeds without valid credentials.

Final answer: SQL injection — the database's authentication was bypassed. Sense-check: the site trusted the input as part of the query instead of treating it as data, and the attacker exploited exactly that trust.

It is a very common vulnerability in web applications. It can not only allow the hacker to steal the data, but also to modify the data. When you can modify the data in the database, integrity is compromised — SQL injection breaks the I of the CIA triad. (Stealing it breaks the C.) The fix family: parameterized queries and input filtering — the same "treat input as data, never as code" rule.

2.9.8 Zero-Day Exploits

A zero-day attack is a type of vulnerability where the weakness does not have a necessary patch that can prevent the systems from being attacked by the zero-day exploit.

Why 'zero days'? Normally, when a vulnerability exists in a system, someone says "if you patch to this version, the vulnerability will leave your system." But there are some exploits where even that does not work — there is no patch available to fill the vulnerability. Those scenarios are called zero-day exploits. The name says it: zero days of warning. The vendor learned of the weakness the same day the world (or the attacker) did — so there are literally zero days between discovery and attack in which a fix could exist.

Recap of the attack zoo: APT hides quietly for a long time; backdoors create a secret second entrance; buffer overflows spill past memory boundaries; man-in-the-middle reads and alters traffic between two trusting parties; DoS/DDoS denies service; XSS runs script in the victim's browser; SQL injection bypasses the database's authentication and breaks integrity; zero-day exploits have no available patch. Each maps onto the CIA triad — when in doubt, ask which leg it breaks.

2.10 The Zero-Day Assignment — Defending Without a Patch

What do you do when a vulnerability is known but there is no fix for it? That is the one question of this session's assignment — and the honest answer is harder than it looks.

2.10.1 The Assignment

The problem statement. Here comes a small assignment. You are a cyber security engineer. You want to protect your systems, servers, or networks from a zero-day exploit, and there is no patch available to protect the systems. What are the possible options you would try so that the impact of the zero-day attack on your systems can be marginally reduced? List down all the possibilities — three to five ways — you can think of for protecting your systems, networks, or servers from zero-day attacks. There is no time to fill the gap for this vulnerability, so what can you do? This assignment is to be answered in the next session.

Notice the two constraints hiding in the wording:

No patch exists — you cannot close the hole itself.
Impact must be reduced — the wording says "marginally reduced," so the goal is damage limitation, not prevention.

This makes it a different kind of security thinking: without a fix, the classic controls (patch, update) are off the table, and the answers have to come from detection, isolation, monitoring, and containment.

2.10.2 EDR and XDR — the Proposed Answer and Why It Falls Short

During the discussion, EDR was proposed. EDR — endpoint detection and response — and XDR — extended detection and response — work differently from the antivirus of the golden days.

How EDR differs from old antivirus. The old model: a central manager pushed signatures, an agent on each machine compared incoming code against those signatures, identified matches, and dropped the threat. EDR and XDR do not run on signature patches. They run on behavior: abnormal code, abnormal process communication.

The key idea: signature-based antivirus can only catch what it has already seen; behavioral detection can catch something it has never seen — which is precisely the zero-day situation.

Worked example — CrowdStrike watching a process conversation. Example: CrowdStrike, an EDR tool.

Normal baseline: each process on the endpoint talks to a well-known set of other processes; this pattern is learned as normal behavior.
The anomaly: an abnormal process is triggered — for example, an ordinary document viewer suddenly starts communicating with a system utility it has never talked to before.
Detection: CrowdStrike sees the abnormal process-to-process communication immediately.
Response: the tool itself responds — either by blocking the communication, or by alerting the admin to take action.

Final answer: behavioral detection caught a never-before-seen interaction without needing a signature for it. Sense-check: this is exactly the strength EDR brings to a zero-day scenario — the attack pattern is new, but the abnormal behavior is visible.

But if you are thinking that EDR is the answer for the question, the answer is: no, definitely not.

Q: Could the answer be EDR/XDR endpoint detection? A suggestion was made to correct it from the network — checking the blacklist system and disabling all the ports. A: No — EDR is definitely not the answer. And think about the constraint in the question: if you are working for a banking company, the server cannot be disconnected — taking it down would cause a lot of business loss. You are not supposed to make the system unavailable. You must keep the systems and networks available while still limiting the impact from the zero-day as much as possible. The concrete answer is not urgent to produce today; the next session will come up with the answer.

Why is EDR not the answer? Not because it is useless — it is a legitimate layer — but because the question asks for what you would do in your own response plan, and EDR is a detection-and-response tool rather than the full answer to impact reduction under the availability constraint. The answer must respect the rule that the system stays up.

2.10.3 The Banking Constraint

The availability constraint is the examinable core of this assignment. The banking example sets the real constraint for any solution to the zero-day problem: availability cannot be sacrificed. The server stays up, the business keeps running, and the impact of the exploit is limited as much as possible. Whatever your three to five possibilities are, they must respect that constraint.

So any proposed answer that takes the system down — disconnecting the server, shutting ports wholesale, powering off the machine — fails the constraint, even though it technically limits the attack. A banking server that is offline is also a business loss.

Recap: the zero-day assignment asks for three to five impact-reduction options when no patch exists, under the constraint that the system must stay available (the banking constraint). EDR/XDR was proposed and ruled out as the answer. Bring your list of possibilities to the next session for discussion.

2.11 How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

How does someone attack a network they have never been inside? The answer starts with a walk around a house — and ends with a step-by-step method any external attacker (or red team) follows.

2.11.1 Student Questions and Answers

Q: The most powerful threats are the insiders, and for internal security we have the need-to-know basis. But how do VAPT teams protect against outsiders? As a red team employee you can attack from inside, but outsiders don't have access — so how do you act like an outsider and attack the organization's servers?

A: Take an analogy. Imagine a five-bedroom villa. How do you know whether a thief can enter your home or not? You walk around the 360 degrees of your home and check where the possibility of entry is. If you have a four-foot wall, you notice there is no electric wiring on top — so there is a high chance the thief enters over the back-side wall. Or the front-side gate has no checks, so the thief walks in there. Based on those entry points you find where exactly the thief can enter. In the same way, in an infrastructure, if you want to perform an external hack, what should you know? You need a blueprint of the system: how the network diagram is configured — where the database servers are, where the email servers are, where the internal servers are. How does a hacker find out the architecture without even entering the network? That is what ethical hacking stages are for: the reconnaissance phase, then the information-gathering phase, and then you try to exploit based on the gathered information. You gather information about the servers, then you ping those servers, and based on the responses you can know whether there is a firewall in between. If packets drop at certain paths when you ping, that can be an indication of a firewall — firewalls are often configured so that any ICMP request hitting the device frequently will get blocked. Then you try to understand what type of server is used: a web server, Apache, or a database server. If you inject some query into the username and password fields and the error message shows the backend is an SQL server — "SQL so-and-so version is running" — and the version is outdated, you look up the common vulnerabilities in that SQL Server 2.1 (as stated), and it lists all the vulnerabilities and loopholes in that server. The hacker tries the possibilities one by one and exploits the system. So for someone external to enter, he must first understand the entire skeleton of your system — the infrastructure. Then he sees how the infrastructure is configured so he can bypass the configured rules. If certain IP addresses are whitelisted at the network level, he can do IP spoofing — changing the source IP address in the packet. If the firewall blindly trusts the whitelisted source IP and does not detect the spoofing, that is a loophole. After entering, he finds out which database server and version, what common vulnerabilities exist, and in the IAM part, whether the default credentials of the server were changed — he drives through all the possibilities, or he sends a falsified email pretending to be the IT help desk: "you need to reset your password, click here." Clicking directs to a fake page where your credentials get captured. So there are N possible ways to bypass a system. That is why, even if one level of bypass succeeds, multiple levels of bypass are needed when you apply defense in depth — more controls. As you said, the need-to-know basis means by default you grant minimum privileges for a person to carry on their business; when the business needs require it, you grant admin-level access. That is the least-privilege model: by default everybody is restricted to a minimum level of access, and access is increased slowly. Controls are deployed at different layers — physical manner, administrative manner (policies and procedures), or technical manner. Nobody can ever say their system is 100 percent secure; we do our maximum effort to secure from unauthorized access. If somebody wants to attack from the external source, he will do footprinting — gather the necessary information — then understand what systems and servers are used, find the vulnerabilities and loopholes, and exploit one or the other.

The villa maps onto the network like this:

Villa walk-through	Network equivalent
Walk 360 degrees around the house	Reconnaissance — map the external surface
Notice the four-foot wall with no wiring	Find the weak entry — an unguarded service
Notice the gate with no checks	Find the unauthenticated or misconfigured entry
Enter through the weak point	Exploit the found vulnerability

Worked example 1 — the version-disclosure giveaway. The error-message case shows how a tiny detail leaks a big secret:

Probe: the attacker injects a query into the username and password fields of a login form.
Leak: instead of a generic error, the application responds with a message like "SQL 2.1 version is running" — revealing the exact backend database and its version.
Look up: the version is outdated, so the attacker searches the known-vulnerability lists for that SQL Server version.
Exploit: the list provides the loopholes; the attacker tries them one by one until one works.

Final answer: reconnaissance succeeded through information disclosure — the error message gave away the stack. Sense-check: the server was not "hacked" at this stage; it volunteered its own blueprint. This is why error messages in production should be generic — "unable to process your request" instead of "SQL Server 2.1, build 7601".

A second bypass route attacks the network rules themselves rather than the software.

Worked example 2 — IP spoofing against a whitelist. Once the attacker understands how the infrastructure is configured, he looks for rules to bypass:

The configuration: certain IP addresses are whitelisted at the network level — traffic from those addresses is trusted.
The bypass: the attacker does IP spoofing — changing the source IP address in the packet to one of the whitelisted addresses.
The gamble: if the firewall blindly trusts the whitelisted source IP and does not detect the spoofing, that is a loophole — the attacker's packets sail through the filter.

Final answer: a whitelist bypassed by forged source addresses. Sense-check: a whitelist is only as strong as the identity it checks — a source IP address can be written on any packet, so a blind trust in it is itself a vulnerability.

And a third route goes around the technology entirely, straight to a person.

Worked example 3 — the falsified help-desk email. The non-technical route into the same server:

Disguise: the attacker sends an email that looks like it comes from the IT help desk: "you need to reset your password, click here."
Hook: the link points to a page that looks like the real company portal.
Capture: the user types their credentials on the fake page; the attacker records them.
Reuse: the attacker logs into the real system with the captured credentials.

Final answer: a phishing-based credential capture — social engineering carried over email. Sense-check: this path does not need a single technical exploit; it needs one user who does not verify the sender before clicking.

There are N possible ways to bypass a system, which is why even if one level of bypass succeeds, multiple levels of bypass are needed when you apply defense in depth — more controls. The need-to-know basis means by default you grant minimum privileges for a person to carry on their business; when the business needs require it, you grant admin-level access. That is the least-privilege model: by default everybody is restricted to a minimum level of access, and access is increased slowly. Controls are deployed at different layers — physical manner, administrative manner (policies and procedures), or technical manner. Nobody can ever say their system is 100 percent secure; we do our maximum effort to secure from unauthorized access.

2.11.2 The Takeaway

The attacker's chain, and the defender's mirror. The external attacker's sequence is always the same: footprinting (information gathering) → understanding the infrastructure → finding vulnerabilities and loopholes → exploiting one of them. The defender's counter is the opposite pattern: multiple layers of controls (defense in depth), least privilege, changed default credentials, monitored traffic, and detection tools — so that each step of the attacker's chain is hard and visible.

The logic is simple: the attacker must succeed at every step in the chain; the defender only needs to break one step to stop the attack.

Real-world: this is the actual VAPT engagement flow — external and internal penetration tests, reconnaissance, vulnerability scanning, exploitation, and reporting — and the whitelist/IP-spoofing and help-desk-phishing scenarios are standard red team techniques. A red team's job is to replay exactly this chain on the organization's own systems, with permission, so the findings become the fix list.

2.12 What Happens When an Attack Succeeds

An attack that works is not the end of the story — it is the beginning of a chain of consequences, and the last link is often the most damaging.

2.12.1 The Chain of Consequences

Once an attack has been successful, a lot follows: financial loss, reputation loss, legal issues, regulatory issues, clients leaving the organization, and so on. The deepest damage is trust: trust is lost by your clients and customers. Reputation damage — the news that a company's data has been lost — directly results in the failure of the business.

The consequence chain, in order:

Financial loss — the direct cost: funds stolen, systems rebuilt, ransom paid, forensics engaged.
Reputation loss — the breach becomes news, and the public reads the headline.
Legal and regulatory issues — regulators (and privacy laws like the DPDP Act and GDPR) impose fines and investigations.
Clients leaving — customers and business partners react to the lost trust.
Trust destroyed — the deepest damage: even after systems are restored, the confidence of clients and customers does not return on the same schedule.

The deepest damage is trust: trust is lost by your clients and customers. Reputation damage — the news that a company's data has been lost — directly results in the failure of the business.

The asymmetry of recovery. Technical recovery can be fast — a patched server can be back in hours. Trust recovery is slow — years of customer confidence can be undone by a single headline, and the business may not survive the gap. This is why the pre-breach work (detection, response plans, communication plans) is not a luxury; it determines how much of the chain actually gets triggered.

Real-world: the same sequence appears in every major breach disclosure — financial cost, regulator scrutiny, customer churn, and a trust recovery phase that takes years. When you read a breach report, try placing each headline into one of the five links: most of them fit the chain exactly.

2.12.2 Where the Course Goes Next

The next session will show a diagram that explains the interlink between threat, vulnerability, weakness, exploit, and attack — how a threat connects to a vulnerability, a vulnerability to a weakness, a weakness to an exploit, and an exploit to an attack. That diagram is intended to make the whole chain clear. The zero-day assignment answers will also be discussed there.

Bridge to the next session: this lecture ends with the consequences of success; the next session connects the pieces into one chain — threat → vulnerability → weakness → exploit → attack — and discusses your zero-day assignment answers. Keep your list of three to five impact-reduction options ready.

2.13 Networks, the Internet, and Layered Models

Everything in security travels over a network — so before the course dives into the details of defense, it spends one session on the roads themselves: how networks connect, how they are layered, and how far the isolation can go.

2.13.1 How Networks Used to Connect

To understand security you also need to understand the network itself, since everything is about data getting transmitted from one system to another; if the data is not getting transferred, there is an issue.

The old telephone picture. The old days: whenever you wanted to connect to somebody via telephone, you used to call a repeater, and the operator lost the number and connected the call manually. In the current era, connecting two different networks is not so difficult as in the older days. The course looks at the history of the internet, how it has changed, and what the basic network utilities are that have changed along the way.

The picture to keep: a call once needed a human in the middle who remembered (or lost) the number and physically patched the line. Today the "patch" is done automatically by protocols and routers in milliseconds — which is why we now ask the security question that would have been absurd for the manual switchboard: what happens if the path itself is malicious?

2.13.2 The OSI Seven Layers and the TCP/IP Four Layers

Communication and the different layers are discussed using the OSI model or the TCP/IP model.

From seven layers to four. The OSI model has seven layers: physical, data link, network, transport, session, presentation, and application. From seven we reduce to four, which are the TCP/IP protocol layers.

The standard reduction mapping:

OSI seven layers	TCP/IP four layers
Application	Application
Presentation	Application
Session	Application
Transport	Transport
Network	Internet
Data link	Network access (link)
Physical	Network access (link)

Why does the reduction matter for security? Because a control lives at a layer: the earlier session's example of IP-address filtering at layer 3 and MAC filtering at layer 2 was working inside this model. When you say "protect at the network layer" or "application-layer security," you are choosing the layer of the model where the control sits. This is where network topology and the types of networks get decided.

2.13.3 Network Types, Devices, and the Air Gap

The course covers the types of networks — LAN (local area network), WAN (wide area network), MAN (metropolitan area network) — and the different varieties based on the architecture diagram, such as mesh networks. The advanced electronic devices are the router, the switch, and similar network devices, and the next step is the interconnection of networks and the internet.

LAN (local area network) — a network in one physical area: an office floor, a building.
WAN (wide area network) — a network spanning large distances, connecting LANs across cities or countries; the internet is the largest WAN of all.
MAN (metropolitan area network) — in between, covering a city-scale area.
Mesh — an architecture where devices connect in a web rather than a single chain, so traffic can reroute around a broken link.

Q: What about air-gapped network security? A: Think about this laptop. What threats can reach it? Only when it is connected to an external network — once you are connected to the internet, anything can enter the system. If the laptop is not connected to the internet at all, there is no chance of anything happening to it. An air gap is a mechanism that restricts the computer so it cannot establish any external connection. You segregate the laptop into a separate zone, ensure it never connects to any external connection, and restrict its communication only within the internal network. Nobody can access it from external IP addresses. That is one example of a security measure called an air gap.

The air gap's cost. The air gap is the strongest form of isolation because it removes the attack surface entirely — no external connection, no external threat. But that strength is also its price: no updates from the internet, no remote access, no cloud services, and data enters only through controlled media (which then become the new risk — a USB stick crossing the gap is the classic way an air-gapped network eventually gets infected). Use it where the asset's value justifies the inconvenience.

Real-world: air gaps are used for the most sensitive systems — industrial control systems, isolated payroll servers, and classified networks — exactly because removing the external connection removes the threat surface.

Recap: networks used to be connected manually through repeaters and operators; today the OSI seven layers (collapsed into the TCP/IP four) describe where data handling and controls happen; networks span LAN → MAN → WAN, with devices like routers and switches interconnecting them; and the air gap — no external connection at all — is the extreme end of isolation.

2.14 The Course Syllabus and Its Domains

A course roadmap is also a security lesson: it shows how the pieces of this lecture — CIA, controls, threats, networks — plug into a larger body of knowledge.

2.14.1 The Eight Chapters

The course follows eight chapters. Chapter 1 introduces the fundamentals: why we need security, what the CIA triad means and why we need it, and the controls — the two classification schemes for controls (physical, administrative, technical, and the functional categories preventive, detective, corrective, deterrent). From there the course moves to key security technologies: cyber security, network security, endpoint security, infrastructure security, and the security operations center with its SOC analysts.

The next chapter is about policies, standards, and frameworks: the difference between a policy, a standard, and a framework; who develops the policies; and how to establish procedures from the policies. The goal is aligning the organization's policies and procedures to the achievement of confidentiality, integrity, and availability. (The session's earlier definition — a policy is the management tone, the direction from the head of the organization — is the foundation this chapter builds on.)

Then comes the network material: what is a network, when do we call something a network, the different types of networks (LAN, WAN, MAN, and the mesh variety from the architecture diagram), the devices (router, switch), and the interconnection of networks and the internet.

Chapter 4 in the overview covers cyber threats — not threats in specific, but the language of threats: the possibility. A cyber attack is someone trying to damage your laptop; it can be data getting locked, or the system crashing by injecting into the database. Different methodologies exist for performing cyber attacks, and for every attack there is also a protection. The overview lists seven common attacks at the application layer: malware, DoS (denial of service), session hijacking, phishing, SQL injection, zero-day attacks, and DNS tunneling.

Then the course addresses cyber crime: what a cyber crime is, the types of cyber crime, and specifically how these issues can be resolved. If someone has attacked you, you resort to the police and file a complaint — the same process applies when a cyber crime happens to someone. A case study at the end shows what the issue or conflict was in a real scenario. Along the way the course covers the threat landscape — starting from threat identification, then scanning: vulnerability scanning is what identifies any security loophole in the systems being tested — and the question of protecting the data in the cloud: since the majority of compute is in the cloud now, what level of controls do you deploy, based on the cost of the asset.

The eight-chapter map at a glance:

Fundamentals — why security, the CIA triad, controls.
Key security technologies — cyber, network, endpoint, infrastructure security, SOC.
Policies, standards, and frameworks — and how procedures follow.
Networks — types, devices, interconnection, the internet.
Cyber threats — the language of threats and the seven application-layer attacks.
Cyber crime — types, resolution, police complaints, a case study.
Threat landscape — threat identification, vulnerability scanning, cloud data controls.
Policies and risk management — the governance layer.

(This is the professor's own overview of the chapters as presented; the later chapters of the syllabus continue into the governance domain.)

2.14.2 Which Security Domains the Syllabus Covers

Q: How many domains of cyber security does the syllabus cover? A: Typically two domains, out of the eight domains that exist in the security body of knowledge. Mostly we touch on threats, vulnerabilities, and controls, and then something on policies and risk management. These are the areas the course covers from the syllabus perspective.

So the full security body of knowledge has eight domains, and this course deliberately focuses on two of them: (1) threats, vulnerabilities, and controls — the technical heart of this lecture — and (2) policies and risk management. The other domains exist in the profession, but the syllabus does not aim to cover them in depth.

2.14.3 What Comes in the Sessions Ahead

The upcoming sessions build on this: the difference between policies, standards, and frameworks; the network types and internet interconnection; the cyber security landscape — where the possibility of threat happening is, including the target and non-target audience — and the top cyber crimes: what exactly happened in the major incidents.

Exam note: the mid-semester exam coverage is tied to specific contact sessions (see the Exam Guidance Summary below). Keep the two-domain focus in mind when you revise: everything in this lecture belongs to threats/vulnerabilities/controls or to policies/risk management — sort each topic into its domain and the syllabus becomes much easier to navigate.

Exam Guidance Summary

Mid-semester coverage. A student asked exactly where the mid-semester syllabus ends. The course handout says the first one to eight contact sessions are covered, which reaches up to the topics 5.1 and 5.2 (around sub-topic 5.1.1). The answer confirmed: material from 5.2 onwards is the syllabus for the second half of the course. So: contact sessions 1 through 8 → up to 5.1/5.2 → mid-semester; 5.2 onwards → second half.

Q: The handout says the mid-semester comes till contact sessions one to eight, which covers up to here — so where does the eighth contact session end, at 5.1 or 5.2, up to 5.1.1? And from 5.2 onwards will be the syllabus for the second half, right? A: Yes, correct. 5.2 onwards will be the syllabus for the second half; the first half covers sessions one through eight, ending around 5.1/5.2.

Open book. The signals are mixed and worth knowing: when asked whether an exam will be open book, the first answer was "no, it will not be open book." Later, the handbook was referenced as saying both exams are open book, with the note that this would be checked and confirmed — and the working belief is that these are internal exams. Treat the handbook statement as the official record and expect confirmation.

Q: Will the exams be open book? A: No, it will not be open book. Later clarification: both exams are mentioned as open book exams in the handbook; I am not sure, I will check it and confirm. Based on my knowledge, I believe these are all internal exams.

Labs and demos. There will be practical demos explained in terms of the labs. A question about granting lab access to the group is pending a response from the admin team; the answer will be posted once received.

Q: Will there be labs with particular demos? A: Yes, there will definitely be some practical demos which will be explained in the labs. About granting access to the labs: I am waiting for the response from the admin team, and will keep you posted the moment it arrives.

No programming or scripting. There is nothing related to programming in this course; no scripting languages will be used.

Q: Do we need any programming or specific scripting language? A: No, there will be no scripting. Nothing related to programming will be done in this course.

Textbook per topic. A textbook will be provided for each topic as reference material; the prepared session content covers the majority of the syllabus.

Assignment to prepare. The zero-day assignment: as a cyber security engineer, list three to five possible ways to reduce the impact of a zero-day attack on your systems, servers, or networks when no patch is available. Answers are discussed in the next session; EDR/XDR was proposed and explicitly ruled out as the answer, and the banking constraint (the system cannot be taken down) applies.

How the course runs. Interactive knowledge-exchange format; questions do not have to stay within the syllabus. Sessions are not graded or tested for reference — the syllabus walkthrough was a discussion, not a test.

Key Industry Applications

VAPT and red teaming. The ethical hacking flow — reconnaissance, information gathering, footprinting, exploitation — and the villa analogy for entry-point analysis map directly to external penetration tests performed by VAPT teams; whitelisting plus IP spoofing, version disclosure via error messages, default credentials, and help-desk phishing are standard red team techniques.
EDR/XDR. Endpoint detection and response and extended detection and response tools — CrowdStrike being the named example — replace signature-based antivirus with behavioral detection of abnormal process-to-process communication.
Identity governance. SailPoint (or similar tools) is used for periodic user access reviews so the right people keep the right level of access; IAM and least privilege are the underlying model.
Network defense. Firewalls, IDS, and IPS protect the network; IP tables, MAC-address filtering, and port restrictions implement controls at layers 3, 2, and transport.
Threat intelligence. MITRE ATT&CK is the framework that lets monitoring systems place an attacker in a phase — initial access, exploitation, escalation to admin, exfiltration.
Privacy regulation. The DPDP Act in India (data principal, data fiduciary, data processor) and the GDPR in Europe (data subject, controller, processor, sub-processor, enforced 2018) drive privacy engineering; standard contractual clauses and data processing agreements enable cross-border transfers to the 8–10 countries the EU trusts.
Resilience planning. SLA uptime commitments, RTO and RPO targets, backups (daily/weekly/quarterly), dual redundancy, BCP (business continuity planning), and DR (disaster recovery) keep availability commitments to clients.
Cryptography in practice. AES and Triple DES for encryption (confidentiality), hashing for integrity, digital signatures, and HTTPS for data in transit.
Emerging models. Zero trust (trust nobody, verify before granting access) and air-gapped networks for the most sensitive systems.

CS Lecture 2 notes · Cyber Security: Fundamentals, Threats, and Attacks

Cyber Security· postgraduate· 2026-08-16

Sections Breakdown

12.1 How This Course Runs — A Knowledge Exchange, Not One-Way Teaching

How the course runs as an interactive knowledge exchange, the secure SDLC, and why cyber security is buzzing.

22.2 Privacy versus Security — Data Ownership and Data Protection Law

Security as protecting assets, privacy as data-owner rights, the DPDP Act and GDPR roles, and purpose limitation.

32.3 The CIA Triad — Confidentiality, Integrity, and Availability

The CIA triad: confidentiality, integrity, and availability, their mechanisms, failure examples, and student Q&A.

42.4 The Three A's — Authentication, Authorization, and Accountability

Authentication, authorization, and accountability, with the payroll portal and campus examples and the audit log story.

52.5 Computer Security, Network Security, and Cyber Security

Computer security, network security, and cyber security scopes, controls at different layers, and defense in depth.

62.6 Assets, Threats, Vulnerabilities, and Controls

The asset, threat, vulnerability, and control chain, including the two classification schemes for controls.

72.7 Cyber Threats — Sources, Types, and Impact

Cyber threats: malicious intent, threat sources, malware families, social engineering, and impact.

82.8 Threat Modeling — MITRE ATT&CK and Attack Frameworks

MITRE ATT&CK attack phases from initial access to exfiltration, and the countermeasure toolkit.

92.9 Types of Cyber Attacks

The major attack types: APT, backdoors, buffer overflow, man-in-the-middle, DoS/DDoS, XSS, SQL injection, zero-day.

102.10 The Zero-Day Assignment — Defending Without a Patch

The zero-day assignment: three to five impact-reduction options under the banking availability constraint.

112.11 How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

How external attackers operate: footprinting, reconnaissance, exploitation, and the villa analogy.

122.12 What Happens When an Attack Succeeds

The chain of consequences when an attack succeeds, from financial loss to destroyed trust.

132.13 Networks, the Internet, and Layered Models

Networks and the internet: manual switchboards to OSI seven and TCP/IP four layers, network types, and the air gap.

142.14 The Course Syllabus and Its Domains

The course syllabus: the eight chapters and the two security domains it covers.

15Exam Guidance Summary

Exam logistics: mid-semester coverage, open-book status, labs, and the assignment.

16Key Industry Applications

VAPT and red teaming, EDR/XDR, identity governance, privacy regulation, and resilience planning.

Postgraduate students in Cyber Security

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

How This Course Runs — A Knowledge Exchange, Not One-Way Teaching

Must-know: This course runs as an interactive knowledge exchange, not one-way teaching; a textbook is provided per topic, and a secure SDLC is the normal SDLC with a security perspective applied at each phase (e.g., consent for personal data under the DPDP Act).

⚠️ Top pitfall: Treating security as a final phase: consent and data-design decisions cannot be retrofitted late; they must be part of requirements gathering.

Self-check: Where in the SDLC does a consent requirement for collecting employee data belong?

Connects to: 2.2 Privacy versus Security — Data Ownership and Data Protection Law; 2.14 The Course Syllabus and Its Domains

Privacy versus Security — Data Ownership and Data Protection Law

Must-know: Confidentiality is about accessibility (who may read the data); privacy is about the rights of the individual over their data. Purpose limitation (an OECD principle) forbids using data for any purpose other than the one it was collected for.

⚠️ Top pitfall: Confusing privacy with confidentiality: in the bank example the data stayed confidential between bank and telemarketer, yet privacy was still violated because there was no consent for the new purpose.

Self-check: Which DPDP Act role is the person whose data it is, and which entity collects the data?

Connects to: 2.3 The CIA Triad — Confidentiality, Integrity, and Availability; 2.1 How This Course Runs — A Knowledge Exchange, Not One-Way Teaching

The CIA Triad — Confidentiality, Integrity, and Availability

Must-know: If any one of confidentiality, integrity, or availability fails, information security is compromised; map each scenario to its triad leg (ransomware = availability, man-in-the-middle tampering = integrity, weak/default credentials = confidentiality).

⚠️ Top pitfall: Calling an availability failure 'not a security problem' — ransomware locking data and ping-of-death flooding both break availability and are security failures even when nothing is stolen.

Self-check: Which triad leg does a man in the middle altering a 100-rupee transfer into 1000 rupees break?

Connects to: 2.2 Privacy versus Security — Data Ownership and Data Protection Law; 2.9 Types of Cyber Attacks

The Three A's — Authentication, Authorization, and Accountability

Must-know: The three A's are authentication, authorization, and accountability — NOT accounting; accountability is supported by audit logs that trace any transaction to a user ID.

⚠️ Top pitfall: Confusing authorization with authentication: being authenticated does not grant full access — authorization sets the level based on roles and responsibilities.

Self-check: In the payroll portal example, which A allows you to see your payslip but not the admin options?

Connects to: 2.3 The CIA Triad — Confidentiality, Integrity, and Availability; 2.6 Assets, Threats, Vulnerabilities, and Controls

Computer Security, Network Security, and Cyber Security

Must-know: Computer security protects systems and data, network security protects the network (firewall, IDS, IPS, NAC), cyber security protects assets from external attackers; defense in depth reduces the attack surface — nobody can claim a system is 100% secure.

⚠️ Top pitfall: Believing a system can ever be '100 percent secure'; security is maximum effort to make exploitation as hard as possible through multiple layers.

Self-check: At which OSI layer does IP-address-based access restriction work, and which layer uses MAC addresses?

Connects to: 2.6 Assets, Threats, Vulnerabilities, and Controls; 2.11 How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

Assets, Threats, Vulnerabilities, and Controls

Must-know: Threat is the potential for harm, attack is the threat carried out, vulnerability is a weakness in the system, and controls (physical/administrative/technical; preventive/detective/corrective/deterrent) overcome vulnerabilities.

⚠️ Top pitfall: Assuming the threat always comes from outside — the attacker may already be inside; a failure of control creates the weakness that becomes a vulnerability.

Self-check: Classify a firewall by category and by functionality.

Connects to: 2.3 The CIA Triad — Confidentiality, Integrity, and Availability; 2.7 Cyber Threats — Sources, Types, and Impact

Cyber Threats — Sources, Types, and Impact

Must-know: Malware families differ by objective: Trojan captures and shares information, worm self-propagates to make systems unusable, virus damages system or program files; keyloggers record keystrokes.

⚠️ Top pitfall: Using virus/worm/Trojan interchangeably — they behave differently (Trojan hides, worm self-propagates without a carrier, virus attaches to programs), so misidentification hides the attack.

Self-check: Which malware family's objective is to self-propagate across the entire system?

Connects to: 2.6 Assets, Threats, Vulnerabilities, and Controls; 2.9 Types of Cyber Attacks

Threat Modeling — MITRE ATT&CK and Attack Frameworks

Must-know: Exfiltration is the stage where the attacker has already gained access and admin rights and is extracting data out of the network; the response should match the detected phase.

⚠️ Top pitfall: Treating an exfiltration alert like an initial-access alert — by the time data leaves the network, the attacker has been inside for a while, so response must cut the data flow and trace the path, not just patch the entry.

Self-check: What does 'escalation mode' mean in the MITRE ATT&CK phase model?

Connects to: 2.6 Assets, Threats, Vulnerabilities, and Controls; 2.11 How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

Types of Cyber Attacks

Must-know: APT = silent long-term access; backdoor = secret alternative path that negates normal authentication; SQL injection can steal AND modify data (breaks the I of the CIA triad); zero-day = vulnerability with no patch available (zero days of warning).

⚠️ Top pitfall: Believing a backdoor can be caught by login checks — it bypasses authentication entirely; only deep scanning and behavioral monitoring reveal it.

Self-check: Which CIA leg does SQL injection break when the attacker modifies data in the database?

Connects to: 2.3 The CIA Triad — Confidentiality, Integrity, and Availability; 2.10 The Zero-Day Assignment — Defending Without a Patch

The Zero-Day Assignment — Defending Without a Patch

Must-know: The zero-day assignment: three to five ways to reduce impact when no patch exists; the answer must keep systems available — the banking server cannot be disconnected (availability cannot be sacrificed).

⚠️ Top pitfall: Proposing EDR/XDR as the answer — ruled out; also proposing any solution that takes the system down violates the banking availability constraint.

Self-check: Why was EDR rejected as the answer to the zero-day assignment?

Connects to: 2.9 Types of Cyber Attacks; 2.3 The CIA Triad — Confidentiality, Integrity, and Availability

How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

Must-know: External attack sequence: footprinting (information gathering) → understand infrastructure → find vulnerabilities and loopholes → exploit one; defenders counter with defense in depth, least privilege, changed default credentials, monitoring.

⚠️ Top pitfall: Trusting whitelisted source IPs blindly — IP spoofing changes the source address in the packet, bypassing the whitelist if the firewall does not detect it.

Self-check: What does an error message revealing 'SQL 2.1 version is running' tell the attacker?

Connects to: 2.5 Computer Security, Network Security, and Cyber Security; 2.8 Threat Modeling — MITRE ATT&CK and Attack Frameworks; 2.9 Types of Cyber Attacks

What Happens When an Attack Succeeds

Must-know: The deepest damage of a successful attack is trust: reputation loss from public breach news directly results in the failure of the business.

⚠️ Top pitfall: Measuring breach cost only as the fine — the market and customer reaction following reputation damage costs more than the fine itself.

Self-check: What is the deepest damage when an attack succeeds?

Connects to: 2.7 Cyber Threats — Sources, Types, and Impact; 2.10 The Zero-Day Assignment — Defending Without a Patch

Networks, the Internet, and Layered Models

Must-know: OSI has seven layers (physical, data link, network, transport, session, presentation, application) reduced to TCP/IP's four; the air gap restricts a computer to no external connections so nothing can reach it from external IP addresses.

⚠️ Top pitfall: Believing an air-gapped network is immune forever — data crossing the gap (e.g., via USB) becomes the new entry point.

Self-check: Which security measure restricts a laptop so no external IP address can reach it?

Connects to: 2.5 Computer Security, Network Security, and Cyber Security; 2.14 The Course Syllabus and Its Domains

The Course Syllabus and Its Domains

Must-know: The syllabus covers two of the eight security domains: threats/vulnerabilities/controls and policies/risk management; the course follows eight chapters from fundamentals to governance.

⚠️ Top pitfall: Assuming the course covers all eight security domains — it covers two: threats/vulnerabilities/controls and policies/risk management.

Self-check: Which two of the eight security domains does the syllabus cover?

Connects to: 2.1 How This Course Runs — A Knowledge Exchange, Not One-Way Teaching; 2.3 The CIA Triad — Confidentiality, Integrity, and Availability

Exam Guidance Summary

Must-know: Mid-semester covers contact sessions 1 through 8, ending around topics 5.1/5.2; from 5.2 onwards is the second-half syllabus.

⚠️ Top pitfall: Assuming the open-book question is settled — the handbook says both exams are open book, but this is to be confirmed; the working belief is internal exams.

Self-check: Where does the mid-semester syllabus end?

Connects to: 2.10 The Zero-Day Assignment — Defending Without a Patch; 2.14 The Course Syllabus and Its Domains

Key Industry Applications

Must-know: Named tools and frameworks to remember: CrowdStrike (EDR), SailPoint (identity governance), MITRE ATT&CK (threat modeling), AES/Triple DES (encryption), DPDP Act and GDPR (privacy regulation).

Self-check: Which EDR tool was named in the lecture for abnormal process-to-process communication detection?

Connects to: 2.8 Threat Modeling — MITRE ATT&CK and Attack Frameworks; 2.2 Privacy versus Security — Data Ownership and Data Protection Law; 2.3 The CIA Triad — Confidentiality, Integrity, and Availability

Previous LectureLecture 01 · Foundations and Course Roadmap

Next LectureLecture 03 · Threats, Vulnerabilities, and Risk Management

Was this lecture useful?

Loading comments…

🤖

BitsNotes AI Assistant

Subject Notes Assistant

Configure AI Chat

Choose how to access the chatbot

Have your own API key?

Switch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.

AI Provider Preset

API Endpoint URL (OpenAI-Compatible)

API Key

Model Name

🔑 Enter API key above to fetch live models from provider, or enter model name manually.

Remember key for this session (until tab closes)

OpenAI-Compatible API Support

Choose any provider preset (Gemini, DeepSeek, Kimi, GLM, MiniMax, Qwen, OpenAI, Groq, Ollama, etc.) or enter a custom endpoint URL.

Security & Privacy First

Your API key is sent directly from your browser to your specified provider. BitsNotes servers never store or see your key.

2.1 How This Course Runs — A Knowledge Exchange, Not One-Way Teaching

2.1.1 The Format of the Session

2.1.2 Why Cyber Security Is Buzzing, and the Shift Into It

2.2 Privacy versus Security — Data Ownership and Data Protection Law

2.2.1 Security Means Protecting Assets

2.2.2 Privacy: You Own Your Data

2.2.3 The Bank Example: Violating Purpose Limitation

2.3 The CIA Triad — Confidentiality, Integrity, and Availability

2.3.1 Confidentiality

2.3.2 Integrity

2.3.3 Availability

2.3.4 Student Questions and Answers

2.4 The Three A's — Authentication, Authorization, and Accountability

2.4.1 Student Questions and Answers

2.4.2 Auditability and Why Logs Matter

2.5 Computer Security, Network Security, and Cyber Security

2.5.1 Three Kinds of Security

2.5.2 Layering Security at Different Layers

2.5.3 Defense in Depth

2.6 Assets, Threats, Vulnerabilities, and Controls

2.6.1 Assets and What a Threat Is

2.6.2 Vulnerabilities

2.6.3 Controls

2.7 Cyber Threats — Sources, Types, and Impact

2.7.1 What Counts as a Cyber Threat

2.7.2 Threat Sources

2.7.3 Malware Families: Virus, Worm, and Trojan

2.7.4 Social Engineering and the People Who Get Targeted

2.7.5 Impact of a Successful Threat

2.8 Threat Modeling — MITRE ATT&CK and Attack Frameworks

2.8.1 Phases of an Attack

2.8.2 Countermeasures

2.9 Types of Cyber Attacks

2.9.1 Advanced Persistent Threats (APT)

2.9.2 Backdoor Attacks

2.9.3 Buffer Overflow

2.9.4 Man-in-the-Middle Attacks

2.9.5 Denial of Service and Distributed Denial of Service

2.9.6 Cross-Site Scripting (XSS)

2.9.7 SQL Injection

2.9.8 Zero-Day Exploits

2.10 The Zero-Day Assignment — Defending Without a Patch

2.10.1 The Assignment

2.10.2 EDR and XDR — the Proposed Answer and Why It Falls Short

2.10.3 The Banking Constraint

2.11 How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

2.11.1 Student Questions and Answers

2.11.2 The Takeaway

2.12 What Happens When an Attack Succeeds

2.12.1 The Chain of Consequences

2.12.2 Where the Course Goes Next

2.13 Networks, the Internet, and Layered Models

2.13.1 How Networks Used to Connect

2.13.2 The OSI Seven Layers and the TCP/IP Four Layers

2.13.3 Network Types, Devices, and the Air Gap

2.14 The Course Syllabus and Its Domains

2.14.1 The Eight Chapters

2.14.2 Which Security Domains the Syllabus Covers

2.14.3 What Comes in the Sessions Ahead

Exam Guidance Summary

Key Industry Applications

CS Lecture 2 notes · Cyber Security: Fundamentals, Threats, and Attacks

Sections Breakdown

Exam Revision Notes

How This Course Runs — A Knowledge Exchange, Not One-Way Teaching

Privacy versus Security — Data Ownership and Data Protection Law

The CIA Triad — Confidentiality, Integrity, and Availability

The Three A's — Authentication, Authorization, and Accountability

Computer Security, Network Security, and Cyber Security

Assets, Threats, Vulnerabilities, and Controls

Cyber Threats — Sources, Types, and Impact

Threat Modeling — MITRE ATT&CK and Attack Frameworks

Types of Cyber Attacks

The Zero-Day Assignment — Defending Without a Patch

How an External Attacker Operates — Footprinting, Reconnaissance, and Exploitation

What Happens When an Attack Succeeds

Networks, the Internet, and Layered Models

The Course Syllabus and Its Domains

Exam Guidance Summary

Key Industry Applications