Attack Surface Analysis

Performing an Attack Surface Analysis includes analyzing the security architecture to identify and document product interfaces and surfaces that could be attacked, as well as consider if there are planned security measures that will provide enough protection against attacks on these surfaces.

Attack Surface Analysis

• Why
  The Attack Surface Analysis will make you aware of the entry points that an adversary can use to enter the system. It includes open ports, code that processes incoming data, user interface forms and fields, keys, valuable data, APIs, files, and run-time arguments among others.
  By minimizing the attack surface the risk for potential damage to the system can be reduced. When the product is implemented, tools can be used to verify/analyze the attack surface.

• When
  The Attack Surface Analysis is initially done during the design phase, but it is recommended to update it during the implementation phase when further details about e.g. ports, services, registry keys etc. may be available.
  For a Roll-Up, TC, CC, or Service Pack the existing Attack Surface Analysis should be updated, if needed.

• Who
  The Architect is the responsible role.

• Where
  The analysis is normally performed on product or component level.

• What
  The Attack Surface Analysis is a complement to the Threat Model. It can be seen as specific view of the Threat model with the purpose to give an overview of certain interface types and listing the attack surfaces. The analysis should cover interfaces, with particular attention to interfaces allowing access across a trust boundary. Make sure the sub-paragraphs below under Attack Surface Analysis, are covered (e.g. Network attack surface, Files and folders, etc.).

  The following information should be provided:

  • What data the interface exposes.
  • How the interface can be accessed
  • What user roles are expected to use the interface.
  • How the interface is used.
  • Third-party product used to implement the interface.
  • Impact on system/product/component security by exposing the interface.
  • Security considerations, assumptions and/or constraints including applicable threats.
  • What protection mechanisms the interface has.
  • How threats are mitigated (refer to threat model).
  • If data flows across trust boundary (refer to threat model).

• How
  The result of the analysis can be documented as tables listing all considered attack surfaces and planned security measures, similar to the examples below.
  Following the table there could be sections describing the used security measures, alternatively refer to such a description in the security architecture document.
  If the complexity of the product is very low the details requested by the Attack Surface Analysis could be combined into the Threat Model.

• Inputs to the analysis (examples)

  • Attack Surface Analysis from the previous release can be updated with a new revision for the current release.
  • DSAC application from previous release that contains useful information about protocols/ports.
  • Security architecture description including security context (note that the outcome of the analysis may differ for a different security context).
  • Description of Function that cover product interfaces.

Network attack surface

A product’s network attack surface mainly consists of the connections that the product creates or enables.
Both client and server ports shall be described.
Following the table there could be sections describing the used security measures or references to such descriptions in the security architecture document.
This description shall match the information in the product’s security deployment guide as much as possible. If there is a mismatch an effort should be made to harmonize them to decrease the attack surface.
If the analysis concluded that the attack surface can be made smaller than what the security deployment guide describes, this should be described in the Attack Surface Analysis document and this description should be used as input for an improved security deployment guide. Shortcomings in the security deployment guide should not be brought to the attack surface analysis. One example is that all properties for identified network connections should be described in the attack surface analysis even if the security deployment guide only lists some of them.
More specifically: it shall be described which process that serves each specific port and which nodes that use the connection even if this information is missing in the security deployment guide.

Example of Network Attack Surface documentation

Server/Receiver Node	Protocol/port ​	Server/Receiver Process	Client/Sender Node	Client/Sender Process	Comment	Security Measures
	TCP/2500	%Program-Files(x86)%\ABB...\bin\opc_server.exe	any client	%Program-Files(x86)%\ABB...\bin\opc_client.exe	OPC/DCOM traffic	Windows Firewall IPsec
CI871/PROFINET device	UDP/34964 + 0x0400-0x0463/L2		PROFINET device/CI871		PROFINET Communication	see UDP/34964 + 0x0400-0x0463/L2
system server nodes	Protocol X (TCL/port xxx)	ServerServiceX.exe (Windows Service)	System client nodes	Client process Y	System function Z	See Protocol X security below

UDP/34964 + 0x0400-0x0463/L2:
CI871 PROFINET IO does not implement any secure protocols. All implemented protocols are mandatory and have no secure counterpart.
A default exceptions for PROFINET and for NTP exist in 9AKK107045A0795 Default Exceptions for the Minimum Cyber Security Requirements for Products.

Protocol X Security: • Authentication method (e.g. username/password authentication, Certificate-based authentication) • Integrity protection method (e.g. packet signing using design pattern XXX)
• Confidentiality protection method (e.g. Packet encryption using design pattern XXX)
• Availability measures (e.g. session/rate limitations to prevent DoS attacks, load balancing to distribute traffic evenly across servers redundancy and failover mechanisms to ensure continuous operation) • Authorization (e.g. which users/groups/roles can use the service? Can it be accessed from anywhere on a routed network or only on the same subnet as the product?)

Files and folders

List the file types and folders that the product read from or write to and sections describing the used security measures, alternatively references to descriptions in the security architecture document.

Example of Files and folders documentation

File type	Folders ​	Usage	Security Measures
.EXE	%ProgramFiles(x86)%\ABB Symphony Plus\Operations\SV3\bin	Runtime	ACL
File type X	Folder Y	Engineering data storage	See File type X Security below

File type X Security: • Access Control List (e.g. which authenticated users can access the files/folders)
• Integrity protection method (e.g. file signing using design pattern XXX)
• Confidentiality protection method (e.g. file encryption using design pattern XXX character add)

Application interfaces

Describe the API of the component/product (e.g. HTTPS, OPC UA, COM/DCOM/WCF of a Windows application)
Describe if any parsing is done on the data entered through the API.
Describe restrictions for use (hardening).
Describe if authentication/authorization is used.

Windows Registry

Describe the type of data that the product stores in the Windows registry and how the locations are protected. This could be documented in a similar way to how files and folders were documented.

Debug ports

ABB highly recommends to remove debug ports used during the dvelopment from production hardware. If debug ports are present describe the debug interfaces and how to protect them from unauthorized access.

User Interface

Describe which users can access the user interface and the coverage of the authentication/authorization.
Describe the security implications, if any, of the interface. Describe if any parsing is done on the data entered.
Describe input validation of the data entered.

Start-up/boot

Describe the data that is loaded at start-up/boot and how it is validated/authenticated.

Verification with tools

If possible, tools should be used to verify the attack surface. The used tools should be listed in the analysis documentation.
There are different tools that are suitable for different types of attack surface. Below are some examples .

• Nmap, Nessus, Resource Monitor

  It is optional to use network scanning tools like Nmap or Nessus for attack surface analysis (however it is mandatory to use Nmap and Nessus for Pre-DSAC tests).
  These tools can be used for all types of products that communicate via IP.
  In Windows, the Resource Monitor tool can also be used to show TCP connections and listening ports. The output of these tools can be used to verify that the list of protocols/ports in the attack surface tables is complete.

• Lynis

  It is an optional open-source tool that can be used for security auditing, vulnerability detection, system hardening, compliance snd penetration testing.

• Microsoft Attack Surface Analyzer

  It is optional to use Microsoft Attack Surface Analyzer. The attack surface of a Windows Application can be analyzed by analyzing the attack surface of the computer where the application is to be installed before and after the application was installed and used. The difference between these should be caused by the installed application. Microsoft has a tool called the Attack Surface Analyzer that can do this type of analysis. The tool can be downloaded from Microsoft’s website.

Other Attack Surfaces

Describe other kinds of attack surfaces that are not covered by the previous chapters, e.g. hardware ports.

Attack surface reduction

Attack surface reduction is the process of finding ways to reduce the attack surface to a minimum.

1. The first step is to consider if the surface/function/feature is needed or if it can be removed. If a feature is not used by many users and there is a significant cost for adding protection, it should be considered to simply remove the feature.

2. The second step to consider is if the exposure of the surface/function/feature can be reduced. Here are some examples of reduction:

   • Allow an interface to be accessed locally but not remotely.
   • A function/feature is turned off by default.
   • A function/feature is only accessible for an authenticated and authorized user, not all users (and never anonymous users).
   • Making sure a user/process/application only gets the needed privilege, never more.
   • Making sure a user/process/application only accesses the needed information, never more.
   • Minimize code that executes by default.

3. The third step is to suggest protection for the attack surface. At this stage, think about the main risks and suggest the obvious security measures for protection. A detailed analysis of threats and mitigations need to be handled by Threat Modeling.