Know Your Cloud to Defend Your Cloud, Part 1: Knowing

I recently had the opportunity to participate in a webinar with Scott Ward from Amazon Web Services and Arup Chakrabarti from PagerDuty, and much of our conversation centered on the objective that just about everyone is struggling with: going fast, securely.

So what’s the big deal? Is security really that important? Can’t I just bolt it on later and buy one of those “defender” tools to prevent bad things from happening?

Sure, but if you do, you’re missing a massive opportunity to:

  1. Drive security into the fabric of your product development lifecycle and processes
  2. Level up your product development teams to own, define, and execute on a cloud security strategy that supports your goals from the start
  3. Move fast with confidence and better adapt to ever-changing security requirements

Where do you start? The first step to forming a strategy to defend your cloud is to Know Your Cloud.

Know Your Cloud Assets

If you’re just getting started or you’re scaling in the cloud, implementing configuration management as the hub of your software-defined infrastructure is crucial. As you got started with your cloud infrastructure, you’ve likely been visiting your cloud service provider’s (CSP) console to spin up instances, but you quickly moved on. You have welcomed automation and configuration management into your life not just to make things repeatable, but also declarative.

It’s critical to use tools like Chef, Puppet, Ansible, Salt, etc., not just to define what software goes on your instances, but also to define critical properties such as:

  • The correct OS image (with up-to-date OS bits, right?)
  • Core configurations
  • Important metadata, such as setting proper ownership, applying the right tags (you’re using AWS tags, right?), and ensuring that only the necessary security groups get assigned

Additionally, CSPs like Amazon Web Services offer rich APIs for defining and launching non-compute resources (databases, queues, etc.), so don’t leave them out of the mix. You might not script their lifecycle as completely, but be sure to apply the same rigor to the naming, tagging, and application of security groups.

Those tools now create an internal process for your teams to use to get access to new assets and facilitate controlled processes for lifecycle management. You want to have the confidence that any new assets are created and destroyed using the process, so make those tools easy and accessible. In doing so, you have leveled up your ability to introduce security early in your lifecycle and weave it into your standard processes.

Know Your Workloads

Your workloads naturally have a web of dependencies to other components, services, and assets in your cloud environment. You can’t control the network in the cloud, but you can control your hosts and what they talk to — getting comfortable with redefining the network perimeter to the dependency graph of your workloads is a critical mindset change. You can’t just monitor network traffic at the edge; you also need visibility into what each host is talking to and the ability to shape your policies and control paths around those relationships.

One example is the additional libraries you’re using as part of your software development platform. How do you know what that ruby gem or npm module is talking to as it’s executing? Or how do you know that the database you’re sure is internal-only, is not accessible from the public internet?

Defining specific roles for your workloads helps to achieve deeper visibility. At Threat Stack, our architecture is composed of independent services that have specific roles that are matched to specific instance types and security groups. Since we have our rules laid out, we can easily and quickly scale up and change our environment with confidence. And we can quickly become alerted to workloads talking to things they shouldn’t.

Since you’ve built your processes for defining, provisioning, and configuring assets and software with configuration management, you can use that to get focus on user activities on your systems. If your process is that only the deploy user can lay down software bits on production machines, it becomes trivial to create visibility into situations where humans go around the process. The intentions may be good (we needed an emergency fix), but the outcomes may unintentionally put your workloads at risk (we accidentally left the management port open).

We’re All Moving Fast

Most companies have invested in continuous integration (CI) environments and are now moving to continuous deployments (CD). Coupled with platforms built from the ground up with service-oriented design, this gives your product development teams some core tools that allow them to deliver features, enhancements, and fixes faster than ever. However, traditional security tools have generally been built to defend the end product of your work, not to be embedded into your cloud infrastructure from the start.

If you’re just getting started with your engineering organization, or re-organizing, you’re likely starting from a place where traditional software development and operations roles are blown up and engineers of all disciplines are working together. Knowing your cloud doesn’t just mean having the tools: it also means ensuring that those advanced platforms can be built into the core processes that are driving your teams forward. The traditional operations role of on-call isn’t just for infrastructure engineers; it’s for your entire team. For security, by knowing your cloud from the start, you can start to build in the same approach to democratizing access to security events and positioning your teams to identify, respond, and remediate issues faster than ever before.

Next Steps

Since we can agree that knowing is half the battle, the next step is understanding how to use that knowledge to defend your cloud. Stay tuned for the next post in this series to learn how to better defend your cloud.