Nick Coblentz: June 2009

In anticipation of my article being published in the May 2009 ISSA Journal, I removed posts for:

Application Security Portfolios: Part 1
Application Security Portfolios: Part 2

Now that the journal article has been out for a while, I wanted to repost those two blog entries. The content in the blog entries is somewhat different than the journal article. The blog entries include a few more images, examples, and additional discussion. Here is that content:

Part 1

Managing an application security program can be a complex responsibility. Applications have a large number of moving parts and potential security risks. Security directors and managers must gather and organize a mountain of information in order to make informed decisions regarding allocating budget money for security and compliance efforts.

This two part blog suggests types of information a security directory might collect about an organization's applications and introduces one of many methods to organize that information. The first article focuses on the collection of detailed information for one single application. The second article attempts to combine relevant information from each application into one single document in order to aide in make decisions.

The goal is for these documents to be useful in at least the following situations:

Maintaining a list of all web applications within the organization.
Prioritizing application security assessment needs based on business and data importance, compliance requirements, and risk.
Identifying key personnel responsible for the security of systems or code associated with a particular application.
Determining network devices, servers, and components to target in an incident response investigation.
Identifying low importance applications that should be assessed due to the shared use of a database or other high importance component.
Understanding the flow of sensitive data between applications and other components.

Part 1: Loan Application Security Portfolio

First, one should gather a list of web applications within the organization. This should be done in a variety of ways including interviewing development managers and web server admins, logging into web servers and inventorying web applications, and by performing network scans over the internal and external network.

Once applications have been identified, basic information should be collected such as the application's name and purpose, who developed the code, where the application is hosted, and business importance. This information can be organized in a variety of ways. A simple excel spreadsheet is shown below for simplicity.

(Click the image to enlarge)

Detailed technical information should also be gathered. This includes items such as the language and framework the application was developed with and the authorization levels that exist. The information shown below is helpful for scoping application assessments with third parties or can be used to estimate time needed for an internal review.

(Click the image to enlarge)

Once the technical information has been documented, security staff can dig into the type of data handled by the application and its data flow. In the example loan application, a table listing the data or event, data type, and relevant compliance requirements was created.

(Click the image to enlarge)

Through interviews with developers and direct observation, a data flow diagram can be created. The method used to collect and present this information was taken directly from Branden R. Williams' article in the ISSA Journal, March 2008 titled "Data Flows Made Easy." In the loans application, individual data flow diagrams were created for key functionality. Once individual diagrams were complete, the diagrams were combined into one compound diagram.

(Click the image to enlarge)

Next, the network devices, servers, and components that the application depends upon should be documented. These assets are also color coded based on how important the application or data is on the asset (this will be more important in part two of the article). Instructions and an example for the loans application is shown below.

(Click the image to enlarge)

Using the dependency table above, pseudo firewall rules can also be defined.

(Click the image to enlarge)

A couple other pieces of information that may be helpful to track are past, present, and future code bases, location of log files, and security related history.

(Click the image to enlarge)

Using the information in the following spreadsheet, one should be able to answer the following questions:

Do we host that application or does a third party host it for us?
Who developed the application?
Does this application need to be assessed?
What additional network devices, systems, or components need to be assessed to assure the security of this application and its data?
Are there compliance requirements associated with this application?
What risk does this application present to the organization?
We've been hacked! Which development manager do I call? Where are the log files? What other systems might also be affected?
Where is the information I can use during scoping and the technical interview process of an assessment from VeriSign Global Security Consulting?

Google Docs Version: http://dl.getdropbox.com/u/1132296/Web%20Application%20Security%20Portfolios/CCANCSA%20-%20Application%20Portfolio.xls

Part 2

Managing an application security program can be a complex responsibility. Applications have a large number of moving parts and potential security risks. Security directors and managers must gather and organize a mountain of information in order to make informed decisions regarding allocating budget money for security and compliance efforts.

This two part blog suggests types of information a security directory might collect about an organization's applications and introduces one of many methods to organize that information. The first article focuses on the collection of detailed information for one single application. The second article attempts to combine relevant information from each application into one single document in order to aide in make decisions.

The goal is for these documents to be useful in at least the following situations:

Maintaining a list of all web applications within the organization.
Prioritizing application security assessment needs based on business and data importance, compliance requirements, and risk.
Identifying key personnel responsible for the security of systems or code associated with a particular application.
Determining network devices, servers, and components to target in an incident response investigation.
Identifying low importance applications that should be assessed due to the shared use of a database or other high importance component.
Understanding the flow of sensitive data between applications and other components.

Part 2: Application Security Portfolios Summary
In part 1 of this series, an application security portfolio was created for an example loan application. Detailed information about the application was gathered including the sensitivity of data within the application, the data flow, and the application's dependencies on other network devices, servers, and components.

In part 2, we will try to organize information about all the organization's applications into one high-level document. The aim is for this document to aid us in answering questions like:

What applications do I have?
What data do I have?
How important is the application or its data to my business?
What risk level is that application or data at?
What Systems and network paths do these applications depend on?
How are these applications and its data interrelated?
Which applications, systems, and networks should I spend security budget money on for assessments?
If an incident occurs or an issue is identified, who is the contact person and what other related systems need to be analyzed?
What compliance regulations apply to my applications?
When was the last time these applications were found to be compliant with relevant regulations and standards?

In order to create this document, the effort described in Part 1 of this series needs to be completed for all the organization's applications. Once that data has been gathered, we can combine the high-level portions into a spreadsheet like the one below.

(Click to enlarge the image)

If we are evaluating this information to determine which applications need assessments, we may make the observations listed below.

Loans Application
The loans application and its data are critical to the business. We completed an application assessment recently on version 1.0, however a whole new version was pushed to production in the last few days (version 2.0). Since this application is so important and we have recently completed an assessment, it may be a good idea to engage the same third party to perform a follow up assessment. We will provide that third part with a list of changes or new features and ensure those items are assessed in depth. In addition, that third party will briefly review the rest of the application to ensure no security issues were introduced in existing functionality by the changes or new features.

If we need a higher level of assurance, need to re-certify our PCI compliance, or drastic changes to the application were made in version 2.0 we may even have a whole new assessment completed.

Company Home Page
An assessment was completed approximate three years ago, and no new changes or features have been introduced since then. While it is important that a public facing website for the company is accessible externally, the data within the application is not terribly valuable.

Depending on the level of assurance needed, we may want to run an automated web application scanner tool just to verify our assumption that the site is relatively secure. If issues are identified, it may be a good idea to perform an assessment internally. Since the company home page does not require users to login and contains only public information, an automated tool is a good choice because the types of vulnerabilities that are challenging to identify using these tools (authentication, authorization, and business logic rules) should not be present.

Online Banking
The online banking application also has not been assessed in a while. This application and its data are critical to the business. The previous assessment occurred on version 3.0. Bug fixes, security updates, and other minor changes were introduced recently in version 3.1. A third party should be engaged to perform follow up testing to verify issues identified in the previous assessment have been addressed. The third party should also assess the minor changes to the application to ensure no additional issues have been introduced.

Internal Wiki
The company's wiki page contains items such as HR policies, processes and procedures for completing day to day tasks, and also contains protected application areas containing private company information or intellectual property. The data associated with this application is critical. This application has never been assessed before. While this application is not a client-facing application, employees, contractors, and other users all access this critical information. This situation may warrant an assessment by a third party.

Employment Application
The employment application is developed and hosted by a third party. Ideally, before this application/service was purchased, a third party assessment should have been performed, and the company should verify that the third party has a secure development process in place. Additionally, the contract between the third party and the company should include details about how assessments are handled, how the third party will respond to the identification of security issues, and other related topics.

As is often the case, a business unit negotiated a contract and purchased service from the third party prior to an assessment being performed. While the employment application does not generate revenue for the company and will not hinder day to day operations if the application goes down, the data within the application includes PII. The compromise of this application and its data will affect the company's reputation and will require the company to spend resources on incident response.

It is a good idea if this application undergoes a third party review.

Compound Dependency Table

In addition to gathering the high-level data above, a dependency table can be created to show how all the applications, data, network devices, servers, and components are interrelated. This table follows the same rules as introduced in Part 1 of this series, and can be used to determine how data flows between systems and networks. Additionally, this information may help to identify key systems that need to be assessed.

For example, if a low importance application accesses data within a database that is also accessed by a high importance application, it may be important to assess the low importance application in terms of introducing or manipulating data to the detriment of the high importance application.