It was my second year of university when I realised that I wanted to work in security, I just loved the problem space, the challenge of finding bugs and working out how to exploit them. My first job after university was working for the government helping to find bugs in software that was being built to support the military. This involved reviewing cryptographic implementations, system code etc. It was fun and I learned a lot about working in a consultant role with engineers and topics such as cryptography, networks and systems design. In the following years I worked as a security engineer, a senior security engineer, architect and senior architect. Now I lead a team of senior architects and other amazing professionals.
I consider myself a security architect — it’s a title that a lot of people in industry seem to be adopting at the moment. One of my LinkedIn Mentees has recently decided to call himself an “architect” with just two years experience. I’m not sure that’s a good thing, I think title inflation can be dangerous. Certainly I’ve met a lot of self-described “security architects” who wouldn’t hold a candle to the men and women on my team. In this article I discuss the qualities I personally feel make someone a great security architect.
Generally speaking a security architect is someone in the IT security hierarchy who is more senior than an engineer but less so than the Chief Technology Officer (CTO) or Chief Information Security Officer (CISO). Depending on the organisation, there may be different levels of engineers and architects. For the purposes of this discussion. I’ve drawn a generic career ladder / org structure that we can use to discuss the different security roles out there.
I accept there are lots of roles missing from this generic diagram, perhaps even entire career streams; but it should be generic enough for this discussion. Most of the time, a security architect is near the top of the technical tree. There are only a few of us. We are supported by a cast of security engineers, specialists and analysts.
Security architects should be able to set, and alter the course of an organisations security journey. I expect architects to be able to look at processes such as DevOps with it’s collapsed separation of duties and rapid deployments-to-production process; and work out how we build new policy, guidance and audit processes that enable the business to meet all of it’s security requirements. Then, security engineers can create useful tools, services and crucially automation to support the business mission.
I’m a strong believer that security has to include a code delivery component. For me that means working with security engineers to get things built that make life easier for our developer communities. I’m convinced that the best way to achieve security assurance is to secure the path of least resistance for developers. Architects should understand the needs of the business and developers, and work out ways for both to succeed.
In my time I’ve met a lot of people who call themselves security architects but not many who I would recommend for our team. The title of security architect can be very flexible. I’m sure there are exceptions but I think it’s unlikely that you’ll be a successful architect if you haven’t come up through some security engineering role first, the basics are just too broad.
What a Security Architect isn’t
- Someone who was previously an “architect” responsible for building systems and services who is now in a security role.
- Someone who’s really good at plumbing existing security products together in order to build “solutions” for customers
- Someone who works primarily in the medium of Visio
- A project manager
Qualities every Security Architect should have
I don’t expect Security Architects to be experts in any of these areas but they need to have a very good working knowledge of all these topics. I have built up a list of some 50 interview questions that we use to assess Security Architect candidates. Most are open-ended like “Describe how TLS protects the connection between a browser and a server”. This is a question almost anyone can answer to some degree. It allows me to dig deeper and look for depth on networking and cryptography.
My interview questions fall into a number of categories that an architect needs to understand. I’ve explained some of the most important ones here.
Genuine Interest:
You wouldn’t believe how many candidates fail to answer questions that demonstrate they take an interest in the industry: “Tell me about something that happened recently in the information security world that you found interesting” — it’s not a trick question, I just want to know that candidates are engaged with the industry.
Business Awareness:
A Security Architect should understand a lot about the business they’re trying to secure. They should have a working knowledge of cloud technologies, understand who the big players are, and the differences between their offerings. A good candidate looking for a role in my team will be able to describe what the security concerns and impact might be for an organisation looking to move from on-premises compute to public cloud. An excellent candidate will be able to explain how some clouds can improve the security of a number of different types of applications, depending on where they fit in the shared responsibility model.
Basic Cryptography:
Cryptography is the foundation of a significant number of security controls. Cryptography helps us to protect both the confidentiality and integrity of data in many ways. A good candidate will be able to explain the symmetric and asymmetric parts of a TLS handshake, and explain the difference between signing and hashing. An impressive candidate is able to explain the difference between stream and block implementations, and convey an understanding of code books and authenticated encryption.
Distributed Systems / Software Design:
Architects cannot work in ivory towers of academic correctness. We need to understand the compromises that teams make every day, in order to make things work. Security Architects should have strong opinions about the right way to build systems. Understanding common patterns for data ingestion, distribution, etc. is also very important. Good candidates can explain how we might implement distributed identity patterns, or how we trade consistency for availability in the light of network issues.
Threats, Risks, and Modelling Both:
Security Architects need to use the same terms as customers. For example, architects should be able to explain the difference between threats and risks. I look for architects who can understand what organizations need to protect, who they need to protect it from, and how that protection should work. Bonus points if the architect can walk through threat classification frameworks like STRIDE or risk assessment models such as DREAD.
Vulnerabilities and Exploitation:
A good architect should relish the opportunity to take an afternoon off to play on some wargame or Capture the Flag (CTF) servers — I still do it from time to time. The reason is because we have to stay close to the basics. The day job may well involve more Powerpoint than C but when Spectre rolls around or Heartbleed rears its head, we have to be able to read the PoC’s and interpret the academic papers to understand how our organisation is affected. I expect architects to be able to describe basic buffer overflows, what one might look like, what happens to the stack and common protections. From there, we might talk about more low-level exploitation stuff like ROP or heap spraying. If the candidate is struggling, we’ll walk up the stack to talk about OS level exploitation and then web applications. A very good candidate will be able to explain the OWASP top 10 and what the common methods of mitigation are.
Focussed on Collaboration:
Think, would I want to work with this person every day? I learned a great piece of wisdom as an undergraduate, when the wonderful Clive King of Sun Microsystems (now Oracle) presented to my class at university. Clive showed how being personable, approachable, and empathetic are extremely valuable qualities in a Security Architect. The Security Architect role requires lots of cooperation and engagement within the security organisation and the business they’re supporting. Unfortunately, I’ve met too many Security Architects who have gotten used to bossing teams around and generally developing a superiority complex.
Should you be a Security Architect?
If you’re interested in learning new things, sympathetic to the needs of developers and passionate about security then, yes, you probably should consider becoming an IT Security Architect. It takes time to develop the experience required, the areas of interest I’ve called out above are really just a sampling of what’s required.
Every architect on our team is different. Some are crypto-wizards but struggle with massively distributed systems. Some are ninjas at low level exploitation, but hate talking about identity systems. However, thanks to our technical breadth and willingness to engage in difficult problems; all of us are security generalists, eager to understand new concepts.
Does that sound like you? We need more Security Architects!
