Reports
Purpose
This document describes how to generate and download reports in the new portal interface.
Introduction
After scanning your environment, Vulnerability Reports can be exported for one or more assets. The reporting tools gather all the relevant findings and lets you export them in various formats.
Requirements
It is assumed that the reader has basic access to the OUTSCAN/HIAB account.
Reports
Vulnerability Reports
Vulnerability Reports can be exported for one or more assets from two places:
- Assets
- Findings → Vulnerabilities
These reports contain all vulnerability findings associated with the selected assets.
Compliance Reports
Compliance reports can be exported for one or more assets from two places:
- Assets
- Findings → Compliance
These reports contain compliance requirements and their status for the selected assets.
View Templates
Reports uses View Templates to filter the reports by predefined templates. There are some built in templates but more can be customized by the user.
Generate Report
From the Assets view:
- Select one or more assets.
- Click on the Generate report icon located at the bottom right of the view
or from the menu when right-clicking the asset.
From the Findings→Vulnerabilities view:
You can generate a report by selecting one or more assets in the left Assets pane of the view.
- Select one or more assets.
- Click on the Generate report icon located at the bottom right of the respective column.
From the Findings→ Compliance view:
- Select one or more assets.
- Click on the Generate report icon located at the bottom right of the respective column.
In any of the above cases, you are prompted with the Generate Report window.
Select the type of the report to be generated and click NEXT.
Note the optional template for filtering the report.
Here you can re-check the scope for the report. After confirming the scope, click NEXT.
Choose the report format and the level of details and click NEXT.
Select how detailed the generated report should be. See Report Levels for more information.
A report can be exported in the most commonly and widely used document formats.
The available reporting formats are:
PDF - This is the most commonly used reporting format.
Excel - The reports generated using excel format, have a lot of tabular information, which can be useful when reporting information to IT/Security department or similar divisions.
XML - This format is the default industry standard used for data exchange and integration. The reports generated in XML format are typically used for integration and automation.
Select if the report should be compressed or if it should be password protected and NEXT.
Choose the report delivery type:
Select Download to generate a report to be available under the All Downloads button in the right corner of the toolbar. See Download Report for more information.
If you select Download, you cannot configure the report schedule.
- Select Send by email and enter one or more users to send the generated report by email.
Select Send to Report Library and enter a name and a tag for the report to save the generated report in the Report Library.
Reports can be scheduled for reoccurring delivery by linking a report to an existing schedule or add a new schedule.
The available options are:
Option Description Scheduled report name Provide a name for the Scheduled report. Schedule name
Provide a name for the schedule. Time
Set a time with a timezone when the schedule must be triggered. The time value is saved in UTC (Coordinated Universal Time) and the offset corresponds to the system time in the user web browser and therefore might differ for users accessing the schedule options in different time zones.
Example: A schedule time set to 10:00 in July (summer time) by a user located in Copenhagen (UTC+2) appears as 09:00 to a user located in London (UTC+1) at the same time.
Recurrence / Every Determines the frequency of the schedule. Select one of the available options in the menu:
Option Description None Once The schedule is set to run only once on a select start date. Hour Set the recurrence window by providing the Number of Hours. Day Set the recurrence window by providing the Number of Days in this field.
Example: If set to 2, it means that the schedule runs once in every 2 days.
Week Select the days of the week for the schedule. Month Select the occurrence of days, weekday, day of the month for the schedule. Year Select the day of year for the schedule. On these days Determines what days of the week the schedule should run. Select one of the available options in the menu.
Occurrence of the weekday Determines occurrence of the selected weekday the schedule should run.
2,3 - will schedule 2nd and 3rd selected weekday in the month
Day of the month Determines what day of the month the schedule should run.
4,8,10 - will schedule 4th, 8th, and 10th day of the month
Starts on Set the start date for the schedule. Ends on Set an end date for the schedule. The schedule becomes inactive after this date. Ends after_occurrences Set the number of occurrences the schedule must be triggered before it becomes inactive. Never ends If set, the schedule never becomes inactive. Click NEXT to create the scheduled report. The scheduled reports can be viewed under Automation in the task bar.
Set the time frame for the report.
The time frame chosen indicates that the report should cover the findings within the selected time frame.Example
When you select Last month, all findings seen in the last month is then included in the report.
Choose Custom to select the dates to include the findings found during that period in the exported report.- Click on GENERATE button.
If all assets or asset groups related to a scheduled report configuration are deleted, the scheduled report configuration will be automatically removed.
Download Report
The Download Report view presents the list of generated reports that are ready to be downloaded:
To download a report:
- Click the All Downloads icon to the upper right of the window.
- Select the report you want to download in the list and click the Download icon.
Report Levels
The detail level can be adjusted based on the target recipient of the report. The amount of information varies in each type, thus making each report exclusive depending on the functionality and audience. There are three report levels available:
- Management
- Summary
- Detailed
All reports contain the following sections:
- Title page
- Report information
- Executive summary
Additionally, depending on the selected report level, the following sections will be included:
| Report Type / Report Level | Management | Summary | Detailed |
|---|---|---|---|
| Technical details | (no additional sections) | Web application summary | Web application summary |
Title Page
This is the first page of each report with the title and the date when the report was generated:
Name and content may differ between Management, Summary, or Detailed reports.
Report Information
This section contains the generic information about the report:
Executive Summary
The Executive Summary shows the trend information, risk families and solutions. It provides a highly visual overview which is informative and useful to report findings to the top management:
Risk Summary
This section provides the information like, number of findings and their severity, number of virtual hosts discovered, and scanning interval.
Risk Details
The Risk Details section provides information such as Risk factor, CVSS scores, Description, Status, CWE, CAPEC, OWASP, Impact, Solution among others.
The Risk Details are only available when selecting a detailed report.
Methodology
Activities
Explicit Exceptions
The following tests were not executed during the testing:
Denial of Service Attacks - The result of a denial of service attack might cause the application to cease normal behavior. Therefore, attacks of this type will not be executed, unless explicitly requested by the customer.
Social Engineering - In social engineering, an adversary attempts to gain access or otherwise manipulate an application by attacking the people and employees with privileged access, e.g. by enticing them to divulge information.
Physical Security - Physical security is the protection of personnel, hardware, programs, networks, and data from physical circumstances and events that could cause serious loss or damage to an enterprise, agency, or institution.
Purpose
Outpost24 AB has executed web application tests for the customer.
The objective of these tests was to get an impression about the information security of the web applications and the environment. Based on the test results Outpost24 AB will compile a vulnerability report, and give recommendations for improvements where applicable.
The end result will be that the customer will gain insight about the robustness and security of their applications. Conclusions will be provided with clear suggestions for operational solutions and managerial focus, leading to heightened IT security.
OWASP Top 10 2021 Description
The OWASP Top Ten is a powerful awareness document for web application security, which represents a broad consensus
about what the most critical web application security flaws are.
A01 | Broken Access Control | Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits. |
A02 | Cryptographic Failures | Poor protection of data in transit and/or at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS). |
| A03 | Injection | Injection flaws occur when an attacker can manipulate user input to inject malicious code into an application as part of a command or a query and execute it. This can lead to data loss, corruption, or unauthorized access to sensitive data. |
| A04 | Insecure Design | Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design". An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. |
| A05 | Security Misconfiguration | Security misconfigurations occur when security features are not configured properly. This includes presence of improperly configured permissions, default accounts and their passwords, stack traces or overly verbose error messages as well as poor hardening of the used frameworks and libraries leaving systems and applications vulnerable to attacks. |
| A06 | Vulnerable and Outdated Components | Vulnerabilities introduced by the use of third-party or open source components with known security issues. These components may contain unpatched vulnerabilities, which can be exploited by attackers to gain unauthorized access, steal data, or execute malicious code. |
| A07 | Identification and Authentication Failures | Vulnerabilities related to the verification of user identity and access control. This can include weak password policies, lack of multi-factor authentication, insufficient user validation, and improper session management. These vulnerabilities can be exploited by attackers to bypass authentication mechanisms, impersonate legitimate users, gain unauthorized access to sensitive data or functionalities, and conduct other malicious activities. |
| A08 | Software and Data Integrity Failures | Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. |
| A09 | Security Logging and Monitoring Failures | Lack of proper logging and monitoring of security events. This can include issues such as missing or incomplete logs, insufficient monitoring, and inadequate incident response procedures. These vulnerabilities can be exploited by attackers to evade detection and remain undetected on the affected system for an extended period, leading to further compromises and data theft. |
| A10 | Server-Side Request Forgery (SSRF) | SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL). |
Common Vulnerability Scoring System (CVSS) v2 Description
The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat. Scores are calculated based on a formula that depends on several metrics that approximate ease of exploit and the impact of exploit. Scores range from 0 to 10, with 10 being the most severe. While many utilize only the CVSS Base score for determining severity, Temporal and Environmental scores also exist, to factor in availability of mitigation and how widespread vulnerable systems are within an organization, respectively.
Access Complexity (AC)
| Metric Value | Description |
|---|---|
| High (H) | Specialized access conditions exist. For example: In most configurations, the attacking party must already have elevated privileges or spoof additional systems in addition to the attacking system (e.g., DNS hijacking). The attack depends on social engineering methods that would be easily detected by knowledgeable people. For example, the victim must perform several suspicious or atypical actions. The vulnerable configuration is seen very rarely in practice. |
| Medium (M) | The access conditions are somewhat specialized; the following are examples: The attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted. Some information must be gathered before a successful attack can be launched. The affected configuration is non-default, and is not commonly configured (e.g., vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme). The attack requires a small amount of social engineering that might occasionally fool cautious users (e.g., phishing attacks that modify a web browser's status bar to show a false link, having to be on someone's "buddy" list before sending an IM exploit) |
| Low (L) | Specialized access conditions or extenuating circumstances do not exist. The following are examples: The affected product typically requires access to a wide range of systems and users, possibly anonymous and untrusted (e.g.,Internet-facing web or mail server). The affected configuration is default or ubiquitous. The attack can be performed manually and requires little skill or additional information gathering. The "race condition" is a lazy one (i.e., it is technically a race but easily winnable). |
Access Vector (AV)
| Metric Value | Description |
|---|---|
| Local (L) | Vulnerability exploitable with only local access requires the attacker to have either physical access to the vulnerable system or a local (shell) account. Examples of locally exploitable vulnerabilities are peripheral attacks such as Firewire/USB DMA attacks, and local privilege escalations (e.g., sudo). |
| Adjacent Network (A) | Vulnerability exploitable with adjacent network access requires the attacker to have access to either the broadcast or collision domain of the vulnerable software. Examples of local networks include local IP subnet, Bluetooth, IEEE 802.11, and local Ethernet segment. |
| Network (N) | A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow. |
Authentication (Au)
| Metric Value | Description |
|---|---|
| Multiple (M) | Exploiting the vulnerability requires that the attacker authenticate two or more times, even if the same credentials are used each time. An example is an attacker authenticating to an operating system in addition to providing credentials to access an application hosted on that system. |
| Single (S) | One instance of authentication is required to access and exploit the vulnerability. |
| None (N) | Authentication is not required to access and exploit the vulnerability. |
Confidentiality Impact (C)
| Metric Value | Description |
|---|---|
| Partial (P) | There is considerable informational disclosure. Access to some system files is possible, but the attacker does not have control over what is obtained, or the scope of the loss is constrained. An example is a vulnerability that divulges only certain tables in a database. |
| Complete (C) | There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.) |
| None (N) | There is no impact to the confidentiality of the system. |
Integrity Impact (I)
| Metric Value | Description |
|---|---|
| Partial (P) | Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited. For example, system or application files may be overwritten or modified, but either the attacker has no control over which files are affected or the attacker can modify files within only a limited context or scope. |
| Complete (C) | There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised. The attacker is able to modify any files on the target system. |
| None (N) | There is no impact to the integrity of the system. |
Availability Impact (A)
| Metric Value | Description |
|---|---|
| Partial (P) | There is reduced performance or interruptions in resource availability. An example is a network-based flood attack that permits a limited number of successful connections to an Internet service. |
| Complete (C) | There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.) |
| None (N) | There is no impact to the availability of the system. |
Test case appendix - SWAT
SWAT is a hybrid service delivery covering automated monitoring and web application scanning as well as at least quarterly penetration testing, including application logics, of web applications under service.
The test-cases are oriented around the OWASP TESTING GUIDE, and for the application the following controls has been performed. Note that a control will be marked as audited either if found present and audited, or were found not present and hence not auditable - This to show that the application has been audited for this class of risks.
Report Library
Report Library view is only available on OUTSCAN. When Send to Report Library option is selected on HIAB, the report is uploaded to your OUTSCAN Report Library.
Click on Report Library on the task bar to open the library, where the generated reports are saved.
- Tags can be added while generating the report. For more information about adding or removing Tags, refer to Common Settings.
- Click on a report to view its details on the right panel of the window.
- Click on Table View icon located on top right of the window to switch to table view. Re-click to view grid view.
- Click on the green Upload icon in the lower right corner to upload the downloaded reports. You can also drag and drop the reports to upload.
- Click on the Download icon on the report to download a saved report.
Related Articles
Copyright
© 2024 Outpost24® All rights reserved. This document may only be redistributed unedited and unaltered. This document may be cited and referenced only if clearly crediting Outpost24® and this document as the source. Any other reproduction and redistribution in print or electronically is strictly prohibited without explicit permission.
Trademark
Outpost24® and OUTSCAN™ are trademarks of Outpost24® and its affiliated companies. All other brand names, product names or trademarks belong to their respective owners.