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

Return to the regular view of this page.

Getting Started

How to get started with Cobalt software.

Use this document to visualize your journey through Cobalt to secure your systems.

You want to enhance the security of your software. You’re ready to set up penetration tests (pentests) to elevate your security posture. With pentest-driven solutions, you can comply with regulations and enhance the confidence of your customers. You want results as soon as possible.

You’ve come to the right place.

Learn more.

Overview

Our journey takes you through the steps required to create a pentest:

  1. Define Your Assets. Our pentesters analyze all kinds of assets, from web apps to internal networks.
  2. Create objectives for your pentest.
  3. Define details of your environment. Is your asset in production or in development? Is part of your system on a Cloud platform?
  4. Start planning the test. Define your desired pentest start date. We need time to find the best available pentesters for your assets.
  5. Review your pentest request. Use our Pentest Checklist to make sure you’ve included all information that our pentesters need.

Once you’ve set up a pentest, we start analyzing your asset. When possible, we share results even before we create your report. Here’s what you can expect.

Assuming you’ve received an email invitation, take the next step. Sign in to Cobalt.

1 - Sign In to Cobalt

Start the pentest process. Sign in to the Cobalt app.

This page assumes that you’ve received a welcome email from Cobalt.

Even if you haven’t yet purchased Cobalt credits, this page (and document) can help you visualize how you can set up a pentest with the Cobalt UI.

You’ve just received an email with the following title:

Welcome to the Cobalt Platform: Let's Get Started

Open the email. It should include a link to Get Started:

Cobalt Welcome email

Now you can:

  1. Select the link in your email.

  2. From the webpage that appears, create a password. Follow the complexity requirements on the screen. We require passwords with at least:

    • Eight (8) characters
    • One (1) uppercase letter
    • One (1) lowercase letter
    • One (1) digit

    We also include a link to our Terms and Conditions.

  3. Once you’ve set a password, you should see the Cobalt app.

  4. The next time you want to sign in, navigate to https://app.cobalt.io.

    • Your username is your email address.

    Cobalt Sign In Screen


    You can now use the Cobalt app to start setting up a Pentest.

  5. Select Create a Pentest. Now proceed to the next step, Define Your Assets.

Authentication

We support two-factor authentication. After you sign in, select the icon in the upper-right corner and select Security Settings.

2 - Define Your Assets

Security professionals perform pentests on your assets. Collect the info they need.

Help our pentesters test your assets faster.

The Let’s get started! screen includes two options:

  • Create a new pentest from an existing asset
    • This option opens a drop-down text box. Use it to select from assets that you’ve created. It populates the Asset screen with available information.
  • Create a new pentest for a new asset.

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 define your asset. In the Cobalt UI, you can define pentest objectives in the following screen:

Asset Screen

This page corresponds to the Assets that you can set up in the Cobalt app. You can access the UI to define your assets in the following ways:

  • Select Assets in the left-hand pane, and select New Asset.
  • Select Assets or Pentests in the left-hand pane, and select Create a Pentest. When you set up a pentest, the wizard allows you to define an asset.

This Getting Started Guide assumes that you’re setting up an asset as part of setting up a pentest.

The asset screen prompts you for the following information:

  • Asset Image: Use it to help identify what you need from a list of assets.
  • Asset Title: Set up a descriptive name to attract attention from the best pentesters.
  • Asset Type: Select one of the options described in the linked page.
  • Asset Scoping: Review the guidance on:
  • Asset Description: Add information that can help your pentesters fully analyze your asset.
  • Asset Documentation: Upload documentation, architecture diagrams, images, spreadsheets, videos related to your asset.

The UI provides the information that you need to add an Asset Image and Title. Now take the next step and define your Asset Type.

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.

2.1 - Specify Asset Type

What kind of asset do you have?

Help us find the right pentesters for your asset.

For each asset, we provide guidance for each of the following asset types:

Asset Type Description
Web An online application (app). Includes APIs that supply data to the (Web) app.
Mobile Any application intended for smart phones or tablets.
API API is an Application Programming Interface. Use for APIs independent of a Web app.
External Network Any network that’s directly exposed to the internet.
Internal Network Any network with either a limited or no interface to the internet.
Cloud Config For systems on “the Cloud,” using services such as Amazon AWS, Microsoft Azure, or Google GCP.

We also support tests that span two categories, including:

  • Web + API
    • If the only APIs you use supply information to your web app, select the Web asset type. We test those APIs as part of web-only tests.
  • Web + External Network
  • Web + Mobile

Once you’ve classified your asset, select an Asset Type:

Select an Asset Type

The next step is to Size Your Assets

2.2 - Size Your Assets

Size your assets to ensure appropriate coverage.

Make sure your asset size matches its complexity.

Once you’ve read this page, you’ll know what to enter as an asset size. As shown in the asset page of the UI, you can select sizes between Extra Small and Extra Large.

Asset Size

The size you select depends on the complexity of your asset. We provide guidance on this page for each of the following Asset Types:

  • Web apps
  • External networks
  • Internal networks
  • Mobile apps
  • APIs
  • Cloud configuration (AWS, Azure, GCP)

We also support tests that span categories, including:

  • Web + API
  • Web + External Network
  • Web + Mobile

This page provides basic guidance for assets in a single category. If you have one of these “multiple category” assets, you’ll see a link to a basic guide in the UI. For example, if you’ve selected a Web + API Asset Type, you’ll see a link to a “Web + API Scoping Guide”:

Link to Scoping Guides in the UI

The following sections can help you understand the following characteristics of assets:

  • Different types
  • How to classify an asset by size

Once you’ve selected a size for your asset, your next step is to review the test coverage.

Web

To scope a Web asset, you need to specify the number of the following characteristics of that asset:

When scoping an Asset, include every type of User Role and Dynamic Page. Be thorough. If you forget certain roles or pages, your pentest might not cover all critical details.

Cobalt subdivides the number of User Roles and Dynamic Pages into the following categories:

Extra Small Small Medium Large Extra Large
User Roles 1 1 - 2 3 - 5 5 - 7 > 8
Dynamic Pages 0 - 30 30 - 60 60 - 90 90 - 120 > 120

If your numbers fit in different categories, use your judgment. Review your findings with your Customer Success manager (CSM), or email support@cobalt.io. If you choose a “bigger” category, you’ll get a more complete test.

As part of our tests for Dynamic Pages, we also test the backend API endpoints frequently used to populate content on those pages.

Our pentesters need to know more about your Web asset, including:

  • Application type, such as a page-driven website or a single-page application
  • Special endpoints associated with your dynamic pages

Mobile

To scope a Mobile asset, you need to specify the number of the following characteristics of that asset:

When scoping an Asset, include every User Role, Operating System, and Mobile Screen. Be thorough. If you forget certain roles, pages, or screens, your pentest might not cover all critical details.

Cobalt subdivides these properties into the following categories:

Extra Small Small Medium Large Extra Large
User Roles 1 1 - 2 3 - 5 5 - 7 > 8
Operating Systems 1 1 1 - 2 1 - 3 1 - 3
Mobile Screens 1 - 19 20 - 39 40 - 59 60 - 79 > 80

If your numbers fit in different categories, use your judgment. Review your findings with your CSM, or email support@cobalt.io. If you choose a “bigger” category, you’ll get a more complete test.

API

We can test both RESTful and GraphQL APIs. However, these APIs work in different ways. While some RESTful APIs can have dozens of endpoints, a GraphQL API has a single endpoint.

If you’re sizing a GraphQL API, identify a list of queries and mutations. For pentest purposes, that’s functionally equivalent to the number of RESTful API endpoints.

To scope an API, you need to specify the number of the following characteristics of that asset:

When scoping an asset, do include every user role and endpoint. If you forget some, you may sacrifice quality in penetration testing.

Cobalt subdivides the number of User Roles and Dynamic Pages into the following categories:

Extra Small Small Medium Large Extra Large
User Roles 1 1 - 2 3 - 5 5 - 7 > 8
Endpoints/Queries 0 - 74 75-149 150-224 225-299 300-374

If your numbers fit in different categories, use your judgment. Review your findings with your CSM, or email support@cobalt.io. If you choose a “bigger” category, you’ll get a more complete test.

External Network

To scope an External Network, you need to specify the number of affected public IP addresses:

Extra Small Small Medium Large Extra Large
Public IP Addresses 1 - 149 150 - 299 300 - 449 450 - 599 600 - 749

If you’re working with more external IP addresses, you can set up additional external network assets. One way to organize such assets is by subnet.

Internal Network

To scope an Internal Network, you need to specify the number of affected IP addresses and servers:

Extra Small Small Medium Large Extra Large
Private IP Addresses 1 - 149 150 - 299 300 - 449 450 - 599 600 - 749
Servers 1 - 49 50 - 99 100 - 149 150 - 199 200 - 249

If you’re working with more internal IP addresses, you can set up additional internal network assets. One way to organize such assets is by subnet.

If you’re working with servers on the cloud, you can also set up a Cloud Configuration asset.

Cloud Configuration

Cobalt pentesters can test services on the following platforms:

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

Each platform includes different categories of services, such as EC2, databases, and machine learning engines.

To scope a Cloud Configuration asset, total the number of services you use on that asset.

Extra Small Small Medium Large Extra Large
Services 1 - 49 50 - 99 100 - 149 150 - 199 200 - 249

If you’re working with more services, you can set up additional cloud configuration assets.

Assets of Multiple Types

Sometimes, assets fit into more than one category. To that end, Cobalt supports pentests on assets in the following groups of categories:

  • Web + API
  • Web + Internal Network
  • Web + Mobile

The challenges with each of these combined asset types is complex, beyond the scope of this Getting Started documentation. If you select a combined asset type, our UI includes a pop-up scoping guide.

Once you’ve selected a size for your asset, your next step is to review pentest coverage.

2.3 - Understand Pentest Coverage

To get a cost-effective but complete pentest, you need the “right” coverage for your assets.

Once you’ve sized an asset, you can select the desired pentest coverage.

Coverage and Credits

We have standard recommendations for our pentests. Each recommendation correlates to a number of credits.

Sizing and Credits

We specify sizing criteria by asset type and size. For more information see our guide on how to Size Your Assets.

You can set your assets to one of five sizes:

Size Default Credits
Extra Small 1
Small 2
Medium 3
Large 4
Extra Large 5

Coverage Levels and Credits

Cobalt includes the following coverage levels for each asset. The number of credits that we recommend varies by coverage level:

Coverage Description
Extra Light Covers up to two features.
Light Sufficient for most general compliance test functionality.
Standard Recommended for compliance tests.
Large Extended coverage for key assets with complex functionality.
Extra Large Comprehensive tests for assets with complex functionality.

Every situation is unique. You may select more (or less) rigorous testing levels.

The following table specifies the number of credits associated with different asset sizes and coverage levels:

Extra Light Light Standard Large Extra Large
Extra Small X X 1 2 3
Small X 1 2 3 4
Medium 1 2 3 4 5
Large 2 3 4 5 6
Extra Large 3 4 5 6 7

Pentest Reports

If you want a pentest report, you generally must set up a test of at least two (2) credits. If you have a one (1) credit pentest, you’ll still have access to the non-report items listed in Pentest Expectations.

We do not create multiple pentest reports for large assets. For example, if you want separate pentest reports for different APIs, set up different pentests for each API.

Now that you’ve defined the asset type and coverage, you can now describe your asset in detail.

2.4 - Describe Your Assets

Better descriptions help our pentesters test your assets properly.

Help our pentesters test your assets faster.

Our pentesters need all relevant information about your asset. To help you understand what to share, we include a description template.

For all assets, we’d appreciate a:

  • High-level overview
  • Description of important functions or features
  • Business risks associated with each function and feature

Include links to published documentation related to the asset. You can upload documentation, diagrams, and more in various file formats under Asset Documentation.

The following sections detail additional needs for different kinds of assets:

Web, API, Mobile

Web, API, and Mobile assets frequently include user roles in different categories such as:

  • Administrator
  • Service user
  • Regular user

Each of these roles typically have different sets of rights, privileges, or permissions. We can verify whether such roles are appropriately limited.

For web assets, define the application type. For example, some web assets may be a:

Web and API assets frequently include dedicated reference documentation. For example, RESTful API assets frequently include OpenAPI-based documents that describe the properties associated with each endpoint.

Web Asset Description

Help us find the right pentesters for your asset. Include a high-level overview of the application. Add details such as:

  • Coding Language.
  • Functions or features central to the capability of your asset.
    • Business risks associated with specific functions or features.
  • Special endpoints associated with your dynamic pages.
    • While our pentesters can find the API endpoints used by your web app with browser “Developer Tools,” let us know if you have special concerns with one or more endpoints.

Network Assets (External and Internal)

Our pentesters need network diagrams to know what to test on a network. If you’ve set up a jump box for our pentesters on your network, include the location in the diagram.

Add network information, including the IP address / hostname of the jump box.

Cloud Configuration Assets

Our pentesters need to know how you’ve set up and use your cloud assets. Even when your cloud assets stand alone, they may share features with other types of assets.

For example, if you have dedicated roles to maintain cloud assets, describe them as you would describe a web app asset.

Make sure to include the:

  • Cloud provider
  • Service
  • Unique users / roles
  • Applicable network / architecture diagrams

Asset Documentation

To share more about your assets, you can upload the documentation of your choice. Our app accepts files in the following categories and formats:

  • Archives (.gz, .rar, .tar, .zip)
  • Documents (.doc, .docx, .pdf, .txt)
  • Images (.gif, .jpg, .jpeg, .png)
  • Spreadsheets (.csv, .xls, .xlsx)
  • Videos (.mov, .mp4)

Our app limits uploads to 100 MB.

Asset Documentation Screen

If you’d like to upload files in a different format, you can try to:

  • Compress or archive the files into one of the noted formats.
    • For example, you can use a “Zip” tool built for your operating system to save your file with a .zip file extension.
  • Contact your Customer Success Manager (CSM) or support@cobalt.io for guidance.

For complex assets, we encourage spreadsheets. The UI includes links to the following templates:

  • Workflow/Priority Target
  • User role matrix

We’ve included suggested data in the downloadable Excel (.xlsx) files. We encourage you to replace this information with other data, and upload it with any other documentation for your asset.

At this point, you’ve completed all entries in the Asset section of the pentest wizard. You can now select Create asset and pentest to move to the next part of the wizard, the Pentest Objectives.

3 - 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.

3.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.

3.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.

3.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
  • Automated 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 two (2) 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.

3.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 two (2) 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.

3.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
  • Automated 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 two (2) 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.

3.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 two (2) 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.

3.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.

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 two (2) 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.
    • 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 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.

3.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 two (2) 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.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.

3.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

3.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.

4 - Specify Pentest Details

Describe key details of your Pentest.

Some detail requirements vary by the type of asset.

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

In this section, you can specify pentest details. Our pentests have common requirements for all assets, as well as requirements for specific assets.

Pentest requirements for Web and API assets are identical. However, tests of a Web asset include tests of APIs used to populate content on that asset.

Pentest Details

The Details page of the pentest wizard requests information about:

  • The target environment
  • For cloud providers, if you need their authorization

Common Pentest Requirements

Our pentests share the characteristics listed in this section:

Network Information

Our pentesters send requests from one or more IP addresses on a Virtual Private Network. Share this pentest with your network administrator. They may need to know the IP addresses that we use:

List of IP addresses:

Environment

We need to know the environment of the pentest asset. The standard options are:

  • Production (for end users)
  • Staging (proposed future production environment)
  • Development (asset in work)

If you define your environment differently, let us know. Add that information in comments.

Target Environment

Controls

Tell us about how you’ve regulated access to your systems. For example, administrators may set up firewall rules that limit access to specified traffic to reduce the risk of Denial-of-Service attacks.

You could use systems like:

  • Web-Application Firewalls (WAF)
  • IP-based restrictions using allowlists/denylists, or services like iptables.

Rate Controls

If you do have rate controls, include details. For example, you might include details such as:

  • Limit ping messages (ICMP) to 2/second

Cloud Platform Components

If part of your asset resides in the cloud, you may not need a separate cloud asset test. As described in this question, if your asset includes “systems” installed on a cloud, you can include the platform and system name in the text box.

Cloud Platform Details

In some cases, you may need to inform your Cloud provider about tests. For guidance, see our page on Cloud Methodologies.

Additional Guidelines

You may have already addressed these questions when setting up Special Instructions when defining pentest objectives.

You’re welcome to add more information here.

Test Data

Our pentesters need to know about the environment that they’re testing, as well as whether they can find production data on the test system.

Our pentesters also need information on test data. If your apps contain:

  • Personally Identifiable Information (PII)
  • Protected Health Information (PHI)
  • Credit-card holder data (CHD)

Our pentesters take extra care to protect that information.

Some apps support the use of credit cards for purchases. If you provide test credit card numbers, you can share that information in the instructions or in the “Kickoff call.”

Now that you’ve filled in the details, you can start planning the actual pentest.

5 - Plan the Pentest

Set up a schedule. Confirm the scope.

Now you can set a date for the pentest.

Depending on your PtaaS Tier, we can help you schedule pentests with a start date from at least one to three business days after you select “Submit for Review.”

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

We reserve two (2) weeks to complete our pentests.

Pentester Planning

On the Pentest Planning screen, you can also update the asset scope, and the number of credits required for the test.

If you have any special requirements, such as qualifications for pentester certifications, we reserve the right to start the pentest later than the flow time specified in your PtaaS Tier.

Additional Requests

You can also specify special requirements for pentesters. For example, if industry, company, or national regulations require that you limit pentesters to residents of one or more countries, you can do so here:

Pentester Limits

If you’re ready with your pentest, select Save & Exit > Yes.

In the next screen, you can review your work, as a checklist.

6 - Your Pentest Checklist

Review your pentest request.

Make sure our pentesters have the information they need.

In previous sections, you’ve saved what you’ve entered for the pentest. Now you can review your work. Before selecting Submit For Review, follow this checklist for Objectives, Details, and your Asset.

Review Your Work

For all three tabs, you can select Edit to make changes.

Objectives

Under the Objectives tab, you can review:

Details

Under the Details tab, you can review:

Asset

Under the Asset tab, you can review:

Reports

If you want a pentest report, you generally must set up a test of at least two (2) credits. If you have a one (1) credit pentest, you’ll still have access to the non-report items listed in Pentest Expectations.

When You’re Ready

If you’re ready with your pentest, select Submit for Review.

Once you do so, learn what to expect after you create a pentest.

7 - Pentest Expectations

What happens after you’ve set up your pentest.

Our pentesters share what they’ve found before they write your report. We’ll write a report for pentests with at least two (2) credits .

Now that you’ve done all the work needed to set up a pentest, you might be anxious for results. Here’s what you can expect:

  1. Once you’ve finished setting up a pentest, select Pentests in the left-hand pane. You should see your pentest listed, with an In Review label.

  2. Select your pentest. You should see a link to a Slack channel, dedicated for your pentest.

  3. Add the colleagues of your choice to the Slack channel. Choose colleagues who can benefit from direct communication with our pentesters.

  4. We’ll select the best available testers before the start of the pentest. The time we need depends on your PtaaS Tier and any special requirements you have.

    • As soon as we’ve selected your pentesters, and have moved your pentest from In Review to Planned, you’ll see them in your Slack channel.
  5. You may get questions from your pentesters in Slack. You can also elaborate on your requirements in that same channel.

  6. As our pentesters analyze your asset, they’ll add updates frequently in your Slack channel. If they discover vulnerabilities (“findings”), you can start remediating before the pentest is complete.

    Here’s an example finding as discussed in a Slack pentest channel.

    Pentest Sample Discussion

  7. Once the pentest is complete, we move your pentest from Planned to Remediation.

  8. You can start assessing all discovered vulnerabilities. In the Cobalt app, navigate to Pentests. Select your pentest, and navigate to the Findings tab.

    • Scroll down until you see Activity. Depending on your assessment, you can set the finding to one of the following states:

      • Pending Fix, when your developers are remediating the finding.
      • Ready for Re-Test, assumes that your developers have fixed the issue, and you’re ready for our pentesters to validate your fix.
      • Accepted Risk, when you’ve determined that the finding is either not critical, or is beyond your control. For more information, see the following blog post on Accepted Risk.
  9. We keep the Slack channel open until you’ve set each finding to:

    • Accepted Risk
    • Fixed

    If you need access to the archived channel, contact your Customer Success Manager or support@cobalt.io.

  10. If you’ve purchased a qualifying PtaaS Tier, you can customize your Pentest report. However, we report all findings. For more information, see the following blog post on how you can Customize Your Pentest Reports.

  11. Based on your Service Level Agreement, our pentesters then share a formal report. You’re welcome to download this sample test report (PDF) for a web app.

Our Pentest States page includes more information about each pentest state, including Draft, In Review, Planned, Remediation, and Closed.

7.1 - What's in a Pentest Report

Here’s what can you expect in a Pentest Report.

Our pentest reports include what you need to further secure your systems.

We provide following types of pentest reports:

  • Customer Letter
  • Attestation Report
  • Attestation Letter
  • Full Report
  • Full Report + Finding Details

Our Full Report + Finding Details includes all of the following sections. If you’ve purchased an appropriate PtaaS Tier, you can customize what you see in all but the Attestation Letter.

The Attestation Letter is a one-page report that you can share with external stakeholders such as prospects or customers. We base the letter on our Executive Summary. You cannot customize an Attestation Letter.

Target

We include the Pentest Target, the location of your asset.

Test Period

We include the dates when we tested your asset.

Test Performed By

We include a list of pentesters who analyzed your asset. Each pentester name includes a link to their Cobalt profiles.

Executive Summary

Our executive summary includes:

  • A high-level summary of the tests we performed
  • A table with the number of findings that we identified, categorized by different severity levels
  • Highlights of any significant findings

Scope of Work

The scope shown in the following subsections varies depending on the type of asset.

Target Description

The report includes information on the asset that we tested, along with the environment you specified when planning the pentest:

  • Production (for end users)
  • Staging (proposed future production environment)
  • Development (asset in work)

In-Scope Testing Methodologies

In this section, we get into more specifics on the tests that we performed. In general, we test to standards such as:

In this section we include a checklist of the tests that we performed on your assets. Depending on your asset, it may also include manual and automated steps that we use with black box and grammar-based fuzzing. For more information, see:

Test Cases that Thwarted Exploitation Attempts

This section lists the tests that did not find vulnerabilities while testing your asset.

Methodology

We list the basic methodologies that we used before, during, and after our tests.

Pre-Engagement

  • Scoping
  • Customer
  • Documentation
  • Information
  • Discovery

Penetration Testing

  • Tool-assisted assessment
  • Manual assessment
  • Exploitation
  • Risk Analysis
  • Reporting

Post Engagement

  • Prioritized remediation
  • Best practice support
  • Re-testing

Risk Factors

We use a modified version of the OWASP Risk Rating Methodology, based on their business impact and likelihood. We measure each factor on a scale from 1 (very low) to 5 (very high).

Severity Definitions

Based on Risk Factors, we assign a rating to each finding, using the following equation:

risk = impact * likelihood

For more information, see our documentation on Severity Levels.

Summary of Findings

When feasible, we include graphs that categorize vulnerabilities by:

  • Type
  • Severity

Analysis

We include a short summary of each vulnerability. If you have a Full Report + Finding Details, you can find more information about each vulnerability in the appendix on Finding Details.

Where applicable, we also include a list of open ports and services.

General Risk Profile

We include a color coded chart based on impact and likelihood of each vulnerability.

Recommendations

We include recommendations for what you can do to mitigate and remediate each finding.

Post-Test Remediation

In this section, we include the type, severity, and state of each finding, as well as whether the finding has been resolved.

Terms

This section includes a disclaimer.

Appendix A - Finding Details

In this section, we go into details for each finding. Our descriptions include the following:

  • Vulnerability Type
  • Description
  • Affected URLs
  • Proof of Concept of the vulnerability
  • Severity
  • Suggested Fix

8 - Customize Your Pentest Report

You may be able to customize your pentest report.

This feature may be limited to subscribers with a specific PtaaS Tier.

You can simplify what’s included in your pentest reports. This page describes available pentest report types, along with what you can do to leave out one or more sections from your reports.

In our application, we make pentest reports available when they’re ready for Remediation, or when they’re Closed. To find and customize what you see in a report, take the following steps:

  1. Select Pentests, select the State dropdown box, and select Remediation.

  2. Now select your pentest, and select the Report tab. You’ll see report sections, along with a drop-down option that allows you to select from the Pentest Report Types shown in the linked table.

  3. You can now customize the selected report type. Select Customize, and scroll to a report section.

  4. If you want to leave out a report section, select the eye icon next to the section title. As we report all findings, we do not allow you to leave out any finding details.

    Customize a pentest report

  5. When you’ve finished customizing your report, scroll to the top of the page and select Apply.

  6. Now you can select Download to download your pentest report, as a PDF file, with the changes you configured.

Pentest Report Types

Report Type Description
Customer Letter An executive summary of the pentest. May be used as a certificate of completion. Great for external shareholders. Includes:

- Executive Summary
- Methodology
Attestation Report Adds the following information to the customer letter:

- Pentester user information
- An overall list of findings
Attestation Letter Includes the executive summary as a formal letter, suitable for external stakeholders or customers
Full Report Includes the following report sections, beyond attestation:

- Executive Summary
- Scope of Work
- Methodology
- Summary of Findings
- Recommendations
- Post-Test Remediation
Full Report + Finding Details Adds details of every test finding to the full report. Details include:

- Vulnerability Type
- Description
- Proof of Concept
- Severity
- Suggested Fix

The Attestation Letter is a one-page report that you can share with external stakeholders such as prospects or customers. We base the letter on our Executive Summary. You cannot customize an Attestation Letter.

9 - Glossary

Learn more about the language of software security.

If you don’t see a term defined on this page, refer to one of the governmental or industry standards cited in the References.

The definitions included in this page may vary from the cited standards, based on how we configure and use Cobalt software.

Allowlist

An allowlist explicitly lets identified systems access. In networks, an allowlist can specify IP addresses. You can typically find allowlists and denylists in files like /etc/hosts.allow and /etc/hosts.deny.

API Endpoint

An endpoint is typically a URL used to allow two software applications to communicate with each other. For example, https://api.cobalt.io/orgs is one endpoint that you can find at https://docs.cobalt.io.

Some endpoints include additional information that may make them seem different. For example, the following two URLs are in fact the same endpoint, as the content after the ampersand (&) describes an action on data sent from that URL:

  • example.com/endpoint1&_prettyPrint=true
  • example.com/endpoint1&_prettyPrint=false

Asset

For pentests, an asset is a software component of value. Cobalt can perform pentests on assets in the following categories:

  • Web apps
  • External networks
  • Internal networks
  • Mobile apps
  • APIs
  • Cloud configuration (AWS, Azure, GCP)

Application Security (AppSec)

Application security is the practice of using security software, hardware, techniques, best practices, and procedures to protect computer applications from external security threats. Source: TechTarget.

Application Security Verification Standard (ASVS)

The OWASP Application Security Verification Standard (ASVS) relates to pentests of web application technical security controls.

Attacker

Sometimes also known as a Threat Actor, Malicious Hacker, “Black-hat Hacker,” or “Cracker.” May be an individual, a group, or even a nation-state. Specified as “attacker” in Cobalt pentest reports.

Attestation Letter

The Attestation Letter is a one-page report that you can share with external stakeholders such as prospects or customers. We base the letter on our Executive Summary. You cannot customize an Attestation Letter.

Black Box Testing

Where the pentester has no knowledge of the internal details of the asset. Contrast with gray box and white box testing.

Also known as “opaque box testing.”

Center for Internet Security (CIS)

The Center for Internet Security is an independent nonprofit organization which develops and refines best practice security solutions.

One of the test criteria used by our pentesters is CIS Controls v8, released in 2021.

Cobalt Users

When using the Cobalt UI, you may encounter a variety of different users, in the following roles:

  • Organization Roles: If you’re a Cobalt customer, your account may have one or more of the following roles:

    • Organization Owner
    • Organization Member
    • Pentest Team Member
  • Pentester Roles: Cobalt pentesters who are assigned to your pentest have one of two roles:

    • Lead
    • Pentester

    Some Cobalt pentesters may be a Lead in one test, a Pentester in a second test, and possibly no role and no involvement in your other pentests.

Select Cobalt employees may be assigned as administrators, as Cobalt Staff.

You can review a list of permissions associated with each organization role in the following article: What do the user roles mean?.

Organization Owner

An Organization Owner is the administrator for a customer organization within the Cobalt app. As such, they can:

  • Add/remove the users of their choice, by their email addresses, as an Organization Member or Organization Owner.

  • View collaborators, the members of their pentest team. That team includes:

    • Pentest Team Member, typically an organization employee.
    • Pentest Lead, the Cobalt pentester responsible for the pentest.
    • Pentester, one or more additional Cobalt pentesters who are helping with the pentest. Smaller pentests may only have a Pentest Lead.
  • An Organization Owner may also be a Pentest Team Member.

  • If allowed by their PtaaS Tier, they can also manage multi-factor authentication (MFA) as well as SAML settings for the users in their organization.

An Organization Owner also has top-level (sudo) administrative privileges for their organizations in the Cobalt app.

Organization Member

An Organization Member is a user of the Cobalt App who can create an asset as well as a pentest. That user can also see the pentesters who are working on their asset. If allowed by their PtaaS Tier, they can also manage integration with Jira and GitHub.

Pentest Team Member

A Pentest Team Member is a customer (organization) representative during a specific pentest. That user can review and respond to each finding identified by a Cobalt Pentester or Pentest Lead.

That Pentest Team Member can also add one or more users as a Pentest Team Member.

A Pentest Team Member does not have to be an Organization Owner or an Organization Member.

Pentest Lead

A Pentest Lead is a Cobalt pentester who leads other Cobalt pentesters in their efforts to test an asset. When applicable, the Pentest Lead also drafts the pentest report.

Pentester

A Pentester is a Cobalt pentester who works with a Pentest Lead to test a specific asset.

Cobalt Staff

Cobalt Staff members may help you manage the users in your organization. They may also help manage work on your pentests.

Dynamic Page

Web applications typically include static and dynamic web pages. A Dynamic Page includes content that can be customized, either through an application server (server-side) or through code such as JavaScript running in the browser (client-side).

Environment

In the context of a Cobalt pentest, you can specify one of three options for an environment:

  • Production (for end users)
  • Staging (proposed future production environment)
  • Development (asset in work)

Finding

A potential security flaw in an app or physical hardware. We include findings in vulnerability reports, as something that a threat actor can exploit.

When you select Full Report + Finding Details, we add a detailed list of findings to your report, which includes:

  • Vulnerability Type
  • Description
  • Affected URLs
  • Proof of Concept of the vulnerability
  • Severity
  • Suggested Fix

Gray Box Testing

Where the pentester has limited knowledge of the internal details of the asset. Contrast with white box and black box testing.

Also known as “translucent box testing.”

Jump Box

Also known as a jump host or a jump server, a jump box is a system (typically) on an internal network or a DMZ. Jump boxes are used to access and manage devices in a separate security zone.

Where the pentester has limited knowledge of the internal details of the asset. Contrast with white box and black box testing.

Known Vulnerability

A “well-known” security vulnerability. Documented in a security bulletin or a CVE (Common Vulnerabilities and Exposures) from MITRE.

In Cobalt pentest reports, you may see this as a published or documented vulnerability.

Mitigate

To apply preventative measures. Based on problems identified by a pentest or incident report. Examples:

  • Install security updates on potentially affected servers
  • Review and update a codebase for issues identified on specific files

Contrast with remediate. This reflects how we use mitigate at Cobalt, and differs slightly from the NIST definition of mitigate.

Mobile Screen

A mobile screen is what you see on a mobile device, such as an iPhone or an Android system. As described by Codepath, mobile screens fall into several archetypes.

You may have multiple screens of an archtype. For example, you may have 10 mobile screens for the onboarding archtype.

Multi-factor Authentication

Authentication which uses two or more different factors, which may include:

  • Something you know, such as a password or a PIN number
  • Something you have, such as an identity token
  • Something you are, which works with biometric authentication

Open Web Application Security Project (OWASP)

OWASP is a nonprofit foundation with “Top 10” security issues for different asset types, including Web apps, APIs, and Cloud systems.

Open Source Security Testing Methodology Manual (OSSTMM)

The OSSTMM tests the operational security of physical locations, human interactions, and all communications on the network, whether they be wireless, wired, analog, or digital.

Operations Security (OpSec)

Operations Security, commonly known as OpSec, identifies critical information, and if/how it may be used by opponents or enemies. OpSec measures can reduce security risks.

Pentest

Short for penetration test. As described in the Getting Started Guide, you can draft a pentest. Once you submit it for review, Cobalt reviews your pentest and assigns a Pentest Lead and frequently one or more Pentesters who then test the asset specified in your pentest.

Pentest as a Service (PtaaS)

Combines manual and human testing with a modern delivery platform to deploy penetration testing programs.

Pentest Report

A summary of all vulnerability reports, including observations on positive security measures. Target audiences: executives, security engineers, and developers. Includes:

  • Executive Summary
    • Describes tests performed with criteria
  • Executive Analysis
    • High-level summary of vulnerabilities
  • Scope of Work
    • Target description
    • Environment
    • In-scope Testing Methodologies
    • Assumptions and Constraints
    • Test Methodologies
    • Web app-specific issues (endpoints, fuzzing)
    • Secure test cases
  • Summary of Findings
    • Trends and critical issues
    • Auto-generated graphs
  • Summary of Recommendations
    • Highlights of the work we recommend to remediate findings
  • Post-Test Remediation
    • List of details with type, severity, state, and resolution
  • Finding Details
    • More information on each finding

Within Cobalt, this is also known as a Report or a Final Report.

Remediate

To fix a vulnerability identified by a pentest or incident report. Examples:

  • Install a security update on an affected server
  • Update directly affected code

Contrast with mitigate. This reflects how we use remediate at Cobalt, and differs slightly from the NIST definition of remediation.

Security Assertion Markup Language

As defined by the Organization for the Advancement of Structured Information Standards (OASIS), the Security Assertion Markup Language (SAML) SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information.

SANS Institute

Original sponsor of a set of standards for testing networks. SANS stands for SysAdmin, Audit, Network, and Security. The SANS Top 20 has been migrated to CIS Controls Version 8.

Single-Page Application

For more information, see https://developer.mozilla.org/en-US/docs/Glossary/SPA

User Role

A User Role specifies the permissions or privileges associated with a user. Common examples of User Roles include:

  • Global Administrator (such as a UNIX root user)
  • Administrator
  • Group Owner
  • Workspace Administrator
  • Full User
  • Guest

When scoping an Asset, include a complete list of user roles. If you miss a user role, you may sacrifice quality in penetration testing.

Vulnerability

A security issue discovered during a pentest. Also a specific weakness which can be exploited by a threat actor, such as an attacker who crosses privilege boundaries (and performs unauthorized actions) within a computer system.

Contrast with Known Vulnerability. A vulnerability may be part of a finding.

Vulnerability Management

The cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. At Cobalt, we focus on manual pentests (enhanced with automated tools). Also see Vulnerability Assessment and Management, as defined by the US Cybersecurity and Infrastructure Agency (CISA).

Vulnerability Report (Manual)

A document that provides information about one specific finding. Cobalt vulnerability reports are based on manual tests. Such reports include:

  • Step-by-step notes on how the tester identified each vulnerability (when possible)
  • Locations, such as files or hardware
  • Recommendations to remediate

Vulnerability Report (Automated)

A document created by an automated scanning tool. Primarily used to list known vulnerabilities associated with specific code patterns.

Vulnerability Type

How Cobalt classifies the vulnerability. Examples include:

  • Client Side Injection
  • Server Security Misconfiguration > Lack of Password Confirmation
  • Broken Authentication and Session Management

White Box Testing

Where the pentester has full knowledge of the internal details of the asset. Contrast with black box and gray box testing.

Also known as “clear box testing.”

References