A Cybersecurity Graduation Project in Cairo: Evaluate Alert Rules

1. Agree on one research question

For an illustrative student team in Cairo, the question is: does adding a failure-rate condition reduce unnecessary alerts while missing more cases marked for review? The output is an experiment and a reproducible report. It does not require a live network, customer records or attacks.

Each row represents one invented ten-minute login window. Store an ID, failed attempts F, total attempts T, and a reference label: 1 = requires review in the fictional scenario; 0 = routine. T includes successful and failed attempts. These are application-event summaries, not packet captures.

If you are still choosing a broader topic, use the graduation-project selection guide. Here, keep the scope to evaluating these two rules.

2. Write the rules and label policy before testing

1. Rule A: alert when F is at least 5.
2. Rule B: alert when F is at least 5 and F/T is at least 0.5.
3. Input contract: F and T are integers, T is positive, and 0 ≤ F ≤ T. Invalid rows receive a validation message and stay outside the scored set.

Write scenario labels independently of these thresholds. For example, a planned login-form check can produce many failures but remain routine; an account activity report can require review despite few failures. Keep the fictional reason in a separate answer sheet. Do not feed labels, reasons or row IDs into either rule.

The numbers and labels below are authored teaching data. They establish no real malicious activity, and these thresholds are not operating recommendations.

3. Separate development from evaluation

Use D1–D4 to check your calculations. Freeze the two rules, field definitions and output format before processing T1–T8. These are fixed rules, so no machine-learning training is required.

On narrow screens, scroll the table horizontally to see all columns.

This published example reveals both batches so anyone can reproduce the arithmetic. It is not an unseen final test for your graduation report. For your own experiment, appoint a teammate to retain a separate evaluation batch until the implementation is frozen. If you adjust thresholds, use development or validation data; create a fresh untouched final set after using old test results to guide changes. Google’s dataset-splitting guidance explains this separation.

4. Verify the confusion matrix by hand

On T1–T8, A alerts on T1, T2, T3, T5, T6 and T7. B alerts only on T1, T2 and T7. T4 is missed by both.

TP means an alert on a label-1 row; FP means an alert on a label-0 row. FN is a missed label-1 row; TN is a label-0 row without an alert. Together these four counts form the confusion matrix.

On narrow screens, scroll the table horizontally to see all columns.

Precision = TP/(TP+FP); recall = TP/(TP+FN). Check that each row’s four counts total eight. These follow the standard classification definitions. When a denominator is zero, report the metric as undefined and explain why.

B creates two fewer false alerts but misses one additional review case. Neither rule is simply “better”: the decision depends on the cost of unnecessary review and missed cases. Eight invented rows cannot estimate real deployment performance.

5. Keep a run record another teammate can reproduce

Before a Cairo team meeting or remote handover, complete this worksheet rather than sending only a screenshot:

• Research question; label policy; dataset version and row count.
• Development, validation and evaluation membership; scenario-family grouping.
• Rule version; exact thresholds; handling of invalid rows.
• For each row: reference label, A output, B output and outcome category.
• Four counts per rule; metric calculations; limitations; reviewer and review date.

One teammate prepares fictional scenarios, another implements the rules, and a third checks the arithmetic. If the team is smaller, separate these roles into documented stages. A second person should recreate the results from the same files without asking which spreadsheet column was used.

6. Develop a larger, defensible student experiment

1. Add independently authored scenario families: busy routine windows, planned retry tests, low-count review cases and changing total activity. Keep related variants in the same split to avoid near-duplicate leakage.
2. Document why each label was assigned before running a rule. Resolve ambiguous cases explicitly; do not change a label to improve a score.
3. Test boundary inputs separately: F=5, F/T=0.5, F=0, T=0 and F>T. Invalid input tests verify validation, not detection quality.
4. Compare alert volume and error types across scenario groups. Report counts alongside percentages and retain both successful and failed cases.
5. Freeze a release, run the untouched evaluation once, and ask a teammate to reproduce it. Later improvements require a separately identified experiment.

If coding foundations are the obstacle, the Gammal Tech programming course roadmap can help you choose prerequisite study. Programming courses support implementation; they do not by themselves establish cybersecurity competence.

7. Present the evidence and its limits

Show the question, data contract, frozen rules, per-row predictions, confusion matrix and two contrasting mistakes. Explain that invented labels, tiny samples and missing context prevent claims about real intrusion detection. Adding a polished dashboard does not remove those limits.

Your deliverable can be a local program or spreadsheet with a report. A separate Gammal Tech API portfolio exercise teaches hosted integration; it is optional background, not a required backend for this experiment. Agree the academic deliverables with your supervisor rather than assuming a universal Cairo university requirement.

Questions before you start

Does the project need real login attempts?

No. Enter invented counts in a file. Do not generate failed attempts against a website or obtain private logs for this exercise.

Can we call this an AI intrusion detector?

These are deterministic rules evaluated on synthetic application events. Describe them accurately; neither AI nor real-world attack detection has been demonstrated.

What if both rules perform poorly?

Keep the result. Explain which missing information or scenario assumptions contributed. A reproducible limitation is more useful than changing the test set until the percentages look impressive.