Create Pentest Objectives

• 1: Pentest Target
• 2: Pentest Methodologies
• 2.1: Web Pentest Methodologies
• 2.2: Mobile Pentest Methodologies
• 2.3: API Pentest Methodologies
• 2.4: External Network Pentests
• 2.5: Cloud Pentests
• 2.6: Internal Network Pentests
• 3: Test Credentials
• 4: Special Instructions
• 5: Technology Stack

1 - Pentest Target

To set up a pentest, you need to define the location of your asset. Since the pentests that we support are all “online,” you would set a pentest target to their location on the Internet.

After you’ve defined the target, proceed with the Pentest Methodology.

2 - Pentest Methodologies

By default, our pentesters test for industry standard vulnerabilities from:

• Open Web Application Security Project (OWASP).
  • Includes different “Top 10” lists for web, API, mobile, and cloud systems.
• Open Source Security Testing Methodology Manual (OSSTMM) (PDF).
  • Used for internal and external networks.

For more information on how we pentest, refer to the detailed pages associated with your asset.

• Web
• API
• Mobile
• Internal Network
• External Network
• Cloud

In most cases, the Methodology is fixed, based on the Asset Type you defined earlier. However, if you selected a combined asset type, such as Web + API, you can limit the test to either of the individual methodologies:

Review the methodology for your asset, from the links shown earlier. Each methodology includes default requirements based on standards such as:

• OWASP
• OSSTMM

You’re welcome to include additional requirements.

Next, you’ll want to set up and share Test Credentials for your pentesters.

2.1 - Web Pentest Methodologies

We use the penetration testing objectives listed on this page. If you want to know more about each methodology, navigate to the Pentest Methodologies page associated with your asset.

Web

The Cobalt team of pentesters do not need access to the underlying web application source code, unless you specify it as a requirement.

When you set up a pentest for a web asset in the UI, you’ll see the following in the Objectives text box:

Coverage of OWASP top 10, ASVS and application logic.

Learn more about these objectives from OWASP:

• OWASP Top 10 Web Application Security Risks
• OWASP Application Security Verification Standard (ASVS)

We look at application logic by working with your app.

Tests of a Web asset include tests of APIs used to populate content on that asset. If you have additional APIs, you may consider setting up:

• A combined Web + API test
• A separate test for APIs

We follow an industry standard methodology primarily based on the OWASP Application Security Verification Standard (ASVS) and Testing Guide. Our team takes the following steps to ensure full coverage:

• Target scope reconnaissance
• Business and application logic mapping
• Automated web crawling and web scanner configuration tweaking
• Authenticated vulnerability scanning
  • Manual crawling to ensure better coverage
• Manual web vulnerability tests and exploit reviews
  • Also covers microservices
• Ongoing assessments
  • Report results to clients through the platform
• Report, triage, and retest

We’ll write a report for pentests with at least eight (8) credits .

Additional Requirements

You’re welcome to define additional test objectives. If you follow best practices other than OWASP, ASVS, or OSSTMM, let us know. Include a link or other documentation. If it’s a “well-known” security practice, our pentesters probably already know them!

If you have special instructions for a pentest, add them later, under Special Instructions.

2.2 - Mobile Pentest Methodologies

We use the penetration testing objectives listed on this page. If you want to know more about each methodology, navigate to the Pentest Methodologies page associated with your asset.

Mobile

The Cobalt team of pentesters do not need access to the underlying mobile application source code, unless you specify it as a requirement.

When you set up a pentest for a mobile asset in the UI, you’ll see the following in the Objectives text box:

Coverage of OWASP top 10, ASVS and application logic.

Learn more about these objectives from OWASP:

• OWASP Mobile Top 10
• OWASP Application Security Verification Standard (ASVS)

We look at application logic by working with your app.

We follow an industry standard methodology primarily based on the OWASP Application Security Verification Standard (ASVS) and Testing Guide. Our team takes the following steps to ensure full coverage:

• Reconnaissance
  • Share the mobile application files
    • Android: .apk
    • iOS: .ipa
• Automated and Manual Testing
• Exploit Discovered Vulnerabilities
• Report, triage, and retest
  • We’ll write a report for pentests with at least eight (8) credits

Additional Requirements

You’re welcome to define additional test objectives. If you follow best practices other than OWASP, ASVS, or OSSTMM, let us know. Include a link or other documentation. If it’s a “well-known” security practice, our pentesters probably already know them!

If you have special instructions for a pentest, add them later, under Special Instructions.

2.3 - API Pentest Methodologies

We use the penetration testing methodologies listed on the page. If you want to know more about each methodology, navigate to the page associated with your asset.

API

The Cobalt team of pentesters do not need access to the underlying web application source code, unless you specify it as a requirement.

When you set up a pentest for an API asset in the UI, you’ll see the following in the Objectives text box:

Coverage of OWASP top 10, ASVS and application logic.

Learn more about these objectives from OWASP:

• OWASP API Security Top 10
• OWASP Application Security Verification Standard (ASVS)

We look at application logic by working with your app.

We base our methodology primarily on the OWASP Application Security Verification Standard (ASVS) and Testing Guide. Our team takes the following steps to ensure full coverage:

• Target scope reconnaissance
• Business and application logic mapping
• Automated web crawling and web scanner configuration tweaking
• Authenticated vulnerability scanning
  • Manual crawling to ensure better coverage
• Manual API vulnerability tests and exploit reviews
  • Also covers microservices
• Ongoing assessments
  • Report results to clients through the platform
• Report, triage, and retest
  • We’ll write a report for pentests with at least eight (8) credits

Additional Requirements

You’re welcome to define additional test objectives. If you follow best practices other than OWASP, ASVS, or OSSTMM, let us know. Include a link or other documentation. If it’s a “well-known” security practice, our pentesters probably already know them!

If you have special instructions for a pentest, add them later, under Special Instructions.

2.4 - External Network Pentests

We use the penetration testing methodologies listed on the page. If you want to know more about each methodology, navigate to the page associated with your asset.

External Networks

The Cobalt team of pentesters can proceed with a minimum of information, such as the IP addresses in question. However, you can include the following details in the scope of your desired pentest:

• Network diagrams
• Infrastructure diagrams
• Accounts (even temporary accounts for pentests)
• User information

When you set up a pentest for an external network asset in the UI, you’ll see the following in the Objectives text box:

Coverage of OSSTMM and SANS top 20 security controls.

Learn more about these objectives:

• Open Source Security Testing Methodology Manual (OSSTMM) (PDF).
• SANS Top 20 Security Controls CIS Controls v8

We follow an industry standard methodology primarily based on the OSSTMM standard for penetration testing.

• Reconnaissance
  • Corporate website
  • Related websites, databases
  • DNS
  • Public records (such as WHOIS information)
• Service discovery
  • Port scans on specific IP ranges
  • Focus on public-facing services
  • Follow-up with further tests
• Vulnerability scans
  • Test for penetration of the internal network
• Manual assessment
  • Public-facing services (Web, FTP, Email, Firewalls, Routers, DNS, VPNs, and more)
• Report, triage, and retest
  • We’ll write a report for pentests with at least eight (8) credits

Additional Requirements

You’re welcome to define additional test objectives. If you follow best practices other than OWASP, ASVS, or OSSTMM, let us know. Include a link or other documentation. If it’s a “well-known” security practice, our pentesters probably already know them!

If you have special instructions for a pentest, add them later, under Special Instructions.

2.5 - Cloud Pentests

We support penetration testing of systems in the following cloud environments:

• Amazon AWS
• Google Cloud Platform (GCP)
• Microsoft Azure

While we perform many of the same tests on different cloud configurations, each environment has unique testing requirements.

Cloud Network Pentest

We test cloud assets based on the cloud pentest methodologies listed on this page. If you want a network pentest of your cloud asset, ask us for an External Network Pentest.

Common Requirements

Cobalt assesses your selected cloud environment, as well as all internal and external components. Cobalt follows an industry standard methodology primarily based on:

• Best practices established by your cloud provider
• OWASP standards for Cloud Providers (PDF) and Application Security Verification Standard (ASVS).

The Cobalt team of pentesters do not need access to the underlying web application source code, unless you specify it as a requirement.

We follow an industry standard methodology primarily based on the OWASP ASVS Testing Guide. Our team takes the following steps to ensure full coverage:

• Target scope reconnaissance
• Component enumeration
  • Based on automated component discovery
• Automated component configuration assessment
  • Detail risks, based on Center for Internet Security (CIS) best practices
• Automated / manual review of externally exposed services
  • Basic vulnerability assessments
• Architectural design analysis
• Report, triage, and retest
  • We’ll write a report for pentests with at least eight (8) credits

In general, the cloud providers that we work with no longer need to know before we perform our pentests. However, each cloud provider may have their own procedure. We’ve included links to procedures that we know of in the section for each provider.

Source IP Addresses

Cloud providers may need to include IP addresses associated with pentest traffic in their allowlist. We’ll share these addresses when you create an actual pentest.

Testing Parameters

When you create a pentest that involves a cloud provider, we’ll share the information that your cloud provider may require, including:

• Peak bandwidth
• Peak queries per second
• Escalation traffic requirements
• Emergency contact information

Amazon AWS

Our pentesters need access to test your AWS systems. To that end, you should prepare:

• A dedicated AWS account for each pentester, with access to each target system.
  • Identity and Access Management (IAM) API credentials for each affected AWS account.
    • Include the following managed policies for the pentest user or role:
      • SecurityAudit
      • ViewOnlyAccess

These are the required policy Amazon Resource Names (ARN):

arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

You should also include the architecture of your cloud configuration.

Google Cloud Platform (GCP)

Our pentesters need access to test your GCP systems. To that end, you should prepare:

• A dedicated GCP account for each pentester, with access to each target system.
  • GCP access keys.
  • Identity and Access Management (IAM) API credentials for each affected GCP account.
    • To provide API credentials, use a (service) account with Viewer and Security Reviewer permissions.

Microsoft Azure

Our pentesters need access to test your Azure systems. To that end, you should prepare:

• A dedicated Azure account for each pentester, with access to each target system.
  • Identity and Access Management (IAM) API credentials (read-only) for each dedicated account.

Other Cloud Providers

We’ve done pentests on other cloud providers. You can refer to the Common Requirements listed earlier.

Additional Requirements

You’re welcome to define additional test objectives. If you follow best practices other than OWASP, ASVS, or OSSTMM, let us know. Include a link or other documentation. If it’s a “well-known” security practice, our pentesters probably already know them!

If you have special instructions for a pentest, add them later, under Special Instructions.

2.6 - Internal Network Pentests

We use the penetration testing methodologies listed on the page, based in large part on the OSSTMM.

Special Pentester Needs

Our pentests of internal networks are all performed remotely. To support this access, our pentesters need:

• Access to your internal network through a stable VPN.
• A lightweight Linux server inside the network, used as a jump box.
  • If you use AWS for your internal network, you can use this link to set up a virtual machine.
  • You can also download a Kali VM Image.
  • You’ll need to set up key-based SSH access for each pentester.

Internal Networks

The Cobalt team of pentesters can proceed with a minimum of information, such as the IP addresses in question. However, you can include the following details in the scope of your desired pentest:

• Network diagrams
• Infrastructure diagrams
• Accounts (even temporary accounts for pentests)
• User information

When you set up a pentest for an internal network asset in the UI, you’ll see the following in the Objectives text box:

Coverage of OSSTMM and SANS top 20 security controls.

Learn more about these objectives:

• Open Source Security Testing Methodology Manual (OSSTMM) (PDF).
• SANS Top 20 Security Controls CIS Controls v8

We follow an industry standard methodology primarily based on the OSSTMM standard for penetration testing.

• Reconnaissance
  • Corporate website
  • Related websites, databases
  • DNS
  • Public records (such as WHOIS information)
• Service Discovery
  • Port scans on specific IP ranges
  • Focus on public-facing services
  • Follow-up with further tests
• Vulnerability scans
  • Test for penetration of the internal network
• Manual assessment
  • Public-facing services (Web, FTP, email, firewalls, routers, DNS, VPNs, and more)
  • Access control systems such as Microsoft Active Directory
  • Less secure email protocols (SMTP, POP3, IMAP)
  • Printers
• Report, triage, and retest
  • We’ll write a report for pentests with at least eight (8) credits

Additional Requirements

You’re welcome to define additional test objectives. If you follow best practices other than OWASP, ASVS, or OSSTMM, let us know. Include a link or other documentation. If it’s a “well-known” security practice, our pentesters probably already know them!

If you have special instructions for a pentest, add them later, under Special Instructions.

3 - Test Credentials

In our journey through Pentest Objectives, we now discuss Test Credentials. When you see that title, select from the following options:

• You will provide credentials for each pentester
• You need pentester email addresses
  • We’ll share email addresses once your pentest is in the Planned state.
• Pentesters can create their own credentials / No authentication required

Explain the process in the special Instructions, based on the following use cases:

• If our pentesters can create their own accounts on your system
• If our pentesters can test your system without credentials

If you’ve set up dedicated accounts:

• Remember to create one (1) account per pentester.
  • Make sure each test account works.
  • Share documentation on how your pentesters can set their own passwords.
  • If necessary, share username/password (or other credential) information using the secure channel of your choice.
• Describe the user role along with associated permissions and/or privileges.
• Include other authentication requirements such as multi-factor authentication (MFA).
• Once the pentest (and any retests) are complete, delete the dedicated accounts.

Depending on the methodology, we may also perform black-box and gray-box tests.

Now proceed to the next step, special Instructions.

4 - Special Instructions

You’ve already shared details about your asset, ideally including its architecture. Beyond the standards, you should share any or all special concerns about the asset. The following checklist includes examples to help you decide what to share with your pentesters. While you’re not required to include any such details, we encourage you to include concerns that affect your production systems.

• Highlight areas for special attention, such as:
  • Recent releases
  • Specific functionality
• Vulnerabilities that you’re concerned about
  • Be specific. Include CVE numbers (or equivalent) if available.
• Requirements to access the target environment:
  • For example, if you’re looking for a test on the internal network, include instructions on how to access the Jump Box on that network.
• Production concerns. If you’re setting up a test on production systems, share details that could affect your network.
• Out-of-scope subjects. Highlight any features or workflows that are out of scope for this test.
  • We discourage “out of scope” lists.

Proceed to the next step, the Technology Stack

5 - Technology Stack

You should specify the technology stack associated with your asset. The technologies can vary by asset:

Web

When building a web application, you may use one or more coding languages. List those languages in the text box.

In addition, dynamic web sites may pull information from databases. Include those languages as well.

Mobile

For some, mobile apps are an extension of web apps. If you have a dedicated mobile app, your pentester needs to know the language used to develop that app.

You may have used one of the Web app languages. You may have also used one or more of the languages that designed for mobile apps. In either case, add those languages to the list.

API

An API, short for an Application Programming Interface, specifies how apps communicate with each other. Most APIs are associated with one of the following technologies:

• RESTful APIs
• GraphQL
• Simple Object Access Protocol (SOAP)

The technology drives the commands used to access data. And API testing also depends on the programming language used to set it up. In general, you may use one or more of the same programming languages used to create Web or Mobile apps.

Internal Network / External Network

The technologies associated with internal and external networks generally relate to hardware components, including:

• Routers
• Switches
• Firewalls
• Load Balancers
• Proxy Servers

If you’re looking for a test of an internal or an external network, it’s also helpful to include:

• A hardware diagram which depicts connections on your network

You can upload this information to your asset, as described in the section on Asset Documentation.

Cloud Configuration

We can help users test their cloud configurations by service. In general, cloud services correspond to what may be installed on internal servers. But you also need to specify cloud components for the Technology Stack.

In this case, cloud configuration technology stacks correspond to the services that you might buy from a cloud provider such as Google, Amazon, or Microsoft. To help you list the right components, we provide this list of examples:

• APIs
• VPNs
• S3 Buckets
• Databases (SQL, RDMS)
• Remote Desktops
• Virtual Machines

Now that you’ve defined the technology stack, proceed to pentest details.