Measuring Security

If we want to understand how well something performs, we need some way of testing it.

Security is no exception, while we might be able to slap together a bunch of individually "secure" technologies to make a product¹, the interaction between these systems is complex. Even if the individual technologies are "secure", an error in the way they are configured, or a logical issue in the way we handle information could cause a security flaw. We therefore need a way to evaluate the security of the service as a whole.

How do we know something is Secure?

For normal² users, it often comes down to trusting the application developers to do their job. We can often see statements about the security of a website, like the one I found on a webstore⁴, shown below.

How do we protect your Data?

We use state-of-the-art encryption technology to protect your credit card/personal information. You can place your order(s) using Secure Socket Layer (SSL) encryption.

Digital certificates encrypt data using SSL technology, which is the industry-standard method for protecting Web communications. The SSL security protocol provides data encryption, server authentication, message integrity and optional client authentication for a TCP/IP connection. Because SSL is built into all major browsers and Web servers, simply installing a digital certificate turns on their SSL capabilities.

SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the "session key"; generated by every encrypted transaction. The longer the key, the more difficult it is to break the encryption code. We use 128-bit encryption. Most browsers support 128-bit SSL sessions, which is trillions of times stronger than 40-bit sessions.

Its great to see that the site has measures in place to protect our data. SSL is the current standard for encrypting data across the web, but does that mean the site is secure?

The communications with the server almost certainly are⁵, meaning that the data sent between the client and the server is secure from eavesdropping. The rest of the functionality on the site however, is untested. Perhaps the payment facility has a flaw⁶, or there is SQL injection in the store itself.

We can draw a comparison between a measuring security, and running a set of unit tests on our programs⁷ when we are developing code. We have a set of tasks that we want the code to perform, and a set of expected responses to input.
If the program responds to our tests with the correct output, we know that the code is correct⁸.

If we look at measuring security as a whole, we can see that there are three main strategies:

The High level Security Audit.

A high level security audit gives us a way to systematically evaluate the security of a system. It gives us a way of measuring the performance of the system against a set of pre-defined criteria, and is normally used to confirm the that an organisation deals with data meets some accreditation standard (for example ISO27001⁹)

Audits tends to be a pen and paper exercise, looking at identifying risks the the system and how they are addressed. The audit will also cover processes in the organisation, to determine if they meet with legal and regulatory requirements

An audit will cover all 3 pillars of cyber security, and the CIA Triangle and can include evaluation of:

Network Infrastructure Looking for weaknesses in networking, such as the confidentiality of data in transit. This will include things like adequate logging and monitoring, as well as network availability
Security Controls, examines the security policies of an organisation and how well they have been implemented. This stage may also cover the people elements, looking at training around security policies
Software Systems how the software used by the organisation effects security. This can include things like patch management, and the use of legacy software.
Information Storage and Processing ensuring that data held by the organisation is stored securely, and is processed in line with regulations
Processes and Procedures internal processes that are linked to security, such as password policy, user account policy etc.

Audits give us one way of looking at an organisations security profile.
By focusing on the procedures and processes they give us a way to identify and manage risk. They also allow us to see if a organisation is meeting regulatory and legal requirements. The are also great at helping is identify procedural problems, like shared accounts for admin users, or common passwords for databases.

However, they do leave a gap in our knowledge, as they only test the design rather than the implementation. While the risk assessment may say "We will not use vulnerable software", we also need some way of ensuring that this is the case.

Vulnerability Scanning

Vulnerability scanning tools such as Nessus, or OpenVAS are often used to identify common vulnerabilities in a systems configuration. Scanning the applications used in a network, and checking that the relevant security settings and patches are applied.

This gives us a reasonably quick and efficient way to check whether the systems used suffer from known vulnerabilities, and allow us to address any problems that are detected.
It also lets us put an automated scanning schedule in place, meaning we can schedule periodic checks for new flaws in the system.

The image below shows the output of a scan from Nessus

Nessus Scan

However, there are drawbacks.
While scanning can help identify issues, and is often an early stage in a pen-test, it is only able to spot known problems. Scanning have a problem with "False Positives" In the scan above we can see that there are several issues identified with the Jenkins build system. However the issues identified cover several version of Jenkins, so may not all be relevant. Therefore, further investigation is needed to check if the correct patches have been applied. (I assume this is because Nessus was unable to determine the version of Jenkins)

Scanning tools are great are great at spotting configuration problems, but logical issues in the way the deployed programs are implemented can mean that vulnerabilities are missed. While they have a place in any security audit process, relying on the results of the scan alone can leave a gap in our audit.

Note

Although not directly related to a security audit, we should also mention monitoring and measuerment here.

Systems like IDS (intrusion detection systems) and SIEM (Security information and event management), monitor network traffic and processes looking for suspicious behaviour.

This can allow us to detect and respond to cyber attacks that are in progress, or pick up signs that a cyber attack may happen.

While we don't have time to go into detail in this module, the whole SOC world is fascinating branch of cyber security, and well worth looking into.

The Penetration Test

The problem with the above methods is they can only test for issues we know about:

A security Audit lets us know if our procedures and processes meet a standard for security, and identify areas that need improvement.
Vulnerability scanning lets us test for known issues in the software in infrastructure we use.

However, both of these approaches leave a gap in our knowledge around implementation.

To Quote Donald Rumsfeld:

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones ¹⁰

Penetration testing helps us to find these unknown unknowns, by performing a simulated attack on the system. By Taking a manual approach to testing, that is closer to the approach taken by real attackers, and examining how the systems react to inputs we get a much clearer idea of any flaws in the security. A pen test should take a much deeper look at the system as a whole than vulnerability scanning, and removes some of the issues around missed items or false positives.

There can are limitations to a pen-test:

It will only cover targets that have been defined in the scope of the test. For example:
- May only forward facing (web) services
- May not examine human factors
- Could be limited by legal factors.
They only provide a snapshot of the system at a point in time. Changes to the system would require another test.
May not find all security weaknesses, due to limited scope or inadequate testing.
While it may cover social engineering, often the people elements of security are not considered. This can include other ways that information can lean from an organisation, such as poor policy on USB drives, or BYOD.

However, regardless of these limitations, a properly specified pen test gives us the best indication of whether software and systems on our infrastructure is secure.

Summary

In this article we have looked at three common strategies for assessing the security of a service.

Each of the approaches addresses a separate element of security.

Audit, can help us identify issues an organisations procedures and processes.
Vulnerability Scanning, can help us identify software, or configuration problems in common applications
Pen Testing gives us an in-depth look at the security of a particular element.

While each of them are valuable, by combining all three approaches, we get a much stronger idea of how secure our systems are.

In the next article we will look at a generic pen-testing process.

Measuring Security

The High level Security Audit.

Vulnerability Scanning

The Penetration Test

Summary

Further Reading