The Business Forum

"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

Understanding Web Application Security Challenges.

Contributed by IBM Corporation

 

Introduction

As businesses grow increasingly dependent upon Web applications, these com­plex entities grow more difficult to secure. Most companies equip their Web sites with firewalls, Secure Sockets Layer (SSL), and network and host security, but the majority of attacks are on applications themselves - and these technologies cannot prevent them.

This paper explains what you can do to help protect your organization, and it discusses an approach for improving your organization's Web application security.

What makes Web applications vulnerable?

In the Open System Interconnection (OSI) reference model,1 every message travels through seven network protocol layers. The application layer at the top includes HTTP and other protocols that transport messages with content, including HTML, XML, Simple Object Access Protocol (SOAP) and Web services.

This paper focuses on application attacks carried by HTTP — an approach that traditional firewalls do not effectively combat. Many hackers know how to make HTTP requests look benign at the network level, but the data within them is potentially harmful. HTTP carried attacks can allow unrestricted access to databases, execute arbitrary system commands and even alter Web site content.

Without governance measures to manage security testing throughout the application delivery lifecycle, software teams can expose applications to HTTP-carried attacks as a result of:

  • Analysts and architects viewing security as a network or IT issue, so that only a few organization security experts are aware of application-level threats.

  • Teams expressing application security requirements as vague expectations or negative statements (e.g., You will not allow unprotected entry points that make test construction difficult).

  • Testing application security late in the lifecycle — and only for hacking attempts.

Typical Web application attacks.

A Web application's specific vulnerabilities should dictate the technology you use to defend it. Figure 1 shows many points within a system that might require protection. Often, it is best to employ generic countermeasure concepts first to help ensure that you choose the technology best suited to your needs rather than one that claims to counter the latest hacking technique.

Enterprises can employ multiple preventive measures against Web application breaches caused by impersonation, tampering and repudiation. Table 1 shows common threats and preventive measures.  However, specific threats to your application may be different.

Preventive measures can also be taken to ward off attacks that attempt to access sensitive information and overwhelm server resources.

 

By applying several basic practices, software development teams can help prevent common Web application security violations and reduce remediation costs.

Basic guidelines for providing security for Web applications

By using security-specific processes to create applications, software development teams can guard against security violations like those shown in table 1.  Specifically, you can apply several basic guidelines to existing applications and new or reengineered applications throughout your process to help achieve greater security and lower remediation costs, such as:

  • Discover and create baselines: Conduct a complete inventory of applications and systems, including technical information (e.g., Internet Protocol [IP], Domain Name System [DNS], OS used), plus business information (e.g., Who authorized the deployment? Who should be notified if die application fans?).  Next, scan your Web infrastructure for common vulnerabilities and exploits. Check list serves and bug tracking sites for any known attacks on your OS, Web server and other third-party products. Prior to loading your application on a server, ensure that the server has been patched, hardened and scanned. Then, scan your application for vulnerabilities to known attacks, looking at HTTP requests and other opportunities for data manipulation. And, finally, test application authentication and user-rights management features and terminate unknown services.
     

  • Assess and assign risks:  Rate applications and systems for risk — focusing on data stores, access control, user provisioning and rights management. Prioritize application vulnerabilities discovered during assessments. Review organizational, industry and governmental policy compliance. And identify both acceptable and unacceptable operations.
     

  • Shield your application and control damage:  Stay on top of known security threats and apply available patches to your applications and/or infrastructure. If you cannot fix a security issue, use an application firewall, restrict access, disable the application or relocate it to minimize exposure.
     

  • Continuously monitor and review:  Schedule assessments as part of your documented change management process. When you close one out, immedi­ately initiate a new discovery stage.

The Rational Unified Process delivers a comprehensive, iterative framework for developing Web applications based on industry best practices.

Understanding the Web application lifecycle

Shown in figure 2, the IBM Rational® Unified Process®, or IBM RUP*, solution delivers a widely used iterative process framework for developing Web applications based on industry best practices. The core phases of the framework (which may require two or more iterations to complete) are:

  • Inception: Establish a business case, scope and operational vision. Then, create an initial use-case model, project plan, risk assessment and project description, including core requirements, security requirements (such as clarification of security compliance and policies), constraints, features and prototype candidate architectures.
     

  • Elaboration: Refine your vision, address architecturally significant scenarios to establish a baseline architecture, and detail the use-case model. Then, create and test one or more prototypes to mitigate technical risks.
     

  • Construction: Develop detailed designs for specific components and their interactions with other applications, continuously tracking against requirements. Generate code and test components for performance, reliability and security, while tracking and resolving issues and integrate tested components into a first release.
     

  • Transition: Deploy the application, train users and conduct beta testing to verify security and performance and validate the application against requirements. Continuously monitor performance, reliability and security as the application undergoes changes.

 Each of the four phases of the Rational Unified Process — inception, elaboration, construc­tion and transition — spans multiple disciplines and may require multiple iterations.

Fixing a design error after a Web application has been deployed costs approximately 30 times more than addressing it during design.  To help prevent expensive fixes, enterprises can build application security testing approaches into their development and delivery process.


 

Considering the right testing approaches

To help prevent expensive fixes, organizations need to build application security testing approaches, such as those shown in figure 3, into their development and process alongside other quality management measures.

 

Black-box and white-box testing approaches can leverage commercial tools, while gray-box testing calls for a uniquely defined application framework.


 

With help from a third-party consultant, enterprises can employ training, communication and monitoring activities to improve security awareness.

Four strategic best practices for protecting Web applications

To address security-related issues as they pertain to Web applications, organizations can employ four broad, strategic best practices.

1. Increase security awareness

This encompasses training, communication and monitoring activities, preferably in cooperation with a consultant.

  • Training

Provide annual security training for all application team members: developers, quality assurance professionals, analysts and managers. Describe current attacks and a recommended remediation process. Discuss the organization's current security practices. Require developers to attend training to master the framework's prebuilt security functions. Use vendor-supplied material to train users on commercial off-the-shelf (COTS) security tools, and include security training in the project plan.

  • Communication

Collect security best practices from across all teams and lines of business in your organization. Distribute them in a brief document and make them easily accessible on an intranet. Get your IT security experts involved early and develop processes that include peer mentoring. Assign a liaison from the security team to every application team to help with application requirements and design.

  • Monitoring

Ensure that managers stay aware of the security status of every application in production. Track security errors through your normal defect tracking and reporting infrastructures to give all parties visibility.

2. Categorize application risk and liability

Every organization has limited resources and must manage priorities. To help set security priorities, you can:

  • Define risk thresholds and specify when the security team will terminate application services.
     

  • Categorize applications by risk factors (e.g., Internet or intranet vs. extranet).
     

  • Generate periodic risk reports based on security scans that match issues to defined risk thresholds.
     

  • Maintain a database that can analyze and rank applications by risk, so you can inform teams of how their applications stack up against deployed systems.

To help govern development and delivery processes and to manage compliance, enterprises must establish a security program and set a zero-tolerance enforcement policy.

By integrating security testing throughout the software delivery lifecycle, enterprises can improve application design, development and testing.

3. Set a zero-tolerance enforcement policy

An essential part of governing the development and delivery process, a well-defined security policy can reduce your risk of deploying vulnerable or noncompliant applications. During inception, determine which tests the application must pass before deployment, and inform all team members. Formally review requirements and design specifications for security issues during inception and elaboration — before coding begins. Allow security exceptions only during design and only with appropriate executive-level approval.

4. Integrate security testing throughout the development and delivery process

By integrating security testing throughout the delivery lifecycle, you can have significant positive effects on the design, development and testing of applications. You should base functional requirements on security tests your application must pass, making sure that your test framework:

Uses automated tools and can run at any point during the development and delivery process.

  • Includes unit and system tests as well as application-level tests.
     

  • Allows for audit testing in production.
     

  • Includes event-driven testing.
     

  • Uses an agile development methodology for security procedures.
     

  • Can be run during coding, testing, integration and production activities.

During the inception phase, enterprises can structure requirements that address multiple application-level security concerns.  Table 4 suggests ways to structure requirements that address a spectrum of application-level security concerns during the inception phase.

Coding and data validation measures can offer significant benefits during the elaboration and construction phases of the software development and delivery process.

Table 5 details activities during elaboration and construction that align with defined security requirements.


By improving authentication, authorization and configuration management practices, enterprises can address security issues during the elaboration and construction phases.

Session protection, exception management, and auditing and logging can also provide opportunities for improving the security of Web applications.


Through event-driven testing, enterprises can integrate security tests right into the application being developed.

In addition to making security an integral part of the application development and delivery process, you can integrate security tests right into the application you are building to conduct event-driven testing. In this case, where a user makes a request and the application responds, the test compares the response to an expected or previously stored response to determine whether the system is operating properly. For example, in figure 3, an application uses a database as its back-end component. The tester inserts a spy proxy and a verifier into the request flow, telling the verifier what a normal request should be so that the verifier can compare it with the spy proxy's actual request.

Any service, e-mail, XML or legacy service can serve as a back end. How you implement the code to review requests depends on the application architecture.  For example, your spy component might be a mock data access object, a proxy or a class that inherits from the front-end service. You can also create code specifically for a test that you insert into the data stream to supply reporting data needed by the testing framework. Coordinating the testing objects gives you comprehensive, fine-grained control of a range of tests. You can perform these tests using either black-box or white-box testing, improving your chances of catching security problems early in the lifecycle — before they pose a serious business risk.   

For more information

To learn more about the IBM Rational methodology and how you can create security-rich Web applications using IBM Rational automated lifecycle security took, please contact your IBM representative or visit:

ibm.com/software/rational/offerings/testing/webapplicationsecurity

© Copyright IBM Corporation 2008

IBM Corporation Software Group Route 100 Somers, NY 10589 U.S.A.

Produced in the United States of America

All Rights Reserved.

IBM, the IBM logo, Rational, Rational Unified Process and RUP are registered trademarks of International Business Machines Corporation in the United States, other countries, or both.
 

The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this documentation, it is provided "as is" without war­ranty of any kind, express or implied. In addition, this information is based on IBM's current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this documentation or any other docu­mentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of IBM software.
 

IBM customers are responsible for ensuring their own compliance with legal requirements. It is the customer's sole responsibility to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regula­tory requirements that may affect the customer's business and any actions the customer may need to take to comply with such laws.
 

This publication contains other company Internet addresses.  (IBM is not responsible for information found on these Web sites.)

   1  International Organization for Standardization;  http://www.iso.org

   2  www.nist.gov/director/prog-ofc/report02-3.pdf

Search Our Site

Search the ENTIRE Business Forum site. Search includes the Business
Forum Library, The Business Forum Journal and the Calendar Pages.

Editorial Policy: Nothing you read in The Business Forum Journal should ever be construed to be the opinion of, statements condoned by, or advice from, The Business Forum Institute, its staff, workers, officers, members, directors, sponsors or shareholders. We pass no opinion whatsoever on the content of what we publish, nor do we accept any responsibility for the claims, or any of the statements made, within anything published herein.  We merely aim to provide an academic forum and an information sourcing vehicle for the benefit of the business and the academic communities of the Pacific States of America and the World. Therefore, readers must always determine for themselves where the statistics, comments, statements and advice that are published herein are gained from and act, or not act, upon such entirely and always at their own risk.  We accept absolutely no liability whatsoever, nor take any responsibility for what anyone does, or does not do, based upon what is published herein, or information gained through the use of links to other web sites included herein.                                     Please refer to our:  legal disclaimer

The Business Forum
Beverly Hills, California, United States of America

Email:  [email protected]
Graphics by DawsonDesign
Webmaster:  bruceclay.com

 ©  Copyright The Business Forum Institute - 1982 - 2014  ** All rights reserved.
  The Business Forum Institute is not responsible for  the content of external sites.

Read more