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 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.

  • Confidential Information can be a user name, a sales contacts entire set of information or the formula of an integral product.  Each can have an impact or cost that could be relative or significant.
  • Data Integrity – Losing data in any form can affect the integrity of corporate information, but what if a hacker alters that information?  The impact may be immaterial or it could have adverse effects on how the company does business for years.
  • The risk of Financial Systems being affected may be a company’s first and worst concern, however that risk like the previous two has varying consequences.  Just stealing financial information or records will be difficult to overcome but the risk of actual financial assets being taken can be devastating.

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.

About Mitch Horton

Mitch Horton PMP,CSM is a Principal Security Program Manager at Veracode. He collaborates with Veracode’s largest customers to address Application Security in a full lifecycle approach from initiation of a program to optimization. Prior to joining Veracode Mitch worked for Microsoft managing programs for government and enterprise customers. When he is not working Mitch enjoys training for Ironman triathlons, creating new recipes in the kitchen and is a father of four.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.

 

 

 

contact menu