Creating & Updating Projects
Creating a New Penetration Test (Pentest) Or Other Security Testing Activity

Overview

AttackForge is built upon Projects. Each project has assets (scope) and vulnerabilities. Vulnerabilities are linked to assets.
Projects can be any of the following, however is not limited to the following:
  • Web Application Penetration Test
  • Web Services / API Penetration Test
  • Mobile Application Penetration Test
  • Network and Infrastructure Penetration Test
  • Wireless Network Assessment
  • PCI-DSS Assessment
  • SCADA Assessment
  • OSINT Assessment
  • Physical Security Audit
Only Administrators and Project Coordinators can manually create a new project.
To create a new project, click on Projectsmodule from the main menu. You will see a page which contains a table with all your projects. To create a new project, click on Create New Project button from the page menu.

Validating Project Code

You can validate the project code to check whether an existing project exists using the same code.
You can also fetch the latest project code, to help with sequencing.

Linking Groups

You can link one or more groups to a project. Groups may be used in the following ways, however is not limited to following:
  • Link a Customer to their project
  • Link a Customer's 3rd party to the project (for example development agency)
  • Link a Customer and their related organizational sub-units to the project
  • Link a Platform / Technology to a project
  • Link a Functional Team to the project
  • Link a Security Team to the project
Linking a group will have the following effects:
  • Any Group Members will automatically receive access to the project, based on their access level defined in the Group settings.
  • Group Members will be able to filter Analytics & Trend Analysis based on the Group.
  • Project data will be included in the Group Dashboard.
!IMPORTANT: Group members do not receive access to project-related emails by default. You need to enable this option when creating/updating a group.

Selecting a Scoring System

When creating a new project, you can select a scoring system for the vulnerabilities.
AttackForge supports following scoring systems:
  • Manual
    • manually select Priority (Critical / High / Medium / Low / Info)
    • manually select Likelihood of Impact (0 to 10)
  • CVSS v3.1 Baseline
  • CVSS v3.1 Baseline + Temporal
  • CVSS v3.1 Baseline + Temporal + Environmental

Selecting a Methodology

When creating a new project, you can select one or more methodologies or checklists to apply to the project - referred to as Test Suites.
A test suite helps:
  • Clients understand exactly what was tested on the project;
  • Developers/Engineers link test cases to vulnerabilities;
  • Pentesters structure their testing in a methodical, consistent & standardized way.
When hovering over each test suite, you will see brief information relating to what the test suite is intended for and number of test cases that will be assigned to the project.
AttackForge comes preloaded with test suites from industry benchmarks such as OWASP, OSSTMM, NIST and more.
You can create custom test suites via the Test Suite Builder module. This allows you to define exactly what you will test on your projects; or for customers.

Vulnerability Code

Vulnerability code field is used to generate user-friendly unique vulnerability identifiers for all new vulnerabilities on the project.
For example, if you set a vulnerability code as SEC01 - the first vulnerability created on the project will have an alternate user-friendly unique identifier of SEC01-1. The next vulnerability will be SEC02-2 and so on.
You can update the vulnerability code on a project at any time, so long as it's a unique value (has not been used on ay other projects) and is between three (3) to eight (8) characters in length.
When you update a vulnerability code on a project - all of the existing IDs for any of the projects' vulnerabilities will also be updated to match.
!IMPORTANT: Be careful if you update a vulnerability code on a project - as it may break your existing references to external tools.

Email Notification Type For New Vulnerabilities

Emails for new vulnerabilities can be sent in two different ways:
  • Send Individual Email For Each New Vulnerability - an email will be sent to each opt-in project team member (and additional recipients, if configured) for every new vulnerability discovered. That is, one email will be sent per new vulnerability.
  • Send One Email with Details For All New Vulnerabilities - an email will be sent to each opt-in project team member (and additional recipients, if configured) which includes a summary for every new vulnerability discovered, in a single email. That is, one email will be sent with a summary for each new vulnerability.

Custom Individual Email Notifications on New Vulnerabilities

If you have opted into 'Send Individual Email For Each New Vulnerability' (see above) - you can set a custom email template for each vulnerability.
When creating a custom email body, ensure to include all HTML tags as the emails will be sent in HTML format. You can adjust the standard template which is already pre-loaded in the form for you.
The following meta tags will map to the following details when the email is sent:
  • {firstName} - this will include the firstName of the project team member. For Additional email recipients who are not on the project team, this field will be skipped.
  • {consultant} - this is the first name & last name of the consultant who is sending the daily email.
  • {projectName} - this will be the name of the project.
  • {priority} - this is the priority of the vulnerability i.e. Critical, High, Medium, Low, Info.
  • {title} - this is the title of the vulnerability.
  • {asset} - this is the affected asset for the vulnerability.
  • {likelihood_of_exploitation} - this is the likelihood of exploitation for the vulnerability. It is a number between 1 to 10.
  • {is_zeroday} - this is either Yes or No depending on if the vulnerability is a Zero-Day (0-day) or not.
  • {description} - this is the description of the vulnerability.
  • {attack_scenario} - this is the attack scenario of the vulnerability.
  • {remediation_recommendation} - this is the remediation recommendation for the vulnerability.
  • {proof_of_concept} - this is the proof of concept / steps to reproduce the vulnerability. This is rendered in full HTML.
  • {notes} - this is the notes for the vulnerability.
  • {tags} - this is the tags for the vulnerability. It is presented as an unordered list.
  • {link} - hyperlink to view the new vulnerability in AttackForge

Custom Group Email Notifications on New Vulnerabilities

If you have opted into 'Send One Email with Details For All New Vulnerabilities' (see above) - you can set a custom email template with a summary for all new vulnerabilities.
When creating a custom email body, ensure to include all HTML tags as the emails will be sent in HTML format. You can adjust the standard template which is already pre-loaded in the form for you.
The following meta tags will map to the following details when the email is sent:
  • {firstName} - this will include the firstName of the project team member. For Additional email recipients who are not on the project team, this field will be skipped.
  • {consultant} - this is the first name & last name of the consultant who is sending the daily email.
  • {projectName} - this will be the name of the project.
!IMPORTANT: The following tags must be included within {vulnerabilities}...{/vulnerabilities} tags in your template - for example {vulnerabilities}<li>{priority} - {title}</li>{/vulnerabilities}
  • {priority} - this is the priority of the vulnerability i.e. Critical, High, Medium, Low, Info.
  • {title} - this is the title of the vulnerability.
  • {asset} - this is the affected asset for the vulnerability.
  • {likelihood_of_exploitation} - this is the likelihood of exploitation for the vulnerability. It is a number between 1 to 10.
  • {is_zeroday} - this is either Yes or No depending on if the vulnerability is a Zero-Day (0-day) or not.
  • {description} - this is the description of the vulnerability.
  • {attack_scenario} - this is the attack scenario of the vulnerability.
  • {remediation_recommendation} - this is the remediation recommendation for the vulnerability.
  • {proof_of_concept} - this is the proof of concept / steps to reproduce the vulnerability. This is rendered in full HTML.
  • {notes} - this is the notes for the vulnerability.
  • {tags} - this is the tags for the vulnerability. It is presented as an unordered list.
  • {link} - hyperlink to view the new vulnerability in AttackForge

Custom Email Notifications on Daily Start & Stop Testing

When creating or updating a project, you can set a custom email body for the daily start & stop testing notifications which are sent to the project team. You can also send the emails to additional recipients which are not already on the project team, for example SOC teams.
When creating a custom email body, ensure to include all HTML tags as the emails will be sent in HTML format. You can adjust the standard template which is already pre-loaded in the form for you.
The following meta tags will map to the following details when the email is sent:
  • {firstName} - this will include the firstName of the project team member. For Additional email recipients who are not on the project team, this field will be skipped.
  • {consultant} - this is the first name & last name of the consultant who is sending the daily email.
  • {started_or_stopped_testing} - this will be either 'Started Testing' or 'Stopped Testing' depending on the daily email action being performed.
  • {projectName} - this will be the name of the project.
  • {projectStartDate} - start date for the project.
  • {projectEndDate} - end date for the project.
  • {key.<custom_field>} - you can access your project custom fields using {key.<custom_field>} where <custom_field> is the key for your custom field. For example, if you had a custom field 'Out of Scope' and it had a key 'out_of_scope' - you can use {key.out_of_scope} to print the value of the custom field in this email.
  • {scope} - this is the scope on the project. It is presented as an unordered list.
  • {link} - hyperlink to view the project in AttackForge
  • {startTesting}...{/startTesting} - information which will only be sent in email's when testing has started.
  • {stopTesting}...{/stopTesting} - information which will only be sent in email's when testing has stopped.
  • {totalVulnsToday} - total number of vulnerabilities that were discovered today.
  • {totalCriticalVulnsToday} - total number of critical vulnerabilities that were discovered today.
  • {totalHighVulnsToday} - total number of high vulnerabilities that were discovered today.
  • {totalMediumVulnsToday} - total number of medium vulnerabilities that were discovered today.
  • {totalLowVulnsToday} - total number of low vulnerabilities that were discovered today.
  • {totalInfoVulnsToday} - total number of informational vulnerabilities that were discovered today.
  • {totalActionedTestCasesToday} - total number of actioned test cases today.
  • {totalFailedTestCasesToday} - total number of failed test cases today.
  • {totalRemainingTestCases} - total number of remaining test cases on project.
  • {totalRemainingTestCases%} - percentage of remaining test cases on project.
  • {totalCompletedTestCases} - total number of completed test cases on project.
  • {totalCompletedTestCases%} - percentage of completed test cases on project.
!IMPORTANT: The following tags must be included within {assets}...{/assets} tags in your template - for example {assets}<li>{name} - {details}</li>{/assets}
  • {name} - name of the asset.
  • {type} - asset type.
  • {details} - details for the asset.
  • {external_id} - external id of the asset.
  • {key.<custom_field>} - you can access your asset custom fields using {key.<custom_field>} where <custom_field> is the key for your custom field. For example, if you had a custom field 'Asset Owner' and it had a key 'asset_owner' - you can use {key.asset_owner} to print the value of the custom field in this email.
Let's take a look at an example email template:
1
<p>Hi {firstName},</p>
2
<p>This is just a courtesy email to let you know {consultant} has {started_or_stopped_testing} for <br /><b>{projectName}</b></p>
3
{startTesting}
4
<p>As a reminder, testing for {projectName} will be performed between {projectStartDate} to {projectEndDate}.</p>
5
<p>The scope for testing is as follows:
6
{scope}
7
</p>
8
{/startTesting}
9
{stopTesting}
10
<p>
11
Please find summary below for today's testing:
12
</p>
13
<h4>Testing Progress</h4>
14
<ul>
15
<li>Test Cases Actioned Today: {totalActionedTestCasesToday}</li>
16
<li>Test Cases Failed Today: {totalFailedTestCasesToday}</li>
17
<li>Total Test Cases Completed: {totalCompletedTestCases} ({totalCompletedTestCases%})</li>
18
<li>Total Test Cases Remaining: {totalRemainingTestCases} ({totalRemainingTestCases%})</li>
19
</ul>
20
<h4>Vulnerabilities Found Today</h4>
21
<ul>
22
<li>Total: {totalVulnsToday}</li>
23
<li>Critical: {totalCriticalVulnsToday}</li>
24
<li>High: {totalHighVulnsToday}</li>
25
<li>Medium: {totalMediumVulnsToday}</li>
26
<li>Low: {totalLowVulnsToday}</li>
27
<li>Info: {totalInfoVulnsToday}</li>
28
</ul>
29
{/stopTesting}
30
<p>For more information on testing progress please visit {link}.</p>
Copied!
When the Daily Start Testing email is sent, it will appear as follows:
And when the Daily Stop Testing email is sent, it will appear as follows:

Apply SLAs on Vulnerabilities

This field will become available if you have SLAs enabled in your Administration --> Configuration --> SLAs settings.
Usually SLAs will be automatically applied to any new vulnerabilities created or imported on your projects.
However you can opt-out of applying SLAs automatically, and instead apply them manually on selected vulnerabilities.
This is useful if you want SLAs to applied only under certain conditions, for example:
  • Apply SLAs only at the end of the project;
  • Apply SLAs only when the application team acknowledges the findings;
  • Apply SLAs only on certain projects, for example compliance/regulatory projects;
  • Apply SLAs only on certain vulnerabilities that require an SLA.
To apply SLAs manually on your project, select Manual option:
To apply SLAs manually, please check the following link:

Linking Project to Portfolios & Streams

You can also associate a project with one or more Portfolios & Streams at time of project creation or approval; or when editing a project.

Invite Project Team

You can invite your project team during the project creation process.
You can invite as many users as you need, all in one go. You can define the following for each project team member:
  • Access Level
    • Set the access level for the user on the project. This can be either View, Upload & Edit.
  • Project Role
    • Set the users' project role on the project e.g. pentester, customer, developer, etc.
  • Email Notifications
    • Set the emails which the user will receive on the project.
  • Assign to Test Suite
    • Assign the user to a test suite. The user will be assigned to each of the test cases loaded on the project for the given test suite.

Updating a Project

After your project is created, you will be redirected to the Project Dashboard page. This is you control center for your projects. From here you can access all project areas.
If you would like to update your project, you can select Edit Project from the Project Dashboard page menu.

Place Project On-Hold / Off-Hold

A project may be set to On-Hold or Off-Hold at any time. This can be used when there are issues which are preventing the project from progressing further, and recording when these issues have been resolved.
When a project is placed on-hold or off-hold, an email will be sent to the project team with the reason why, and a banner will be displayed on the project dashboard with the details.
Every time a project is placed on-hold or off-hold, the details are logged in the project tracking section. You can access this by clicking on Tracking button on your project dashboard page.

Cloning Projects

If you are an Administrator or Project Coordinator - you can clone an existing project. This is an effective way to:
  • Prepare for a new round of testing
  • Track vulnerabilities for specific assets across projects
  • Focus retesting on open vulnerabilities
When cloning a project, the new project will get access to:
  • Project settings, which can be adjusted for the new project - this includes name, codes, test suites, scope, email templates, portfolios, custom fields & project team
  • Project workspace, included all notes & files previously uploaded / created
  • Project notes previously created (excluding private notes)
  • Executive summary, including uploaded files
You can also select which vulnerabilities (if any) you would like to carry forward into the new project.
To start, you can select Clone Existing Project from project module menu; or select Clone Project from projects action menu.
Next, select the project from list which you would like to clone.
Review & adjust settings for new project.
Select any vulnerabilities from previous project you would like to bring into this new project.
IMPORTANT: When cloning vulnerabilities, keep in mind: - Vulnerabilities are not transferred. Vulnerabilities will become available in the new project, and will also remain available in the source project. - Vulnerabilities are not copied. This means there will be no duplication of vulnerabilities. - Vulnerabilities are universal. Any changes to these vulnerabilities in source project, will also apply to the new project, and vice-versa. - These vulnerabilities will no longer be able to be deleted. - Assets assigned to each vulnerability will be added to the new projects' scope.
Once you are done, simply click Create Project and your new cloned project will be ready.

View Project Logs

If you are an Administrator or Project Coordinator - you can view project logs to see every recorded event on the project. This can help you to troubleshoot or report on project activities.

Delete Project

If you are an administrator, you can delete your project at any time by pressing Delete Project from your project menu. You will receive a confirmation prompt to authorise this.
All deleted projects will be sent to the project archive. You can access the project archive from Projects module page, by selecting Archived Projectstab.
Archived projects are not accessible by non-admin users. The results from the archived projects will also not be included in Analytics or other sections with AttackForge.
Archived projects can be restored at any time by selecting Restore Project from the actions menu.
You can also delete projects entirely from the database (including logs) or choose to keep the logs. This can be performed using the Destroy Project Data option from the action menu.
WARNING - once a project has been destroyed, there is no way to recover it or its data.