top of page

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 -

  • 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

Featured Posts
Recent Posts
bottom of page