To get a handle on your security posture, you must understand the areas in which you are most at risk and design strategies to protect those areas. Your areas of risk are known as your attack surface. The Open Web Application Security Project (OWASP) defines the attack surface of an application as the sum of all paths for data and commands into and out of the application, combined with the code that protects them and the data behind them.

Mapping Your Attack Surface to Identify High-Risk Code

Mapping your attack surface allows you to summarize all aspects of your application’s security position into a single matrix. Compiling these details is made easier using the Attack Surface Analysis Cheat Sheet provided by OWASP, which suggests you give primary focus to such activities as

  • Entry Points
  • Login and Authentication Forms
  • Admin Interfaces
  • Search Functionality and Other User Inquiries
  • Data-Gathering Forms
  • Database Users and Permissions
  • File Storage Locations
  • APIs
  • Network Interfaces
  • E-Mail and Text Messaging Services

Researchers at Microsoft have created a methodology for measuring the Attack Surface of an application, then tracking changes to the surface as the code changes over time. They refer to a single Relative Attack Surface Quotient to reflect the vulnerability of the system.

Researchers at Carnegie-Mellon have also built a way of calculating an Attack Surface Metric for very large database systems. First they identify all the system entry points, then they apply a ratio of potential damage from a breach compared with the difficulty of patching the code. The result is a way of prioritizing security improvements.

Prioritizing Software Insecurities

The attack surface map quickly gets complex. In addition to identifying user entry points to the system, these access points have to be weighted by the potential damage caused from a breach. Access to authorization, authentication, and password management controls brings with it the ability to shut down the entire system. The ability to change a user’s role, permissions, or functions also needs extra care. Any code involved in encryption deserves extra scrutiny.

The attack surface for a piece of software includes not only the paths that users with various levels of permission can take through the software, but also the protective coatings around those path: encoding, validation, logging, encryption, and auditing, to name a few. With each parameter tracked, the Attack Surface Map becomes more complex.

We developed the Code Pulse application, freely available as an OWASP project, to identify how much of the attack surface is tested during penetration testing activities and what part of the code is exposed by the attack surface. You can get this open-source tool at  http://code-pulse.com/.

If you understand the attack surface, you will be able to more effectively analyze and prioritize the results of your static application security testing (SAST) tools, and focus your attention on those software weaknesses that are exposed on the attack surface. Code Dx’s filter-driven analysis helps you focus on the important issues based on the criteria you established from your attack surface analysis.

And stay tuned because we’re looking at some really interesting ways to help with the attack surface analysis from within Code Dx. We’re in the process of incorporating into Code Dx the results of dynamic application testing tools (DAST) that expose the Attack Surface. We’re initially focusing on Burp Suite, Arachni, OWASP ZAP, Netsparker, Acunetix, HP WebInspect, and IBM AppScan.

Reducing Your Attack Surface: Strategies to Improve Software Security

The attack profile for your application is a living thing that grows and changes with time; you can never let your guard down. It all comes down to instinct and preparation. Look for problems, worry over inconsistencies, and always employ the lowest common denominator rules.

Here are a few key strategies to consider that will reduce your attack surface and make your application less vulnerable:

  • Don’t give more access to users that you absolutely have to. Limit users to the least possible level of access required to accomplish their tasks.
  • Store as little confidential data as possible. Quickly isolate or destroy sensitive data when it is no longer needed. Do not continue to collect sensitive data unless you have a use for it.
  • Turn off functionality that is not required or being used. Get rid of features that are not being used. Remove previous versions of software and unused code — a major source of software insecurity.
  • Reduce entry points into your application: eliminate unnecessary service requests. This may include email services, database access, DLLs, web pages, mobile applications, and other API calls.
  • Reduce reliance on third-party APIs and interfaces: give careful consideration to any add-ons that originate outside your organization.
  • Before upgrading or de-bugging your application, identify risks to your existing system: What is changing? What will be done differently after the changes? What new vulnerabilities could be exposed?
  • Zero Access by Default. Scale user security upward instead of downward: start at ‘zero’ and permit access to functions and data as required, rather than starting with an ‘all-access pass’ and turning off bits and pieces to reduce privilege levels.

Tracking Changes to Your Software’s Attack Surface

Attack Surface mapping provides the data necessary to observe best practices in application security. Once the matrix of access points is mapped to the levels of access and/or authority, it would be foolish not to maintain the matrix as the software develops.

In particular, changes to high-impact settings such as password routines, user authentication systems or encryption systems should be examined against the attack surface map to identify access points needing reinforcement or elimination. If you are adding something to the software that requires a whole new level of access, you are going to have to go through a lot more security testing than just updating an existing level’s capabilities.

If you would like assistance implementing Attack Surface Mapping or maintaining an application security testing program, Code Dx is here to help.

%d bloggers like this: