This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Create Pentest Objectives

Now that you’ve defined an asset, it’s time to define objectives for the pentest.

Define what you want our pentesters to test.

When you set up a pentest through the UI, your going through the following stages of our pentest wizard:

  • Define the Asset
  • Create Pentest Objectives
  • Specify Pentest Details
  • Plan the Pentest

This section can help you create pentest objectives. In the Cobalt UI, you can define pentest objectives in the following screen:

Pentest Objectives

On this page of the UI, you can:

If you’re not sure what to include in the UI, follow the links associated with each bullet. If you’re experienced with defining pentests, fill out the page, and continue to Pentest Detail Requirements.

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.

If you start at the top of the pentest objectives page, your next step is to specify a target.

Invite Help

You may not have all the information that you need. To invite others to help define your pentest, look for the Add Collaborator icon:

Add Collaborator

If you select the icon, we save the current pentest, in draft format. We then prompt you for an email address of a coworker who could have more information about your pentest needs.

Next, your coworker receives an email to sign up for Cobalt, with a link directly to the pentest that you’re working on.

1 - Pentest Target

Define where our pentesters can find your asset.

Typically, all you need is a URL, IP address, or link.

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.

Asset Type Typical Target
Web Fully-Qualified Domain Name (FQDN) such as www.example.com. May also specify an IP or network address.
Mobile URL where anyone can download a mobile app, such as on Google Play or the Apple App Store.
API Base URL of the API. You can define the endpoints / queries in the Instructions text box.
External Network IP addresses or the IP network address.
Internal Network IP network address. External IP address for the Jump Box.
Cloud Config IP address(es) and FQDNs of your cloud components.

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

2 - Pentest Methodologies

An overview of available pentest methodologies.

Our pentesters follow specific methodologies for different types of assets.

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

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

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:

Choice of Methodologies

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

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

Review pentest objectives for Web Apps.

Overview of test methodologies for Web assets. Includes microservices.

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:

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 .

Web pentest flow

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

Review methodologies for Mobile Apps.

Overview of test methodologies for mobile assets.

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:

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

Mobile pentest flow

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

Review methodologies for Web Apps.

Overview of test methodologies for API assets. Includes microservices.

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:

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

API pentest flow

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

Review methodologies for External Networks.

Overview of test methodologies for external networks. Includes instances of Microsoft Office 365.

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:

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

External network pentest flow

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

Review methodologies for Cloud Configurations.

Overview of test methodologies for your cloud setup.

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:

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

Cloud pentest flow

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

Review methodologies for Internal Networks.

Overview of test methodologies for Internal networks.

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.

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:

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

Internal network pentest flow

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

Your pentesters need dedicated accounts to test your systems.

Be sure to delete these pentester accounts after the process is complete.

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

Every asset is unique. What do your pentesters need to know about it?

You may have unique requirements and concerns about assets in production use.

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

Your pentesters need to know the technologies behind your asset.

A technology stack could include languages like Java or Go. For networks, it can include hardware components like routers and switches.

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

Technology Stack

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.