6.2 Security Control Testing
6.2 Security Control Testing
Security controls should not be trusted simply because they are documented, configured or purchased.
They need to be tested to determine whether they actually work, whether they resist realistic threats and whether they produce the security outcome they were intended to provide.
Find
Identify vulnerabilities, weaknesses and control gaps.
WHAT IS WRONG?Test
Exercise controls and observe their actual behaviour.
DOES IT WORK?Validate
Determine whether the intended security outcome is achieved.
IS IT EFFECTIVE?Conduct Security Control Testing
Identify and evaluate weaknesses within systems and environments.
Attempt to exploit vulnerabilities and demonstrate security impact, including red, blue and purple team exercises.
Examine security event records to verify control operation and detect unusual activity.
Generate controlled transactions or compare observed behaviour against expected baselines.
Examine software implementation and test security-relevant behaviour.
Test how the system behaves when functionality is intentionally abused or used in unexpected ways.
Determine whether testing sufficiently covers relevant requirements, controls, attack surfaces, code paths or scenarios.
Test user, network and application interfaces, including APIs.
Reproduce adversary behaviours in a controlled manner to validate preventive, detective and response controls.
Compare systems and controls against applicable requirements, standards and baselines.
The Big Idea
Different testing techniques answer different security questions.
Control Testing Questions
Existence Is Not Enough
Is the control capable of addressing the intended risk?
Has it actually been deployed?
Is it configured appropriately?
Is it functioning in the real environment?
Does it produce the desired security outcome?
Can failures or bypass attempts be detected?
The organisation has deployed a Web Application Firewall.
That proves:
the WAF exists.
Testing is required to determine whether:
- traffic actually passes through it;
- appropriate rules are enabled;
- malicious traffic is blocked;
- alerts are generated;
- bypass paths exist.
Vulnerability Assessment
A vulnerability assessment systematically identifies and evaluates weaknesses that could expose systems, applications, networks or other assets to compromise.
Vulnerability Assessment
🔎 Vulnerability Scanning Automated discovery is powerful, but output still needs interpretation
Examines hosts, services and network-accessible vulnerabilities.
Examines operating systems, applications and configuration on individual systems.
Evaluates application-facing weaknesses.
Evaluates cloud configuration, identities and exposed services.
Findings may need validation, context and prioritisation before a risk decision is made.
🔑 Credentialed vs Uncredentialed Assessment Different access produces different visibility
Assesses what can be observed from the available network perspective without privileged system access.
OUTSIDE VIEW
Uses authorised credentials to inspect deeper system state, configuration, software and patch information.
INSIDE VIEW
An uncredentialed scan sees:
HTTPS service on port 443.
A credentialed scan may additionally determine:
An external perspective may identify exposure while authenticated inspection may reveal internal configuration weaknesses.
⚠️ False Positives & False Negatives Scanning output is not infallible
The tool reports a vulnerability that is not actually present.
ALARM · NO REAL ISSUE
A real vulnerability exists but the assessment fails to identify it.
NO ALARM · REAL ISSUE
Vulnerability Assessment vs Penetration Testing
| Vulnerability Assessment | Penetration Test | |
|---|---|---|
| Primary Goal | Identify weaknesses | Demonstrate exploitability and impact |
| Typical Breadth | Broad | More targeted |
| Exploitation | Usually limited or absent | Often part of the engagement |
| Automation | Often heavily automated | Usually combines tools and human analysis |
| Main Question | What appears vulnerable? | Can it actually be exploited? |
VA vs Pentest
Penetration Testing
Penetration testing uses authorised adversarial techniques to determine whether vulnerabilities can be exploited and what security impact may result.
🎭 Knowledge Available to the Tester Black box · Gray box · White box
Tester begins with little or no internal knowledge of the target.
OUTSIDER-LIKE VIEW
Tester receives limited knowledge or credentials.
PARTIAL KNOWLEDGE
Tester receives extensive internal knowledge such as architecture, accounts or source information.
DEEP KNOWLEDGE
White-box testing may allow deeper coverage because time is not spent rediscovering information already known to the organisation.
Red · Blue · Purple
Emulates an adversary to achieve defined objectives using realistic attack techniques.
ATTACK
Defends systems by detecting, investigating and responding to adversarial activity.
DEFEND
Brings offensive and defensive perspectives together to improve detection and response effectiveness.
COLLABORATE
Team Colours
🎯 Penetration Test vs Red Team Exercise They are related but not identical
Commonly focuses on identifying and exploiting weaknesses within a defined technical scope.
CAN WE BREAK THIS?
More broadly emulates adversary behaviour to achieve an objective while testing prevention, detection and response.
CAN WE ACHIEVE THE OBJECTIVE?
"Find and demonstrate exploitable vulnerabilities in the customer portal."
"Determine whether an adversary can obtain access to a protected customer-data environment without being detected."
Log Reviews
Logs provide evidence about how security controls and systems behave over time.
Reviewing them can help verify whether expected events are recorded and whether security controls are generating useful evidence.
Review
📜 Testing Logging Controls Generate a known event and follow the evidence
An authorised tester deliberately triggers:
five failed administrator logins.
Event generation, collection, analysis and response may all be separate control components.
Synthetic Transactions
Synthetic transactions use controlled, artificial activity to verify that systems and controls behave as expected.
Every five minutes, a monitoring system:
- connects to the customer portal;
- authenticates using a dedicated test identity;
- requests a known page;
- checks the expected response;
- records the result.
Failure may reveal problems with:
Synthetic Transaction
📊 Benchmarks & Baselines Compare observed state against a known or expected state
Benchmarking provides a reference against which observed security or system behaviour can be compared.
Expected:
administrative remote access disabled.
Observed:
administrative remote access enabled.
Normal authentication response time:
200 ms.
Current result:
8 seconds.
The difference may trigger investigation.
Benchmark
Code Review & Testing
Security weaknesses can exist directly in software implementation.
Code review examines how the application implements security-sensitive functionality rather than relying only on behaviour visible from the outside.
A reviewer inspects security-relevant implementation and logic.
Tools analyse code or compiled artefacts without exercising the running application.
Verify expected security behaviour of individual components.
Verify security behaviour where components interact.
Observe the running application's response to security-relevant inputs and behaviour.
💻 Code Review Example A control may look correct from the interface while failing internally
Users may view only their own customer records.
The reviewer finds that the application accepts:
customer_id
from the browser but does not verify that the authenticated user is authorised to access that customer.
Static vs Dynamic Testing
| Static | Dynamic | |
|---|---|---|
| Application Running? | Not required | Yes |
| View | Code / implementation | Runtime behaviour |
| Strength | Can inspect paths not easily reached externally | Demonstrates behaviour of deployed application |
| Limitation | May generate findings without runtime context | May not reach every internal code path |
Misuse Case Testing
Normal functional testing asks:
"Can the legitimate user complete the intended task?"
Misuse-case testing asks:
"What happens if someone intentionally abuses the functionality?"
Customer transfers £100 from their own account.
Customer changes the account identifier in the request to another customer's account.
Use vs Misuse
😈 Think Like the Abuser Test valid functionality in invalid or malicious ways
What happens if thousands of login attempts are submitted?
Can the process be used to reset another user's account?
Can negative or extremely large values be submitted?
What happens if executable or malformed content is uploaded?
Can identifiers be changed to access another user's objects?
Can steps be skipped or performed out of order?
🚫 Positive vs Negative Security Testing Expected success and expected failure both matter
Confirm legitimate behaviour is allowed.
Finance administrator can view authorised payroll records.
Confirm illegitimate behaviour is rejected safely.
Standard employee cannot access payroll records.
Positive vs Negative
Coverage Analysis
Coverage analysis asks whether the security testing performed is broad enough to support the intended assurance conclusion.
Coverage can be considered across several dimensions.
Have relevant security requirements been tested?
Have important controls been exercised?
Have the relevant assets and systems been included?
Have meaningful entry points been evaluated?
Have important interfaces and trust boundaries been tested?
Where relevant, how much of the application logic has been exercised?
🗺️ Coverage Example Look for what has not been tested
Security testing covers:
But excludes:
Ask: "What important areas remain untested?"
📐 Coverage Analysis Is Broader Than Code Coverage Do not automatically interpret the CISSP term too narrowly
Code coverage can be one useful measure in software testing.
Examples include whether testing exercised:
But security coverage can also include:
Tests can execute a large percentage of code without testing the important security assertions.
Interface Testing
Interfaces are trust boundaries through which users, systems and applications exchange commands and data.
Test how human users interact with the application.
Test exposed protocols, ports, services and network relationships.
Test integrations and application-to-application communication.
Test authentication, authorization, input handling and data exposure through programmatic interfaces.
Interface Testing
🔌 Test the Interface, Not Just the Screen The visible UI may expose only part of the application's functionality
The web interface displays:
name + email address.
The underlying API returns:
🔗 API Security Testing Test the service directly rather than assuming the client enforces security
Test
The mobile application never displays an "administrator" function.
A tester calls the administrative API directly.
The server must enforce authorization itself rather than assuming:
"The button was hidden, so users cannot call the function."
Breach Attack Simulation - BAS
Breach attack simulation uses controlled attack behaviours to repeatedly evaluate how security controls respond to adversary techniques.
BAS
💥 BAS Example Validate the defensive chain
A controlled adversary-emulation tool performs a known credential-access or execution technique on an authorised test endpoint.
A simulated technique that is allowed to execute may still represent a successful defensive test if detection and response operate exactly as designed.
BAS vs Penetration Test vs Red Team
| BAS | Penetration Test | Red Team | |
|---|---|---|---|
| Main Focus | Repeatably validate defensive controls | Find and exploit weaknesses | Achieve adversary-style objectives |
| Automation | Often highly automated | Tools + human expertise | Strong human/adversarial component |
| Repeatability | High | Moderate | Varies |
| Creativity | Based on predefined/supported behaviours | Human investigation | High adversarial adaptability |
| Main Question | Would controls stop or detect this? | Can we exploit this? | Can the adversary achieve the objective? |
Repeatable automation and adaptive human adversary simulation provide different forms of assurance.
Compliance Checks
Compliance testing determines whether systems and controls satisfy specified requirements.
Does implementation follow internal security policy?
Does configuration satisfy the required technical baseline?
Are applicable regulatory security obligations addressed?
Are contractual security requirements being met?
📋 Compliance ≠ Security Passing requirements does not prove the absence of exploitable risk
Requirement:
Administrative accounts must use MFA.
Compliance check:
PASS.
But an unrelated vulnerability allows an attacker to execute code without authenticating at all.
Compliance
Testing Different Security Controls
| Control | Possible Test |
|---|---|
| Firewall | Attempt permitted and prohibited network connections |
| MFA | Attempt authentication without required second factor |
| DLP | Attempt authorised simulation of protected-data exfiltration |
| Account Lockout | Generate defined failed authentication attempts |
| Logging | Generate known event and verify log creation |
| SIEM Detection | Generate recognised attack behaviour and verify alert |
| Backup | Perform restoration validation |
| Segmentation | Attempt prohibited traffic between network zones |
| Authorization | Attempt access using a lower-privileged identity |
| Secure Configuration | Compare actual configuration against approved baseline |
Prevent · Detect · Respond
Testing can validate different layers of the security architecture.
Defensive Chain
🧯 When a Control Fails a Test A failed test is evidence, not the end of the process
🔁 Retesting Confirm remediation rather than trusting closure status
Standard users can access an administrative API.
Development team adds server-side authorization.
Repeat the original unauthorized request and related variants.
Confirm:
access is now denied.
Automated vs Manual Testing
Automated scanner:
identifies outdated web-server software.
Human tester:
discovers that changing an invoice identifier exposes another customer's invoice.
🚧 Test Safely Security testing itself can create risk
Security control testing should operate within the approved strategy and rules of engagement established before testing begins.
Consider
Test whether production anti-DDoS protection works by unexpectedly launching enough traffic to take the customer service offline.
Testing a Banking Application
A bank wants to validate security controls protecting online payments.
Testing Network Segmentation
Policy says:
Employee workstations must not connect directly to the production database network.
Can the SOC Detect the Attack?
🎓 CISSP Scenarios Recognise which security-control test is being described
An organisation scans thousands of servers to identify missing patches and known weaknesses.
Which activity?
Vulnerability assessment.
A tester exploits a discovered weakness to demonstrate access to sensitive information.
Which activity?
Penetration testing.
A security manager assumes a vulnerability scan and penetration test are the same activity.
Is this correct?
No.
Vulnerability assessment identifies weaknesses; penetration testing can demonstrate exploitability and impact.
A scanner reports an obsolete software version, but manual validation proves the system is not running that version.
Which result?
False positive.
A real vulnerability exists but the scanner does not identify it.
Which result?
False negative.
An authenticated scanner can inspect installed software and system configuration.
Which approach?
Credentialed vulnerability assessment.
A tester is given no internal architecture information and approaches the application like an outsider.
Which style?
Black-box testing.
A tester receives source code, architecture diagrams and test accounts.
Which style?
White-box testing.
An adversarial group attempts to reach a sensitive business objective while defenders are unaware of the detailed attack plan.
Which exercise?
Red-team exercise.
Security analysts detect and respond to the simulated attackers.
Which team?
Blue team.
Offensive and defensive teams deliberately collaborate to test a technique and improve detection logic.
Which approach?
Purple teaming.
A penetration test focuses on vulnerabilities, while another exercise attempts to achieve a specific adversary objective across people, processes and technology.
What is the second exercise?
Red teaming.
Security deliberately generates failed administrator logins and checks whether the events appear in the SIEM.
Which testing activity?
Log/control testing.
The application records a malicious event, but no central system collects the event.
What does the test reveal?
A gap in the logging/monitoring control chain.
A monitoring platform periodically performs a known login and business operation to confirm that the service behaves correctly.
Which technique?
Synthetic transaction.
Current security configuration is compared against an approved expected configuration.
Which concept?
Benchmark / baseline comparison.
A security engineer examines application source code to identify missing authorization checks.
Which technique?
Code review.
A tool analyses source code without executing the application.
Which general approach?
Static analysis/testing.
A tester sends requests to the running application and observes its behaviour.
Which general approach?
Dynamic testing.
A normal user is supposed to transfer money only from their own account. The tester changes the source-account identifier to another customer's account.
Which technique?
Misuse-case testing.
A legitimate user should be allowed to retrieve their own record.
Which type of test?
Positive test.
A standard user attempts an administrator action and the test expects it to fail.
Which type?
Negative test.
The security team has tested the website but not the mobile API, administrator portal or external integrations.
Which issue?
Insufficient test coverage.
Automated software tests execute 90% of source-code statements.
Does this prove the application is secure?
No.
Code coverage does not itself demonstrate adequate security-test coverage.
A tester analyses what information an API returns instead of looking only at what the browser displays.
Which technique?
Interface / API testing.
A mobile application hides an administrator button, but the underlying API accepts administrator requests from a standard user.
What failed?
Server-side authorization.
A tool safely reproduces known adversary techniques every day to determine whether EDR and SIEM controls detect them.
Which technique?
Breach attack simulation.
An organisation claims BAS has removed all need for human penetration testing and red teaming.
Is this appropriate?
No.
Automated adversary simulations and adaptive human testing provide different forms of assurance.
A simulated malicious technique executes successfully but the SOC immediately detects and contains it.
Did every control fail?
No.
Prevention failed or allowed the behaviour, but detection and response controls operated.
System configuration is automatically compared with a mandatory organisational security baseline.
Which technique?
Compliance check.
A system passes every compliance check, so management concludes that it cannot be compromised.
What is wrong?
Compliance with tested requirements does not prove the absence of all security vulnerabilities.
A firewall rule is reviewed and appears to block workstation-to- database traffic.
What provides stronger functional evidence?
Attempt the prohibited connection under controlled conditions.
A security control fails. The administrator changes the configuration and immediately closes the finding without another test.
What is missing?
Retesting.
A remediation successfully fixes the original vulnerability but creates a new authorization problem.
Which testing principle matters?
Retest the fix and relevant surrounding functionality.
An automated scanner finds outdated software while a human tester discovers a business-logic flaw.
Which lesson?
Automated and manual testing are complementary.
A penetration test demonstrates a vulnerability but no detection alert appears in the SOC.
What additional weakness has been demonstrated?
Detection/monitoring control weakness.
An attack is blocked by endpoint protection but the SIEM never sees the event.
Which lesson?
Preventive and monitoring controls should be tested independently and end-to-end.
A tester launches an aggressive denial-of-service technique against production without approval.
Primary problem?
Unsafe and unauthorised testing.
A security test generates sensitive customer data and exploit details.
What should happen?
The testing evidence should be protected according to its sensitivity.
A WAF is installed and enabled, but attackers can reach the application directly through another endpoint.
Which lesson?
Control deployment does not prove complete or effective control coverage.
A tester wants to determine whether a known malicious technique is prevented, logged, detected and investigated.
Which approach is particularly suitable?
BAS or a controlled adversary/purple-team exercise.
The organisation repeatedly checks a security control using the same controlled transaction and compares results with an expected outcome.
Which technique?
Synthetic transaction / benchmark testing.
Recognise the Clue Words
Identify Weaknesses
Broad discovery.
Vulnerability AssessmentExploit Weakness
Demonstrate impact.
Penetration TestAdversary Objective
Realistic attack exercise.
Red TeamDefend Against Attack
Detection and response.
Blue TeamAttackers + Defenders Collaborate
Improve security together.
Purple TeamDid Event Get Recorded?
Security evidence.
Log ReviewKnown Test Activity
Controlled transaction.
Synthetic TransactionExpected vs Actual
Compare state.
BenchmarkInspect Source
Implementation review.
Code ReviewNot Running Application
Analyse implementation.
Static TestingRunning Application
Observe runtime behaviour.
Dynamic TestingHow Could This Be Abused?
Malicious use.
Misuse CaseAllowed Action Works
Expected success.
Positive TestForbidden Action Fails
Expected rejection.
Negative TestWhat Wasn't Tested?
Assurance completeness.
Coverage AnalysisUI / Network / API
Trust boundary.
Interface TestingAutomated Adversary Technique
Repeatable defensive validation.
BASMeet Baseline?
Requirement comparison.
Compliance CheckFinding Isn't Real
Incorrect alarm.
False PositiveReal Issue Missed
False assurance.
False NegativeFix Implemented
What next?
Retest⚠️ Common CISSP Mistakes Know what each testing technique actually demonstrates
Vulnerability assessment identifies weaknesses.
Penetration testing attempts to demonstrate exploitability and impact.
Automated results may require validation.
False negatives and test limitations exist.
Penetration testing commonly focuses on finding and exploiting vulnerabilities.
Red teaming generally focuses on achieving adversarial objectives and exercising defensive capabilities more broadly.
The blue team performs defensive detection, investigation and response functions.
Purple teaming represents collaboration between offensive and defensive perspectives.
Logs should contain appropriate information, be collected, protected and made useful for monitoring where required.
It is controlled activity created to test expected system behaviour.
Static testing analyses implementation without running the system.
Dynamic testing evaluates runtime behaviour.
Use cases describe intended functionality.
Misuse cases deliberately examine malicious or unintended use.
Security controls also need negative tests proving prohibited actions are rejected.
Security coverage may include requirements, controls, interfaces, attack surfaces, threats and misuse scenarios as well as code.
Tests must assert meaningful security properties.
An API must enforce security independently of what the user interface displays.
Security-sensitive functions must be protected by server-side authorization.
BAS is particularly useful for repeatable validation of controls against known adversary behaviours.
Automated repeatability and human adversarial creativity solve different testing problems.
Detection and response controls may still operate successfully.
Compliance confirms satisfaction of particular requirements, not the absence of every possible vulnerability.
Configuration may look correct while actual system behaviour differs.
Retest the control to confirm the fix.
Complex business logic and unexpected behaviour often require human analysis.
Security tests should gather sufficient evidence without creating unjustified operational risk.
Quick Reference
| If you see... | Think... |
|---|---|
| Find weaknesses broadly | Vulnerability Assessment |
| Demonstrate exploitability | Penetration Test |
| Little/no target knowledge | Black Box |
| Partial target knowledge | Gray Box |
| Extensive target knowledge | White Box |
| Adversary simulation | Red Team |
| Defensive detection/response | Blue Team |
| Offense and defense collaborate | Purple Team |
| Review event records | Log Review |
| Generate known test activity | Synthetic Transaction |
| Compare actual with expected state | Benchmark |
| Inspect source implementation | Code Review |
| Analyse without running | Static Testing |
| Test running application | Dynamic Testing |
| How could legitimate functionality be abused? | Misuse Case |
| Valid operation should succeed | Positive Testing |
| Invalid operation should fail | Negative Testing |
| What important areas were not tested? | Coverage Analysis |
| User / network / API boundary | Interface Testing |
| Automated repeatable adversary techniques | Breach Attack Simulation |
| Compare against required baseline | Compliance Check |
| Reported problem is not real | False Positive |
| Real problem not identified | False Negative |
| Fix has been implemented | Retest |
6.2 Techniques Memory Aid
Vulnerability vs Penetration Memory Aid
Find ≠ Exploit
Red · Blue · Purple Memory Aid
6.2 Master Memory Aid
The Security Tester's Questions
Key Takeaways
CISSP 6.2 focuses on actually conducting security control testing.
The current CISSP outline explicitly includes vulnerability assessment, penetration testing, log reviews, synthetic transactions and benchmarks, code review and testing, misuse-case testing, coverage analysis, interface testing, breach attack simulations and compliance checks.
A control should not be assumed effective merely because it exists or is documented.
Testing can determine whether a control is correctly implemented, operating as intended and producing the expected security outcome.
Installed ≠ configured ≠ operating ≠ effective.
Vulnerability assessment identifies weaknesses across the assessed environment.
Automated scanning can provide broad and repeatable vulnerability discovery but its results may require validation and contextual analysis.
Credentialed and uncredentialed assessments provide different levels and perspectives of visibility.
False positives report weaknesses that are not actually present.
False negatives fail to identify weaknesses that really exist.
Vulnerability assessment primarily asks "what weaknesses exist?" Penetration testing asks "can we exploit them and what is the impact?"
Penetration testing uses authorised adversarial activity to demonstrate exploitable risk within an agreed scope.
Black-box testing begins with little internal information, gray-box testing provides partial knowledge and white-box testing provides extensive knowledge.
Red teams emulate adversarial activity and attempt to achieve defined objectives.
Blue teams perform defensive detection, investigation and response.
Purple teaming promotes collaboration between offensive and defensive perspectives to improve control effectiveness.
Red = attack. Blue = defend. Purple = improve together.
A red-team exercise is not necessarily the same as a penetration test. Penetration testing often focuses on exploitable weaknesses, while red teaming can test whether an adversary can achieve broader objectives against prevention, detection and response.
Log reviews can validate whether security-relevant events are generated, collected and available for monitoring.
Testing logging end-to-end can verify event generation, central collection, detection and response.
Logs existing does not prove that security monitoring is effective.
Synthetic transactions create known controlled activity and compare the resulting behaviour with the expected outcome.
Benchmarks provide a baseline or expected state against which current results can be compared.
Code review examines how security behaviour is implemented inside the software.
Static testing can analyse software without executing the application, while dynamic testing examines behaviour of the running system.
Static and dynamic testing techniques provide complementary information.
Functional software can still contain serious security flaws.
Misuse-case testing deliberately exercises functionality in malicious, invalid or unexpected ways.
Normal use cases ask how legitimate functionality should operate.
Misuse cases ask how an attacker might abuse that functionality.
Positive security tests confirm that authorised behaviour succeeds.
Negative security tests confirm that unauthorised or invalid behaviour is rejected safely.
Good security testing tests both what should work and what should not work.
Coverage analysis evaluates whether enough of the relevant security surface has been tested.
Security coverage can include requirements, controls, assets, interfaces, attack surfaces, threats, misuse cases and code paths.
Code coverage is therefore only one possible form of coverage analysis.
High code coverage does not automatically mean high security coverage.
Interface testing evaluates security at user, network and application-to-application boundaries.
APIs should be tested directly because the visible client interface may expose only part of the underlying functionality and data.
Hiding a function in the user interface does not provide server-side authorization.
Breach attack simulation uses controlled adversarial behaviours to evaluate whether defensive controls prevent, detect and respond to known attack techniques.
BAS is particularly useful where repeatable security-control validation is required.
BAS does not automatically replace human penetration testing or red teaming because adaptive human investigation provides a different form of assurance.
A simulated adversary technique being executed does not necessarily mean every defensive control failed; detection and response may still operate correctly.
Test the defensive chain: Prevent → Detect → Alert → Respond.
Compliance checks compare actual systems and controls with required policies, standards, contracts or regulatory criteria.
Compliance with a defined requirement does not demonstrate the absence of every possible security weakness.
Configuration review and functional testing provide different evidence. A configuration can look correct while actual system behaviour differs.
Automated testing provides scale, repeatability and frequency.
Manual testing provides context, creativity and the ability to explore unexpected behaviour.
Automation and human security testing are complementary rather than mutually exclusive.
Testing itself can create risk, particularly in production environments, so assessment authorization, scope, data handling and operational safety remain important.
When a control fails, the finding should be validated, analysed and remediated.
Remediation should then be retested.
Fix applied ≠ fix proven. Retest.
The central CISSP principle is: choose the testing technique that answers the security question, exercise the control under realistic conditions, observe the actual outcome and obtain enough evidence to determine whether the control truly works.
📚 Sources & Further Reading Security-control testing and adversary-emulation references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-53A Rev. 5 - Assessing Security and Privacy Controls
View current NIST control-assessment guidance - NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment
View NIST security-testing guidance - OWASP Web Security Testing Guide
View the OWASP Web Security Testing Guide - OWASP - Testing Defenses Against Application Misuse
View OWASP misuse testing guidance - MITRE ATT&CK - Adversary Emulation and Red Teaming
View MITRE adversary-emulation resources - MITRE CALDERA
View MITRE's automated adversary-emulation platform