Application Security

Your New Rosetta Stone: The Security Architecture

What? We’re not coding yet?

Not yet. Almost. I promise! This, and one more post, and you’ll start seeing honest to goodness code. PHP and Java. Together at last!

To be honest, I think coding’s more enjoyable, too, but you know what?

Coding in the wrong direction is a waste of time. Writing code that makes customers’ lives harder is even worse. That’s why I’m presenting the material in this order.

We’ve talked about the importance of understanding your security policy. We’ve talked about why it’s a good idea to understand your industry’s legal environment. In this post, we’re going to expose you to the awesomeness you can achieve by adhering to your security architecture.

What Is This Architecture You Speak of?

Sure, it's famous -- but its foundation is terrible and it's useless! Don't be like this tower!
Sure, it’s famous — but its foundation is terrible and it’s useless! Don’t be like this tower!

As an application developer, no doubt your designer or (if you’re the designer) your architect has introduced you to your company’s application architecture. In the commercial space, you might be using something The Open Group Application Forum (TOGAF)’s architecture, which is robust and flexible. In the government space (with which I’ve had considerably less experience), you might use the Federal Enterprise Architecture. Or you might have rolled your own. In any case, if the platform, system, or applications you develop have any complexity, then as a developer, you know the benefits of an application architecture:

  1. More clear communication within the development teams, and more clear communication between development and business teams, because the vocabulary is clearly defined
  2. More time spent on development, since high-level decisions that underlie designs have already been made and vetted
  3. Better coordination between development teams, since the high-level decisions are already made and everyone’s playing from the same sheet of music
  4. Shorter time to market, since you can focus more on development and less on fixing misunderstandings, re-developing misunderstood requirements, and fixing interfaces that don’t work together because of false assumptions

If you’re a veteran developer, you likely don’t even think about this kind of thing anymore: it’s second nature, stored in your personal ROM, and is an expected part of the landscape. If you’re a new developer, it’s a good idea to begin build this understanding. Make sure your team understands the need for an architecture, or at least makes an informed decision not to use one. Don’t default to unprepared! If you must be unprepared, boldly be unprepared!

What if you’re in a competitive market and you don’t have an application architecture?

If that’s the case, I hope you have time to make the case for an architecture before your competitors overtakes you and consume your lunch. Unless, of course, they also don’t have an architecture. In which case it’s a race for who can provide the least terrible solutions.

Not a “pride of ownership” kind of scenario…

Security Architecture Is a Thing?

Security Architecture: Protecting you from miscommunications, one security principle at a time!
Security Architecture: Protecting you from miscommunications, one security principle at a time!

An application architecture establishes a common vocabulary between the business and technical teams to talk about applications. It also defines how systems work (preference of REST over SOAP; text-based protocols instead of binary protocols for intra-application communications; a preference for open source libraries over closed source, etc.). A security architecture does the same thing for security. And like the application architecture, a security architecture has benefits:

  1. More clear communication within development teams, and more clear communication between development and business teams, because the vocabulary is clearly defined (sound familiar?)
  2. More time spent on development, since high-level decisions that underlie designs have already been made and vetted (like authentication/authorization mechanisms or audit/logging mechanisms)
  3. Better coordination between development teams, since the high-level decisions are already made and everyone’s playing from the same sheet of music (team A doesn’t use OpenLDAP, while team B doesn’t use Active Directory and team C doesn’t write their own super secret and amazing identity provider — which they’d then have to spend time supporting instead of writing functionality for the customer)
  4. Shorter time to market, since you can focus more on development and less on fixing misunderstandings, re-developing misunderstood requirements, and fixing interfaces that don’t work together because of false assumptions

Yep! Same benefits as the application architecture, but in the security space.

But there’s a huge difference that might be invisible to you as an application developer. Whereas the application architecture does touch on the business, it still focuses mostly on the technology. The security architecture cuts across all aspects of an organization, from HR to Finance to IT. That’s because a failure in any one are could start a chain reaction that compromises your data.

And makes your customers get all frowny-faced, which is not how you want your customers to be.

Because then they won’t give you their money.

It’s a trust thing.

Examples, Please!

Want to smile like this developer? Partner with your security architect. The alternative is too frightening to comprehend! (Is it just me, or is this model everywhere?)
Want to smile like this developer? Partner with your security architect. The alternative is too frightening to comprehend! (Is it just me, or is this model everywhere?)

Architectures can seem like abstract things. Abstract things can be hard to get a handle on. Fortunately, there are a couple of great security architecture examples that can help.

The first is the Open Security Architecture. This is an open sourced approach to building a security architecture. A good starting point on that site is its Open Security Architecture (OSA) Landscape page. It lays out the areas of concern for the OSA, which are:

  1. Governance (a topic too often ignored by otherwise smart organizations)
  2. IT Service Security Patterns
  3. IT Application Level Patterns
  4. IT Infrastructure Patterns
  5. (Central) Security Services

The reason I recommend starting here is that while it’s a little light on philosophy, it’s strong on patterns, which are articulations of architecture. They have a large security pattern library (called the Pattern Landscape) that you can begin to implement right away. Each individual pattern implements specific security controls, like “AC-03 Access Enforcement,” which ties directly back to the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 rev 4. We discussed in the previous post.

Isn’t it cool how all of this works together?

Once you get your bearings with the OSA, try checking out something more substantial: the Cloud Security Alliance’s security reference architecture. This security architecture is the real deal. It provides four distinct domains of vocabulary and security principles that apply across the entire organization:

  1. A business-centric view based on SABSA so you can converse with and provide security guidance for the business (isn’t fulfilling business objectives the whole point of your application?)
  2. An Information Technology Infrastructure Library (ITIL) perspective to focus on the IT operations team (your apps have to run somewhere, right?)
  3. A TOGAF perspective to drive security adoption within the application teams (yea! stuff you can use every day!)
  4. A Jericho Forum perspective to fully address the security domain concerns (it’s stuffy, and it’s security, but it won’t bite…)

Of course, as an application developer, you’ll want to focus on the TOGAF perspective.

But I’m Not an Architect!

20161006-figure04-fixedNot every developer needs to be an architect. That’s cool! But if you want to be more than “just” a developer — if you want to realize your potential as a developer — you should understand how the pieces upstream from you fit together. For one thing, understanding the whole process will give you insights into your own company’s development lifecycle, and the better you understand that, the more precisely you can focus your work.

It’ll also help you not freak out when some security professional, all atwitter because your code has violated a security principle that increases the risk of the application violating a security principle and potentially running your company afoul of regulatory bodies — or customer expectations — begs you to fix your code.

But most of all? It’ll help you be a more robust developer. I have no complaint about someone who wants to sit and crank out code, day after day, year after year. However, the best application designers I’ve ever met, the best application architects I’ve ever met — even the best security architects I’ve ever met — all started as developers who understood the big picture.

There’s no substitute for understanding how things work.

The world doesn’t necessarily need more big picture people.

But it does need more big picture people — who actually understand the big picture!

by Terrance A. Crow

Terrance has been writing professionally since the late 1990s — yes, he’s been writing since the last century! Though he started writing about programming techniques and security for Lotus Notes Domino, he went on to write about Microsoft technologies like SQL Server, ActiveX Data Objects, and C#. He now focuses on application security for professional developers because… Well, you’ve watched the news. You know why! 

terrance
Terrance A. Crow is the Manager of Global Security at a global library services company. He holds a CISSP and has been writing applications since the days of dBASE III and Lotus 1-2-3 2.01.
https://www.interstell.com

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.