ASSURE Service Description

Table of Content


 1.1 SCOPE




























1. Description of service

Outpost24 Assure is a point in time security assessment of an web application designed to provide customers an assurance of the security level of their application. The Assure service is a time-restricted penetration test that provides baseline insight to the security level of the application and is suitable for smaller web applications of low business criticality.

Outpost24 delivers this assurance to organizations, using a combination of highly experienced ethical hackers, tools, and the Outpost24 Portal. Each Assure engagement is a designed to be short-term, delivering the following services:

  • Assurance focused test of the application
  • Zero false positives
  • Multi-factor authentication testing
  • Context-aware risk scoring
  • Ability to verify individual findings for 30 days
  • Secure web portal for presentation of results
  • Ability to raise comments and questions on findings through the portal
  • Ability to export Assure testing report from the portal.

1.1 Scope

The Assure subscription model is based on a 12-month contract, whereby several engagement licenses (known as the ‘pool’) are purchased as part of the subscription. At the point of purchase there is no requirement to provide a list of ‘in scope’ web applications. During the 12-month contract period, organizations may request one or more engagements monthly, there are limits to the maximum number of requests an organization may make, which is outlined in Appendix A – Service level agreement – however for clarity this is either five (5) or 10% of the total engagement pool, whichever is the greater. It is also possible for organizations to purchase additional engagements throughout the 12-month contract period. These engagements must be completed within the 12-month contract period to which they belong, bearing in mind the limitations on how many engagements can be requested in any one-month period.

Instances are not covered and are subject to the use of additional engagement licenses if an organization wishes them to be tested. Outpost24 recommends customers focus on a single production web application per engagement.

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 counted as a separate entity for Assure engagement purposes.

2. Engagement requests

2.1 Submit Engagement details

When a customer is ready to commence an Assure engagement, a support case of the type ‘engagement’ should be completed via the relevant customer support portal. This engagement request is then sent to the Ghost labs Application Security team for review.

There is a limit to the maximum number of applications an organization may request to be assessed in any single month. Please see the SLA for more information.

When submitting a Assure engagement request, the customer should provide all relevant information pertaining to each application they wish to be considered in scope:

  • Application URL(s)
  • 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
  • Test credentials for at least once, preferably two separate user / Role combinations
  • If you want a management / Executive summary creating – check the relevant box

The engagement request should be sent to the Application security team who will review the information as described below:

2.2 Review of Engagement Request

Whilst no formal scoping is conducted prior to commencement of the service, the following information is deemed mandatory, and any nonconformity may result in the engagement being delayed beyond the requested start date or rejected in its entirety.

  • Engagement Start date
    Any engagement request must include a preferred engagement start date. This will be reviewed and upon agreement will determine the commencement of the thirty (30) day engagement.
  • Internet facing
    Currently the Assure 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.
  • Authentication
    Any 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
  • APIs
    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 Assure service does not cover stand alone, or full API reviews.
  • Components
    A 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 information
    Additional information provided by the customer will be taken into consideration, this might include specific areas to focus testing on, application architecture/design.
  • 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.
  • Executive Summary
    By default, executive summaries are not created for Assure services. If you want an executive summary to be written at the end of the 30-day engagement, please check the box in the engaging request form.

2.3 Scope Changes

Once the engagement start date has been agreed, no change in application scope will be permitted for that engagement. Should the customer have additional engagements in their pool, they are welcome to submit further engagement requests as outlined above.

2.4 Scope Adherence

Once agreed the Application Security Consultant will use the Assure Engagement Request to determine the service deliverables.

2.5 Assure engagement delivery (service end)

Each Assure engagement is delivered as a thirty (30) day engagement, adhering to the service deliverables below. At the end of the engagement the scope for that engagement is to be considered fully delivered. At this juncture the customer will have received:

  • A three (3) day manual penetration test conducted at the beginning of the thirty (30) day period
  • Findings reported through the Outpost24 portal
  • Ability to raise verification requests for each finding to verify fixes
  • A final executive summary added to the application on day (30), if requested
  • Ability to generate testing reports throughout the subscription period

As previously noted the Assure service is a twelve (12) month subscription service designed to reduce the need for customers to negotiate penetration testing services on a per application basis through the purchase of a pool of engagement’s for use throughout that twelve (12) month period. Towards the end of the twelve (12) month subscription period, usually within the last sixty (60) days it is not unusual for Outpost24 to conduct a review with the customer on the service received to allow ample time to plan for the following year.

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

3. Manual Application Testing

Each Assure engagement focuses on manual testing of the in-scope application, the following sections provide an overview of requirements and deliverables.

3.1 Access to the applications

All testing originates from one of the following network ranges: (Sweden) (Sweden)

2001:67c:1084::/48 (Sweden)

To avoid interference, this network range should be allow-listed in the network and web application firewalls (WAF) protecting the web apps if there are any. Interference may otherwise lead to reduced testing coverage, depending on the conditions.

The network traffic may be sent from multiple different machines having different IP addresses in that network range and therefore there is no single IP address to allow-list. Outpost24 owns the entire ranges specified.

3.2 Test Accounts

It is recommended that 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
  • 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).

Failure to provide user accounts, or the ability to generate self-service user accounts may delay the start of the Assure engagement beyond the agreed start date. Should an issue arise with credentials the Application Security Consultant will raise an inquiry with the customer, via the support portal to have the issue remediated.

3.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 can result in either a delay to the start of the engagement or specific test cases being omitted from the manual testing resulting in a lesser coverage.

3.4 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, tailored or deliberate Denial-of-Service attacks are not executed as part of the Assure 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.

3.5 Manual Testing Methodology

Outpost24 Application Security Consultants are experienced testers who are trained and certified internally in their skills at application security testing. The testers adhere to the methodology of the OWASP testing guide (v4), with influences from OSSTTM and good practices such as those outlined in ISO27001 and PCI DSS. For Assure tests, time allocated for auditing is constrained meaning that it constitutes a security audit but not a full test or complete security review. Assure does provide a high-quality baseline insight into the security of the application. We ensure the application has been audited in full for platform, encryption, and communication security issues as well as a sound level of hardening. Beyond establishing this baseline, testing is performed focusing on high risk functionality in the applications, ensuring that a good sampling is achieved. Focus of the audit is primarily on technical risk.

The Application Security Consultant, besides using Outpost24’s own testing platform, use tools available on the Internet as well as 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 Assure engagement service:

  • Code analysis / Source code review
  • Independent testing of an API
  • Internal only applications that are not reachable from the Internet

3.6 Review & Publish 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.

3.7 Customer’s 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:

assure service description

Findings are published as they pass through the peer review process, ensuring that customers are presented with real findings without the concern of false positives. As Assure is a time-restricted service, customers can expect to have all identified findings presented in the Outscan portal at the end of the third day of the assignment (day 3).

Findings are linked to the asset (or web application) 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.).

3.8 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 severity.

assure service description

As a rule, findings will begin to be published to the Outpost24 portal as they are found and verified.

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.

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 during the thirty (30) day engagement on the in scope application.

3.9 Engagement duration

During the engagement period, the in-scope web application is tested, the results verified and uploaded to the portal for the customer to perform remediation activities. Where needed, the customer may ask for a verification of a finding, post comments or questions on a finding to seek clarification or answers.

The testing of the application will be conducted over a period of three (3) working days, with all verified findings posted to the portal, and an Executive Summary is added at the end of the engagement period (typically on day 30), if requested in the Engagement Request. The customer may continue to request validation of findings through to the end of the thirty (30) day engagement after which the application test will be marked as completed. The Executive Summary will reflect any remediated findings.

3.10 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
    Comments and questions posted on each finding will be responded to by the Application Security Consultant within one (1) business days subject to the limits noted in appendix A – Service levels
  • Request verification testing
    Customers who believe a finding has been remediated by development or other means can request a verification on the finding. Within one (1) business days, subject to the limitations noted in Appendix A – Service levels, 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.

3.11 Day 30 and beyond

What happens on day thirty (30)

  • Day 30
    When requested, we reserve the final day of the engagement to allow the Application Security Consultant time to create the executive summary that reflects all activities undertaken by both the customer and the Application Security Consultants. As such we request that any final verification requests should be submitted, where possible not later than day twenty-nine (29). If verification request is made on day thirty (30) the application security consultant may, time permitting and on a best endeavor’s basis, action the request. Any verification requested actions on day thirty (30) will not be reflected in the final management summary.
  • Additional Verification
    Should you have findings still unverified at the end of the thirty (30) day service, you can, at further cost, purchase an additional thirty (30) days ‘verification’ service from Outpost24. Please speak to your account representative if you wish to add this.

4. Penetration test Reports

The Assure service is designed to provide a customer with a baseline security assessment of the in-scope application. Customers may 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

To help customers, configuring notifications on findings published can serve as a reminder to generate a report as required.

Until the 30-day assignment has come to an end, the customer should treat any penetration test report generated through the Outpost24 portal as an interim report.

5. Supporting documentation

The following documents are available to support the Assure process.

  • Assure Service agreement form
  • Assure Engagement request form
  • Assure Service Level agreement
  • Outpost24 standard Terms and Condition

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

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

6.3 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.4 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. Appendix A – Assure service levels

Service Component SLA
Outpost24 Portal 99.8 % availability measured on a monthly basis
ASSURE start date To be agreed within five (5) business days of receipt of the request. Subject to a maximum of five (5) or ten percent (10%) of the total number of available engagements to be tested in a single month period per customer. (whichever is greater)
ASSURE Findings Verification (excludes day 30) Verification of a finding by AppSec security consultant within one (1) business day of receiving the verification request from the customer with a maximum of ten (10) verification requests within one (1) single day
ASSURE Findings discussion Response from Assure analyst within one (1) business Day of receiving the comments from the Customer