Control assessments are done using various methods and tools, and must be performed in a consistent, structured and repeatable manner. The tools and methods must be appropriate for the scope of work. The following topics are presented in the CBK for required understanding.
Security assessment policy establishes the organization’s expectations for planning, conducting and reporting the results of assessments. The policy should include changes in context of the assessment since the previous assessment. The context has three elements:
• Threat landscape
• Business logic
• Compliance regime requirements
Scoping – before the assessment is conducted, scoping needs to occur. Remember the phrase “Scoping is Subtracting”? This should help you in Domain 6 as well, since scoping would be removing controls that are no longer applicable to the assessment.
Tailoring – should also occur. Remember the phrase “Tailoring is Tuning”? This applies to assessments as well, in the context of inputting specific settings or thresholds that must be met, for example having a minimum encryption strength for data in transit. This is directed by the changing and updated requirements and standards being used for the assessment.
Need-to-know is critical in maintaining confidentiality during and after the assessment – scoping and tailoring will help establish the assessor’s needed levels of access.
Sampling – this can be either random or judgment-based.
Statistical sampling uses laws of probability to measure the performance of a control.
Judgment sampling uses the professional expertise of the assessor to determine the systems or events to be examined, or those that have the greatest risk.
Examination has a few approaches:
• Artifact examination – is useful for administrative controls, such as policies and procedures or system specifications, where the assessor simply needs to look at the documents, make sure they are current, and determine whether they meet the expected criteria.
• Observation – is useful for activities such as badge wearing, training of employees, backup or system maintenance activities. Reviewing documentation of control performance such as facility access logs can help substantiate any findings or prevent the issuance of findings.
Interviews help identify the difference between business practices and organizational expectations. The interview subjects for an assessment should be identified (by role) in the chartering process and explicitly named (by name) in the pre-audit checklist. Interviews must be documented, and tools such as VOIP or videoconferencing can be considered along with recording the interview, however subjects should be notified if they are being recorded, and in some areas the law requires their permission.
Testing compares a system’s actual behavior with expected behavior. A successful test documents that the expected and actual behavior are consistent. If they are not, the test documentation should reflect the difference. The expected outcome should be determined beforehand.
Compliance test as mentioned earlier, determines if, in the opinion of the assessor, the control exists and is operating properly. If the control requires an effective onboarding/offboarding process, for a compliance test the assessor might examine a list of authorized users (via personnel file or management) against a list of system users with those permissions.
Substantive test evaluates the proper operation of a process. In our prior example, if the assessor were to conduct a substantive test, the assessor would document the actual onboarding and offboarding of an employee through observance or examination of log artifacts to ensure that the user was properly added, permissions assigned, and that the account and permissions were removed timely. Substantive tests provide better assurance but are more expensive.
Vulnerability Assessments examine a system’s security by looking for weaknesses due to unpatched software, firmware, or configurations.
Ethical Penetration Test – simulates the actions of a threat actor. It requires clearly defined Rules of Engagement (RoE) that specify the limits of liability for the penetration testers. A contract is necessary so that testers are not in violation of criminal and civil laws. Testers can be held liable for operational disruptions as well. Ethical penetration testing is different than ethical hacking, which includes amateur and professional security researchers that probe, explore, reverse engineer or otherwise try to find vulnerabilities in software systems and products. Some companies have bug bounty programs, where they encourage hacking into their products and systems. This style of hacking is ethical in the sense that the hacker abides by the terms and conditions of the bug bounty program and in particular does not disclose the results of testing to any person other than the owners of the systems. Ethical pentests can include both a Blind test, where the tester has no knowledge of the organization, and a Double-Blind test, where neither the tester nor the organization has knowledge of the test (with the exception of approving management).
ISC2 indicates that ethical pentesting has the following basic methodology:
Chartering
This is where the ROE is defined and a risk assessment is done for the pentest. RoE is incorporated into the contract and defines the individuals in the organization who can authorize the test.
Discovery
Consistent with the RoE, the testers define the potential breadth of the environment. Note this is an administrative process that is done prior to testing activities (it identifies what is to be tested). If the ROE already defines the systems and areas in scope, this part of discovery is not needed.
Scanning
Once a system has been identified as being within scope, it will be scanned to identify any potential weaknesses. The weaknesses will be further researched to fully “fingerprint” the system so that exploits can be properly identified and carried out.
Exploitation
This is where the exploit is delivered, and the compromise is documented. The tester must adhere to the ROE since the penetration test itself may provide an opportunity for real damage. In concluding the exploit, the tester is responsible to ensure that the potential for further damage is not caused by the exploit.
Reporting
The activities are compiled with special attention to the results of the penetration test. An executive summary is prepared that addresses any recommendations to mitigate the exploited weaknesses. All materials related to the test are returned to the client, which includes any credentials obtained during the course of the test.
Synthetic Performance Monitoring (or Proactive Monitoring) – this is where external agents run scripted transactions that resemble a user on a web application. The benefits of synthetic monitoring are:
- Monitors the application’s availability continuously
- Monitors the database availability continuously
- Ensure that service level agreements are met
- Can be used to create a baseline of performance trends
- Service-level agreement validation: A scripted process can measure aspects of availability (e.g. authentication) to document whether service levels are being met.
Types:
- Website monitoring – monitors availability
- Database monitoring – monitors availability
- TCP port monitoring – monitors availability and can be specific to server and TCP port
Finally we come to Remediation, which is applicable to any audit, test, or assessment. Remediation is how things are fixed.
Exception Handling – if remediation does not reduce the risk sufficiently, the control must either be improved (hardened) or an exception must be documented to reflect that risk tolerance has changed. Control hardening (also any risk reduction activities) and any exceptions/acceptance of risk must go through the change management process so that proper authorizations and testing/documentation can occur.
Continual process improvement, or CPI models are important to enable organizations for change activities.
The plan-do-check-act or PDCA cycle, is popular, and often referred to as the Shewhart or Deming cycle. This simple approach breaks down the process improvement into four steps.
Plan. Decide what needs to be done, establish the objectives, and determine the processes needed to implement the change.
Do. Execute the plan.
Check. Evaluate the results of the plan. This may happen through the use of statistical measures of performance, observations or evaluations.
Act or adjust. Based on the information generated in the do and check phases, root causes of failure are identified. Risk is re-evaluated and the baseline is determined to measure performance of future changes. Then the process begins again with plan.
Click here for more information on PDCA.
Six sigma is also a popular approach. First, define the problem. Second, measure the process and collect performance data. Third, analyze the data relationships, causality, and root cause. Fourth, improve the current process using the data and try out the new and improved process. Fifth, control the future state process to eliminate any deviations before they can result in defects and implement control systems that continuously monitor the process. Tailoring the process is important because there isn’t a one-size-fits-all approach to CPI.
Here are a few methods of Continuous Full-Cycle Testing for the purpose of assessing controls from the perspective of continuous monitoring, or from the perspective that some assessments, such as penetration testing, represent a point in time and findings can become outdated.
Breach attack simulation tools automate the testing activities so that they can be performed continuously on the organization’s infrastructure. When combined with threat intelligence information and change management activities, breach attack simulation tools can provide a different level of assurance than traditional penetration testing.
Chaos engineering forces production systems to fail, and then tracks the detection, incident response and recovery activities. The internal response groups are not told in advance (blind test?) and treat the failure as if it were an actual attack, not a simulation. Keep in mind that real shut-downs may be costly, and do not represent a true attack (because they are designed internally).