Security+ SY0-801 Audits, Assessments and Penetration Testing

Auditors gather evidence in three main ways: sampling tests a subset of records, questionnaires or surveys collect fixed written answers from many people, and interviews collect detailed accounts from a few people with room for follow-up. Each answers a different kind of question, so the choice depends on what the auditor needs to know.

The methods work together. A survey can reach every department quickly; sampling then checks the records behind the answers; and when the two disagree, an interview lets the auditor probe the discrepancy and ask follow-up questions that a fixed written form cannot. Testimony from surveys and interviews is weaker evidence than records, so auditors corroborate it rather than accept it alone.

How sampling supports a conclusion

In sampling, the auditor selects items (ideally at random, so every item has a chance of selection), tests each one, and counts the exceptions: items where the control did not work, such as a change with no approval. Before testing, the audit plan sets a tolerable exception rate, the highest failure rate the auditor can accept and still conclude the control works.

• The sample exception rate is exceptions divided by the number of items tested, because those are the only items the auditor has evidence about. For example, 4 exceptions in 80 sampled user access reviews is 5%.
• Compare that rate with the tolerable rate: at or below it, the evidence supports the control; above it, the evidence does not.
• A properly selected random sample is the basis for a conclusion about the whole population for the period audited. The conclusion is projected from the sample; it is not a statement about the selected items alone.

An assertion is a claim made by management about its own controls or subject matter, and it is what the auditor gathers evidence to support or refute. Audits do not start from a blank page: management says something is true, and the audit tests whether the evidence backs it up.

The clearest example is a SOC 2 examination. Management provides a written assertion that its system description is accurate and that its controls were suitably designed and implemented (a Type 1 report, as of a date) or also operated effectively over a period (a Type 2 report). The service auditor then tests evidence and gives an opinion on that assertion. Internal audits work the same way on a smaller scale: a team asserting that "every new starter completes security training before receiving system access" is making a testable claim.

• An assertion is the thing tested, not a way of testing. Sampling, interviews and surveys are the methods used to test it.
• Evidence decides. Sample exceptions above the tolerable rate mean the evidence does not support the assertion for the population, however confidently management stated it.
• An assertion is not an audit charter (the audit function's mandate) or a benchmark (an external comparison point).

Signed attestations and acknowledgements as compliance monitoring tools are covered in the Security+ security compliance lesson.

Three reference models give assessors a shared language for adversary behavior: MITRE ATT&CK catalogues specific attacker tactics and techniques, the Cyber Kill Chain orders an attack into sequential phases, and the Diamond Model of Intrusion Analysis relates the four core features of an intrusion event. They are used to scope assessments, map findings and plan tests against realistic attacker behavior.

MITRE ATT&CK

ATT&CK is a free, publicly available knowledge base maintained by MITRE. Its matrices (Enterprise, Mobile and ICS) list tactics as columns and the techniques that achieve them beneath. Because it names specific behaviors, it is the model to use when you need to label what an attacker actually did or pick individual techniques to test one at a time. Its role alongside CVE, CVSS and other threat intelligence resources is covered in the Security+ threat intelligence lesson.

Cyber Kill Chain

Developed by Lockheed Martin, the Cyber Kill Chain describes an intrusion as seven phases in order:

1. Reconnaissance: researching the target (staff, systems, public information).
2. Weaponization: pairing an exploit with a payload, such as a malicious document. This happens on the attacker's side.
3. Delivery: sending the weapon to the target, for example by email or a malicious site.
4. Exploitation: triggering a vulnerability to run the attacker's code.
5. Installation: placing malware such as a backdoor for persistence.
6. Command and control (C2): the installed malware opens a channel back to attacker-controlled servers so the attacker can operate it remotely.
7. Actions on objectives: achieving the goal, such as exfiltrating or encrypting data.

The model's main lesson is that breaking any link stops the attack, and the earlier the break, the less the attacker achieves. Each phase has its own defenses: limiting what staff and systems expose publicly degrades reconnaissance, mail and web filtering disrupt delivery, patching disrupts exploitation, endpoint controls disrupt installation and egress filtering disrupts C2. Weaponization happens entirely on the attacker's side, so defenders cannot act on it directly. Map the attack's current phase first, then look for the defense that acts on that phase or the next one.

Diamond Model of Intrusion Analysis

The Diamond Model describes every intrusion event by four connected features: the adversary (who is responsible), the capability (the tools and malware used), the infrastructure (servers, domains and accounts used to deliver and control the capability) and the victim (the person, department or system targeted). Because the four are linked, knowing one lets the analyst pivot to the others. The Diamond Model does not list techniques and does not order phases; it relates the parts of an event.

Scoping decides what an audit function may examine and how often it examines it. The audit charter sets the mandate, and frequency is set by risk.

Audit charter

An audit charter is the formal document, approved by the board or its audit committee, that establishes the internal audit function's purpose, authority, scope and responsibilities. Crucially, it grants auditors the right of access to the records, people and property they need, so the function's authority comes from the board rather than from the goodwill of the departments it reviews.

Engagement-level documents such as rules of engagement and statements of work are covered in the Security+ third-party risk management lesson.

Audit frequency

Audit frequency should follow risk, not the calendar. A system that holds sensitive data and changes often can drift out of compliance quickly, so it needs assurance more often; a stable, low-impact system with a clean history needs it less often. Regulations and contracts may also set a minimum frequency, such as an annual assessment.

• Factors that raise frequency: sensitive or regulated data, frequent change, critical business dependence, previous findings.
• Factors that lower frequency: little change, low impact if the control fails, a record of clean results.
• Risk-based frequency is a way to allocate a fixed audit effort: more attention where failure is likely and costly, less (but not none) elsewhere, while keeping the assurance's independence where it matters most.

Audit and assessment engagements differ in who performs them and what they compare against. Internal engagements are run by the organization's own people; external engagements are run by outside parties; gap analysis compares against a target standard; benchmarking compares against peers.

Independence decides internal vs external

The deciding difference between internal and external engagements is independence. Internal auditors can be thorough and objective, and reporting lines can improve that objectivity, but they are part of the organization they review. When a stakeholder requires an opinion from a party with no stake in the results, the assurance has to come from outside the organization. Independence runs along a scale: control owners assessing themselves, then internal audit, then independent external parties.

Audit committee vs other board bodies

The audit committee exists so that internal audit reports to independent directors, keeping findings from being filtered by the executives whose areas are audited. Its members are directors who do not run the business, which is what makes the reporting line meaningful. Setting risk appetite and managing risk are covered in the Security+ risk management lesson.

Regulatory examinations vs third-party audits

Ask who initiated the review and on what authority. A body with legal authority reviewing an organization against rules it has issued, with enforcement powers behind the findings, is conducting a regulatory examination; a health regulator inspecting a hospital's handling of patient records is one example. An independent firm the organization commissions to give an opinion is an independent third-party audit. Voluntary standards and frameworks carry no legal authority, so reviews against them are not regulatory examinations.

Gap analysis vs benchmarking

Both compare the organization with something else, so check what the comparison point is. A gap analysis compares current controls with a standard or target state and lists what is missing. Benchmarking compares performance or practice with peers and industry norms, for example whether the time the security team takes to detect and contain incidents is typical for organizations in the same sector.

Penetration tests are classified by how much the testers know before they start: a known environment test gives them full details, a partially known environment test gives them some, and an unknown environment test gives them none. A physical penetration test targets buildings and people rather than networks.

Choose the environment from the goals and constraints together: which perspective the test must reproduce (an outsider, an employee, an authenticated user of an application), how much of the engagement time can be spent on discovery, and what information the organization is willing or permitted to share. Any information given to testers moves the test away from an unknown environment; withholding sensitive material such as source code keeps it short of a fully known one.

Physical penetration testing

A physical penetration test tries to defeat facility and procedural controls in person: for example cloning or borrowing badges, checking whether reception verifies visitors, testing whether doors and cabinets are actually locked, or plugging into unattended network ports in shared areas. Its evidence is a real attempt against the real site, which is what distinguishes it from technical tests of systems and from reviews of documented controls.

Every penetration test runs under written authorization and agreed rules of engagement (scope, timing, permitted techniques), covered in the Security+ third-party risk management lesson. Automated vulnerability scanning, which finds weaknesses without exploiting them, belongs to the Security+ vulnerability management lesson.

Offensive testing (the red team) emulates real attackers and tries to breach defenses; defensive testing (the blue team) detects and responds to that activity; integrated testing (the purple team) has both sides work together to improve detection. A white team often referees exercises and sets their rules.

Separate red and blue exercises realistically test the organization, but findings often travel as reports weeks later, and detection improves slowly. Integrated testing fixes that by closing the loop in real time. It pairs naturally with MITRE ATT&CK: the team picks techniques from the catalogue, runs them and records which ones defenders detect, giving a measurable coverage map.

Passive reconnaissance gathers information about a target without sending anything to the target's systems; active reconnaissance interacts with those systems directly. The test is simple: does any packet reach the target?

Passive does not mean vague. Some public datasets are built from scanning that third parties have already done, so they can describe exposed hosts and services in detail while the tester still sends nothing to the target. Each passive source answers a particular kind of question (ownership, hostnames, people, exposed services), so the skill is matching the source to the information needed within what the rules of engagement allow.

Audits and assessments measure against a framework or standard, and Security+ groups them by reach: industry-based standards apply to one sector or activity, international standards apply across countries, and region-specific standards apply in one country or region.

Two near-twins matter most. ISO/IEC 27001 vs 27002: 27001 contains the certifiable requirements for running an ISMS, while 27002 is guidance on implementing controls, so certification is always to 27001. Reach: an industry standard applies to its sector or activity wherever it happens, a regional scheme carries weight mainly within its own jurisdiction, and an international standard is recognized across borders. Writing the organization's own policies and standards is covered in the Security+ governance lesson.

Functional testing checks that a control does what its specification says: given defined inputs, it produces the expected result. Behavioral testing examines how people and systems actually behave in real operation, which can differ from what the specification assumed.

A control can pass every functional test and still fail in practice because people route around it. The two are classified by their evidence: comparing results with a specification is functional, examining what happens in real use is behavioral. Phishing simulations and other awareness exercises are covered in the Security+ security awareness lesson.