Archive 6 min read

DevOps Overload

DevOps is the "new hotness" but what does it really mean to development, operations, and security?

DevOps Overload

Watch this episode on YouTube.

Reasonably Accurate 馃馃 Transcript

All right, all good morning episode seven. It's a bit of a dreary day here, but I'm gonna try to keep things upbeat. Um because I'm not fearing feeling dreary. I am feeling parched, which is why I've got my tea finally getting in at the right temperature for broadcast time so that I don't scald myself.

Um Never looks good on camera and you're like, hey, everybody, how's it? Oh, it's going good fight through it. Um All good. Uh It's Wednesday, I think, pretty sure it's Wednesday yesterday when I was talking to you. Um We started talking about voice interfaces.

Um and I fully intended on spending a good chunk of my day diving into some of the issues around voice and because I think it's absolutely fascinating. I had posted some links to a couple um pieces, one from Wired, one from Gary Vanner Chuck.

And that really kind of dive into um some of the issues around voice and I think those are worth checking out. But of course, like most days I was thinking of going this way and it ended up taking a bit of a sharp turn.

Um So there was an announcement yesterday or not so much an announcement as a story that broke where a team working in the aws cloud had unfortunately exposed the management interface improperly. In fact, it was exposed at all. It was probably improper and of course, in there were their Amazon API access keys.

And for those of you that don't know, it's an access key and a secret key. And basically what it does is with these two pieces of information, your user name and password to your Aws account. Now, a lot of the time, unfortunately, people give these things way too many privileges.

So when those leak, it can't be a big deal. Good news. In this case, it was responsibly disclosed. But of course, that led me to a little bit of video work. I just published it first thing this morning, I'll put a link down below and of course, I'll republish it here on Facebook and on youtube and all my social channels.

Just a quick two minute hit about how to avoid this happening to you um within Aws, um uh specifically, but of course, it applies to a number of other areas. Um But this one really dives into the technical aspects looking for the TE of uh of AWS because it is super easy to avoid in that environment.

But the bigger issue and that's kind of what I wanted to tackle this morning because I think I'm going to be spending a good chunk of my day doing this now. Um, as much as I try to plan out what I'm gonna do for the day and then share it with, um, you know, the reality is, stuff is really dynamic.

It really changes a lot. So based on the fact that these credentials have leaked and it sort of raised the issue again. It kind of comes back for me to the idea of Dev ops and I know people are trying to jam Dev ops into it doesn't really work.

It's really about um you know, breaking down barriers between it teams. But really at the end of the day connecting it with um the business. So no matter what you call it, it's easier just to use the accepted Dev ops instead of trying to create something new because security is part and parcel of all of it.

And really, that's where people kind of miss out is that because you're doing more with a smaller team, with a more dynamic team, what ends up happening is a lot of things. They kind of look and say, hey, this works, I'm going to do it this way because it's working and meets our goals and let's move forward because there's so much pressure to deliver fast and that's not necessarily a bad thing.

But when you're dealing with um you know, a huge variety of technologies, you can really overlook some of the basics and this is what happens time and time again with these access keys and with credentials is that the easiest and I'll fully admit this, the easiest way to get things running is to fire up an access key and a secret key, give it full permissions or full access to the services you need.

And then just go, just go from there because it works because you have full access. That's a horrible security decision and it's not something you need to make at all. What you need to implement is what's called the principle of lease privilege.

And lease privilege essentially means give an object or a user only the bare minimum permissions that they need to do their job. So they don't need admin access to everything. You just need access to write to one file in S3 or to one table in dynamo or to one database in Aurora or whatever the case may be, that's the only permissions they should get.

Now, it's remarkably easy to do that in all of the major clouds in Azure, in the Google cloud platform in and the Aws cloud. So that's really the principle you should be applying to. But I totally understand the business pressures on people to deliver quickly.

The unfortunate thing is that you deliver quickly, you set up those credentials real early on in your process and you never go back and visit them. So when something like this happens where they're exposed unnecessarily, you go, oh man, I have full admin access that is breached out, that is now publicly available.

And I need to go back, not only cut off that access immediately, but go back and audit to see everything that they've done to make sure that there's nothing malicious or untoward happening in my account. Now, the best case scenario is that they don't touch anything that you actually need for production and just run resources in your account.

We've seen that happen where people have been hit with, you know, a $64,000 bill I think was the one I saw yesterday. Um, excuse me, um inadvertently, inadvertently because they had left their credentials out there. Now, worst case scenario is that they wipe you out and we've seen that happen a few years ago.

Thankfully, it hasn't really happened since where somebody left out full admin credentials and unfortunately, uh someone with malicious intentions got them and took them right down. Um So definitely, um issues to be considered here and I'm just trying not to giggle because I have um a live studio audience member who is participating.

He just came in and jumped. This is Bubba. Um this is the beauty of life. Things happen. Um You know, it's no BBC kid which is still cracking me up. Um But, you know, Bubba obviously wants to be a little bit famous here, so he gets his little five seconds of fame.

Anyway, that's what I'm tackling today. Uh Interesting thing. You know, the credentials, uh check out the video that I'm gonna post. I actually um put up a post on, on medium as well. Um For those of you that don't want to watch the video, but you would rather read and link to some uh more concrete resources on how to fix this.

Um Yes, Bubba, you definitely want to be on camera. Um So that's what I'm doing with my day. I'm also spending it with this guy as every day and his brother who's less uh camera friendly, a little more camera shy.

Um, but, uh I hope you guys are up for a good day. I hope you've got a coffee and it's not so dreary, um or a tea if that's your thing like me and uh I look forward to chatting to you with you online.

We'll see all, all. Yeah. Hey, first time this time, uh hit me up, marknca hit me here on Facebook on linkedin wherever you're finding this content. Happy to engage, wondering what your thoughts are. How do you tackle all of those services and different technologies that you're using on a smaller team?

You can't know them all inside and out. How do you make sure that you're not going to shoot yourself in the foot or make a critical mistake? Something that works now, but might not work for you later. Let me know. I'm happy to chat.

Looking forward to chatting. Have a great great day.

Read next