This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Design Review, the first security practice in the Verification function.

The Design Review (also called Architecture Review) is a crucial milestone in the software assurance lifecycle, providing an opportunity to spot major high-level issues early in the process when they are still relatively inexpensive to fix. It is typically conducted by security-savvy staff who are either on the project team (for large projects) or in conjunction with the project architect(s) on smaller teams.

First Maturity Level

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Secure Architecture, the third and final security practice in the Construction function. Starting with this post, I am also changing the title naming convention to refer more generally to "software assurance" rather than "secure development." Software assurance is an industry-standard term and encompasses the full spectrum of software security activities across an organization.

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Security Requirements, the second security practice in the Construction function. Almost all software development is driven by a set of business requirements, but unfortunately security is often not factored into these requirements at the start of a project. To address this issue, analysts and managers should work to integrate Security Requirements into a development project from the beginning. Security Requirements serve as a "hook" for security: once security has been written into the requirements, it will naturally follow the development lifecycle through design, development, testing, and deployment to production.

While the SAMM model lists Governance as the first business function, we will start with the Construction and Verification functions since they address some of the more traditional and well-known aspects of the software development lifecycle. Once we have explored these functions, the infrastructure discussed in the Deployment and Governance functions is a logical extension.

Over the course of the next several months, this blog will explore the Software Assurance Maturity Model (SAMM) in detail. Last time, we talked about some of the many methodologies for integrating secure practices into the development cycle, but in the interest of keeping it simple we will be focusing on SAMM going forward.

First, a quick introduction to SAMM: according to its creators, SAMM is "an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization." The model is based on the following three premises, which ensure that it is realistic and flexible:

Over the last few months, this blog series has focused on the technical details of integrating security during the development phase. While this is the most critical phase, where the proverbial rubber meets the road, developers alone cannot bear the burden of producing secure code. To achieve robust security, it must be integrated into the whole software development lifecycle, from requirements to testing and beyond.

There has been a lot of work in this space recently. This post will attempt to give an overview of the various methodologies and approaches, but it is not designed to be an exhaustive list (and is shown in no particular order).

Since I started this series several months ago, OWASP has released its final version of its latest and greatest Top 10 list for 2010. In today's post, we will use this list to summarize the vulnerabilities covered so far and briefly talk about some of the new additions. For most of these, I have simply linked the title of the vulnerability to the corresponding post in my blog series.

Due to vacation schedules and lots of other things going on this summer, "next week" has turned into "next month" for this final post in my top 10 series. Today's subject may be a little surprising to many developers: Aren't buffer overflows so 2003? Hasn't this been fixed in virtually all modern programming languages by preventing direct memory access? While the second statement is certainly true, it doesn't mean that today's developers don't need to be aware of buffer overflows, especially when interacting with closed-source and/or legacy software written in languages that allow arbitrary memory access (C and C++ being the most common examples).

No matter how well-written or secure your application is, Denial of Service (DoS) attacks always pose a risk. Most web applications are publicly accessible by design, so the server/application really has no way to tell 10,000 legitimate user requests from 10,000 malicious requests designed to bring it down. If a DoS attack originates from a single source or from a few sources, it can be blocked fairly easily once the source(s) are identified. Unfortunately, most DoS attacks today are actually DDoS attacks (distributed DoS), which means that they originate from hundreds or thousands of different places across the Internet, most commonly from botnets. This makes it nearly impossible to shut down the malicious traffic without also cutting off the legitimate users...which is exactly the point of a DoS attack.

Some common types of DoS attacks are the following:

Writing secure code is the most important aspect of secure development, since this is where the proverbial rubber meets the road. However, there are many other environmental factors that contribute to your application's overall security posture. This includes the application/web server, backend systems such as databases, and of course the underlying operating systems and network infrastructure. Consider the following common vulnerabilities: