Security Assessment and Testing: A CISSP MindMap Exploration
Download FREE Audio Files of all the MindMaps
and a FREE Printable PDF of all the MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Transcript
Introduction
Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to Security Assessment and Testing in Domain 6, to understand how they interrelate, and to guide your studies.
This is the first of three videos for domain 6. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.
Our systems are becoming ever more complex, we are collecting more data, gathering more insights, rapidly making decisions, these systems are integral to the success of the business.
What then is the purpose of security assessment and testing?
To ensure that security requirements and controls are defined, tested, and operating effectively to support the business in achieving its goals and objectives.
In today’s world, no business is going to be successful if they don’t have systems that provide a sufficient degree of confidentiality, integrity and availability.
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
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.
Rigour
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 subdivide the development effort into different units.
Unit
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.
Interface
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.
Integration
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.
System
And finally, once all the units are completed, and we have done a bunch of integration testing, we can begin testing the whole system.
Testing Techniques
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
Manual is hands on keyboard. A person, manually reading code, or performing some action on a running program.
Automated
Automated implies the use of automated tools – software to test other software. For example code scanning tools, or vulnerability scanners.
Runtime
Runtime is all about whether the code is running or not.
Static
Static testing is testing a system that isn’t running. Static testing is looking at code.
Dynamic
Dynamic testing means the software is running so you are testing a running system.
Fuzz
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.
Mutation
Diving a little deeper into Fuzz testing, there are two types of Fuzzers you should be familiar with: Mutation Fuzzers are often referred to as dumb fuzzers as Mutation Fuzzers do not have any understanding of the input data they are fuzzing. Mutation Fuzzers just randomly mutate some input data to a system - with no understanding of the data structure.
Generation
Generation Fuzzers are often referred to as Intelligent Fuzzers as they have a basic understanding of the type and structure of input expected by a system and, therefore, a Generation Fuzzer can generate new chaotic input.
Access to Code
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
White-box means you have access to the source code for your testing.
Black
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.
Techniques
There are many techniques we can employ in software testing. To name a few of the key ones:
Positive
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
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
Misuse testing is abusing the system as an attacker might. Testing for buffer overflows, SQL injection vulnerabilities, and that sort of thing.
Decision table analysis
Decision table analysis is a software testing technique used to test system behavior for different input combinations. Essentially you create a table that lists all the different input combinations and their corresponding expected behavior and this allows you to check all possible combinations and make sure you don’t miss anything - even in a complex application.
Decision table analysis is particularly useful for testing complex software & requirements management.
State-based analysis
State-based analysis is a testing technique that is particularly useful for testing software that can exist in different abstract states. State-based analysis is particularly useful for testing software such as GUIs and communications protocols like TCP.
Efficiency
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. Put more simply, you identify where there are changes of behavior – you call this a boundary – and then you focus your testing on either side of the boundary. And a more official technical definition is the Test cases cover the extreme ends of the input values.
Equivalence Partitioning
In Equivalence Partitioning, inputs are divided (partitioned) into groups which exhibit the same behavior. Test cases are then written to cover each partition.
And here is a diagram to help you visualize the difference between these two techniques. If we are asking for a password length of 8 to 16 characters, then we have a boundary between 7 and 8 characters – 7 characters should be rejected and 8 characters should be accepted. And then another boundary between 16 and 17 characters. So in boundary value analysis, we would focus our testing on either side of this boundary. In equivalence partitioning, we identify the three partitions and then do some testing within each partition.
Operational
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
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
Internal implies a company’s own employees testing their own software.
External
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.
Third-Party
Third-party implies three parties are involved. The customer, the service provider, and the independent third-party auditor.
SOC 1
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
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!
Type 1
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
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.
SOC 3
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.
And here is a diagram depicting the three SOC reports and the Type 1 & Type 2
Roles
Now let’s talk about the different roles that may be involved in the audit and assurance function.
Executive Management
Executive management provide the tone from the top, and promote and fund the audit process.
Audit Committee
The audit committee is composed of members of the board and senior stakeholders who provide oversight of the audit program.
Security Officer
The security officer advises on security related risks to be evaluated in the audit program
Compliance Manager
The compliance Manager, manages the compliance program to ensure corporate compliance with applicable laws and regulations, professional standards, and company policy.
Internal Auditors
Internal Auditors are company employees who provide assurance that corporate controls are operating effectively.
External Auditors
External auditors provide unbiased and independent assurance as they are independent of the entity being audited.
Metrics
As part of security assessment and testing, it is important to define metrics. To measure what matters.
Focus
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.
KPIs
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
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 you need to know for the exam.
A cool feature we recently added to our currently FREE CISSP app is a simple personalized schedule. Just enter in the app when you plan to start studying and when you plan to take the exam, and the app will automatically tell you how many practice questions and flashcards you should study each day - and makes it easy to track your progress. It’s a simplistic version of the advanced personalized schedule from our CISSP MasterClass.
Links to download our currently free CISSP app are in the description below.
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!
