UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 8.7 Free with a free account
Intrusion Detection Systems
Ethics in Technology · Chapter 8: Guarding the Data Vault: Database Protection, Cloud Risks, and Intrusion DetectionSection 8.7 · lesson 41 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: How Criminals Target Databases: Common Attack Methods and How to Defend Against Them →← Risks of Moving Data to the CloudNext lesson: How Criminals Target Databases: Common Attack Methods and How to Defend Against Them →
In this lesson
Observing attacks, understanding errors, correlating evidence, and responding responsibly.
- Compare network and host visibility
- Distinguish signatures, anomalies, and prevention
- Calculate detection outcomes and the base-rate problem
- Explain SIEM correlation, response duties, and privacy limits
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,804 words). Read along, or search it.
Chapter 8
Intrusion Detection Systems
Intrusion detection monitors activity for signs of attacks or policy violations, then produces findings for assessment. Preventive controls remain important, but stolen access and missed weaknesses can defeat an intended boundary. We compare sensors that observe network traffic with software that observes individual computers. Placement, encryption, capacity, and coverage determine what each can actually see. Signatures recognize covered patterns, while anomaly methods look for departures from suitable baselines. Protocol analysis adds another way to evaluate observed exchanges. Prevention can automatically block traffic, adding speed and a risk of disrupting legitimate work. We classify four detection outcomes and calculate the source's illustrative base-rate problem. The Target example connects detection technology with the people and procedures that act on warnings. SIEM platforms bring related evidence together, supported by analysts and carefully bounded automation. Finally, we consider privacy and the safety tradeoffs on a hospital's patient-monitoring network.
Why Monitor?
Preventive Controls Need Evidence of What Gets Through
An intrusion detection system can be software, a dedicated device, or part of a broader platform. It monitors network or computer activity and raises alerts on signs of malicious behavior or policy violations. Firewalls and access rules constrain entry or action, while detection looks for evidence of trouble. The source's building analogy compares preventive locks with sensors and cameras. An alarm needs assessment; it is not proof of who acted or whether a compromise succeeded. Large event streams make automated filtering and prioritization useful for human investigation. The scale varies by organization, so no single daily event count defines the need. Dorothy Denning's nineteen eighty-seven intrusion-detection model was an early influential example. Monitoring can reveal activity while it happens or through later analysis. Collection delay, missing evidence, limited processing capacity, and delayed response all influence the result. Automated monitoring adds a layer of defense, without promising that every intrusion will be detected immediately.
Sensor Placement
A Traffic Copy Observes; an Inline Device Can Affect the Traffic Path
The placement diagram shows one simplified network, rather than a required design for every organization. Traffic travels through a firewall and an inline prevention point to the switch and hosts. A switch mirror sends a traffic copy to the network detection sensor. A network tap can provide another way to observe traffic at a chosen point. The detector analyzes the copy without requiring the original packets to pass through that sensor. The inline prevention device can affect traffic on the illustrated path. Host sensors separately observe individual web servers, database servers, or employee laptops. They can see relevant local activity that never crosses the monitored network point. Alternative routes, cloud architecture, capacity, and encryption all shape actual coverage. Detection and prevention capabilities may coexist in one product, with behavior determined by configuration. Before relying on a sensor, identify what reaches it and how an alert leads to action.
Network and Host Systems
Complementary Views Reduce Blind Spots Without Eliminating Them
A network detector observes packets and related behavior across the points it monitors. It may reveal movement among devices or a laptop scanning hundreds of internal addresses. Unseen routes, lost packets, and encrypted payloads limit that view. A host detector observes suitable logs, files, processes, and privilege activity on its covered computer. A protected password-file change illustrates file integrity monitoring on a database server. Host software needs deployment and maintenance; an attacker with sufficient control may impair the sensor. Encrypted network contents require appropriate authorized decryption before a network sensor can inspect them. Available timing, volume, destinations, and other metadata can still support an investigation. Snort and Suricata illustrate network detection, while Zeek supplies a broader programmable network security monitor. OSSEC and Wazuh illustrate host monitoring; endpoint detection and response adds investigation and containment capabilities. Complementary views reduce blind spots, without proving that the combined system can see or stop everything.
Signature Detection
Known Patterns Can Be Precise, but Coverage and Interpretation Still Matter
Signature detection, also called misuse detection, compares activity with stored patterns associated with known threats. A pattern might cover malware bytes or a characteristic request connected with an exploit. The source's fingerprint analogy emphasizes comparison with a previously known pattern. A suitable specific rule can recognize covered activity and provide an understandable investigation starting point. Signatures need maintenance and coverage relevant to the environment being monitored. A changed attack may evade a pattern that depends on its earlier form. A new exploit can escape when the system has no applicable pattern. That does not mean every unknown exploit is invisible to every existing broader signature. Known behavior patterns may sometimes match activity produced by a new attack. False positives remain possible, and a generic alert name may not identify the exact attack. Treat the match as evidence to assess, rather than proof of successful compromise or complete protection.
Anomaly and Protocol Detection
Unusual Behavior Is a Clue, While Protocol State Provides Another Check
Anomaly detection compares observed behavior with a suitable baseline of expected activity. An accountant usually reads dozens of records during ordinary working hours. Fifty thousand records at two in the morning would justify closer attention. A legitimate deadline job could still explain that unusual pattern. Statistical methods and machine learning can help identify departures, but unusual does not automatically mean malicious. User and entity behavior analytics applies related ideas to users, devices, or other entities. Profiles need useful context, a learning period, and ongoing maintenance as legitimate work changes. Malicious activity may resemble normal behavior or become incorporated into an unsuitable baseline. Stateful protocol analysis examines whether exchanges fit accepted protocol behavior in the current state. Allowed variations, implementation details, visibility, and processing limits affect that check too. Combining signatures, behavioral analysis, and protocol evidence can improve coverage, while retaining the need for tuning and judgment.
Detection versus Prevention
Blocking Adds Speed, Along with a Risk of Interrupting Legitimate Work
The illustrated network distinction compares observation in detection mode with an inline prevention point. An intrusion prevention system can block selected traffic, drop a connection, or otherwise enforce a configured response. That speed can reduce harm before an analyst completes an investigation. A mistaken decision can also block a legitimate order or important clinical communication. An out-of-band detector may lose visibility when it fails, while the original traffic continues. An inline device needs a planned failure behavior and continuity arrangement. Fail open preserves flow while losing that enforcement; fail closed can interrupt flow while preserving the barrier. Neither choice is automatically appropriate for every hospital network or every security boundary. Detection-only trials help assess a rule before permitting automatic blocking. NIST uses detection and prevention together as a technology category, and host or integrated products can also respond. Evaluate configured behavior, response ownership, testing, and safe recovery instead of relying on the product label alone.
Four Detection Outcomes
Classify the Alert Against the Actual Activity
Classify each decision against the actual activity, rather than treating every warning as an attack. A true positive flags actual harmful activity within the definition being evaluated. A false positive flags activity that is actually harmless, such as an authorized administrator's scan. A false negative misses harmful activity, allowing an attack to continue unnoticed by that detector. A true negative leaves harmless activity unflagged. Missed attacks can be serious, depending on impact and the other controls available. False alerts consume investigation time, and automatic responses can cause additional disruption. Alert fatigue occurs when excessive or poorly prioritized warnings overwhelm attention. That overload can make a real incident easier to overlook. Tuning changes suitable rules, thresholds, context, and routing, while measuring both misses and false alerts. The most harmful error depends on the environment and response, rather than one universal ordering for every system.
Worked Base-rate Example
Rare Attacks Can Produce Mostly False Alerts Even with High Detection
The source's illustrative day contains one million events, including one hundred attacks. That leaves nine hundred ninety-nine thousand nine hundred harmless events. The detector identifies ninety-nine percent of attacks and wrongly flags one percent of harmless activity. It correctly flags ninety-nine attacks and misses one attack. One percent of the harmless events produces nine thousand nine hundred ninety-nine false alerts. The harmless events left unflagged total nine hundred eighty-nine thousand nine hundred one. All alerts therefore total ten thousand ninety-eight, which the source rounds to about ten thousand one hundred. Only ninety-nine of those alerts are attacks, giving precision of approximately zero point nine eight percent. The attack-detection rate is not the percentage of alerts that are attacks. Rare harmful activity can produce mostly false alerts, even with apparently impressive detection and false-alert rates. Improve useful evidence, context, prioritization, and response capacity; simply discarding noise can also increase missed attacks.
Target, 2013
Useful Detection Needs an Owner Who Can Evaluate and Act
In late twenty thirteen, attackers stole data from about forty million payment cards at Target. The following year's Senate staff analysis discussed reported warnings and possible missed interruption opportunities. The account included malware alerts that could have supported a response before more data left. The analysis relied on available reports and did not resolve every detail of the incident. It discussed the possibility of frequent alarms influencing interpretation, rather than proving alert fatigue as the definitive cause. The transferable lesson is that useful findings need someone with authority and capacity to act. Prioritize credible high-impact findings and route them to trained responders. Investigate supporting evidence, affected systems, and plausible benign explanations. Use defined incident procedures, escalate uncertainty, and track findings that remain unresolved. Review response timing, noise, detection gaps, and activity missed by the system. An installed detector is only part of the control. Unread warnings cannot produce a practical response.
SIEM and Correlation
Related Evidence Can Become a More Meaningful Incident
A security information and event management platform collects related evidence from supported sources. These may include detection tools, firewalls, hosts, databases, cloud services, and identity systems. Normalization makes relevant fields and formats comparable, while correlation links events using rules and context. Alerting and dashboards prioritize findings, with retention and reporting supporting investigations and applicable duties. Consider five failed manager logins, a successful login from an unexpected location, and a large customer-data download. If they occur within ten minutes, the combination justifies a stronger account-takeover investigation. It still does not prove theft, or establish that a location indicator correctly identifies the human actor. A security operations center can evaluate findings and coordinate response, according to its staffing arrangements. Security orchestration, automation, and response tools can automate selected actions. Account restriction or endpoint isolation needs appropriate safeguards, approval boundaries, recovery, and review. Correlation and automation help connect evidence to action, while preserving judgment about consequences and uncertainty.
Privacy and Hospital Review
Monitoring Should Protect People While Respecting Its Own Boundaries
Monitoring observes activity that may belong to employees and customers, creating privacy duties of its own. Explain relevant monitoring and its purpose through suitable notice. Collect what the security purpose and applicable duties justify, restrict access, and protect the monitoring records. Set justified retention rather than keeping every detail indefinitely or deleting evidence needed for a valid duty. For encrypted data theft, combine suitable network metadata with relevant host or endpoint evidence. For a new threat, consider applicable patterns, behavior, and protocol evidence, without promising any method detects it. For patient monitoring, weigh blocking risk, missed attacks, device failure, bypass, redundancy, and response time. Test the arrangement and plan safe recovery for the actual clinical environment. Large alert volume calls for base-rate understanding, measured tuning, prioritization, and staffed investigation. SIEM correlation connects related findings that may look less meaningful when examined separately. Detection becomes useful through proportionate evidence and timely response, while avoiding excessive surveillance and unjustified conclusions about people.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Intrusion Detection Systems
What is the difference between a network-based and a host-based intrusion detection system?
What is the difference between signature-based and anomaly-based intrusion detection?
What is the difference between an IDS and an IPS?
Why do intrusion detection systems generate so many false alarms?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →