ML Algorithm Selection for Security Applications

# ML Algorithm Selection for Security Applications

6.1 No Free Lunch Theorem — Recap and Security Context

The No Free Lunch Theorem (often abbreviated NFL or NFLT) states that there can be no single ML algorithm that performs optimally across all problem instances. This is a generic theorem from optimization theory, not specific to security — it applies to any ML model you build for any domain. Averaged over all possible problems, all algorithms perform the same, so the quest for a universal best algorithm is futile. Algorithm selection must always be problem-specific.

The theorem was originally formalized by Wolpert and Macready in 1997 in the context of optimization, and its implications extend directly to machine learning: if you average performance over every possible data distribution, every learner achieves the same error rate. The practical takeaway is not that algorithms are useless — it is that no algorithm dominates on the specific distributions we care about unless we match it to the problem structure.

6.1.1 Two Interpretations in Security

The theorem has two useful interpretations in a security context, moving from an obvious "apples to oranges" reading to a more subtle "apples to apples" one.

Apples to oranges (different problem types): Consider data exfiltration — someone trying to steal data from your organization using network logs, server logs, or application logs — versus intrusion detection — someone trying to enter your network. These are fundamentally different problems. There cannot be a single ML model (say, an isolation forest) that detects both breach detection and data exfiltration optimally. This interpretation is straightforward: different problem types demand different algorithms.

Apples to apples (same problem type, different context): Even within data exfiltration alone, a single algorithm cannot handle all variants. Consider two data exfiltration scenarios:

1. Cloud S3 bucket exposure: All your data sits in AWS S3 buckets. Someone left a configuration open to the public — a common mistake, especially during early cloud adoption — and anyone can download the data. This is one kind of data exfiltration. The data sits at rest; the exfiltration is passive (anyone can access it). Features like access logs, unusual IP addresses, and download volume are key signals.
2. Data center theft: An attacker breaches the network, discovers a SQL database password, and figures out how to upload data to a remote server. This is also data exfiltration. But here the data is in motion; the attacker actively queries the database and pushes results outward. Features like SQL query patterns, network connection timing, and data transfer direction matter.

Can a single ML algorithm detect both? Even here, within the same problem family, the answer is no. The contexts differ fundamentally — publicly exposed cloud storage versus deeply nested data center databases behind firewalls. The feature engineering, data collection, and detection logic must be tailored to each scenario.

The bottom line: Context determines the optimal choice. The context of AWS S3 buckets left open is different from the context of data exfiltration from a database server inside a data center. This applies everywhere. Brute force detection, for example, has different contexts depending on whether it is application brute force (web application username/password attacks, data logged from a browser) or server login brute force (SSH login attempts from a terminal). Each context demands different feature engineering, different data collection, and potentially different algorithms.

Selecting the right algorithm comes from exposure to different algorithms, reading white papers, and experimentation. It is not a "plug it in, see it works, move on" process. The companion text Machine Learning and Security (T1) reinforces this: the authors emphasize that applying machine learning to security "is not a straightforward task" and that "developers still need to make many decisions along the way" — the NFL theorem is the mathematical reason why.

6.2 Algorithm Selection Criteria

Since no single algorithm works everywhere, you need a structured way to select algorithms for security use cases. Four key criteria guide this selection. These are critical both for exams and for real-world implementation. Think of these four criteria as a decision checklist: before you touch any ML library, you must answer all four questions about your specific problem.

6.2.1 Interpretability versus Performance

This is a fundamental trade-off. Interpretability means the ability to explain why an algorithm made a particular decision — which features drove the output, what the decision path looked like, and why the model flagged one thing but not another. Performance means speed, accuracy, or throughput — how fast the model runs, how many predictions it can make per second, and how accurate those predictions are.

Why interpretability matters in security: In a Security Operations Center (SOC), efficacy is measured by how many alerts come in and how many the team acts upon. Alerts arrive from multiple sources — server compromises, data exfiltration, network anomalies. If an alert is not interpretable — meaning the SOC analyst or administrator cannot understand why the alert was raised — it will not be acted upon. The algorithm's output gets ignored or turned off.

This is the same distinction between anomalous and malicious. If you flag something as "anomalous" without explaining why, the SOC operator cannot determine whether it is actually malicious. A cricket match streaming spike is anomalous but not malicious. Without interpretability, the operator cannot distinguish the two.

Neural networks struggle here. You can describe having millions of parameters, but if you cannot explain why a particular alert fired, the output will not fly in a SOC environment. Simpler decision science algorithms — like decision trees or hierarchical scoring — are sometimes better because the decision path is visible and explainable. A decision tree that says "this vulnerability is critical because it is externally-facing (weight 0.4), has a known exploit (weight 0.3), and sits on a critical asset (weight 0.3)" gives the analyst an actionable explanation. A neural network that outputs "priority score: 0.87" does not.

Why performance matters: Consider website security. If a web page takes more than two to three seconds to load, users leave. If you have a browser plugin that determines whether a website is good or bad, that determination must happen within that window. You cannot take seven seconds to provide a complete explanation of malware findings. For companies in the ad business, performance is paramount — people simply move on. Security must be invisible and fast.

The T1 companion text reinforces this: anomaly detection systems "need to run in a streaming fashion, consuming data and generating insights with minimal latency. This requirement rules out some slow and/or resource-intensive techniques."

The trade-off in practice: If you need superior accuracy and can sacrifice explainability, use neural networks. If you must explain to a customer which feature received what weight and why, use decision trees or random forests with visible decision paths. The vulnerability prioritization example illustrates this: you find 10,000 vulnerabilities via a scan, and you need to tell asset owners which to fix first. A simple scoring algorithm that weights features like exploitability, external facing status, and asset criticality is easy to explain and defend. A black-box neural network that outputs a priority score is not.

6.2.2 Real-Time versus Batch Processing

Some security tasks demand near-real-time processing. Others can tolerate batch processing over hours or days. The processing time constraint is one of the strongest filters on your algorithm choice — it can immediately rule out models that are too slow.

Real-time requirements: An intrusion prevention system on a 10 Gbps or 100 Gbps network line must process packets at wire speed. Even a simple lookup to check whether a source IP address is a known bad address must be fast. If the network is slow, end-user experience degrades — the same frustration as airport security bottlenecks. Security should be invisible, protecting without slowing things down.

Batch processing acceptable: Historical incident investigation can tolerate batch processing. For example, a shipping company reported fraudulent emails sent from their organization six months prior. The question was whether logs existed. If six months of Outlook email logs exist, you can batch-process them over several hours. Getting to the bottom of the investigation is more important than near-real-time results. Active directory logs spanning months, stored in systems like ELK, can be batch-processed to find a needle in the haystack.

The selection implication: The processing time constraint narrows your algorithm choices. Real-time tasks on high-speed networks rule out complex models that take seconds per prediction. Batch tasks allow more computationally expensive approaches. Always ask: "What is my latency budget?" before selecting a model.

6.2.3 Labeled versus Unlabeled Data

Labeled data means each data entry is tagged by a human — this image is a cat, this URL is malicious, this network packet is benign. Unlabeled data has no such tags. Your choice of algorithm depends heavily on whether labels are available.

The labeling challenge: Labeling is expensive and niche. At CTU Prague, a professor runs honeypots and a network intrusion detection lab where students manually label network packets as malicious or non-malicious. They built the Stratosphere IPS, an intrusion prevention system based on machine learning. This kind of manual labeling is labor-intensive — each packet requires a trained human to examine it and make a judgment call.

CAPTCHA as labeling: Every time you enter a CAPTCHA — identifying cars, traffic lights, or crosswalks — you are performing labeling for free. This is a brilliant way to get labels at scale. It serves a dual purpose: verifying you are human and building labeled datasets. Google's corpus grows this way. But CAPTCHA alone is not enough for specialized security tasks — identifying traffic lights does not help label malicious URLs.

Spam marking as labeling: When you mark an email or phone number as spam, that is a human signal — a form of labeling. Google or Microsoft can cross-correlate your marking with other users in similar profiles to improve spam detection. Sometimes spam is context-dependent: spam to you may not be spam to someone else. This is a rich, high-quality signal, but it is one source among many.

Labeled data in security contexts:

• Malicious URLs: Alexa top 1 million sites (known good URLs), Kaggle datasets, threat intelligence sources, and block lists like CrowdStrike provide labeled URL data.
• IP reputation: CrowdStrike block lists and similar services provide labeled IP addresses.
• Phone number reputation: Systems like Sanchar Sati build phone number blacklists for fraud prevention. Telecom providers use ML to process user-reported spam SMS and calls, protecting citizens. This is labeled data at national scale — approximately 10 lakh phones have been identified and returned to original owners using ML algorithms on fake IMEI numbers and mule accounts.

When labels are absent: Sometimes you set up a SOC and the manager says there is no budget for labeled data. You have rich data but no labels. Your algorithm selection narrows to unsupervised approaches — anomaly detection, clustering, or density estimation. You may need to crowdsource labels within the team or use techniques like active learning to bootstrap. The T1 companion text notes that "it is common to erroneously think of anomaly detection as the process of recognizing a set of normal patterns and differentiating it from a set of abnormal patterns" — in reality, anomaly detection defines normality and flags deviations, without needing labels for the abnormal class.

Real-world: In industry, it is both supervised and unsupervised — the short answer. The long answer is it depends. Cisco Talos, one of the popular threat intelligence teams, uses a combination. There is no single way of doing it. Internal teams may label critical assets and applications, while research teams use honeypots and other techniques to collect data. External solutions (like Darktrace or Vectra) may use different approaches.

6.2.4 Imbalanced Data Handling

This is one of the most critical and persistent problems in security ML. Class imbalance means the overwhelming majority of your data belongs to one class (benign) while the minority class (malicious) is extremely small.

Why 99.99% accuracy is meaningless in security: Consider a non-security example first. A parking lot uses CCTV cameras and computer vision to detect free slots. The algorithm is 99.99% accurate. In 10,000 predictions, one is wrong — a customer is told slot 19 is free, but it is not. The mall owner accepts this: 10,000 happy customers, one unhappy. That is a perfectly acceptable false positive rate in that domain.

Now apply this to security. A dataset has 10,000 network packets: 99.99% are benign, one packet is malicious. Your ML algorithm achieves 99.99% accuracy. In the real world, that means the algorithm simply predicts everything as benign and achieves that accuracy by simply predicting everything as benign — a naive classifier that predicts all-benign gets 99.99% accuracy. But it misses every single attack. One authentication log entry that should have been flagged — the attacker got in. That 0.01% failure rate in security is catastrophic.

Why this matters for algorithm selection: Before you even think about which ML model to use, you must identify and address the class imbalance problem. If you do not, all subsequent phases — feature engineering, model training, evaluation — are meaningless. The accuracy metric becomes meaningless when classes are this imbalanced. You need imbalance-aware evaluation metrics: precision, recall, false positive rate, false negative rate, F1 score, area under the ROC curve (AUC-ROC), and confusion matrix analysis. It is not just accuracy — you must look at the full picture.

6.3 Techniques for Handling Class Imbalance

Several approaches exist for dealing with the extreme class imbalance in security datasets. The companion text Machine Learning and Security (T1) emphasizes that anomaly detection and pattern recognition are the two broad categories of ML use cases in security — and class imbalance is the reason anomaly detection dominates: when 99.99% of data is normal, learning what "normal" looks like and flagging deviations is more practical than trying to learn what "attack" looks like from a handful of examples.

6.3.1 Cost-Sensitive Learning

If the learning technique can handle asymmetric misclassification costs — meaning the cost of missing a malicious packet (false negative) is much higher than the cost of flagging a benign packet as malicious (false positive) — that is a good start. The algorithm is penalized more for missing attacks than for raising false alarms.

For example, suppose you set cost(FN) = 100 (missing an attack costs 100 units) and cost(FP) = 1 (a false alarm costs 1 unit). The algorithm will now strongly prefer predicting "malicious" when uncertain, because the penalty for missing a real attack is 100× higher than the penalty for a false alarm. This is a simple but effective way to encode security priorities directly into the learning objective.

6.3.2 Resampling (SMOTE)

SMOTE (Synthetic Minority Over-sampling Technique) is one of the easiest approaches. If you have 10,000 samples where 99.9% are benign and 0.01% are malicious, SMOTE generates synthetic samples of the minority class to balance the dataset. It is like generating data based on the few true positives you have, then training the algorithm on the balanced set. This is a simple Python call. There are trade-offs — synthetic data may not perfectly represent real attack patterns — but it is a practical starting point.

from imblearn.over_sampling import SMOTE
smote = SMOTE(sampling_strategy=0.5)  # balance to 50% minority
X_resampled, y_resampled = smote.fit_resample(X_train, y_train)

6.3.3 Algorithm-Inherent Approaches

Some algorithms inherently handle imbalance because they are designed for anomaly detection:

• Isolation Forest: Works by isolating anomalies rather than profiling normal points. The algorithm builds random decision trees and measures how many splits it takes to isolate each data point. Anomalies (the minority malicious class) are isolated quickly — in fewer splits — because they are rare and different. The time complexity is:

$$O(n\log n)$$

where $n$ is the number of training samples. This is manageable for large-scale streaming data — even at millions of packets, the algorithm completes in seconds.

• One-Class SVM: Learns a boundary around the normal class and flags anything outside as anomalous. It trains only on normal data — no attack samples needed — making it ideal when you have abundant benign data but few or no labeled attacks.

The R4 companion text (Data Mining and Machine Learning in Cybersecurity) confirms: "Unsupervised anomaly detection can overcome the drawbacks of supervised anomaly detection" because it "aims to find malicious information buried in cyberinfrastructure even without prior knowledge about the data labels and new attacks."

6.3.4 Ensemble Approaches

An ensemble is a collection of models. You do not run a single algorithm — you run different configurations of the same algorithm or entirely different models. You then combine their outputs through voting, averaging, or weighted decisions. The first time this concept was demonstrated in practice was at a company Cisco acquired from the Czech Republic — Cognitive Security — about 12–13 years ago. It was a revelation: it is not about one algorithm, not about one supervised or unsupervised approach. It is a combination. We will dig deeper into ensemble types as the course progresses.

6.3.5 Evaluation Metrics

Beyond accuracy, you need the full confusion matrix: true positives, false positives, true negatives, false negatives. The F1 score (harmonic mean of precision and recall) and area under the ROC curve (AUC-ROC) are essential. Recall is particularly important in security — you want to minimize false negatives (missed attacks). These metrics will be covered in detail when we reach specific algorithms.

6.3.6 Advanced Techniques

Probability calibration (Platt scaling, isotonic regression) are more advanced approaches for refining model outputs. These are not to be feared — they exist as tools for when simpler approaches are insufficient.

6.4 Supervised versus Unsupervised Learning in Security

This section compares the two paradigms in the security context and argues for hybrid approaches. The T1 companion text (Machine Learning and Security) frames this directly: "We can classify machine learning's use cases in security into two broad categories: pattern recognition and anomaly detection." Supervised learning excels at pattern recognition; unsupervised learning excels at anomaly detection. Security needs both.

6.4.1 Supervised Learning

Supervised learning trains on labeled data — each input has a known correct output. The model learns the mapping from features to labels, then applies that mapping to new, unseen data.

Strengths in security:

• Requires extensive labeled datasets — but when available, produces well-calibrated models
• Relatively low false positive rates because trained on well-defined data — the model has seen both benign and malicious examples and learned the boundary
• High interpretability — decision trees, weights, and decision paths are visible
• Validation is straightforward — you have ground truth labels to measure against

Weaknesses in security:

• Poor at detecting unknown threats (zero-days, novel attacks not in training data) — the model can only recognize patterns it has seen before
• Concept drift is a problem: when the environment changes (work-from-home to office, VPN to zero trust), models must be retrained — the learned patterns become stale
• Requires extensive labeled datasets — expensive and time-consuming to create

The R3 companion text (Basics of Machine Learning in Cybersecurity) describes the supervised learning pipeline: "Supervised learning methods learn from labelled data and then use the insight to make decisions on the testing data." The training phase is iterative — "the data incrementally helps to improve the quality of prediction" — and typically uses 70-80% of labeled data for training and 20-30% for testing.

6.4.2 Unsupervised Learning

Unsupervised learning trains on unlabeled data — the model discovers structure (clusters, anomalies, patterns) without being told what to look for.

Strengths in security:

• Does not require labeled data — can operate in environments where labeling is too expensive or impossible
• Excellent at detecting unknown threats and novel attack patterns — anything that deviates from normal is flagged
• Adapts to environmental changes without retraining — it learns "normal" from current data

Weaknesses in security:

• Higher false positive rates — anomalous does not mean malicious
• Lower interpretability — harder to explain why something was flagged
• Validation is difficult — an analyst must investigate whether flagged anomalies are actually malicious

The R4 companion text (Machine Learning for Anomaly Detection) notes: "Unsupervised anomaly detection aims to find malicious information buried in cyberinfrastructure even without prior knowledge about the data labels and new attacks." However, it also warns: "anomaly detection approaches may trigger high rates of false alarm. Because these methods flag any significant deviation from the baseline as an intrusion, it is likely that nonintrusive behavior that falls outside the normal range will also be labeled as an intrusion."

6.4.3 The Anomalous versus Malicious Distinction

This is a critical point. Unsupervised algorithms flag anomalies — patterns that deviate from normal. But anomaly is not the same as malicious. The professor gives four vivid examples:

This is why interpretability (Section 6.2.1) matters so much for unsupervised models. An anomaly detection system that flags a bandwidth spike AND explains "this spike is caused by video streaming from cricket.com, not data exfiltration to an external server" saves the analyst 30 minutes of investigation.

6.4.4 Hybrid Approaches

The practical answer is to combine both paradigms. The companion texts consistently support this: T1 notes that "a system might make use of both approaches to achieve better coverage" and R4 describes how "semi-supervised and unsupervised machine-learning methods are employed frequently" together.

Unsupervised pre-clustering with supervised refinement: Take the geo-fencing use case. Your boss says: "Do not allow traffic from outside countries, but there is no budget for a geo-intelligence subscription." You cluster IP addresses into buckets using unsupervised learning (k-means or DBSCAN on IP features). Then you go to the application team and ask: "Do you see any activity from these clusters — logins, purchases, article reads?" Based on their feedback, you refine the clusters with supervised labels. First unsupervised, then supervised — a hybrid approach.

Active learning and semi-supervised approaches: These leverage unlabeled benign data plus scarce labeled attacks. You start with what you have and iteratively improve. Active learning selects the most informative unlabeled samples for human labeling — maximizing the value of each expensive label.

Simple fusion: Take multiple methods, fuse their outputs, and use a supervised meta-classifier to make the final decision. This is what happens in the real world — combinations, not single algorithms. The R3 companion text describes ensemble methods (bagging, boosting, stacking) as a way to combine multiple models: "The performance of a model can be improved by ensembling the performance of multiple algorithms."

Practical guidance for industry tools: Solutions like Darktrace, Vectra, and the ML tier in ELK stack may use supervised, unsupervised, or hybrid approaches. It is very context-dependent — the product, version, and deployment scenario all matter. If your organization has a detection engineering team, they can build supervised models with internal labeling (marking critical servers, application paths, good versus bad traffic). Smaller teams may rely more on unsupervised approaches from external solutions.

Security research teams (like Cisco Talos) do the heavy lifting: generating threat intelligence, using honeypots to collect data, and combining labeled and unlabeled approaches. Internal SOC teams typically receive alerts and act on them — they are security engineers, not ML engineers.

The four criteria apply everywhere: Whether you choose supervised, unsupervised, or hybrid, the four selection criteria — interpretability versus performance, real-time versus batch, labeled versus unlabeled data, and imbalanced data handling — all constrain and guide your choice. Do not start with "what is the latest algorithm." Start with "what is my problem context."

6.5 Exam Guidance Summary

6.5.1 Exam Question Format and Expectations

• Scenario-based questions are expected. You may be given a scenario (e.g., designing an email security solution) and asked to defend your algorithm choice. There may not be a single right answer — you must substantiate with concrete reasons. Frame your answer around the four selection criteria: interpretability vs. performance, real-time vs. batch, labeled vs. unlabeled data, and imbalanced data handling.

• Outcomes matter. Your algorithm should serve the purpose in context. Real-world problems are not black and white. The professor evaluates how sound your arguments are, not whether you picked the "correct" algorithm.

• The four selection criteria are critical: interpretability vs. performance, real-time vs. batch, labeled vs. unlabeled data, imbalanced data handling. Be prepared to apply all four to any scenario. If a question asks "what algorithm would you use for X?", structure your answer as: "First, I would consider the latency requirements (real-time vs. batch)... Second, I would check whether labeled data is available... Third, I would assess the class imbalance... Fourth, I would evaluate whether interpretability is required..."

• Confusion matrix, recall, false positive/negative ratios, AUC-ROC — expect questions on these evaluation metrics in the context of imbalanced security data. You should be able to construct a confusion matrix from a scenario, compute recall and precision, and explain what each metric means in security terms (e.g., "recall of 0.95 means we catch 95% of attacks but miss 5%").

• Do not just memorize slides. Understand the rationale, the logic, and how to map concepts to real-world scenarios. The slides are raw material — the exam tests your ability to reason with the concepts.

• Exam questions may have no definitive right or wrong answers. You must argue and substantiate. The professor evaluates how sound your arguments are. A well-reasoned answer that picks an unconventional algorithm but justifies it with all four criteria will score higher than a "correct" answer with no justification.

6.6 Key Industry Applications

6.6.1 Threat Intelligence and Detection Systems

The following real-world systems and tools illustrate how the concepts from this lecture — algorithm selection criteria, class imbalance handling, and supervised vs. unsupervised learning — apply in practice.

• Cisco Talos: Threat intelligence team that researches vulnerabilities, web reputations, and file reputations. Uses a combination of supervised and unsupervised approaches. Cisco acquired Sourcefire and Cognitive Security (Czech Republic) to integrate ML-based threat detection. The Cognitive Security acquisition was the first large-scale demonstration of ensemble approaches in production security — combining multiple ML models to detect threats that no single model could catch alone.

• Stratosphere IPS: Intrusion prevention system built at CTU Prague using machine learning. Students manually label network packets from honeypots. This is a real-world example of the labeled data challenge (Section 6.2.3) — high-quality labels require expert human effort, and the cost limits the scale of labeled datasets.

• Alexa Top 1 Million / Kaggle / CrowdStrike Block Lists: Publicly available labeled datasets for malicious URL and IP detection. These illustrate that labeled data exists in abundance for many security use cases — the claim "we don't have data" is often not true.

• Sanchar Sati: Indian government telecom fraud prevention system. Uses ML on phone numbers, IMEI numbers, and user-reported spam. Distributed approximately 10 lakh phones back to original owners by identifying fake IMEIs and mule accounts. This is labeled data at national scale — a government-scale application of supervised learning on fraud detection.

• Credit Scoring (Sibyl Score): Black-box algorithm controlled by a private company that determines loan eligibility. Cannot be explained — a case study in why interpretability matters (Section 6.2.1). The book Weapons of Math Destruction documents how such opaque algorithms cause harm when gamed.

• Banking fraud detection: Millions of UPI transactions require real-time isolation of fraudulent transfers. Money gets transferred 10 levels deep in 30 minutes, ending in cryptocurrency. Isolation forest at $O(n\log n)$ is fast enough for real-time screening (Section 6.3.3). If there are temporal patterns, RNN-based autoencoders can help. This is a hybrid approach (Section 6.4.4) — unsupervised for speed, supervised for accuracy.

• Malware detection via density analysis: Malware files have varying densities due to encrypted or obfuscated code sections. DBSCAN (Density-Based Spatial Clustering of Applications with Noise) can quickly flag anomalous file structures without identifying the specific malware family. This is an unsupervised approach that leverages the structural differences between benign and malicious files.

• Geo-fencing with hybrid approach: Unsupervised clustering of IP addresses combined with supervised refinement from application-layer activity data. This is the hybrid approach described in Section 6.4.4 — practical, low-cost, and effective.

6.7 Professor Pedagogical Moments

6.7.1 Analogies and Mental Models

The professor uses several vivid analogies and mental models throughout this lecture to make abstract ML concepts concrete. These are preserved here as a quick-reference collection — each is expanded with its context in the relevant section above.

• Security guard analogy for class imbalance (Section 6.2.4): Security guards are bored 99.99% of the time. That one lapse — ignoring a suspicious bag, skipping a check — changes everything. Cybersecurity has the same structure: the ratio of good to bad traffic is tiny, and missing that one malicious packet is catastrophic. The guard's vigilance for 23.5 hours is irrelevant if they sleep for the last 30 minutes.

• Parking lot analogy for accuracy in non-security domains (Section 6.2.4): A parking lot CV system at 99.99% accuracy means one wrong slot prediction in 10,000 — perfectly acceptable. The same 99.99% accuracy in security means you miss every attack, because a naive all-benign classifier achieves that number by simply predicting all benign. Same number, completely different consequences.

• New shiny object syndrome (Section 6.2.1): Do not pick an algorithm because it is the latest paper from Google or the fanciest model in the market. Be skeptical. Define the problem well first. LLMs in vulnerability prioritization may or may not make sense — dig up the analysis and take an informed decision.

• Weapons of Math Destruction (Section 6.2.1): An ML model scored schools based on performance. The algorithm was a black box. Schools gamed it. A toxic culture developed. The whole purpose was defeated. This is why interpretability matters — when the model is opaque, humans optimize for the metric rather than the underlying goal (Goodhart's Law).

• Airport security as a network performance analogy (Section 6.2.2): The bottleneck at airports is security screening. Even with advanced scanners, the security check is the longest queue. They will not compromise security for speed. The same applies to networks — security must be there, but it should be invisible and fast.

• Attacker versus defender asymmetry (Section 6.4): Attackers have to get it right only once. Defenders must get it right every single time. That asymmetry should be the driving motivation for your ML strategy. This is why hybrid approaches matter — no single model can defend against every possible attack, but a layered defense increases the chances of catching the one that matters.