All software systems exist in an insecure state, which creates the need for a way to conduct software attack surface analysis. This is because any useful system must connect in some way with the outside world and therefore contains at least one point of interaction with that world. These communication paths accept data / instructions into the system and report processing results out. Modern web-enabled software systems, as opposed to older client-server systems, are usually directly connected to the broader Internet. These connection points are required for the system to provide value to its stakeholders, but also represents opportunities for attackers to suborn the system.
In this blog post we will explore a visual modeling approach to attack surface discovery for rapidly identifying software system assets, evaluate various attack point vulnerabilities, definition of controls against those risks, and reporting evidence of attack mitigation.
Figure 1. Example Attack Surface Model
As shown in Figure 1, an Attack Surface Model is a technique for evaluating and assessing the vulnerabilities of a system that are potentially exposed and available for exploit. The purpose of this exercise is to identify the organizational assets that have value to an attacker and to associate them with appropriate risks. The model focuses on the external access points, or “surface”, of the target system as these are the most likely points for an external/internal actor to target for access. For example, a web-site hosted on a corporate network may be vulnerable from a variety of external exploits such as denial-of-service, cross-site scripting, unauthorized data exfiltration, and malicious code execution, just to name a few. To mitigate these exposed vulnerabilities a series of controls are established to either eliminate the vulnerability or educe the potential for exploit. Examples of controls for “data leaks” (aka unauthorized data exfiltration) include encryption, removal of unneeded sensitive/proprietary information, or anonymization of the data.
Identification of Assets
An organization’s assets are represented by any system, data, or artifact that has value. For example, a corporate human resources system contains highly sensitive and/or private data regarding compensation, bonus awards, equity awards, and the like. Exposure, loss, or corruption of this system will result in a high business, and possibly legal, impact. Identification and characterization of assets is beyond the scope of this post, but for more information please refer to the ISO 270001/2 standard. For the purpose of Attack Surface modeling, it is sufficient to identify all components of a software system that are potentially exposed to exploitation.
Table 1. Example Description of Software System Assets
| Asset | Description | Value Statement | Threat Profile |
|---|---|---|---|
| AEM Platform | AWS hosted Adobe Experience Manager development and testing environments. | Lower environments are essential to development efforts; loss or corruption of these will result in extra time/effort to recover functionality. | These platforms are hosted on the AWS cloud, which involves the Shared Security Model. The organization is responsible for the virtual machines, network configuration, and access management (i.e. not physical security of the data center). As A lower development environment this poses a moderate attack target. |
| Adobe SharePoint | This data store is used as the primary repository for AEM content deployment | Web-site content is versioned and maintained in this systems for use in public-facing web applications. | As publicly facing information, this represents a significant attack target. Loss or corruption may affect organization reputation, customer confidence, or limit system functional behavior |
Understanding Attackers
There are many possible motivations behind a software system attacker. An ‘extortionist’ may simply be after monetary reward to avoid causing damage to the target systems or reputation. A ‘vandal’ by contrast may be interested in causing as much damage as possible. Understanding the the types of attackers likely to target a particular system helps give insight into the means and mechanisms used by these actors, and in turn aids in identification of system vulnerabilities.
Table 2. Description of Attackers and Motivations
| Actor | Description | Goal | Motivation |
|---|---|---|---|
| Extortionist | This Actor is looking for opportunities to insert ransomware or other non-destructive ways of forcing the organization to pay for return of data and/or system capability. Typically the attack does not expose private data, but rather prevents approved access. | Force target organization to pay a ransom for return of data / system access. | Money and pride are key motivations. |
| Vandal | This Actor is looking to cause as much disruption and destruction of property as possible. They desire to disrupt the organization by blocking access, corrupting data, inserting false data, or otherwise co-opting production systems. | Disruption of business activities, degradation of organizational reputation, exposure to legal / governmental consequence. | Pride, activism, or revenge are key motivations. |
| Thief | This Actor is focused on accessing and acquiring valuable data. Typically, they will access systems covertly (sometimes for years) collecting private data on customers, clients, and any other target of interest. | Acquisition of private data for sale, business disruption, espionage, identity theft, or other means of producing profit from data theft. | Money is the primary motivation. |
Discovery of Risks/Vulnerabilities
Software systems, and in particular web-applications, are vulnerable to a variety of different attacks. Nefarious actors seek these attack points in order to uncover vulnerabilities that can be exploited to compromise the system. Shown in Table 3 is a short collection of such attack-points grouped under a general category of risks. There are many available resources to identify and detail potential risks, such as the Open Web Application Security Project®, the open-source National Vulnerability Database, the HITRUST Alliance, and the Center for Internet Security. By categorizing potential vulnerabilities, and rapidly discarding ones that are not relevant to the current investigation, the analysis space can be rapidly defined. For example, a web-application that is hosted by a cloud provider does not need to consider physical security of the servers (which is the shared responsibility of the vendor). Refer to Figure 1 for the hierarchy of risks, attacks, vulnerabilities, and exploits.
Table 3. Example Risks – Attacks – Vulnerabilities
| Risk | Attack | Vulnerability | Consequence | Description |
|---|---|---|---|---|
| System Operation | Insufficient Monitoring | Intrusion Awareness | Unknown unauthorized system access | Logging and monitoring is the process of performing and storing audit logs for sign-ins to detect unauthorized security-related actions performed on a framework or application that forms, transmits, or stores sensitive data. This vulnerability occurs when the security event is not logged properly and/or the system is not actively monitored. Lack of implementation of such practices can make malicious activities harder to detect, affecting the process by which the incident is handled. While logging and monitoring are universally important to all aspects of data security, this vulnerability becomes particularly acute when bad actors with valid credentials (such as Trusted Insiders) are enabled to traverse a system and exfiltrate data undetected due to lack of comprehensive access logs. |
| Platform Health | Reduced system availability / compromised behavior | |||
| Invalid Authorization | Session Spoof | X-Site Scripting | User session compromised |
Often initiated through “sniffing” (the grabbing of unencrypted network data through the use of a network controller in Monitor mode), the Session Spoof vulnerability is enacted when a highly qualified specialist actor obtains the identifiers (TCP Sequence Number and TCP Acknowledgement Number) of a user’s active web service session. The actor can then use the current identifiers to create a falsified data packet which can be sent from any internet connection to fool the service that the actor’s session is legitimate, providing the actor with access control of whatever credentials the user was implementing. Session Spoofing is rarely used by modern actors, as OS providers have developed defenses against these attacks; however, some estimates put the number as high as 35% of modern web-systems still being vulnerable to Session Spoofing. |
| Header Impersonation | User session compromised | |||
| Automated Response | User session compromised |
Definition of Controls
Controls are defined as technical, procedural, or administrative mechanisms used to prevent or mitigate one or more vulnerabilities (see ISO 270001, Annex A for details on control categories). For the Attack Surface Model the key points are the type of control, the specific vulnerability targeted, the mitigation mechanism, and the resulting evidence of mitigation. Examples of common controls are noted in Table 4. As part of the Attack Surface Model analysis approach, once a set of potential vulnerabilities are identified the next step is to investigate what (if any) controls have been applied. As also shown in Table 4, the mechanism used for mitigation (and the evidence of effectiveness) is tied to the way the control is implemented.
Table 4 – Example Controls and Mitigations
| Control | Target Vulnerability | Mitigation Mechanism | Evidence of Mitigation |
|---|---|---|---|
| Establish Secure Configuration Process for Network Infrastructure | Public port availability | Automated port access grant/restrict network configuration | Network port availability report |
| WebApp Firewall/AWS CloudWatch | Intrusion Awareness | Monitoring of network traffic for invalid sources and/or packet patterns |
|
| Load-balancer Alarm | Platform Health | Evaluation of platform operation via health-check (i.e. ‘heart-beat’ request). | System/Platform uptime report |
| Patch Process |
|
Ensuring timely application of all upgrade and security patches | Vulnerability mitigation report |
| SSH Secure Key Access | Log Data Access | Shared secret access management for platform logs | Implementation of SSH platform security with periodic key rotation |
Using the Attack Surface Model for Investigation
The key to an effective security investigation is to ensure a consistent, thorough approach. The model presented here provides guidance for such an approach, but should not be considered the only way to conduct attack surface modeling. In the end, it only takes one critical security miss to make the newspaper headlines.
Limit system scope to focus on a limited risk area. Taking on a large an initial investigation will result in confusion for the development teams. It will also provide opportunities for missed vulnerabilities. A good rule of thumb is to keep each investigation centered on a single functional area, such as a web-site or set of micro-services.
Work with risk areas as a unit, as controls are often related. By leveraging the various vulnerability similarities it is much easier to identify appropriate controls. For example, when considering data risks, a common control across a wide variety of vulnerabilities is to use encryption. Likewise, user session vulnerabilities can often be mitigated by using a properly configured web-server that leverages modern session management.
Eliminate potential vulnerabilities that are not relevant. For most systems, not all of the possible risks/vulnerabilities are present. As one example, session management is typically only relevant for web-based systems; a database management system would not have the same risks. Limiting the vulnerability space to a small set also helps with control identification for the reason given above.
Note areas of potential high risk consequence. Not all vulnerabilities are equal in the potential impact to the business. Therefore, it is a good practice to rank the identified vulnerabilities according to the value of the asset involved, and the potential consequence of a successful attack. Note all vulnerabilities without adequate mitigation and rank by consequence (i.e. Catastrophic, Major, Moderate, Minor).
Finally, all vulnerability mitigations require evidence of effectiveness. It is not enough to state in documentation that a particular control is in place, it is also necessary to show proof that the vulnerability has been mitigated. For example, if proxy-servers are used to control against unauthorized network access, then a periodic test must be run to ensure the network address configurations are still in place and functioning.
Conclusion
There are many techniques for performing security threat assessments. The Attack Surface Model approach has been shown to be effective and complete when investigating system vulnerabilities and controls. As this post illustrates, there is significant effort spent up-front to create a risk/vulnerability framework for a given set of assets. However, once built the same framework can then be applied across a wide variety of software / network systems. Therefore, this approach is recommended for critical business support systems as part of a full security assessment approach.
