SWAT Service Description
SWAT (Secure Web Application Tactics) offers customers a combination of a state-of-art web application scanning technology and Security Consultants to provide the most accurate and reliable solution for dynamic security testing of web applications. It combines vulnerability scanning with penetration testing in a continuous approach to ensure customers’ websites remain protected even when web applications change or new attack methods are discovered, covering both technical vulnerabilities and business logic flaws.
The service comprises:
- Unlimited number of user accounts and roles
- Unlimited updates
- Web application scanning
- Managed scan configuration
- Continuous monitoring
- Zero false positives
- Multi-factor authentication testing
- In-depth penetration testing
- Context-aware risk scoring
- Unlimited verification of the applied fixes
- Outpost24 portal where the results are presented
The approach Outpost24 takes to delivering the continuous assessment service to customers sees a significant reduction in the number of potential business risks being introduced to the monitored application through the lifetime of the subscription.
Additionally through the trusted approach of only publishing findings that pose real risks to the application and the business, development teams are given details, focused information to pinpoint, recreate and address the risks without having to review hundreds or even thousands of false positives or informational findings. Finally, where applicable, classifying the risks against OWASP top 10 and CWE allows many Security Consultants to provide tailored security education to the development teams, helping them understand the risks of not remediating the issues, as well as improving their code hygiene – all resulting in a reduction over time of the risks introduced.
Working with SWAT
1. First 30 days of SWAT
The following diagram provides an overview of the ‘onboarding’ phase of the SWAT service. During this time each customers engagement will undergo the same process. Each of these steps are covered in more detail below and form the basis for the delivery of the SWAT service to customers.
2. Agree Scope of engagement
The SWAT subscription model is based on a per web application and web application instance basis only and excludes any network or underlying host infrastructure.
A web application is defined as:
"A collection of web resources composing a client interface, and the exposed server-side services used to orchestrate this, perceived by a user as one entity".
One web application is not necessarily limited to one domain, subdomain or URL and may be hosted on multiple servers.
An instance is defined as “a deployment of a web application”. Some examples may involve staging or development deployments, but multiple deployments in the same environment (for instance live) are also allowed.
An instance is not necessarily the same as a domain or subdomain.
Submit Scoping details
Prior to service commencement and onboarding, customers should agree the scope of the service delivery with the Application Security Consultant. This is done by completing a form, usually prior to any final pricing and contract negotiations are finalized as the scoping information provides a final service cost to the customer.
When submitting a scoping request, the customer should provide all relevant information pertaining to each application they wish to be considered in scope:
- Application URL(s)
- Any instances
- Any services or API’s required by the application
- Any specific areas of concern to be focused on during the testing
- Any specific microservices in use by the application
- Any additional information relevant to the application
The Scoping document should be sent to the Application security team who will review the information as described below:
Review Scoping requests
The application security team review each customer’s scoping requests prior to any agreement with the customer to commence the service. As part of the scoping exercise the application Security Consultant will review each application (and any attendant instances or services) the customer has requested to be considered.
Applications - The following is mandatory for an application to be considered ‘in scope’
Internet facingCurrently the SWAT service is only available for applications directly accessible from the internet without the need for any VPN or similar tunnel to be set up. Any application that requires access via a VPN connection, or additional software to be installed, will be rejected as out of scope.
Additionally all application testing is conducted remotely, any requirement for on premise based application testing should be considered out of scope for this service.
AuthenticationAny application requiring authentication should be provided, as a minimum, with test credentials covering each in scope user role. The customer is responsible for maintaining these credentials OR for ensuring the Security Consultant team can generate new credentials as required. (for more information see customer onboarding). This information is used to scope the authenticated elements of the application prior to any scope agreement. If the customer cannot provide credentials, or a mechanism for registering accounts is unavailable, then the authenticated part of the application would be deemed out of scope for the service.
APIsIf the application uses APIs as part of its processes, then to be considered in scope, the api must form an integral part of the in-scope application. As such only those API elements that are used during normal operation of the application are to be considered in scope. Currently the SWAT service does not cover stand alone, or full API reviews.
ComponentsA descriptions of any additional components that would require testing, for example if the application has a separate authentication component that is called, or data is passed to. To be considered in scope, a description of how these components relate to the primary application is required as part of the scoping assessment.
Any additional informationAdditional information provided by the customer will be taken into consideration, this might include specific areas to focus testing on, application architecture/design
The Application Security Consultant will review information provided and create a final scoping document that is provided to the customer during contract negotiations. This scoping document will clearly identify the following information:
- Commencement date (usually 30 days after the date of the scoping document)
- Number of in scope applications – both a count and a list of the primary applications
- Number of in scope instances – both a count, and a list of instances along with the primary application they are related to (and thus considered part of)
- Number of APIs - both a count and a list of primary applications they are considered part of
On agreement and signature by the customer these applications, instances and components are considered to define the scope of the SWAT service to be delivered to that customer for a duration of 365 days (1 year) from the commencement date as described in the Scoping document.
For more detail on the deliverables tied to the approved scope please see sections 3. Customer onboarding and 4. Manual penetration testing.
The agreed in scope applications can be changed within the first thirty (30) days of the onboarding process if the manual test HAS NOT commenced. This can be done by raising a scope change request through the Outpost24 Support Portal.
Once the manual test has started, or has been completed, scope changes can only be made at an additional cost, to reflect the work required to onboard a new application. Should a customer wish to change the scope of the service after the first thirty (30) days (and assuming the manual test has not commenced), they should contact their Outpost24 account manager for pricing and further information.
Additionally once the customer reaches the last thirty (30) days of the subscription period, they may change the scope of any application upon renewing the service for the next year. Customers wishing to do this are advised to make the request upon receipt of the renewal for the following years subscription. This will provide the Application Security Consultant time to review the new applications and define a new scope for the customer to agree.
Once agreed the Application Security Consultant will use the final scoping document to determine the service deliverables. All elements described in sections 3 and 4 will be considered applicable to this scope. The customer, outside of the above noted scope change process will not have recourse to alter or request additional testing under the agreed for service.
Scope delivery (service end)
The SWAT service is delivered as a twelve (12) month subscription, adhering to the service deliverables below. At the end of the subscription period the service is to be considered fully delivered. At this juncture the customer will have received:
- A continuous assessment of the application(s) in scope
- Several manual penetration tests conducted through the subscription period
- Findings regularly reported through the Outpost24 portal
- Ability to generate testing reports throughout the subscription period
It is normal for Outpost24 to conduct a service review with the customer approximately sixty (60) days prior to the conclusion of the subscription period. At which point the customer will be given the option to extend the service for a further 12 month period or cancel.
As noted above this provides an opportunity for the customer to adjust the scope for the following twelve (12) month subscription or add additional applications to the existing scope.
3. Day 0 – Customer Onboarding process
As noted in section 2. The Scoping document includes a service commencement date which includes a customer onboarding process. The steps covered during the onboarding process are outlined below and further details are provided for customer reference
- Portal access created for primary user
- Welcome and onboarding Email OR Customer onboarding call
- Set up automated scanner and continuous assessment of applications & instances
- Review initial findings
- Publish initial findings which appear in the Outpost24 portal
Portal access created for primary user
As part of the initial onboarding, a user account is created by the order management team for the customers primary user. This is usually the individual requesting the service or a nominated person covered in the initial contract discussions. This primary user will also receive the onboarding communication as detailed in the next section.
By the commencement date, the customer will receive EITHER a welcome email explaining the basics of the SWAT service and how to access the APPSEC portal OR an invitation to an onboarding call with a member of the Managed service team OR customer success team (whichever is appropriate) The purpose of the initial information exchange between Outpost24 and the customer is to provide some familiarization training on the Outpost24 portal and the service being delivered. The introduction should cover
- How to access the portal including: logging in, configuring notifications, generating reports and reviewing findings, creating additional sub users
- Contacting the Security Consultants via the Outpost24 portal for requesting verification of findings or asking questions about the findings or application(s) being monitored under the service
- Raising support tickets: information on how customers can raise support issues outside of the Outpost24 portal should the need arise (concerns about test impact on live application, bugs, general questions not related to the findings being presented etc)
- Support escalation: the process by which a customer can escalate service concerns outside of the normal support process. See Appendix 1 for more information.
Setup continuous scanning
The Application Security Consultant configures each of the primary applications as well as any attendant instances or microservices for continuous assessment and scanning at this point subject to the mandatory information being provided by the customer.
The application is subject to the following daily activities
- Automated application scan. The application and all applicable instances and components are scanned daily for vulnerabilities and risks.
- Application change detection. As part of the service the in-scope applications and instances are monitored daily for change and assessed as to the likely impact on the applications risk. The types of changes detected are as follows, note this list is not exhaustive and new change detection capabilities are added on a regular basis
- New web pages
- Deletion of existing web pages
- Web page changes
- Addition, deletion or change to components
- Major API changes
- External links
These changes are then triaged by the Application Security Consultant to determine the next course of action. Such as:
- A change to the application scanner to ensure new coverage as needed
- Manually review changes for any new risk
- Provide responsible disclosure to customer should it be deemed appropriate
At this stage the Application Security Consultant will also schedule the start time of the initial onboarding manual test. Usually this is scheduled within thirty (30) days from the commencement date (see later for more information on this stage)
Review & publish (initial) findings
Findings are captured by the team and published to the Outpost24 Portal. When a finding is presented, we guarantee that the finding is NOT a false positive and has a relevant impact to the applications overall risk. To achieve this, we follow the following process for each finding,
- Does the finding pose a risk to the application?
- Is there a relevant improvement suggestion based on a finding?
- Does the finding have relevant risk information? CVSS, CWE etc
- Can the finding be recreated?
If the answer to each of these questions is yes, then the finding will be published to the Outpost24 portal.
Customers view of findings
The primary way of engaging with the Application Security Consultant is through the Outpost24 Portal. The portal provides customers with a view of all their applications under assessment and their associated vulnerabilities and risks. More information on the portal can be found in the onboarding documentation provided as part of the initial customer onboarding experience. When a new finding is published to the portal. It provides the following information, allowing customers to quickly begin work on remediating the issue.
- Risk level
- CWE and OWASP categories
- Recreation flow
As seen in the example below:
Findings are published as they pass through the peer review process, ensuring that customer are presented with real findings without the concern of false positives. Typically, during the onboarding process customers can expect to begin seeing new findings published within the first five (5) to seven (7) business days, dependent on the risks identified by the automated scanners.
Findings are linked to the assets (or web application/instances) they were discovered on. The Outpost24 portal makes it easy to view findings in a way most appropriate to the user’s requirements (All, by group, by specific web application etc).
4. Manual application testing
The SWAT continuous assessment service includes regular manual testing of the application alongside the daily assessments being conducted. During the onboarding process the first manual test will be scheduled and started within the first thirty (30) days.
Further manual testing is scheduled throughout the duration of the contract with a guarantee of four (4) manual tests being performed per subscription year.
In addition, the following conditions may trigger additional manual testing
- Whenever any change that could cause a security issue is detected (components, web forms, dynamic content)
- As soon as a new vulnerability that may be applicable to the web application is disclosed
- When verification requests are submitted by the customer
The following highlights any requirements or other points that customers of the service should be aware of.
Manual testing of the application is done remotely. As such there is no requirement for Application Security Consultants to be present on a customer’s premises.
All in scope applications should be internet facing, or reachable from the internet without the need to utilize a VPN as previously stated. All manual testing originates from one of the following IP address ranges:
It is recommended that customers whitelist these ranges in the network and web application firewalls (WAF) protecting the web apps if there are any, as interference caused by these technologies may lead to reduced testing coverage, depending on the specific test conditions.
Outpost24 recognizes that customers want to review activities in their security logs and monitoring infrastructure the coincide with such manual testing and as such, the above network ranges can be used to identify activity being conducted throughout the twelve (12) month subscription period on the in scope applications.
As noted earlier, at least one user account is required in order to test authentication, authorization, access restriction, and other related multi-tenant functionality.
To achieve full test coverage, the following should be provided:
- At least two user account for applications featuring authentication
- At least one user account per unique user role or user level (e.g. one administrator and one regular user)
User accounts may be omitted if a self-service sign-up exists (e.g. a public account registration).
We recommend that any supplied credentials are added to the credential store in the OUTPOST24 PORTAL where the application security team can make use of these credentials. Failure to provide user accounts, or the ability to generate self-service user accounts may delay the start of the initial manual test beyond the first thirty (30) days. Should an issue arise with credentials the Application Security Consultant will raise an inquiry with the customer to have the issue remediated.
Applicable documentation, tokens and hardware
Some applications may have specific requirements regarding certain operations or functions. Common examples include:
- Order operations, which require a credit card number
- Multi-factor authentication, which require a hardware or software token
The customer should provide the Application Security Consultant with the means required for executing all regular functionality. The Application Security Consultant will raise an inquiry whenever a test case cannot be run because of an unmet requirement. At such point the client can opt to either provide access or exclude the functionality from testing.
Failure to respond to requests or provide the required information (as noted in the scoping document) can result in either a delay to the start of the manual test or specific test cases being omitted from the manual testing resulting in a lesser coverage.
Explicit exceptions excluded functionality and test cases
It is possible to exclude testing of certain areas, functionality, or test cases, if desired. In such case, a full exhaustive list of what is to be excluded must be provided during the scoping process.
The Application Security Consultant takes all care to avoid creating a situation where a live, business critical application is none responsive and therefore impacts the customers’ ability to conduct normal business operations. Should such an event occur customers should raise a priority 1 support request first before escalating through the complaint’s procedure.
By default, the following tests are NOT executed as a part of the SWAT service:
- Tailored or deliberate denial of Service attacks - as a result of such a test, the web application or the server might cease normal behavior and therefore no Denial of Service attacks are executed.
As noted in 2.0 the service covers the in-scope application, instances, and microservices and provides the customer a clear indication of the primary application, as well as those we consider instances. Where instances exist in scope, we treat them differently to the primary application.
For instances we perform the following tests:
- Daily automated scanning
- Daily change detection
- Peer review of findings generated by automated scanning
- Verification of existence of findings discovered during manual test of primary application
We do not conduct full manual testing of an instance.
Manual testing methodology
Each application is tested using the methodology described in the OWASP testing guide (V4), OSSTMM and good practices as described by standards such as ISO27001 and PCI DSS. We continually assess each testing methodology and update these as required.
The testing focuses on Application, Presentation and Session layers of the OSI model. This includes examination of the implementation of the HTTP protocol, WebSockets, TLS, caching and other mechanisms the application utilizes. This however doesn’t mean that all the other layers are omitted, for instance HTTP relies on the Transport layer, which is depending on the Network layer, any eventual issues related to these layers will also be reported.
The Application Security Consultant, besides utilizing Outpost24’s own testing platform, use tools available on the Internet and commercial tools to perform manual testing, in all instances Outpost24 will procure any license needed for such tools without additional costs to the customer.
Microservices or other application components are tested when they are encountered as part of the application’s normal functionality where noted in the service scope.
The following are not included in the SWAT service
- Code analysis / Source code review
- Independent testing of an API
- Internal only applications that are not reachable from the Internet
As noted in section 3.4 and 3.5 findings are peer reviewed and assessed for false positives before being presented to the customer through the Outpost24 portal.
Findings are categorized using OWASP and CWE. Where possible, the Appsec Security Consultant will provide both a CVSS v2 and CVSSv3.1 score for each finding using the CVSS calculator as found here: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator.
As findings are published on a regular basis and this process is not dependent on either the completion of the manual test or the severity of the finding, there is no SLA governing the time to publish a finding of any particular type.
As a rule, findings will begin to be published to the Outpost24 portal within five (5) to seven (7) business days of the commencement of the manual testing of the application.
The diagram to the left highlights the process the Application Security Consultants follow from initial detection to publishing the finding.
Customers are recommended to configure notifications based on their specific use cases to ensure they receive regular updates as findings are published.
In instances where serious flaws in commercial off the shelf tools are discovered the Application Security consultant is not permitted to disclose any finding without the express permission of the Chief information security officer or Chief Marketing officer. In all instances the customer will be notified of the issue first and agreement will be obtained to raise the issue to the COTS vendor if appropriate.
Likewise the Application Security Consultant is not authorized to discuss any findings with national or global press without the express permission of all parties involved (The customer and/or the COTS vendor as appropriate) and in all instances the Vice President of Marketing and the Chief Information Security Officer are required to provide authorization to do so.
Contact with Application Security Consultants
All day to day information exchange between the customer and the Application Security Consultant is conducted through the Outpost24 portal.
Customer can perform the following actions in the portal
Ask questions on findingsComments and questions posted on each finding will be responded to by the Application Security Consultant within five (5) business days as appropriate.
Request verificationCustomers who believe a finding has been remediated by development or other means can request a verification on the finding. Within five (5) business days, the Application Security Consultant will then retest the finding based on the recreation flow to determine if the finding has been fixed. If it is found to be fixed, the finding will be marked as such, otherwise the Application Security Consultant will, if needed, update the finding with any new, pertinent information.
The SWAT service is designed to provide a continuous assessment of an application throughout the subscription period, as such, unlike traditional penetration testing engagements, manual test reports are not automatically generated, nor provided to customers by the Application Security Consultant.
Customers can generate a vulnerability report through the Outpost24 Portal on demand as required. Reports can be generated to focus on specific applications, all applications, and can provide a lighter weight management summary or a detailed report as need and audience dictates. As the report contains detailed information about detected vulnerabilities, it is recommended that the customer only approve access for authorized personnel.
The report contains the following sections:
- Summary of Application risk
- Detailed findings information
- Appendix of tests conducted
To help customers, configuring notifications on findings published can serve as a reminder to generate a report as required.
Where customers require a management summary to be written, usually to satisfy an audit requirement or provide higher level information on the testing conducted to third parties, a request can be made via the customer support portal. On receipt of the request the Application Security Consultant will, within five (5) business days create a management summary that can also be included in the report.
Management summaries are only produced on request and are not part of the day to day service. A customer can request a maximum of four (4) management summaries in any twelve-month period per application.
1. DevOps integration
The Outpost24 Portal runs on a RestAPI, and as such customers are also able to push findings published to the Outpost24 Portal into their JIRA backlog. This is accomplished through running a script that Outpost24 will make available to the customer should they request it.
For more information and to request the script, please contact Outpost24 support who will be happy to provide the required information.
Impact to customer assets
All tools are operated by trained Security Consultants and the actions of the tools are strictly controlled. Any vulnerabilities are reported as soon as they are confirmed.
The amount of traffic generated by SWAT is as high as needed to crawl the web application, test the input parameters and gather data used for change detection, this traffic is also tuned to decrease the impact on the performance of the web application. Ultimately this depends on the size of the web application and therefore no exact sizing guide can be provided. To prevent unnecessary load on the web application the following approach is applied:
- deduplication of requests leading to the same resources
- downloading of static resources like documents and media files is limited
- the HTTP requests may be subject to a threshold and delayed in multiple ways
Data security and retention policy
All interaction, (Scoping, questions, requests for validation) and all findings related to one or more customer applications are stored within the Outscan SaaS platform and are presented to the customer through the Outpost24 Portal.
Data at rest
All backups are encrypted and stored in a secure offsite facility with authorized access only. Data stored within the platform is encrypted as appropriate, such as passwords or other credentials.
Data retention policy
Data is stored within the Outscan SaaS platform on a per application basis for as long as the customer retains a subscription covering that application. Once a customer notifies Outpost24 of termination of contract then the data is retained thirty (30) days from date of termination OR deleted immediately after termination on written request from the customer.
Further information on the data retention policies applying to Outscan can be found in the knowledge base.
Audit log retention
All test logs are retained for a period of six months after a customer terminates their subscription. Audit logs of user activity are retained for a period of twelve months after termination.
Documentation from customer
Any documentation provided by customers such as Scoping information, API specifications or other similar will be stored in the CRM system once reviewed by the Application Security Consultant. Access to client documentation is based on a permission basis.
Summary of responsibilities throughout subscription
The following elements of the service are the responsibility of the customer
- Application details
- User / Password combinations for ALL in-scope roles
- List of in scope roles
- Generation of testing reports
- Requesting management summaries for reports
- Requesting verification of findings
- Set up customers in scope applications in the Outpost24 portal
- Configure continuous assessment
- Commence first manual test by day 30
- Ensure all findings are false positive free
- Post to Outpost24 portal once peer reviewed within five (5) to seven (7) days of the initial discovery
- Verification requests & questions
- Complete each verification request within five (5) business days
- Respond to questions within five (5) business days
- Notification of Issues
- Credential failures
- Application unreachable
- Executive summary requests
- Complete within five (5) working days
Appendix 1: Customer Support process
All support cases relating to the day to day operation of the Outpost24 Portal, requests for management summaries to be created, or relating to the overall service should be raised via the Outpost24 Support portal.
Details of the SLA’s can be found by referencing the following URL : https://outpost24.com/service-description/customer-support
In the unlikely event that a Customer is unhappy with the service they have received, please ask the support representative to provide the Customer Support Service Description and escalation process and they will be happy to provide this.