Detective and preventive measures and insider risk governance

Security operations relies on a set of technical safeguards that either stop unwanted activity before it succeeds (preventive measures) or reveal it so people can respond (detective measures). The CISSP outline, in sub-domain 7.7 (operate and maintain detective and preventive measures), lists firewalls, intrusion detection and prevention systems, allow lists and deny lists, third-party provided security services, sandboxing, honeypots and honeynets, anti-malware, and machine learning and artificial intelligence based tools. A security manager does not need to configure these products, but does need to know what each is good for, what it cannot do, how to measure whether it is working and what governance it needs.

The second half of this lesson addresses insider risk: the possibility that people with legitimate access, whether employees, contractors or partners, will misuse it, deliberately or by accident. Insider risk programs combine the personnel controls from Lesson 1, the monitoring from Lesson 3 and the investigation principles from Lesson 2, under governance that protects both the organization and the privacy and dignity of its people.

Choosing measures by purpose

Controls are often classified by function: preventive controls stop an event; detective controls identify it; corrective controls limit damage and restore; deterrent controls discourage; recovery controls restore operations; and compensating controls substitute when a primary control is not feasible. A sound design layers these so that a failure of one is caught by another. For example, a firewall rule prevents most unwanted connections, an intrusion detection system notices suspicious traffic that the rule allowed, endpoint detection notices unusual behavior on the host, and backups allow recovery if all of those fail.

Firewalls, IDS and IPS from a management view

Firewalls enforce the network segmentation that architecture (CISSP-114) designed. Operationally, the biggest risk is rule decay: rules added for projects, vendors or emergencies that are never removed, until the firewall permits far more than intended. Good practice requires every rule to have an owner, a business justification and a review date, with periodic recertification in which owners confirm rules are still needed. Unused rules, identified through hit counts, are removed through change control.

IDS and IPS illustrate the trade-off between detection and prevention. An IDS watches and alerts, so a false positive costs analyst time. An IPS sits inline and blocks, so a false positive interrupts business; a false negative lets an attack through either way. Organizations often run new IPS signatures in detect-only mode first, measure their false positive rate, and switch to blocking only for signatures that are precise enough. That decision is a business risk decision: the cost of occasionally blocking legitimate traffic against the cost of letting malicious traffic through.

# Decide which IPS signatures to switch from detect-only to block mode (synthetic 30-day trial)
signatures = [
    ('SIG-1001 exploit attempt on VPN portal', 412, 3, 'high'),
    ('SIG-1002 suspicious user agent', 9800, 7350, 'low'),
    ('SIG-1003 known ransomware callback domain', 57, 0, 'high'),
    ('SIG-1004 large outbound transfer pattern', 230, 140, 'medium'),
    ('SIG-1005 SQL injection pattern on web store', 1290, 26, 'high'),
]
for name, hits, false_pos, sev in signatures:
    precision = (hits - false_pos) / hits
    blocked_legit_per_day = false_pos / 30
    if precision >= 0.97 and sev != 'low':
        decision = 'BLOCK'
    elif precision >= 0.35:
        decision = 'detect, tune further'
    else:
        decision = 'detect only or retire'
    print(f'{name:44s} precision {precision:6.1%}  legit blocks/day if blocking {blocked_legit_per_day:6.1f}  -> {decision}')

SIG-1001 exploit attempt on VPN portal       precision  99.3%  legit blocks/day if blocking    0.1  -> BLOCK
SIG-1002 suspicious user agent               precision  25.0%  legit blocks/day if blocking  245.0  -> detect only or retire
SIG-1003 known ransomware callback domain    precision 100.0%  legit blocks/day if blocking    0.0  -> BLOCK
SIG-1004 large outbound transfer pattern     precision  39.1%  legit blocks/day if blocking    4.7  -> detect, tune further
SIG-1005 SQL injection pattern on web store  precision  98.0%  legit blocks/day if blocking    0.9  -> BLOCK

Three signatures are precise enough to block with little business disruption, and the ransomware callback signature produced no false positives at all. The large-transfer signature is right only about four times in ten and would interrupt several legitimate transfers each day, so it remains a detective control while it is tuned. The suspicious user agent signature mostly produces noise and is a candidate for retirement, freeing analyst capacity.

Allow lists, anti-malware and sandboxing

Application allow listing, sometimes called application control, permits only approved software to run. It is one of the most effective preventive measures against unwanted code and features in the Australian Signals Directorate's Essential Eight and in CIS Critical Security Control 2. Its cost is administrative: someone must maintain the list, and there must be a fast, fair exception process so that the control does not stop legitimate work. Allow listing is easiest on fixed-function systems such as point-of-sale terminals, kiosks and industrial workstations, and hardest on developer laptops.

Anti-malware has evolved from signature matching into endpoint detection and response (EDR) platforms that combine prevention with behavioral detection and response actions such as isolating a host. Coverage is the key operational metric: a tool protects only the devices it is installed and working on. Managers should track the percentage of in-scope devices reporting in recently, and investigate gaps. Sandboxing, used in email and web gateways, opens suspicious attachments or links in an isolated environment and observes their behavior before releasing them to users. It is a detective layer whose results feed prevention.

Honeypots, honeynets and legal considerations

A honeypot is a decoy system, account, file or credential that has no legitimate use, so any interaction with it is a strong signal of unauthorized activity. A honeynet is a network of such decoys. Modern deception tools place decoy credentials and files across the real environment, generating very high-precision alerts. Their governance needs are distinctive. Legal advice should confirm that monitoring of the decoys is consistent with policy and privacy law. The distinction between enticement (making a target available to someone already intending to misbehave, which is generally lawful) and entrapment (inducing someone to commit an offense they would not otherwise have committed, which can defeat a prosecution) is a classic exam point. A honeypot must also be isolated so that it cannot be used to harm others.

Machine learning, AI-based tools and third-party services

Machine learning and AI-based tools are now embedded in most security products, from anomaly detection in user behavior analytics to assistants that summarize alerts for analysts. Their value is in spotting patterns at a scale humans cannot. Their risks include opaque decisions that analysts cannot explain to an investigator or a court, bias that causes some groups or roles to be flagged more often, drift as normal behavior changes, and over-reliance by analysts. Governance should require documented purpose and data sources, performance measurement against ground truth, human review before consequential actions such as account suspension, and periodic re-validation. Where tools use generative AI, organizations should also confirm what data is sent to the provider.

Third-party security services, such as managed detection and response, managed firewalls and outsourced SOCs, give access to scale and around-the-clock coverage. Lesson 1 discussed sourcing; here the operational points are clear service levels for detection and notification, defined authority for the provider to take containment actions, data residency and access controls, right-to-audit and reporting such as SOC 2 Type II or ISO/IEC 27001 certification, and an exit plan. Responsibility for risk remains with the organization.

Insider risk governance

Insider risk arises from people who have authorized access. Some insider incidents are malicious, such as theft of intellectual property by a departing employee, fraud or sabotage. Many more are negligent or accidental: sending a file to the wrong recipient, storing data in a personal cloud account, or falling for social engineering. Programs in both Canada and the United States, including the guidance of the CISA Insider Threat Mitigation Guide and the CERT National Insider Threat Center, emphasize that insider risk management is a multidisciplinary program, not a monitoring tool.

Privacy and employment law shape what an insider risk program can do. In Canada, PIPEDA applies to employee personal information in federally regulated workplaces, and Alberta, British Columbia and Quebec have private sector laws covering employees; the Office of the Privacy Commissioner expects monitoring to be for a legitimate purpose, proportionate and the least privacy-invasive effective option. Ontario requires employers with 25 or more employees to have a written electronic monitoring policy. In the United States there is no general federal employee privacy law for private employers, but the Electronic Communications Privacy Act, state laws such as the New York and Connecticut electronic monitoring notice requirements, and sector rules apply, along with labor relations protections for concerted activity. Unionized workplaces may need to consult on monitoring.

import random
random.seed(11)
# Insider risk triage: combine indicators, but require HR-and-legal review before any action
weights = {'resigned_recently': 2, 'bulk_download': 3, 'personal_cloud_upload': 3, 'access_outside_role': 2, 'after_hours': 1}
staff = [f'E{n:03d}' for n in range(1, 401)]
flags = {}
for s in staff:
    ind = [k for k in weights if random.random() < 0.09]
    score = sum(weights[k] for k in ind)
    if score:
        flags[s] = (score, ind)
review = {s: v for s, v in flags.items() if v[0] >= 6}
print(f'{len(staff)} staff, {len(flags)} with any indicator, {len(review)} meet review threshold')
for s, (score, ind) in sorted(review.items(), key=lambda kv: -kv[1][0]):
    print(f'  {s} score {score}: {", ".join(ind)} -> refer to case review panel (no automatic action)')

400 staff, 154 with any indicator, 2 meet review threshold
  E213 score 6: bulk_download, personal_cloud_upload -> refer to case review panel (no automatic action)
  E305 score 6: resigned_recently, bulk_download, after_hours -> refer to case review panel (no automatic action)

Note the design choices in the example: staff are identified by pseudonymous codes until a case review panel decides that identification is justified; single indicators, which are common and usually innocent, do not trigger review on their own; and no action is automatic. Most people who resign, work late or download files are doing their jobs. A program that treats them as suspects damages trust and invites legal challenge.