+ All Categories
Home > Documents > Mapping Application Security to Business Value - Redspin Information Security

Mapping Application Security to Business Value - Redspin Information Security

Date post: 21-Nov-2014
Category:
Upload: redspin-inc
View: 58 times
Download: 2 times
Share this document with a friend
Description:
This white paper outlines considerations and recommendations for reducing business risk by ensuring that your web applications are secure.
11

Click here to load reader

Transcript
Page 1: Mapping Application Security to Business Value - Redspin Information Security

Because applications

are a reflection of the

business, we believe

application security plays

a major role in creating

and retaining business

value system.

6450 Via Real, Suite3

Carpinteria, CA 93013

800-721-9177

805-684-6858 WHITE PAPER

Mapping Application Security To Business Value: Considerations And Recommendations For IT And Business Decision Makers

Page 2: Mapping Application Security to Business Value - Redspin Information Security

TABLE OF CONTENTSSummary1

The Role of Applications within the Information 2 Security System

Secure Software Development3

Integrating the Application within the Information 4 Security System

Creating Business Value5

Business Impact6

Page 1 | www.redspin.com 2009 | White Paper

Page 3: Mapping Application Security to Business Value - Redspin Information Security

We consider

application security

from the standpoint

of supporting an

effective compute

and communications

infrastructure...

This white paper outlines considerations and recommendations for reducing business risk by ensuring that your web applications are secure.

Our goal is to present information

that will be helpful not only to IT and

information security professionals

but business unit general managers

as well. We will examine the

process of managing applications

throughout their lifecycle.

In an earlier white paper we introduced a simple top-down system for making the association between security initiatives and business metrics for the purpose of better managing the information security system. In this white paper we will examine the relationship between investments in application security and the metrics that drive business growth. We will also explore the various alternatives to approaching application security as well as the pros and cons associated with each.

In a recent Harvard Business Review article titled “The Big Shift” (HBR; July-August 2009; John Seely-Brown, Lang Davidson) the authors presented the idea that in times of economic crisis such as those we face now, traditional metrics for managing business may be insufficient to point the way forward. The HBR article presents a framework for understanding business transformation in terms of three factors: foundations for major change (such as compute power and Internet usage), flows of resources (such as information and knowledge)

Summaryand the impact of the combination of the previous two factors on companies and the economy. As is often the case in business, this framework is measured as an index (the shift index) comprised of three components: foundation, flow and impact. The foundation index is strongly influenced by computing and communications (Internet) infrastructure. The flow index is influenced by information sharing and Internet activity. The impact index is influenced by brand loyalty and competitive intensity. The article concludes by challenging executives on how can they best create and capture value by managing these factors.

Throughout this paper we will examine what can be done with respect to application security in terms of enabling business by actively managing these factors. Because applications are a reflection of the business, we believe application security plays a major role in creating and retaining business value. We frame the discussion of this role as part of the overall security system whose efficacy can be evaluated in terms suggested by Seely-Brown and Davidson. We consider application security from the standpoint of supporting an effective compute and communications infrastructure (positively impacting the foundation index). We examine the role of applications in supporting the flow of information and knowledge resources in a secure fashion (positively impacting the flow index). Lastly, we explore methods to securely deploy applications and business process to protect corporate brands and promote competitive advantage (positively affecting the impact index).

Page 2 | www.redspin.com 2009 | White Paper

Page 4: Mapping Application Security to Business Value - Redspin Information Security

Note that aspects of application security make contributions in all three categories. Next, we must think about the elements that connect the application security system with the business. As with any other major subsystem of the overall information security system, application security is a factor to consider in each major area of the systems. An application security system must be driven by policy, integrated with the overall strategy and tightly coupled with the controls that carry out holistic protection objectives. An ideal description of the customer security system is shown in the following diagram:

Figure 1. The Information Security System

The Role Of Applications Within The Information Security SystemFor an application security system to support the business we must treat it like a system. It must have structure and be measurable. We suggest a different approach that starts with a top down perspective. We also believe that a system must be rich with the necessary information but simple enough to support business decision making.

Our application security system uses the terms presented in the HBR article. Ultimately we have three elements to manage with three associated indices to track. The system is illustrated in table 1.

The Role Of

Applications Within

The Information

Security System

Foundation Flow Impact

Key Elements

Key Metric

Storage, Compute,Applications,

CommunicationsInfrastructure

Data, Information,Knowledge, People

Availability Confidentiality Integrity

BusinessProcesses,

Business Value

Table 1. High level elements and metrics associated with the Information Security System

Page 3 | www.redspin.com 2009 | White Paper

Page 5: Mapping Application Security to Business Value - Redspin Information Security

Foundation Flow Impact

Key Elements

Key Metric

Storage, Compute,Applications,

CommunicationsInfrastructure

Data, Information,Knowledge, People

Availability Confidentiality Integrity

Developer Training Data Classification System Integration

BusinessProcesses,

Business value

ApplicationAreas

Architecture Information Privilege Change Management

Threat Modeling Identity and AccessManagement

RegulatoryCompliance

Risk AssessmentPrivacy Audit Process

Code Review Security EnforcementMechanisms

Incident Response

Security Checklists Encryption and KeyManagement

Production Testing

Source CodeAnalysis

Pre-ProductionTesting

Risk Management

Now, let’s examine where various aspects of the application security program fit in. Table 2 illustrates some key application security areas and their relation to our foundation, flow, impact model of the information security system.

For an information security system to be running optimally managers must make decisions about each of these application security areas and put in place processes to carry out their decisions. If managers ignore their responsibility or take shortcuts on process, ad-hoc decisions will fill the void. These decisions often have disastrous results.

Let’s discuss a few of the application security areas in each category to explore the relationship to the overall information security system and business value contribution through the foundation, flow and impact framework.

Page 4 | www.redspin.com 2009 | White Paper

Page 6: Mapping Application Security to Business Value - Redspin Information Security

Often the team can

draw upon general

application security

policies and specify

how these general

policies manifest

themselves in the

specific application

environment.

Foundation – Secure Software DevelopmentDeveloper Training

As web applications have become more fundamental to the business, security training which may often have started through ad-hoc processes must become formalized and widespread. Developers cannot be held accountable for security issues if they have not been adequately trained. We recommend general purpose security training for all team members including QA staff. We would also recommend specific training targeted by development role.

ArchitectureJust as the functional architecture specifies the relationship between the major subsystems that make up the application, the same must be true of the core security services that govern security of the application. Often the team can draw upon general application security policies and specify how these general policies manifest themselves in the specific application environment. For example, the general policy may make statements regarding input validation, but the architecture must refine these specific to the business requirements and security context associated with the application.

Threat ModelingIn order to have an understanding of the risks associated with an application; developers must understand the threats that are present. A common practice is to develop a threat model that characterizes the threats and risks to the application. Microsoft has invested significant resources in formalizing this process. They recommend a step by step process of identifying security objectives; reviewing the application in terms of components, data flows and trust boundaries; decomposing the application in terms of components to identify areas where security needs to be evaluated; creating a structured list of threats; and enumerating likely vulnerabilities associated with the class of application in development. To assist in this effort of threat and risk modeling Microsoft advocates a threat classification scheme known as STRIDE.

This scheme aims to characterize the threats with respect to the exploit that may be employed. This clever acronym stands for:

These areas provide a helpful mechanism for enumerating threats to the application.

Risk AssessmentAs with any endeavor related to security, we recommend a risk based approach where development effort to secure the application is guided by the risks to business. Closely associated with this process is a scoring scheme to help evaluate risk to the application. Another acronym applies to this problem as well: DREAD.

DREAD attempts to quantify, compare and prioritize the amount of risk presented by a given threat. It stands for

Typically each of these areas is assessed on a scale of 1 to 10 with 10 referring to the most severe risk. As always risk needs to be evaluated in terms of both probability and impact.

Spoofing Identity

Tampering With Data

Repudiation

Information Disclosure

Denial Of Service

Elevation Of Privilege

Damage PotentialReproducibilityExploitabilityAffected UsersDiscoverability

Spoofing IdentityTampering With DataRepudiationInformation DisclosureDenial Of ServiceElevation Of Privilege

Damage PotentialReproducibilityExploitabilityAffected UsersDiscoverability

Page 5 | www.redspin.com 2009 | White Paper

Page 7: Mapping Application Security to Business Value - Redspin Information Security

Code ReviewWe recommend that an application in development pass a thorough code review. By no means, do we expect each developer to walk through their sections line by line. In contrast, this is an exercise that ensures that common assumptions are agreed upon, and no major misunderstandings are present. A reasonable sample outline is suggested as follows:

Monitoring of security metrics is supported.•

Secure operational environment is specified.•

Attack surface and threat environment is understood.•

Misuse cases have been identified.•

Global security policy (for the project scope) is in place.•

Resource and trust boundaries have been identified.•

User roles and resource capabilities are understood. •

Security relevant requirements have been documented.•

In practice the agenda and topics covered will undoubtedly be lengthier, but this serves to give you a flavor of the process.

Security ChecklistsThese simple checklists are often useful for developers to keep security principles in mind. Listed below is a subset of an actual checklist. These lists should also adapt themselves to the business goals, threat environment and usage scenarios associated with the application.

Procedure Category Goal

Denialof Service

Custom ApplicationVulnerability

Does application continue tofunction normally when given abnormally large input values, query strings, or cookie strings?

Cross SiteScripting

Custom ApplicationVulnerability

Does the application allow scripts to be reflected within the HTML content stream and execute when viewed in a browser? Does the application allow users to store persistently harmful scripts?

SQL Injection Custom ApplicationVulnerability

Does the application allow a user to elicit database errors or run arbitrary database commands by sending unexpected input sequences?

OS-levelCommandInjection

Custom ApplicationVulnerability

Does the application allow a user to execute system commands by submitting specially crafted values in form fields and/or query strings?

Authorization AuthenticationMechanisms

Does the application successfully restrictaccess to all pages, scripts and objects forwhich authentication is required? Is it possible to access restricted resources via forceful browsing?

AuthorizedPages/Functions

AuthenticationMechanisms

Does the application properly enforce security controls to registered orauthenticated users? Does the application allow a user to manipulate query strings and obtain access to restricted URLs?

AuthenticationEndpoint Request Shouldbe HTTPS

SSL Security Does the application allow userpasswords to be submitted over non-SSL connections?

Page 6 | www.redspin.com 2009 | White Paper

Page 8: Mapping Application Security to Business Value - Redspin Information Security

Source code analysis

tools can provide

a useful point

of automation

in identifying

potential risks and

vulnerabilities.Source Code Analysis

Source code analysis tools can provide a useful point of automation in identifying potential risks and vulnerabilities. This process may easily be integrated within the build cycle. However, when it comes to analysis those performing the analysis must be equipped with the system requirements and security specifications;

the threat profile for the system and any additional supporting documentation. The team is then equipped to examine the tool output and determine whether risks are relevant or not. The threat profile may also help rule out potential risks and vulnerabilities. Nevertheless, the findings in scope must be addressed.

Procedure Category Goal

CredentialTransport Overan EncryptedChannel

SSL Security Once an SSL session is established, are there any cases when a user browses to an HTTP resource?

Session TokenSecurity

Session Security Does the application utilize session IDs that are sufficiently long and random?

SessionHijacking

Session Security Does the re-use of Session IDs allow one user to obtain access to another user’s session?

HTTP Methods InfrastructureTesting

What HTTP methods does the web server support? Does the web server support HTTP methods such as PUT or DELETE?

Web ServerConfigurationCommon Paths

InfrastructureTesting

Are there configuration dependentvulnerabilities on the server? Dependingupon the web server type, what are themost common configuration errors andare they present?

DirectoryBrowsing

InfrastructureTesting

Can any directories be browsed?

User ErrorMessages

EnvironmentSecurity

Does the application reveal sensitiveinformation in its error messages related tothe presence or absence of user accounts?

AuthenticationEndpoint Request Shouldbe HTTPS

SSL Security Does the application allow userpasswords to be submitted over non-SSL connections?

Security Checklist (Cont.)

Page 7 | www.redspin.com 2009 | White Paper

Page 9: Mapping Application Security to Business Value - Redspin Information Security

The goal should be a

systematic reduction

in the number of

vulnerabilities over

time even as new

functionality is

added.

Flow – Integrating The Application Within The Information Security System

Data ClassificationAlthough this is a system wide information security initiative application developers and owners should create an inventory of data expected to be used and generated by the application. This exercise typically classifies data as High Business Impact (HBI), Medium Business Impact (MBI) or Low Business Impact (LBI) depending on the business requirements and the confidentiality, integrity and availability implications. Corporate security policy should help in this regard.

Information PrivilegeAgain corporate security policy can act as a reference point in making decisions regarding information privilege. Ultimately the decisions in this area will reside in the application security specification. It is useful though to consider the total scope of information sources and the associated privilege levels. Internal policy requirements as well as regulatory requirements will aid in shaping these decisions.

Identity and Access Management

When making identity and access management decisions it is important to have a clear understanding of the type of customers the application will be addressing. Clearly, different solutions will present themselves for a consumer facing banking application than for an internal travel and expense system. It is best to make this decision early and then iterate and refine implementation strategies as you refine the threat and risk models as well as the application specification.

PrivacyPrivacy is another area that should be dictated by corporate security policy and reinforced by the application. There may be circumstances where the application is intended to be used internationally and corporate policy has not yet caught up with privacy laws in those countries. In this case the application team must do their own research and fold back the results into corporate policy.

Security Enforcement Mechanisms

Keep in mind that the application resides within the infrastructure and you should take full advantage of the enforcement mechanisms that exist. The same is true of monitoring mechanisms. The application team does have to exert effort to ensure that they understand how enforcement works and what they expect to achieve (whitelisting, blacklisting, etc.).

Encryption and Key Management

Encryption can play a key role in reducing the attack surface for critical data. Here, you can use the output of the data classification exercise to decide what to encrypt. Key management is also an important factor in the overall process. A critical attribute to seek out are solutions where you don’t have to change your database table sizes to accommodate encryption. In other words, the encrypted data is the same size and data type as the clear text data.

Preproduction TestingWhether performed by QA or operations pre-production testing is usually performed using black box tools and should be done in an environment that is nearly (if not) identical to the production environment. This activity should be performed as part of the daily build cycle. The goal should be a systematic reduction in the number of vulnerabilities over time even as new functionality is added.

Page 8 | www.redspin.com 2009 | White Paper

Page 10: Mapping Application Security to Business Value - Redspin Information Security

System IntegrationVery few applications in modern environments exist as standalone entities. At the very least they employ directory services or back-up services. In most circumstances the application is providing or receiving data from other applications, sometimes directly or quite commonly through an enterprise message bus. It is imperative that the test environment reflects these conditions and that no vulnerabilities are introduced through this additional connectivity.

Change ManagementChange management controls when fixes to the application may be introduced. Processes should be stipulated by policy. An important practice is to document well the circumstances surrounding the need for the change. Often, a new set of vulnerabilities will have been found, but it is equally important to note if there has been a change in threat model or with the supporting infrastructure.

Regulatory ComplianceWe advocate creating policy such that internal compliance encompasses regulatory requirements. In any circumstance testing procedures need to ensure compliance with the applicable regulations. This is often a good opportunity to perform a web application assessment from a trusted third party in that compliance is generally a cut and dried area, but the assessment may also surface other important areas of consideration.

Audit ProcessOne aspect of the secure application development process should consider making the audit process easy and predictable. Strong documentation, predictable logging, and demonstration of adherence to policy all contribute towards a successful audit experience. Most importantly anticipating and preparing for an audit makes this task just another predictable item on the schedule rather than a fear inducing experience that can disrupt performance to schedule.

Incident ResponseWhat happens if there is a data breach? We recommend that you prepare in advance for the actions that will be taken. Further, responding to an incident will extend beyond just the core applications team. Be clear on the roles and responsibilities of security, operations and your own applications group.

Production TestingTo assess applications running in production a different strategy must be employed. One potential approach is to do application penetration testing with a suite of attacks that are known to be non-invasive and likely will not take down the application. A better option, if the application is deployed in a virtualized environment, is to take a “snapshot” of the application to be tested. This image is then moved to a staging environment where it can be tested thoroughly. When vulnerabilities are identified the application must be fixed, tested and then released back to production under change control.

Risk ManagementAnother important practice is to actively manage risk associated with the application. We have found that this can be done most effectively by developing a model that accounts for the likelihood and probability of loss related events. For example, quantitatively modeling the risk of financial loss due to data breach, fines associated with non-compliance or business loss due to application downtime can be helpful in terms of allocating resources for prevention. But it is also useful in terms of helping management understand why so much effort is being expended around application security. Once again, this is an ongoing process that must stay current with emerging threats whether internal, external or from partner organizations.

Impact – Creating Business Value

Page 9 | www.redspin.com 2009 | White Paper

Page 11: Mapping Application Security to Business Value - Redspin Information Security

Redspin delivers the highest quality information security assessments through technical expertise, business acumen and objectivity. Redspin customers include leading companies in areas such as health care, financial services and hotels, casinos and resorts as well as retailers and technology providers. Some of the largest communications providers and commercial banks rely upon Redspin to provide an effective technical solution tailored to their business context, allowing them to reduce risk, maintain compliance and increase the value of their business unit and IT portfolios. Penetration Testing

About Redspin www.redspin.com

Business ImpactThe most important result of following this process is an application that is up and running and fulfilling its mission whether that is to make employees more productive or to generate revenue through online transactions.

The extended team, including operations, security and business unit management should have a high degree of confidence in the following areas:

The corporate brand is protected•Risk has been minimized•The service will be available (or at least not down because of security issues)•Employees will be productive•Regulatory fines will be avoided•

Reputational damage will be avoided•

Page 10 | www.redspin.com 2009 | White Paper


Recommended