by Adam Braun
OWASP (Open Web Application Security Project) was started on September 9, 2001 By Mark Curphey and Dennis Groves. Since late 2003, Jeff Williams served as the volunteer Chair of OWASP until September 2011. The current chair is Michael Coates, and vice chair is Eoin Keary. The OWASP Foundation, a 501(c)(3) organization (in the USA) was established in 2004 and supports the OWASP infrastructure and projects. OWASP is not about individual recognition but community knowledge sharing. The OWASP Leaders are responsible for making decisions about technical direction, project priorities, schedule, and releases. Collectively, the OWASP Leaders can be thought of as the management of the OWASP Foundation.
OWASP is an open-source application security project. The OWASP community includes corporations, educational organizations, and individuals from around the world. This community works to create freely-available articles, methodologies, documentation, tools, and technologies. The OWASP Foundation is a charitable organization that supports and manages OWASP projects and infrastructure. It is also a registered non profit in Europe since June 2011.
OWASP is not affiliated with any technology company, although it supports the informed use of security technology. However CabForward in Austin TX is a member of the organization and is helping to author the Rails Cheatsheet for OWASP.
OWASP is also an emerging standards body, with the publication of its first standard in December 2008, the OWASP Application Security Verification Standard (ASVS). The primary aim of the OWASP ASVS Project is to normalize the range of coverage and level of rigor available in the market when it comes to performing application-level security verification. The goal is to create a set of commercially-workable open standards that are tailored to specific web-based technologies. A Web Application Edition has been published. A Web Service Edition is under development.
If you want to know more about CabForward’s℠ involvement with OWASP, or about implementing Application Security into your business, Contact Us.
“Rugged” describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure, and resilient software. Rugged organizations use competition, cooperation, and experimentation to learn and improve rather than making the same mistakes over and over. Rugged organizations also actively seek out threats and create defenses before they are a problem.
“Rugged” can also be used to describe the software applications produced by rugged organizations. These applications are not only well-protected against attacks, but are also able to analyze themselves, report on their own security status, detect attacks in progress, and respond appropriately.describe the image
Rugged is NOT a technology, process model, SDLC, or organizational structure. It’s not even a noun. Rugged is NOT the same as “secure.” Secure is a possible state of affairs at a certain point in time. But rugged describes staying ahead of the threat over time. Rugged organizations create secure code as a byproduct of their culture. You are rugged because you run the gauntlet, instrument your organization and your code, constantly experiment to see if anything breaks, and survive the process of hardening yourself through real-world experience. Rugged organizations produce rugged code – designed to withstand not just today’s threat, but future challenges as well. Rugged also represents a balance between two approaches to establishing, verifying, and monitoring security – a positive control-based approach, and a negative attack based approach.
To encourage this culture, one of the key ideas is to make security visible with a specific and understandable “security story” that captures everything necessary to understand why the code and the organization that built it are Rugged. The security story is both a guide and a reflection of security in the development organization and the software. Making it explicit allows you to create a culture where “builders” and “breakers” can compete and cooperate to make it better. Without a unifying story, all you have are thousands of security fragments that are impossible to understand.
The best approach to these industry game changers is to first understand how they came about and to implement these methodologies into the development process. The concept is simple, but its implementation is really hard, because of the lack of quality standards/metrics in our industry. This is a really important concept, and its complete lack of adoption (and traction) speaks volumes for our industry. For example, how am I supposed to make informed decisions as a software/website user if I cannot be exposed to something like this:
At CabForward℠, we don’t view Rugged as a burden or cost. In fact, this approach should yield time and money savings, while reducing risk. Because the alternative is unacceptable, we choose to be rugged. Not because it is easy, but because it is necessary, and we are up to the challenge.