Requesting A Project
Last updated
Last updated
Check YouTube for more tutorials: https://youtube.com/@attackforge
Customers can request a new project by clicking on Projects module, then selecting New -> Project Request from the page menu.
During the project request process, the customer will complete a scoping form and upload any supporting information. The form will capture initial scope & details. All form fields, including custom fields, as well as presentation and form logic can be modified in Administration module.
The customer can select one or more services from the service catalogue presented.
Once the customer has completed the form, they can submit it for review. The relevant authorized users will be notified of the new project request and can commence the review process. The customer will also be notified by email that their request is pending review.
Users can view pending requests by clicking on Pending Requests from within the Projects module.
Users can make modifications to their pending requests.
Administrators and Project Coordinators can Approve or Reject requests.
Project requests can be approved by selecting Approve and Setup Project.
When approving a project request, you can choose to setup the project as either a clone of an existing project; or as an entirely new project. Cloning a project is ideal if the request is for a new round of testing for a previously tested application, system or set of assets.
When opting to set up the new project as a clone from an source project, the details from the source project will prevail.
Alternatively when opting to set up the new project not as a clone, then the data from the project request will be pre-loaded into the form for convenience.
You can view the details from the project request in the Request pane.
The Info pane will include any specific information relating to the selected field in the form as you are completing the form.
If a request is Approved, the project will be automatically created and the customer will be invited to the project. The customer will be notified by email that their request was approved. The email will include a link to access the project dashboard.
If a request is Rejected, the user can include a reason why the project was rejected. The customer will be notified by email that their request was rejected and the reason for rejection.
Authorized users can also request more information for a project, before they Approve or Reject the request.
When requesting more information, an email will be sent to the customer with the details for the request. The information is also visible by clicking on the request to view the details.
Once request for more information is made, the status of the request will be set to Requested Information. The customer can make necessary changes to the request in order to address the feedback, and once they save the updates - the status will be set back to Pending Approval and authorized users will be notified by email that the request has been updated and is ready for review.
All users can see the history of their project requests in the Actioned Requests section in Projects module.
When a customer is requesting a new project, they must specify the service which they would like to purchase or proceed with. The test suites are presented to the customer as a Service Catalogue, allowing them to pick and choose what testing they would like to be performed. Test suites can be adjusted to align with the security services offering for a consultancy or playbooks for internal security teams.
For example, if a customer requires a PCI DSS penetration test to meet their annual penetration testing requirements, they can select the service from the catalogue and list the details for the PCI assets in-scope for the assessment. Additional fields can be configured based on the service selected, to capture specific information for a variety of different security audits.
Every project request comes with direct access controls which can be applied to help ensure the right people are notified and access is granted as needed.
Access to project requests can be granted to the following:
Users
Groups
This is in addition to implied access granted for Administrators and Project Coordinators; or other users who have been delegated with the privileges to view, edit and action project requests via global delegations.
Access to each project request includes the following options:
View - user can view the project request, however not make any changes.
Edit - user can view the project request and make changes.
Action - user can action the project request.
Actions on project requests include:
Approve - approve the project request and create a new linked project.
Reject - reject the project request with a reason.
Request more information - request the submitter to resubmit the project request based on feedback.
When a group is linked to a project request, the access controls applied to the relevant group members will apply to the project request.
These settings can be managed directly from the groups settings:
Groups support an optional feature which allows project requests created by the groups members, to be automatically added to the group. This can be useful to automate access to project requests and reduce manual overheads of administering access.
In the example below, if ANY of the following users create a project request:
Project Manager
Joe Pentester
Client User
Account Manager
Then the following access will be granted automatically to that project request if the auto-add feature is enabled:
Project Manager - will get Action access.
Joe Pentester - will get View access, unless is project request creator in which will have Edit access.
Client User - will get no access, unless is project request creator in which will have Edit access.
Account Manager - will get Edit access.
