This post originated from an RSS feed registered with Web Buzz by Tim Vernum. Original Post: What is "Secure Architecture" Feed Title: Secure by Design Feed URL: http://www.securearchitecture.net/feed/rss2 Feed Description: A blog about the intersection of security and architecture Latest Web Buzz Posts Latest Web Buzz Posts by Tim Vernum Latest Posts From Secure by Design

My previous post threw the term "architecture" about, but what is architecture? And what is "secure architecture"?

Architecture I run a training course that covers Security Principles and Architecture. In that course I use the following definition of architecture

The application of patterns and abstractions to realise non-functional requirements

(I know I lifted that definition from someone else, but I can't remember where I got it.)

Typically the "non-functional" requirements are things like "developer efficiency", "code maintainability" and "scalability", but "system security" is (for the most part) a non-functional requirement also.

If architecture is the application of patterns and abstractions to realise non-functional requirements, then a "secure architecture" is one that applies those patterns and abstractions to realise security requirements.

Cross Dependencies However that is not a 1-dimensions measure, for within that scope we can ask "does this architecture allow for new features to be built in a way that is both efficient and secure?". So, for example, we want to apply a set of patterns in such a way as to allow developers to easily implement new database queries, without introducing SQL injection holes. And we want to be able to create an underlying model for users (with groups, roles, attributes, etc) that allows the administrators to be able to apply their required security policy with little or no code changes.

A secure architecture cannot be concerned purely with "is this underlying code secure" and ignore the other system requirements (functional and non-functional), any more than we can secure a server by disconnecting it from the network. A secure architecture needs to support doing all the things that the system is intended to do, and to do so securely.

Trade-Offs Like all things in architecture, this is a trade-off. Certain requirements (security-related, or otherwise) will have a negative impact on other requirements. Simply by implementing security controls in an application, you increase its complexity and thereby decrease maintainability. Such trade-offs are obviously necessary in order to implement any system. The right architecture is one that finds an appropriate balance between the various competing requirments.

It's easy to fall into the trap of thinking that security is a black / white issue., that it must be the most important thing, or else it will be ignored. It's true that security can't be half-done - a "little bit" secure isn't secure at all - but security is a risk assessment, and like any risk assessment there are some threats that we decide not to mitigate - or to migtigate only partially - in order to focus on some other requirement.

So secure architecture must also mean know which security threats to mitigate, and which ones to consciously accept.

Where the Rubber hits the Road A software architect who cares about security - and we all should - has a tough job. It's not just a matter of finding the right patterns to secure the system, it's also about balancing security requirements against other requirements and performing risk assessments - knowing what to do and what not to do.

This blog is my attempt to help wade through that mess, and offer some practical suggestions to help software architects of all disciplines find the right balance of security.