Comments on Jason Yuen - "Understanding Information Security": Web Application Security - Part 2: How to Define S...

I am a Sr. IT Security contractor for the USDA, an...

2009-05-28T14:57:27.055-04:00

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.

Dan, thanks for the feedback. I agree that web ap...

2009-02-10T11:48:00.000-05:00

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.

You are right that there is a gap between 800-53 a...

2009-02-10T11:28:00.000-05:00

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.

Right on. To complement Jason's points, many organ...

2009-02-10T11:11:00.000-05:00

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.