The article discusses penetration testing – methods to identify and patch vulnerabilities in an organization's systems and how technology has evolved to make in depth white box penetration testing possible.
The article discusses penetration testing – methods to identify and patch vulnerabilities in an organization's systems. There are three types of penetration tests: black-box (minimal info given), grey-box (limited info), and white-box (detailed info). White-box is comprehensive but historically harder to automate.
Technology changes have made white-box testing more feasible. Cloud, containers, and IaC advancements enable automated white-box testing. CoGuard aims to automate white-box testing by scanning configuration files for security issues and vulnerabilities across clusters, networks, and cloud services.
Most people, even developers, asked out of the blue, are able to give vague answers at best. Yet, it seems to be the first answer that comes to mind when someone is asked “What are you doing for the security of your web app?”.
The purpose of penetration testing is to identify and patch the vulnerabilities that would be exploited by an attacker. Penetration testing is a controlled and systematic simulation of real-world cyberattacks on an organization’s systems, networks and applications. The objective is to find and exploit weaknesses and vulnerabilities.
But not all penetration tests are equal in their effectiveness, comprehensiveness or pricing.
There are three main types of penetration tests, each with a different purpose, risks and motivations.
The main difference between the types of penetration testing is the amount of information given to the tester and this changes the scope, budget and time. Black-box testing is where the attacker is given no information or credentials about the systems being tested. White-box testing provides detailed information about the system, applications, network and configurations allowing for the identification and assessment of potential vulnerabilities. Gray-box testing uses a limited amount of information and allows for tests that can strike a balance and test for access privileges between distinct user groups.
(We’re going to conveniently ignore grey-box testing, because it uses a combination of black-box and white-box testing that limits the information shared with the penetration tester).
Ideally, both white-box and black-box approaches should be tried (this is the approach recommended in NIST SP 800-53 (Rev. 5)).
The black-box approach is widely accepted as the standard for penetration testing. It requires no knowledge of the respective servers and systems except their IP addresses and DNS entries. This allows a black-box penetration test to be done quickly with automated tools and very little information to produce meaningful results depending on the security posture of the company.
Historically, white-box penetration testing has been much more difficult to automate and required significantly more time and people resources than a black-box approach. White-box penetration testing required the collection of meta-data and configuration settings for all of the network, application and compute servers for an organization. This information was used to assess the quality of the security posture and identify potential vulnerabilities. In some cases, it was required to connect to each server to extract configuration data and support a multitude of different routing/firewall solutions and operating systems.
The costs and effort of white-box penetration testing often limited the approach to customers where the security of the system or software was critical. For example, when deploying an application with critical customer data such as banking or health care applications, or building software for vehicles (UAVs, military transportation, airplanes, etc.) when the consequences have dire consequences. These situations have no room for vulnerabilities internal or external. And the investment in comprehensive test to ensure every aspect of the system is reasonable. Software has become more critical to companies, and the this requires making comprehensive approaches more accessible.
From a complexity perspective, thorough black box testing is exponential and at a certain size not feasible. In order to verify all possible security hole possibilities using trial and error can equate to checking all branches of a binary search tree. The benefits of a white-box approach are the breadth of the assessment and vulnerability identified.
For example, white-box assessments include:
Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has. - Margaret Mead
We’ve come a long way baby. The conversation around security and IT has evolved. We don’t talk about IT in isolation, we talk about DevSecOps. This change has been enabled by changes in the technology. The adoption of cloud technologies have provided new ways of thinking about and working with the technology. The cloud has endpoints to enumerate the used resources. The most common services used by developers have become a dedicated managed cloud service (think AWS Dynamo for databases, or Prometheus for monitoring, etc.) with direct configuration parameters and integrated into the identity and access management (IAM).
The widespread adoption of Kubernetes and containers have propagated Infrastructure as Code (IaC). The benefits have spilled over to on-premise environments leading to hybrid and multi-cloud solutions. Containers and configuration management including Ansible playbooks are increasingly created, and allow for quick set up, common task execution and tear down. Network isolation is easily done using proper container orchestration. And authentication has moved to more straightforward OIDC solutions, with password rotation enabled by vault technologies. The benefits of automation of infrastructure are clear and it has led to IaC becoming standard.
Whitebox penetration testing is enabled by the underlying changes in technology adoption patterns. These changes allow additional security requirements across applications, like ensuring at most two authentication methods are employed: one auth process for humans and a separate process for inter-service communication. And to ensure that role-based access control (RBAC) is applied at every step of the way. It enables the separation of data from processing, and the creation of immutable processing units that are easily replaceable.
At CoGuard, we see a future where whitebox penetration testing can be automated. CoGuard is a static analysis engine for configuration files. The tooling provides a method to discover configuration files across clusters, networks, devices and applications. The configuration files are discovered in filesystems, infrastructure code repositories and in cloud configuration panels. The configurations may be written by your team, or they may be included as defaults provided with the containers, applications and tools used. CoGuard identifies a manifest of used configuration files and evaluate these against our rule engine that is comprised of security benchmarks (CIS Benchmarks, OWASP, DoD STiGs, etc.), known misconfigurations (software manuals), compliance frameworks (SOC2, HIPAA, ISO27001, etc.) and custom rankings (slashing, SLAs, etc.).
This provides CoGuard an adaptable framework for a variety of unique setups, technology stacks and configurations. We scan the respective configurations for best practices, misconfigurations, potential security breaches and known vulnerabilities. We embed in existing development and deployment tool chains allowing automation and integration into existing CI/CD pipelines.
To get started, create an account and install the CLI to identify configuration files in your repository or cloud infrastructure.
Install the CLI and start scanning.
The purpose of a penetration test is to identify and patch the vulnerabilities that would be exploited by an attacker. But this can mean different things to different people in different situations. The goal is to identify and patch security and configuration vulnerabilities that leave systems at risk to exploitation by attackers.
In most countries, there is no legal framework defining a penetration test. The UK Government Services team defines the CHECK framework plus a certification. The General Services Administration in the US is providing some aid, but most of the market is done by private companies. OWASP provides penetration testing methodologies and guidelines. NIST SP 800-53 (Rev. 5) suggest a common methodology using a pretest vulnerability scan (whitebox approach) coupled with an independent third party (blackbox approach) to test the exploitability of the discovered vulnerabilities. There are a number of independent certifications for penetration tests in the marketplace. Most notably the CompTIA Pentest+ and the CISSP penetration tests
However, is there one standard penetration test? See Sidebar 2.
The lack of a legal framework around what defines a “penetration test” means there are multiple attempts in creating a standard.
“The good thing about standards is that there are so many to choose from.” Andrew S. Tanenbaum
OWASP has collected a variety of different penetration testing frameworks on one page at the Web Security Testing Guides project. The frameworks vary in practicability and detail. It is to be especially noted here that the PTF references a lot of open source tools which administrators can use to perform an extensive self-assessment.
In fact, from the major compliance frameworks, only PCI DSS has that requirement, and it provides an overview of the expectations and checklists.
Let us go back to first principles and discuss what a penetration test was supposed to be for in the first place: A risk assessment with action items to reduce the risk. Not more, not less. To identify and patch the vulnerabilities that would be exploited by an attacker. It is good to have one, but there is no guarantee that everything important for your organization will be checked for.
