Organizations that want to manage their security risk need to understand how they are exposed. The applications an organization runs make up a tremendous amount of this exposure due to the fact that vulnerabilities in the applications, as well as misconfigurations, are likely targets for attackers. Being able to properly defend these applications requires the organization to first identify their attack surfaces before meaningful risk management can take place.
When identifying an application’s attack surface, you must first determine what will be in and out of scope. Organizations deploy many different types of applications, and each may be treated differently from a risk management standpoint. Common types of applications can include web applications, web – and micro – services, mobile applications, as well as other types of deployed software. Applications may be treated differently based on where the software came from. Some applications may be custom software developed in-house while others may have been developed by 3rd parties –on or offshore, or out-of-the-box from external vendors both large and small. It is important to count any cloud services among an organization’s application attack surface because they are often used to store and manage sensitive information.
The goal in developing a scope of applications is to determine the most comprehensive list possible. Formulating this list is an iterative process and is unfortunately rarely done. Why is the attack surface enumeration process so difficult? In most organizations, an existing set of “legacy” applications were built before the census process started, leaving analysts to work through a backlog of existing applications. Additionally, new applications are being developed by lines of business all the time or are brought on as a result of a merger or acquisition. Cloud vendors and services also make it far easier for various groups and lines of business to procure additional attack surface in a decentralized manner. Finally, in many organizations, DevOps and other strategic initiatives can cause a proliferation of microservices and other software attack surface as existing applications are rearchitected and expanded.
So how can an analyst find applications deployed across their organization? This varies based on the organization but the size of an organization will likely impact attack surface and how it is discovered.
Bigger organizations often have more lines of business, more services and products, and these are often tied to application exposure. In smaller organizations it may be more feasible to work with other departments, like accounting, to use non-technical means to identify applications. The industry of an organization will also likely impact the attack surface. A large bank or financial services organization will typically have more custom software development than a large mining company which would typically rely on packaged software and a handful of industry-specific applications. IT maturity and centralization will influence the process used to identify applications, as organizations with a high level of maturity tend to have better starting points for application inventories due to better asset management practices.
Cloud adoption also has an impact on the process. Organizations that have prohibitions against using cloud services and who instead rely on their own data centers for hosting can make it easier to find out what is being hosted. However, it is important to note that the trend is moving in the opposite direction – organizations are increasingly pushing a large amount of their services to cloud providers in order to support DevOps and other agility strategies.
Applications can be identified by both technical and non-technical means. Technical approaches to identifying applications can include scanning IP ranges in data centers to identify what is hosted on the network. A combination of targeted nmap scanning with some scripting can help provide a starting point for additional manual analysis. Banner-grabbing and review of web application home pages can provide insight into what applications are being hosted on different parts of the infrastructure. Also, reviewing DNS records for domains an organization owns can provide a view into where various applications and services may have been provisioned. Searching the Apple App Store and Google Play can enumerate mobile applications that an organization has released.
Non-technical means for identifying applications can include working with accounting departments to identify external applications hosted by prominent cloud providers. There are vendors that can help organizations analyze and optimize their cloud spend. A side effect of working with these vendors is that they can also often help identify cloud spend associated with unknown application attack surface. In addition, analysts can work with IT departments to review disaster recovery plans. If something is important enough that a group wants to make sure that it keeps running, it’s likely important enough to be monitoring its security. Discussions with people from different lines of business can also freqently identify surprising information about application attack surface. These conversations can be frustrating because they do not scale, but often the best way to discover applications contributing to attack surface is to network internally with representatives from different lines of business. Doing so will allow you to find out what applications they know about, as well as initiatives that may be underway to transition away from end-of-life legacy applications or provision and deploy new ones. For organizations with less mature and decentralized IT operations, this is often one of the only ways to learn about an evolving application portfolio.
Now that you have your list, what do you do with it? The technical discovery provides analysts with the raw materials needed to start filling out the attack surface. The non-technical discovery provides analysts with valuable meta-information about applications and services. The analyst then needs to work to meet in the middle, with the goal of developing a list that ranks application risk based on factors such as the data being managed, business-criticality, and associated regulatory requirements. This additional meta-data will feed into risk management decisions about testing and mitigations that will be made later on.
The application asset management process is an iterative one – both to discover legacy information that may have been missed on earlier passes and to deal with the evolution of the organization’s attack surface over time. Even an incomplete list is far superior to not having any specific understanding of your organization’s attack surface, because unknown attack surface cannot be defended.
Next, we will look at using the application attack surface inventory as the starting point for creating a comprehensive application testing and risk management plan.
