SWAT Service Description

Table of Content
























1 SWAT Overview

SWAT offers customers a combination of 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 and focused information to pinpoint, recreate, and address the risks without having to review hundreds or even thousands of false positives or irrelevant 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

2 Working with SWAT

2.1 First 30 Days of SWAT

The following diagram provides an overview of the Onboarding phase of the SWAT service. During this time, each customer’s 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.2 Agree Scope of Engagement with Outpost24

2.2.1 Service Definition

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.

2.2.2 Submit Engagement Details

Prior to service commencement and onboarding, customers should agree on the scope of the service delivery with the Application Security team. This is done by completing a form, usually before any final pricing and contract negotiations are finalized, as the scoping information provides a final service cost to the customer. Alternatively, where a customer has an agreed consumption model in place, an engagement request should be made via the relevant customer support portal by completing a request type ‘Engagement’.

When submitting an engagement 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 APIs 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 Engagement Request document should be sent to the Application security team who will review the information as described in the following paragraphs.

2.2.3 Review Engagement Request – Scoping

The application security team reviews each customer’s engagement 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 facing
Currently, 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.

Any application requiring authentication should be provided, as a minimum, with test credentials covering each in scope user role. The customer is responsible for either maintaining these credentials or 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.

If 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.

A description 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.

Test Data
In order to carry out effective testing covering most of the application’s normal workflows the application needs to be populated with test data, should it not be possible to produce data during testing. Ideally, the application should be presented to the testing team as it is presented to a regular user in a live environment.

Any additional information
Additional information provided by the customer will be taken into consideration; this might for example include specific areas to focus testing on, or application architecture/design.

2.2.4 Engagement Approval

The Application Security Consultant will review the information provided and feedback on a final version of Engagement Request Document that is provided to the customer during contract negotiations. This feedback will include the following information:

  • Commencement date of manual testing (within thirty (30) days after the license start date)
  • 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 license start date as described in the Engagement Request Document and Sales Quotation.

For more detail on the deliverables tied to the approved scope, please see sections 2.3 Day 0 – Customer Onboarding Process and 2.4 Manual Application Testing.

2.2.5 Scope Changes

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, 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 year’s subscription. This will provide the Application Security Consultant time to review the new applications and define a new scope for the customer to agree.

2.2.6 Scope Adherence

Once agreed, the Application Security Consultant will use the final Engagement Request Document to determine the service deliverables. All elements described in sections 2.3 and 2.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.

2.2.7 Scope Delivery (service end)

The SWAT service is delivered as a 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 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 12-month subscription or add additional applications to the existing scope.

2.2.8 Payment information and Official Identification

If any scoped application requires governmental official identification documents, governmental electronic identification or payment details, the customer is required to provide this information. Due to the sensitive nature of personal information, our consultants will never provide their official identification documents or payment details as part of a test.

Should test payment- or identifications details not be provided, any functionality or application workflow depending on the same will be omitted during testing.

2.3 Day 0 – Customer Onboarding Process

As noted in section 2.2., the Engagement Request 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.

  1. Portal access created for the primary user.
  2. Welcome and onboarding Email.
  3. Customer onboarding call together with a Product Expert.
  4. Setup of automated scanner and continuous assessment of applications and instances.
  5. Review initial findings.
  6. Publish initial findings which appear in the Outpost24 portal.

2.3.1 Portal Access Created for Primary User

As part of the initial onboarding, a user account is created by the order management team for the customer’s 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 onboarding communication as detailed in the next section.

2.3.2 Customer Onboarding

By the commencement date, the customer will receive a welcome email explaining the basics of the SWAT service and how to access the APPSEC portal as well as an invitation to an onboarding call with a member of the Managed service team or a Product Expert from the 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, asking questions about the findings or application(s) being monitored under the service and requesting Executive Summaries.
  • 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 a 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: Customer Support process for more information.

2.3.3 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 and all applicable instances and components are subject to daily automated scanning in order to identify potential vulnerabilities and risks. The scanning output is then reviewed by the Application Security Consultant to determine the next course of action, such as:

  • Manual review of identified anomalies to determine potential risk
  • Re-configuring the application scanner to ensure new coverage as needed
  • Provide responsible disclosure to the 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 license start date.

2.3.4 Review & Publish (Initial) Findings

Findings are captured by the team and published to the Outpost24 Portal. When a finding is presented, Outpost24 guarantees that the finding is not a false positive and has a relevant impact on the application’s overall risk. To achieve this, the Application Security Consultant will take the following into consideration:

assure service description
  • 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.
Additionally, in the instance where an identified anomaly does not constitute a risk by itself, the Application Security Consultant may report an informational finding with recommendations to further strengthen the security posture of the application.

2.3.5 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:

  • Name
  • Risk level
  • CWE and OWASP categories
  • Description
  • Hostname
  • Recreation flow

As seen in the example below:

SWAT service description

Findings are published as they pass through the peer review process, ensuring that customer is 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.).

2.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.

Apart from the reviewing the application based on a testing queue, 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 the customer submits verification requests

2.4.1 Requirements

The following highlights any requirements or other points that customers of the service should be aware of. Remote Testing

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 use a VPN, as previously stated. All manual testing originates from one of the following IP address ranges:


Testing is usually conducted during Swedish office hours (7-19 CET). The SWAT service does not support specific testing or scanning schedules, for example limiting testing or scanning to out of office hours.

It is recommended that customers whitelist the Outpost24 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 that coincides with manual testing. 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.

2.4.2 Test Accounts

As noted earlier, at least one user account per tenant is required 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 accounts for applications featuring authentication
  • At least one user account per unique user role or user level (e.g., one administrator and one regular user)
  • At least two tenants in a multi-tenant environment

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 in the Customer Support Portal, in order to have the issue remediated.

2.4.3 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 requires 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 Engagement Request 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 lesser coverage.

2.4.4 Explicit Exceptions – Excluded Functionality and Test Cases

It is possible to exclude testing of specific areas, functionality, or test cases if desired. In such a 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, tailored or deliberate Denial of Service attacks are not executed as part of the SWAT service. 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.

2.4.5 Testing Scope

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
  • 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.

2.4.6 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, Web Sockets, 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 using 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

2.5 Findings

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.

2.5.1 Disclosure

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 Service Level Agreement (SLA) governing the time to publish a finding of any type.

assure service description

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 expressed 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 Chief Marketing Officer and the Chief Information Security Officer are required to provide authorization to do so.

2.5.2 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 findings
Questions posted on each finding will be responded to by the Application Security Consultant within five (5) business days as appropriate.

Request verification testing
Customers who believe a finding has been remediated by development or other means can request a verification of the finding. Within five (5) business days, the Application Security Consultant will then re-test 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 and pertinent information

3 Manual Reports

3.1 Reporting and exporting a report

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 generated by default 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 all or specific 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. The customer may also configure report exports to be generated automatically based on a set schedule or certain triggers.

3.2 Management Summaries

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 ten (10) business days create an Executive 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.

4 Integrations

4.1 DevOps Integration

The Outpost24 Portal runs on a Rest API, 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.

5 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

6 Data Security and Retention Policy

All interactions (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 at https://outscan.outpost24.com.

6.1 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.

6.2 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 the contract, then the data is retained for sixty (60) days from the date of termination OR deleted immediately after termination upon written request from the customer.

Further information on the data retention policies applying to Outscan can be found in the knowledge base.

6.3 Data deletion process

This is achieved through a twostep process, firstly, all services which ‘expire’ are notified to the Ghost labs Application Security Operators who, secondly, initiate a process to delete the application(s) and associated applications after reviewing the information to ensure only the affected applications are removed. Once completed all data from the Outpost24 portal is removed, the customers user accounts are removed and access to the Portal terminated.

Any preexisting backups are annotated with the customers unique ID to ensure no data is recovered in the event of a requirement to restore data from a backup that predates the removal of the account.

6.4 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.

6.5 Documentation from Customer

Any documentation provided by customers such as Scoping information, API specifications, or other similar will be stored in the Customer Relationship Management (CRM) system once reviewed by the Application Security Consultant. Access to client documentation is based on a permission basis.

7 Summary of Responsibilities Throughout Subscription

7.1 Customer Responsibilities

The following elements of the service are the responsibility of the customer:

Application details

  • Components
  • Instances


  • 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

7.2 Outpost24 Responsibilities


  • 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
  • Post high or critical risk issues to Outpost24 portal within one (1) day of initial discovery and peer verification

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 ten (10) working days

8 Appendix 1: Customer Support process

All support cased relating to the day-to-day operation of the Outpost24 Portal, requests for Executive 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.