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.

Jesse: Building new things in the cloud is often a fun and exciting process, however moving a legacy application or infrastructure is usually a difficult and stressful process. There are several ways to implement a migration of something to run in the cloud. Which cloud migration strategy you choose largely depends on timeline and available resources. Some ways to accomplish an application migration are: one, rehost, aka lift-and-shift; two, refactor; three, rebuild; and four, replace. Rehosting, or lifting and shifting, simply means replicating your current legacy infrastructure on systems in the cloud, then cutting over from production. You spin up cloud systems in something like AWS EC2, install the OS and supporting middleware, add your application and data on top, then cut to prod.

Refactoring means rewriting your application to run in at least partially cloud-native services, but you can shortcut some of this by using container or middleware services, such as cloud-native databases offered from your cloud provider. Doing this means you largely use your codebase unchanged, but the underlying infrastructure is more scalable and is at least partially like a cloud-native product.

Rebuilding means writing a cloud-native app to be truly cloud-native. This is much like writing a new application as cloud-native, but you have an existing codebase—and possibly compatibility issues to contend with—from which to pull.

Replacing simply means implementing a SaaS tool that meets the same business requirements as the legacy application without migrating any of the old code. For example, moving to use Salesforce instead of a legacy CRM product or custom-built sales process tracking systems.

You can, of course, do some of these in stages as iterative steps. To do this, you could lift-and-shift your existing systems, then slowly work out replacing individual pieces with cloud-native solutions over time. Then you eventually get to a place where you can do very little work to yank out your final EC2 or container systems. At that point, you have a fully cloud-native application. If you don’t have much, or any, cloud application experience in your organization, follow the path of stepping through these processes as you grow your organization’s cloud skill-base and experience. Your people will migrate with your applications.

Meanwhile in the news. What does it Take to Secure Containers? Using containers isn’t instant security. They’re easier to lock down in terms of services and such, but it isn’t a silver bullet. The vampires are still going to storm the house if you invite them in.

Critical ICS vulnerabilities can be exploited through leading cloud-management platforms. Industrial control systems, or ICS, are notoriously insecure by default and often difficult to secure at all. Modern paradigms of locking down access to these infrastructures and tunneling all access through management and monitoring platforms is great. However, that platform is now the keys to the whole kingdom, so secure your 
cloud management apps and dial up the monitoring.

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.

Kaseya Obtains Universal Decryptor for REvil Ransomware. This is amazing that Kaseya got their hands on the bits to unlock REvil things. If you are their customer, go get this right away. This doesn’t get you off the hook, though. There are likely time bombs just waiting for whatever rises from the ashes of REvil to take over the next phase. Watch your back.

Kubernetes Cloud Clusters Face Cyberattacks via Argo Workflows. Argo Workflows are great—so I hear—but now you could be pwned if you aren’t careful. Back to my often-used admonishment, don’t be stupid. Like many things, it’s easy to lock down and keep the control systems hidden, but you have to both care and verify you’ve been diligent.

Cloud security is like an ‘all-you-can-eat buffet’. The lesson here is that, as one source says, securing cloud resources is not the same as securing on-prem resources. The tools are often the same or similar, but how you use them is different. Also, the sheer volume of highly granular data from cloud systems is impossible for humans to parse and manage. You need better, highly tuned tools for the cloud.

Cloud security in 2021: A business guide to essential tools and best practices. The tl;dr: don’t be stupid. Like many lists of fundamental cloud security things, it’s lots of obvious things most people say they understand and never implement, consequences be damned.

GitHub boosts supply chain security for Go modules. I harp on supply-chain protection frequently because corrupting your software supply chain is insidious and incredibly hard to detect and remediate. Looks like there’s some help if you code in Golang.

Cloud (in)security: Avoiding common cloud misconfigurations. You can never read enough of these lists of obvious things to do. Even if you have done most of the basics correctly, it’s likely some new project hasn’t followed the best practices. This is back to my usual admonishment: DBS.

Akamai Edge DNS outage knocks out multiple major websites. Most of us got ensnared in this one. Either your DNS was wonky or sites you use were messed up. Keep this in mind with single-vendor solutions. Granted, there are times that you can’t avoid something being unavailable. No matter how well you plan, something will break or be owned by malware or attackers. Fail gracefully and make a necessary recovery plan.

And now for the tip of the week. Check your sources. Don’t believe every article or blog you read until you have verified the source as trustworthy. Think of this as the zero trust model of information gathering. Trust no source until you confirm that source’s information with a trusted third party. This is true for news, process and methodologies, and product or service vendors. Go to multiple sites, look at many frameworks and standards, and get lots of reviews and experiences from others on products and services before you implement. 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.