144 lines
9.1 KiB
Typst
144 lines
9.1 KiB
Typst
#import "helper.typ"
|
||
|
||
#let cover(title, author) = {
|
||
// Define page
|
||
set page(
|
||
paper: "a4",
|
||
background: [
|
||
#image("title.png")
|
||
],
|
||
margin: (
|
||
top: 50%
|
||
)
|
||
)
|
||
// Reset counter
|
||
counter(page).update(n => n - 1)
|
||
|
||
text(size: 32pt, [
|
||
#text("Penetration Test Report")\
|
||
#text(title, weight: "black")
|
||
])
|
||
|
||
v(0pt)
|
||
|
||
text(size: 16pt, [
|
||
Düsseldorf, #datetime.today().display("[day].[month].[year]") • #author
|
||
])
|
||
}
|
||
|
||
#let toc() = {
|
||
outline(
|
||
title: "Table of contents",
|
||
indent: 10pt,
|
||
depth: 2
|
||
)
|
||
|
||
pagebreak()
|
||
}
|
||
|
||
#let legal(author) = {
|
||
// Define page
|
||
set page(
|
||
paper: "a4",
|
||
)
|
||
// Reset counter
|
||
counter(page).update(n => n - 1)
|
||
|
||
block(height: 1fr)
|
||
|
||
show heading: it => {
|
||
v(1em)
|
||
par(text(it.body, fill: gray))
|
||
}
|
||
text(fill: silver,
|
||
[
|
||
#heading(level: 2, outlined:false, "Report Version & Authorship")
|
||
|
||
#table(
|
||
columns: (15%, 15%, 40%, 30%,),
|
||
align: center,
|
||
stroke: gray,
|
||
[*Version*], [*Date*], [*Author*], [*Changes & Comment*],
|
||
[#helper.placeholder("Draft")], [#helper.placeholder("01.01.1970")], [#helper.placeholder(author)], [#helper.placeholder("Some")]
|
||
)
|
||
|
||
#heading(level: 2, outlined:false, "Classification")
|
||
This report and all associated materials are strictly confidential and may be communicated and/or distributed by the Client only with written approval of the author. All report data, including findings and recommendations, may be stored encrypted in the author's secure archive for a minimum of 3 months post-engagement, in compliance with applicable data protection regulations.
|
||
|
||
#heading(level: 2, outlined:false, "Legal Disclaimer")
|
||
This report constitutes the professional findings of a penetration test conducted under the scope and terms agreed upon by the client. All results reflect the state of security vulnerabilities as assessed during the engagement using standardized methodologies and tools. The findings presented are not guarantees of security or compliance; they represent identified weaknesses which may require remediation as by the professional impression of the author.
|
||
|
||
The client is responsible for interpreting these findings within their operational context and for implementing appropriate security measures. No liability is assumed for actions taken based on this report. This assessment does not constitute security certification, and its results are valid only for the scope and timeframe of the engagement. Neither the contents of this document nor the expressions of the author in any form are legal advice.
|
||
])
|
||
}
|
||
|
||
#let ciaAppendix() = {
|
||
[
|
||
== CIA Triad
|
||
|
||
The CIA triad is a fundamental framework for information security that encompasses three important principles: confidentiality, integrity, and availability. In this report, each of the three principles is used to highlight specific aspects of the security implications for the area under observation. All three principles are explained in more detail below.
|
||
|
||
=== Confidentiality (C)
|
||
The principle of confidentiality means that information is only accessible to authorized users or entities. It protects sensitive data from unauthorized access or disclosure through measures such as encryption, access controls, and data classification. By maintaining confidentiality, companies reduce the risks of data breaches and unauthorized disclosure, thereby preserving the privacy and trustworthiness of their information assets.
|
||
|
||
=== Integrity (I)
|
||
Integrity preserves the accuracy, consistency, and reliability of data. It prevents unauthorized changes, deletions, or falsifications through techniques such as checksums, digital signatures, and access controls. By maintaining data integrity, companies ensure the reliability and credibility of their information assets, thereby minimizing the risk of fraud or manipulation.
|
||
|
||
=== Availability (A)
|
||
Availability ensures the smooth and reliable provision of information. Potential interruptions to services, systems, or networks are mitigated through redundancy, failover mechanisms, and disaster recovery planning. By maintaining high availability, companies maintain operational continuity and user satisfaction by mitigating the impact of downtime or failures. At the same time, the unavailability of information can have serious consequences, such as lost revenue.
|
||
]
|
||
}
|
||
|
||
#let cvssAppendix() = {
|
||
[
|
||
== Common Vulnerability Scoring System (CVSS)
|
||
|
||
The Common Vulnerability Scoring System (CVSS) provides a standardized, vendor- and platform-agnostic methodology for quantifying the technical severity of software, hardware, and firmware vulnerabilities. Its outputs deliver numerical scores that contextualize a vulnerability’s risk relative to others, facilitating consistent prioritization across diverse systems. CVSS is structured around three interdependent metric groups: *Base*, *Temporal*, and *Environmental*. The Base Score captures the inherent characteristics of a vulnerability (e.g., exploitability, impact), assigning it a severity rating under idealized conditions. Temporal Metrics dynamically adjust this base score based on time-sensitive factors like exploit availability or the existence of patches. Finally, Environmental Metrics tailor the severity assessment to an organization’s specific deployment, accounting for mitigations, criticality of affected assets, and other contextual factors unique to the environment.
|
||
|
||
The only metric group that can be calculated without deep knowledge of the environment and situation is the Base Score, as the Base Score reflects intrinsic vulnerability characteristics (e.g., exploit complexity, impact on confidentiality/integrity) and is designed to be vendor-neutral and environment-agnostic. It does not account for the specific client’s infrastructure, patch status, or operational context. Since a penetration test reports on a single target environment, the Base Score represents the objective severity of the flaw within the scope of the test (e.g., "this flaw could be exploited in this network").
|
||
|
||
The version of the Common Vulnerability Scoring System used in this report is 3.1#footnote("https://www.first.org/cvss/v3-1/user-guide").
|
||
|
||
=== Attack Vector (AV)
|
||
|
||
This metric quantifies how remotely an attacker can exploit a vulnerability, directly influencing the Base Score:
|
||
|
||
- *Network (N)*: Highest severity. Attack possible from anywhere on the internet (e.g., sending a malicious packet across routers).
|
||
- *Adjacent (A)*: Moderate severity. Exploit limited to local networks (e.g., same subnet, Bluetooth/Wi-Fi, or secure VPN).
|
||
- *Local (L)*: Lower severity. Requires local access (console/SSH) or user interaction (e.g., phishing a document).
|
||
- *Physical (P)*: Lowest severity. Requires direct physical contact (e.g., evil-maid attacks, cold boot, DMA via USB).
|
||
|
||
=== Attack Complexity (AC)
|
||
|
||
This metric quantifies the technical difficulty of exploiting a vulnerability, independent of user interaction. It directly impacts the Base Score:
|
||
|
||
- *Low (L)*: Attack is repeatable and predictable with no special conditions. Example: Exploiting a buffer overflow in a service accessible via network.
|
||
- *High (H)*: Exploit requires attacker preparation or external factors, reducing reliability. This may include:
|
||
- Gathering target-specific knowledge (e.g., configuration settings, shared secrets).
|
||
- Overcoming mitigations (e.g., race conditions, anti-exploit techniques).
|
||
- Network manipulation (e.g., man-in-the-middle attacks).
|
||
- Example: Exploiting a flaw requiring a victim’s browser to accept a malicious file.
|
||
|
||
=== Privileges Required (PR)
|
||
|
||
This metric measures the attacker’s initial access level needed to exploit a vulnerability, directly impacting the Base Score:
|
||
|
||
- *None (N)*: Highest severity. Exploitable by unauthorized attackers with no prior access (e.g., unauthenticated web attack).
|
||
- *Low (L)*: Moderate severity. Requires basic user privileges (e.g., standard account access to non-sensitive resources).
|
||
- *High (H)*: Lowest severity. Needs administrative privileges to access critical system settings/files (e.g., root/superuser access).
|
||
|
||
=== User Interaction (UI)
|
||
|
||
This metric assesses whether a vulnerability requires human involvement (beyond the attacker) to be exploited, directly influencing the Base Score:
|
||
|
||
- *None (N)*: Highest severity. Exploitable without user action (e.g., automated network attack).
|
||
- *Required (R)*: Lower severity. Requires user interaction (e.g., clicking a malicious link or installing software).
|
||
|
||
=== Scope (S)
|
||
|
||
This metric determines if a vulnerability breaches security boundaries, allowing impact on components outside its original security scope (e.g., an app exploiting a database). Directly impacts Base Score severity:
|
||
|
||
- *Unchanged (U)*: Lowest severity. Vulnerability only affects resources within the same security authority (e.g., a web app affecting its own files).
|
||
- *Changed (C)*: Highest severity. Vulnerability crosses security boundaries, impacting components under different authorities (e.g., a compromised web server accessing a database).
|
||
]
|
||
} |