Monday, February 9, 2009

Web Application Security - Part 2: How to Define Security Requirements

In most organizations today, a detailed framework for defining security requirements does not exist. Typically, NIST SP 800-53 is translated and defined as the high-level security requirements and standards for use in the development of an application or system.

There is a gap between the standards listed in NIST SP 800-53 and the actual defined requirements being tracked throughout the SDLC. Usually all security requirements are thrown into a bucket that is on a separate page from the rest. This may be logical, but what happens? It may be forgotten. It may not be integrated into current development of other functions. It is not a top priority and may end up being satisfied retroactively. What should happen? Security requirements should be integrated with other requirements where it fits with that particular function or component.

A framework for translating NIST standards into detailed traceable security requirements needs to be adapted for every project. Security best practices, developer security methods and techniques, and additional countermeasures can all be combined and tailored to fit organizational needs for a holistic security approach. This framework should be written in such a way that all teams (Security, Development, QA, etc.) can understand the security requirements to be able to translate them into their own activities. A Security Requirements Framework (SRF) is a more effective tool for integrating traceable security requirements and best practices into the SDLC.
Posted by at 7:17 PM
Labels: , , , , ,

4 comments:

  1. Right on. To complement Jason's points, many organizations today develop security requirements based on 800-53. That may be sufficient if your goal merely is “compliance readiness”. Else, we can only generate FUNCTIONAL security requirements from 800-53. Others come from the maturity of the organization’s security program. For example, Requirement generated by historical data: An organization has been performing VA/SCA for a period of time and notice that there is trend in most codes (developers are not validating input). This should be added to what Jason called SRF.
    ReplyDelete
  2. You are right that there is a gap between 800-53 and SDLC requirements for each project. It's an unfortunate reality that NIST has to write it's guidance for the broadest audience and then encourage end users to properly adapt them for their own needs.

    This may be changing slightly in the future. NIST can't be too specific when writing documentation but it has changed its focus in the new FISMA documentation (800-37 Rev 1, 800-53 Rev 3, 800-39, etc.) from a C&A cycle to an authorization process tied to the paired Risk Management Framework and Software Development Life Cycle. This should help ease the requirements for SDLC practitioners to meet authorization process requirements.

    If you haven't looked at NIST SP 800-64 Rev. 2, Security Considerations in the System Development Life Cycle it is worth reviewing. While not a perfect document it can aid in the process of identifying authorization requirements for projects. I recently contacted NIST regarding their plans for what I see as a glaring omission in their guidance, web application security. They are planning on working on guidance for this but as yet are not actively developing the guidance.

    For what it's worth I am currently working on mapping 800-53 to the newly developed OWASP Software Assurance Maturity Model (SAMM) ( http://opensamm.org/Home.html ). So far I am liking some of the design features of this framework and think it may be useful as a C&A/security authorization process tool.
    ReplyDelete
  3. Dan, thanks for the feedback. I agree that web application security is a glaring omission from NIST's library. The commercial side is way ahead of NIST; no surprise at all. The problem is the lack of collaboration between private and government sectors. Hopefully, this will change in the Obama Administration.

    There is a lack of implementation guidance associated with NIST. I believe that more tools and useable methodologies need to be created. Only after they have been integrated into existing processes will we see improvement.
    ReplyDelete
  4. I am a Sr. IT Security contractor for the USDA, and we are an app dev shop. NIST guidance has largely been written as general guidance at the system level. It is very true that current NIST guidance lacks a security perspective at the application layer. I am authoring and modeling a process and corresponding documentation similar to what you have indicated here; security tasks as they apply to each phase of the SDLC, including the RA and the C&A process.

    One other large gap I see in my day-to-day work is lack of written policies or even basic methodology on application level data archival procedures and overall application decommissioning process and policies.

    I certainly have my work cut out for me, but change is coming. It's a very huge, slow moving locomotive on this side of the wall.
    ReplyDelete

Subscribe to: Post Comments (Atom)