Application Security Governance 1: Understanding your portfolio
“How many applications do you have and what do they do?” It seems simple enough yet this questions seems to perplex many a smart mind. Having posed it to over a hundred and fifty CSO/CIOs over the last year, I have rarely received a clear answer that wasn’t based solely on gut-feel. The information security leader for a large retailer summed up the sentiment in one insightful sentence “We are so project focused that we don’t even know the shape of the larger beast.”
As Microsoft started grappling with the application security problem around 6 years ago, we found that our understanding of our application risk profile was incomplete as we did not know what data was being exposed and through which applications.
When most organizations start the application security program, they have these 4 categories of applications:
- In-production applications
- Soon to be retired/replaced – At this point, evaluate the risk profile of the application and if it is high retire or replace it before schedule. In most cases it is not worth conducting a security assessment on these applications.
- Not slated for retirement/replaced – Conduct a reactive security assessment based upon risk profile. Medium risk applications should get a pen test and high risk applications should code reviews. If newer versions of the applications are to be built then a threat model should be created.
- these form the large class of legacy applications that were produced before your developers had ever heard of Cross Site Scripting and SQL Injection [insert attack name of your choice here], when buffer overflows were just another way of writing self-modifying code. These in-production applications are housed in a known corporate data centers. The risk they represent can be managed based upon a further classification - “Shadow” applications – this is the set of applications that exist but no one knows about them and they are not in your data center. They can be applications like the one running in the legal department for the convenience of the 4 lawyers who are negotiating your next $6 billion acquisition or at your neighborhood retailer doing back-end data mining on credit-card transactions for some merchandising specialist. These applications are the most difficult to discover and pose some of the gravest risk to the enterprise. In my experience, up to 90% of applications at some customers are Shadow applications.
At Microsoft IT, we started a multi-year program to identify and bring Shadow applications into our data-center after conducting security assessments on them. The main tool allowing us to do so was a application portfolio management tool that was developed in-house and called Microsoft Application Portfolio System (MSApps). This allowed MSIT to inventory the existing applications and ensure that no new applications were being built without being recorded by the system. This was enforced by coupling MSApps to some budgetary and resource allocations. For some of our corporate customers who wished to replicate a light-weight version of this functionality, we added it as the Application Portfolio Management (APM) to the Threat Analysis and Modeling Enterprise tool. - Under-production applications – These applications are currently being developed and have not been released to production. They may be in various stages of completeness and most organizations struggle with the level of security assessments that these projects should face. Our recommendation is to treat these engagements the same as “Planned applications” and produce threat models and conduct white-box code reviews for these applications based upon the risk profile. These do differ in one significant way from planned applications because most of the security tasks are conducted by the security team still in a fairly reactive mode.
- Planned applications - These applications have not been implemented yet and represent future Line of Business (LoB) application portfolio for your organization. This is where any proactive approach pays the highest dividend. The security architecture can be assessed at design time and the threat model can act as the guide for architects, developers and testers to ensure a secure application is built from ground up. A properly implemented application security program will allow the application team to feel empowered to conduct a majority of the security tasks while the security team provides guidance and verification. In future posts, I will be expanding in detail about the proactive approach.
From the situation above most organizations should aspire to move to a state where application security program caters to two risk programs 1. In-production applications or 2. Under-production/planned applications.
It took Microsoft IT a couple of years to identify and bring close to a 100% of its Shadow applications into data centers and complete its application inventory process. Application inventory is a critical first-step to a mature application security process and the time for you to do it is now.
