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.

Transcript

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

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.

My recent experience prepping a commercial space for a state fire marshal office inspection and approval has me thinking about compliance and security and ever-present ‘temporary’ fix for things. How many times have we said, “Oh, I’ll just do this quick fix to get us by,” and that quick fix becomes the de facto supported production implementation? Repeat after me: all changes are permanent until replaced. All changes are permanent until replaced.

Anything we alter at all, whether it in computing or in real life, is a permanent alteration until it is replaced by a new alteration, or by a natural corrective or evolutionary process, like decay. We cut our hair and it grows back. We weed our gardens and the weeds return. If you don’t want temporary changes happening in your environment, then implement hard controls that will correct any aberrations that come up. Cloud-native architectures give us the tools to force this by making it seamless to close down and erased from existence anything that veers from your ideal. Take advantage of this now.

Meanwhile, in the news. Password reset code brute force vulnerability in AWS Cognito. If you use this AWS service, you should read this one. Although it is now patched, it’s good to understand how AWS Cognito works more closely, which is true for any other security service you rely upon that is hosted by your cloud provider or other vendor.

Task force seeks to disrupt a ransomware payment. This is tangentially related to cloud security because both Amazon and Microsoft has joined up on this one, but I’m personally fascinated by strange frenemy combinations who work together on these things. I’m watching for either interesting things to happen with their recommendations that could have an impact on disclosure of ransomware incidents, or for it all to fizzle out to do nothing.

Is your cloud raining sensitive data? Kubernetes generally needs securing like any other service. Time to stop ignoring your newest infrastructure and lock Kubernetes down. However, if you want real security for your Kubernetes clusters, you should look at a robust solution like Fairwinds Insights. I’m a big fan of outsourcing tool development to experts.

Enterprise lift and shift to the public cloud requires a newer type of API and cloud security program to prevent data breaches. Ignoring some glaring editing mistakes, which is rather difficult for me to do, I’d like this easy-to-read case study of a traditional on-prem infrastructure going through a lift-and-shift cloud migration. This piece specifically addresses some of the serious security implications of doing this, and how your attack surface changes dramatically in the process.

NOAA shifts some key environmental data processing to the cloud. This one is important to me personally. Years ago, when I was a security engineer for the United States Department of Energy Oak Ridge National Laboratory High-Performance Computing Group—boy, that’s a mouthful—I helped ensure security for one of the National Oceanic and Atmospheric Administration—or NOAA—supercomputers doing climate research. NOAA moving any of its compute systems supporting global research is a very big deal, and this is a great example of why AWS GovCloud is helping the US federal government modernize and move to the cloud. Also, mixing an acronym-heavy industry with government work turns into a pile of TLS so fast. Also, as another aside, this was back when I met The Duckbill Group CEO, Mike Julian, in Knoxville, Tennessee.

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

ClearDATA expands flagship solution to facilitate health care’s adoption of containers and serverless tech. Speaking of outsourcing to experts, there are lots of compliance reporting options out there, and like my favorite, Qmulos. Full disclosure, remember I do work for Splunk. But there are less options for actively managing compliance in your cloud environment. Does anyone have experience with ClearDATA’s Comply offering? Email me, I want to know more.

Expanding security, visibility, and automation across AWS environments. I’m most interested in the AWS Graviton to ARM-based security in the asset discovery for AWS environments announcements in this piece. First, I love me some chip geekery, especially when security-related, and second, the thing most of us suck at is tracking your assets. Any help managing an asset list for our security tools is gravy.

As Microsoft nears a $2 trillion market cap, Amazon is most likely to reach that level next. I’m always looking at economics and how that drives both behavior and technology. Also, looking at how markets move and companies grow and die tells us more about trends in technology decisions and spend than many other indicators. Stop and think about the implications of this: four of the world’s five largest companies by market capitalization are us tech giants. Three of these are the parent companies of the three cloud giants: Microsoft, Amazon, and Alphabet or Google. It’s a cloudy forecast for sure.

Seven modern-day cybersecurity realities. None of these are earth-shattering news, but at least some of these will make you cringe when you consider your own environment. Feeling uncomfortable thinking about any of these is a good thing if you act on that feeling. Go forth and fix things.

The challenge of securing non-people identities. Most of us wearily monitor people’s account activity to ensure they aren’t compromised. But the art and science behind monitoring accounts not tied to a person is more difficult to master. I argue some of the recent big security breaches shine light on these accounts being more critical to risk mitigation than human-used accounts.

And now for the tip of the week. Turn off instances or containers or cloud services you aren’t using. We turn off unused services on a system, right? Not using Postgres or MySQL? Shut it down. Not using the webserver? Shut it down.

Leaving something answering on the network that isn’t being actively used, or worse, not actively monitored, is an attack vector that can be easily leveraged by malware and bad actors. This is true for whole systems or cloud services that aren’t actively part of your functional environment. If you aren’t using your testing system, it should not be running at all. Leaving unused whole systems is far worse than leaving an extra service running because an intruder now has free reign over a whole machine that isn’t in the spotlight, not just a corner of a well-used system. Given you can programmatically turn whole servers or containers on and off, there’s no excuse for leaving them up when not in use. Turn those systems off. When in doubt, close the route.

And that’s a wrap for the week. This is Meanwhile in Security. Securely yours, Jesse Trucks.

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.