CY2: Authorised assessment: settings, packages and reports
Planning an assessment
🎯You'll be able to
Choose the right kind of assessment, plan its method within the scope, and decide what evidence to keep.
🏠The everyday picture
A building inspector doesn't wander around at random. They bring a checklist, agree with the owner which floors to inspect, note each problem with a photo, and hand over a report the owner can act on.
📘What it really is
- Kinds of assessment:
- Configuration review: reading settings against a known-good baseline.
- Dependency review: matching the packages a system runs against published advisories.
- Secure code review: reading the code for flaws (CY3).
- Vulnerability assessment: a broad search for known weaknesses, usually with tools, on systems in scope.
- Penetration test: a deeper, authorised test by specialists that tries to show real impact. It needs a careful scope and rules of engagement, and it's beyond this path.
-
Audit: checking controls against a standard (CY9).
-
Method: decide the checklist first. Good sources are the OWASP Application Security Verification Standard (ASVS) for apps and the CIS Benchmarks for operating systems and cloud services.
-
Evidence: for every finding, keep what shows it, such as the exact setting or version, with the file and date.
- Timebox: agree the hours. An assessment lists what was checked and what wasn't.
- Safety: prefer reading copies and snapshots over touching live systems, and never use real personal data you don't need.
📝A worked example
Input: the clinic owner wants to know how risky the old AarogyaDesk server was. You have the snapshot in data/assessment-target/.
Steps:
- Confirm the permission in the snapshot's
README.md: what was captured, by whom, and on which date. - Plan three checks: settings against a baseline, packages against the advisory list, response headers against a header checklist.
- Decide the evidence for each: the setting's name and value, the package and version, the missing header.
Expected output: a half-page plan with three checks, their sources and the evidence each will keep.
🌍Where it's used
- Customer questionnaires ask which standard a company checks against.
- Cloud teams run configuration checks against CIS Benchmarks every day.
- Auditors ask to see the plan and the evidence, not only the result.
📝Case scenario
Two consultants reviewed the same online store. One wrote "the site looks secure". The other listed 30 checks, marked 27 passed and 3 failed, with evidence. Only the second report could be checked by anyone else, and it was the one the store acted on.
🖱️Try it
Open the CIS Benchmarks page or the OWASP ASVS and pick five checks that would apply to a small web app. Write each as a yes/no question. Success: each question can be answered from a settings file or a response, without guessing.
⚠️Common mistakes
- No checklist. Sign: the assessment depends on what the assessor remembered. Fix: choose a standard list first.
- Calling every check a penetration test. Sign: the word used for a settings review. Fix: name the method accurately.
- Missing "what wasn't checked". Sign: a report that sounds complete. Fix: list the limits.
🛠️For your project
Project 1 plans and runs exactly these three checks, using the kit's snapshot.
✅Quick check
What is the difference between a configuration review and a penetration test?
Show the answer
A configuration review reads settings against a baseline; a penetration test is a deeper authorised test that tries to show impact.
Why should a report list what wasn't checked?
Show the answer
So nobody mistakes a limited assessment for a complete one.