What is the Penetration Testing Execution Standard (PTES)?

The Penetration Testing Execution Standard, or PTES, is a standard that was developed and continues to be enhanced by a group of information security experts from various industries. PTES provides a minimum baseline for what is required of a penetration test, expanding from initial communication between client and tester to what a report includes.

The goal of PTES is to provide quality guidance that helps raise the bar of quality for penetration testing. The standardization of penetration testing procedures helps organizations better understand the services they are paying for and gives penetration testers accurate direction on what to do during a penetration test.

The 7 Stages of PTES

The PTES methodology is a structured approach to penetration testing balancing guided phases with organizational vulnerabilities. The standard is organized in sections that define what should be included in a quality penetration test.

PTES defines penetration testing in seven phases:

  1. Pre-Engagement Interactions
  2. Intelligence Gathering
  3. Threat Modeling
  4. Vulnerability Analysis
  5. Exploitation
  6. Post-Exploitation
  7. Reporting

Let’s look at each of these 7 phases of the Penetration Testing Execution Standard in more detail.

Pre-Engagement Interactions

Penetration testers will prepare and gather the required tools, OS, and software to begin the penetration test. The required tools vary depending on the type and scope of engagement but will be defined by a quality penetration tester at the start of any penetration test.

Intelligence Gathering

The organization being tested will provide the penetration tester with general information about in-scope targets, and the tester will gather additional details from publicly accessible sources. This step is especially valuable in network penetration testing.

Threat Modeling

Threat modeling is a process for prioritizing where remediation strategies should be applied to keep a system secure. PTES focuses on business assets, business processes, threat communities, and their capabilities as key elements of threat modeling.

Vulnerability Analysis

Penetration testers are expected to identify, validate, and evaluate the security risks posed by vulnerabilities. This analysis of vulnerabilities aims to find flaws in an organization’s systems that could be abused by a malicious individual.

Exploitation

This phase of a penetration test involves the exploitation of identified vulnerabilities in an attempt to breach an organization’s system and its security. Since the vulnerability analysis phase was completed in a quality manner, the next step is to test those entry points into the organization that are weak.

Post-Exploitation

After the testing is complete, the penetration tester must consider the value of the compromised machine and its usefulness in further compromising the network.

Reporting

An executive-level and technical-level report will be delivered covering what was tested, how it was tested, what vulnerabilities were found, and how the penetration tester found those weaknesses. The report should provide your organization with helpful guidance on how to better your information security practices.

How to Get a PTES-Standard Penetration Test

The main segments of PTES provide a detailed dive into the purpose and expectations of penetration testing. For many organizations, the ins and outs of penetration testing are confusing. Because of standards such as PTES, you can get a better idea of what to expect when a penetration tester hunts for your organization’s vulnerabilities.

PTES influences the penetration testing methodology of many auditing firms across the industry. It’s through these standards that information security experts can develop a well-working, quality system that detects your greatest vulnerabilities and reports on ways to improve your information security processes.

At KirkpatrickPrice, we understand that keeping your data secure is important to your organization. That’s why our expert team of penetration testers work hard to stay up to date on industry standards, so you can focus on increasing the security of your organization.

Connect with one of our experts for more information on our quality penetration testing.

More Penetration Testing Resources

The 7 Stages of Pen Testing

Penetration Testing Steps for a Secure Business

Finding and Mitigating Your Vulnerabilities Through OWASP

What is Wireless Penetration Testing?

What’s the Difference Between Internal and External Networks?

Let’s face it: anything connected to the Internet is at risk of being compromised, which means that organizations like yours must understand the types of vulnerabilities in your internal and external networks that could be exploited by a malicious hacker. If you’re interested in learning about common ways your networks may be compromised by a malicious hacker, remediation tactics for mitigating threats facing your internal and external networks, and how to continue to stay abreast of cyber threats with KirkpatrickPrice’s penetration testing services, watch the full webinar now.

In order to protect your organization’s networks, you must first know the difference between internal and external networks and what systems and devices are connected to them. Are client workstations, internal services (DCs, mail, DB), routers, firewalls, fax machines, and/or printers part of your internal network? Do you have WAFs, web applications, or external services (e.g. FTP, SFTP, or Mail) in your external network environment? Ultimately, internal network environments primarily act as the domain for internal users to access your organization’s internal assets they need to function. External network environments, on the other hand, are more often available to the outside world (e.g. for a partner or client to access).

Common Vulnerabilities in Networks: Configuration Problems

In both internal and external networks, KirkpatrickPrice expert penetration testers often find issues due to misconfigurations. Considering this, they encourage organizations to be weary about leaving default passwords and/or using weak passwords on things like appliances, internal applications, network accounts, or even printers, scanners, and fax machines. To prevent your networks from being compromised due to misconfiguration issues, our pen testers explain that regularly testing your configurations is critical, as well as undergoing at least an annual penetration test.

How sure are you that you have found all of the vulnerabilities in your networks? Could there be more you’re unaware of? Watch the full webinar now to learn about common vulnerabilities in networks or contact us today to speak to one of our Information Security Specialists about our internal and external network penetration testing services.

The California Consumer Privacy Act has been regarded as the United States’ strictest data privacy law of our time, and yet, many organizations still don’t know where to start with their compliance efforts. Does the law even apply to them? How can they ensure compliance? What are the steps they need to take? While no one journey toward CCPA compliance is the same, we’ve rounded up four data privacy best practices that you can follow to help with your CCPA compliance efforts. Let’s take a look at what those are.

4 Data Privacy Best Practices to Help with CCPA Compliance

Between GDPR, PIPEDA, CCPA, and the plethora of other data privacy laws going into effect, there are a few data privacy best practices that organizations can follow. When it comes to preparing for CCPA, we suggest following these four best practices:

1. Create an internal privacy framework

An effective internal privacy framework is the foundation of your organization’s data privacy compliance efforts because it lays out what and how you’ll comply with CCPA. Typically, when an organization creates an effective internal privacy framework, they’ll take the following into consideration:

  • Notices and disclosures
  • Access (internal and external)
  • Breach notification
  • Consent
  • Risk
  • Designated responsibilities
  • Data retention
  • Vendor management

2. Do more with less data

When it comes to complying with any data privacy law, minimizing the data you collect, use, store, and transmit is critical. Why? Because data minimization is typically a regulatory requirement, and it reduces your liability when it comes to protecting personal information. How do you do more with less data? You can start with data mapping, which will allow you to know what you have and what you absolutely need. Performing data mapping exercises can help identify situations where you need less personal information. Consider the following data minimization tactics:

  • When the function you provide could be performed without certain personal information
  • When the personal information is no longer needed
  • When the personal information is only needed from a subset of a population
  • When personal information is only needed for a subset of a population

3. Automate compliance efforts

Automated tools can be helpful for complying with data privacy laws, including CCPA, but should not be an end-all be-all solution. To make compliance efforts easier, though, organizations might consider using privacy compliance automation tools to perform the following tasks:

  • Automate processes for consumers to access, delete, export, copy, or correct their personal information
  • Automate data mapping tools
  • Automate data protection impact assessment processes
  • Automate subscriptions to manage consent and opt-out requests

4. Get specific about your internal and external privacy posture

Data privacy laws are known for being ambiguous, but that does not mean that the privacy policies your organization creates should follow suit. Instead, they should clearly define the types of data you’re collecting, the purposes for collecting the data, how you’ll share the data with third parties, how you’ll retain the data, access rights to the data, and security safeguards you’ll implement to protect the data. For CCPA specifically, privacy policies must also include a “Do Not Sell” button on your website if you sell personal information to third parties. In addition to this, organizations must be sure to explicitly define what types of data will you share, how they share it, what activities they are using the data for, and what kinds of obligations you have to support client or vendor compliance with privacy regulations in your contracts.

Ultimately, the key to preparing for CCPA compliance boils down to these following these four data privacy best practices: start with broad privacy goals instead of focusing on one specific requirement from the law; minimize the data you collect, use, store, and transmit; take advantage of good automation tools, but don’t solely rely on them during your compliance efforts; and make specificity in your privacy policies and contracts a priority. If you’re looking for more guidance on your CCPA compliance efforts, let’s talk about how one of our Information Security Specialists can help.

More CCPA Resources

5 Facts to Know About CCPA

Privacy Policies Built for CCPA Compliance

California Consumer Privacy Act vs. GDPR: What Your Business Needs to Know

Could what happened at Capital One happen at your organization? As a business owner, stakeholder, or IT personnel, that’s the unavoidable fear that appears when you hear about the latest data breach. The Capital One data breach is one of the most damaging data breaches of 2019, and we’ll continue to learn about the repercussions for months to come. This data breach impacts 100 million individuals in the United States and 6 million in Canada. The compromised data was from businesses who filled out credit card applications, and Capital One reports that, “The largest category of information accessed was information on consumers and small businesses as of the time they applied for one of our credit card products from 2005 through early 2019.” Most importantly – we know that this breach could happen to any organization that’s not educated on how to properly configure your perimeter security groups. Let’s discuss web application firewalls (WAF), Server Side Request Forgery (SSRF) attacks, metadata, and how a misconfiguration could lead to a compromised AWS environment and stolen data.

Security Misconfiguration in AWS

Evidence from the Capital One case confirms that this data breach began with a misconfigured open-source WAF used in AWS. The intruder, Paige Thompson (a former AWS employee), launched a SSRF attack to manipulate the WAF into running commands it should have never been allowed to – including the command to communicate with the metadata service on AWS.

The Justice Department’s complaint outlines three commands that Thompson performed to abuse the misconfiguration and extract the compromised data, which was later found on a GitHub file:

  1. AWS WAF uses IAM service-linked roles, meaning that an IAM role is linked directly to the AWS WAF. The first command that was executed leaked the security credentials for a specific WAF role with elevated privileges that had access to folders in Capital One’s AWS environment.
  2. The second command that was executed, the “List Buckets Command,” used the compromised WAF role to list the names of Capital One’s folders in their S3 bucket. Thompson obtained access to over 700 folders.
  3. The “Sync Command” was the final step in actually extracting the data from these folders and/or buckets because the WAF role that Thompson compromised already had the required permissions to do so.

The bottom line? The WAF role was probably assigned too many permissions to begin with, and that combined with the misconfiguration led to a successful SSRF attack that had detrimental consequences.

In a statement given to KrebsOnSecurity, Amazon argued, “The intrusion was caused by a misconfiguration of a WAF and not the underlying infrastructure or the location of the infrastructure. AWS is constantly delivering services and functionality to anticipate new threats at scale, offering more security capabilities and layers than customers can find anywhere else including within their own datacenters, and when broadly used, properly configured and monitored, offer unmatched security—and the track record for customers over 13+ years in securely using AWS provides unambiguous proof that these layers work.”

Mitigating Risks in AWS and Securing Your Perimeter

How could you mitigate potential risks and misconfigurations facing your AWS environment? Cloud security experts at KirkpatrickPrice challenge you to consider the following:

  • Understand and monitor the configuration of perimeter security systems (including WAFs). They need to be regularly reviewed to ensure that intended rule sets are functioning as designed.
  • Relying on a WAF, though, to catch exploits is no replacement for proper code creation. The WAF just masks poor code development. Mitigation should focus on good application development hygiene and the enforcement of secure coding practices.
  • Penetration testing can yield huge benefits for externally-facing web applications and infrastructure. The scope and rules of engagement for the penetration testing, though, must ensure that the testing will include exploits that are specific and unique to AWS environments.
  • You must protect your internal services. In the Capital One case, the reason the exploit was able to access the information was because of the metadata service. Learn about a proxy for the AWS metadata service here.

How to Strengthen AWS Environments

How do you validate that your AWS environment has been properly configured? How do you determine that your security and privacy practices are effective? How do you protect the metadata service? Who’s responsible for cloud security – you or the cloud provider? We’re afraid that organizations aren’t asking enough questions like these. As more data migrates to AWS, organizations must have processes in place to check their cloud security efforts. Whether that’s through consulting with an AWS Cloud Practitioner or CCSK, something like a SOC 2 audit, or advanced penetration testing, you need a third party’s perspective and expertise to gain assurance.

What consequences would you face if your clients’ data was discovered to be open to the public? We hope you’ll never have to find out. Let’s partner together to ensure that misconfiguration is not your enemy in your cloud environment.

More AWS Resources

AWS’ Letter to Senator Ron Wyden

AWS Shared Responsibility Model

What is Web Application Penetration Testing?

Who Should Perform Your Cloud Audit?

Why Onsite Audits are Necessary for Cloud Environments

Do you provide cloud solution services? Or, does your organization utilize the services of cloud providers? At KirkpatrickPrice, we understand that it’s important to recognize the value of cloud environments and technology, while also understanding the risk that is coupled with storing data in the cloud. Whether you provide the cloud service or use it for your business, you should know that the services are secure – and that includes auditing both the virtual and physical environments used to provide cloud services. In this webinar, KirkpatrickPrice Lead Practitioner, Mike Wise, discusses why onsite visits are the smart choice for cloud environments.

The assumption that everything is based in the cloud is simply not true. Not only is it inaccurate, it is harmful to an organization to believe an onsite analysis of its security controls is a waste of time. While your data may be stored in the cloud, your physical security processes, onsite technologies, and personnel who process the data are not in the cloud. Think about it: how many processes related to your cloud environment aren’t actually in the cloud? For example:

  • You can’t manage the cloud from the cloud. Who is responsible for managing it? Where does that oversight take place? How is it secured?
  • Development and DevOps activity don’t take place in the cloud. How do you ensure that the changes you’re making to your cloud environment are secure? Who is in charge of overseeing changes and implementation?
  • Human resources, onboarding, training, team meetings, stand-ups – they don’t take place in the cloud. How are you training your personnel about cloud security?
  • Governance and compliance don’t take place in the cloud. How could this impact the security of your cloud environment?

Overcoming the misconception that everything is in the cloud is necessary if you want to make sure that the cloud environment your organization uses is secure. To learn more about why onsite audits are necessary for cloud environments, about shifting the risk when migrating to the cloud, and about how different cloud models impact your security efforts, download the full webinar now or contact us today to speak to one of our cloud experts.