Lesson 5: Security Controls Practical

Security work becomes interesting when two requirements conflict.

The user wants convenience.

The organization wants control.

The application wants an exception.

The technician needs enough access to repair the system.

The device still has to be recoverable if the control causes a lockout.

A good security decision explains the tradeoff instead of pretending every control is free.

Ticket 1: server-room badge works, door stays open

Current state:

badge reader: working
camera: covers hallway
door: sometimes propped open
door-close alarm: none

The credential boundary can be bypassed after an authorized person opens the door.

A stronger design may add door-position monitoring, alarm, vestibule controls, policy, training, or human monitoring.

The badge reader is not broken.

The control set does not cover the full physical-access path.

Ticket 2: temporary administrator need

Requirement:

one approved maintenance task
15 minutes of elevated access
audit required

Compare permanent administrator membership, a shared administrator password, and controlled just-in-time or privileged access.

The strongest fit satisfies the task without leaving unnecessary standing privilege afterward.

Security is partly about reducing how long a dangerous capability exists.

Ticket 3: shared folder says Access Denied

Evidence:

server: reachable
share: reachable
user: authenticated
user group: wrong group
folder NTFS permissions: inherited correctly

Bad fix:

Everyone: Full Control.

That solves one user's access by removing the authorization boundary for many others.

Correct the identity/group relationship according to policy, then verify the intended user gains access and an unintended user remains denied.

The negative test proves the security boundary still exists.

Ticket 4: removable drive carries sensitive data

Risk:

USB storage may be lost outside the office.

A relevant control may be supported removable-drive encryption such as BitLocker To Go in the Windows scenario.

New dependencies include recovery-key management, compatible authorized endpoints, and documented recovery.

Do not write only:

Encrypt USB.

Explain how an authorized user recovers access if normal unlock fails.

Ticket 5: staff Wi-Fi needs individual identity

Requirements:

modern WPA2/WPA3-capable infrastructure
central authentication
individual user identity
no permanent shared staff passphrase as the only identity

Map the roles:

• wireless security protects the radio/access link;
• RADIUS-style AAA can centralize network access decisions;
• Kerberos may support the wider enterprise identity model;
• MFA can add independent authentication evidence.

Do not say:

RADIUS encrypts the Wi-Fi.

That confuses authentication infrastructure with wireless encryption.

Ticket 6: corporate phone is lost

Evidence:

device: corporate-owned
encryption: enabled
MDM: enrolled
backup: current
locator: available
remote wipe: available
loss: confirmed

A defensible response may include:

confirm device / user
→ lock or locate if authorized
→ review account/session risk
→ revoke credentials or tokens if required
→ wipe when policy and authority require it
→ document

Why not wipe instantly every time?

Because remote wipe is destructive and can affect recovery, evidence, or location chances.

Follow the incident policy.

Ticket 7: "Disable security because it creates tickets"

Proposal:

Disable firewall, UAC, antivirus, and screen lock because they get in the way.

Reject it by control.

Firewall

Risk reduced: unwanted network communication according to policy.

Better response: create the narrow approved rule the application needs.

UAC

Risk reduced: unnecessary administrative elevation.

Better response: correct the privilege requirement or use approved elevation.

Antivirus

Risk reduced: malicious or unwanted software according to detection capability.

Better response: investigate a false positive or exclusion through policy, not by switching protection off globally.

Screen lock

Risk reduced: misuse of an unattended authenticated session.

Better response: choose a timeout that balances operational need and security.

Security problems are not solved by deleting the security model.

Ticket 8: "SSO means MFA is unnecessary"

SSO answers:

How many separate sign-in experiences should the user need across connected services?

MFA answers:

What independent authentication evidence is required when establishing identity or session?

SSO can make MFA more valuable because one authenticated session may reach several services.

Usability and authentication strength are separate design dimensions.

Ticket 9: legacy device cannot use modern Wi-Fi security

The device remains useful for one business process.

Possible options:

• replace it;
• isolate it;
• remove its network requirement;
• explicitly accept a narrow exception under policy.

Bad answer:

Turn on the weakest compatible mode for the whole network.

The exception should be as small as the compatibility problem.

Ticket 10: BitLocker recovery appears after hardware service

Evidence:

volume: encrypted
hardware/boot state: changed during approved service
BitLocker recovery: requested
recovery key: escrowed correctly

The encryption system is not necessarily broken.

It is protecting the volume because the trusted state changed.

Use the approved recovery material and document the service event.

This is why recovery planning had to exist before encryption was enabled.

Ticket 11: motion sensor alerts but nobody responds

Evidence:

motion sensor: detects movement
alert: generated
response owner: undefined

The detection control works.

The response architecture does not.

Adding more sensors will not fix an undefined escalation path.

Controls need ownership after detection.

Ticket 12: magnetometer catches metal but badge identity is unknown

Evidence:

entry screening: metal detected
badge reader: not yet used

What did the magnetometer prove?

Only that the screening system detected metal according to its design.

It did not authenticate the person or decide whether the item is authorized.

Different physical controls answer different questions.

Build five control defenses

For five mixed cases, document:

asset
risk / unwanted event
current evidence
trust / access boundary
control selected
why this control matches the risk
control that would be irrelevant or excessive
least-privilege consideration
management / recovery dependency
positive verification
negative verification
remaining risk

Then defend one case using:

The risk is...

The boundary is...

The control changes...

It does not prevent...

The recovery dependency is...

I would verify it by...

The remaining risk is...

That is a security decision.

"Enable everything" is not.

What Week 13 should leave you with

Security controls belong to different layers:

physical access
→ identity / authentication
→ authorization / permissions
→ privilege / elevation
→ network policy
→ encryption
→ endpoint hardening
→ mobile management
→ recovery

The control should be narrow enough to solve the intended risk and strong enough to matter.

Next week we move from preventive controls to threats and response, where the first question becomes: what actually happened, and what evidence supports calling it malicious?