Security Assessment and Testing: A CISSP MindMap Exploration
To Download the FREE PDF of MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Hey, I’m Rob Witcher, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics in Domain 6, to understand how they interrelate, and to guide your studies and help you pass the CISSP exam.
This is the first of three videos for domain 6. I have included links to the other MindMap videos in the description below.
When should security become involved in testing?
Security assessment & testing covers the gathering and validation of business requirements, definition of controls, development of new applications and systems, the ongoing operation, and the eventual retirement and disposal of systems and data.
A good way to summarize this is that testing should be involved right from the start and throughout.
And a good exam hint is that if you are asked when security should become involved in testing, look for the earliest possible answer. If the dawn of time is an answer, it’s probably the right answer.
We’ll start this MindMap with Validation. Validation is all about gathering business requirements to truly understand what the business needs and validating those business requirements with the relevant stakeholders.
We cannot possibly perform any of the testing we are going to talk about if we don’t understand what the business needs.
Verification is all the testing we perform once we start building the product. We are verifying that controls are properly designed and baked into the system.
We can invest very little effort in testing, or we can invest a lot of effort. What drives us to perform more testing to have greater confidence that the system is working correctly? The value of the system to the organization. The more valuable the system, the more effort we will invest in testing to make sure the system is effectively supporting the business in achieving its goals and objectives.
Testing a System
Software is complex, and it is often built by teams of people. As such we can sub-divide the development effort into different units.
Unit testing is where we test the individual units of software as they are developed. To wildly oversimplify, for an operating system we might have a unit of software that is responsible for keyboard input, and another for mouse input, and another for video output. Unit testing would be testing each of these individual units separately.
Units of software need to communicate with each other. They communicate through standardized interfaces. Interface testing verifies that communication between two or more units is working correctly.
Once a few units are completed, we can begin integration testing. We are testing groups of units together to make sure they play nicely with each other
And finally, once all the units are completed, and we have done a bunch of integration testing, we can begin testing the whole system.
There are various techniques that we can apply to perform our testing. And note that these techniques can be mixed and matched together to perform different types of tests, they are not mutually exclusive.
Methods & Tools
There are two main methods we can use to perform testing
Manual is hands on keyboard. A person, manually reading code, or performing some action on a running program.
Automated implies the use of automated tools – software to test other software. For example code scanning tools, or vulnerability scanners.
Runtime is all about whether the code is running or not.
Static testing is testing a system that isn’t running. Static testing is looking at code
Dynamic testing means the software is running so you are testing a running system.
And SSH, Secure Shell protocol which operates at layer 7, the application layer.
Fuzz testing is a form of dynamic testing. It is essentially the idea that programmers are logical people. They expect logical input and provide logical output.
If you throw chaos at a system, massive amounts of random data, then you can identify all sorts of unexpected errors and vulnerabilities in the code.
Access to Code
As I’ve implied, some testing involves having access to the code, and in other tests, you don’t have access to the code, but rather the running system
White-box means you have access to the source code for your testing
Black-box means you can’t see the underlying source code. You are testing a running application and the internal workings are a black box to you.
There are many techniques we can employ in software testing. To name a few of the key ones:
Positive testing is verifying that a system works as expected. If you are testing a login mechanism, the positive testing would be verifying that a correct username and password allows you to login.
Negative testing is looking at normal and expected errors. In a login mechanism, you expect someone to enter the wrong password on occasion.
The negative testing would be verifying that an incorrect username and password is handled gracefully – the system says: have you forgotten your password, and doesn’t just crash.
Misuse testing is abusing the system as an attacker might. Testing for buffer overflows, SQL injection vulnerabilities, and that sort of thing
The next two techniques are all about making testing more efficient by reducing the number of tests required while still achieving a required level of confidence.
Boundary Value Analysis
In Boundary Value analysis testing is focused at the boundaries. Test cases cover the extreme ends of the input values.
In Equivalence Partitioning, inputs are divided (partitioned) into groups which exhibit the same behavior. Test cases are then written to cover each partition.
Operational is the testing we perform on systems that have been deployed and are in production
Real User Monitoring
Real User Monitoring, RUM, is monitoring the system usage of real users. Monitoring user transactions in real-time for usage, performance & errors
Synthetic Performance Monitoring
Synthetic Performance Monitoring is running scripted transactions to monitor functionality, availability and response times. Basically creating little bots or agents that simulate usage of a system.
Synthetic Performance Monitoring is a good way to do load or stress testing on a system.
Regression testing is performed after a change is made to a system to verify that previously tested software continues to perform correctly after a change
Testers / Assessors
Who can perform this testing?
Internal implies a company’s own employees testing their own software.
External implies a company hiring an independent external tester to test the company’s software. Or external can also mean a company sending their employees to test a service provider or vendor to test the services being provided.
Who can perform this testing?
The reports produced as part of a third-party audit are often SOC - Service Organization Controls Reports. A SOC 1 report focuses on financial reporting risks. As security professionals, SOC1 reports aren’t that interesting to us.
SOC 2 reports focus on the 5 trust principles: Security, Availability, Confidentiality, Processing Integrity, and Privacy. The 5 trust principles are most definitely of interest to us as security professionals!
Just to make things confusing, there are two types of SOC1 and SOC2 reports. A Type 1 report looks at the design of a control at a point in time.
Essentially reviewing some paperwork on a Monday.
Type 2 reports look at the design and operating effectiveness of a control, over a period of time – typically a year. The auditors are testing to see if a control was operating effectively over a whole year, through sampling and other methods. Type 2 reports are way more useful.
A SOC 3 report is a summarized and sanitized version of a SOC 2 for public distribution - basically a marketing tool. To sum it up, as security professionals we want SOC 2 Type 2 reports.
Now let’s talk about the different roles that may be involved in the audit and assurance function.
Executive management provide the tone from the top, and promote and fund the audit process
The audit committee is composed of members of the board and senior stakeholders who provide oversight of the audit program
The security officer advises on security related risks to be evaluated in the audit program
The compliance Manager, manages the compliance program to ensure corporate compliance with applicable laws and regulations, professional standards, and company policy
Internal Auditors are company employees who provide assurance that corporate controls are operating effectively
External auditors provide unbiased and independent assurance as they are independent of the entity being audited
As part of security assessment and testing, it is important to define metrics. To measure what matters
How do you decide what metrics to focus on? It should always be tied back to business goals and objectives. If you understand what the business is trying to achieve, you can create metrics that demonstrate if progress is being made in that direction.
Two specific types of metrics you can use are: KPIs and KRIs.
KPIs - Key Performance Indicators are Backward looking metrics. KPIs indicate the achievement of performance targets.
KRIs – Key Risk Indicators are forward looking metrics. They indicate the level of exposure to operational risk. They help to monitor potential future shifts in risk conditions or new emerging risks.
And that is an overview of security assessment and testing within Domain 6, covering the most critical concepts to know for the exam.
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!