[Figure: FiveStudy logo]
FiveStudy
Cybersecurity · Unit 5 · 5.2.b
AP Cybersecurity · Securing Applications and Data
Managerial Controls for Applications and Data
Both policies do one job: take a technical decision once, centrally, instead of per project.
key ideaBoth policies do the same job: take a technical decision once, centrally, instead of per project.
Matching controls to threats
Developers under deadline make cryptography and testing decisions individually, and those decisions drift. A cryptography policy and a web application security policy replace that drift with one answer everyone builds against.
| Policy | What it specifies | Failure it prevents |
|---|
| cryptography policy | acceptable encryption protocols and key parameters | each team choosing its own algorithm, some of them broken |
| | a list of algorithms approved for specific uses | a hashing algorithm used where an encryption one belongs |
| | minimum key lengths | short keys that pass review because nobody stated a floor |
| web application security policy | requirements and parameters for testing web application vulnerabilities | testing that happens only when someone remembers |
| | parameters for when testing occurs and how findings are mitigated | findings that are recorded and never fixed |
Every row converts a repeated judgment call into a stated default. That is what makes a managerial control cheaper than the engineering it replaces.
Cryptographywhich algorithms, what key length
Web app securitywhen to test, what to fix
Bothdecided once, not per project
Layering
The two policies sit at different points in a project's life: cryptography is decided at design, web application testing recurs through delivery and operation. Neither substitutes for the other.| Without the policy | With it |
|---|
| each team picks an algorithm; some pick a broken one | an approved list, chosen once by people qualified to choose |
| ‘encrypted’ means whatever the developer decided | a minimum key length makes the claim measurable |
| a hash used where encryption was needed, or the reverse | algorithms approved for specific uses |
| testing happens when someone has time | stated parameters for when testing occurs |
| findings are logged and quietly aged out | mitigation requirements attached to each finding |
Read the left column as the default state of any organization without these policies — not as negligence, but as what happens when a technical decision is left to whoever is closest to the deadline.
what each policy contains
- A cryptography policy describes the acceptable encryption protocols and key parameters for the organization.
- It may list algorithms approved for specific uses — not all algorithms suit all purposes.
- It sets minimum key lengths, which is what makes ‘encrypted’ a checkable claim.
- A web application security policy outlines testing and mitigation requirements — including when testing happens.
Worked analysis
EX 1
Why list algorithms by use?
A cryptography policy could simply say “use strong encryption”. Why does the CED describe algorithms approved for specific uses instead?
1
Note that algorithms are not interchangeable
A hash is not an encryption algorithm; a symmetric cipher does not solve key exchange.
2
Predict the vague-policy outcome
A developer picks something strong but wrong for the purpose — and it passes review.
3
State what the list adds
It maps purpose to algorithm, so the choice is made by someone qualified once.
4
Add the key parameter
Minimum key lengths turn ‘strong’ into a number a reviewer can check.
5
State the principle
A policy is only useful to the extent it is checkable.
EX 2
Testing that never happens
An organization requires web application vulnerability testing but does not say when. Diagnose.
1
Note what exists
A requirement to test — genuinely the harder half to agree.
2
Note what is missing
Parameters for when testing occurs.
3
Predict the outcome
Testing happens before major releases, occasionally, when there is time.
4
Give the fix
State the trigger: before release, after significant change, and on a schedule.
5
Add the second half
Mitigation requirements — how quickly findings of each severity must be fixed, or the tests just produce a growing list.
EX 3
The key length nobody set
A review finds three applications encrypting data with three different key lengths, one clearly too short. No policy exists. Assess.
1
Note the absence of a rule
With no minimum key length stated, each developer chose reasonably by their own lights.
2
Resist blaming the developer
The control that was missing was managerial, not technical.
3
State the immediate fix
Re-key the weak application to the current standard.
4
State the durable fix
Publish a cryptography policy with approved algorithms and minimum key parameters.
5
Note the recurrence otherwise
Without the policy, the same finding returns with the next application.
Check yourself
What does a cryptography policy describe?
Show answer
The acceptable encryption protocols and key parameters for an organization — typically a list of algorithms approved for specific uses and minimum key lengths.
Why list algorithms by use rather than simply requiring 'strong encryption'?
Show answer
Algorithms are not interchangeable: a hash does not do the job of a cipher. Mapping purpose to algorithm makes the decision once, by someone qualified, and makes review possible.
What does a web application security policy outline?
Show answer
The requirements and parameters for testing and mitigating web application vulnerabilities — including parameters for when testing occurs.
Why does the timing parameter matter?
Show answer
Without a stated trigger, testing happens when someone has time. Naming when it occurs — before release, after significant change, on a schedule — is what makes it reliable.