Creating & Updating Projects
Creating a new penetration test (pentest) or other security testing activity
AttackForge is built upon Projects. Each project has scope (assets) and findings (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
- Source Code Review
- Configuration Audit
- PCI-DSS Assessment
- SCADA Assessment
- OSINT Assessment
- Physical Security Audit
Only Administrators, Project Coordinators, and delegated users can create a new project.
To create a new project, click on Projects module from the main menu. You will see a page which contains a table with all your projects. To create a new project, click on New --> Project button from the page menu.
The project name is used to identify this pentest or security testing activity within the system.
The project code is also used to identify this pentest or security testing activity within the system. It does not have to be unique. It can be any value.
AttackForge will 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.
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 Groups' settings.
- Group Members will be able to filter Analytics 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 in the groups settings when creating/updating a group.
You can associate a project with one or more Portfolios & Streams at time of project creation or approval; or when editing a project. Data from the project, such as vulnerabilities and assets, will be associated with the relevant portfolios and streams.
Every project must have at least one (1) asset assigned to the project scope.
Assets can be, but are not limited to, the following:
- URL for a web application or web services / API
- Name of an application or server
- Network subnet or IP address e.g. 192.168.0.1/24
- File (for example if performing a code review)
- Person (for example if performing social engineering)
- Address (for example if performing a physical security audit)
The asset(s) can be entered in manually, or if using the Assets module, can be selected from a list of pre-existing assets.
When creating a new project, you can select one or more methodologies/playbooks/checklists to apply to the project - referred to as Test Suites.
A test suite helps:
- Clients understand exactly what was and was not 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 Suites module. This allows you to define exactly what you will test on your projects; or for customers.
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 (1 to 10)
- CVSS v3.1 Baseline
- CVSS v3.1 Baseline + Temporal
- CVSS v3.1 Baseline + Temporal + Environmental
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, except for Linked Vulnerabilities. To manage the vulnerability code for a linked vulnerability, you need to update the settings from the source project.
!IMPORTANT: Be careful if you update a vulnerability code on a project - as it may break your existing references to external tools.
This field will become available if you have SLAs enabled in Administration --> Vulnerabilities --> Enable SLAs.
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 disable automatic creation of SLAs on your project, select Manual option.
To make vulnerability information flow faster to help reduce time-to-remediate, email notifications can be enabled on different events, such as discovery of a new critical or high vulnerability. You can opt into whichever email notifications are relevant for the project.
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.
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 for convenience.
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
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
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 for convenience.
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:
<p>Hi {firstName},</p>
<p>This is just a courtesy email to let you know {consultant} has {started_or_stopped_testing} for <br /><b>{projectName}</b></p>
{startTesting}
<p>As a reminder, testing for {projectName} will be performed between {projectStartDate} to {projectEndDate}.</p>
<p>The scope for testing is as follows:
{scope}
</p>
{/startTesting}
{stopTesting}
<p>
Please find summary below for today's testing:
</p>
<h4>Testing Progress</h4>
<ul>
<li>Test Cases Actioned Today: {totalActionedTestCasesToday}</li>
<li>Test Cases Failed Today: {totalFailedTestCasesToday}</li>
<li>Total Test Cases Completed: {totalCompletedTestCases} ({totalCompletedTestCases%})</li>
<li>Total Test Cases Remaining: {totalRemainingTestCases} ({totalRemainingTestCases%})</li>
</ul>
<h4>Vulnerabilities Found Today</h4>
<ul>
<li>Total: {totalVulnsToday}</li>
<li>Critical: {totalCriticalVulnsToday}</li>
<li>High: {totalHighVulnsToday}</li>
<li>Medium: {totalMediumVulnsToday}</li>
<li>Low: {totalLowVulnsToday}</li>
<li>Info: {totalInfoVulnsToday}</li>
</ul>
{/stopTesting}
<p>For more information on testing progress please visit {link}.</p>
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:
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.
- Full details for each access level are displayed in the info panel, and can also be found in the Access Control Matrix
- Project Role
- Set the users' project role on the project e.g. pentester, customer, developer, etc.
- Project role is used for collaborative purposes only. Privileges are managed via access level (see above)
- Notification Events
- Set the emails which the user will receive on the project.
- Test Suites
- 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.
After you have completed setting up the project, you can review the project to ensure all the details are correct, then proceed to create the project. Once the project is created, you will be directed to the project dashboard page.
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 click on the cog in the top-right of the page to enter the settings.
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 the project status will be updated.
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.
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 Project option from project module actions menu.
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.
- Assets assigned to each vulnerability will be added to the new projects' scope.
Select from different cloning options available.
Once you are done, simply click Review and Create Project and your new cloned project will be ready.
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. You can view logs from the project settings page.
If you are an administrator, you can delete your project at any time by first selecting Archive Project from the projects module actions menu. You will receive a confirmation prompt to authorise this.
All archived projects will be sent to the projects archive. You can access the project archive from Projects module page, by selecting Archived Projects.
Archived projects are hidden for non-admin users. Therefore any vulnerabilities inside archived projects will not be included in dashboards, 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 permanently destroy projects. This can be performed using the Destroy Project Data options from the action menu.
WARNING - once a project has been destroyed, there is no way to recover it or its data.
Last modified 5mo ago