It’s common to hear people talk about “security testing” as if it is a singular, monolithic thing.
If you actually do security testing, you know that’s not true. There are a variety of different types of security tests. They are achieved using different tools and processes, and they reveal different types of insights.
Security tests are also constantly evolving. A list of the most common types of security tests from five or ten years ago would not be the same as today.
With these facts in mind, let’s break down security testing into its constituent parts by discussing the different types of security tests that you might perform today. This article won’t cover every type of software security test ever performed, but we’ll discuss the major ones.
Static code analysis
Static code analysis is perhaps the first type of security testing that most people think of, probably because it is one of the oldest forms of security test (and was one of the only important types of tests before the advent of cloud computing made security much more complicated).
Static code analysis involves reviewing source code to identify problems that could lead to security breaches in an application (or in resources to which the application has access). Classic examples of vulnerabilities that you might be looking out for using this type of analysis are coding flaws that could enable buffer overflows or injection attacks.
It’s possible to perform some amount of static code analysis by hand, meaning that developers read through code manually to find security flaws. But that is often not practical to do on a large scale, given the size of many source code files; plus, humans can easily overlook flaws. That’s why using automated analysis tools to scan your source code is important.
Penetration tests involve simulating attacks against an application or infrastructure in order to identify weak points. For example, you could use a tool like nmap to attempt to connect to all endpoints on a network from a non-trusted host and see if any endpoints accept the connection; if they do, you probably want to make them stop accepting connections from arbitrary hosts.
Some folks might argue that penetration testing should be broken down into subcategories, since there are different types of penetration tests. Some focus on the network, some on applications, some on authentication gateways, some on databases, and so on.
Compliance tests (which are sometimes called conformance tests) are used to assess whether a configuration, architecture or process meets an organization’s predefined policies. Compliance testing is not strictly limited to the realm of security; you could conceivably use compliance tests to help maintain standards for application performance or response time, for example.
However, when it comes to security, compliance tests are an important resource for ensuring that a given application’s configuration or deployment architecture meets minimum standards set by your organization. Compliance tests typically work by comparing actual configurations with those that are deemed to be safe. When the tests identify incongruity, admins know that there may be a security issue or other problem.
For the record, compliance tests shouldn’t be confused with tests performed to ensure that your organization meets requirements defined by regulatory compliance frameworks — meaning those set by the government, such as HIPAA or PCI DSS. Compliance tests simply mean tests that help you identify nonconformance with predefined policies or best practices. They could help meet regulatory compliance requirements, but they do much more than that.
Load testing refers to tests that measure how an application or infrastructure performs under heavy demand. Load testing is not often thought of as a type of security test; it’s more commonly used to help optimize application performance and availability.
However, there is a reason why security admins might want to pay attention to load testing results, too. That reason is Distributed-Denial-of-Service, or DDoS, attacks, which aim to disrupt application availability by overwhelming an application or its host infrastructure with traffic or other requests.
Load tests can help an organization determine what level of abuse from DDoS attackers an environment can tolerate before the DDoS attack succeeds in making it unavailable.
Origin analysis testing
As the popularity of open source software has grown over the past decade, so has the importance of origin analysis testing. This type of testing helps developers and security admins determine where a given piece of source code originated.
In cases where some of your source code came from a third-party project or repository — which is very common these days, given the ease with which developers can incorporate upstream open source code into their applications — security admins will need to make sure that any known vulnerabilities in that code are addressed, and that the code conforms to internal security standards. (There are also often licensing considerations at play, since you need to make sure that you remain in conformance with the licenses of any third-party code that you incorporate into your own application.)
A growing number of tools are now available for scanning source code to perform origin analysis testing.
Again, this isn’t a comprehensive, exhaustive list of security tests. There are other types of tests that you might want to consider as part of your security strategy. But the tests described above are mainstays for helping to thwart the security threats of the cloud-native era.
- Application Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Key Differences in Security, Management for Serverless vs. ContainersRead the Blog
Docker vs. KubernetesRead the Blog
How Cloud Workload Protection is Different than Application SecurityRead the Blog
Zero-Trust Security: What It Means and How to Achieve ItRead the Blog
Service Mesh. Service Fabric. Service Bus. What Does It All Mean?!Read the Blog