A Bear and Two Friends

We think about architecture in terms of its capacity to describe existing systems or its ability to induce runtime properties, but we often do not spend enough time thinking about its role in security. In a talk at the GIDS Architecture Live 2020 series, Brian Sletten makes a case for why Architectural Risk Assessment (ARA) is an organizational activity that should be done periodically. Read an excerpt below and watch the full talk on-demand for free.

This seems like a simple question. What is security? Everybody wants it, but it really depends who you ask. If you have an employee, they're going to say the system is secure if your employer does not have the ability to read your email, whereas the company is going to say it's secure if you do have the ability to read the employee's email, because you want to avoid secrets and data exfiltration activities flowing out just through normal channels.

Obviously, we need to come up with some sense of who's guidance lines and goals are we trying to protect, but that's part of why security is such a nebulous topic, is because we have a hard time even describing what its boundaries are.

One thing I want you to think about. The trustworthiness of a system is the whole sum of the trustworthiness of the pieces, the architecture, the runtime, the languages that you're using, the tools that you're depending upon, the people that are building the system and the physical access that is around the runtime process.

As you commit more and more of your resources to cloud based systems, keep in mind, there is no actual cloud. It's just somebody else's computer that you don't control, you don't have physical access to, so you really do have to have a high level of trust in the vendor that you're using.

But it's not just a question of using encryption. It's not just a question of developers patching the operating system. A lot goes into making a system secure, and so architecture is a nice way to attack the problem because architecture straddles business requirements and technical requirements and nonfunctional requirements. As an environment in which to have these discussions, security is a cross cutting concern across all of these things. This is a very useful way of considering it.

The problem is we can't spend none of our money and time on security and we can't spend all of our money and time on security, we've got to find a balance between what is good enough, and we just don't really have a way of even articulating that, so one thing that I think is useful for you to take away is the idea that you can't make something perfectly secure.

You can make it really annoying to try to get around the security. If you do that, if you make it harder and not worth their time, generally the attackers are going to go someplace else. They're going to try to find another organization that's going to give them access to computers for building denial of service attacks or other kinds of data theft or data breach or other kinds of privilege escalation.

This is how we can start to gauge a sense of what value does the system provide, and therefore we want to make it so that it's not worth attacking that system and they'll go someplace else.

There is a very famous joke that I like to say here. Two friends are camping in the forest and at night and they're woken by a noise and they come out of the tent and there's a bear there and they both go running off as fast as they can, running really far away, and the one friend says to the other “Run as fast as you can!” And the other friend thinks “I just have to run faster than you”, because if you run faster than him, then the bear will get him, not me. It's not very nice, I don't want to go camping with those people, but that's kind of what it's like with security.

As long as you are ahead of your competitors, ahead of peers in your industry, then you will be less likely to be a target. The question is: How do you know? I've got a fantastic resource at the end of this that I encourage you all to read. It's free and it will help you start to have this conversation with your organization, but also be able to know what is enough, or at least what's in the ballpark of being enough with respect to the amount of time and money that you spend on security.

Watch the full video on-demand, including all of the talks from GIDS.Architecture LIVE 2020, for free.

Like This? Register for our Newsletter to Continue the Converstion

See Highlights of

Hear What Attendees Say

PWC Logo

“Once again Wurreka has knocked it out of the park with interesting speakers, engaging content and challenging ideas. No jetlag fog at all, which counts for how interesting the whole thing was."

Cybersecurity Lead, PwC

Intuit Logo

“Very much looking forward to next year. I will be keeping my eye out for the date so I can make sure I lock it in my calendar"

Software Engineering Specialist, Intuit

Groupon Logo

“Best conference I have ever been to with lots of insights and information on next generation technologies and those that are the need of the hour."

Software Architect, GroupOn

Hear What Speakers & Sponsors Say

Scot Davis

“Happy to meet everyone who came from near and far. Glad to know you've discovered some great lessons here, and glad you joined us for all the discoveries great and small."

Scott Davis, Web Architect & Principal Engineer, ThoughtWorks


“What a buzz! The events have been instrumental in bringing the whole software community together. There has been something for everyone from developers to architects to business to vendors. Thanks everyone!"

Voltaire Yap, Global Events Manager, Oracle Corp.

Venkat Subramaniam

“Wonderful set of conferences, well organized, fantastic speakers, and an amazingly interactive set of audience. Thanks for having me at the events!"

Dr. Venkat Subramaniam, Founder - Agile Developer Inc.