Last updated at Fri, 22 Dec 2023 15:01:11 GMT
Attack Surface Analyzer, a tool made by Microsoft and recommended in their Security Development Lifecycle Design Phase, is meant primarily for software developers to understand the additional attack surface their products add to Windows systems.
As defenders, this tool can be very useful.
The tool is meant to identify changes on a system that can have an impact on security, such as the creation of new services, modification of firewall rules, and more.
This data is very valuable to you as a defender, as it'll allow you to understand the new software package you're analyzing, see if hardening measures are required, as well as see if the software will work under your current policies, if for example, you have strict firewall rules deployed to your regular workstations and servers.
Here's how it works and how to use the results.
Baseline
Baseline System
Before you can analyze the attack surface changes caused by a certain software package, you need to scan a baseline system. Ideally, the baseline system will be as clean as possible. Using a system that has been configured with the corporate standards can be useful, to see if the installer would modify settings, but use a baseline with as little 3rd party software installed as possible.
Ideally, a clean, vanilla Windows installation should be used.
As of September 14 2015, Microsoft ASA seemed to exhibit compatibility issues with Windows 10. Windows 8.1 was used for this article.
Baseline Scan
First, install the Attack Surface Analyzer.
The tool has command line options, and can be integrated to various testing and deployment processes, but for the purposes of this post, we'll use the GUI.
Make sure the "Run new scan" option is selected, then click "Run Scan".
The tool will then begin collecting data, which is saved to the CAB file specified on the previous window.
Once it has completed, it'll go back to the previous screen.
Product Scan
Installing Software
Install the software package you want to analyze, enabling all features.
If this software requires a reboot and/or to be run at least once before being completely set-up, make sure this is performed before running the product scan in the Attack Surface Analyzer.
In this example, we'll use the version of iTunes currently available on Apple.com: 12.2.2.25.
Scanning the Product
The product scan is simply another scan, performed after product installation, reboots and everything has been completed.
Run ASA, and select "Run a new scan". Make sure the filename is clear, then hit "Run scan".
Again, once the scan completes, we're brought back to the main window of ASA.
The Report
Now that we have two scans, we need to compare them and generate the report for the product we installed.
Select "Generate standard attack surface report" and make sure you select the right baseline and product files, then click "Generate".
Note: reports can be generated from any computer with the Attack Surface Analyzer installed, provided the scan files are available to it.
An HTML report will be generated, containing a summary, issues identified by the tool, as well as the attack surface report.
Using the Results
The results can be used to understand the software package, potential issues, but also to identify potential hardening steps to be undertaken after the deployment of this software.
While interpreting results, be careful not to assume every single change is related to the software package. There could be other reasons why changes happened at the time the scans were run. This is why using a clean machine is important, as it'll reduce the amount of noise significantly.
Using iTunes as an example, in the Attack Surface section of the report, we can see multiple changes made to the system which you might not want to allow in a corporate environment.
Firewall rules were added. A potential mitigation for this would be to control Windows Firewall rules centrally using GPOs, ensuring that these rules do not persist on systems where iTunes is deployed.
You can also see that iTunes registered multiple services, which are executed as Local System. Two of them are started automatically, and one is on demand. You can then use this information to create a GPO to deny the launch of these services, if they're not necessary to the particular use cases for this software on corporate workstations.
If the installer had created local accounts, they would also be identified in this report. Here, we see that the previously mentioned services are linked to the NT Service account.
Someone who enjoys puns could say we're only scratching the surface of the information this tool can provide.
By running it on software packages that are to be deployed, you'll be able to assess threats, leverage the information in the report to update threat models for corporate assets as well as design hardening methodologies to mitigate some of the potential issues discovered.
In environments with important amounts of third party software, the command line version of Microsoft ASA, combined with your favorite software deployment tools, can be combined to provide an easy, mostly automated way for software packaging teams to generate these reports for further analysis.
Grab the installers to the most common software you have in your environment and get started!