Snapshot Service Description

Outpost24 Snapshot is a point in time security assessment of a web application designed to provide customers a detailed overview of the security level of their application. The Snapshot service is a thorough manual penetration test suitable for both larger web applications, as well as smaller web applications of high complexity and business criticality.

Outpost24 delivers this security posture overview to organizations, using a combination of highly experienced ethical hackers, tools, and the Outpost24 Portal. Each Snapshot engagement lasts for a period of 60 days and includes the following services:

In-depth application penetration testing
Zero false positives
Multi-factor authentication testing
Context-aware risk scoring
Unlimited verification of applied fixes during the sixty-day (60) engagement
Secure web portal for presentation of results
Ability to raise comments and questions on findings through the portal
Ability to export application penetration test reports from within the portal

1.1 Scope

The Snapshot 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 Snapshot engagement purposes.

2. Engagement requests

2.1 Submit Engagement details

When a customer is ready to commence a Snapshot 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 Snapshot 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 sixty (60) day engagement.
Internet facing Currently the Snapshot 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 SNAPSHOT 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 Snapshot services. If you want an executive summary to be written at the end of the 60-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 Snapshot Engagement Request to determine the service deliverables.

2.5 Snapshot engagement delivery (service end)

Each Snapshot engagement is delivered as a sixty (60) 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 thorough manual penetration test conducted at the beginning of the sixty (60) day period
Findings regularly reported through the Outpost24 portal
Ability to raise verification requests for each finding to verify fixes
Ability to generate testing reports throughout the subscription period

As previously noted, the Snapshot 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 engagements 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 Snapshot 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:

91.216.32.0/24 (Sweden)

80.254.228.0/22 (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 Snapshot 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

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

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:

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. Typically, during the Snapshot engagement process, customers can expect to begin seeing new findings published within the first three (3) to five (5) business days, and then throughout the duration of the sixty (60) days as appropriate.

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.

As a rule, findings will begin to be published to the Outpost24 portal within there (3) to five (5) business days of the commencement of Snapshot engagement.

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 sixty (60) 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.

Snapshot’s aim is to provide most of the feedback in the beginning of the thirty-day engagement to give the customer time to perform remediation activities. While Snapshot cannot guarantee the length of time it will take to fully test the web application, the aim – based on over 15 years of penetration testing experience – is to complete the test between 5 and 10 days total elapsed time. This should however not be construed as a service level, and the Application Security Consultant reserves the right to test the application throughout the sixty (60) day engagement. Findings are posted to the portal as they are identified and verified, and an Executive Summary is added at the end of the engagement period (typically on day 60), if requested in the Engagement Request. The customer may continue to request validation of findings through to the end of the sixty (60) day engagement after which the application test will be marked as completed. The Executive Summary will reflect any remediated findings.

For more information on application service levels for verification, response to questions, number of engagements that can be used per month, please see Appendix A – Snapshot service levels

3.10 Law Enforcement request policy

Outpost24 respects the rules and laws of the jurisdictions in which we operate as well as the privacy and rights of our customers. Consequently, we provide customer information in response to law enforcement requests only when we believe that we are legally required to do so. To obtain non-public customer information, law enforcement must provide the appropriate legal documents required for the type of information being sought, such as a subpoena, court order, or a warrant. To protect our customers’ rights, we scrutinize all requests to make sure they comply with the law. In order for Outpost24 to process the request it must meet the following requirement:

be sent by a law enforcement agency or official government entity via a registered email domain to legal@outpost24.com
include valid and enforceable legal process (e.g., a subpoena, court order, or search warrant) that compels Outpost24 to produce the information requested.
contain the name and contact information of the individual law enforcement agent or government representative who is authorized to serve the request.
state with particularity the categories of records or information sought.
include sufficient information regarding the customer account in order for us to identify the customer account(s) at issue; and indicate the specific time period for which information is requested

3.11 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
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.12 Day 60 and beyond

What happens on day sixty (60)?

Day 36
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 sixty (60) the Application Security consultant may, time permitting and on a best endeavor’s basis, action the request. Any verification requested actions on day sixty (60) will not be reflected in the final management summary.
Additional Verification
Should you have findings still unverified at the end of the sixty (60) day service, you can, at further cost, purchase an additional sixty (60) days ‘verification’ service from Outpost24. Please speak to your account representative if you wish to add this.

4. Penetration test Reports

The Snapshot service is designed to provide a customer with a comprehensive application penetration test 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
Appendix of tests conducted

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

Until the 60-day assignment has come to and 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 Snapshot process.

Snapshot Service agreement form
Snapshot Engagement request form
Snapshot Service Level agreement
Outpost24 standard Terms and Conditions

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 sixty (60) 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 – Snapshot service levels

Service Component	SLA
Outpost24 Portal	99.8 % availability measured on a monthly basis
SNAPSHOT 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)
SNAPSHOT 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
SNAPSHOT Findings discussion	Response from Assure analyst within one (1) business Day of receiving the comments from the Customer