Identifying the scope of Risk for an Application Security Program is not as difficult a task as it seems. Risk Strategies for network, server and desktop environments exist in almost every company and working with the compliance group is a great starting point. If you do not have the assistance of a compliance group then there are some great resources out there, at CA Veracode the Security Program Managers can be one of those. In my discussions with customers on Risk Strategies we have identified some fundamental areas to review when defining a scope of Risk in Application Security.
What is the Applications Location? Depending on the location of an application it can raise the level of risk by being an external facing or limit the amount of risk on an internal network. Not all internal applications are protected by the network layer, instead they may be more susceptible due to their location and access to data and other systems!
Who develops and maintains the application is very important to the Risk Strategies for Applications. Developers who are employees either local or offshore can lower the Risk of an application as compared to an outsourced resource or no one at all. Additionally, if the original developer of an application is not an employee there may not be a way to find source code files or understanding why an applications logic was determined.
All systems are not created equally, the desktop may have access to all systems but a server may contain the system. Additionally, if the system is on a kiosk it may not be as easily compromised as a public facing website.
The number of users who access a website or connect to a networked application increases risk as the hits or connections increases. Conversely a larger number of devices accessing a database or server application can increase risk of an attack as well. Users and devices are additional indicators that can be tracked through logging, increases may adjust the risk profile of an application rapidly!
One of the strongest indicators of risk is Data Type, some examples are PII, PCI, CTI, and Government issued ID or HIPPA information. There are a ton of great recommendations for Data Types on multiple web sites, however the best place to look internally the compliance department or even Human Resources can be helpful.
If an application uses proprietary or even collective algorithms from another source that is tied to a government regulation such as EAR or ITAR the level of risk can increase. The risk to an application can increase nominally to capture the existence of the risk or amplify with the depth of compliance to a regulation.
Depending on the accessibility of the application through the Corporate Intranet, External Network, Over a VPN or on a Mobile network can affect the risk profile of an application.
Access Restrictions or Permissions to system resources or an application that runs with Admin or Root Access can dramatically increase risk. Additionally service account usage with an application should be scrutinized and tracked in the risk profile.
Legacy software or devices should also be reviewed, sure RedHat 8 and Windows XP were awesome however they no longer get updates for security and can introduce risk unlike their up-to-date versions!
There are three additional areas of risk to think about, each can cross a large section of systems and data with varying consequences of a data breach.
Identifying the Scope of Risk for a company can be the most tedious step to developing a Risk Assessment Strategy. Hopefully the areas identified above initiates the conversation and customization per industry segment or company can continue to adapt the strategy.