Security Architecture is Not A Checklist

• Read original article here

This is a continuation of my series of posts on Automating Cybersecurity Metrics.

In the last post I wrote about architecting a secure solution for automation with MFA.

Now I’m going to take a step back and look at the bigger picture — our security architecture for the cloud resources we want to deploy.

If you’ve been following along and reading my posts on implementing an AWS Batch job to help with cybersecurity metrics, you’ve probably noticed by now that I didn’t jump straight in to deploying a batch job using AWS Batch. I’m not even close to that yet.

I’m sorry if I disappointed anyone, but creating secure software starts with thinking through attacks and your security architecture, not on “working” code. That’s the difference between how many developers think compared to how most security professionals think. Some developers (not all) just want to make it work. Security professionals want to make sure on one can break it.

But sometimes developers have the upper hand because they get things done— and security professionals think on things forever. We need to balance out these two objectives, and that’s why I like an iterative approach like the one I’m using to write these blog posts. You can get things done while you’re thinking about it, test things out, and go back and revise it if needed. You’re always moving forward — but not too fast.

I could have just presented you a GitHub repo full of working code, but then you wouldn’t understand the path I took to get there. The path taken in this series is almost more than the finished product (and who knows if and when I will get there.)

If you just copy and paste my code, you are missing the point of why I’m writing it. I’m piecing together a solution based on the components and security controls available to me and showing how you can do the same. I’m pointing out the potential threats along the way and explaining my thought process.

In the end, though, hopefully we have a somewhat secure starting point for building batch jobs. I can’t and won’t promise it is foolproof or “secure” because nothing ever really is, but hopefully it’s better than just jumping in and deploying code from tutorials in production environments without considering the risks involved.

Think like an attacker

In my classes, I’m always trying to adjust how people think about security.

That was my objective since I started teaching my own classes in February 2019. I wrote about the concept in this blog post where I talked about what we should be trying to get out of cybersecurity training. Ironically, a friend of mine told me a few months after I wrote this that he was writing that same concept in his own classes. Is that the universal mind meld again?

Security is not only about how to use independent tools and tricks or checking off a list, but how to construct security processes and architectures that minimize the possibility of a successful attack. If you’re simply working off a checklist you pulled from an industry standard list, you’re not thinking about how all the things on your list work together. That’s not architecture. That’s compliance. If you think about how someone might attack a system, then you can construct defenses to defend against those attacks using layers of preventative and reactive controls.

Industry checklists are good, they just aren’t good enough

Am I saying you should not use checklists? No! Checklists will help you spot basic security problems and get them fixed quickly, if you choose to do so. Unfortunately, even with checklists of best practices, organizations are still not even fixing that minimal baseline. Items on checklists and in penetration test findings go unmitigated for far too long. They often sit there festering and taking up time for people to review over and over again.

Sometimes companies only fix the high-risk items. I warn customers in penetration tests not to only focus on the high-risk findings. Sometimes lower risk findings can be chained together to form an attack. I try to demonstrate these things when I can find them but a penetration test is only a few weeks and attackers have years to try to discover attacks.

Sometimes I see the same problems manifesting themselves in different places throughout an organization or popping up year after year in different places. I always try to provide recommendations that help organizations holistically resolve a security finding across an organization — not just that one finding.

Although I think checklists are highly beneficial you still have to understand where items on the checklist apply and do not apply and adjust your list accordingly. For example, the Azure Security Baseline wants you to buy every expensive Azure security product available to remove all findings in that list. You might have alternate solutions for securing your Azure account, in which case you should adjust the underlying list and findings that appear in Microsoft Defender for Cloud tools. You should add your own items to the list to ensure your cloud environment is compliant with whatever security configurations you chose to implement as an alternative.

I also have written and presented about the fact that although a software and hardware inventory is very helpful, those things do not stop data breaches. Fixing known CVEs does. Maybe the priorities are a bit out of order in terms of where we focus our efforts with certain checklists. Consider your priorities and adjust your list accordingly.

As I’ve mentioned before the 20 items in my book are things aimed at stopping and mitigating data breaches first and foremost. Although the list is simple at the highest level, I drill down into considerations in the chapter related to each item that demonstrate to readers that the high level question has a lot of nuances and details to consideration when architecting a solution. The high level list is a checklist but I suggest measuring in percentages as usually the answer is not binary for a single organization. The architectural considerations are in the details.

Architecture is more than a generic checklist

If you want to write secure code or crate secure cloud architectures, you can’t just rely on a generic checklist. As you go through my blog posts and process for architecting and creating a solution, you’ll noticed that I’m constantly thinking about threat modeling along the way. I’m considering the implications of each choice I make and how an attacker might abuse it. I design my solution in such a way to try to make it harder to infiltrate systems and steal data or abuse privileges in some way.

I’m not just using independent controls. I’m thinking about how the controls work together such as how my user policy works with the IAM role. The policy needs to allow role assumption, but only the correct roles. But I don’t want to have to update that policy each time I create a new batch job. There’s a trade-off between security and and efficiency of future development and deployments that needs to come into consideration.

I’m also thinking about costs. Security controls have a cost that is often overlooked until system architecture is complete. I’m thinking about the cost of the security controls, the logs, and the cost of the architecture itself. I mentioned that using batch jobs on AWS can save money and to consider the cost of KMS for high-volume users. All of these things are part of the thought process involved in designing secure system architectures.

Although an industry standard checklist might not be good enough, you can create custom checklists for your applications and configurations that include the architectural details and the choices you have made. You can measure your system compliance to these more detailed checklists that are system-specific. Ideally, you can automate those checks. That way you will understand if the security architecture you have designed has been altered in some undesirable way.

Start with the checklists. Clear them off. Resolve the findings. Tune the reporting engine to only show you what matters. Find holistic solutions to prevent recurring findings.

When you’re building new systems, architect them with security in mind — up front. Perform threat modeling. Think about attacks, and design systems to defend against them. Get a security assessment, penetration test, or architecture review to validate your design and find vulnerabilities or gaps you might have missed.

Create custom checklists to monitor your security architecture and configurations. Once you have determined what your architecture should be and the critical controls, you can derive custom, detailed checklists to monitor that your architecture and configuration does not change in such a way that it undermines the integrity of the system.

If you liked this story ~ clap, follow, tip, buy me a coffee, or hire me :)

All the posts in this series:

Cybersecurity for Executives in the Age of Cloud on Amazon

Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.

Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts