Change One Thing, Prove One Thing

A security control is not proven because someone wrote it in a policy.

It is not proven because a configuration file looks correct.

It is not proven because an alert disappeared.

A defensive change becomes credible when you can connect:

condition → evidence → control → retest → result

This lesson finishes Week 1 by doing exactly that with a synthetic configuration change.

Start from the finding

From Lesson 2:

10:07:05Z user=alex role=student client=LAB-07 result=ALLOW resource=/admin

The baseline said /admin should be instructor-only.

Our bounded finding was:

A supplied log event records a student-role request being allowed to /admin, which conflicts with the stated instructor-only baseline.

That statement gives us something testable.

Inspect the supplied policy snapshots

Baseline policy

routes:
  /status:
    allow_roles: [student, instructor]
  /admin:
    allow_roles: [instructor]

Changed policy

routes:
  /status:
    allow_roles: [student, instructor]
  /admin:
    allow_roles: [student, instructor]

No exploit is needed to reason about the failure.

The changed policy widened /admin access from one role to two.

Describe the condition before naming the risk

A useful condition statement is mechanical:

The changed access policy includes student in the /admin allowed-role list.

Now connect it to behavior:

The supplied log records a student-role admin request receiving ALLOW, which is consistent with the widened policy and conflicts with the intended instructor-only baseline.

Only after that do we state the risk:

A student role may receive privileges intended only for instructors inside this fictional service.

Each sentence is doing a different job.

Why “misconfiguration” is more useful than “hacked” here

Nothing in the supplied evidence proves how the policy changed.

It could be:

• a mistake;
• a bad deployment;
• a stale template;
• an incorrect role mapping;
• a deliberate lab change; or
• an unauthorized change.

The defensive action is similar either way: restore the intended boundary and verify it.

A defender does not need a dramatic story before fixing a clearly documented control failure.

Choose the narrowest control that repairs the boundary

The intended policy already gives us the target state:

/admin:
  allow_roles: [instructor]

In a real system, changing authorization policy would require change control, backups, deployment procedures, and possibly rollback planning.

In this lesson we do not modify a live service. We model the corrected policy and design the retest.

Proposed control

Remove student from the allowed roles for /admin in the isolated lab policy.

Why this control

It directly restores the documented role boundary without changing unrelated /status access.

That last clause matters.

A defensive change should solve the problem without breaking more of the system than necessary.

Retest design

A useful retest must include both a negative and a positive case.

If you only test that students are denied, you might accidentally create a policy that denies everyone.

Negative case

Role: student
Resource: /admin
Expected result: DENY

Positive case

Role: instructor
Resource: /admin
Expected result: ALLOW

Regression case

Role: student
Resource: /status
Expected result: ALLOW

Now the retest protects three things:

1. the forbidden path is blocked;
2. the intended admin path still works; and
3. an unrelated student feature still works.

Supplied post-change evidence

10:30:11Z user=alex    role=student    client=LAB-07 result=DENY  resource=/admin
10:31:06Z user=teacher role=instructor client=LAB-01 result=ALLOW resource=/admin
10:32:22Z user=alex    role=student    client=LAB-07 result=ALLOW resource=/status

Compare this with the retest plan.

What can we claim now?

A defensible statement is:

In the supplied post-change evidence, all three planned access checks match the intended role baseline. The student-role admin request is denied while instructor admin access and student status access remain allowed.

What can we not claim?

The service is completely secure.

Three checks cannot prove that.

Retest is not the same as “the error went away”

Suppose an alert disappears after a change.

That could mean:

• the control worked;
• logging broke;
• the test no longer reaches the service;
• the alert rule changed;
• the system failed closed; or
• the observation window missed the event.

This is why a retest should be designed around expected system behavior rather than the absence of a warning.

Build the Defensive Evidence Record

Combine your Week 1 work into one artifact.

1. Authorization

Name the fictional/isolated system, permitted actions, prohibited actions, evidence sources, and stop conditions.

2. Baseline

State the expected access behavior for /status and /admin.

3. Finding

Record the student-role admin event and the exact baseline conflict.

4. Evidence

Include the raw event and the relevant policy difference.

5. Control

State the smallest change that restores the intended boundary.

6. Retest

Include negative, positive, and regression cases.

7. Result

State what the supplied post-change evidence shows.

8. Limitation

Name at least one thing the evidence does not establish.

A strong limitation might be:

The supplied exercise proves only the three documented authorization behaviors during the provided test window. It does not evaluate every route, identity source, network control, or application vulnerability.

That sentence makes the artifact stronger, not weaker.

Peer challenge

Give your evidence record to another student and ask them to challenge it with these questions:

• Where did this claim come from?
• Which evidence is raw and which part is your interpretation?
• What baseline are you comparing against?
• Did the control change anything unrelated?
• What test would make this conclusion fail?
• What is still unknown?

If you cannot answer one of those, revise the record.

The Week 1 standard

For the rest of CS1337, do not submit “I fixed it.”

Submit something closer to:

Here was the authorized boundary. Here was the expected state. Here is the evidence showing the mismatch. Here is the control I changed or modeled. Here is the retest. Here is what the evidence supports. Here is what it still cannot prove.

That is the difference between an activity and an engineering record.