Application security

Application Security, Deconstructed and Demystified

August 5, 2011 by Mark Wireman

Security professionals have all heard, read, and in some instances, directly felt the impact of insecure or vulnerable applications. Whether they originate from an internal, custom built application or a third party component or application, the vulnerabilities that an organization must deal with are challenging and, more importantly, have found a way to penetrate the traditional Castle Defense strategy by finding the weaknesses in our Castle Wall. As a result of breaches, some mighty and seemingly impenetrable fortresses have fallen victim to exposure of these vulnerabilities in the past 18 months.

What’s interesting is that for many years, the issue of writing more secure code has been discussed, written about, and built into the fabric of audit requirements. But despite this continuous dialogue, we are still struggling with the “how” when addressing security within the development lifecycle.

This series will provide an in-depth look at issues that impact application security, providing an overview of challenges that organizations face when creating and implementing processes to ensure application security. This first installment will address general challenges in the world of application security and move to a discussion of how to implement threat modeling within developmental processes.

Challenges in Application Security and in Creating Secure Code

A significant challenge that the industry faces today is the gap in the educational curriculum – whether at the university or technical school level – for students seeking Computer Science degrees. The programs instruct students on how to write functional applications that meet business needs, leaving out the critical component of building in security to enforce the C.I.A. (Confidentiality, Integrity, and Availability) triad.

The principles are quite simple, yet are neglected in the classroom. This oversight continues to create confusion about who is responsible for securing the applications that developers are building.

Another challenge is the staffing levels within Security departments. The majority of security engineers, operations, and managers migrate from the network or infrastructure side of the business. This shift results in having a wealth of knowledge of components like firewalls, routers, IDS, IPS, anti-virus, and web servers, but little to no knowledge of how an application is developed.

Evaluation and Assessment: Pinpointing and Preparing for Application Security Risks

So how do we deal with the challenges within the realm of Application Security: where do organizations begin? The answers to the questions are straightforward when we use what we know about Risk Management and Risk Mitigation techniques and then apply them directly to Application Security.

The triangle in Figure 1 is the end state: Application Security within the Enterprise. The three corners of the triangle represent the strategy an organization must take in order to achieve an Enterprise Risk Management program that includes application security.

Here’s an understanding of the three primary components of an Application Security Program from a Security Perspective:


  • Risk Assessment – the process to identify applications that must undergo continuous review
  • Risk Mitigation – the process to rate vulnerabilities, timelines to remediate, and workflows for reporting vulnerabilities identified
  • Evaluation and Assessment – the process commonly referred to as the Secure Coding program which integrates with the SDLC, performance of the static and dynamic analysis, policy and procedure enforcement, coding standards, training, and reporting

Risk Assessment Methodology

A Risk Assessment methodology is used to identify applications that must undergo consistent and regular vulnerability assessments. This process involves the use of a data classification policy in conjunction with a business impact analysis in accordance with the business model. The business model includes factors such as financial importance, number of users, operational necessity, compliance and legal requirements – all important aspects of the Business Continuity and Disaster Recovery Plan and Policy. Figure 2 shows a process used to identify applications using a funnel approach.

Risk Mitigation Strategy

This process defines the “whats” of Application Security:

  • What vulnerabilities must be remediated
  • What rating factors are applied to the vulnerabilities that must be remediated
  • What timeframe the vulnerabilities must be remediated in based on the rating of the vulnerability
  • What the exception process for vulnerabilities that go beyond the timeframe should look like
  • What enforcement mechanisms are used to ensure compliance with remediation of vulnerabilities within the required timeframe based on the rating assigned
  • What vulnerabilities to remediate and the rating factors to be applied can be determined through the use of industry standards to rate security issues

The OWASP Top Ten, SANS Top 25, CWE and CAPEC are commonly used and accepted standards that are utilized to help identify and rate known vulnerabilities and vulnerability types.

Remediation timelines provide a risk perspective to detect known vulnerabilities and give the organization a tangible metric to estimate the amount of time that it will take to correct these weaknesses. It is important to align remediation timelines with the accepted risk that the organization is willing to take in combination with the application release cycles. A suggested timeline is 90 days for high vulnerabilities; 180 days for medium; and 365 days for low.

Regardless of the tool or method used to identify the vulnerabilities, a standard vulnerability assessment report is critical to consistent communication and tracking. The report, at a minimum, should include an executive summary, evaluation criteria used, prioritization of vulnerabilities identified, summary, and a list of false positives (if any). The reports should be provided to all parties, including Business, Development, and IT Security, for review and comment.

In addition to the reporting process, it is important to have an exception and governance process in place so that application teams can ask for an extension on remediation timelines. The exception will then be used as a formal sign-off from the entire organization, by way of the Governance Board, in accepting the extended risk based on the stated reasons. The Governance Board can also keep metrics on the progress of remediation efforts and suggest improvements if a significant number of exceptions are being submitted and granted.


Implementing an Application Security Program

This is the real “meat and potatoes” of an Application Security program and warrants a detailed explanation of implementation. If your organization has an active IT security department or program, many of the policies and procedures around Risk Assessment and Risk Mitigation are already in place. At this point, they should have been reviewed and modified as needed to include Application Security as part of the process. However, it is also important that at this point the communication and collaboration has already been formed between Business, IT Security, and the Development Organization about the importance of and ROI in bringing Application Development into the realm of Risk Management.

To help organizations understand what is required to apply an evaluation and assessment program within the Development area, a six step approach is used to bring an understanding of the controls required to seamlessly integrate security into the Software Development Lifecycle (SDLC).

SixFold Path to Secure Coding in SDLC

  • Right Leaders
    • Security
    • Business
    • Development
  • Right Plan
    • Phased approach
    • Education
    • Developers
    • Business / Management
  • Right Process
    • SDLC Integration
    • Tools
  • Right Skill sets
    • Language SME’s
    • Vulnerability Assessment / Identification
    • Understanding of SDLC, Project Mgmt, and Risk Mgmt
  • Right Policies
  • Right Traceability
    • Centralized and standardized code framework
    • Defect tracking of vulnerabilities
    • Standard reporting regardless of tool/approach
    • Metrics
    • Governance


Figure 3 is a high-level view of an example of the controls to integrate within the key areas of the SDLC. Figure 4 is a detailed view of the application of the Six Fold Path process.


Six-Fold Path Example:


Don’t Get Caught in Methodology Chasing

While many security professionals have different ideas about application security best practices, when the layers of the onion are peeled back, a methodology already exists – it’s the strategy we use today for Risk Management and Mitigation. It’s also the strategy we use for Application Development by way of a Software Development Lifecycle. Creating a set of best practices for application security simply boils down to placing the necessary controls within the SDLC that allow for detection of vulnerabilities as early as possible before releasing the application to production.

Ensuring application security is that straightforward – the real challenge, however, is bridging the gap between IT Security, Business, and the Development organizations. But this bridge can easily be crossed by showing the enterprise the ROI of placing the controls in the SDLC, helping Developers work with and understand the controls by avoiding the “dump and run” approach, and ensuring that IT Security enhances the existing Risk Management and Risk Mitigation policies to include application security. This essential collaboration will produce more secure applications and, ultimately, protect customers from compromised information and organizations from damage to their reputations and brands.


Challenges in Threat Modeling

In the previous section an overview of application security was discussed, focusing on two of the three important aspects of the security C.I.A. triad – People and Process. In the upcoming installment of this series, you’ll see a deeper dive into the third influencer, Technology: we’ll discuss the common vulnerabilities that occur, along with an explanation of the technologies that can be used to detect and assist with mitigation of these weaknesses. However, before we talk Technology, it’s important to continue to our discussion on Process and specific but key part of the Process: Threat Modeling.

The implementation and adoption of Threat Modeling as a normal activity within development processes can be difficult for development and architectural staff. This challenge is due to a large number of issues, ranging from incomplete requirements; incomplete or missing software design documentation; rush to market; and lacking a security focus or awareness as part of the development process. The incomplete or missing documentation is a sign that the software development lifecycle processes are either not enforced or not understood, which is a far less common issue than not integrating security awareness as part of the development process. In either situation, one of the common misconceptions is that either the documentation is missing or that not having a security focus results in the inability to produce a Threat Model. The remainder of this discussion will refute these myths and will show why a Threat Model can be created at anytime, anywhere, and by anyone within the IT Organization.


The Cycle of Threat Model Activities

A general understanding of the threat model process is crucial to taking the next step to plan and create a comprehensive plan for Threat Modeling. Figure 5 provides a visual representation of the Threat Model Activities.

Figure 5: Threat Model Activities


The Activities are described in detail below:

  1. Identify and Understand Security Objectives. When producing the threat model, it is important to have an understanding of what security objectives, functions, and activities are being addressed to help define the parameters to focus on. The primary security objective is always focused around the C.I.A. triad, which is then used to determine specific objectives related to the application in scope. Example questions are: a) What type of data requires protection?; b) What are the compliance requirements that must be followed?; c) What, if any, intangible assets require protection?; d) What Service Level Agreement or availability requirements exist.
  2. Application High-level Overview – While having the Requirements Document along with the Functional Specifications document will be extremely beneficial, it is not necessary to gain an understanding of the application from a high-level perspective. This activity will provide an understanding of the application and the dependent components, servers, and deployment activities; user roles; technologies used; application security mechanisms utilized; and key usage scenarios. A useful diagram in this activity that can be quickly created is an end-to-end deployment diagram that highlights servers, databases, and application boundaries, i.e. Presentation, Business, and Database.
  3. Break-down Application – This is a deeper dive into the application from the high-level overview. Trust boundaries, data flows, and exit/entry points are identified within this activity. Trust boundaries are determined by walking the flow from the outer perimeter and working inside. Typically this starts from the DMZ through the data access layer, identifying key devices that are used to protect the separation of layers. Then, a look at the flow of data from outer perimeter through the egress and ingress points of the application can be established, focusing in the key usage scenarios identified in the overview. The depth and breadth of the application is not important – it is ensuring coverage of the key scenarios and the alignment to the objectives that will provide for the most efficient coverage and identification of potential security issues.
  4. Identify Attack Surfaces and Threats – With an understanding of the roles, boundaries, dependent components, and technologies involved in our application, attack surfaces and threats to those surfaces can be identified. Common threats related to authentication, authorization, input validation, data validation, session management, and cryptography are explored. In addition exception management, logging, and auditing can also be identified to ensure that any attacks that do occur can be captured, monitored, and used as evidence. It is important in this step to not only look at attack surfaces and threats from a boundary perspective, but also to look at threats throughout the data flow for the key functional aspects of the application.
  5. 5. Identify Vulnerabilities – The categories used to identified potential attack surfaces and threats in Step 4 are used to map the threats to the specific vulnerabilities which can be used to compromise the application and system. Cross-site scripting and SQL Injection are vulnerabilities associated with Improper Input Validation; Escalation or Elevation of Privileges is a vulnerability associated with improper Authentication and Authorization; Session Manipulation and Cookie Tampering are vulnerabilities associated with improper Session Management; Server Timeout to the Database is a vulnerability associated with Denial of Service; etc. It is important in this step to think like an attacker by asking how to compromise the application based on known threats.
  6. Remediation and Test Plans – The final activity is taking all of the information within the Threat Model and providing a report to the Application Team with a rating of the vulnerabilities, remediation recommendations, and test scripts that can be used to ensure the threats have been mitigated. The tests are specialty tests that attempt to exploit the identified vulnerabilities and associated threats with the goal of compromising the application. While it is tempting to try and test all identified vulnerabilities, it is important to prioritize the effort focusing on the more critical vulnerabilities within the scope of the key functional aspects of the application.To understand how all of the activities above tie into the Threat Model, Figure 6 provides a view of the inputs, outputs, and development processes that can benefit from the information learned from a Threat Model. The dotted lines passed in the Requirements process and the subsequent documents are beneficial but not necessary to construct a Threat Model. As part of the Threat Modeling activities, an Access Control Matrix will be created, as well as a Threat Model Report that highlights the information learned from the activities above. The significance of this diagram, however, stresses the importance that for the effort put in to creating a Threat Model, the benefit is realized threefold by impacting Development, Testing, and Post-Deployment activities, with the key end result of producing a quality and secure application.

Figure 6: Threat Model Process – Inputs, Outputs, and Influence Paths


The Acme Company: A Threat Model Example

To show how straightforward it is to create an informative and useful Threat Model, the Acme Store is going to develop a website that will be used for customers to place orders and for vendors to manage the products that they sell. To follow the steps outlined in the activity cycle and using the Microsoft SDL Tool, the following information is used to generate the Threat Model:

1. Security Objective – Protect the Customer’s information; meet Service Level Agreements with the Vendors; protect Acme’s online credibility as a safe and secure Internet retailer.

2. High-Level Overview – See Figure 7.

Figure 7: High-level Overview

Key Usage Scenarios:

a) Customer places and reviews orders; submits payment information to process order; provides shipping and billing information.

b) Vendor adds, updates, deletes product information.

Both Customer and Vendor communicate to the Web Server via HTTPS.

3 – 6. The remaining activities – Break-down Application, Identify Attack Surfaces and Threats, Identify Vulnerabilities, and Remediation and Test Plans – can all be completed using the Microsoft SDL tool. Figure 8 is a Data Flow Diagram of our Acme Store application that will also be the basis for our Threat Model. The inbound, outbound, data flows, boundaries, and dependent components are labeled.

Figure 8: Data Flow Diagram as the Threat Model for the Acme Store application.

Table 1 is a subset of the list of the Surfaces and Threats. Figure 9 is an example of the Vulnerabilities of the Repudiation threat: using the Microsoft SDL tool, the list of known Threats on the Attack surfaces will automatically be generated from the diagram. Additionally, as noted in Figure 9, a list of remediation and testing criteria can be easily formed based on the questions presented to ask about the threat. This is an important time-saver and allows for more time to focus on remediation recommendations and establishing test scripts to ensure the surfaces are protected.

Threats against Customers
Spoofing (Threat #1)
Threat: Credential Storage
Credentail Protection
Mitigation: Credentials are stored on the Server
HTTPS is used in communication between User and Web
Repudiation (Threat #2)
Threat: Repudiation of Orders
Mitigation: All Orders placed are logged to include Customers acknowledgement
Threats against Vendors
Spoofing (Threat #59)
Threat: Credential Storage
Credentail Protection
Mitigation: Credentials are stored on the Server
HTTPS is used in communication between User and Web
Repudiation (Threat #60)
Threat: Repudiation of Vendor modifications
Mitigation: All Product updates, deletions, and additions are recorded
Threats against Store Website
Spoofing (Threat #25)
Tampering (Threat #26)

Table 1: Sample list of Threats against the Surfaces in the Threat Model

Figure 9: Threat with list of Vulnerabilities

Final Thoughts on Threat Modeling

Creating a Threat Model is a clear-cut task that provides a wealth of information about the security posture of the application, types of threats that the application can encounter, and a list of items to test against to ensure the application is as safe and secure as possible before release. Additionally, all of this framework can be created without any prior knowledge of the application, and only requires a moderate level of detail about the application.


Abrams, M.D., Jajodia S., Podell, H.J. (September 1994). Information Security: An Integrated Collection of Essays.

Eckert, C. and Marek, D. (November 1998). Developing Secure Applications: A Systematic Approach.

McGraw, G. (April 1998). Testing for security during development: Why we should scrap penetrate-and-patch.

Security Innovation. (n.d.). Aligning Application Security and Compliance.


Additional charts/resources

Posted: August 5, 2011
Mark Wireman
View Profile

Mark A. Wireman is the Application Security National Practice Lead at OpenSky, working in the IT Risk Management & Security practice. For the last 12 years, Mark has worked in the Application Development space, primarily focusing on application security from a process and practice perspective within the DoD, Financial, and Health Care sectors. Mark has presented at the CSO Breakfast Philadelphia Chapter and the Joint ISACA/OWASP conference, as well as published articles on application security best practices and participated on blogs and forums about application security. Prior to OpenSky, Mr. Wireman worked in Iraq with the DoD as a Technical Advisor to the Multi-National Corp on matters relating to secure coding in secure and non-secure systems, SharePoint, Business Intelligence, and other systems. Mark is also an Associate Professor and teaches computer science and cyber security courses at University of Maryland University College and is currently working with the university to develop a first-of-its kind Application Security course. Mark holds a B.S. in Computer Science and a MS in Information Technology with a concentration in Information Assurance.