Writing Security Story

Security Story is an artifact that anyone (developer, manager, business owner, user,  etc ) can read and feel assured that their security concerns are addressed.It is a collaborative effort that highlights how the implementation, application design, service infrastructure, organization processes, and the business environment itself protect what’s important to the business.

There is no fixed format or content for a security story as a security story should evolve over the life of an application. A story may contain text, images, diagrams, spreadsheets, links, and other formats.

security story can be write in many ways most commonly it can start with capturing the concerns of application stakeholders, including both application providers and application users followed by list down the lifelines of the application.You need to create strategy to defend the each lifeline.Build the specific defence and proof of these defenses should be included in story. security stories are not static they has to change when condition changes .

 

Reference: http://www.ruggedsoftware.org/

What It Takes To Be Rugged.

Recently one of my friend ask if there is any good reference to to incorporate security testing with agile development. Unfortunately we didn't able to find any such reference.Although Rugged  approach look promising and also claim to support agile way of security testing of application.  The ultimate goal of including Security testing in SDLC is to produce secure code.

Rugged approach doesn't focus only finding vulnerabilities but try to improve overall  capability of an organization to develop secure Code. To achieve this goal organization must establish process to monitor  upcoming threats. there should be a communication path so everyone can share all the security-relevant information about the application . A standard mechanism of defence should be use  across the organization . Don't trust third party component used in your product, establish guidelines for each component that details the secure use of that library. Build applications that will be largely resistant to the threats of the future for example using strong input validation, in-application attack detection and safe interpreter use can eliminate many flaws forever. Defences should  be continuously verified and monitored all the way through development and into production. Being Rugged means that you constantly patch and refactor your software development organization to eliminate the organizational bugs that are causing insecure code.

 

Reference: http://www.ruggedsoftware.org/

The Rugged Software Manifesto

• I am rugged and, more importantly, my code is rugged.
• I recognize that software has become a foundation of our modern world.
• I recognize the awesome responsibility that comes with this foundational role.
• I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
• I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic, and national security.
• I recognize these things - and I choose to be rugged.
• I am rugged because I refuse to be a source of vulnerability or weakness.
• I am rugged because I assure my code will support its mission.
• I am rugged because my code can face these challenges and persist in spite of them.
• I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.

 

Reference: http://www.ruggedsoftware.org/