Want to Play Poker? ... Protection Poker: A New Practice to Secure Application Development

Researchers at NC State have developed a new innovative practice called Protection Poker. This interactive tabletop process allows Developers, Security Experts, Upper Management, and other various key stakeholders to perform threat modeling without the burden of discussing code implementation. The process would be executed prior to development and most likely after draft requirements have been defined. It would allow for additional changes to the RTM, if needed.

"The dual purpose of a Protection Poker session is (1) to structure a collaborative, interactive, and informal practice for misuse case development and threat modeling; and (2) to spread software security knowledge throughout a team."

More information can be found here:
Poker: The New Game in Secure Application Development
Protection Poker: Structuring Software Security Risk Assessment and Knowledge Transfer

WAS 2.0 - Are you ready?

Web 2.0 technologies are gaining more and more attention as each day passes. It is all over the Internet and even beginning to enter the Government space. How does it affect us?

Well, Web 2.0 offers a more enjoyable Web experience through enhanced collaboration, information sharing, and user functionality. This comes with a cost and additional security risks to the organization and end users. Securing Web 2.0 is usually an afterthought; mainly because security impedes the focus of being user-friendly and innovative. Currently, Web 2.0 security is not nearly as strong as Web 1.0. We are just getting up to speed on implementing Web 1.0 security controls. Introducing a new set of variables will increase the complexity of Web Applications. We're not ready!

Web Application Security 2.0 (WAS 2.0) will be more common in the upcoming year as the focus will shift more in the direction of Web 2.0. You may have already heard the term "Government 2.0". GSA has already launched new Web 2.0 tools for USA.gov with many Departments/Agencies following in their footsteps. President Obama has embraced Web 2.0 during his campaign and will continue to do so throughout his administration. The "Change" that is about to come will be a drastic overhaul of legacy Government systems, but does cyber security play as big of a role as President Obama originally pitched?

Here are just a few basic Web 2.0 security risks among the many possibilities and examples of Government 2.0 Security Incidents/Vulnerabilities ...
Top 10 Web 2.0 Attack Vectors
President Obama's Campaign w/ a Trojan Horse
Government and Twitter + Twitter Hacked
Congressman uses Twitter and Reveals "Secret" Location

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.

QA and Security "Testing" ... a Logical Combination

As stated in my previous post, security "testing" fits into Quality Assurance. This a hot topic and is discussed again here. This is the final gate that applications need to successfully pass in order to be considered for deployment. This sort of "testing" is not going to be thorough; especially if QA lacks security expertise. So how do we solve this problem?

Simple. Develop test plans and specific test cases that can be executed by QA Team members. It reduces the amount of work of the Security Team with the bulk of it done by QA. It will also serve as an indicator of security posture. If a security defect is found, the Security Team can be alerted for further analysis. This Security Review is a perfect way to enhance Web Application Security.

Effective security testing is important, but resources may be limited. Test plans and test cases are the bread and butter of the QA Team, so it makes sense.