Monthly Archives: February 2016

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.

Does the End of an Iteration Change Your View of Risk?

You have been working hard for the past few weeks or months on the latest round of features for your flagship product. You are excited. The team is excited. Then a security test identifies a vulnerability. Balloons deflate and everyone starts to scramble.

Take a breath.

Not all vulnerabilities are created equal and the risk that each presents is vastly different. The organization should already have a process for triaging security findings. That process should be assessing the risk of the finding to determine its impact on the application, organization, and your customers. Some of these flaws will need immediate attention. Some may require holding up the release. Some may pose a lower risk and can wait.

Take the time to analyze the situation.

If an item is severe and poses great risk, by all means, stop what you are doing and fix it. But, what happens when the risk is fairly low. When I say risk, I include in that the ability for it to be exploited. The difficulty to exploit can be a critical factor in what decision you make.

When does the risk of remediation override the risk of waiting until the next iteration?

There are some instances where the risk to remediate so late in the iteration may actually be higher than waiting until the next iteration to resolve the actual issue. But all security vulnerabilities need to be fixed, you say? This is not an attempt to get out of doing work or not resolve issues. However, I believe there are situations where the risk of the exploit is less than the risk of trying to fix it in a chaotic, last minute manner.

I can’t count the number of times I have seen issues arise that appeared to be simple fixes. The bug was not very serious and could only be exploited in a very limited way. For example, the bug required the user’s machine to be compromised to enable exploitation. The fix, however, ended up taking more than a week due to some complications. When the bug appeared 2 days before code freeze there were many discussions on performing a fix, and potentially holding up the release, and moving the remediation to the next iteration.

When we take the time to analyze the risk and exposure of the finding, it is possible to make an educated decision as to which risk is better for the organization and the customers. In this situation, the assumption is that the user’s system would need to be compromised for the exploit to happen. If that is true, the application is already vulnerable to password sniffing or other attacks that would make this specific exploit a waste of time.

Forcing a fix at this point in the game increases the chances of introducing another vulnerability, possibly more severe than the one that we are trying to fix. Was that risk worth it?

Timing can have an affect on our judgement when it comes to resolving security issues. It should not be used as an escape goat or reason not to fix things. When analyzing the risk of an item, make sure you are also considering how that may affect the environment as a whole. This risk may not be directly with the flaw, but indirectly due to how it is fixed. There is no hard and fast rule, exactly the reason why we use a risk based approach.

Engage your information security office or enterprise risk teams to help with the analysis. They may be able to provide a different point of view or insight you may have overlooked.