Software Assurance - Secure Architecture

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.

The Secure Architecture practice primarily focuses on providing your development teams with reusable services and infrastructure, along with security-focused design patterns. Having these components in place standardizes development practices across the organization, reducing overall development risk. A nice side effect is saved time, since developers don't have to "reinvent the wheel" and/or maintain separate codebases performing the same basic function in different projects.

First Maturity Level

Initially, the focus should be on compiling a list of recommended software frameworks and adding some security guidelines to your design process. One approach is to start by interviewing your technical project leads to identify the most common third-party frameworks and software packages in use, focusing on the major functional components. Having compiled an overall list, you can then group them into categories based on functionality provided (for example: e-mail messaging, database connectors, cryptography). To add more value to your framework list, you should interview the teams about their experiences with particular packages, including factors such as complexity, ease of integration, and vendor responsiveness in terms of support issues and bug/vulnerability fixes. The creation of the framework list should be driven by senior developers and architects, but project managers and your security organization also need to be included in the process. Once the list is complete, it should be actively advertised to your development staff to raise awareness and encourage use.

During the design phase, the project team should work with your security organization to factor in a set of guiding security principles. SAMM lists some of the following as examples (I have added some brief explanations):

• Defense in depth - Multiple layers of security should protect your assets and infrastructure
• Securing the weakest link - Focus security efforts on the component(s) most likely to be breached
• Use of secure defaults - A developer can't forget to change a setting if it's already configured for him
• Simplicity in design of security functionality - Complexity introduces additional risk
• Secure failure - When the system fails, it should revert to a known secure state
• Balance of security and usability - Don't sacrifice security solely for usability, but don't make the system "unusably secure"
• Running with least privilege - Elevate privileges only when needed, then drop them back down
• Avoidance of security by obscurity - Assume the attacker has your full source code and can see all unencrypted network traffic

The team should work closely with your security organization and pay special attention to external interfaces (see "weakest link" above).

Second Maturity Level

Building on the idea of a framework list, the next step is to create a set of shared security services across the organization. The two most common functions for such systems are authentication (single sign-on) and access control/auditing, but other examples could include secure e-mail, secure data storage, and even configuration management (which has important security implications; more on that when we get to the Environment Hardening practice). For authentication, LDAP and Active Directory are two commonly deployed frameworks that allow centralized management of users and access permissions (usually handled via group memberships). As an aside, centralized authentication systems have many advantages beyond increased security: reduced administrative overhead for account creation/maintenance, less help desk calls for user password resets, and less complexity when users change roles in the organization. It's important to note that centralized authentication is by no means limited to your internal applications. If your organization provides multiple separate services or websites to its customers, the same principles can be leveraged to create a single account that end-users use for all systems. For example, Google takes this approach with its Google Account, which is used to access all of its many services: Gmail, Google Voice, Google Docs, Picasa, etc.

At this maturity level, the design phase moves beyond simply incorporating guiding principles, moving toward specific design patterns for each software category. SAMM lists the following common types of application categories: "client-server applications, embedded systems, desktop applications, web-facing applications, web services platforms, transactional middleware systems, mainframe applications." These may have to be refined to suit your organization, or further sub-divided according to platform, development language, etc. For each category, your architects and senior developers should work with your security organization to identify the applicable best-practice design patterns. Some examples of secure design patterns are input validation, privilege separation, secure centralized logging, and many more. In October 2009, Carnegie Mellon University published an excellent, very comprehensive technical report on generalized secure design patterns.

Third Maturity Level

This maturity level brings together the framework/services component and the design principles/patterns: your organization should create a reference architecture/platform in the form of a shared codebase. SAMM lists the following common examples of reference platforms: "frameworks for model-view-controller web applications, libraries supporting transactional back-end systems, frameworks for web services platforms, scaffolding for client-server applications, frameworks for middle-ware with pluggable business logic." By leveraging these reference platforms, developers are not only leveraging existing, vetted code, but are also "forced" to implement a vetted design (model-view-controller, separation of business logic from code, etc.).

The final component is to perform ongoing validation activities to ensure that these guidelines at all maturity levels are being followed in practice. These checks can be easily integrated into routine project reviews/audits, either by your organization's PMO or similar project governance body, or by your security organization. Parameters to monitor include adoption/usage rates of recommended frameworks, shared services, security principles, design patterns, and reference platforms. In addition, it is helpful to also keep an eye on use of non-recommended frameworks and unused/misused design patterns since this can indicate that the organization's official library of frameworks and design patterns may need to be updated to more closely align with current trends.

Summary

In many development shops today, creating insecure software is the default--and often simply due to a lack of education, time, and available tools. By creating a Secure Architecture within your organization, you're making secure software the path of least resistance for your development teams by giving them the tools and resources to not only enhance security but increase their productivity. Shared infrastructure such as recommended frameworks, security services, and reference architectures take much of the security burden off your developers. By providing security principles and design patterns, you make it easy for your architects to create secure designs. The majority of developers and architects are not security experts (nor are they expected to be), so it makes sense to give them ready-made components that have been created and/or vetted by your organization's security experts.

Next time, we will start our discussion of the Verification function, which includes the Design Review, Code Review, and Security Testing practices.