Thor’s Quick Sheets – CISSP® Domain 6

Contents

Assessment and Test Strategies ..................................................................................................................................2

Audit Strategies for Cloud and Hybrid Environments ...................................................................................................3
Vulnerability Scanning/Testing ...................................................................................................................................4
Penetration Testing....................................................................................................................................................4
Software Testing ........................................................................................................................................................7

https://thorteaches.com/
 Thor’s Quick Sheets – CISSP® Domain 6
Assessment and Test Strategies
Key Terms:
• Static Testing: We passively test the code; we do not run it.
• Dynamic Testing: We test code while executing it.
• Fuzzing (Fuzz Testing): This black box testing submits random, malformed data as inputs into software
programs to determine if they will crash.
• Penetration Testing (Pen Testing): We pay someone to test our security by trying to compromise our
safeguards; this is testing both our organization's physical and logical perimeter.
• Synthetic Transactions/Monitoring: Building scripts/tools to simulate normal user activity in an app.
Security Assessments: A full picture approach to assessing how effective our access controls are; has a very
broad scope. Security assessments often span multiple areas and can use some or all these components:
• Policies, procedures, and other administrative controls
• Assessing the real-world effectiveness of administrative controls
• Change management
• Architectural review
• Penetration tests
• Vulnerability assessments
• Security audits
Security Audit: A test against a published standard. SOC 2 Type 1 or 2, PCI-DSS, …
Internal, External, and 3rd-Party Audits:
• Unstructured Audits (internal): Internal auditors to improve our security and find flaws, often done before
an external audit.
• External Audits: Like internal audits, an external company audits our controls to find flaws and improve our
security posture.
• Structured Audits (3rd party): External auditors who validate our compliance, often done for a regulatory
body; they are experts, and the audit adds credibility.
SOC1: Focus on service organization controls relevant to internal control over financial reporting.
• Type I: Opinion on design effectiveness of controls. Type I covers a single point in time.
• Type II: Opinion on design and reporting effectiveness of controls. Type II covers a minimum six-month
period.
SOC 2: Assess internal controls for compliance and operations. Must meet trust service principles defined by
AICPA: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
• Type I: Report on management's description of a service organization's system and the suitability of the
design of controls. Type I covers a single point in time.
• Type II: Report on management's description of a service organization's system and the suitability of
controls' design and operating effectiveness. Type II covers a minimum six-month period. The purpose of
type II reports is to validate/verify that an organization meets the requirements as stated in the published
standard. Proves organization controls listed are operational and enforced. Better and more expensive than
Type I reports.

https://thorteaches.com/
2
 Thor’s Quick Sheets – CISSP® Domain 6
SOC 3: Like the SOC 2 report but much more generalized, shorter, and less sensitive; a more public-facing
document; includes only the auditor's opinion and a limited description of controls. Covers the controls'
design and operating effectiveness relevant to applicable trust service principles (security availability,
processing integrity, confidentiality, and privacy).
Security Audit Logs: Reviewing security audit logs in an IT system is one of the easiest ways to verify that
access control mechanisms are working as intended. Reviewing audit logs is primarily a detective control.
NIST Special Publication 800-92 suggests the following log types should be collected and audited:
• Network Security Software/Hardware: Antivirus logs, IDS/IPS logs, remote access software (VPN logs), web
proxy, vulnerability management, authentication servers, routers, and firewalls.
• Operating System: System events, audit records, applications, client requests and server responses, usage
information, significant operational actions.
Centralized Logging: This should be automated and secure; even administrators have limited access. Often a
central repository is hashed and never touched, and a secondary copy is analyzed to ensure integrity. Logs
should have a retention policy to ensure we are compliant and keep the logs as long as needed.
Security Audit Logs (Audit Trail): Audit record management typically faces five distinct problems:
(1) Logs are not reviewed on a regular and timely basis. (2) Audit logs and audit trails are not stored for long.
(3) Logs are not standardized or viewable by correlation toolsets - they are only viewable from the audited
system. (4) Log entries and alerts are not prioritized. (5) Audit records are only reviewed for the bad stuff.

Audit Strategies for Cloud and Hybrid Environments

Auditing in On-Premise Environments: Infrastructure, applications, and data are hosted and managed within
the organization's physical boundaries.
• Physical security: Securing buildings, data centers, and server rooms with proper access control and
monitoring.
• Network security: Firewall configuration, network segmentation, intrusion detection, and prevention
systems.
• System and application security: Ensuring proper configuration, patching, and security against known
vulnerabilities.
• Data security: Classification, storage, handling, and protection of sensitive data.
• System and application logs: Collecting and analyzing logs for policy violations, misuse, or potential security
incidents.
• Configuration management: Ensuring proper configuration according to best practices and organizational
policies, and maintaining proper change management.
• Challenges in on-premise audits: Complex infrastructure and legacy systems can make it difficult to obtain
an accurate asset inventory, potentially leading to security risks.
Auditing in Cloud Environments:
• Shared Responsibility Model: Cloud service provider and customer are responsible for different aspects of
security, depending on the service model (PaaS, IaaS, SaaS).
• Data Sovereignty: Understanding where data can be stored and processed based on legal requirements.
Audit Approaches for Cloud Service Models: Cloud providers typically do not allow external audits in their
data centers.

https://thorteaches.com/
3
 Thor’s Quick Sheets – CISSP® Domain 6
• Infrastructure as a Service (IaaS): Customer is responsible for securing the operating system, applications,
and data running on the cloud provider's infrastructure.
• Platform as a Service (PaaS): Customer is responsible for securing applications and data, while the cloud
provider manages the underlying operating systems, middleware, and hardware.
• Software as a Service (SaaS): Cloud provider manages and secures the entire application stack,
infrastructure, platform, and software.
Service Level Agreements (SLAs) and Contracts: Clarify the cloud provider's obligations regarding privacy,
security, and data protection.
Auditing in Hybrid Environments: Some resources are hosted on-premise, while others are in the cloud.
• Complexity: Harder to maintain a consistent security posture across the entire environment.
• Integration: Ensuring proper integration and configuration between onpremise and cloud resources.

• Data flow: Mapping data flow between on-premise and cloud environments to understand how to protect
specific data.
• Incident response: Ensuring effective response both on-premise and in the cloud environment.

Vulnerability Scanning/Testing
Vulnerability Scanning/Testing: A vulnerability scanner tool is used to scan a network or system for a list of
predefined vulnerabilities such as system misconfiguration, outdated software, or a lack of patching. It is very
important to understand the output from a vulnerability scan; they can be hundreds of pages for some
systems and how the vulnerabilities map to Threats and Risks (Risk = Threat x Vulnerability). When we
understand the true Risk, we can then plan our mitigation.

Penetration Testing
Penetration Testing (Pen Testing), often called Ethical Hacking:
• Test if the vulnerabilities are exploitable.
• An authorized simulated attack on our organization looks for security weaknesses, potentially gaining
access to the systems, buildings, and data.
• It is very important to have very clear rules of engagement defined in a SOW (Statement Of Work).
• Which IP ranges, time frame, tools, POC, how to test, what to test, …
• Our legal team is involved in hiring Pen Testers; even if we allow it, it may still be illegal.
• Senior management set the goals for the Pen testing.
• Why are we doing it? What are we trying to achieve? They must sign off on it.
• If we are the pen testers, we are there to test and document the vulnerabilities, not to fix them.
• We report to senior management, and they decide the vulnerabilities we want to address.
• It uses multiple attack vectors; pen-testing uses an iterative process, like Agile project planning.
• Discovery (planning): Finding the vulnerabilities; designing the attacks.
• Gaining Access: Access the network.
• Escalate Privileges: Get higher-level access; ultimately, we want admin access.
• System Browsing: Gain additional access, often back to discovery with our new knowledge and access.

https://thorteaches.com/
4
 Thor’s Quick Sheets – CISSP® Domain 6
• Install Additional tools: With our elevated access, we can install more tools, exploit new attack surfaces,
and go back to Gaining Access.
• Finally, when done, they report the findings.
• Planning > Reconnaissance > Scanning (enumeration) > Vulnerability Assessment > Exploitation > Reporting.
• A Pentester has a very clear SOW, and they do not compromise the system and data integrity.
• The Pentester may not be allowed to access certain files (PII/PHI), but a dummy file is created in the same
location; if the Pentester can get to the target file, they could get to the actual data file.
• The Pen testing is done in clearly defined time windows, often in maintenance windows after hours; the
point is to prove we are vulnerable, not disrupt our business.
• Some can also do low-impact Pen tests on DR environments not to affect our live environments; they are
often less useful since most DR environments are not a mirror copy of the production environment.
Black Box Pen Testing (Zero-Knowledge): The attacker had no knowledge about the organization other than
publicly available information. They start from the point an external attacker would.
White (Crystal/Clear) Box Pen testing (Full Knowledge): The attacker has knowledge of the internal network
and access to it like a privileged employee would. Normally, administrators access employees with full
knowledge of our environment.
Gray (Grey) Box Pen Testing (Partial Knowledge): The attacker has limited knowledge, a normal user, vendor,
or someone with limited environment knowledge.
Breach and Attack Simulation (BAS): Automated tools simulating complex cyberattacks on-demand across all
attack vectors. Combine red and blue team approaches (purple teaming), automate it, and provide us with
continuous coverage with breach and assault platforms. They can be running 24/7/365, giving us much more
in-depth visibility into the real state of our defense readiness. Breach simulation is used to simulate attacks on
endpoints (malware), data exfiltration, malware attacks, APT attacks that move laterally through a network,
targeting the most valuable assets.
Compliance Checks: Security controls we put in place sufficient to ensure compliance with the regulations that
our organization must follow? (PCI-DSS, HIPAA, SOC2, and so on). Audits can be part of it, but they are a point-
in-time event, whereas compliance checks are ongoing, and compliance should be the beginning of our risk
management program. Think like an attacker would start with the easiest attack first, the users. Low technical
tools can be just as effective as sophisticated tools. Many organizations have strong perimeter defense but no
defense-in-depth; once you get past 1 or 2 barriers, you can access most things.
Social Engineering uses people skills to bypass security controls.
• Used in combination with many other attacks, especially client-side attacks, or physical tests.
• Attacks are often more successful if they use one or more of these approaches:
• Authority (someone you trust/are afraid of): Look and sound like an authority figure, be in charge
(in a uniform or a suit). Most effective with impersonation, whaling, and vishing attacks.
• Intimidation (If you don't do what they say bad thing happen): Virus on the network, credit card
compromised, a lawsuit against your company; intimidation is most effective with impersonation
and vishing.
• Consensus (Following the crowd, everyone else was doing it): Fake reviews on a website, using
consensus/social proof is most effective with Trojans and hoaxes.
• Scarcity (If you don't act now, it is too late): New iPhone out, only 200 available; often effective
with phishing and Trojan attacks.

https://thorteaches.com/
5
 Thor’s Quick Sheets – CISSP® Domain 6
• Urgency (It must happen now or else): The company will be sued for $1,000,000 if these papers
are not filled out before Friday; often used for Phishing.
• Attacks are often more successful if they use one or more of these approaches:
• Familiarity (Have a common ground or build it): Knowing something about the victim ahead of
time and then referencing it can drastically raise the chances of a successful attack. People want
to be helpful; they want to even more if they feel like they know you. Often successful with
vishing and in-person social engineering.
War Dialing: Uses modem to dial a series of phone numbers, looking for an answering modem carrier tone;
the penetration tester then attempts to access the answering system. Not done anymore but know it for the
exam.
War Driving (access point mapping): Driving or walking around, mapping access points, and trying to gain
access to them.
Network Attacks: Client-side attacks, server-side attacks, or Web application attacks.
Wireless Tests: Evaluate the risk related to potential access to your wireless network. It uses the password
combination & sniffing technique for cracking unsecured wireless networks, so a proper setup is required for
making the whole process semi-automated and automated.
Penetration Testing Tools and Methodology: Like hackers, Pentesters use many different tools to test, both
published tools and their own creations. Be VERY careful if testing these out, do not use them outside your
own network, and only on internal networks with written permission.
• Penetration Testing Tools:
• Open source Metasploit: http://www.metasploit.org/
• Closed source Core Impact: http://www.coresecurity.com/
• Immunity Canvas: http://www.immunitysec.com/
• Top 125 Network Security Tools: http://sectools.org/
• Kali Linux: https://www.kali.org/
Semi Real-Time Attack Maps: https://cybermap.kaspersky.com, https://www.digitalattackmap.com
Exception Handling: An exception is raised or thrown when an application encounters an error (programming
error, division by zero, invalid argument, creating an object when the system is out of memory, and so on). By
default, most applications would terminate, but an exception handler can stop that.
Ethical Disclosure:
• As IT Security professionals, we need to act ethically and disclose unknown vulnerabilities discovered
during security testing.
• We'd most likely put in place compensating controls to address the vulnerability.
• We'd notify the vendor, giving them time to create a patch or other form of fix (white hat).
• If they do not act, we may disclose it to a larger audience; however, this raises security concerns now
that attackers are aware of the vulnerability — they can attack before others have applied to
compensate controls or repair.

https://thorteaches.com/
6
 Thor’s Quick Sheets – CISSP® Domain 6
Software Testing
Software Testing: We have built functional and tested software just for stability and functionality; security has
been an afterthought if considered at all; software needs to be designed securely; normal software can have
millions of lines of code, and about 1% of that contains vulnerabilities.
• Static Testing: Passively testing the code, it is not running; walkthroughs, syntax checking, and code
reviews; look at the raw source code itself looking for evidence of known insecure practices, functions,
libraries, or other characteristics having been used in the source code.
• Dynamic Testing: Actively testing the code while executing it; can uncover implementation flaws and
code interaction that static analysis missed; software can run and execute with flaws.
• Code testing uses white and black box terms, just like pentesting.
• White Box Software Testing: The tester has full access to program source code, data structures,...
• Black Box Software Testing: The tester has no details, just the software; they then test for
functionality and security flaws.
• TM/RTM (Requirements Traceability Matrix): Normally, a table is used to map customer requirements to
the testing plan using a many-to-many relationship comparison. A requirements traceability matrix may be
used to check if the current project requirements are being met and help create a request for proposal,
software requirements specification, various deliverable documents, and project plan tasks.
Software Testing Levels:
• Unit Testing: Tests that verify the functionality of a specific section of code; this is usually at the class level
in an object-oriented environment, and the minimal unit tests include the constructors and destructors;
usually written by developers as they work on code (white-box), to ensure that the specific function is
working as expected.
• Integration Testing: Seeks to verify the interfaces between components against a software design; works to
expose defects in the interfaces and interaction between integrated components/modules; progressively
larger groups of software components are tested until the software works as a system.
• Component Interface Testing: Testing can be used to check the handling of data passed between various
units or subsystem components beyond full integration testing between those units; tests a completely
integrated system to verify that the system meets its requirements.
• Operational Acceptance: Used to conduct operational readiness (pre-release) of a product, service, or
system as part of a quality management system.
Software Testing Types:
• Installation Testing: The software installs correctly and works on the customer's hardware.
• Regression Testing: Finding defects after a major code change has occurred; looking for software
regressions as degraded or lost features, including old bugs that have come back.
• Fuzzing (Fuzz Testing): Testing that provides many different inputs to try to cause unauthorized access for
the application to enter an unpredictable state/crash; if the program crashes or hangs, the fuzz test fails;
the Fuzz tester can enter values into the script or use pre-compiled random or specific values.
• Mutating fuzzing: The tester analyses real info and modifies it iteratively.

https://thorteaches.com/
7
 Thor’s Quick Sheets – CISSP® Domain 6
• All-Pairs Testing (Pairwise Testing): All-Pairs Testing is defined as a black-box test design technique in
which test cases are designed to execute all possible discrete combinations of each pair of input
parameters; the most common bugs in a program are generally triggered by either a single input parameter
or an interaction between pairs of parameters; it uses carefully chosen test vectors, this can be done much
faster than an exhaustive search of all combinations of all parameters by parallelizing the tests of
parameter pairs.
• Misuse Case Testing: Executing a malicious act against a system, attackers won't do what normal users
would; we need to test misuse to ensure our application or software is safe.
• Test Coverage Analysis: Identifies how much of the code was tested with the entire application; to ensure
there are no significant gaps where a lack of testing could allow for bugs or security issues to be present
that otherwise should have been discovered; with 50+ millions line of code in a Windows OS, often spot
checks on critical areas are only enforced.
• After we have completed our tests, like on our log reviews, we need to use it and analyze the data we got
from the testing.
• It can be huge amounts of data, and we need to prioritize what we act on first, what is acceptable, and
what is not.
• Think of the qualitative risk analysis; if it is a low likelihood and low impact, we may leave it alone and focus
on higher priority items.

https://thorteaches.com/
8