Introduction to Cybersecurity — Core Concepts and Definitions
Introduction to Cybersecurity — Core Concepts and Definitions
3.1 Course Overview and Expectations
3.1.1 Course Theme and Structure
Why this course exists: Cybersecurity threats are growing faster than human analysts can handle them. Machine learning offers a way to scale detection and response — but only if you understand both the security domain and the ML tools available.
This course on AI and Machine Learning Techniques for Cybersecurity is an applications course, not a deep-math course and not an ethical-hacking course. The core theme is straightforward: traditionally, without machine learning, cybersecurity problems are getting harder to solve; with machine learning, we can solve them better. The course takes supervised and unsupervised learning techniques that students have already studied and applies them to cybersecurity use cases — malware detection, network intrusion detection, anomaly detection, brute-force detection, DDoS detection, and more.
The course spans 16 contact sessions covering 10 modules. The first module introduces cybersecurity fundamentals and taxonomy. The second covers core cybersecurity concepts — security architectures, threat intelligence, attribution, TTPs (Tactics, Techniques, and Procedures), and security operation centers. The third module brings in data science and machine learning foundations for cybersecurity: what data to collect, how to pre-process it, what ML algorithms apply, and what an ML development pipeline looks like. Later modules cover malware detection, network intrusion detection, DGA (Domain Generation Algorithm) detection, network profiling, and adversarial machine learning.
What makes this course different: This is not a theory-heavy ML course. Students are expected to already know supervised and unsupervised learning. The course focuses on how to apply these techniques to real security problems — what data to collect, how to engineer features from network traffic or system logs, and how to evaluate models in adversarial settings where attackers actively try to evade detection.
The course is structured to build progressively: foundational cybersecurity concepts first, then ML foundations for security, then specific application domains. Each module builds on the previous one. By the end, students will have worked through malware detection, network intrusion detection, DGA detection, network profiling, and adversarial machine learning — covering the major areas where ML is deployed in production security systems.
3.1.2 Textbooks and References
The primary reference is a 2018 textbook by Chio and Freeman. The core concepts remain sound, but the field has evolved significantly in the eight years since publication — attacks and defenses have both advanced. Additional references include classic computer security texts by Stallings and Brown. Students are encouraged to follow the class content, slides, research paper links, and hands-on exercises rather than relying solely on textbooks.
Why textbooks are not enough: Cybersecurity is a rapidly evolving field. Textbooks provide foundational knowledge, but real-world attack techniques change faster than textbooks can be updated. The professor recommends supplementing textbook material with conference recordings from B-sides and RSA, research papers, and hands-on experimentation.
The companion textbook by Chio and Freeman (2018) covers the intersection of machine learning and security — topics like malware analysis, network traffic analysis, anomaly detection, and adversarial ML. While the core ML algorithms have not changed, the threat landscape has evolved significantly. For example, ransomware attacks have grown dramatically, adversarial ML techniques have matured, and new attack vectors like supply chain compromises have emerged. Students should treat the textbook as a foundation, not a complete picture.
Additional references by Stallings and Brown provide broader computer security context — covering cryptographic tools, access control, intrusion detection, firewalls, and security management. These are useful for understanding the security infrastructure that ML models operate within.
3.1.3 Assessment Structure
- EC1 (30%): Split into a quiz and an assignment. The quiz covers material up through roughly the third or fourth contact session. The assignment is a hands-on project — a working prototype, not a research report.
- EC2 (30%): A closed-book midterm exam after the eighth contact session, covering the first seven to eight classes. Mix of theory and applied questions, but no deep math or equations.
- EC3 (40%): An open-book final exam. Students may bring annotated PPTs with a watermark marker.
Exam note: Nothing will appear on exams beyond what is taught in class. The professor advises students to attend classes or watch recordings, follow the course material and references provided, and not worry excessively about marks — focus on curiosity and learning.
Assessment tips:
- Quiz 1: 10 marks, 30 minutes, open for 7 days, no negative marking. Covers the first 3–4 sessions. Do not miss it — it is easy marks.
- Assignment: A hands-on working prototype, not a research report. Opens after the midterm, runs for 14 days (two weekends). Individual submission. Focus on building something that works, not on writing a lengthy report.
- Midterm: Closed book, covering the first 7–8 classes. Mix of theory and applied questions. No deep math or equations — focus on understanding concepts and their applications.
- Final exam: Open book. Students may bring annotated PPTs with a watermark marker. Wait until the last two classes before printing, as the watermarking may change.
Exam note: The CIA triad, vulnerability-threat-control paradigm, and acts of harm model are all important theoretical frameworks to understand. These are theoretical models, not machine learning models.
Exam note: Definitions of asset, vulnerability, threat, threat actor, impact, controls, and risk must be clear in students' minds. The professor will use these terms throughout the course, and confusion between them will hinder learning.
3.2 Fundamental Cybersecurity Definitions
Why definitions matter: The same words — threat, vulnerability, risk — mean different things to different people. Without a shared taxonomy, discussions about cybersecurity become confused. A security team that cannot distinguish between a vulnerability and a threat will struggle to prioritize their work. These definitions form the foundation for the entire course.
Getting the terminology right is critical. The professor uses these terms consistently throughout the course, and confusion between them will hinder learning. Each term builds on the previous ones — assets have vulnerabilities, threats exploit vulnerabilities, threat actors cause threats, impacts are the consequences, controls reduce risk.
3.2.1 Asset
An asset is something of value to an individual or an organization. It could be hardware (a laptop, a server, a networking router, a phone), software, data (intellectual property, customer records, photos, email), or even a virtual machine in the cloud. The value is not always monetary — personal photos, music, or sensitive company designs carry intrinsic value. The repercussions of losing an asset can far exceed the physical value of the device itself. When everything becomes digital — designs, code, customer data — it becomes a computer security problem.
Asset categories (from Stallings and Brown):
- Hardware: Computer systems, data processing devices, storage devices, communication equipment
- Software: Operating systems, system utilities, application programs
- Data: Files, databases, security-related data (password files, configuration files)
- Communication facilities and networks: LAN/WAN links, bridges, routers, switches
Example: A company laptop worth 1,000 USD contains customer database access credentials, proprietary source code, and email archives. The physical device is worth 1,000 USD, but the data on it could be worth millions — and the cost of a breach (investigation, notification, regulatory fines, reputation damage) could be far higher still. This is why asset valuation must consider not just replacement cost, but the value of what the asset protects or provides access to.
3.2.2 Vulnerability
A vulnerability is a weakness in an information system, security procedures, internal controls, or configurations. It is not always a bug in source code; it can be a misconfiguration, a missing security control, or a flaw in implementation.
The open manhole analogy: The very presence of an open manhole on a road is a vulnerability. It is a weakness that exists regardless of whether anyone falls in. Similarly, a SQL injection in code is a vulnerability. Not having MFA (Multi-Factor Authentication) enabled on your Gmail account is a vulnerability. The vulnerability exists whether or not anyone exploits it.
Vulnerability sources (from Stallings and Brown):
- Design flaws: Weaknesses in the architecture or design of a system
- Implementation bugs: Coding errors, buffer overflows, injection flaws
- Misconfigurations: Default passwords, open ports, overly permissive access controls
- Missing controls: Lack of encryption, absence of audit logging, no backup procedures
- Process weaknesses: Poor change management, inadequate incident response procedures
Common pitfall: Thinking vulnerabilities are only software bugs. A missing security policy, an untrained employee, or a server room without a lock are all vulnerabilities. The NIST definition is broader: "a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy."
3.2.3 Threat
A threat is a circumstance or event with the potential to adversely impact an organization or its assets through IT systems. Think of it as: "What can go wrong? What is the worst that can happen?"
The key distinction — threat vs. incident: A threat is always before the fact. It is a likelihood, not a certainty. If someone says "there is a threat of war," war has not happened yet. If war is actually happening, you do not say "threat of war" — you say "it is war." Similarly, if a ransomware attack has already occurred, it is an incident, not a threat. Threat is pre-ante; incident is post-ante.
In the open manhole analogy: the threat is the harm that could happen — someone falling in and getting injured. If the road is abandoned and nobody uses it, the likelihood of the threat materializing is low.
Threat classification (from RFC 4949 and Stallings):
- Natural threats: Fire, flood, storm, earthquake, power loss
- Human-made threats (accidental): Employee error, hardware failure, software bug
- Human-made threats (deliberate): Hacking, malware, espionage, sabotage
- Passive threats: Eavesdropping, monitoring, traffic analysis (do not alter data)
- Active threats: Modification, replay, masquerade, denial of service (alter system resources)
3.2.4 Threat Actor
A threat actor is an individual or group of individuals that actually manifest a threat to an organization. The open manhole threat actor could be the municipal worker who carelessly left it open. In cybersecurity, threat actors include:
- Disgruntled employees: An employee who was fired and, two days later, discovered their cloud account access was still active — they went in and deleted virtual machines. This has happened at large companies.
- Cyber criminals: Seasoned criminal groups whose sole job is to attack systems.
- Competitors: Engaged in espionage to steal designs or source code. There are public cases of companies like Google reporting that competitors (e.g., Baidu) attacked and stole source code.
- Nation-state actors: Countries like the U.S., Russia, North Korea, China — superbly funded, extremely difficult to defend against. Geopolitical tensions often manifest as cyberattacks on IT systems rather than (or in addition to) physical borders.
- Terrorists and hacktivists: Loosely connected groups, sometimes organized crime members.
- Vendors: Third-party vendors who may inadvertently or deliberately become threat actors.
Real-world: During geopolitical tensions, the Ministry of IT sends private intimations to organizations about measures they need to take. Wars can be waged on economies, IT systems, and biology — not just at borders.
Threat actor attributes (from Stallings and Brown):
- Motivation: Why would they target this organization? Financial gain, espionage, ideology, revenge?
- Capability: What is their skill level? Script kiddies vs. advanced persistent threats?
- Resources: How much time, money, and infrastructure can they deploy?
- Probability of attack: How likely and how often would assets be targeted?
- Deterrence: What are the consequences to the attacker of being identified?
3.2.5 Impact
Impact is the concrete consequence of a security incident. It is not just "buy a new laptop" — the real costs are far greater:
- Loss of productivity: If GitHub goes down for 12 hours due to a DDoS attack, development teams cannot ship products. Manufacturing companies lose millions when factory systems slow down or stop.
- Revenue loss: An e-commerce website going down due to a cyberattack means direct revenue loss, even outside of peak sale periods.
- Penalties: Organizations that fail to comply with regulations face huge penalties.
- Investigation costs: The cost of investigating a breach, revoking compromised credit cards, reissuing credentials, and helping affected users.
- Human casualties: A German hospital hit by ransomware had to ship patients to another hospital, and someone died during transport. Attacks on IT systems can cause real human harm.
Example — impact levels (from FIPS 199):
- Low: Limited adverse effect — degradation in mission capability, minor financial loss, minor harm to individuals
- Moderate: Serious adverse effect — significant degradation, significant financial loss, significant harm (not life-threatening)
- High: Severe or catastrophic adverse effect — inability to perform primary functions, major financial loss, loss of life or serious life-threatening injuries
3.2.6 Controls
Controls are technical or non-technical measures that exist to remediate or mitigate potential impact. Examples include antivirus software, firewalls, SIEM (Security Information and Event Management) systems, information security policies, and awareness trainings.
Remediation vs. mitigation:
- Remediation completely eliminates the vulnerability (filling in the manhole)
- Mitigation slows or contains the threat (putting a board or barricade near the manhole)
- How effective a control is depends on the specific situation
Control categories (from FIPS 200):
- Technical controls: Access control, identification and authentication, system and communication protection, system and information integrity
- Management controls: Awareness and training, audit and accountability, certification and accreditation, contingency planning, risk assessment, personnel security
- Operational controls: Physical and environmental protection, maintenance, media protection, incident response
Common pitfall: Thinking controls are only technical. A security awareness training program, a background check on new employees, or a policy requiring strong passwords are all controls. The majority of FIPS 200 functional requirements are primarily management issues, not purely software or hardware solutions.
3.2.7 Risk (Cyber Risk)
Risk is the likelihood of a threat occurrence by a threat actor, resulting in adverse impact, after exploiting a vulnerability. All the pieces must come together: there must be a threat actor, an adverse impact, and an exploitation of a vulnerability.
Risk formula: Where:
- Likelihood is the probability that a threat exploits a vulnerability
- Impact is the consequence if the threat materializes
- Both must be present for risk to exist
You articulate risk as: "There is a 90% likelihood of a professional cyber criminal exploiting a SQL injection on our website, resulting in loss of data." This is the language of risk — probability, threat actor, vulnerability, and impact combined.
Risk vs. threat: Risk is always before the attack. If the damage has already happened, it is an incident. The goal of security is never to completely eliminate threat (that is impossible) but to minimize risk. The risk model is the preferred framework for prioritization because it is contextual — unlike the CIA triad, which describes parameters but does not directly prioritize.
The open manhole risk assessment:
- If there is no lid, no barricade, the hole is deep, and it is on an active road — the risk is high
- If you add a proper lid (remediation) or a barricade (mitigation), the risk drops
- If the road is abandoned and nobody uses it, the risk is low regardless of the vulnerability
- Risk = Likelihood (someone walks by and falls in) × Impact (injury or death)
Common pitfall: Confusing risk with vulnerability. A SQL injection is a vulnerability. The risk is "a cyber criminal could exploit this SQL injection to steal customer data." Without a threat actor and an impact, there is no risk — just a vulnerability.
3.3 The CIA Triad — Confidentiality, Integrity, Availability
Why the CIA triad matters: The CIA triad is the foundational model for understanding what any security incident impacts. Every use case in this course can be analyzed through the lens of: does it affect confidentiality, integrity, or availability? If you cannot classify a security problem into one or more of these three categories, you probably do not understand the problem yet.
The CIA triad is not just a textbook concept — it is the framework that security professionals use daily to categorize threats, design controls, and communicate risk. The three letters stand for Confidentiality, Integrity, and Availability. Every security incident, every malware variant, every attack technique ultimately targets one or more of these three properties.
3.3.1 Confidentiality
Confidentiality means only the authorized person, program, or process can access protected data. A failure of confidentiality occurs when an unauthorized person accesses a data item, an unauthorized program processes a data item, or even when an unauthorized person detects the existence of a data value.
Confidentiality (from NIST FIPS 199):
- Data confidentiality: Assures that private or confidential information is not made available or disclosed to unauthorized individuals
- Privacy: Assures that individuals control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed
- Loss of confidentiality: The unauthorized disclosure of information
Example: Accessing a file server you are not authorized to view is a confidentiality failure. Later in this course, machine learning will be applied to identify scenarios where confidentiality is breached — for instance, through behavioral analytics and anomaly detection. A hospital employee accessing patient records they are not authorized to view is a confidentiality violation, even if they do not modify the data.
Real-world: File integrity monitoring systems track who modified files, when, and whether they had authorization. These systems help detect confidentiality breaches by logging access patterns and flagging unusual behavior — for example, an employee accessing records outside their normal working hours or accessing records they have never accessed before.
Common pitfall: Thinking confidentiality is only about encryption. Encryption protects data in transit and at rest, but confidentiality also requires access controls, authentication, and audit logging. A system with strong encryption but weak access controls still has confidentiality problems.
3.3.2 Integrity
Integrity means data is precise, accurate, and unmodified — except in ways that are authorized and acceptable. It is not just about reading data; it is about tampering with it.
Integrity (from NIST FIPS 199):
- Data integrity: Assures that information and programs are changed only in a specified and authorized manner
- System integrity: Assures that a system performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation of the system
- Loss of integrity: The unauthorized modification or destruction of information
Real-world anecdote — the grade-tampering students: An educational institution's IT administrator reported that students were smarter than the IT team. The students knew how to poke around the college LAN and Wi-Fi. The worry was not just that students might access the marks server, but that they might change their grades. That is an integrity problem — the exam results have been tampered with.
Real-world anecdote — the HR salary hack: An HR administrator worried that employees might somehow gain access to the HR server and update their own salaries. Without proper controls, this is exactly an integrity violation. The data itself is not stolen — it is altered without authorization.
Authorized processes and integrity: Authorized processes modifying data is also part of integrity. A batch program that updates employee salaries after a hike announcement is an authorized process. In the modern era, AI agents acting on behalf of users are authorized processes — and controlling what they can modify is an active area of concern. The challenge is ensuring that authorized processes do not exceed their intended scope.
Example: A hospital patient's allergy information stored in a database must be accurate. If a nurse deliberately falsifies the data to cause harm, that is an integrity violation. The database needs to be restored to a trusted basis quickly, and it should be possible to trace the error back to the person responsible. Inaccurate information could result in serious harm or death to a patient and expose the hospital to massive liability.
3.3.3 Availability
Availability means the system is up and running when needed. It is not about unauthorized access or tampering — it is about the system being there when you need it.
Availability (from NIST FIPS 199):
- Ensuring timely and reliable access to and use of information
- Loss of availability: The disruption of access to or use of information or an information system
- The more critical a component or service, the higher the level of availability required
If GitHub is down and a team needs to check in code for a product release, availability is compromised. If a supermarket cashier cannot process payments because the billing system is down, availability is lost.
Real-world: Reports exist of human casualties due to ransomware attacks causing non-availability of hospital systems. A German hospital had to transfer patients to another facility because systems were unavailable, and a patient died during transport. Attacks on IT systems can kill people. This is not a theoretical risk — it has happened.
Example: A system that provides authentication services for critical systems, applications, and devices has high availability requirements. An interruption of service results in the inability for customers to access computing resources and staff to access the resources they need to perform critical tasks. The loss of the service translates into a large financial loss in lost employee productivity and potential customer loss.
3.3.4 Acts of Harm Model
Acts of harm model — another way to frame security impacts:
- Interception: Confidentiality is lost — someone is eavesdropping on your communication
- Interruption: Availability is lost — the system is down or unresponsive
- Fabrication: Integrity is lost — someone created fake data
- Modification: Integrity is lost — someone altered existing data
These are different theoretical models for the same underlying problems. Having multiple models helps approach security from different angles. The acts of harm model maps directly to the CIA triad:
| Act of Harm | CIA Component | Example |
|---|---|---|
| Interception | Confidentiality | Eavesdropping on network traffic |
| Interruption | Availability | DDoS attack taking down a website |
| Fabrication | Integrity | Creating fake user accounts |
| Modification | Integrity | Altering database records |
Exam note: The CIA triad, vulnerability-threat-control paradigm, and acts of harm model are all frameworks students should know. The professor emphasizes that models here are theoretical models, not machine learning models. Understanding which component of the CIA triad is affected by a given attack is a fundamental skill for this course.
Prioritization is contextual: Does it make sense to classify priorities in the security triad, with availability first? The answer is: it depends. In a manufacturing scenario with a conveyor belt, availability is paramount — the factory floor manager cannot slow down production. In a different scenario, confidentiality might be most important. In another, integrity. All three matter; which one matters most depends on the situation. A proper risk assessment determines prioritization — not a fixed ranking.
3.4 Product Security vs. Security Products
3.4.1 The Distinction
Why this distinction matters for this course: Understanding whether you are building security into a product or building a product for security determines your approach, your threat model, and your success criteria. This course focuses on the latter — but the concepts overlap.
A critical distinction in this course:
- Product security is about building a product securely — threat modeling, security requirements, secure coding principles, security testing, secure deployment. This is the focus of courses like Secure Software Engineering.
- Security products are purpose-built tools to protect networks, devices, systems, and data — firewalls, antivirus software, intrusion detection systems, SIEM platforms, web application firewalls.
The home analogy: To protect your home, you might build high walls and strong doors (product security — the house itself is built strong). You might also install a biometric lock or an alarm system (security products — auxiliary tools that protect the house). Both are necessary, but they serve different purposes. A house with strong walls but no alarm is still vulnerable to a determined intruder. A house with an alarm but weak walls is easy to break into.
Product security activities:
- Threat modeling during design
- Security requirements gathering
- Secure coding principles (input validation, output encoding, least privilege)
- Security testing (penetration testing, code review, fuzzing)
- Secure deployment (configuration hardening, patch management)
Security products:
- Firewalls (network traffic filtering)
- Antivirus/antimalware (signature and behavior-based detection)
- Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS)
- SIEM (Security Information and Event Management) platforms
- Web Application Firewalls (WAF)
- Identity and Access Management (IAM) systems
3.4.2 Course Focus and Adversarial ML
This course focuses predominantly on security products — the ML models students build will go into firewalls, threat detection systems, identity management systems, and similar security products. However, the concepts apply to product security as well.
Where ML fits in security products:
- Malware detection: ML models that classify files as malicious or benign
- Network intrusion detection: ML models that detect anomalous network traffic
- DDoS detection: ML models that identify distributed denial-of-service attacks
- Brute-force detection: ML models that detect credential guessing attempts
- Anomaly detection: ML models that identify unusual patterns in system behavior
- DGA detection: ML models that detect domain generation algorithms used by botnets
Even security products need to be secured themselves. Toward the end of the course, adversarial machine learning addresses this: someone attacking the ML systems inside security products. Approximately the last 5% of the course covers adversarial ML — how to protect the ML models that protect everything else.
The meta-problem: If you build an ML model to detect malware, an attacker can try to fool your model. This is the adversarial ML problem. The attacker does not need to break your system — they just need to make your ML model misclassify. This is why understanding adversarial ML is critical for anyone building security products with ML.
Example: A spam filter (security product) uses an ML model to classify emails as spam or ham. A spammer (attacker) studies the filter and crafts emails that the model classifies as ham. The spammer does not need to hack the email server — they just need to understand how the ML model makes decisions and exploit its weaknesses. This is adversarial ML in action.
3.5 Threat Types and Threat Actors
3.5.1 Common Threat Types
Why threat literacy matters: You cannot defend against what you do not understand. This section is not just a glossary — it is a map of the battlefield. Each threat type has different characteristics, different detection challenges, and different countermeasures. Understanding these differences is essential for building effective ML-based security products.
The landscape of threats is diverse and constantly evolving:
Malware threats:
- Virus: Malware that executes without the user's knowledge, often attaching to legitimate programs. Requires a host program to propagate.
- Worm: Self-replicating malware that copies itself across systems without requiring a host program. Can spread rapidly across networks.
- Trojan: Malware disguised as legitimate software to avoid detection. Users install it thinking it is a useful program.
- Rootkit: Once installed, extremely difficult to remove; they hide their presence in the system. Often operates at low levels of the operating system.
- Keylogger: Captures every keystroke on a device and relays it to a remote server. Used to steal passwords, credit card numbers, and other sensitive data.
- Ransomware: Encrypts systems and demands payment (typically in Bitcoin) for decryption. The supermarket anecdote (see below) illustrates this vividly.
- Spyware: Malware installed without permission for espionage and information collection.
- Adware: Malware that injects unsolicited advertising material into a user interface.
Network and application threats:
- Phishing: A malicious link sent via fraudulent email, instant message, or other communication. Real-world: WhatsApp fraud messages claiming "your vehicle chalan — you violated traffic rules, click to pay." The link installs an APK file (Android application) that steals data. Even experienced security professionals are not immune — phishing can be extraordinarily sophisticated.
- Spear phishing: Targeted phishing aimed at specific individuals or organizations. Uses personal information to make the attack more convincing.
- DDoS (Distributed Denial of Service): Overwhelms a system with traffic, causing availability loss. Uses botnets to generate massive traffic volumes.
- SQL injection: Exploiting a vulnerability in database query handling. Attacker injects malicious SQL code through user input fields.
- Credential abuse: Brute-forcing passwords on the internet. Attackers try common passwords or stolen credentials from data breaches.
- Crypto mining attacks: Unauthorized use of computing resources for cryptocurrency mining. Attackers compromise systems to use their processing power.
Social engineering and content threats:
- Misleading content, defaced websites, fake websites: Common threats targeting end users.
- Social engineering: Information extraction from humans using nontechnical methods such as lying, trickery, bribery, blackmail.
- Botnet: A large network of compromised computers (bots) controlled by attackers. Used for DDoS, spam, credential stuffing, and more.
Real-world — the supermarket ransomware: On a Sunday, the professor and his son went to a nearby supermarket. When they tried to pay, the card system was down. The cashier turned the monitor around and showed a classic ransomware message: "This system is encrypted. To unlock, pay so-and-so Bitcoin." The parent organization — a Middle Eastern chain — had been hit. The supermarket's POS (Point of Sale) systems and loyalty programs were completely locked. Customers were frustrated, queues were long, people walked out, and the business was losing revenue. This is not an IT company — it is a supermarket. Anything that IT touches, even a chain of dental hospitals, even a Kirana store, can be hit by ransomware. The impact is real and growing.
Real-world — the WhatsApp phishing message: A WhatsApp message claims "your vehicle chalan — you violated traffic rules, click to pay." The link installs an APK file (Android application) that steals data. Even experienced security professionals are not immune — phishing can be extraordinarily sophisticated. The attack works because it exploits urgency and fear — the victim thinks they have a traffic violation and clicks without thinking.
Common pitfall: Thinking these threats are only problems for large organizations. The supermarket ransomware story shows that any organization — even a grocery store — can be hit. If it has IT systems, it is a target. The attack surface is everywhere.
3.5.2 Threat Actors in Depth
Beyond the types listed in Section 3.2.4, threat actors vary in sophistication and motivation:
Threat actor spectrum:
- Disgruntled employees: Real-world — an employee at a large company was fired, discovered their cloud account was still active two days later, and deleted virtual machines as revenge. Insider threats are particularly dangerous because insiders have legitimate access.
- Nation-state actors: Superbly funded, extremely difficult to fight. During border tensions, government websites are targeted for defacement. These actors have access to zero-day vulnerabilities and advanced tools.
- Competitors: Espionage for source code, designs, or trade secrets. Companies like Google have reported that competitors attacked and stole source code.
- Organized crime: Loosely connected criminal networks. Motivated by financial gain. Operate like businesses — with specialization, outsourcing, and marketplaces.
- Hacktivists: Politically or socially motivated attackers. Use cyberattacks to promote a cause or protest.
- Vendors: Third-party vendors who may inadvertently or deliberately become threat actors. Supply chain attacks target the weakest link in the chain.
Real-world: During geopolitical tensions with neighboring countries, customers of the professor's company received private intimations from the Ministry of IT about security measures needed. Wars can be waged on economies, IT systems, and biological fronts — not just at borders. Nation-state cyberattacks are not theoretical — they happen regularly during geopolitical conflicts.
Example — the cyber attacker's economy: Internet-based criminality has become increasingly commercialized. The transformation from a reputation economy ("street cred," glory, mischief) to a cash economy (direct monetary gains, advertising, sale of private information) means that attackers are increasingly professional. Darknet marketplaces and illegal hacking forums exist where vulnerabilities, exploit kits, and compromised credentials are bought and sold. Lower-skilled "hackers" can participate by purchasing tools and scripts.
The cat-and-mouse game: If defenders use ML, attackers also use ML. Attackers study the defenses and adapt. Spammers have been known to apply polymorphism (changing the appearance of content without changing its meaning) to circumvent detection, or to probe spam filters by performing A/B tests on email content. Both good guys and bad guys use machine learning in fuzzing campaigns to speed up the process of finding vulnerabilities. This is the fundamental nature of the battle — a continuous cycle of escalation.
3.6 Challenges in Cybersecurity Defense
3.6.1 Complexity and Evolving Threats
Why this section matters for ML practitioners: These challenges directly affect how ML models are built, deployed, and maintained. If you do not understand the environment your model operates in, you cannot build an effective model. Every challenge listed below has implications for data collection, feature engineering, model training, and model maintenance.
The complexity of modern cybersecurity defense is enormous, and these challenges directly affect how ML models are built and maintained:
Challenge 1: Security product sprawl Large conglomerates deploy 40–45 different security products. The sheer complexity of integrating and managing them is staggering. Each product generates its own logs, alerts, and data formats. An ML model that needs to work across multiple products must handle heterogeneous data sources — this is a data engineering challenge as much as a machine learning challenge.
Challenge 2: Remote and hybrid workforces When COVID hit, organizations rushed to deploy VPNs and remote access solutions. ML models trained on network traffic assuming employees were in the office went "for a complete toss" — the features were different. When companies called employees back, models trained on remote traffic broke again. The data, attributes, and features shift with the work environment.
This is a critical lesson: ML models are only as good as the data they are trained on. If the underlying data distribution changes (a concept called data drift or concept drift), the model's performance degrades. In cybersecurity, the data distribution changes frequently — and sometimes abruptly.
Challenge 3: Emerging technologies
- 5G applications: Network traffic baselines change when moving from gigabit internet to 5G. Models trained on one network technology may not generalize to another.
- Cloud and IoT attacks: New attack surfaces emerge as organizations move to cloud and IoT. Each new technology introduces new vulnerabilities and new data patterns.
- Software vulnerabilities: Almost every single day, new vulnerabilities are discovered. The attack surface is constantly expanding.
Challenge 4: Evolving attack techniques Continuously evolving ransomware: Attack techniques evolve faster than defenses. Attackers adapt to new defenses, find new vulnerabilities, and develop new tools. A model trained on last year's ransomware may not detect this year's variant.
Challenge 5: Adversarial ML — the cat-and-mouse game If defenders use ML, attackers also use ML. If we come up with better techniques, they come up with better techniques. It is a cat-and-mouse game. Attackers can:
- Study the ML model and craft inputs that evade detection
- Use ML to generate more convincing phishing emails
- Use ML to find vulnerabilities faster than defenders can patch them
- Poison training data to make the model learn the wrong patterns
The fundamental asymmetry: The attacker needs to find only one weakness. The defender must find and eliminate all weaknesses. This asymmetry is why cybersecurity is so challenging — and why ML is both a powerful tool and a potential attack surface.
Example — COVID broke ML models: An organization deployed an ML model to detect anomalous network traffic. The model was trained on data from employees working in the office — normal traffic patterns included internal file transfers, printer communications, and local server access. When COVID forced everyone to work from home, all traffic went through VPN. The model flagged normal VPN traffic as anomalous because it did not match the training data. The model had to be retrained on remote work traffic. When employees returned to the office, the model had to be retrained again. This illustrates the challenge of concept drift in cybersecurity ML.
The professor's message: The field of cybersecurity is so dynamic that things change fast. It is always a cat-and-mouse game. Attackers and defenders are in a continuous cycle of escalation. Building ML models for cybersecurity is not a one-time task — it requires continuous monitoring, retraining, and adaptation.
3.7 Student Questions and Answers
3.7.1 ML Models for Cyber Defense
Q: Which ML models will help in cyber defense, and are any models available readily? A: There is no single ML model for cyber defense, and there is no single cyber defense use case. "Cyber defense" is too broad a term — it is like boiling the ocean. You must define the precise problem: brute force detection, DDoS detection, lateral movement, data theft, data exploitation, and so on. The professor has identified 100+ use cases. Even if you define the problem well, there will not be one single model — there are theorems about this that will be discussed in later classes. You can go to Hugging Face and search for "cybersecurity" to find models for specific use cases (e.g., a brute force model), but there is no blanket "cyber defense" model. The nature of data, attributes, features, and the kind of data available varies enormously across use cases — that is why you need multiple models for multiple scenarios.
Key insight: The professor's point is fundamental — "cyber defense" is not a single problem. It is a collection of hundreds of distinct problems, each with its own data characteristics, feature spaces, and detection challenges. A model trained to detect DDoS attacks will not detect malware. A model trained to detect brute-force attacks will not detect data exfiltration. This is why the course covers multiple use cases — each one requires a different approach.
Q: Can we apply machine learning on firewall text logs to figure out patterns and forecast future events? A: Yes, you can apply both supervised and unsupervised ML to firewall event logs (pumped into a SIEM or Splunk). However, the use case may not be about forecasting events — it is more about detecting whether people are trying to bypass the firewall, abuse configured rules, or find loopholes. The specific use case depends on what kind of firewall it is (Layer 3, Layer 4, Layer 7) and what you are looking for.
Q: Are organizations using agentic AI to automate security workflows? A: Yes, there is an uptick. Many startups are using agents to automate incident response, vulnerability management, and GRC (Governance, Risk, and Compliance) flows. It is in an early phase but the trend is picking up. Security will be the bottleneck — as long as agents can be secured, they can be used. Securing agents themselves is an active concern.
Q: Can generative AI replace ML models for cybersecurity use cases like anomaly detection? A: Reasoning models are being built for analyzing logs, but they are still in an early phase. Building effective systems is not only about the LLM model — it is about the RAG (Retrieval-Augmented Generation) pipeline, the contextual data provided, and the applications built on top. Context quality is critical.
Q: If you train ML models with open source data, is it easy for attackers to build malware agents to evade them? A: The question is valid. Attackers do have an edge if models are trained on public data. But it is not that straightforward — it depends on the features extracted and the robustness of the ML model built. It is not only about the data. If you take enough measures to make your ML model robust, it may not be easy to evade. This topic will be covered in depth during the malware detection module (around the fifth to seventh contact sessions).
Q: Is this course useful only for security product designers, or also for SOC analysts? A: It is most appropriate for SOC analysts. ML is predominantly about data, and SOC teams are best positioned to have data access. The use cases — threat detection, brute force detection, DDoS models, breach detection — squarely fit SOC environments. Security product designers can also benefit, but the course is not limited to them.
Q: What could be "authorized processes" as mentioned in the definition of integrity? A: When we say authorized people modifying data, it is clear. But authorized processes also modify data. A batch program that increments employee salaries by 10% after a hike announcement is an authorized process. In the modern era, AI agents acting on behalf of users are authorized processes — controlling what they can modify is a growing concern.
Q: Does it make sense to classify priorities in the security triad, with availability first? A: Prioritization is subjective and contextual, not fixed. The risk model is a better framework for prioritization because it accounts for context. In a manufacturing scenario with a conveyor belt, availability is paramount — the factory floor manager cannot slow down production. In a different scenario, confidentiality might be most important. In another, integrity. All three matter; which one matters most depends on the situation. A proper risk assessment determines prioritization.
3.8 Exam Guidance Summary
3.8.1 Assessment Components and Exam Advice
Exam note: The assessment has three components — EC1 (quiz + assignment, 30%), EC2 (midterm, closed book, 30%), and EC3 (final, open book, 40%).
Exam note: Quiz 1 covers material through roughly the third or fourth contact session. It is open for seven days, 10 marks, 30 minutes, no negative marking. Do not miss it — it is easy marks and covers foundational material.
Exam note: The assignment is a hands-on working prototype, not a research report. It opens after the midterm and runs for 14 days (two weekends). Individual submission. Focus on building something that works, not on writing a lengthy report.
Exam note: The midterm is closed book, covering the first seven to eight classes. Mix of theory and applied questions. No deep math or equations — focus on understanding concepts and their applications.
Exam note: The final exam is open book. Students may bring annotated PPTs with a watermark marker. Wait until the last two classes before printing, as the watermarking may change.
Exam note: Nothing will appear on exams beyond what is taught in class. Attend classes or watch recordings, follow the course material and references, and be curious.
Exam note: The CIA triad, vulnerability-threat-control paradigm, and acts of harm model are all important theoretical frameworks to understand. These are theoretical models, not machine learning models.
Exam note: Definitions of asset, vulnerability, threat, threat actor, impact, controls, and risk must be clear in students' minds. The professor will use these terms throughout the course, and confusion between them will hinder learning.
3.9 Key Industry Applications
3.9.1 Real-World Cybersecurity Connections
The cybersecurity landscape is real and growing:
- Ransomware attacks are at an all-time high and growing. Even non-tech businesses like supermarkets are affected — POS systems, loyalty programs, and payment processing can all be locked down.
- The Verizon Data Breach Report documents the gravity of the cybersecurity situation — credential abuse, exploitation of vulnerabilities, phishing, and other attacks are increasing year over year.
- Large organizations deploy 40–45 different security products, creating enormous integration and management complexity.
COVID and ML model fragility: During COVID, the shift to remote work broke ML models trained on in-office network traffic. When employees returned, models trained on remote traffic broke again — illustrating that ML models must continuously adapt to changing environments. This is a concrete example of concept drift in cybersecurity ML.
Nation-state cyberattacks: During geopolitical tensions, nation-state actors target government websites for defacement. These attacks are well-funded, sophisticated, and difficult to defend against. They represent the highest tier of the threat actor spectrum.
Human casualties: The German hospital ransomware incident caused patient transport and a death — demonstrating that cyberattacks can cause human casualties. This is not a theoretical risk — it has happened. Cybersecurity is not just about protecting data; it is about protecting lives.
AI agents in security: AI agents are being used to automate incident response, vulnerability management, and GRC (Governance, Risk, and Compliance) flows. Securing these agents is an emerging challenge. The agents themselves become attack surfaces — if an attacker can compromise an AI agent, they can manipulate its actions.
Resources for staying current:
- Hugging Face: The largest collection of open-source ML models; searching for "cybersecurity" yields models for specific use cases
- Conference recordings: B-sides and RSA conferences are recommended for staying current with cybersecurity research
- Verizon Data Breach Report: Annual report documenting the state of cybersecurity threats and trends
The key takeaway: Cybersecurity is not just an IT problem — it is a business problem, a safety problem, and a national security problem. The threats are real, growing, and increasingly sophisticated. ML offers powerful tools for detection and response, but it is not a silver bullet. Understanding the domain — the threats, the actors, the challenges — is essential for building effective security solutions.
AMTCS Lecture 3 notes · Introduction to Cybersecurity — Core Concepts and Definitions
Sections Breakdown
Course theme, structure, textbooks, references, and assessment structure
Core definitions: asset, vulnerability, threat, threat actor, impact, controls, and risk
Confidentiality, integrity, availability, and the acts of harm model
Distinction between building secure products and security tools, with adversarial ML context
Common threat types (malware, phishing, DDoS) and threat actor categories
Complexity, evolving threats, concept drift, and the cat-and-mouse game
Q&A on ML models for cyber defense, firewall logs, agentic AI, and more
Assessment components and exam preparation advice
Real-world cybersecurity connections and resources
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
Course Overview and Expectations
Must-know: Assessment structure: EC1 (quiz+assignment, 30%), EC2 (midterm, 30%), EC3 (final, 40%). Quiz 1: 10 marks, 30 min, open 7 days. Assignment: working prototype, 14 days. Nothing beyond class material on exams.
Top pitfall: Treating the assignment as a research report instead of a working prototype.
Self-check: What percentage of the final grade is the open-book exam?
Connects to: 3.2 Fundamental Cybersecurity Definitions, 3.3 The CIA Triad
Fundamental Cybersecurity Definitions
Must-know: Definitions of asset, vulnerability, threat, threat actor, impact, controls, and risk must be clear. Risk = Likelihood × Impact. Threat is pre-ante; incident is post-ante. The open manhole analogy ties all concepts together.
Top pitfall: Confusing risk with vulnerability. A SQL injection is a vulnerability; the risk is that a threat actor exploits it to cause harm.
Self-check: What is the difference between a threat and an incident?
Connects to: 3.3 The CIA Triad, 3.5 Threat Types and Threat Actors
The CIA Triad — Confidentiality, Integrity, Availability
Must-know: CIA triad: Confidentiality (unauthorized disclosure), Integrity (unauthorized modification), Availability (disruption of access). Acts of harm: Interception, Interruption, Fabrication, Modification. Prioritization is contextual — use risk model.
Top pitfall: Thinking confidentiality is only about encryption. Also requires access controls, authentication, and audit logging.
Self-check: Which CIA component is affected by a DDoS attack?
Connects to: 3.2 Fundamental Cybersecurity Definitions, 3.5 Threat Types and Threat Actors
Product Security vs. Security Products
Must-know: Product security builds products securely. Security products protect systems. Course focuses on security products. Adversarial ML protects the ML models that protect everything else.
Top pitfall: Thinking product security and security products are the same thing. They have different goals and approaches.
Self-check: Is a firewall an example of product security or a security product?
Connects to: 3.5 Threat Types and Threat Actors, 3.6 Challenges in Cybersecurity Defense
Threat Types and Threat Actors
Must-know: Common threat types: malware (virus, worm, trojan, rootkit, ransomware), network threats (phishing, DDoS, SQL injection), social engineering. Threat actors vary in sophistication: insiders, nation-states, competitors, organized crime, hacktivists.
Top pitfall: Thinking threats only target large organizations. Any system with IT is a target.
Self-check: What is the difference between a virus and a worm?
Connects to: 3.2 Fundamental Cybersecurity Definitions, 3.6 Challenges in Cybersecurity Defense
Challenges in Cybersecurity Defense
Must-know: Key challenges: security product sprawl, concept drift from changing work patterns, evolving attack techniques, adversarial ML. ML models must be continuously monitored and retrained.
Top pitfall: Building an ML model once and assuming it will work forever. Data distribution changes in cybersecurity are frequent and sometimes abrupt.
Self-check: Why did COVID break ML models trained on network traffic?
Connects to: 3.5 Threat Types and Threat Actors, 3.7 Student Questions and Answers
Student Questions and Answers
Must-know: No single ML model for cyber defense — 100+ use cases, each needs different model. Firewall logs: ML for detection not forecasting. CIA prioritization is contextual, not fixed. Course is most useful for SOC analysts.
Top pitfall: Thinking there is one ML model that solves all cybersecurity problems. Cyber defense is too broad — must define the precise problem first.
Self-check: Why is there no single ML model for cyber defense?
Connects to: 3.2 Fundamental Cybersecurity Definitions, 3.3 The CIA Triad, 3.6 Challenges in Cybersecurity Defense
Exam Guidance Summary
Must-know: EC1 (quiz+assignment, 30%), EC2 (midterm, 30%), EC3 (final, 40%). Quiz 1: 10 marks, 30 min, open 7 days. Assignment: working prototype. Midterm: closed book. Final: open book. CIA triad and definitions are examinable.
Top pitfall: Missing Quiz 1 — it is easy marks and covers foundational material.
Self-check: What percentage of the final grade is the closed-book midterm?
Connects to: 3.1 Course Overview and Expectations
Key Industry Applications
Must-know: Ransomware attacks growing. COVID broke ML models (concept drift). Cyberattacks can cause human casualties. AI agents for security automation. Resources: Hugging Face, B-sides/RSA.
Top pitfall: Thinking cybersecurity is only an IT problem. It is a business, safety, and national security problem.
Self-check: What is concept drift and how did COVID illustrate it?
Connects to: 3.5 Threat Types and Threat Actors, 3.6 Challenges in Cybersecurity Defense
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.