Jesse Trucks is the Minister of Magic at Splunk, where he consults on security and compliance program designs and develops Splunk architectures for security use cases, among other things. He brings more than 20 years of experience in tech to this role, having previously worked as director of security and compliance at Peak Hosting, a staff member at freenode, a cybersecurity engineer at Oak Ridge National Laboratory, and a systems engineer at D.E. Shaw Research, among several other positions. Of course, Jesse is also the host of Meanwhile in Security, the podcast about better cloud security you’re about to listen to.

Jesse: Welcome to Meanwhile in Security where I, your host Jesse Trucks, guides you to better security in the cloud.

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

Jesse: Trilogy of Threes and a New Mantra. Trilogy of Threes. Good security practices and good security programs are built on three separate but intertwined principles, each of which has three parts. Simon Sinek’s Golden Circle framework lays the foundation for why you have a security program, which is a balance of risks to critical assets and services, and business objectives. The next part of how you apply the Golden Circle to your security program is about how you accomplish meeting these objectives and mitigating your risk through the People, Process, and Technology framework.

The PPT method helps you define the roles are needed to implement your security program, the overview of processes or actions within your security program, and the types of technology that supports your security program. The final part of how you apply the Golden Circle encompasses what specific things you do to implement your security program using the Holy Trinity of Security: confidentiality, integrity, and availability, or the CIA triad. In your security program, you should define who should be allowed access to any data or service, how you monitor and protect any data or services, and how you keep data or services available for users. Although understanding how to build a security program from nothing is incredibly important, most of us are already operating within an existing security program. Many of us will have influence only on the specific implementation of tools for the Holy Trinity, CIA. All this theory is crucial to understand, but you still have a job to do. So, let’s get practical.

Where to start today. Searching online for ‘Top X for AWS Security’ returns an expected long list of pages and there are shed-loads of fantastic tips in the results. However, reading through many of them, including AWS’s own blog entry on the topic, shows that proper cloud security involves large projects and possibly fully re-architecting your entire environment. As is often the case in these things, all the best security advice in the cloud has to do right security from the very beginning. Yet this is like discovering a new love of playing the piano late in life like I did, [laugh] but someone telling you the right way to learn to play the piano is to take lessons as a child. This isn’t so useful advice, now is it? Of course, it’s too late to become a child piano prodigy, but it’s not too late to take up the piano and do well.

Fundamentals. In traditional non-cloud environments, physical security for everything leading up to touching a machine is usually the purview of a different part of the organization, or an entirely different organization than the security team or group responsible for system network and application security. Generally, most information or cybersecurity starts with accessing the software-based systems on a physical device’s console or through a network connection. This, of course, includes accessing the network through some software path, usually a TCP or UDP-based protocol. In cloud environments, the cloud providers, such as Amazon Web Services—or AWS—Microsoft Azure, or Google Cloud Platform—GCP—maintains and is wholly responsible for all the physical environment and the virtual platform or platforms made available to their customers, including all security and availability required for protecting the buildings and hardware, up through the hypervisors presenting services allowing customers to run systems.

All security above the hypervisor is the customer’s responsibility, from the operating system or OS through applications and services running on these systems. For example, if you run Windows systems for Active Directory Services, and Linux systems for organizations’ online presence, then you own all things in the Windows and Linux OSes, services running on those systems, and the data on those systems. This is called the shared responsibility model. AWS provides details on their compliance site aws.amazon.com/compliance as well as in a short video on their training and certification site aws.training.

Microsoft describes their model on their documentation site docs.microsoft.com/asure/security. Google has lots of information in various places on their Google Cloud Platform GCP site, including a guided tour of their physical security for their data centers, but finding a simple explanation like the other two major services have available eluded me. Google does have a detailed explanation of their shared responsibility matrix, as they call it, which is an 87-page PDF. Luckily, given the overwhelming popularity over the other cloud providers, I tend to focus mostly on AWS. I didn’t read the whole GCP document.

Announcer: If your mean time to WTF for a security alert is more than a minute, it’s time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you’re building a secure business on AWS with compliance requirements, you don’t really have time to choose between antivirus or firewall companies to help you secure your stack. That’s why Lacework is built from the ground up for the Cloud: low effort, high visibility, and detection. To learn more, visit lacework.com. That’s lacework.com.

Jesse: basic AWS training. Amazon provides ample training and online tutorials on all things AWS. This includes AWS basics through advanced AWS architecture and various specialty areas like machine learning and security, among others. I encourage everyone who touches anything in AWS to go through their training courses online at aws.training.

If you are new to AWS or cloud in general, go take AWS Cloud Practitioner Essentials, and then take some primers in AWS security: AWS Security Fundamentals; Introduction to AWS Identity and Access Management, or IAM; and AWS Foundations: Securing Your AWS Cloud. These are all eLearning-based and free. This will be some of the best nine to ten hours you can spend to build a foundation for securing your AWS infrastructure.

Learning is great; doing is better. Whether you’ve taken the relevant AWS training or just want to dive in and make your AWS security better today, you’ll want to go make a difference in your risk and exposure as quickly as possible. After all, unless you’re listening to this as a seasoned security professional, you’re probably here to learn how to make your security better as quickly and easily as possible. Anyone looking at the list of courses I’ve suggested and considering my fundamental approach might be trying to discern which first principles of good security I’ll talk about first. If you’re thinking along those lines, you might miss some of the very basics.

As with all things in the tech world, there are some basics that can’t be repeated often enough. The most simple and blatantly obvious advice is to secure your S3 buckets. Let’s cover that again so nobody misses the point. Secure. Your. S3. Buckets. Now, repeat that 27 times every morning while you get ready for work before you touch your keyboard.

This is the cloud version of securing FTP, meaning FTP isn’t too bad protocol, but it’s notorious for being misconfigured and allowing anonymous FTP uploads and downloads. If you want to fall into a hole learning everything there is to this, go read the Security Best Practices for Amazon S3 portion of the S3 User Guide. If you don’t have time or energy for wading through that lengthy but valuable tome, check some basics for your maximum ROI for minimal effort. If you allow public access to S3 files directly, you should seriously reconsider your solution. There are dozens of ways to provide access to files that aren’t as risky as opening direct access to data storage.

You should block public access at the account level by going to the S3 services section in the AWS Management Console. And in the menu on the left, select ‘Block Public Access Settings for this Account.’ If you can’t do this immediately, go lockdown all buckets that don’t have this insane requirement to be open to the public. Do this by selecting the bucket, and block access in the permissions tab.

You should always be thinking of the fundamentals of great security, and you should always be learning and improving your skills, of course. You should also continually make little changes and review the basics. Some new project will go live and some S3 bucket will have horrible permission settings, or some other fundamental violation of security best practices will occur. We should always be looking out for violations of the basics, even while we work on the larger projects with greater apparent impact. I repeated my mantra 27 times today. Have you?

Jesse: Thanks for listening. Please subscribe and rate us on Apple and Google Podcast, Spotify, or wherever you listen to podcasts.

Announcer: This has been a HumblePod production. Stay humble.