Application Registry: Knowing Your Assets

If an auditor asked you what applications exist on your network, how accurate do you think your answer would be? Do you have a repository or registry of the applications your company maintains? A good application security program starts with knowing what you have. Without this knowledge it is very difficult to understand the risk the applications bring to the company.

Depending on the maturity of your application security program, the way that applications are registered can be very different. On the simplest side, this may be a basic spreadsheet. On the advanced side the registry may be a custom built, or commercial application with lots of bells and whistles. In either case, the central repository of applications gives important insight into what exists. The ability to search through all applications for specific data fields will be a really popular feature.

In addition to the application name, creating a profile can be very handy. Here a list of some common items that may be useful in the application registry:

• Application name – The name of the application. If the application has any nicknames or known by anything else it may be useful to capture that as well.
• Application Lead / Contact Information – The name of the contacts responsible for the application. If an audit is occurring, questions arise, or anything else comes up, who should be contacted regarding the application.
• Short description – A short description about what the application does and what it is used for. This may include how roles are used and/or maintained.
• Programming Language / Framework – What language is the application written in. For example, Java, .Net, Python, Ruby, etc. The version is also helpful to understand if the latest version is being used or what language security issues may be present. For the framework, is this MVC, Spring, WebForms, etc.
• Third party components – Applications are commonly made up of many external components which may contain vulnerabilities at some point. Tracking these items can help identify which applications may be effected in the event a vulnerability is found in a component.
• Data elements / classifications – What data is used by the application? Does the application store credit card data, health data, personal information? Record the sensitive information and classify the application based on the most sensitive data. Your company should have a data classification policy to assist with this.
• Regulatory Compliance Requirements – Does the application fall under any regulatory requirements such as PCI or HIPAA?

The above items are not a complete list of fields, but should help get you started if you don’t have anything to this point. Remember that an application security program doesn’t mature overnight. It takes small steps to get where you really want to be. Starting with an application registry is a good first step to provide insight into the environment.

In future posts I will dig deeper into the information that can be tracked with the application registry. If you have other fields you track or know of any good applications to help track your applications please feel free to send them over.