The security field guide
Cybersecurity resources.
Security controls are supposed to change what can happen in your systems. To find out whether they do, we have to look at how those systems actually work. These guides walk through that process: define the problem, examine the evidence, make a change, and check the result.
From an outcome to an assessment
A framework can tell you what an outcome should be. It still takes work to determine whether your organization achieves it. The CSF 2.0 worksheet covers all 106 outcomes, with an example question, evidence to examine, and a check on what that evidence actually supports. Each outcome also links to related guides.
Govern, scope and assure
Someone needs to own the decision, understand the tradeoff, and follow up on what happens.
Governance and risk
Make security risk decisions specific enough to implement, assign and revisit, with a worked example of temporary vendor access.
Read the guide ↗FIELD GUIDE / 02Assurance and compliance evidence
Check security evidence against the claim it is supposed to support, including the system, population, time period and unresolved exceptions.
Read the guide ↗FIELD GUIDE / 24Supplier risk: prove access, accountability and a usable exit
Review what a supplier can access, what the customer still owns and whether the data can be used after exit. Includes an export-and-import acceptance example.
Read the guide ↗FIELD GUIDE / 25Human security: make reporting and verification easy to do
Test whether people can verify a request, pause a consequential action and get help. Follow the reporting process through to a useful response.
Read the guide ↗FIELD GUIDE / 34Scope the operating context before choosing a security checklist
Define assessment scope from the actual system, operating conditions and consequences of failure. Identify where specialist authorization or evidence is required.
Read the guide ↗Understand and design
Start by establishing which identities, systems and data can affect one another. Those relationships give the architecture review something concrete to examine.
Assets and attack surface
Find gaps in asset ownership and visibility by reconciling independent inventories and testing how new, changed and retired assets appear.
Read the guide ↗FIELD GUIDE / 04Security architecture and threat modeling
Use a customer-export example to connect architectural assumptions to actual authorization checks, changed-state tests and unresolved questions.
Read the guide ↗FIELD GUIDE / 05Identity and access
Check how identities gain and lose access across sessions, credentials, queued work and workload federation, including what each test can establish.
Read the guide ↗FIELD GUIDE / 21Data security: verify where information goes and when it leaves
Trace a record through application, search, supplier, support and backup copies. Verify what deletion removes and who owns anything left behind.
Read the guide ↗FIELD GUIDE / 22Key management: test rotation, revocation and recovery separately
Test what changes when a key is rotated, revoked or retired. Follow consumers, cached trust and historical backups through the actual lifecycle.
Read the guide ↗FIELD GUIDE / 23Post-quantum readiness: build a migration decision record
Plan post-quantum migration around data lifetime and real dependencies. Record what each pilot connection negotiated, including authentication that remains unexamined.
Read the guide ↗Build and operate
Policies and designs eventually meet running software. Here we look at what happens in infrastructure, applications, build systems and everyday communication.
Network, DNS and edge security
Test the routes around an edge control, including direct-origin access, administration, DNS changes and application egress.
Read the guide ↗FIELD GUIDE / 07Cloud and SaaS security
Check who maintains, monitors and recovers a cloud service, including the customer responsibilities that remain after a migration.
Read the guide ↗FIELD GUIDE / 08Containers and platform security
Review the running container workload, including its image, identity, resource access, admission controls and differences from the test environment.
Read the guide ↗FIELD GUIDE / 09Endpoint and operating-system security
Verify endpoint settings on the device, test recovery and keep exceptions tied to the specific work that requires them.
Read the guide ↗FIELD GUIDE / 10Application and API security
Test API authorization through requests, queued work and downloads, then reproduce 25 synthetic scenarios in a standalone Python exercise.
Read the guide ↗FIELD GUIDE / 11Secure development and product security
Follow a security defect from its reachable paths through regression tests and the deployed release, using an archive-validation example.
Read the guide ↗FIELD GUIDE / 12Software supply chain and CI/CD
Check source, build, signing and deployment authority as one release process, including unauthorized publication, rollback and recovery.
Read the guide ↗FIELD GUIDE / 35Review the everyday paths from untrusted content to sensitive work
Check email authentication, browser permissions and collaboration access against observed behavior. Keep domain identity, account control and message legitimacy distinct.
Read the guide ↗Find and validate
Finding a weakness is the start. We need to know what causes it, what it permits, and whether the proposed fix actually addresses it.
Vulnerability management
Prioritize vulnerabilities using the actual deployment, documented exploitation and dated EPSS evidence, then verify the running fix.
Read the guide ↗FIELD GUIDE / 14Vulnerability research and coordinated disclosure
Document a vulnerability with reproducible evidence and precise impact, then verify the correction and preserve accurate public attribution.
Read the guide ↗FIELD GUIDE / 15Red, blue and purple team validation
Choose an authorized red- or purple-team exercise that answers a specific question, then verify the defensive response, cleanup and retest.
Read the guide ↗Detect, respond and recover
An alert should give someone enough information to act. After an incident, we also need to establish that recovery restored a usable service.
Detection engineering and security operations
Test a detection from the event source to the responding owner, including benign cases, delays, missing data and delivery failures.
Read the guide ↗FIELD GUIDE / 17Threat intelligence and hunting
Turn threat intelligence into a bounded hunt, verify that the search can find relevant events and retain alternative explanations for the results.
Read the guide ↗FIELD GUIDE / 18Incident response
Prepare incident authority, containment checks and recovery decisions through a fictional tabletop and a record of what was known when action was taken.
Read the guide ↗FIELD GUIDE / 19Digital forensics: preserve evidence before changing the system
Investigate what happened without losing the records needed to check the explanation. Includes collection, custody, hashes and a practical evidence ledger.
Read the guide ↗FIELD GUIDE / 20Recovery testing: measure when the business service works again
Test recovery through a usable business transaction and reconcile the restored records. A worked example shows why matching counts and timestamps can miss lost data.
Read the guide ↗Assess specialist systems
Testing a device that controls a physical process is different from testing a web application. Its operating constraints determine what we can safely do.
Mobile security: test the release app, device and backend together
Test the release app, device and backend as one workflow. Check local data, session changes and platform behavior on identified builds and devices.
Read the guide ↗FIELD GUIDE / 27Let the process determine the OT security assessment
Define an OT assessment around the process, operating constraints and stop authority. Choose tests only after their operational consequences are understood.
Read the guide ↗FIELD GUIDE / 28Follow device trust from installation to retirement
Check device identity, updates, recovery and retirement on representative hardware. Record what the tests establish and which hardware properties remain unexamined.
Read the guide ↗FIELD GUIDE / 29Review the physical dependencies behind a resilient service
Trace redundant services to shared power, cooling, rooms and maintenance. Check physical access and media-handling procedures against what actually happens.
Read the guide ↗FIELD GUIDE / 33Separate contract logic from custody and governance
Review deployed contract logic together with upgrade authority, custody and external dependencies. State the invariants and assumptions each test actually checks.
Read the guide ↗Evaluate AI and abuse
With AI systems, we examine the model and the software that acts on its output. We also look at abuse of legitimate product features, with or without AI.
Define what an AI security evaluation can actually establish
Define attacker access, data provenance and test conditions before evaluating AI security. Connect the result to the deployment decision it can support.
Read the guide ↗FIELD GUIDE / 31Make consequential agent actions accountable
Follow consequential agent actions from request through authorization, execution and readback. Test the actual authority exposed by APIs, MCP tools and local commands.
Read the guide ↗FIELD GUIDE / 32Model harmful use of valid product features
Test how valid product features can be used harmfully. Measure the effect of controls on availability, legitimate customers, privacy and recovery.
Read the guide ↗Scope of this library
The 35 guides are organized with reference to NIST CSF 2.0, CIS Controls 8.1, NICE and MITRE ATT&CK. They explain the assumptions behind their examples and link to sources you can use to investigate further.
These are introductory guides. They do not cover every control, attack technique, jurisdiction or specialist system. Start with the problem you are trying to understand, then identify what the guide leaves unresolved in your environment. That gives you a reason to collect more evidence or bring in additional expertise.