Home Blog Talks Open Source Cloud Security Resources
← All posts

Breaking Into Cloud Security

Cloud security is an area of the industry with some of the biggest skill shortages. Combine that with the cloud industry growing at 30-40% a year (judging by AWS’ revenues for the last several years), and to my mind, there’s no better area of security to be getting into right now. There’s a reason for that skills shortage, though - being effective requires more than just technical skills. This post will lay out some advice and direction on how to build the knowledge and approaches you’ll need to succeed.

General advice

Before we dive into the specifics of cloud security, it’s worth talking about a few high-level topics that are often ignored.

People Skills > Technical Skills

A controversial headline item, I’m sure, but it’s broadly true. “Soft skills” are frequently neglected in this industry. A person with average technical skills and great people skills will usually go further than a grouchy loner with fantastic technical skills. Being able to engage successfully with the rest of their business and work collaboratively hugely increases your value as a security professional.

Issues that I’ve seen cripple the careers of otherwise very capable technical security experts include:

  • Poorly written communication
  • Poor time management and project planning
    • You don’t need to be a certified scrum master, but if you can’t manage your workload (and communicate it to your boss and teammates!) then you won’t be effective
  • An inability to compromise and negotiate
  • A problematic level of ego and arrogance
    • You stand to learn something from everyone, and you should never assume you know more than someone
    • Assume people are making the best decisions they can with their knowledge in their circumstances
    • Seek to understand why something is the way it is before trying to fix it

The Basic Tech Skills Still Matter

There’s a lot of gatekeeping in security, and a lot of people who believe that you can’t succeed in security without prior experience in software development, DevOps/SRE, or sysadmin roles. I disagree, and I think that we all benefit from bringing in a diverse range of backgrounds. That said, if you’re coming in without a background in tech, you’ll be at a disadvantage without knowing:

  • The basics of networking
  • Enough of a programming language of your choice to do some basic scripting and automation.
    • If you’re not sure where to start, then Python is accessible and widely used.
  • How the software development lifecycle works at a high level, and where different security activities should fit within that.

Security Doesn’t Exist In A Vacuum

Security is, fundamentally, a cost centre and support function. Security work does not generate value. Even if you’re a security consultant where you’re the core product of your company, you are a cost for the clients who pay your bills. You’ll go furthest when you work to support the business in reducing risk, and that means being empathetic and understanding the business you’re in. You’ll notice I specifically say “reduce risk” and not “improve security”. A business cares about risks to its bottom line, of which security is one.

Kelly Shortridge does a great job of cutting through the security industry BS to the heart of building effective resilience in a business:

The first in particular is well worth a read, and highlights most of the mistakes people make trying to build security in an organisation.

Keeping Up to Date

Half the battle with cloud security is keeping up to date with it all. This journey is a marathon, not a sprint, and it’s important to settle in for the long haul else your skills will atrophy and drop in value. I’d recommend taking a look over all the resources I list on my cloud security resources page, as there are a lot of great options for this.

Building Your Technical Skills

There’s a clear base of skills to build as a starting point, regardless of which specific security function you wish to end up in.

Step Zero - Understand The Engineering Before The Security

Working in a mature, DevOps-driven organisation is a different game from legacy environments. Security in the cloud is about working with engineers to support them, not playing gatekeeper. It’s no surprise that many of the most well-respected people in cloud security are ex-engineers, rather than penetration testers, red teamers, SOC/detection people, etc.

Before you touch cloud security, you need to understand why cloud adoption has skyrocketed, and why organizations are making the process and technology changes they have alongside it. Fundamentally, cloud adoption is largely a symptom of organizations embracing the DevOps engineering paradigms. As such, getting your head around that is, to me, step zero on anyone’s cloud security journey.

I’d strongly recommend that if you’ve no prior software or infrastructure engineering experience, you look for opportunities to get some as early in your journey as possible. Internal temporary secondments work great for this if the opportunity is there. If not, I’d look at contributing to established open source projects, or finding some experienced engineers to start one with.

A month or two of the right experience here can jumpstart you a couple of years ahead into your career, as this will always trump theoretical book learning. It’ll also help you develop empathy for the engineers, you’ll be able to understand their challenges better, and see things from their perspective.

The Phoenix Project

The Phoenix Project is considered mandatory reading for all the cloud specialists I work with, and I’d read this before you go any further. It’s a short novel about a fictional IT organization in a fictional business, and was the book that popularised the DevOps movement. Understanding the underlying mindset shift will do wonders for your ability to work effectively with engineers. If you want to get more into the hows, or want to take a leading role, then its companion piece The DevOps Handbook is also worth a look.

Step One - Cloud Fundamentals

You need to understand the technology to be an effective cloud security practitioner. I’d recommend picking one provider to start with, at least until you’ve got your head around the fundamentals. Any of the major providers are big enough for there to be a lot to learn, and they all do things differently. You’ll need to have a good grasp of at least the following for your platform of choice:

  • Identity and Access Management - IAM in AWS, RBAC and Azure AD in Azure, Cloud IAM in Google Cloud
  • Compute - virtual machines, containerised deployment offerings, serverless functions
  • Networking - VPCs/VNets, subnetting, routing, security groups, VPC endpoints, and their equivalents
  • Databases - the core database offerings from your provider, such as RDS and DynamoDB

Some good resources as starting points:

It’s also a good idea to spend some time building things in the cloud before you try and start securing them. The Cloud Resume Challenge is a great option for this.

Other Core Technical Skills

Beyond the core cloud topics, you’ll also want at least a passing familiarity with the following types of systems:

  • Source Code Management - Github/Gitlab etc
  • Continuous Integration and Delivery (CI/CD) - Jenkins, Gitlab CI, CircleCI etc
  • Infrastructure as Code - Terraform, Cloudformation, Pulumi, AzureRM etc
  • Containerization - Primarily the basics of what containers are, why they’re useful, and how they operate. Kubernetes is important, but a whole specialty of its own. I’d avoid that to start with, unless it’s something you need to learn or are already working with.

These are all commonly found as part of cloud engineering projects, and security of cloud environments frequently depends on the security of supporting systems.

The Well Architected Frameworks

As much as they’re not terribly interesting, the Well Architected Frameworks for each provider, or their equivalent, contain a wealth of information on how the providers think you should build stable, secure infrastructure on their platforms. They can be a little one-sided in how they view security, but they’re pretty essential reading nonetheless, because all the engineers will be reading them if nothing else.

A Note on Certifications

I’m not fond of the currently available security certifications. I believe they’re mostly too focused on doing security work with the tools the providers offer, and not on being secure in the cloud. The entry level architect/administrator exams, however, are a good way to demonstrate foundational knowledge. These are:

Step Two - Cloud Security Fundamentals

There’s a lot to unpack when it comes to cloud security. The following are some good reads to point you in the right direction:

It’s worth setting your own cloud estate up as part of your learning journey, then walk yourself through one of the security roadmaps:

You’ll want to get familiar with the MITRE ATT&CK Cloud Matrix, which is a good source of ideas for what an attacker is likely to try, either for you to emulate yourself or work out how to defend against.

Step Three - Specialising

Once you’ve got the fundamentals down there are a lot of routes to take from there in terms of specialisation. Some common directions to move in are:

  • Offensive Cloud Security - penetration testing, red/purple teaming and so on
  • Cloud Security Engineering - working to build security into an organization’s cloud environment
  • Cloud Security Monitoring and Attack Detection - monitoring cloud environments for malicious activity
  • Cloud Incident Response - incident response, forensics and so on in cloud environments
  • Cloud GRC - governance, compliance and risk management for the cloud platforms an organisation uses.

Of these, I can only really speak to the offensive and monitoring/attack detection with any authority, so that’s what I’ll cover in more detail below.

Offensive Security

Offensive security assessments (or penetration testing), red teaming and so on are the “sexy” end of the security industry, but the sad fact of life is that it’s generally both hard to get into and not the best paid field, due to the level of competition. It’s also very common to see pentesters who learned against on-premises networks and try to just apply all the same old stuff to cloud environments. Don’t be that person, and be wary of any training or resources that talk about common old-school pentesting tools or platforms like Metasploit or Kali Linux for the same reasons.

It’s always good to get some practice under your belt. I’ve seen the following CTFs and challenges used to build skills across the providers, though I can only speak to the quality of the AWS ones:

There’s also TerraGoat, a repository full of vulnerable Terraform code that’s designed for testing infrastructure as code static analysers.

Monitoring and Attack Detection

As with offensive security, it’s best to get your hands dirty rather than merely study the theoreticals. The MITRE ATT&CK Cloud Matrix will become your bread and butter, most organizations tie their detections back to this in some way. Some other useful resources to understand what you’re defending against include:

Unfortunately, there’s been less development of free training and guides in this space. I’ve outlined what I’m aware of below.

To Summarise

Cloud security’s a fantastic field to be working in, there’s a huge shortage of people and the demand is only increasing. It’s a good place to get in on the ground with something relatively new, and there’s a lot of room for novel research, development and innovation. Take the time to understand how people work with the cloud and fit your security efforts in around that, be an enabler rather than a blocker, and you’ll go a long way very quickly.

P.S A Note For Those With A Security Background

One of the most important things you can do is keep an open mind, if you’re coming from the on-premises security world. Trying to shoehorn legacy security approaches and techniques into the cloud world is one of the biggest mistakes I see people make. Much of your experience is relevant, but many of the old attitudes need to be left behind. If you don’t, the organization will leave you behind.

I’ve seen security people pick some questionable hills to die on when they first move into the cloud space, including:

  • Requiring penetration testing, manual code review or other human security work before go live. This is infeasible when an organisation is deploying multiple times a day, as many do now.
  • Insisting that every change with a security impact goes through the security team, turning simple config changes (like opening a port in a security group) from a 30 second job into a 3 week one.
  • Blocking developer access to “security logs” like Cloudtrail in AWS on the basis of separation of duties, which makes debugging (and thus developers’ lives) harder.

If you do things like this, the engineers will hate you, and the rest of the organisation will eventually just cut security out so they can hit their targets. Go to the engineers, work with them, hell, buy them a beer or non-alcoholic beverage every now and again to make some friends, and you’ll make your job much easier.