CruSec’s 2019 CISSP Study Guide - Domain 6: Security Assessment and Testing
Domain 6: Security Assessment and Testing
6.1 Design and validate assessment, test and audit strategies
Spans many areas:
Policies/procedures and other admin controls
Change management – primary goal is to ensure changes don’t reduce security
pen tests
Vulnerability assessments
Security audits
6.2 Conduct security control testing
Security Audits
Formal, tested against a public standard or regulation such as PCI DSS
Can be structured (done by 3rd parties to validate compliance), or unstructured (internal audit to improve security and find flaws before an external audit).
Service Organization Control
Three tiers:
SOC 1 – service provider describes objectives/controls that impact financial info. Reports are limited in scope to financial reporting
SOC 1, Type 1 is used by auditors
SOC 2 – reports extend beyond just financial interest. Focuses on the CIA information as well as general security and privacy concerns
SOC 3 – short version of SOC 2. Omits detailed description of test controls and related results
6.3 Collect security process data
Log Reviews
Network Security Appliances and Applications
AV, IDS/IPS, VPN, web proxy, authentication servers, routers and firewalls
OS
System events and audit records
Applications
Client requests and server responses
Usage info
Significant operational actions
Log Audits
Typically faces five problems
Logs are not reviewed on a regular/timely basis
Audit logs and audit trails are not stored for long enough time period
Logs are not standardized across the variety of hardware/software creating them
Log entries and alerts are not prioritized
Audit records are only reviewed for the bad stuff
Centralized repository allows for more scalable security monitoring. Syslog (UDP 514) assists with this
Security Information and Event Management (SIEM) – is often the centralized logging server
6.4 Analyze test output and generate report
6.5 Conduct or facilitate security audits
Vulnerability Testing
Tools such as Nessus, Rapid 7, BeyondTrust, etc
Scans a network with authenticated scans and compares system configs to the CVE database to report on known vulnerabilities. It does not exploit them
Penetration Testing
Simulating attacks and exploiting vulnerabilities. The difference between pen testing and real attacks are intent
Need explicit permission of target organization
Make sure organization knows test will not stop until attack is fully carried out
Report should include:
Steps undertaken
Weaknesses identified
Recommendations
Test preparation:
Who will commission the test
Who will conduct?
How will it be conducted
What are the limitations?
What tools will be used?
Who on the client side will be available in case of an accident?
Pen testers have a very clear Statement of Work so they do not compromise system and data integrity. Pen tests should not have access to PII/PHI. Dummy files or flags can be placed in the same directory and testers can be allowed to get those files
Pen testing is done in a clearly defined time windows, often in maintenance windows after hours as to not disrupt business.
Process:
Recon - normally about 80-90% of the process is spent here. Often times you'll give pen testers information (gray/white box testing) so they don't have to spend so much time here. Black Box Testing is when the testers have no information and have to gather it from public sources/social engineering. White box testing might simulate a malicious administrator, while gray may simulate a regular malicious user
Scanning
Exploitation
Maintaining Access
Reporting
Tools:
Metasploit
nmap
Closed Source Core Impact
Immunity Canvas
Top 125 network security tools - sectools.org
Kali
Software Testing Methods
Done to make sure your homegrown apps are secure.
Two general approaches
Static - code is not running. Reviewing the source code for insecure practices and unsafe functions
Dynamic - performed while code is running.
Traceability Matrix - maps customer requirements to software testing plan
Synthetic Transactions - involves building scripts or tools that simulate activites normally performed in an app
Software testing types:
Unit – simple “pass/no pass” test for small piece of code? Does it work as intended – yes or no?
Integration – make sure all the different units of code work together
Interface - an integration test between two systems and the application. Basically looking at the GUI
Function – simulates a specific user interaction with the system to see its response and performance
System - tests a complete, integrated system that it satisfies the original specified requirements. Basically a function test on a real-word scale
Acceptance – end user tests it to see if they like it
Regression – same set of above tests whenever the application has been updated or changed to ensure the fix didn’t break anything
Misuse – identifies vulnerabilities and weaknesses by validating input that the app accepts, as well as any other ways that an attacker could exploit it
Fuzzing sends random bits of malformed data into software programs. This is a dynamic test. The basic purpose is to send unexpected input to the software.
Combinatorial Software Testing seeks to identify and test all unique combinations of software inputs. Tests pair of input (pairwise testing)
Misuse Case Testing tries to evaluate software from the perspective of an attacker. Examples could be deliberately leaving fields blank, or exceeding the allowed number of characters of input, fuzzing, attempting to open a web page without first performing a required login, entering illegal values or characters, etc
Test Coverage Analysis – focuses on how much logic/functionality of code has been tested, not the overall percentage of code. It is not always realistic to test every single line of code. Microsoft Office has millions of lines of code
