Friday, June 26, 2009

Internal AppSec Portals: Introduction

When creating an application security program, it can be difficult to make all the resources, policies, procedures, and expectations available to employees. There should be a centralized location for developers, project managers, and auditors to look up application security best practices, the organization's secure development processes, and time lines for remediating vulnerabilities.

The Software Assurance Maturity Model (SAMM) and Building Security In Maturity Model (BSIMM) recommend addressing these needs using an application security portal (See Software Assurance Maturity Model 1.0, EG3 "Create formal application security support portal" and Building Security In Maturity Model, SR1.2 "Create security portal." This centralized internal website or application should be a one-stop shop for all the organization's secure development needs.

So what kind of characteristics should this portal have? Well, employees should be able to easily create and update information on the website. Access controls need to be applied to specific content to ensure only approved guidance, policies, and procedures are included. The portal should also allow collaboration within development groups as well as between development groups. It would also be nice to be able to version documents to see how and when information changes over time.

After reviewing these characteristics, I realized that a Wiki would provide all these features and could easily be placed within an organization's internal network. Specifically, TikiWiki provides collaboration through user pages, forums, blogs, chat, internal messages, and newsletters. It also allows access controls to be applied to individual categories. For example, a "Guidance" category can be created and pages can be grouped within this category. Read only access can be granted to all users, and write access can be granted to specific individuals responsible for updating the organization's guidance documents. A wiki also automatically versions pages so users can see when information is updated and how it changed. Finally, TikiWiki also provides the concept of structures. Structures group pages in a meaningful way allowing easy navigation and well defined organization of information.

The next several blog entries will cover my current project: providing a template or starting point for organization's internal application security portal. The images below give you a sneak peek at the information that will be discussed in future posts. Click on the images below to see each table of contents.





Monday, June 15, 2009

*Repost* Web Application Security Portfolios

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)

(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)

(Click the image to enlarge)

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

(Click to enlarge the image)

This spreadsheet can be accessed via Google docs here:
http://dl.getdropbox.com/u/1132296/Web%20Application%20Security%20Portfolios/CCANCSA%20-%20Portfolios%20Summary.xls

Sunday, June 7, 2009

SAMM Inteview Template Version 1.0

Several individuals (including me) plan on proposing an effort to evaluate the OWASP organization using the Software Assurance Maturity Model (SAMM). One of the action items I took on was to create an interview template to help determine the organization's current maturity level.

The first release of the SAMM Interview Template is available below.

View the SAMM Interview Template here: http://spreadsheets.google.com/pub?key=rYpVqQR3026Zu4DNg8LBIwg&output=html

Download the SAMM Interview Template XLS here (Some formatting is lost): http://spreadsheets.google.com/pub?key=rYpVqQR3026Zu4DNg8LBIwg&output=xls

If you have questions or comments about this template or you wish to help assess OWASP using SAMM, please send a message out on the OWASP SAMM Mailing List.