Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability and compliance on the Microsoft Cloud Platform. Welcome to Episode 100. This week, it's absolutely everyone here, so it's myself, Michael, with Mark, Sarah and Gladys. And we're here to sort of kind of reminisce and just go through things that we've, you know, sort of discussed and just look at our opinions on various aspects around the world of security.
So we're going to go through with some sort of questions that we have and we'll sort of round robin things between Mark, Sarah, Gladys and then me. So let's just kick things off. There's going to be no news this week because we just felt like this is an episode that can kind of stand by itself for a while. Hopefully we'll have some advice that people can use in here as well. Again, this is a very sort of practical episode back here, just looking at our experiences. Let's kick things off.
The first question we're going to raise is, so what got you started in computing or in security? So why don't we get, why don't you get going, Mark? Yeah, I kind of stumbled into both. Like I was always good at computers. And so I just applied for a PC job at a small college and, you know, that kind of got me started in computers and security for me was actually kind of an interesting one. Like I had some, I did a lot of work.
I've been at Microsoft like 24 years now and I did a lot of work mostly on the support side and the infrastructure side. The security was always like a theme on it. Like I was on the Active Directory team, right? When it first launched, actually, I got to Microsoft like the day after the big launch party. So everybody was telling me how cool the party was.
And there was this popular band from the 60s that had just performed and everything like that for the Windows 2000, SQL 2000, Office 2000, et cetera, launch party. And I got there the next Monday and they were like, oh, this was such a cool party. Did you guys? I'm like, nope, I just started. But like in that whole time, like I ended up doing a lot of, I guess, tangential security stuff. Like, I mean, the Active Directory team that we supported EFS, Michael, I'm sure you remember that one.
And certificate server and the security technologies got lumped in with identity because, you know, identity is like half security and half productivity anyway. And I did Windows XP baselines to get some approvals and whatnot as a consultant for some of my customers. I'm still at Microsoft, but for one of my customers. And so I've had security exposure throughout it, but I was doing management tools and Windows and stuff for the career.
And then opportunity came up to do cybersecurity, whatever, 10, 12 years into it. And I was like, let me try doing this thing full time. It seems like it's kind of fun. And I just kind of got the bug from there and got to learn in those kind of first customer facing teams. That was brought in as the infrastructure guy, not as a security person.
And I got to learn from some of these really smart people that started the MSRC and went on to run the Azure Red team and went on to be CISOs at different organizations. And so I just got a chance to kind of have a leapfrog ahead of where a lot of people were thinking at the time and got to work on the Pass the Hash white paper and stuff like that. So it was just like one of those things that I just happened to have a knack for and the opportunities lined up for me.
So nothing I can give people's advice to follow my path. But yeah, that's kind of what got me started. And for me, I really like it. I like hard problems. I like complex things. And I like reconciling different stuff because security is at the nexus of business, of technology, of attackers, international politics and diplomacy and economics. And there's so many different things that apply to it and offer lessons learned. It's like, I just love that kind of stuff. I love learning.
I love connecting the dots on stuff. And so that's what kind of keeps me going. I mean, there's a lot of hope in it that you kind of got to keep to keep your sanity. But yeah, that's kind of my story. Okay, so for me, well, I actually started, well, I should have studied. If anyone doesn't know, I have a history degree because when I was 17, I knew better. I was told to go into IT, but I felt like some kind of technology degree. But I felt like that would limit me to IT, surprisingly enough.
And when you're 17, you're very non-committal. So I did a history degree. I hated it, but I did finish it. And then I wanted to realize I wanted to do tech because it would let me move countries. That is actually pretty much why I went into it. But then obviously, I didn't really have any tertiary qualifications. So I just did help desk. So front line, first line help desk, which was very interesting. And I learned the amazingly weird things some people do with their technology.
Then I went into networking, because that's what the IT company around the corner from my mom and dad's house did. So I learned all my Cisco networking. I mean, expired CCNA, CCNP, et cetera. And then I ended up deploying a lot of phones all around Europe. I have deployed around 250,000 Cisco phones back in the day. So that was super fun. But then I moved countries. I went to New Zealand. And the company that employed me told me I'd be doing the same things I'd been doing before.
But when I got there, they were like, oh, hey, you're technical, right? And I was like, yeah. They're like, but we don't actually do what you were doing in the UK. So go help security. That's actually how I ended up in security. It was very bizarre, because they had told me that they did networking in Cisco and blah, blah. And apparently they didn't, but they gave me a job anyway. But that's probably a wonderful New Zealand thing more than anything else.
But then after I ended up in security, I realized security is actually really interesting and fun and there's a lot more going on. So I stayed and that was like over 10 years ago now. So there's so much going on. It changes. It's fun. I like talking about it way too much. I was on a flight back from Texas. So for anyone who doesn't know, Texas to Australia is a good solid 15, 16 hours. Ended up at the back giving the flight attendant a lesson on personal security, because that's how cool I am.
But I do, so I end up talking about it literally all the time and I do still really love it. Sometimes I know recently, if anyone follows me on Twitter, sometimes it can get a bit overwhelming I think. I had to take a social media break recently because I couldn't deal. But generally still love it. Not going anywhere for sure. And yeah, so that's me. I guess I'm going to show my age. Eventually there was a set of things that happened that got me into computers.
The first thing that happened is my parents bought me an Atari, right? And I started playing Space Invaders and all these cool games and I wanted to know how to make these games. So eventually they brought radio check type of computer. And this radio check computer, it was for my father to do accounting type of work with Lotus 1-2-3 back then. For those of you that do not know, that was the first type of spreadsheet software.
So I remember that my father was doing a lot of accounting work in there. He was going to leave to work and he looked at me and he said, don't touch the computer. This is very important. Don't touch the computer if you break it. There's a lot of important work from my business and from the company that he was working on. So what did I do? I did touch the computer. And actually I was playing with the BIOS and I changed some configuration and all the data disappeared and I had no idea what to do.
But I had until 5 p.m. to figure it out, right? And I got so nervous that I didn't try first to do all the steps backwards. I just started reading all the computer manuals and at that time I could drive and I went to radio check. I was 16 back then. And I started asking them questions and they couldn't answer how to bring it back. Anyway, I went back home and I kept reading and then I said, okay, let me see if I could I do the steps backwards if I get all that working.
And I did with 20 minutes before my father arrived and then I mentioned it to him and he looked at me and he kind of smiled, but I know that he was a little bit nervous and then he was checking his computer. Anyway, that led me to want to learn to program, to do programming and I wanted to study robotics. So what I did is I went to the university and the program that did robotics was in the electrical and computer engineering.
So I started a degree in electrical and computer engineering, but two years into the bachelor degree, the university didn't have enough students studying robotics. So they canceled the program. And what I did is I changed my major to computer science, which was programming. But during that time, I got an internship with Cox communication and I was supposed to be working in the engineering department.
They had this Windows NT 3.1 system and they said, well, you're a computer and electrical engineer major, so you're responsible for making this work because it keeps breaking and blue screening and this phase that it comes out. So you figured it out. So I had to start reading a lot of books into this operating system, ask a lot of questions. There was no internet. There were not that many people to ask questions about because everything was in Nobel.
For those of you that do not know, Nobel was a pre prior operating administrative operating system for networks. So I actually got certified in Nobel, then eventually got certified in Windows NT, not 3.1, but 3.5 and then 4.0 and then 2000 and so on. So throughout the work that I started doing, basically it led me to continue the internship and during the internship, I decided to teach others what I was learning.
And I remember in one of these classes, I was teaching Excel and there was this gentleman that came to me and said, Gladys, Gladys, look what I did. Basically he put colors in this table and did some functions, some basic stuff. But I always remember the brightness and how happy he looked. The brightness is in his eyes. And I said, this is what I want to do. I want to help others accomplish things with computers.
Anyway, eventually it led me to Microsoft and in Microsoft, one mentoring people that were teaching me about security and eventually I migrated to security. So it's a long story, but it shows the type of work it was doing. But I'm proud of it and I love the work that I'm doing. I continue to try to share my knowledge with others as much as I can. All right. Well, my story probably starts further back in time than yours, Gladys. So it all starts when I was about 16 years old, I think.
And I'm going to talk in New Zealand parlance here just because that's where it all happened. I bought a ZX81, a Sinclair ZX81, which had a Z80 CPU and it had 1K of memory. I ended up in the 16K memory pack, which was incredible. All that memory to play with. But I actually started writing games in Z80 assembly language, even trying to get them into 1K of memory. Actually, we were a small game, kind of defender-esque game in 1K of memory. That was all assembly language.
That then got me a job at a company in New Zealand called Grandstand who are representing Sega video games and Sega computer systems. So I got a job there working on their systems. And the reason why I got that job is because of the Z80 CPU. So I actually started just, you know, I picked up a manual. They gave me like a manual instruction manual on how the systems worked.
And within like a week or so, I'll be honest with you, the guy said, well, you know, do you know about this and that and the other on the Sega hardware? I'm like, yeah, sure, I do. I didn't. But I knew that I would know. I mean, just give me a week with some manuals and I'll be fine. So I was up and running in Z80 assembly language on the Sega's pretty quickly.
Grandstand ended up then taking on a brand, an English brand called Amstrad, which was owned by a company in the UK, by a gentleman in the UK called Alan Sugar. In fact, his name, the name Amstrad, actually derived from his name is Alan Michael Sugar Trading. And so they were Z80 CPU machines as well. So guess what? I was writing stuff for those things in Z80 as well. Amstrad then ended up bringing up bringing out PCs, which were obviously X86, not Z80. And so I ended up working on those.
And then Microsoft moved into New Zealand and I know, hey, do you have PC experience? Well, of course I've been working on these Amstrad PCs for a while. So I ended up getting a job. Actually funny, funny story. I actually worked for a company in between those two that actually represented Microsoft in New Zealand. And the guy that ran the company, he's since passed away, his name was Brian Erdly Wilmot.
So Microsoft came into the country and he gave Microsoft a list of names of people he could not approach. And I was on that list. When I found out that I was on that list, I actually resigned from the company with no job to go to. But then about a month I was working, I was working at Microsoft and I was working on Windows 3.x C compiler and C++ compiler support. Because actually a lot of really good software development was done at the time in New Zealand and still is.
So I was really sort of thick in the weeds with that stuff. That ended up getting me a job in Redmond, the Microsoft mothership, working on, it ended up being IIS, our web server, internet information services. And that was then bundled with, as part of NT4, I think it was the NT4 option pack. And that really, even though I'd worked on NT 3.1 and 3.5 and 3.51, I sort of really became embedded with the Windows NT team back at that point because I was working on the products.
And so I really got stuck into security, right? So I was really involved in security in IIS. But it's interesting, there's a really important inflection point there. I was hired into IIS as a security guy to work on security features, Kerberos integration, ACKL, SIDS, privileges, tokens, integration with certificates, TLS, well SSL back then, all that sort of good stuff, right? And that was okay.
But the problem was it had a lot of security features, but let's just say they weren't the world's most secure features. So I was actually the security PM for 3, 4, 5, and then for the start of 6. 3, 4, 5, lots of security features, but the designs and the code weren't exactly the greatest. And so 6 was a complete overhaul, in fact, its code name was Kevlar for that very reason. It was designed to be incredibly robust.
And it was a complete massive code change, massive design change the whole night. So I was very happy to be part of that. Then I ended up working in core Windows, working on security. Then David LeBlanc and I wrote running secure code. Dave, we gave a copy to Bill Gates. That was one of the many things that led to trustworthy computing. Computer led to the security development lifecycle, which I did with my manager at the time, Steve Lipner. Steve and I have a magnificent relationship.
He was my longest manager at 10 years and I was his longest report at 10 years. Really great guy. And so, yeah, so then I moved into the field because I was working in, I moved to Austin. And then finally I moved back to Azure data, well into Azure data and security. And now I'm actually in the secure future initiative team, which is a bit of a bit of a day job where it feels like getting the band back together. That's kind of my story.
I know it's a bit of a long story and I sort of missed a few important points out, but what's interesting is it's interesting how all of us came from really, really simple, humble beginnings. It's not like it's, it's not like we were born with a security spoon in our mouths. You know, we all sort of just fell into it. Michael, I have a funny story that I have. Well, I know you know the story, but I have to share it.
So when we started this podcast, I was living in New Zealand, which is another story. But my neighbor said to me, I was talking to my neighbor and she told her I worked at Microsoft and she said, Oh my goodness, you work at Microsoft. Do you know? And as we know, I'm sure we all get asked this a lot and Microsoft employs what 150,000 people, probably more now. So the chances of me knowing somebody is quite low, right? But you never know.
Anyway, my neighbor, my completely random neighbor in New Zealand was said to me, do you know Michael Howard? And I was like, I actually do. Do you remember Michael, the story that my neighbor is someone you worked with back at Microsoft in New Zealand? I do. I do. Yeah. It's a small world, especially in New Zealand. You know, there's a small world, but actually it's interesting to bring that topic up there.
This is something that I teach my kids and I'm a big fan of and that is just never ever burn bridges, right? Just never, you know, that person could have said, Hey, by any chance, you don't know Michael Howard, do you by any chance? Because if you do stay away from the guy, I always tell my kids like, just never burn bridges. It doesn't matter how angry or upset you are, just don't burn bridges. You have no clue if you're going to meet someone in the future, you have no clue.
So yeah, that's a funny story though. That is true. And in fact, Michael, my dad has said the exact same thing to me, though I'm sure plenty of people bad mouth Sarah. No, I joke. It's amazing how people turn up again, completely randomly, like where you need least expect it. So you're very right on that one.
Okay. So next question is, so I want to be honest with you when this question was entered by Mark, just saying, you know, it said, what are some of the worst blunders you've seen in security? And I immediately wrote after that, yikes, I don't think we can talk about that sort of stuff. So we're still going to keep that in there. And which is, so the question now is, what are some of the funniest stories or worst blunders you have ever seen?
So as soon as you wrote the question, Mark, why don't you kick it off? This is going back, I heard this like, oh gosh, probably 10, 12 years ago from someone and it was several years old by then. But this was in the very early days of cyber when attacks were much rarer than they are today. And there was this time where this guy got a call like, Hey, can you come in? There's like this really big DNS problem that and people can't get to this or that.
And it was like a Friday night or something like that. And so, you know, they, okay, whatever, you know, tell the kids and wife, you know, had you know, got in the car, head on there. And by the time they got to the office, it was fixed. And it was like, wait, what? And they dug into it, trying to understand it.
And you know, long story short, effectively, the attackers had gotten so frustrated with the broken DNS in the organization that they had fixed it for them so that they could get to the stuff that they wanted to get to. And that's how the attackers actually got detected. So I have no idea if it's true or not. But it's one of my favorite, one of my favorite cyber stories. Okay, so mine comes from very relatively early in my career.
And I wasn't even in security at the time, but I accidentally created a security incident, me and a few other people. We were told to do the wrong thing. This was one of those hosting things. This is when you know, before the cloud where people actually went into data centers and installed things. And we were given access to the wrong rack in a data center. And so we installed equipment in a completely different customers rack. This was like some major areas, of course.
And I was relatively junior at the time, and I ended up on a lot of these war rooms with some quite senior people who were, let's face it, coming on and swearing a lot and being very angry, because of course, we had to fix that problem. I was petrified because I thought I was going to get fired. But I did not because for us who had done the bit of work, we'd done exactly what we'd been told to do. We had just been told to do the wrong thing.
But it was a good introduction into how things can domino as in, you know, there was a mistake made further up the chain that basically culminated in me and some other folks making a big security issue. The best thing about that story was, without getting too specific, was that, which I think was my favorite thing about this, was that we had a number of data centers across in different locations in different countries.
And another party that was involved in it basically accused me and the other folks who had done the work of flying around to these different data centers in a 24-hour period breaking things, which we definitely did not do. And it was also a good lesson on finger pointing when things go wrong, when people need to save their reputations and or jobs. Probably more specifics than that, I can't say.
But it was extremely interesting and I definitely learned the value of having everything you do documented just in case. Early when I joined Microsoft, when I decided to get into security, Microsoft was forming this team of engineers that would go on site in order to deal with incident response. They were supposed to help customers basically remediate the issue, stop the attack, remediate the issue, start cleanup.
For those of you that are familiar with Dart, this is a team of engineers in Microsoft that are responsible for going inside a customer and help customers with incident response. This Dart team is a detection and response team. Well, this was prior to this team being formed. So I went to this incident. Eventually we were trying to clean up groups, trying to clean up permissions given to administrators and things like that. And it turned out that the company was using Active Directory.
And one of the issues in Active Directory is that you have the capability of creating groups and nesting all these groups inside of each other. Well, this company, what had done was created a group policy that gave permissions to everything to this particular group, which had a group membership so nested that eventually all users had administrator access to the whole environment. Hence, it was pretty easy for the attackers to come in.
I think that's one of the worst blunders that I have seen, but it was one that got me interested in security. So I have a story. This is with a customer and they had all these devices in the field that were incredibly important. That's all I'm going to say because I don't want to implicate anybody. And we're designing a threat model for their solution and looking at the designs and making sure all the correct mitigations were in place.
And one of the questions I asked is, so all these devices that you have in the field that are taking this critical telemetry, how do you authenticate them? And they said, well, what do you mean? How do you authenticate them? Well, how do you authenticate them? How do you know that they're the real device and not something else? And they said, well, we don't. Well, that's kind of really important. You really do need to authenticate these devices to make sure they're actually valid device.
And they said, no, we don't have to bother with that. So the next day, we had one of their guys come in and in front of management, we're looking sort of going through everything that we talked about. And they connected to one of their dashboards that showed all these devices, sort of the health of the devices in the field. And all the devices are turned off. Every single one was turned off. And of course, you know, they started panicking and I started smiling.
And I said, what are you smiling for? And I said, okay, I'll let you in. You're actually connected to my laptop right now. And I'm just mimicking the traffic from these devices. And basically, the devices are down. So when you connect, there's no valid traffic coming back from them. They said, well, how did you do that? And I said, well, the real reason that it's happening is because you're not authenticating the devices.
So I just did a bit of DNS poisoning so that you're just connected to my laptop instead. And back then, it was just a Perl script. Now, I'm really showing my age. It was a Perl script that was basically listening or pretending to be a server. So every single device, it was essentially, you know, the DNS entry was wrong and it was pointing to my machine instead and just giving it bogus data. Then they started putting in a plan to authenticate the devices. Pretty straightforward.
You know, one thing when we're building threat models, one of the questions we do ask all the time is, you know, when you're connecting to a server, how do you authenticate that thing? How do you know it really is the correct thing and not, you know, Baghdad Bob's server? I mean, how do you know that? And that's server authentication. By the way, the correct answer, 99 times out of 100 is TLS. Yeah, a lot of customers don't think about server authentication that much.
They think about authenticating the clients, only the users of the system. But you can't lose track of the servers as well. Next one. So, Mark, I'm going to kick things off again. Career advice. What you got? That's a good one. My thoughts on the career advice, and I'm thinking about this, you know, for people of all career levels, right? Just starting out, aspiring to security, all the way into, been doing it for a long time and seasoned. My number one thing is just to keep learning, right?
Because there's so much to cybersecurity, right? I mean, it's, I'm working on some standards for the open group, kind of defining like all the different roles in security. I think our current count is somewhere around 72 jobs actually have something to do with security, whether it's a direct full-time security job, kind of a half and half, like the identity and access and networking kind of teams that really you can't do enablement or security without it. Or, you know, CEO, guess what?
You manage risk and direction of the organization. That includes security of the organization, right? And so you're ultimately the one that's going to show up and talk to the press and do a press conference or whatever, or show up in Congress in the worst case. And so like, just there's so much to it. I mean, there's so many different roles that have so much work to do.
There's so many different technologies because you're talking about, you know, the attackers, they have the option of messing with anything. It doesn't matter if it's, you know, it's like Michael was saying, an IoT or instrumentation or sensor type of telemetry device, all the way into ancient level OT stuff, you know, that's controlling a steam-powered, you know, metal press or, you know, endpoints and servers and containers, codeless and serverless, oh my, just like the whole range of things.
And so there's like an infinite amount of things that, you know, you can learn and there's always some way that you can apply it to what you're doing. And that's like part of it. But the other part I think that the learning is super important for is, say you've been in security for a long time and, you know, you grew up a network in IDS and IPS and, you know, SIMs and whatnot.
Those technologies still work for the attacks that were designed for, but they're not going to be nearly as effective as like a modern day XDR or an identity-based thing. Like you can't block a password spray attack with a firewall or an AI attack with a firewall. Like you've got to be able to shift and learn the new stuff. So no matter how good you get in any given area, you've just always got to be open and flexible in learning.
So that's, I guess, my main advice is just always keep learning and keep an open mind. My career advice would be, I think particularly people early in career are super obsessed with certificates and proving on paper, I say proving in inverted commas, that they've got loads of security creds and stuff.
I would say that is important to a point, but I want to talk about one of my frustrations in the industry, which is we say how we desperately have a shortage of security professionals, which we do, but then it's actually very hard in practical terms for people to get into security at that entry level. And I know this because I hear it time and time again, and you look at like the proportion of jobs out there and it's way more skewed towards experienced people.
So I think that people who are trying to get into security can find it really tough. So the advice that I give people is it's just how it is. There's still sort of a prevailing mindset, like amongst some people at least, that you must have done some other bit of IT to get into security. I think it helps in some ways because you can go see how people mess up things, but I don't think it's 100% necessary.
Or what is necessary is to differentiate yourself, and I can tell you, as someone who looks at some early in career, like who looks at early in career, like resumes, CVs, whatever you call them in your part of the world, and I know this, and I don't want to disrespect anybody's tertiary education, but everybody's studied some kind of technical degree. Everybody's maybe done a couple of basic certs.
That doesn't differentiate you, unfortunately, because I have a hundred resumes that all say that kind of stuff. And so what I say to folks is please go and, if you're struggling to get a break in security, go and do more things. So what I mean by more things is you've got to differentiate yourself. So go to community meetups, go to the B-sides, the user groups, there's online ones as well.
Don't spend loads of your own money, like you don't have to, but go and make connections with people, go and contribute to open source projects. You may not have the money to travel, which not everybody does, but there's lots of things you can do from home that will differentiate you, that will help you stand out from the crowd because have empathy with people looking through resumes and CVs. They're often, 99% of them are extremely similar.
So that would be my bit of advice, at least for early in career people. So I'm going to echo Sarah and Michael, but I have a third one, I'm sorry, Mark, but I have a third one that I want to add. So first I'm going to talk about learning. When I first started in computers overall, I started programming. Then after that I was doing computer engineering, right? And I went to, I became network Cisco certified. I became network, previous operating system that I was talking certified.
I went into Windows, I did SQL, I did a SharePoint, I did identity, I did back then SMS, which was the SCCM or configuration management was the type of replacement or the product that replaced SMS back then. And that gave me a visibility all across different functions through the network. So when I came to Microsoft, I was like, oh yes, I'm awesome. I know all this stuff. When I quickly realized I didn't know enough, right? And I started working heavily and trying to study.
And it was, I basically was spending like 14, 16 hours a day, including weekends, trying to catch up. And there was this engineering person that came in to me and said, Gladys, you could work hard or you could work smart. Part of working smart is number one, managing your time. Not everything is about just the work that you do, but you having the time to give to other things. He said, have some openings during your week to allow for extra projects to come in.
At first I wasn't understanding what he was meaning. I kept talking to him and eventually I was working heavily Tuesday through Thursday, but my Mondays and Fridays, I had some time dedicated for training and I had some time just open. Because I went into events like networking events and even conferences, people started knowing me and saying, Hey, can you help with this thing? And including people in Microsoft.
So I started getting involved in more projects because I had the time allocated for nothing else, right? And that it just allowed me to grow and do more special things and learn even more and increase my network at Microsoft. So again, my advice, it will be learning, network and manage your time. That is not solely for the current job, but for opportunities that you could have in the future for growth. You know, I want to echo the first one that Mark mentioned about learning.
This is one of those industries where you can't stagnate at all. You have to keep learning. You just keep, you have to keep moving forward. So one thing I do is whenever I see something I'm interested in, I have a Microsoft to do on my desk, on my main dev box. I have it on a couple of my laptops and I have it on my phone. And basically whenever I see something, I paste it into the to do, Microsoft to do, and then I just forget about it.
Then every day I have, I think it's about 2.33 o'clock, I have a 30 minute block, which is learn. That's all it is. And then what I do is I spend that time and I go into my Microsoft to do, I look at, I pick something out of the list. That's all I do. I look at it. It may be of interest. It doesn't matter, but I learn enough about it to know that I don't care or I do care or I need more to learn more stuff that, you know, whatever. So I do that. So I really want to echo that.
You've just got to keep moving forward. And on the topic of learning, I think everyone needs to learn the basics of programming. I don't mean you need to be a super alpha geek programmer who can debug ARM 64 assembly language, which by the way, I'm currently learning. You know, you don't need to do that. You really don't. But at least be able to, you know, whack a PowerShell script together or a Python script together, at least be able to understand how coding can help you be better.
So I am a big believer in that. The very, very last one is write, write stuff. I'm not going to say write books, although writing a book is a very, very good idea. I mean, write blog posts, you know, keep it going. Just keep writing stuff. Put your thoughts down, your technical thoughts. You'd be amazed how useful that is when you're going for a job to show a body of work that shows real diligence. So I believe in those three big things. Write, learn the basics of programming, and write.
All right, we're getting close to the end now. Where do you want to see the industry going? Where do you see the industry going over the next few years? I'll pick an optimistic tone, right?
Because there's plenty of cynicism you can throw out there on sort of we spend way too much time writing the same control standards over and over again, and way too much time like trying to change out tools as if the slightly better tool from a slightly different vendor is going to make a massive difference in how things work, right? We have just those normal headwinds, right? Because we're just, we're new, right?
We're not, we're what, a couple decades into this thing, like two, three, four decades, you know, depending on how you measure it at most, compared to centuries and millennia of building buildings and roads and everything else. I think the big thing is just we're immature.
And so the thing that I see is I feel like we're getting to a point now, especially if the zero trust thing sticks and people stick with it long enough to sort of get it, that like having this practical view of security is going to get us to a place where we can finally get to, you know, in the, in the maturity model, maturity model parlance, you know, defined, we can actually say, this is what security, this is what good looks like in security.
And this is, you know, and this is how it should work. And everybody knows that this is their part, their job in security.
And so I really see it going into like a little bit more of a professional thing, especially, you know, I mean, when you, when you look at some of the, some of the big incidents that are affecting business and organizations finally sort of get their head around and it's no longer like a fear, uncertainty, doubt type of conversation with the security teams, but it's actually a genuine partnership thing.
I just, you know, I see us becoming more normalized as security, I guess, is what I hope that it just becomes part of how everybody thinks about things like, you know, and we can have a basic security conversation with anyone in the organization and they'll be able to, you know, the security people have a basic business understanding and then the business and tech teams will have a basic security understanding. Like that's, that's kind of where I hope it is.
And that, that really unlocks for the next generation of goodness where people can work together and bring different ideas together. So that's just like my own personal view and hope. Where do I see the industry go? Where do I want the industry to go? I would like us to continue to try and be more inclusive. I think we're going in the right direction. We've got a long way to go. Let's be realistic about this.
Something that is a personal bugbear of mine is that I think if you are not, if you are what considered diverse is, you, you know, whether that's gender, ethnicity, whatever, I still think a predicator of whether you will last a long time in this industry is that you need to be quite resilient and thick skinned, which is not the way it should be more so than your average person at work, I'd say. So I hope that we continue to work on that.
I think it's going to be a very slow piece of work, but you know, there are a lot of efforts to try and fix that. I also just want, I want to see, and we're going in this direction already. I want to see the gatekeeping stop as well. So what I mean by that is not the gatekeeping so much within the industry, but I think it's the industry talking to the rest of IT and the public. Well, you know, a lot of people are like, ah, security, this is very complicated.
You won't possibly understand it, blah, blah, blah. When in fact, I think anybody can understand security, at least at a high level in, if it's explained in the right way. And I think that's really important because people are not going to lose your job if you educate other people in the org a bit more about security. And well, if you, if you're worried about that, then that says to me, you're not good enough at security to start with.
And we need to become more collaborative with the rest of IT. This is a massive rant, so I'm going to stop there because we'll be here for a long time. But we need to accept that other people knowing at least a little bit of security and knowing some security basics in the wider IT org and in the world is not going to mean that we run ourselves out of a job.
As I analyze everything that is happening, basically every, almost every day, there's a major hack, a major data breach happening all across the world. And all this data is going somewhere, right? And AI is coming heavy into place. Quantum is coming heavy into place. And I just start thinking, okay, when all this is put together and all this data from the different data breaches are brought together, they basically will know everything about us.
So, I'm hoping that in the future, I know that we're working toward it. There's intra-verified ID and Microsoft intra-ID is doing a lot of things, but better ways to identify the people in order to make sure that people do not lose their savings. There's things that they have worked heavily for because I keep hearing and seeing all these institutions that use voice recognition in order to authenticate you. And I'm like, okay, AI can do this and things like that.
And then I start thinking, okay, how are my kids going to be able to just protect their money, their resources if this is not solved? So again, I think we are going through there, but there's a lot of work to do. And I think that's the place that I want the security to be improved the most. I have a hope, I think, and that's, I really think we need to see much more work being done in academia around what it takes to design and build secure systems.
Look, I'm going to be honest, this is a conversation that I've had for 20 plus years and there seems to be very little work being done. We hire kids out of school and they just don't understand the fundamentals. I'm not going to say they need to be cybersecurity nerds, but just at least understand some of the basics. And I think that's a bit similar to what Sarah said, but unfortunately we're just not. And so, don't get me wrong, there's a role for industry to educate people.
Absolutely there is, but there's also a role to be played by academia. I still don't see that being done. I've heard people say, well, that's not the role of academia. Okay, we can have that philosophical debate, but personally, I believe academia has a big role to play. All right, we're getting very close.
We've got the last question now, which is a very simple one, which is what are some of the behind the scenes memories or just something you'd like people to know about what we do on the podcast? I'll kick this one off because, and Michael, I'm sorry about this one, but on the very first episode of this podcast, I remember for whatever reason that day, Michael could not say the word security. It is absolutely true. I think you tried it like six, eight times before you got it right.
It was hilarious. I do not understand to this day what the heck was going on there. I mean, were we talking about like accents between New Zealand and American or something or whatever? I mean, something had to have messed your head up because you just could not get that word out. I mean, you know, a word I've been saying for a long, long, long time and I couldn't get it out of my head. Yeah, it's crazy. I can say the word security. I can say it, but Michael definitely can't.
And there's also some guests names you haven't been able to say as well. Yeah. Ryan's name. I'm not going to say the last name because I will get it wrong. But if you go and look at, right. Okay. You say it, Sarah, because I'm not going to say it. Thank you. If you go to the... I thought it was Markababad. Markababad. Oh no. Oh no. Ryan's going to... Ryan, don't listen to this episode. Okay. I'm going to make sure Ryan hears this. No, in all seriousness, there is an outtake. It's on the website.
I'll put a link in the show notes to it, to the actual episode, because it is actually kind of funny. But yeah, I could not get her name wrong. That name, right? Yeah. It was pretty embarrassing. Talking about outtakes. I mean, you've never done this, but Michael, do you want to talk about how all the outtakes are literally my therapy sessions without going into the specifics? That's what I was going to talk about. I was going to... I look forward to those.
Yeah. The first 10 minutes of every single one of these things is all Sarah talking about what she needs to talk about. Yeah. And it's just for those listening, it's a running joke that this is basically just Sarah's therapy. I just have a lot of things to talk about, usually not to do with security.
Well, actually it's an interesting one because something that I learned from an impression I give sometimes to people, not that you would hear this on this podcast because Michael cuts it all out, but sometimes people think that I don't actually care about security that much because I like to talk about everything else as well as security.
But the answer to that, and it is good feedback for when I am in business context and we have a time limit, but the answer to that is I just like to talk about everything quite a lot and I have a lot of stories and I'm a terrible oversharer. I'm working on it. I'm working on it. Actually, those again for the listeners, we do have a couple of rules of thumb with this podcast just so you know. The first one is try to keep it 200-ish, 300-ish level. That's number one. Number two is no cussing.
This is a family show. And then the third one is don't break into jail. That's actually been my philosophy for a long, long, long time. Be careful what you say. The last thing you need is to literally break into jail. So yeah, it's one of the mantras of the podcast. One thing I do want everyone to realize because I understand why people do this, but people have said, hey, you guys have been a little inconsistent sometimes on getting the episodes out and that's absolutely true.
We try to go for every two weeks. Sometimes we just can't do that. This is not anything that we do as part of our jobs. This is something that we do because we enjoy doing it. Honestly, I'm really amazed that we've been going since the end of April 2020. I think it's amazing. We've got an incredible sort of listenership way beyond anything I ever expected. But yeah, just do be aware. We do do our very, very best, but I do all the audio editing as well as the website.
And Sarah and Mark and Gladys also get people together to start farming around, to get people to join the podcast. We don't have any problems getting people on the podcast. Everyone loves coming on the podcast. Sometimes work gets in the way, life gets in the way, vacations get in the way. It's not like we have some hours set aside every week by our management to do the podcast. It really is a labor of love. I can probably say for everyone that we just thoroughly enjoy doing this.
It's a lot of fun. We get to meet a lot of awesome people. We get to learn a lot of things from a lot of people. That's probably another bit of advice for people is grow your network. I forget who someone touched on before, but do grow your network. And honestly, I was doing the podcast, we're all growing our own personal networks as well. So now I know who to talk to about specific issues, which is always a useful thing. So let's bring this episode to an end.
Thank you so much, all of you for listening. As I mentioned before, this is episode 100, an amazing milestone and I'm so proud that we've met this milestone. Do continue listening. If you have any comments, send them our way. If there's any topics you'd like to cover, again, let us know. So again, everyone out there, thank you again for listening. Stay safe and we'll see you next time. Thanks for listening to the Azure Security Podcast.
You can find show notes and other resources at our website azsecuritypodcast.net. If you have any questions, please find us on Twitter at Azure Setpod. Background music is from ccmixtor.com and licensed under the Creative Commons license.