Detection objective
A fictional statement describing the defensive condition the detection should identify and the decision it should support.
High School IntermediateModule I15Lesson 4 of 8
I15.4 Detection Engineering and Tuning Basics
Learn how defenders create fictional detection objectives, map approved data, write explainable logic, test expected and harmful conditions, tune safely, monitor source health, control versions, measure usefulness, and review long-term quality.
Lesson Progress
Detection Engineering and Tuning Basics
High School Intermediate • I15: Security Operations Basics • Lesson 4 of 8
50% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
Reducing Noise Is Not the Same as Improving Detection
A fictional Northbridge detection repeatedly alerts during approved maintenance. The easiest change would be to suppress all activity during maintenance windows. That would reduce noise, but it could also hide actions outside the approved identity, service, task, or time boundary. Professional tuning narrows the expected context, preserves risky differences, tests missing data, stages the change, monitors results, and keeps rollback ready.
Weak detection change
Edit production logic directly, suppress broad categories, test only one positive event, ignore source health, measure only alert count, and leave no rollback or owner.
Professional detection change
Define the decision, map required data, test expected and risky behavior, peer-review, stage, monitor, tune with evidence, version, validate, and reassess.
Objective 1
Explain how fictional detection engineering connects a defensive objective, approved data, source health, logic, thresholds, expected behavior, testing, deployment, monitoring, tuning, ownership, and review.
Objective 2
Distinguish fictional detection goals, data requirements, detection logic, alert severity, triage priority, false positives, false negatives, source gaps, and control limitations.
Objective 3
Design a fictional detection specification that is testable, explainable, privacy-safe, versioned, and linked to a clear defensive decision.
Objective 4
Evaluate fictional tuning changes using approved positive tests, negative tests, boundary tests, replay tests, source-health checks, business validation, rollback, and post-deployment monitoring.
Objective 5
Create a portfolio-safe fictional detection-engineering package with a design record, data map, test plan, tuning history, deployment decision, metrics, findings, and leadership summary.
Why This Matters
Detections Shape Analyst Workload, Visibility, Escalation, and Response
Fictional detections can reveal active access, critical source gaps, unsupported configuration changes, supplier risks, or weak case closure. Poorly designed logic can overwhelm analysts or create blind spots. Strong detection engineering connects healthy data, explainable logic, repeatable testing, useful owner actions, business context, version control, and continuous review.
Core Concept
Use the Objective–Data–Logic–Test–Operate Model
Objective
Which fictional harmful or risky condition should be identified, for which service, and which defensive decision should follow?
Data
Which fictional sources, fields, timestamps, context, coverage, parsing, ownership, and health checks are required?
Logic
Which fictional sequence, threshold, entity, scope, expected behavior, exception, severity, and limitation define the signal?
Test
Which fictional positive, negative, boundary, missing-data, duplicate, replay, business, and rollback tests prove predictable behavior?
Operate
Which fictional owner, case path, monitoring, metrics, tuning, versioning, rollback, and review sustain quality after deployment?
Key Vocabulary
Detection Engineering, Testing, and Tuning Terms
Detection logic
Fictional approved conditions that evaluate selected data and produce a signal when defined criteria are met.
Data requirement
A fictional field, event, context source, timestamp, identity, asset, change, or service attribute required for dependable detection.
Threshold
A fictional value, count, duration, rate, sequence, or condition that influences whether the detection produces an alert.
Baseline
A fictional reference describing expected behavior, source volume, timing, frequency, or configuration for comparison.
Positive test
A fictional approved test that should trigger the detection when the intended condition is present.
Negative test
A fictional approved test that should not trigger the detection when normal or allowed behavior occurs.
Boundary test
A fictional approved test near a threshold or condition edge used to confirm predictable behavior.
Replay test
A fictional safe test that evaluates detection logic against approved historical or synthetic events without using live sensitive activity.
False positive
A fictional alert that matched the logic but did not represent the harmful condition the detection was intended to identify.
False negative
A fictional harmful test condition that the detection failed to identify.
Tuning
A fictional controlled adjustment to logic, thresholds, context, allow conditions, severity, or data requirements to improve usefulness.
Suppression
A fictional approved rule that prevents selected alerts from being created under narrow, documented, and tested conditions.
Detection drift
A fictional decline in detection quality caused by changes in systems, data, behavior, parsing, identity, services, or business processes.
Version control
A fictional record of detection changes, authors, approvals, test results, deployment dates, rollback, and current version.
Detection coverage
The fictional portion of relevant assets, identities, services, events, data, or scenarios included by the detection and its supporting sources.
Detection Design
Eight Questions before Writing Fictional Detection Logic
What defensive decision should the detection support?
Strong design
The fictional objective identifies the condition, protected service or asset, likely decision, owner, and required response time.
Weak design
The detection exists only because a tool can search for the event.
Reviewer question
What changes when this detection fires?
Which exact behavior should be identified?
Strong design
The fictional design defines the event pattern, sequence, identity, asset, action, time window, context, and exclusions.
Weak design
The logic searches for anything unusual without a testable definition.
Reviewer question
Can the intended condition be reproduced safely?
Which data is required?
Strong design
The fictional design maps required fields, sources, timestamps, parsing, enrichment, ownership, expected volume, and source-health monitoring.
Weak design
The rule assumes every needed field always exists.
Reviewer question
What happens when a required source is delayed or missing?
Which allowed behavior may look similar?
Strong design
The fictional design documents maintenance, exercises, service identities, scheduled jobs, approved tools, suppliers, and business exceptions.
Weak design
Normal activity is discovered only after analysts receive repeated alerts.
Reviewer question
Which expected behaviors require context rather than broad suppression?
How will the detection be tested?
Strong design
The fictional plan includes positive, negative, boundary, replay, missing-data, timing, duplication, and business-validation tests.
Weak design
The detection is deployed after one successful trigger.
Reviewer question
Which tests could reveal a false negative or harmful suppression?
Who owns the detection lifecycle?
Strong design
The fictional detection engineer, data owner, service owner, SOC reviewer, approver, responder, and rollback authority are identified.
Weak design
No one owns source changes, tuning, review, or retirement.
Reviewer question
Who maintains quality after deployment?
How will performance be measured?
Strong design
The fictional design tracks alert volume, source health, triage outcomes, false positives, false negatives from tests, coverage, aging, and tuning effect.
Weak design
Success is measured only by the number of alerts.
Reviewer question
Does the metric show useful defensive decisions or just activity?
How will the detection change safely?
Strong design
The fictional process requires versioning, peer review, approval, staged deployment, monitoring, rollback, documentation, and later reassessment.
Weak design
An analyst edits production logic directly during a noisy shift.
Reviewer question
Can the prior version be restored and compared?
Detection Catalog
Northbridge Fictional Detection Records
NBR-DET-01
Access after supplier exception expiration
Ready for staged testingIdentity Detection EngineerObjective
Identify fictional supplier identities that remain active or perform access after approved exception expiration.
Data requirements
Identity lifecycle, exception register, authentication, service access, sponsor, project status, and source health.
Logic concept
Alert when an in-scope supplier identity is active after expiration or accesses the protected service after the allowed end time.
Expected behavior
A documented narrow renewal should be enriched and reviewed rather than automatically suppressed.
Design risk
Broad supplier exclusions could hide stale access.
NBR-DET-02
Maintenance access outside approved scope
Needs boundary testsService Detection EngineerObjective
Identify fictional maintenance identities performing actions outside the approved service, task, or change window.
Data requirements
Change record, maintenance identity, service scope, action type, timestamps, approval, asset, and activity evidence.
Logic concept
Alert only when activity exceeds approved service, action, identity, or time boundaries.
Expected behavior
Approved maintenance within exact scope should not create a high-priority alert.
Design risk
A broad maintenance allowlist could hide misuse during an approved window.
NBR-DET-03
Critical audit-source delivery gap
Deployed with reviewTelemetry Detection EngineerObjective
Identify fictional loss of required security evidence for critical services.
Data requirements
Expected delivery interval, last event time, parser state, source owner, service criticality, maintenance, and alternate evidence.
Logic concept
Alert when required source delivery exceeds the approved delay threshold and no planned maintenance explains the gap.
Expected behavior
Short approved connector maintenance should create a low-priority operational notice rather than a high-priority alert.
Design risk
A long threshold may create dangerous monitoring blind spots.
NBR-DET-04
Unapproved confidential storage-policy change
Ready for staged deploymentCloud Detection EngineerObjective
Identify fictional access-policy changes affecting confidential storage outside approved change controls.
Data requirements
Configuration history, effective policy, identity, approval, asset classification, change window, service owner, and source health.
Logic concept
Alert when an in-scope confidential policy changes without a matching approved change or emergency authorization.
Expected behavior
Approved changes should remain visible in low-noise audit reporting.
Design risk
Relying only on change-ticket text may miss incorrect effective permissions.
NBR-DET-05
Privileged exercise sign-in
Needs negative testsIdentity Detection EngineerObjective
Distinguish fictional approved emergency exercise access from unsupported privileged access.
Data requirements
Exercise plan, emergency network, privileged identity, session activity, approval, time window, service, and owner validation.
Logic concept
Enrich exercise-matching activity and alert when identity, network, time, action, or target exceeds the approved exercise scope.
Expected behavior
Exact approved exercise behavior should produce a reviewable informational record.
Design risk
Suppressing all emergency-network sign-ins could hide unrelated activity.
NBR-DET-06
Repeated user lockout anomaly
Tuning review openIdentity OperationsObjective
Identify fictional lockout patterns that exceed supported user-error behavior and may require identity investigation.
Data requirements
Lockout count, sign-in source, identity type, help-desk record, password reset, timing, asset, and prior behavior.
Logic concept
Escalate when repeated lockouts cross the threshold without a matching support event or when scope expands across identities.
Expected behavior
A documented single-user password-reset problem should remain low priority.
Design risk
A fixed threshold may perform poorly during large password-reset events.
NBR-DET-07
Case closure with unresolved evidence
Design reviewSOC Quality EngineerObjective
Identify fictional SOC cases marked ready for closure while required evidence, validation, owner decisions, or follow-up remain incomplete.
Data requirements
Case status, evidence checklist, source-health issues, action log, approvals, validation, residual risk, and peer review.
Logic concept
Alert when Ready for Review or Closed conflicts with incomplete required fields.
Expected behavior
Low-risk duplicate cases may use an approved simplified closure path.
Design risk
Overly rigid logic could block proportionate closure.
NBR-DET-08
Supplier notification service degradation
PilotSupplier Monitoring EngineerObjective
Identify fictional time-sensitive supplier delivery degradation that threatens important user communication.
Data requirements
Supplier status, internal delivery rate, notification deadline, alternate channel, service owner, contract threshold, and recovery state.
Logic concept
Alert when delivery falls below the approved service threshold during a critical notification window.
Expected behavior
Minor delay outside important windows should remain operational reporting.
Design risk
The rule must not imply malicious cause when only service degradation is supported.
Test Strategy
Eight Fictional Detection Test Types
Positive test
Purpose
Confirm the fictional detection triggers for the exact intended defensive condition.
Fictional example
Synthetic supplier access occurs after exception expiration on the protected service.
Success condition
Expected alert, entities, timestamps, evidence fields, severity, owner, and case path appear.
Failure signal
No alert, missing context, wrong entity, or delayed signal.
Negative test
Purpose
Confirm the fictional detection does not produce an unnecessary alert for approved normal behavior.
Fictional example
Approved maintenance activity remains within exact identity, service, action, and time boundaries.
Success condition
No high-priority alert; expected audit record or enrichment remains available.
Failure signal
Normal behavior creates repeated analyst workload.
Boundary test
Purpose
Confirm fictional behavior just below, at, and above thresholds or time limits is predictable.
Fictional example
Audit-source delay is tested immediately before, at, and after the approved threshold.
Success condition
The rule changes state exactly as documented.
Failure signal
Off-by-one timing, duplicate alerts, or unstable severity appears.
Missing-data test
Purpose
Confirm the fictional detection behaves safely when required fields or sources are absent.
Fictional example
The change-approval field is missing while configuration evidence remains healthy.
Success condition
The alert records reduced confidence or source-health risk instead of making an unsupported conclusion.
Failure signal
The rule silently treats missing data as approved or malicious.
Duplicate test
Purpose
Confirm repeated fictional events are grouped, linked, or rate-limited without losing meaningful scope.
Fictional example
The same source-gap condition reports every minute for forty minutes.
Success condition
One coherent alert or case preserves duration and updates.
Failure signal
The queue receives forty unrelated alerts or loses the continuing condition.
Replay test
Purpose
Evaluate fictional logic against approved historical or synthetic event sequences.
Fictional example
Prior approved maintenance events and synthetic out-of-scope events are replayed together.
Success condition
Expected behavior is separated from test violations.
Failure signal
The rule suppresses both or alerts on both without distinction.
Business validation test
Purpose
Confirm the fictional alert and response fit the service owner’s real operational decision.
Fictional example
The service owner reviews whether the alert identifies activity that requires intervention.
Success condition
The alert supports a clear owner action without unnecessary disruption.
Failure signal
The detection is technically correct but operationally unusable.
Rollback and recovery test
Purpose
Confirm the fictional detection can return to the approved prior version if quality or source issues appear.
Fictional example
A staged tuning change causes unexpected alert volume and is rolled back.
Success condition
Prior logic, documentation, source monitoring, and alert behavior are restored.
Failure signal
The team cannot identify or restore the prior version.
Tuning Register
Six Fictional Tuning Decisions
TUNE-01
Fictional maintenance alerts repeatedly trigger on exact approved activity.
Proposed change
Enrich with change identity, service, action, and time boundaries; lower priority only when all approved fields match.
Expected benefit
Reduces analyst noise while preserving out-of-scope detection.
False-negative or quality risk
Incomplete change records could create incorrect low-priority classification.
Required tests
Positive out-of-scope, negative exact-scope, missing-change-field, boundary-time, and replay tests.
Decision
Approve staged pilot with source-health warning and rollback.
TUNE-02
Fictional audit-source gap alerts arrive every minute.
Proposed change
Group updates into one active alert while preserving start time, duration, service scope, and recovery.
Expected benefit
Reduces duplicates and preserves the complete blind-spot timeline.
False-negative or quality risk
Grouping could hide expansion to new sources or services.
Required tests
Duplicate, scope-expansion, recovery, threshold, and case-link tests.
Decision
Approve after scope-expansion behavior passes.
TUNE-03
Fictional lockout detection creates noise during approved password-reset campaigns.
Proposed change
Add approved campaign context while retaining escalation for privileged identities, unusual sources, or expanding scope.
Expected benefit
Improves queue usefulness during known support events.
False-negative or quality risk
Overbroad campaign context could hide unrelated lockouts.
Required tests
Exact-campaign negative, unrelated-user positive, privileged-user positive, time-boundary, and missing-context tests.
Decision
Pilot with narrow scope and daily quality review.
TUNE-04
Fictional supplier expiration detection misses accounts whose exception record is absent.
Proposed change
Use project end and sponsor status as additional context and raise missing-governance-data alerts.
Expected benefit
Improves coverage when the exception register is incomplete.
False-negative or quality risk
Project records may not represent current approved support needs.
Required tests
Expired exception, missing exception, renewed support, missing sponsor, and source-conflict tests.
Decision
Approve only with owner review before access action.
TUNE-05
Fictional storage-policy detection checks change tickets but not effective permissions.
Proposed change
Add effective-policy comparison and asset classification context.
Expected benefit
Improves detection of actual access-control impact.
False-negative or quality risk
Permission calculation delay may create stale results.
Required tests
Approved no-impact change, unapproved expansion, delayed-effective-state, rollback, and source-health tests.
Decision
Stage after timing and parser validation.
TUNE-06
Fictional case-quality detection blocks simplified duplicate closure.
Proposed change
Add an approved low-risk duplicate closure path with mandatory linkage and no-new-scope validation.
Expected benefit
Preserves proportional workflow without weakening case traceability.
False-negative or quality risk
Analysts may misuse the simplified path.
Required tests
True duplicate, new-scope, missing-link, historical-case, and reviewer-approval tests.
Decision
Approve with monthly quality sampling.
Detection Workflow
Eight Steps from Objective to Detection Assurance
Define the defensive objective
State the fictional condition, protected asset or service, expected decision, priority concept, owner, time requirement, and evidence boundary.
Output: Detection charter.
Map data and source health
Document fictional sources, fields, timestamps, enrichment, ownership, coverage, parsing, delivery, expected volume, and failure behavior.
Output: Data requirement map.
Describe logic and context
Define fictional events, sequence, thresholds, time window, entities, scope, expected behavior, exceptions, and evidence limitations.
Output: Detection specification.
Build the test plan
Create fictional positive, negative, boundary, missing-data, duplicate, replay, business-validation, and rollback tests.
Output: Approved test matrix.
Peer-review and approve
Review fictional privacy, safety, source assumptions, logic, false-positive and false-negative risk, owner actions, severity, and rollback.
Output: Review and approval record.
Stage and monitor
Deploy the fictional detection to a limited scope, monitor alerts, source health, case outcomes, service effects, and unexpected behavior.
Output: Pilot monitoring record.
Tune with evidence
Adjust fictional logic, context, thresholds, grouping, severity, or workflow only after documented findings and repeatable testing.
Output: Tuning and version history.
Validate and review
Confirm fictional defensive usefulness, coverage, case quality, business value, residual gaps, owner signoff, metrics, and reassessment triggers.
Output: Detection assurance package.
Fake Dashboard
Fake Northbridge Detection Engineering Dashboard
Training dashboard for fictional detection quality only.
Detections under review
8
Design, pilot, tuning, staged deployment, and source-health review states are represented.
Open tuning changes
6
Each change includes expected benefit, quality risk, tests, decision, and rollback requirements.
Confirmed incidents
0
The fictional records support detection and control improvements but do not confirm an incident.
Fake SOC Alert
Maintenance Detection Produces Repeated High-Severity Alerts
Source: Fake Northbridge Detection Quality Console • Time: 9:06 PM
A fictional detection alerts whenever maintenance identities access the confidential support service, including activity that remains within approved identity, service, action, and time boundaries.
Defensive recommendation: Do not broadly suppress maintenance activity. Add exact approved context, preserve out-of-scope triggers, test positive, negative, boundary, missing-data, and replay conditions, stage the change, monitor case outcomes, and keep rollback ready.
Fake Log Panel
Fake Northbridge Detection Change Timeline
training-log-viewer.log
08:00 OBJECTIVE maintenance-scope='defined' 08:08 DATA change-record='healthy' 08:16 DATA service-activity='healthy' 08:24 FINDING repeated-alerts='approved exact scope' 08:32 RISK broad-suppression='could hide out-of-scope' 08:40 DESIGN context='identity+service+action+time' 08:48 TEST positive-out-of-scope='pass' 08:56 TEST negative-exact-scope='pass' 09:04 TEST missing-change-field='warning generated' 09:12 TEST boundary-time='pass' 09:20 TEST replay='pass' 09:28 REVIEW peer='approved pilot' 09:36 DEPLOY scope='limited' 09:44 MONITOR alert-volume='reduced' 09:52 MONITOR missed-test-events='0' 10:00 VERSION v='2.1' rollback='ready'
Training note: this is fake data for defensive analysis practice only.
Findings Matrix
Northbridge Detection Findings and Limits
NBR-DET-F01High
The fictional maintenance detection should use exact approved context rather than a broad maintenance suppression.
Evidence support
Repeated exact-scope alerts, approved change fields, risk of out-of-scope activity, available identity and action context, and staged test plan.
Alternative
A simpler threshold change may reduce enough noise without complex enrichment.
Limitation
Detection quality depends on current and complete change records.
NBR-DET-F02High
The fictional source-gap detection should preserve one active case while recording duration and scope expansion.
Evidence support
Repeated duplicate alerts, confirmed source gap, stable service scope, need for a coherent timeline, and available grouping logic.
Alternative
Separate alerts may be useful when different source owners or services are affected.
Limitation
Grouping must not hide new sources or broader impact.
NBR-DET-F03Medium-High
The fictional supplier-expiration detection requires owner review before automatic access removal.
Evidence support
Expired exception risk, possible undocumented support need, incomplete activity review, current access, service dependency, and governance owner.
Alternative
A clearly unauthorized inactive account may qualify for automated disablement under an approved runbook.
Limitation
Current business need may be incompletely documented.
NBR-DET-F04High
The fictional storage-policy detection should compare effective permissions rather than ticket presence alone.
Evidence support
Confidential data, configuration history, approved baseline, possible permission expansion, and delayed effective-state risk.
Alternative
Change-ticket mismatch may still be useful as a separate governance alert.
Limitation
Permission evaluation must be timely and correctly parsed.
NBR-DET-F05Medium-High
The fictional lockout detection should use narrow campaign context but retain privileged and scope-expansion triggers.
Evidence support
Repeated support-related noise, approved campaign, user-error records, privileged identity risk, and expansion scenarios.
Alternative
Analyst enrichment may be sufficient without changing the rule.
Limitation
Campaign records may be delayed or incomplete.
NBR-DET-F06High
A fictional detection should not be considered effective merely because it generates alerts.
Evidence support
Need for source health, positive and negative tests, case outcomes, false-positive review, false-negative tests, owner actions, and business validation.
Alternative
Alert generation may be an acceptable early pilot milestone.
Limitation
Long-term effectiveness requires enough operational data and review time.
Analyze the Evidence
Should Northbridge Suppress All Maintenance Alerts?
The fictional detection repeatedly alerts on exact approved maintenance activity.
The current rule does not use service, action, identity, and time boundaries together.
Maintenance windows could also contain out-of-scope activity.
Change records and service activity sources are healthy.
Approved positive, negative, boundary, missing-data, and replay tests are available.
No supplied evidence supports removing the detection entirely.
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Detection Engineering and Tuning
Creating fictional detections because data is available instead of because a defensive decision requires them.
Writing broad unusual-activity logic that cannot be tested or explained.
Treating one successful positive test as proof of detection effectiveness.
Skipping negative, boundary, missing-data, duplicate, replay, business-validation, or rollback tests.
Using broad allowlists or suppressions that can hide out-of-scope activity.
Tuning only to reduce alert volume without checking false-negative risk.
Changing production logic without version control, peer review, approval, staging, monitoring, and rollback.
Assuming required fields, parsing, timestamps, identity context, asset context, and change records are always healthy.
Using alert count as the only measure of detection quality.
Treating a false positive as proof that the detection has no value.
Treating a true positive test as proof that every real alert represents an incident.
Failing to connect the detection to a case owner, service owner, control owner, decision path, and response deadline.
Keeping a fictional detection after its service, data, threat model, or business decision has changed.
Using or exposing any real company detection logic, credentials, private logs, employee information, school records, supplier details, incident evidence, or confidential SOC information.
Safe Practice Lab
Build the Northbridge Detection Engineering and Tuning Package
Your fictional assignment
Objective, Data, Logic, Tests, Deployment, Tuning, and Assurance
Use only the supplied fictional Northbridge records to design, test, stage, tune, and review one defensive detection.
Required deliverables
- Detection charter with objective, scope, decision, owner, service, privacy, and response time.
- Data map with sources, fields, timestamps, enrichment, parsing, coverage, ownership, and source-health behavior.
- Logic specification with events, entities, thresholds, sequence, expected behavior, exclusions, severity, and limitations.
- Positive, negative, boundary, missing-data, duplicate, replay, business-validation, and rollback test matrix.
- Peer-review, approval, staged-deployment, monitoring, and rollback plan.
- Tuning record with problem, evidence, expected benefit, false-negative risk, tests, version, and decision.
- Quality metrics covering source health, coverage, alert outcomes, noise, tests, case value, and drift.
- Technical summary, leadership summary, reflection, and portfolio-safety statement.
Complete the lab only with fictional evidence displayed on this page. Do not use real detection logic, credentials, company logs, employee information, school records, supplier data, incidents, or confidential SOC information.
Scenario Decision Lab
The SOC Manager Wants to Suppress Every Alert during Maintenance
The fictional alerts are noisy, but the current rule cannot distinguish exact approved scope from out-of-scope activity.
Scenario Decision Lab
A Tuning Pilot Cuts Alert Volume by Eighty Percent
The fictional pilot produces far fewer alerts, but the team has not completed positive replay tests or reviewed missed-event risk.
Defender Habits
Detection Engineering and Tuning Checklist
Check Your Understanding
I15.4 Mini Quiz: Detection Engineering and Tuning Basics
Choose your answers first. Explanations appear only after submission.
1. What should come first in fictional detection engineering?
2. Why are fictional negative tests important?
3. What is the safest way to tune repeated fictional maintenance alerts?
4. What should happen when a required fictional data source is delayed?
5. What is detection drift?
6. What makes a fictional tuning change defensible?
7. What proves a fictional detection is effective?
Portfolio Prompt
Portfolio Prompt
Create a fictional Detection Engineering and Tuning Package for Northbridge. Include the detection charter, data requirement map, source-health plan, logic specification, expected-behavior map, test matrix, peer review, deployment plan, monitoring, tuning history, version control, rollback, quality metrics, findings, leadership summary, reflection, and a portfolio-safety statement.
Use only fictional detections, systems, identities, suppliers, services, sources, tests, alerts, cases, versions, actions, and outcomes.
Do not treat low alert volume, one successful trigger, repeated expected activity, or a false positive as automatic proof of quality or failure.
Make every tuning decision traceable to evidence, expected benefit, false-negative risk, tests, approval, monitoring, and rollback.
Show why narrow context is safer than broad suppression.
Key Takeaways
What You Should Remember
1.Detection engineering begins with a defensive objective and decision, not with available data alone.
2.Source health, context, logic, testing, case value, and owner action determine detection usefulness.
3.Positive tests are not enough; negative, boundary, missing-data, duplicate, replay, business, and rollback tests matter.
4.Tuning should reduce unnecessary noise without creating hidden false negatives.
5.Broad suppressions are riskier than narrow, tested, explainable context.
6.Every change should be reviewed, staged, monitored, versioned, reversible, and reassessed.
7.Portfolio artifacts should use fully fictional evidence and never expose real organizational detection logic.
Navigation