Foundations of Good Security in Cloud

Introduction

As mentioned in the first blog in this series, I had the great pleasure of being involved in a security panel webinar on cloud security and governance lessons learned recently.  This webinar is available on YouTube if you missed it and the discussion inspired me to dig a little deeper into some of those topics.

This blog will focus on our discussion on the foundations of good security in the cloud and will be followed by the final part on common pitfalls.

Starting Right

In this section we will look at some key ideas to use that will help set good security foundations for your organisation in the cloud.  Unfortunately, as with all powerful tools, it is possible to misuse the cloud and to forget to implement good security foundations from the start.  Cloud offers us unparalleled flexibility and access to tools we only dreamt of when we managed on-premises.  Many organisations however start operating with the cloud without good security foundations and often have to implement these later, which can be disruptive.

Design Patterns - You don’t need to start from scratch and the majority of things you want to do have already been done by someone else.  There are a wealth of design patterns and associated reference architectures from trusted sources such as AWS, NCSC, and SANS.  Many of these are backed with deployable templates containing all the key components, including security.  These can include preventative, detective and response tools such as account guardrails with service control policies, threat detection, overall security management, alerting and automated responses.

Know Your Assets - You can’t know it’s secure if you don’t know it exists.  Cloud gives the ability to create, manage and delete assets quickly and easily so the only way to know about them is through automated detection.  Utilise tools such as AWS Config and Security Hub deployed through central organisation management to find assets and evaluate their security posture against your policies and standards (AWS best practice, CIS, PCI, DSS, etc.)

Data, Data, Data - Use data on your security to measure progress and know your security posture, risk profile and threat landscape.  The pace with which our digital environment changes is faster than human processes can keep up with. New vulnerabilities are discovered every day, new services to help us become available every week and our business evolves hourly.  Only data can tell you where your organisation is, in respect of security and as a wise peer once said “keep digging until you find the data that proves it, rather than saying everything looks fine”.  Then share that data with the people who need it and can action it in the way you need them to.  For example, if it is software vulnerabilities then get the summary volumes and risks to the product owners to drive correct prioritisation of the change and the details to developers to fix the problem efficiently.  A key aspect is to act frequently on that data because if you take 1 month to get approval to change you are already 2 months behind from when the issue was identified.

Fix the Right Thing - We all wish we could fix every vulnerability as soon as it emerged but that is not the world we live in.  However, using the data from threat landscape, risk appetite, assets (and their security posture) and resource availability we can prioritise and then we can fix the most appropriate things in their order of priority.

Architect for Failure - Sounds strange but accepting that the things we do will fail is a reality we must accept.  We are not omniscient nor can we tell the future and even then we are only human and as such we make mistakes.  Architecting for failure doesn’t mean architecting to fail, it simply means that we understand what will happen when it fails, and in security terms that it fails in a secure manner.  Think about the failure scenarios and how the systems in your organisation will behave when that happens.  We see evidence of this in business continuity and disaster recovery planning but we need to exercise these things and gather data that it works.

Keep Up the Good Work

So now that we have our foundations in place we need to make sure we keep moving forward in terms of security.  Unfortunately that can often be easier said than done because we still see period focus on security as a result of events such as new product release, new compliance regime to be addressed or unfortunately as the result of breach or near miss.

There are some good practices that can help us build on the solid security foundations, such as:

Bake It In - Security cannot be something added to other processes, it must be an integral part of them.  From product/service planning, through workload management, testing and, release processes it must be about how this is secure throughout the process.  Many have heard me say “secure the process not the product”, our products/services are what we create day after day and can change in months or hours.  The process is what produces each version of those products/services so if we get that right each version is secure.

Make it Easy to Do the Right Thing - People are generally dealing with competing priorities and a lack of resources.  If we make security difficult we increase the risk that it is not done.  Do the hard work and make the investment to make it easy to do security properly.  Make the security tools available for developers/engineers in their tools so the knowledge is available at the point of need.  Implement the security tools into the pipelines that evaluate other quality criteria and feed it directly back to the developer with the information on how to fix the issue.

Simple, Accessible Policies - Security policies that sit on digital shelves and are not used offer very limited value.  These should be clear and understandable to the audience that needs them and data should be gathered on whether they work or not.  If they don’t then dig into why and think about adjusting the format, language, and delivery mechanism to improve the issue.

Don’t Let the Backlog Build - Once a security backlog gets to a certain size it will likely never be addressed.  It will fall into the “too difficult” and “don’t know where to start” pile until a breach forces you to confront it.  The best approach is to allocate a suitable portion of your time, effort, or technology investment to address the backlog as part of on-going organisational behaviour.  Whether you incorporate security debt work into all technical debt work or have a separate budget you must gather the data to see that the budget is being used effectively. If the budget for addressing debt is not being used you need to dig into the data and find our why.  This could be too much emphasis on product owners to deliver new features resulting in them de-prioritising addressing debt, or technical staff wanting to work with newer technology and not fix old issues. Whatever the reason, it creates the conditions for an increasingly risky product or service and customers will migrate away from those when they are impacted.

Automation - It may seem strange to call this out in 2024 after many have been using automation for several years, I still see a lot of manual operations being performed. So much so that it has the title of “ClickOps”.  There is still an over reliance on manually performing certain tasks at certain times, often with the reasoning of “it’s quicker”.  From a security perspective “ClickOps” can be our Achilles heel because they can be hard to audit and unlikely to be easily repeatable and often error prone.  It also requires you to grant access to a person rather than a process which increases your attack surface.  Properly used automation has many benefits including: keeping people away from data, creating repeatable actions (usable across environments, as part of DR process and as part of scale up/out activities), and more easily auditable.

Conclusion

In conclusion, in combination with a good security culture (as discussed in the first part of this series), good security foundations help organisations leverage the power of the cloud.

Leadership plays a key part in empowering the organisation and the people within it to do the right thing from the outset and to continue to evolve and improve the security of the organisation.  I am often known to say “I have met very few people trying to do the wrong thing, they often do it because they are driven in the wrong direction or are not provided the knowledge and tools they need to do it right”.

If you’re looking for assistance with starting right, evolving to improve your cloud security or want some extra help to address that ever growing backlog then come and talk to us.

Useful Reading

• AWS Well-Architected Framework - Security Pillar: Clear guidance on security in the cloud with mechanisms to understand and evaluate your governance and culture throughout.
• NCSC Cloud security guidance: Detailed collection of information from UK National Cyber Security Centre designed to help the reader understand and securely use cloud. The principles give good low level detailed advice.