Pushing Left with Tanya Janca

Tanya: [00:00:00] Come on over, bring coffee, we will worship you.

Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matty Stratton, and I’ve got a great show. We’re talking all about security and how we can— what we can learn about that and how we can make things even more awesome. But while we’re waiting to go into all of that, let’s take a minute to hear from our sponsors.

Tanya: The worst thing about the Arrested DevOps podcast is when it ends. You’re left wondering what to do next.

Matty: What are you going to listen to on your commute home? How do you occupy your time when walking the dog? What are you going to listen to during the quarterly all-hands meeting?

Tanya: But fear not, dear listener, there is a solution.

Matty: You need to subscribe to Software Defined Talk right now. It’s a weekly podcast that recaps all the news in cloud computing, DevOps, and enterprise software. The hosts, Cote, Matt Ray, and Brandon Wichard, will keep you up to date on all things cloud while offering tips on how to optimize your Costco haul and how to PowerPoint. It’s a fun, free-flowing conversation that will keep you entertained and informed.

Tanya: [00:01:17] What are you waiting for?

Matty: Subscribe to the podcast today by visiting softwaredefinedtalk.com or by searching for Software Defined Talk in your favorite podcast app. Today, I’m joined by Tanya Janca, a Cloud Advocate at Microsoft. Shownotes for this episode can be found at arresteddevops.com/pushing-left. But before we get into this, Tanya, can you tell us a little bit about yourself and your experience, and then we’ll start talking about this meaty topic?

Tanya: Absolutely. Thanks, Matty. So, I’m Tanya. Hi. I’m a software developer turned security person turned cloud obsessed person. I previously did software development, like web app hacking and incident response, and then I started doing public speaking and I started doing it more and more, and then eventually I just didn’t have so much time to go to my day job. And that’s where my— I’m obsessed with security and making software more secure. And yeah, that’s me in a nutshell.

Matty: [00:02:23] So one of the things I see when I kind of am looking at what you’re tweeting about, and you always have really interesting topics on Twitter, you’re one of my favorite people to follow in the space, but you talk about threat modeling, and I hear people talk about this a lot. It’s a topic that comes up both literally and as an analogy for other things in day-to-day life. Can we talk a little bit about what threat modeling is in general and what we can learn about it?

Tanya: Absolutely. I was first introduced to threat modeling quite a while ago. I was invited sort of just to watch, and the, you know, the CISO at the time brought me along because I just joined the security team and had a, you know, meeting with the business talking about what kept them up at night. And it turned out that my concerns as, you know, the software developer nerd were completely different than what the business were worried about. And they started talking about like the things that mattered the most to our organization and then how that would be reflected in the applications I literally had no idea. I would never have seen those threats coming from my vantage point of, I just want the app to run and work the whole time and not fall down, right? Then he started getting me into the idea of meeting informally with developers and talking with them about it with the idea that, so you want to figure out what the threats to your system are? And talk about them and make sure you will understand what they are. Then you want to actually try to fix them or protect against them depending, or just accept them if they’re really little. I recently wrote an article with my friend Brian Hughes, and he has this cool app that’s IoT that I’m not allowed telling you what it does. But when he was telling me about it, I was like, well, what about your users? Before we realized it, the threats He didn’t, he just didn’t see it the same angle as I did. You know, he’s coming at it from a developer standpoint. And then when I talked about, well, what if someone uses your app, you know, and then this happens and then someone else is attacking your users and, you know, they have information that’s personal and sensitive about your users because of your app, like that’s the end of the world for us. Like if your users get hurt, well, when they’ve used your app and I find that when you talk with developers, they have very different ideas of what the actual risks and dangers are compared to the business. Putting a few of you in a room and having an informal discussion, or you can do a more formal way of doing it. There are a bunch of frameworks like STRIDE or PASTA, 2 really popular ones, where it has a series of questions that it asks you to go through. I definitely agree you should make sure you touch on those bases, but sometimes just having an informal discussion is a good way to warm everyone up. Like, if you’re going to hack your own app, how would you do it? And, you know, if developers don’t feel threatened, they feel they can trust you and just talk openly, the things they will tell you.

Matty: [00:05:31] Yeah.

Tanya: So once you know what all the threats are, then you’re like, okay, well, let’s go see if they’re real. Like, let’s go look through my code or let’s try to attack my app in that way and see if we’re vulnerable or not. And then you kind of go from there. It gives you a starting place about what people are actually worried about, because sometimes the things that I think we should be worried about, turns out the business is like, no, that’s not important because of blah. Like, oh crap, I have been worrying about that for a week for no reason. So glad we talked.

Matty: So it’s, it sounds like it’s a conversation that is about a lot of what Right? Like, let’s kind of go down the what might happen based upon— and our perspectives are all different, so I imagine having different diversity of opinions and experience only makes your threat modeling exercise more resilient, more effective.

Tanya: Yes, so, so true. It’s basically evil brainstorming, and the more point of views you have, the better.

Matty: So what are— so if someone’s trying to get— and you alluded to this a little bit where you said maybe start with an informal conversation, but what are some of the tactics or techniques or approaches if if someone feels like this is something they’re not doing in their team or their organization, what’s some of the starting points, like some, some basic starting advice, um, especially for someone who’s not maybe in the InfoSec world?

Tanya: [00:06:48] Okay, so, um, I’m going to be super shameless and promote my blog right now. Um, I’m, I’m about to release a more formal article about threat modeling and then to go with the informal one as part of my Pushing Left Like a Blog series, and it will be basically how to start. I definitely, just for the very beginning, just if you know the CIA, the confidentiality, integrity, and availability, if you can just make a meeting for half an hour or an hour with someone from the business that understands the requirements and someone from the tech team that understands the tech requirements and have a meeting with them and a security person and just ask them about protecting CIA. So the confidentiality of the data, like what’s the sensitivity level, etc.? Where are you storing it? Integrity, you know, what happens if something changes it? How could that happen? And then availability, like what could knock this down? What could come between us? Like what, what can we tolerate, right? Like some— if it’s, you know, if it’s a pacemaker, you can’t really accept very much downtime. But if you sell flowers for, you know, a mom-and-pop shop down the corner, if it’s down for an hour, it’s like, oh, that sucks. It’s just, it’s not the same. And so although that’s a very simplified version of it, like, that’s a great place to start. Because if you don’t want to, in my opinion, you don’t want to run out and like do this super advanced like attack trees and run them through, you know, a giant, very formal, very long process the first time because you could scare them away. And if instead they view this as kind of fun and interesting and weird, you have a lot more likely success in your future. I find with getting people to be cooperative, a lightweight process to start and then kind of move your way up, that would be where I would suggest that everyone start.

Matty: [00:08:48] So it sounds like one of the— I don’t want to say mistakes, but missteps that someone could make starting this out is making it too complex. What are some of the other maybe mud pies that someone could accidentally make that they might want to try to avoid?

Tanya: Definitely, if you think this is the only thing that you need to do in order to ensure your application is secure, that would be a problem. Having a really heavy process, having a process that is— okay, so it’s better to threat model at the end than not at all, but starting earlier is always better. If you’re doing requirements, having a security person just peruse the requirements and see, oh, You know, it looks like you’re doing this. Have you thought of that? Maybe we need a security requirement there. And then, you know, while you’re designing it, that’s a great time to do a threat model discussion, right? Before, before the design is done, before it’s like 3 quarters or almost done being coded, right? Because it’s so much cheaper to find a design flaw really early than at the end. I’ve definitely been the victim of that where it’s like, oh crap, We were gonna release in 2 weeks. That looks bad. One more good place to start. I am a huge fan of OWASP, the Open Web Application Security Project. They have an application threat modeling wiki page. I know our website’s ugly. We know. We’re not graphic designers, we’re security folk. But it’s a great, great place to start. Just reading the first line, I’m like, oh yeah, that perfectly describes what I think of as threat modeling. I would strongly suggest Basically, the OWASP webpage is a good place to start for anything related to the security of software. There’s usually something awesome there.

Matty: [00:10:34] You talked about your blog series about pushing left, and I really want to talk about that. I think it’s a really interesting series. What’s it about, and why is it pushing left and not shifting left, which is the thing we all hear all the time? Shift left. Why do we have to push left?

Tanya: The first time I heard of pushing left, my friend Damian Trudel from the Canadian government was telling me about it. He’s a really smart dude, but he’s one of those people that are so smart that they don’t always explain things super clearly. Finally, I just drew it out and I understood. Shifting left is, you know, if you draw the system development lifecycle out on a piece of paper, first to the farthest left you have requirements, Then you have design. Then as you continue right, you have coding, testing, release, and hopefully not incident following that. The further left, physically left, that you would look on this page, the earlier you are in the system development lifecycle. When people say shifting left, it means everyone’s on board and let’s start security earlier. Well, I tend to say pushing left because, not to speak ill of places that I previously worked, but they weren’t— Right now, I work at Microsoft. The biggest software company on the planet, right? We are gigantic. They take security very, very seriously. They’re extremely advanced. Places I worked before, we can’t all be Microsoft, right? I found that him and I and others, we would have to battle to try to start security earlier. We would fight, and so we would push left together as best we could. That’s why I say pushing left.

Matty: [00:12:18] What are some of the things— and we’ll put a link to your blog series in the show notes for sure, so everyone make sure you check it out— but maybe some spoiler-free stuff? What are some of the things to be aware of that maybe you learned, or some things that were interesting that came to you through writing this series as you were putting it together? Because I know when I create stuff, I’ll maybe have an idea, and then I start putting things together, I’m like, oh, today I learned.

Tanya: I tend to go down huge rabbit holes. So the first couple posts were a little bit long, and then the 5th post was just gonna be like 20 pages. And my editor, so one of my friends reads it for me and she’s like, no, this is not acceptable. So we broke it up into 14 posts instead. But basically for each part of the system development lifecycle, there’s at least one security activity that you could, and hopefully one day will do. So during requirements, you want to have a security person see if there’s any requirements. Requirements could be all websites are available only over HTTPS, the strength of your keys, or the length of your keys, or the strength or modernness of your algorithm for encryption. It could be you want to do file uploads. OK, that’s risky. What can we do to reduce the risk of that? I’m going to add requirements around that. It’s kind of like a joke that it’s like a shopping cart. Oh, you’re doing this? Okay, so I’m just going to put these requirements in. The same with design. Not only should you ensure you’re using secure design principles, which I go through in depth, but also I believe during the design phase, we absolutely should be doing threat modeling. Then during coding, there’s secure coding types of concepts that I really want people to take away, and then also code review. If you have the time and money, static code analysis. I’m kind of just going in and explaining for someone that doesn’t know. If you’re already a super duper expert in threat modeling, you’re probably going to be like, well, this is pretty boring, Tanya. But for those of us that aren’t and haven’t done threat modeling for 10 years straight, I’m hoping that the blog is enlightening because when I started, I switched from software development to security. I have to say, I feel like I’ve finally gotten over the hump where I feel like I know more than I don’t know. It only took, like, 5 years. When I made my first talk called Pushing Left Like a Boss, which is what the blog article is about, it’s like, this is all the stuff that I wish someone had told me 2 years ago. Why couldn’t someone explain to me, like, I have a web app, here’s how you scan your code? Why couldn’t someone just tell me, like, this is a thing you can do, this is what DAST, dynamic application security testing, is. It’s running a web app scanner, and then you do more in-depth manual testing as you become more advanced. It’s hard if you speak to someone that’s already done all of this for 20 years, and they’re such an expert, they’re so deep in it, they totally don’t know how to explain. Well, every time I learn something new, I’m like, I’m going to try to explain it to someone else with a talk or a blog article. Usually, people have all these helpful comments and I learn more. Then I feel like I have that fresh wonder of, wow, I just discovered this and I’m excited. Maybe you will be too. The blog article just goes through and tries to explain the idea of an application security program, what could be involved, how those things work, and just the basics. So you can kind of know enough to be dangerous. Yes, that’s my hope, but not too dangerous.

Matty: [00:16:05] Right. It’s interesting because that’s similar to kind of the genesis of this show, this podcast, when we started it years ago, was because I felt like there weren’t any podcasts that were for the people that, as I used to say, your boss read about DevOps in the in-flight magazine and came to you and said, I want some of this. For what it’s worth, I never thought that there would be DevOps in an in-flight magazine, but I feel like somebody found that once and tweeted it to us. But then, that’s part of it, because it is this, like, what’s that accessibility, right? And the other thing that I think is also really interesting— there’s 2 things that kind of resonate with what you’re talking about. So one is, we use a different part of our brain when we’re teaching than when we’re absorbing information. So we learn things better by teaching them. So this is why I love giving talks and writing posts and stuff like that. I think it’s a great way to like cement learning. The other thing is, so I used to do a lot of swing dancing and we used to say that beginner dancers take intermediate classes, intermediate dancers take advanced classes, and advanced dancers take beginner classes. And I think there’s something to be said for experience and expertise, you know, drenched as we might be in our industry, there’s always something about going back to first principles and reading stuff that we might think is like for beginners because We’ve been doing things so long that we might have just missed like this one foundational thing, right? And hearing it through a different lens can really like go, oh, I never thought about it that way because I’ve been thinking about it this other way for the last 20 years. So this is my pitch to you that if you think you’re a super expert in something, go read some of the like basic posts about it because you know what, it might change how you think about it a little bit. And not read them so that you can go and, like, well, actually them. Read them and absorb them, and don’t give any feedback. Just listen. That’s my public for today on that topic. Everybody read beginner stuff. You’ll learn a lot.

Tanya: [00:18:05] I love it.

Matty: Also, serverless. That’s a thing, right? What’s up with security in the serverless world? Do we not have to worry about that anymore because that’s Amazon’s problem?

Tanya: Yeah. No, serverless is not Amazon’s problem. I mean, don’t get me wrong, it’s probably one of their many problems, but it’s not their responsibility. Let’s put it like that. Serverless is basically an app or a function that runs, but you don’t have it installed on a web server somewhere. It just runs. Just like we used to have bare metal, so you would have a server running on a computer, then we had virtualization and virtual machines. That would be You would have one physical machine with a whole bunch of VMs on it. Then we came up with containers. The container just runs the part of the operating system that you need to run your app. Then serverless is like, forget all that. You just hand it to us, and we’re going to make this thing go. Generally, they’re tiny. They don’t do a lot, but you have a whole bunch of serverless things. The thing about serverless is it’s still an app. A lot of them tend to appear and disappear and reappear and disappear. Sometimes if you scan an app or you’re doing testing, if it happens to be off, like let’s say you have a serverless app that runs once a week at 5:00 PM on Fridays, let’s say it’s reminding you all to go have beer. If you do testing on Monday, Tuesday, Wednesday, and then you don’t see it because it wasn’t running, it only runs 5 minutes a week, then that means that you haven’t seen it in your testing. But unfortunately, bad people and malicious actors, they don’t have— they don’t check out, they don’t punch a clock. They can work whenever they want. They can write a script to check constantly and scan over and over and see what’s going on. So it’s really important that we still actually make sure they’re secure. And OWASP came out with Tal Mal, he calls himself, Tal Malman, called the OWASP Top 10 Risks to Serverless Apps. They’re almost the same as regular web apps. They’re almost the exact same, except for you don’t— basically, you just don’t have to worry about configuring the server, but there’s still the potential for injection if it talks to the operating system or if it talks to a database. There’s still the potential for— there isn’t a potential for cross-site scripting. Well, I guess unless you have a COA web page, but generally no. But the idea is that all the same bad things, almost all the same things can still happen. It’s just a much shorter period of time if you turn it on and off. Usually serverless, you don’t run it all the time. That’s part of the appeal that you— let’s say if it runs once every week for 5 minutes, you only pay for that amount of time. But yeah, you still, you still really need to make sure those things are actually all secure and have an inventory of them, because if you don’t know you have them, how can you secure them? I’ve definitely been in a place where I’m responding to an incident for an app no one knew we had. That is thumbs down, not good from a security incident response perspective. Basically, we still need to think about almost all the same things, unfortunately. No free lunch, as Tal would say it.

Matty: [00:21:33] I think it’s interesting, too, when we look at this, like you said, it’s not running all the time, so I imagine that forensics become really challenging in serverless, because even just dynamic infrastructure becomes challenging, because I know, from a forensic standpoint, a lot of times, we want to be like, okay, freeze the system the way it was so we can go look at it. And you’re like, okay, but dynamic scaling, it got whacked and started over and whatever, and especially if it’s a function. But even then, maybe there’s not as many things. I guess this all goes back to, we can’t keep doing things the way we’ve always done them.

Tanya: Yes, absolutely. It’s important that serverless apps log. I know some people are like, oh, but it’s so fast, we don’t need to log. I’m like, oh, but when you don’t log things properly, then that means I have literally nothing to investigate. And then I’m like, I’m sorry, sir, I don’t know why our data is for sale on the dark web, but it’s definitely there. That’s ours, right?

Matty: [00:22:34] That’s what I can tell you. Yeah, I can tell you it’s ours.

Tanya: I can’t tell you how now because I do remember having to report that once when I was consulting. And, you know, I tend to deflect with humor, so I’m like You know, sir, I think the real concern here is why are they only charging $50? I mean, that’s what we should really be— okay, I’ll shut up.

Matty: It’s really interesting how, you know, and I’ve been in ops for a long time and, you know, spent my time— I’ve never been a dedicated security professional, but certainly worked with, uh, security folks a lot. And I, I think everyone’s always trying to do their best, so I want to make sure that that’s clear. Like, there’s no shade, right? But I— the thing that I never understood was patching exceptions, right? Which would be, you know, we’d run into this all the time where there’s a security patch and they’re like, oh, well, we got an exception that said it’s okay. And I always used to tell people, I’m like, it’s not like the bad guys on the internet, like you said, not like the bad— the malicious actors go, oh, you have a note.

Tanya: Okay, well then it’s okay, we’ll come back next week.

Matty: [00:23:38] Right, right, right. So it’s There’s sometimes these things where you just like, if you sort of tease them apart, you’re like, this just doesn’t actually stand up to like reality. And I think that goes back to the thing about like, oh, so we don’t need to log because it’s ephemeral and it does this thing. And it’s like, but what you can’t do is go log retroactively. You can’t say, well, I wish we had some. Ta-da, now we have them. So I guess that’s all part of the threat modeling, right, is to say, what would we do if? Right.

Tanya: Yes, definitely. And also following best practices, which is part of what I’m, I’m trying to release on the blog. Like, you need to log. Here’s what you need to log. Here’s what you should not log. Like, do not log someone’s social insurance number. Do not log their date of birth and home address and their name and their ID number. Right. But do log, you know, this username tried to log in 100 times in 1 second and got the password wrong 100 times. Well, that looks fishy, right? And so many custom apps don’t log anything. Or they’re the worst, Maddie. It’ll be like logged in and that’s it. It won’t say who with a timestamp. Great. Great.

Matty: [00:24:55] Sure did. Someone did something. There was, uh, I’m trying to remember. I was talking to somebody at DevOps Days Nashville last weekend who we were talking about terrible errors. And he was talking about there was an error that occurred in this application that he had to support in ops that would, when there was a problem, it would simply say something has occurred or something has happened. That’s what it was. Didn’t say what it was, but something has happened. And they actually got to the point that they built logging around because they couldn’t get the engineering team, the engineering team that did this to like fix it. So they actually built other logging around it. So when they’re like, oh, well, no one ever complained because it still just says something has happened. They’re like, there’s all this— the reason that no one’s bugging you anymore asking what something has happened means is because we actually now know, because we built stuff around it. But that was what happened, is it would get logged and then they would have to call the developer and say, it said something has happened, what happened? And they have to look into it. But I love something has happened.

Tanya: It is amazing how people— developers just want things to work, right? I remember taking over all these old legacy custom apps and They’re like, oh, we need your email address so we can put it on the notification thing. And I’m like, what’s that? And they’re like, well, all of the custom apps like ping in once a day so you know they’re up. And I said, what happens when they’re down? They’re like, they don’t ping. And I’m like, so I’m going to receive 72 notifications per day and I’m going to check them manually and remember to notice? I’m like, what if I’m sick for a day? Like, don’t worry, we spam all the developers with the same thing. So everyone had a rule that all those things went to a folder and we ignored them. Because who’s going to remember to check all, all of them every day. Right.

Matty: [00:26:31] And so I’m like, normalization of deviance. Yeah.

Tanya: Like, this is, this is not working, you know? And they’re like, well, what if we had it notify us only when it was down? Like, okay, let’s try harder. Yeah. So we, we had to have something go and ping and check. And if it didn’t ping back, then it would send us an email, top priority. Like, great improvements, high fives all around. Thank you.

Matty: And it’s like everyone’s trying, right? But they’re usually— it’s we’re doing something quickly. I remember this is my last little thing about this, that they’re thinking about funny security things. I was at an e-commerce company and the architect— I remember I happened to be in the meeting and the architect was explaining to the— what we, I guess you’d say, like front ends or whoever, you know, kind of was handing off like some backend stuff they wrote. And he’s like, okay, in this config, because then there was a key. That was like the encryption key, or the— but it wasn’t really an encryption key, but it was just sort of an identifier. And he’s like, so here in the config, you put in some key, right? And then blah, blah, blah, da, da, da, da. And I remember like a month or two later, my ops team, we were deploying and we’re like, what is some key? And that’s what it said in the config. It was some key. And because he said you put in some key, right? I’m like, well, I was like, Shane, to be fair, you know, works as implemented. You implemented what you designed. And yeah, I still give him a hard time about that one. I was like, you know, clear. So along those lines, um, and don’t worry, ops people, we’ll get on you in a minute, but what are some of the things that software engineers and developers don’t know about security that you really think they should level up about?

Tanya: [00:28:05] Hmm, this is a tough one because whenever I speak anywhere, I tend to flash the CIA triad, the confidentiality, integrity, and availability triangle. And then I ask, who knows what this is? And a very small amount of hands go up. But I don’t blame software engineers for not knowing it because it’s not taught in school.

Matty: I was going to say, let me, let me put some caveat around this is I didn’t mean like, what are all the ways software engineers are dumb? But like, what are some of the things that we don’t know that it would really be great and everyone could do a better job if they knew about?

Tanya: Okay. Yeah. So, so I wish that all of them understood like the reason why every security person has a job is because it’s our job to, one, follow that mandate, so protect the processes, like the systems and the data in regards to confidentiality, integrity, and availability, and that it’s our job to enable all of you to do your job securely, which means you kind of need to tell us when you need us because sometimes we don’t know. So if you’re doing a design and you’re like, I’m not sure Come on over, bring coffee, we will worship you. Invite us to your meeting. We’re not that bad. Sometimes I think that software engineers feel they’re a bit on their own, and I know that any security team that I would be happy to work on would be really happy to hear software developers say, I have this problem, could you help me? Rather than them deciding they’ll try to figure it out on their own if it’s a security-specific thing. Because sometimes we end up with things that are amazing from a security standpoint, like amazingly bad. Like, oh, well, we Base64 encoded this twice, so it’s encrypted. And they wrote in the design it was encrypted, and it’s only because I asked, like, oh, how did you encrypt it? And they’re like, oh, we Base64 encoded it. Twice. No one will ever catch that. I’m like, that is level 1 at any capture the flag contest. That is, that is nothing. No, no, no. Okay, so, and, you know, but I explained it really densely and I’m like, let me help you add the encryption, right? And it turned out, you know, another group had already implemented it, but they just didn’t know who to talk to or how to do it. And to save time, they just did that because they thought it was equivalent and they didn’t understand the difference. So I guess What I wish they knew is the security team does want to help you, even if sometimes we’re not friendly. Sometimes we can be prickly. I have been prickled by security teams before. I say just like keep annoying us till you get what you need because that’s our job is to help you. So yeah, that’s a thing I wish that they knew about security is that it’s our responsibility to help. But also, definitely as well, the existence of OWASP, the Open Web Application Security Project. And if— so if you— okay, this is going to be a 2-parter, Maddie. I know you asked— oh, you said so many things, you didn’t say one thing. Okay, good, I’m off the hook. I don’t have to try to meld it all into one thing. Okay, so when I was a software developer, this is what I did, and I know lots of you do it because that is what I did. I code all day happily. There’s a thing I forget how to do. I go look on Stack Overflow. I’m like, oh, what is the top thing? Awesome. Copy, paste, it compiles. Great. And then I just continue my day. Whatever is at the top is the worst in regards to security every time. It’s so awful, Matti. If you just peel all the security layers off of everything, it’s so much easier. As much as the security community has tried to vote down those things, it never works. Instead, if you are going to do this, you’re like, I don’t know how to do this. Instead, search online and search OWASP cheat sheet and then the thing you’re trying to do. There’s this amazing project by Dominique Raito, Jim Manico, and a bunch of other awesome humans where basically they just made a cheat sheet on every single thing they could possibly think of. And it’s just how to do this, how to do that, code samples, because they just want it to be easier. So whenever I don’t know the answer, I look up that or just OWASP and the thing I’m looking up, and then the right answer actually comes to the top of the search results, which is magical. So please just change your searching and you will instantaneously start having more secure apps.

Matty: [00:32:43] I think that makes a lot of sense because really at the end of the day, the way to be the best in tech is to be just really good at searching. I was talking to someone about this at a conference the other day too, where I was like, I remember way back in the day, because I knew how to use AltaVista, like I was the smartest person in my company. Because I’d say, you come to me and ask a question, I’d be like, oh, that’s a tough one, let me think about it. And you’d leave my office and I knew how to look it up on AltaVista. And then I would wait half an hour to give you the answer so that you thought I really was thinking about it. And you know what, in like 1998, you could totally get away with that shit.

Tanya: I love it.

Matty: So, you know, this is, you know, how it goes. You just have to know how to search. It’s a little more nuanced now. So like Tanya said, improve your searching and improve your security. What are some of the things when we think about on the operational side? And I think the input you gave about understanding how to work with security applies to SRE and to ops as well. But are there any things when you think about the folks who are running the systems that are doing ops that maybe are maybe misconceptions, especially because ops has been part of— like ops, I feel fairly coupled to InfoSec a lot, but we might be used to doing things kind of an old way. Like, how does that start to hurt us maybe in this new world?

Tanya: [00:34:00] I feel like ops folks get beat up a lot. Like people give them all this crap about why things aren’t patched, but then they’re in, you know, the slow waterfall place where, you know, someone sneezes, everything will shatter. And it’s like, you know, they’re doing a really great job considering the awfulness that they’ve been dropped into. Definitely, I feel switching to smaller changes more often, which is synonymous with the ops half of DevOps, right? If you can release more often, that means you can do the emergency security patch more often and quicker and faster. Definitely. I think that a lot of ops people haven’t had the chance necessarily to be exposed to various security scanning tools that they could add to a pipeline or that they’re definitely smart enough to be able to run. Sometimes I think people are like, oh, that’s a hacking tool. I’m going to need 5 weeks’ training. I’m like, no, no, no, press this button. I was like, which subnet do you want to scan? Let’s go, right? And once I figured out how to use Nessus, I was like, oh my gosh, people get paid $1,000 a day to run this? Are you kidding? Nessus is a great tool.

Matty: [00:35:20] Don’t ruin it for everyone.

Tanya: Uh-oh, shh, don’t tell. But I think if the security team worked with the ops folks and bought them licenses and gave them some training, I think that they could be way ahead. On things. I also think that, you know, adding automation to the pipeline so it scans containers for really obvious known vulnerabilities, or it scans VMs for obvious known vulnerabilities. Also, I guess— no, I was going to get into networking, so I’ll try not to crash into the networking side. We’ll just leave it at that.

Matty: Crash away.

Tanya: Well, I think that Um, so this idea of assume breach, I feel, is really, really important. Um, I’ve worked places with a very, very, very flat network. It— I remember like going in with my scanner, I’m like, oh, I thought you had all of these zones. And they’re like, oh, like we drew, drew out where they will be someday. And so everyone thought they had a segmented network, but they just had one big network, which was great for me, like running a little a little pen test on their one web app. I’m like, great, I’m going to scan your whole network, tell you everything that’s wrong, no problem. But the idea of zero trust is just so cool. It’s so awesome. Why did we not always do this? If we do zero trust— I’m a cloud advocate. I work for one of the clouds. They all basically have the same awesome features, and if one of them comes out with a new one, the other 2 will soon, don’t worry. They have all of these automatic zero trust types of things that you can do. You press a button, all the ports are closed all the time. You have to flip them open manually or with a function, etc. Setting up zero trust is less and less difficult and more and more easy because it’s so much better. A database should only ever talk to the app or the database administrators. No one else should ever need to talk to that. Yeah, anyway.

Matty: [00:37:34] Well, yeah, because we used to think, like, well, we just have the most rad perimeter and there we go, right?

Tanya: Yeah.

Matty: So that’s not our world anymore. There are no perimeters. The perimeter is gone.

Tanya: Exactly. And as systems get more complex, for instance, like with serverless, so many people are poking holes through or just going directly outside You don’t even realize it. Like, I remember, you know, being the security tester coming in and someone’s like, oh, do you want to see our app? I’m like, oh, I don’t see it on the domain. And they like take out their credit card. They’re like, I couldn’t wait. So I just went and did it. And it’s on, you know, this cloud. Like, oh crap, you’re totally outside the perimeter. That’s amazing. And yeah, it just There’s so many holes. My old boss used to refer to our firewall as the Swiss cheese. Like, don’t say that in front of other people, it’s embarrassing. But that’s what a lot of burners look like. So if we assume breach and we go with the idea of zero trust, like, oh gosh, I know that it’s annoying at first, but once it’s set up, it’s just like someone gets in, they’re just like, damn it, this is so boring, I can’t get anywhere. And that’s exactly what I want. I want malicious actors to be like, ah, this is too hard, I’m gonna go bother someone else.

Matty: [00:38:55] Exactly. Move on down to the unlocked door. And speaking of unlocked doors, sometime we’ll have a security podcast where I tell the story about the time that someone wanted me to put PC Anywhere on our firewall. Like, the fact that you want me to do that is why you don’t have access to my firewall.

Tanya: So you’re like, am I allowed to fire you?

Matty: Yeah, you’re really my boss’s peer, but I can say no to you at least. So, but speaking of, instead of firing, And maybe helping people. Let’s talk about helping people. Let’s talk about the hashtag Mentoring Monday. So I see, uh, Tanya, I see you tweet with this a lot on Mondays, as implied. So like, what’s the story? What’s it about? How did it kind of get around? What do you do with it? How can people get involved?

Tanya: Um, I am a big fan of mentoring. I mentor a few people, and then I am so lucky as to have a few professional mentors who have been incredible for me and my career. And so, um, as I started blogging and doing more things, people would write me and say, can you be my mentor? I would say, oh, I’m sorry, I can’t, because, you know, I already mentor 4 women, and I literally feel I’m a crappy mentor because I never give them enough time, like never as much as I want to. So if I take on another one, then that means they’ll get even less time. So it’s not really fair. And like, they’re not, they’re not ready to leave the nest yet, if that makes sense. Right. Like sometimes you come to a natural progression where it’s like you’ve excelled past me, you know, go fly away and they need a more advanced mentor.

Matty: [00:40:27] Right.

Tanya: But I’m like, I can’t, I can’t. No, they’re not. I’m not dumping them. Right. So that stressed me out for a few months because I got a few messages a week like that and I wanted to help them so badly. But I’m like, no, Tanya, sometimes you must sleep. So I came up with this idea, like, I’m going to match people together. So I did this tweet and I put a thing on LinkedIn and it had like thousands of responses of people saying, I need a mentor in this. And then someone coming in and answering them and helping them. So then I thought about, like, well, what if I do this every Monday and I just share this hashtag? And some Mondays it’s more active than others, but there’s all these angels in the InfoSec community where they are searching this hashtag and then reaching out to those people that use it. So basically on Monday, Monday, whenever it is Monday for you, use this hashtag #MentoringMonday. And if you want, you can tag me and I’ll retweet it for you because I have a slightly larger audience than average. And if you’re a woman, I’ll retweet you from the WoSec Tweets account, the Women of Security group. We have a— so we’ll just give you an extra amplification amongst women. And people from InfoSec are coming out of the woodwork and helping so many people, and it’s beautiful. And a lot of people have asked me, like, oh, do I have enough experience to mentor? Like, you know what, the first time someone asked me to mentor them, I didn’t think that I did. And we— I’d gone to this like mentoring matching kind of speed date sort of thing for my OWASP chapter. And I was so surprised there was a lineup in front of me. I’m like, are you kidding? Like, don’t you know I’m the newest one here to security? Like, what are you doing? And they’re like, but you know more than I do. You know, you’ve done your job 2 years. One day I want to have the same type of job as you. You know, if you’re doing it 2 years and no one’s fired you, you must be good at it. So can you show me how? And yeah, so it turns out like I am good at certain things and people that want to be good at those things, I’m good at eventually, eventually in my own maladroit clumsy way, I get this across to them. Sometimes that means, you know, we do a talk together so they can see what it’s like to be on stage, or I review their abstracts, or I help them discuss which type of you know, career path they want to take. Um, and I also do like a lot of advocating for those. So if I’m speaking at a conference, I let them share a hotel room with me. If I can’t speak somewhere, I have this list of people where I say, pick one of these 10 instead, right? Like, I have all these people that are close to your city that know this topic, right? So I’ve been trying to like advocate for other people and help other people and kind of try to lift them up, if that makes sense. And so there are so many people in the InfoSec community who know amazing things. And so this doesn’t— this isn’t— Mentoring Monday is not just for information security. If you want to know Python, if you want to know how to write a blockchain or how to test a blockchain, or if you want to know, you know, like If I want to know what the blockchain is. Yes, exactly. If you want to start a startup, there’s, there’s so many different areas. Project management, code review, JavaScript. Just so many people have been coming forward and people will send me direct messages and they’re like, you know, I’m not exactly hacking. So is it okay?

Matty: [00:44:09] It’s okay.

Tanya: Everyone is welcome.

Matty: Whatever it is, it’s okay.

Tanya: Yeah, yeah.

Matty: If you want to learn how to be a firefighter, I want to learn more how to be a jerk. Like, that’s not okay. Yeah, no one’s going to measure you on being a jerk, but other than that, quite open.

Tanya: Yeah, exactly. How can I break the law?

Matty: Nope.

Tanya: But everything else, I’m in. You want to learn basket weaving? I will retweet you.

Matty: Fantastic.

Tanya: But it might be boring for you because most of my followers are, are info snack people, and that’s cool.

Matty: Well, you know what, unless you do that, you don’t know the Venn diagram overlap of like people into basket weaving and InfoSec people, because you never know, like that could even be a thing. So listeners, if you’re into basket weaving and InfoSec, please tweet @ArrestedDevOps and tell us all about it. Maybe we’ll do a whole show about it. You know, stranger things have started on this podcast.

Tanya: But I would like to appeal to your listeners that if they have worked in their industry for 2 years or more, that they can consider checking the hashtag and consider responding to someone. Because even just telling someone the first book to read, like, people reach out to me about DevOps all the time. And I’m like, you know, I can’t commit to a time commitment, but I can tell you, like, read The DevOps Handbook, read The Phoenix Project, then read Accelerate, and your life is going to be better. And why did no one tell me to read these the moment they came out?

Matty: [00:45:39] So basically, Tanya, you’ve just summarized my entire job. Is I tell people to read like those 3 books. But I do it in a conference room and I work for a company and they’re like, oh, well, now that you said this, so I guess I’ll go do that. I’m like, this is fantastic. I can just tell people. Yeah, it’s basically my job is telling people to read Accelerate. So thanks, Nicole.

Tanya: Yeah, thanks, Nicole. She reads the Audible book. So like they’re all on Audible and she reads Accelerate and she’s so awesome.

Matty: So yeah, it’s It’s funny because I haven’t listened to the audiobook yet because I’m not quite ready to have Nicole read to me. I’ve read the book, but I want to listen to it, but it’s also a little— I’m like, but Nicole, you’re like my friend. It’s weird to have like— I read to my kids, so Nicole shouldn’t read to me. But she should read to you. She should read to everybody. That’s my hangup, right? Everybody go buy the Audible book and buy the Kindle. Buy all the things. Give Nicole all the money. So that is the summary. That’s a great way to end the episode. Give Nicole all the money. And check out Mentoring Monday and help all the people. Speaking of speaking and stuff, if you are inspired to get up on stage and want to talk about things, Mentoring Monday can help you write these abstracts and stuff. But how can you find out? Well, if you want to talk about DevOps stuff, if you go to devopsdays.org/speaking, you’ll find all the DevOps Days events that have an open CFP right now, and you should totally apply to them. And jump on Mentoring Monday and say, I’m doing a talk for the first time. Someone help me write an abstract and we will help you because application and stuff. And speaking of that kind of thing, so Tanya, where can people— not that people should be like kind of trying to hunt you down, but where might people want to see you speaking? What events might you be presenting at in the near future where we could see and learn from you?

Tanya: [00:47:25] I’m going to be speaking at the Diana Initiative in Vegas as part of, you know, the many things that are happening during Hacker Summer Camp. I’m going to be at DevSecCon in Seattle in September. I’m going to be at LASKON in October. I’m going to be at AppSec Day in Melbourne, which is an OWASP conference. And I went to Australia earlier this year and they’re like, do you want to come back? Like, you had me at hello. And I think there’ll probably be some more announcements as time continues.

Matty: Awesome. People can find you on Twitter @shehackspurple. I’m sure you’ll tell us about all the places where you’re speaking and the adventures you’re having. Head over to arrestedevelopops.com/pushingleft to get this episode’s show notes. If you go to arrestedevelopops.com/itunes and leave us a review in the iTunes Store, that actually helps other people find the podcast. I’m not just shilling for reviews like, you know, Kotei thinks I am. This is actually a way to help more people find the show. So, Tanya, thank you so much for being part of the show today. I’m really excited we got to have this conversation.

Tanya: [00:48:34] Oh, Matty, thanks for having me. This was fun.

Matty: Absolutely. So I am Matty, @mattystratton on Twitter. This is Arrested DevOps, and remember, there is always DevOps in the banana stand.