I’ve had a chance to spend some quality time with Microsoft’s Attack Surface Analyzer over the past week, which I’m going to refer to as “MS-ASA” to keep my word count down. The tool itself is pretty nifty, it gathers security and other system information from Windows, compiles it into a .CAB file (a ‘baseline’), and stores it for future analysis. The two most powerful features are the capability to pull this information from almost anywhere on the system, and to compare that information between baselines.
There are a three main conditions to using MS-ASA with control systems. First, MS-ASA doesn’t support Windows XP. This is a huge issue for control system owners and vendors, who are still working with a large XP install base.
Second, full installation of the tool requires the “.NET Framework 4 Extended”, which is not normally resident on control systems. Without .NET 4, MS-ASA can still be used in command-line form,but is limited to data collection only. Using just asa.exe, a user needs to transfer the resulting baseline .CAB to a system with the full version of MS-ASA for comparison and reporting. While this may seem like a complete detriment, use of asa.exe opens the door to automation of the scans, something I’m investigating for a much larger training program around MS-ASA.
Third, much of the important information pulled from the system depends heavily on pieces that are run-time related. So, it’s not enough to make a baseline, and then install an application, and check for differences from the baseline. The actual programs must be running, any normal network connections (such as those to controllers) should be up and running as well. Otherwise, the baseline will miss information, such as listening ports.
So where is MS-ASA useful in a control system context? I see it used to test that patches and updates don’t adversely affect existing cyber security controls. Those of you in the NERC CIP world should really like the wording there, and it’s completely accurate. When used correctly, the tool can be used to detect changes in ports, services, user accounts, key registry settings, COM/DCOM settings, and several other settings. Additionally, it pulls together any security vulnerabilities in the configuration that the tool knows about under a separate heading for analysis. An owner can use this to review their posture, and if they see pieces that don’t fit, either send the whole report the the vendor for analysis or make appropriate fixes themselves.
While individual owners can do this, the best party to use this tool are vendors. Vendors should be using this tool, and others like it, in Software Development Lifecycle processes to catch security issues. This in turn would roll back on developers to explain and/or fix the issue BEFORE the update goes to users. Since vendors rarely listen the first time around, I’m hoping a deluge of MS-ASA reports from their users over the next few months will help them add MS-ASA to their development process.
As an example of the power of this tool, I’ve attached a report (After Matrikon-AB Install) I generated after installing an automation product (specifically the Matrikon Allen-Bradley OPC Server). As you go through the report, you’ll see that things are nicely enumerated, as well as some potential security issues called out. The report has some basic hotlinks with explanations of each sub heading, and generally breaks down the differences quite nicely. This comparison was generated against a clean, fully patched install of Windows 7 on VMWare, and then the application was installed. You’ll notice that without OPC clients accessing the server and AB PLCs connected, there are only a few ports in use (while many ports would be present in both a production or test environment).
While I’ve been very fanboy on this tool, there are a few issues and suggestions for improvement I’d like to make. First, can I get some Windows XP support?XP support would be very helpful for control system users, the ones who will make a decision on whether or not to continue with Microsoft based OSes. Second, the “Network Information – Ports” need further subdivision based on TCP vs. UDP and the state. As a security engineer, I’m most interested in Listening ports, slightly interested in Established ports, and don’t really care too much about things like Time_Wait. These should be split out in the report in separate subsections. Third, it would be nice to have a “Signed Software” column for the modules (mainly DLLs and EXEs). As we push for more control system vendors to sign their code, a tool that reports new modules should let us know if the code has been appropriately signed and who it was signed by.
As always, comments are very welcome. If you’d like a breakdown of the Matrikon OPC Server report, make it known via Twitter (I’m @mtoecker), email (toecker [a-t] digitalbond.com), or in the comments.
image by mtoecker
[Edit: ABB != Allen-Bradley]