SWAT Service Description
SWAT (Secure Web Application Tactics) offers customers a combination of a state-of-art web application scanning technology and security analysts 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
- Unlimited 24/7 support
- Network and service scanning
- 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
- Web portal where the results are presented
SWAT subscription model is based on a number of applications and application instances that will be tested and monitored.
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 deployment 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 SWAT vs automated web application scanners
2.1 Application and business logic testing
Some types of vulnerabilities, will never be detectable using traditional vulnerability scanners and therefore they will never be reported, potentially resulting in false negatives. Web application scanners are limited technical solutions that are only capable of detecting technical vulnerabilities and will miss application logic issues while SWAT includes testing of both.
Typical fully-automated web vulnerability scanning will not be able to detect logical or contextual flaws within the applications. A fully-automatic scanner might be able to assert that there are no technical problems with a certain piece of functionality, but it will not be able to test and exploit the logical aspects of it.
Consider an e-commerce store. Traditional scanners will be able to check for technical issues such as
SQL injections and Cross-Site Scripting attacks, but they won't be able to test what happens if you attempt to purchase a negative (i.e. -1) amount of products.
A scanner will for instance detect and report missing HTTP security headers or outdated TLS ciphers but will not be able report that someone else can send messages as you from a chat app, that the copy of your ID you uploaded when you applied for a bank account can be viewed and downloaded by anyone on the Internet or that unauthorized users can read your records in the medical records system app.
Automatically generated reports from traditional scanners will require more work to consume and comprehend, as findings need to be checked. Since these scanners can't perform full classifications, they will in addition to false positives also report multiple similar (or at times identical) vulnerability findings. SWAT analysts verify all vulnerability findings and as such never report any false positives.
SWAT solves all of this by properly verifying, classifying, and grouping the vulnerabilities according to the specific vulnerability. All findings will contain a clear step-by-step list of instruction on how to reproduce the issue, together with detailed references and mitigation options tailored for the monitored application.
Everything in the SWAT report is targeted towards enabling whoever is reading it to quickly understand the issue and implement the proper remediation.
1 Access to the applications
The Snapshot analyst team is based in Sweden and Denmark. The testing will originate from one of the following network ranges:
To avoid interference, this network range should be whitelisted 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 restrict the whitelist to. Outpost24 owns the entire 188.8.131.52/24 so there shouldn't be any concerns about traffic coming from anyone else than from Outpost24.
2 Test accounts
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 one 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).
3 Applicable documentation, tokens and hardware
Some applications may have specific requirements in regard to 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
- APIs, which require detailed documentation in order to achieve adequate testing coverage
Please provide SWAT with the means required for executing all regular functionality. SWAT 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.
4 Explicit exceptions excluded functionality and test cases
SWAT will track the testing coverage and note all test cases which could not successfully be executed.
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 via the
The following tests are NOT executed as a part of the SWAT delivery:
- 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.
The approach for onboarding new web applications consists of the following steps:
- Fingerprinting and enumeration techniques to gain an understanding of the configuration of the web application
- Initial web application assessment with manual penetration testing. In this stage the manual penetration testing of the web application is performed by dedicated and skilled team of SWAT analysts who carefully assess all security aspects of the web app. This is also used as a baseline for continuous monitoring of the web application and the setup in the SWAT customer portal. For each discovered finding a safe proof of concept is created, all recreation steps are carefully described and clear solution suggestions are provided.
- Setup of the web application in the SWAT portal for continuous monitoring This stage involves setting up the web application for automatic security scanning and monitoring according with all requirements discussed during the initial meeting.
A large part of the SWAT delivery consists of manual penetration testing. The tests will be triggered by the following conditions:
- in the onboarding phase when the project is started
- 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 or the underlying platform is disclosed
- when verification requests are submitted by the customer
- regular reviews (quarterly at minimum)
At least four (4) reviews are performed within a license year; one (1) initial penetration test and three (3) additional reviews of the monitoring setup, which involve penetration testing activities. Whenever the application changes, or a new possibly applicable vulnerability is disclosed, additional manual tests will be performed.
SWAT analysts use the methodology as described by OWASP, OSSTMM and good practices as described by several standards, like e.g. the ISO27001 standard and PCI DSS.
The testing focuses on Application, Presentation and Session layers of the OSI. This includes examination of the implementation of the HTTP protocol, WebSockets, TLS, other encryption layers, 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.
Depending on the application itself tests for the following vulnerabilities will be performed:
- Cross-Site Scripting
- SQL Injection
- Remote File Inclusion
- Local File Inclusion
- Code Injection
- Command Injection
- HTTP Response Splitting
- Cross-Site Request Forgery
- Directory Indexes
- Format String Issues
- Path Disclosure
- Security Misconfiguration
- Sensitive Information Disclosure
The web application security analysts will besides Outpost24’s own testing platform, use tools available on the Internet and on the market to perform the penetration testing, these tools are not limited to open source tools but Outpost24 will procure any license needed for such tools without additional costs to the customer.
Applets or other compiled plugins (Java, Flash, ActiveX) are tested on the HTTP level, any deeper testing/reverse engineering of the compiled plugins may be performed but is not included in the standard SWAT subscription and continuous monitoring of these legacy technologies will be limited.
Code analysis/source code review is not included in the SWAT service.
1 “Zero-day” vulnerability disclosure
Any zero day threats discovered by the analysts in standard components utilized by the web applications are reported immediately to the customer and coordinated with the component vendor through responsible disclosure.
2 Finding verification
In order to eliminate false positives, all findings are verified and confirmed by the analysts. During the verification process the analysts clearly describe the recreation steps and include it in the report in order to simplify the remediation for the development teams.
As SWAT is a continuous monitoring solution, it will monitor the web application 24/7. Since each web application is different, the frequency and type of the different vulnerability tests depends on the structure of the web app and the used components. This is something that is adjusted in the setup phase. The crawling process that provides information about modifications in the application will run at least daily ensuring maximum coverage. Whenever a new vulnerability is disclosed, automated or semi-automated tests will be performed to verify if the vulnerability is applicable to the monitored web applications.
Manual testing will most often be performed during Swedish office hours.
1 Vulnerability feeds
The technical solution uses Outpost24’s own vulnerability database built with data gathered from multiple publicly available vulnerability databases like NVD, OSVDB, vendor advisories and Outpost24 own research and is updated at least once a day.
2 Impact and production safety
SWAT was designed with focus on public live web applications and therefore causes less impact than traditional approaches. Since all the tools are operated by trained analysts, the actions of the tools are strictly controlled and monitored to prevent them from being disruptive or affect the state of the web application. The vulnerabilities are reported as soon as they are confirmed, and no further exploitation is performed unless the customer gives us permission to proceed.
The scanner contains a crawler module. The analysts will refrain from invasive testing, but should there be content on the page which causes an unexpected behavior such as for example non-circular error logs, there may be situations where an error log of a production environment component fill the storage units - hence causing a permanent DoS effect on the system level. This is nothing the analysts can observe as an external tester/assessor, but it will be observed as the system going down. This would happen to the system eventually with or without the analysts’ involvement as the logs grow, but it is triggered by the testing.
If XML External Entities (XXE) is tested for, this can be done via test cases for an echoed response, a remote request/inclusion, or via an XML entity expansion. The SWAT analysts as well as the SWAT scanning platform will never perform the last test as that one if it works will likely crash the web server engine on the system by an out of memory exception, the other methods are however non-disruptive and will be used.
Denial-of-Service vulnerabilities are not in scope of the SWAT security testing, any potential DoS vulnerabilities are coordinated with the customer before any additional testing occurs.
The amount of traffic generated by SWAT is as high as it's 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.
The amount of the generated traffic depends on the size of the web application and therefore no exact measures 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 thresholded and delayed in multiple ways
The impact on the web application can usually be compared to a few users visiting the website and performing some actions in the web application simultaneously.
Hence - SWAT is intended for production environments, but its production safety is context dependent. It is far nicer in its test cases than fully automated web application scanners which will issue also potentially disruptive SQL statements as attempted injections.
In fact, we at Outpost24 use SWAT for monitoring of our own Internet facing applications where availability is of high importance to us and our clients!
3 Change detection
The changes that are detected are anomalies in the web application deviating from the baseline established in the onboarding phase. These changes are modifications that could introduce security issues so changes like a new standard component, a new/changed pattern in the served content, changes in the scope included from external domains, new input vectors caused by new forms or interfaces and similar will be detected and may trigger manual reviews.
SWAT covers the entire application as scoped and a part of the service is that new content, functionality, and changes is included. Since the entire application is covered, this means that the customer has an opportunity to replace every single function of the web application. It's similar to the "Ship of Theseus" thought experiment; how many pieces of a thing can you replace before you end up with a new thing?
If SWAT is monitoring an e-commerce store, the subscription will remain active even if the customer modifies, edits, upgrades, etc, the application. However, if the store application is replaced with a banking application, a file hosting application or an application with a completely different purpose, a new subscription will have to be obtained to keep the accuracy of the report. The subscription is tied to the originally scoped application and cannot be transferred to the new application.
Major changes (e.g. upgrade an e-commerce store from one version to another or change of the e-commerce solution if the features are comparable) are included if and only if the functionality is comparable and the purpose of the application remains the same.
The vulnerability report generated by SWAT can be accessed by the customer in the Outpost24 portal at https://outscan.outpost24.com/. The report is tied to the customer account, and the customer can decide which people within their organization should have access to the vulnerability report, and what actions they can take in relation to it. Please note that the report will contained detailed information about detected vulnerabilities, and it is recommended that the customer only approve access for authorized personnel.