Organizations need vulnerability assessments – and here is why!
Organizations typically use a number of methods to establish and evaluate their security posture. The most popular legacy method is penetration testing. This post will provide a brief overview of penetration testing and, then, illustrate the challenges of this method in a cloud environment. It will also suggest how to effectively mitigate these issues through the use of cloud native vulnerability assessments to improve their security.
A penetration test, frequently referred to as a pentest, is an authorized cyberattack that tells organizations which parts of their system are exploitable.
There are three types of pentests, each conducted in a way that depends on the amount of information the pentester will collect and use through the engagement.
In a black-box penetration test, the pentester will have a perspective of an unauthenticated outside user. Without any information collected prior to the engagement, the pentester will continue to examine the functionalities of the target.
A white-box penetration test is performed from the inside of an organization with the pentester having access to internal information about targeted assets.
A gray-box penetration test aims for the balance between the black-box and the white-box pentest. Gray-box pentests are conducted with the pentester having access to internal information but acting somewhere in between the inside and outside perspective as an authenticated/logged-in outside user. This method enables the pentester to look at the target from different standpoints, ensuring more realistic testing scenarios.
While many enterprises conduct pentests, there are a number of factors that dilute the perceived advantages of this type of testing, especially when it comes as a by-product of a security breach; that is, when it is too late.
Let's take a look at the top tradeoffs that are rarely foreseen and that make penetration testing a less desirable security solution as well as introduce an alternative approach - vulnerability assessments.
Cloud Service Provider Limits on Penetration Testing
Amazon
When it comes to pentesting cloud databases, all included parties must be aware of their responsibilities as the effects of the pentest might be disruptive to the surrounding network.
Amazon, the biggest cloud service provider, follows a shared-responsibility model that makes it possible for each party to easily distinguish the layer of infrastructure and services for which they are responsible.
Amazon’s Shared Responsibility Model
While Amazon allows its customers to perform non-disruptive penetration tests against their own AWS infrastructure, the pentests can only be performed on a limited number of AWS services and AWS-defined policies and guidelines must be adhered to; a number of activities are prohibited and requests to carry out other simulated events must be pre-approved by Amazon.
|
Permitted Services |
Prohibited Activities |
|
|
The ownership of the different components of cloud infrastructure is very important in pentests, but not everyone remembers to take the rules of engagement into consideration. Moreover, when pentests have limited scope, the results are limited.
Penetration Tests Drain Resources
Costly Investments
Penetration testing companies differ in experience, tools, and the methodologies applied to a penetration test. A poorly executed pentest or insufficient reporting can do more harm than good by providing a false sense of security. Differences in attack posture and skill make it impossible to ensure nothing is missed. Here, quality comes with a price, and choosing less-experienced penetration testers may not guarantee results.
Additionally, pentests are a point in time snapshot. Because of this, businesses need to hire experienced penetration testers over and over again in order to conduct a pentest on every notable change within the organization and maintain their security posture. Such an approach is impractical, and even more, it would quickly drain the budget.
Loss of Productivity
Penetration tests require attention and intense work from both the pentester as well as the hiring company’s employees. In the case of a white-box pentest, the pentester moves employees away from their productive work to collect information such as API credentials, database credentials, architecture diagrams, or source code. After conducting a pentest, a pentester creates a report and shares it with the stakeholders who need to review it from their individual business function.
A typical pentest engagement phase requires the pentester to go through lengthy and time-consuming checklists, resulting in pentests lasting up to weeks or even months. Even if the pentester reports no exploited vulnerabilities, the engagement has at this point taken more than a considerable amount of time.
All of these processes are paid for with distractions and additional resources invested into the successful completion of the engagement. Making up for the lost productivity has its costs, especially considering the fact that each pentest's results are only valid until the next major change in the business of the tested company. Whether it's an asset or a process that is the subject of the change, it certainly adds to the overall exposure to vulnerabilities.
Penetration Tests Bring Unforeseen Risks
Service Disruption
A hidden danger of penetration tests is the potential for disruption of service as attacks are carried out. A pentest aims to test and exploit the functionalities of an asset. It is likely that at some point the availability of the asset will be disrupted regardless of whether it happened inadvertently or as part of a planned Denial-of-Service attack.
The nature of Denial-of-Service attacks can lead to downtime, whether caused by a flooding attack that overwhelms the target with illicit network traffic, or by a crash attack such as fuzzing. Downtime disables software developers from releasing new features and instantly overtakes the customer support line. Most damagingly, it enrages customers who are unable to access the service.
In the case of big cloud providers such as Amazon, using tools that hold the power of disruptive Denial-of-Service attacks is strictly forbidden unless the tools are used in a pre-approved pentest conducted by an AWS Partner Network Partner.
Bad Reputation
Another possible cause for service unavailability, with often-overlooked consequences, comes from the fact that penetration testing generates network traffic. In a shared-responsibility environment such as the cloud, both the upstream provider and the cloud service provider can detect that traffic, mark it as illicit, and blackhole it to avoid any damages to the rest of the network. Interestingly, this technique has proved in history that it can introduce very damaging large-scale effects on computer networks.
In a white-box pentest, the pentester might perform the attacks from company premises or through a company VPN, identifying himself with a single external IP address shared between the employees. Such an approach might result in cloud provider blacklisting that IP address and blocking the whole company from accessing their cloud resources.
Notifying the upstream provider about the suspicious traffic that is about to be introduced to their network honors the shared responsibility principle. Even though engaging in such correspondence is an operational cost, the real risk to the business is the fallout that comes from failing to proactively communicate about the pentest.
Security Gaps
In the case of a white-box pentest, the pentester will ask for a fairly decent amount of sensitive, business-critical information such as architecture documentation and full access to source code. If a business has not promoted internal security awareness and motivated security training, they are off to a bad start. Data will be subject to carelessly moving from one pair of hands to another, creating a completely new threat agent - the penetration testing company.
At a minimum, the penetration testing company needs to be treated as someone with temporary access. After the penetration test is done, any access granted should be revoked and the data that’s been shared should be thoroughly scrubbed.
From the post-engagement perspective, it will take time to educate employees about the identified security issues. The vulnerabilities will just keep waiting to be exploited until the personnel is trained, and the long and complicated reports will only serve the opposite of timely reaction.
Penetration Tests Don’t Provide The Whole Picture; Vulnerability Assessments Do
It is inadequate to occasionally assess how safe databases are and to think that the business has achieved a state of security based on those findings.
Penetration tests are just a snapshot in time of how good or bad an organization’s security posture is from the limited perspective of the tools and methodology that was applied. The results of engagement can be subjective and are only valid for the time being. This is problematic because very soon, something will change. Perhaps a new employee will need an account with a specific level of privileges to access a remote database. Perhaps a developer will create a new microservice, propagating changes to repositories and modifying multiple databases scattered across a variety of locations.
Keeping security up with business growth requires practicing proactive defenses and leaving nothing to chance.
While a penetration test will only occasionally report vulnerabilities of a narrow scope of assets, a vulnerability assessment will enable systematic identification of vulnerabilities that might appear in the whole inventory of databases on an ongoing, proactive basis.
A vulnerability assessment is a process of identifying, quantifying, and prioritizing the vulnerabilities in a system. The objective of a vulnerability assessment is to continuously identify all the possible vulnerabilities whenever a change happens in any of the systems included in the scope of the assessment.
In comparison to the potentially disruptive nature of pentests, vulnerability assessments analyze the security posture in a non-intrusive way. The ability to safely run a vulnerability assessment at any time without any concern for disruptions to the targeted environment plays an important role in cloud security assessments where damaging the surrounding network brings the risk of penalties - at minimum.
Continuously conducting vulnerability assessments ensures that databases are sustained within the confines of set security policies. The winning benefit of this approach is that vulnerabilities are remediated before the asset can even expose itself to any threats.