5 Steps to Building Your First Security Architecture

Imagine you’ve been asked to lead security at a company that doesn’t have a strong program in place or wants to significantly upgrade their existing one — either because they suspect it might not be effective, or because a recent cyberattack has proven that to be the case. You’ve obviously got a daunting task ahead, so how do you go about it, and more importantly, where do you even start?

If you work at a startup or growth stage company, chances are you’ve either encountered this scenario in the past, are in this type of situation right now, or will face it in the near future. Maybe you’re a founder or senior employee who has volunteered (or been voluntold) to lead cybersecurity, or you’re an experienced security leader hired to build out the new security program.

I’ve been in this position multiple times and now advise CEOs, CTOs, CISOs and other security leaders on the most effective ways to build out their internal security architecture. While every company and situation is different, there are some approaches that work better than others. 

I’d like to share these approaches and highlight some of the common pitfalls to help kickstart your cybersecurity journey. With that in mind, here’s a step-by-step framework that can act as a guide for starting, or improving, your cybersecurity infrastructure.

Step 1: Map Out Your Current Systems

The first step of any complex task is fact-finding, so before you start building anything, you’ll want to have detailed knowledge of your assets, data, users and devices. You’ll also need to understand what systems, processes and policies are already in place to help reduce cybersecurity risk.

If you’ve been with the company for a while, you’re probably familiar with the architecture — maybe you even built it yourself. Documenting might not seem super valuable, but getting the knowledge out of your head serves two important purposes:

1. It makes it easier for others to understand the current state, which will help them contribute to the threat model and understand the priorities.
2. It highlights gaps and blind spots that naturally develop over time when you spend every day working on the same platform. 

If you’re new to the company, you’ll want to spend your first few weeks meeting your colleagues and doing technical discovery. The key is to effectively balance two critical and sometimes conflicting goals:

1. Your top priority is earning your colleagues’ trust. That means ensuring that they perceive you as not only a smart and knowledgeable technical resource, but also a reliable ally whose long-term goals and values align with theirs.
2. Your other priority is to gather accurate information about the current architecture — the good, the bad, and the ugly — to understand the current state and prioritize improvements where needed.

The key to success is to be clear and transparent about your intentions: you’re not there to judge, cause problems or lay blame for past failures; you’re simply there to find out what has been built and why in order to help the organization.

If you’re exploring a dark corner and run into a brick wall, resist the temptation to bring out your sledgehammer, and instead make a note to come back and investigate later on when you have better tools at your disposal.

Most important of all, ask lots of “silly” questions. Being new to the security role (or even to the organization) gives you the right to ask things without colleagues wondering why you don’t already know the answer. And once you start asking these questions, you’ll be shocked how often no one else knows the answer either.

Step 2: Create a Threat Model

You’re already very familiar with threat modeling, though you might not realize it.

When you leave home for a long trip, you check that the front door is locked, the windows are closed and the stove is off. You double and triple-check that you have your purse or wallet, your keys, phone, luggage and medications. You do all of this because your personal threat model includes the risk of someone breaking into your home, the stove being left on and starting a fire, and you showing up to your destination missing a critical item that you need.

Conceptually, cybersecurity threat modeling is not that different. Your goal is to identify attack scenarios, estimate the likelihood and impact of each one, examine what mitigations are already in place, and use that to prioritize improvements.

While there are many technical threat-modeling frameworks available, I recommend starting simple and just enumerating the attack vectors and the probability and impact of each one on a high/medium/low scale. This naturally leads to great discussions where others can challenge your assessment and contribute their insights.

For example, you might estimate that a ransomware attack has a high probability of causing a medium amount of damage, but the CTO might suggest downgrading the impact due to backup software that you weren’t aware of, while an infrastructure leader could point out the fact that the backups are not properly isolated and would likely be infected as well. This type of information might not explicitly be part of the systems architecture, but is obviously critical for you to understand.

Keep in mind that threat models are naturally imperfect, subjective, contextual and temporal. For instance, your thought process when a stranger walks by wearing a face mask is likely different than it would have been a few years ago, and it might also be very different from the stranger’s thought process when they see you. Don’t over-engineer the threat model or assume it will automatically lead you to the right answer, and don’t be afraid to update it as circumstances change.

Step 3: Document and Prioritize Opportunities

The process of mapping out the architecture and building the threat model usually highlights a lot of opportunities for improvement. Some will be extremely simple and easy to implement, while others might take months or even years and require a lot of resources. Start tracking them all in a backlog and share it with your team and other stakeholders to make sure you haven’t missed any great ideas.

Next, take each opportunity you’ve identified and estimate the value that you think it would deliver and the effort that it would take to implement. Don’t overthink this step either — simple high/medium/low t-shirt sizing is often just as effective as the plethora of systems that use complex formulas to create objective-looking scores. Highlight the obvious ones where the value heavily outweighs the effort.

You can then place the opportunities into broad “buckets” (e.g. short, medium and long term), but I recommend going one step further and stack-ranking the individual ideas. This creates a great forcing function to discuss business trade-offs and dependencies. Is it more valuable for us to start managing endpoints or to improve our employee background checks? Do we need to put in place a vendor evaluation process, or should we use the time to build formal policies for incident response? Don’t worry about making the wrong decisions — you can always revisit later — but use this as a chance to get everyone aligned on the key priorities.

Step 4: Identify and Implement Quick Wins

While you’ll probably discover a few high-value, low-effort no-brainers, most of the opportunities will have a strong correlation between effort and value. So do you start with the highest value items even if they’ll take a while to implement, or do you go with the simpler ones that might not be as impactful?

My advice is to always start simple. Look for things that can be implemented quickly, are highly visible within the organization, and improve your colleagues’ quality of life (or at least don’t cause more hassle for them). For instance, when I started at Georgian three years ago, I prioritized two main projects:

1. Deploying a new spam filtering solution. One of the first things I noticed when I joined was the enormous amount of email spam we got, and users were frustrated because it was directly impacting their productivity. The legacy filters sometimes caught more legitimate email than actual spam, so I quickly worked with a trusted vendor to deploy a new solution that got the problem under control.
2. Doing a two-hour security training session for current employees. This wasn’t a typical “don’t open unknown attachments” lecture, but rather an open discussion on security fundamentals, cryptography, and the types of cybersecurity companies that we should and should not be looking to invest in. Nearly every employee attended and engaged in the conversation, and it helped me learn more about the people I would be working with and how they think about security.

I’m not suggesting these are necessarily the right projects for your environment, but hopefully it gives you a sense of the types of engagements to look for early on. Once again, your main goal at this point is to earn your colleagues’ trust, because that will ultimately determine whether you spend the rest of your time paddling downriver or fighting against the current.

Step 5: Build a Long-Term Roadmap

Once you’ve gotten a few wins under your belt, settled into the role and built some confidence, it’s time to start thinking long-term.

Go back to your list of priorities and look for the most valuable projects — those that will dramatically increase customer trust, improve user efficiency and/or reduce business risk. This could be practically anything depending on your business, including completing a SOC 2 audit, creating a Data Loss Prevention program, implementing a secure Software Development Lifecycle, or even building an internal Security Operations Center.

Scope out a few ideas and present them to your executive team, clearly outlining the business objectives, key results, expected value and resourcing needs (time, money and people). Be sure to build in buffers for project delays, unexpected costs, vacation and administrative tasks. Don’t make the classic error of budgeting 40 hours per week for each employee and then wondering why the project is constantly behind schedule.

Where possible, explain the different options, trade-offs, recommendations and reasoning, especially if you feel strongly about one or more of them. For example, my team was once asked to complete a major systems migration in a matter of weeks to support a key marketing initiative. We presented four options to senior leadership, three of which would have delivered the project on time but led to either a terrible user experience or architectural challenges down the road. With the marketing team’s support, we were able to get executive signoff to delay the initiative in order to complete the right design and ensure a seamless migration, which in retrospect was absolutely the right long-term decision.

Last, but definitely not least, understand that certain projects can take months or even years to fully execute. Don’t be afraid to take these on, but be sure to build in checkpoints and interim releases to show progress. For instance, our internal IT organization is nearing the end of a multi-year transition from a large set of disparate username and password systems to a fully passwordless infrastructure managed through single sign-on. Doing this all at once would have been extremely risky, but we were able to first deploy MFA, then SSO, then transition to a different SSO provider due to technical limitations, and then finally go passwordless. Each step improved either the security or user experience and got us one step closer to our end goal.

Next Step: Scaling With Your Business

I hope you found this short guide on building security architecture helpful and practical. While there are many viable approaches, the techniques above have worked for me and those I’ve worked with over the past decade and a half. I’d love your feedback on the ideas, their limitations, and most important of all what has and hasn’t worked for you in the past. Feel free to share and comment on social media to help others benefit from your experience as well.
As your business continues to grow, your next challenge will be to efficiently and effectively scale your security program to support the growth stage, late stage and eventually even an acquisition or IPO. Leading security at a multi-billion dollar unicorn or public company requires you to effectively benchmark your program, project growth, build your team and most importantly, generate and measure the value you’re delivering to the business.

We’ll tackle these topics in the next few months and then start exploring how emerging technologies like artificial intelligence, the Internet of Things, private blockchains and even quantum computing will impact the long-term future of cybersecurity.