Creating & Updating Projects

AttackForge Community AttackForge Core & Enterprise Self-Service API FAQ
Search…
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:
​https://support.attackforge.com/attackforge-enterprise/getting-started/updating-vulnerabilities#re-apply-slas-on-vulnerabilities​
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.