Security Assessment and Testing: A CISSP MindMap Exploration

Introduction

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.

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. As a security function, we must clearly understand the goals and objectives 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.

Validation

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 sub-divide 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.

SSH

And SSH, Secure Shell protocol which operates at layer 7, the application layer.

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.

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

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

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.

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.

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

Who can perform this testing?

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.

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.

Overview

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!