Lab 5: Security with AI — Intrusion and Anomaly Detection

Commit and push each checkpoint to your github repository.

Use Sommer and Paxson’s Outside the Closed World to examine your detector’s assumptions, false alarms, and evaluation.

The papers below are suggestions. You may propose another relevant paper with public source code and accessible data. Discuss the specific result you will reproduce with Vasanta during week one and record it in worksheet A.

Clone your github repo into Firebird. On firebird your directory structure would look like this: $HOME/CS91R/lab5 on Firebird. Keep the worksheet, Slurm script, experiment scripts, configurations, analysis code, and results in this repository.

Place the selected paper’s source checkout inside an upstream/ subdirectory of the course repository. Keep that checkout’s Git history and license intact. Add upstream/ to the course repository’s .gitignore; save any changes you make as a patch or as an identified commit in your own fork.

Also exclude datasets, model weights, and environments from the course repository. The Firebird instructions below explain where to keep inputs and outputs. Submit the small files needed to explain and rerun your work.

Once you choose your paper, complete worksheet sections A–B. Identify the asset, attacker objective, observations available to the defender, and the decision the model produces. State one legitimate change that could cause an alert and one harmful action that might remain familiar in the measured features.

Connect your answers to our class discussion of Outside the Closed World. Explain how false alarms, incomplete visibility, changes in normal behavior, and contaminated training data could affect your chosen detector.

Complete worksheet A–B. Identify the asset, attacker objective, observations available to the defender, and the decision the model produces. State one legitimate change that could cause an alert and one harmful action that might remain familiar in the measured features.

Connect your answers to our class discussion of Outside the Closed World and Kitsune. Explain how false alarms, incomplete visibility, changes in normal behavior, and contaminated training data could affect your chosen detector. In worksheet B, also work through the campus-server scenario, the border-router visibility question, the base-rate calculation, and Kitsune’s processing steps.

Within your git repo on firebird $HOME/CS91R/Lab5, clone the selected paper’s code into upstream/. Determine the appropriate command from the repository’s instructions and run only the clone command for your selected implementation.

A branch identifies a line of development that can change over time. A commit hash identifies the exact revision you used. Record both in worksheet D1. Some repositories need additional version information:

For every option, record the upstream URL, branch or tag, full commit hash, dependencies, and local changes. Retain the license and citation information. A local clone supplies your working copy; record patches or fork commits for any changes needed to reproduce your result.

Complete worksheet D1–D3. Record actual file paths and function, class, or configuration names from your chosen commit. During the walkthrough, open those files and trace one example through the system:

The goal fo the trace through is to connect the code to the paper.

Use these Firebird resources below as reference:

Identify the rule that converts the model’s output into an alert, ranking, or group, and the data used to choose that rule. The evaluation must connect the output to documented labels and explain what additional evidence a defender would need.

As an example in the Kitsune paper, the authors explain how packet-derived statistics enter the ensemble, how the small autoencoders' reconstruction errors feed the output autoencoder, and how its final error becomes a score. For a different paper, explain the corresponding input, learned representation, and output. A grouping system such as DeepCASE may require a different decision and evaluation procedure.

Record what one evaluated observation represents. A false-positive packet, a false-positive host, and an unnecessary attack investigation impose different costs. Do not compare their counts as though they were interchangeable.

If your system groups security events or detects anomalous system behavior without intrusion labels, use the measures that fit that task. Do not come up with binary attack labels to fill a confusion matrix. Explain what the available labels establish about security and what they leave unresolved.

Use the replication target discussed with Vasanta in week one and recorded in worksheet A3 and C5. Complete worksheet E1–E2 before running the experiment: name the paper’s claim, data subset, model configuration, and metric you will compare. Record a hypothesis and a possible observation that would contradict it. Discuss a proposed change to the agreed result with Vasanta and record the change.

Separate the following roles in your data and code:

Your selected paper may use different names or a different protocol. Document its actual procedure. In particular, for online detectors, preserve the intended time order and identify the boundary between learning and evaluation. If the published evaluation uses test labels to select a cutoff, label that choice explicitly and explain its effect on the claim.

A program that exits successfully has passed an execution check. A score plot shows that some outputs were produced. A replication requires connecting those outputs to the stated research claim and evaluating them with the appropriate data and labels.

Reproducible research means that another person can use your recorded code, data, environment, and procedure to rerun the experiment and assess the same claim.

Keep the experiment commands in your run script and the settings in tracked configuration files. Record how to obtain the input data, its version and split, the upstream commit and patches, environment activation and dependency versions, random seeds, and output locations. Put setup and invocation instructions in the script’s comments or its documented help, and link the script and configuration from worksheet F3.

Use these same scripts for the reference run and the four investigations, changing only the intended configuration values. Give each run an identifier and preserve the mapping from invocation to outputs in worksheet E3. Check that the recorded command can be rerun from the course repository with the documented inputs and environment. For stochastic training, report variation rather than promising bit-for-bit identical results.

Use worksheet E5 to inspect at least two concrete cases. For a labeled binary detector, select a false positive and a false negative when available. If one category is empty, report its count and inspect the closest available case. For a grouping system, examine a useful grouping and a misleading or missed grouping instead.

For each case, identify the record or time interval, the available observations, the model’s output, and the ground truth. Explain what additional context a defender would need before responding. Do not infer an attacker’s intent solely from a large reconstruction error.

Explain what your result means for the protected asset. Would the output help an analyst investigate sooner, reduce repeated review, identify relevant processes, or reveal a change in traffic? State which benefit you measured and which remains a hypothesis.

Return to the security principles in worksheet B2. Give a concrete example of an independent control that complements the detector, the permissions the detector needs, and how excessive alerts or computation could impair the defense. Connect at least one limitation to Outside the Closed World.

Change the cutoff-selection rule using only calibration/validation data. Compare the reference operating point and at least one alternative on the same final test data. Report detection and false alarms at both operating points, and explain what security cost accompanied any reduction in alerts. For a grouping or ranking task, identify the corresponding decision rule and report task-appropriate coverage and workload measures.

You may reuse saved scores when comparing cutoffs; changing a cutoff does not by itself require retraining. Choose the rules before inspecting final test results.

Change one parameter, such as Kitsune’s maximum autoencoder size, a log-sequence window, or a graph-context limit. Compare the reference setting and at least one changed setting. Keep the split, cutoff-selection procedure, and other settings fixed. Refit any components affected by the change using only the permitted training data, and compare both detection behavior and resource cost.

State whether the change affected model capacity, the information available to the detector, or both. Explain any change in runtime or memory alongside the security results.

Compare two review or label budgets, selected before examining final test results. For a system that supports analyst feedback, change the feedback budget while holding the data and evaluation procedure fixed. Use only the labels permitted by that feedback protocol.

If the system has no analyst-feedback mechanism, simulate an analyst reviewing two fixed numbers of alerts using the same ranking and grouping rule. Use the available labels to measure useful findings, unnecessary reviews, and missed labeled events at each budget. This is a review-budget analysis; it does not imply that feedback changed the model. Identify your review unit and explain what any missing security labels prevent you from concluding.

For a pipeline with stochastic training, run the reference configuration with at least three recorded random seeds, keeping the data split and other settings fixed. The original reference run may count as one of the three. Report every run and summarize the mean and range of the selected metrics. Explain whether the variation changes the security conclusion.

If your pipeline is deterministic or your experiment uses supplied pretrained weights, evaluate the same fixed detector on three predeclared, nonoverlapping test subsets or time windows. Keep the decision rule fixed and report the class counts and metrics for each subset. Explain that these differences measure sensitivity to the evaluation data, rather than variability from training. This adaptation is required when seed variation would not change the computation.

Complete worksheet E6 for all four investigations. Report the hypothesis, changed factor, what was held fixed, run IDs, paired or repeated results, an interpretation, an alternative explanation, and one further experiment that could distinguish the explanations. The proposed further experiment is a discussion question; you do not need to run it.

You may reuse the same trained reference model, predictions, and logs when the comparison permits it. Document what was reused and what required a new run. A supplied pretrained model can support an inference comparison; it does not establish that you reproduced training. State what you actually ran.