MITRE + Cloud

**NOTE: Generated via ML. Expect crazy stuff to be translated by an imperfect algorithm that may have never actually been said by the host or guest :-) ***

[EPISODE]

[00:00:25] MC: MITRE Corporation. What is it that comes to your mind when you hear the word MITRE? Well, if you're like me, you think of either the CVE framework, or you think about the MITRE attack framework. Today, we've got a special guest with Tracy Bannon, who's been there for two and a half years. Maybe if you don't know everything that MITRE or does, but what they do is they face some of the biggest threats that are facing the nation here in the US and the world.

They focus specifically on solving large-scale challenges in cybersecurity, defense, health, aviation, and more. They have a single mission, which is solving problems for a safer world. In our discussing with Tracy Bannon, we are going to talk about all things cloud, including the topic of the day, zero trust, DevOps, and how you can bring about change in an organization and do it wisely. I hope you enjoy the discussion.

[INTERVIEW]

[00:01:25] MC: Trace, thank you for joining us today.

[00:01:26] TB: Hey there.

[00:01:27] MC: Let's just jump right into it. I wanted to start out with what for me was the most obvious question. What is MITRE?

[00:01:35] TB: I actually had that question when they knocked on my door as well. MITRE is a federally funded research and development corporation. They call them FFRDC. It's a cool concept. After World War II, the federal government realized, we need more technologists, we need more scientists. We're not always going to have them on our staff. Even though we are working with industry, industry is not always totally objective, which we understand, right? Industry is there as a moneymaker. FFRDCs are chartered to be the objective technology advisors to the US government and to your coalition partners.

It is a very different role than anyone that I've ever had. Yeah, I feel pretty blessed to have made my way here. You oftentimes wonder when you work with the government and you seem to have a trusted relationship, do they really trust me? I can say that as a human, they do. But there's always that little bit of, but are they trying to sell me something? Well, I'm chartered to be objective. I get to go into rooms and conversations that I never dreamed possible before.

[00:02:47] MC: Let's dig in a little bit more. I appreciate that, though, because honestly, I think I've enjoyed some of the output of MITRE’s work over the years, but never really understood that angle. I appreciate you giving us that frame of reference. Let's get a little more specific, though. What are some of the challenges that you are specifically studying, or that you're attempting to solve with your work at MITRE?

[00:03:09] TB: Personally, for Bannon, there are two areas where I am digging in the deepest right now. One of them is with software factories. Not what are they, as much as if we are going to implement digital transformation, lowercase DT, how do we do that? It isn't a matter of DevOps thing, or doing more agile. It means that there are those organizational constructs that have to change, mindset changes, culture pieces and security from soup to nuts, from vision to operational field thing. That's one of the places where I'm digging in. I work with the Army and the Navy and the Air Force from that perspective. Just started doing a little bit of work with what's called the DOD CIO. That's the Department of Defense's Chief Information Office.

The second place where I'm spending a lot of time is on data environments, data centricity. Think about this. ICAM integration, zero trust. This is whether I am working with US, something like CBP, Customs and Border Protection. They have a lot of information. There are nine or 10 different agencies that are involved. How do they exchange information and how do they do that in an exceptionally secure way, making sure that the owners of the data understand and provide the permissions to who is going to have it. There's this two different aspects of it, data transformation, and then this data centricity with zero trust.

[00:04:36] MC: Zero trust, I'm going to take the bait. You brought it up. It's such a buzzword now in the industry. Every vendor slaps it on every presentation. I've seen it all over. It was in the Biden executive order. Let's do two basics. One, how do you define zero trust? Is MITRE doing work around zero trust?

[00:04:56] TB: How do we define zero trust? For the broadest audience, if you think about the way that we used to architect our security for the enterprise, it was essentially a castle with a moat. We made sure that you had the right credentials to get inside. Once you're inside, you could navigate wherever you wanted to go. It was a free pass.

When I look at what zero trust means, it doesn't just mean swapping out a VPN. It means that once I'm inside, any place I go, any room I look in, any hallway that I walk down, any network, hallway is a network, I have to have a card key that validates at every step who I am and whether or not I have the credentials to get there. I mean, there are more. There are much more technical definitions of it, but that's a change.

We used to allow in our own enterprise two different services to trust each other, because they were insider perimeter. Well, we can't trust inside the perimeter, especially when we have transitioned from really huge, I'll use the trendy word, monolithic. Really huge capabilities to many, many, many different services, different APIs, different capabilities. When we're integrating that way, even within the walls of our own castle, we want to have that same approach, that same paradigm. We are always validating who you are, what data you're allowed to get out, and we're taking that down to the network.

[00:06:31] MC: Let me ask this. I know, again, vendors are talking about it, it's over the executive orders. Is this something that MITRE is looking at in terms of just trying to break apart, here's all the noise, but here's the reality. Do you guys get into, I guess, I would call it the, how do I practically apply this? Do you guys get into that angle of it? What does that look like?

[00:06:54] TB: Oh, we absolutely do. There are two different aspects to this. You have to be able to define it from a theoretical point of view. MITRE has those scientists. MITRE has the folks who can tell you very specifically from a theoretical point of view how this should be drawn, how it should execute. Well, then, it's how do you operationalize it? We absolutely have those folks, too.

MITRE gets involved and is a core part of this different standards bodies. We work with the DOD. We work with NIST and we work with IEEE in defining what those standards are. But then, I think, probably the more important part is being those agents that run ahead for the government and say, we'll build the prototype, or we'll work within your environments. Let us help you to get there. Here are the steps that you need to take to operationalize it, because it's not a recipe. It's no different conceptually than DevOps.

It’s not a recipe. It's not five things you got to do. It's understanding the principles and then applying them, being able to audit them, validate consistently that they're happening. MITRE does both sides of that. We have a number of I call them products, but they're really offerings, things that the government has paid us to do. You're probably familiar with the CBE database.

[00:08:08] MC: Oh, yeah.

[00:08:08] TB: That’s MITRE. That’s MITRE. It was fun to be taking a college course a couple of years ago, and the instructor is telling me all about CBE and I'm like, “I just learned about that, because I work there.” Of course, I kept that quiet, but it was in the back of my mind. I found myself very proud to find out about that.

A couple of other things. We have the ATT&CK Framework. You're probably familiar with ATT&CK. That is a very much a threat modeling. It goes beyond that to so many different dimensions now. You can even become ATT&CK certified, which is a strong thing. This is, again, the government providing capabilities to the rest of the government to do this. There are additional competencies. We have something that's called Safe. Not S-A-F-E, like the agile scaling thing. This is a security framework that allows you to pull in all of the different attributes and be able to look across the different attributes and to create those visualizations, so that you understand what's happening within your environment. Not in the operational side. That is on the build side.

Yeah, it's a firm with nearly 8,000 people. I didn't know that. I had met four people from MITRE prior to being courted by MITRE to come and join them. I was surprised. Our job is not to land and expand, right? That's what we do when we're a system integrator or a vendor. It's not a bad thing. We are businesses. This is different. Our job is not to land and expand. It’s impact. At all costs, it's to make impact. If it's one person, or a half of that person, it's really defined by the ability to keep the US safe.

[00:09:52] MC: I love that. I love that. As you mentioned, you've been involved with tech for many years. For a lot of those who are on the public sector side, and I know that one of your passions is developers. Let's talk about one of the things that's commonly talked about within security teams is, why do developers have such a negative reputation when it comes to security? Is it their fault? What's going on there?

[00:10:16] TB: All right, I'm going to let my bias show. It ain't their fault. Now, I say that, and sometimes it is. There's nobody without fault. There's never a developer that hasn't made a mistake. If we look at traditionally what happened, we had developers who were charged with creating against requirements. Often, those requirements didn't have quality attributes. They didn't have the non-functionals that included the security aspects. They weren't given instruction on secure coding. They had no tools at all. Yeah, they would make security mistakes within the code. They're not the only part of the security stack, by the way. There are a lot of other folks that are involved in security.

Then, as you were just about ready to go to production, all the testing had happened, there was one final scan by the security team, and that's where you would get a list of thousands, right? You would have all of these criticals. It became Hatfields and McCoys on who really was doing a bad job, or a good job. They had a negative reputation from that perspective, because people say, “Well, you gave me junk, or you made all these mistakes.”

Now, I went through a point where I was working as the enterprise architect for a large government agency at the state level. One of the things that I decided was that as part, I had multiple architects who were answering to me, and one of them I brought in was a security architect. He was working with the rest of the app arcs, was working with our data arcs. I said, “I would like to provide access to the scan tools, to the developers.” Oh, my goodness. Not only did they roll their eyes at me and like, “Oh, those developers, I’ll never be able to figure this out.”

The licensing structure wasn't there. The way that it had been thought about in purchase was there was two licenses for the security guys. It was not there for anybody else. It wasn't a part of the pipeline. It was very tenuous. Now, it was long fought, and I did get licenses that the team could choose. We can distribute them, because I wanted people to get that exposure. I wanted them to run it themselves as close as they could to the time that they were and learn from it.

I have to tell you, it was a it was a great experiment, and it was really, really valuable. I didn't stay there. I still. It's been a good eight, nine years since I was there. During that time frame, that has become more commonplace. We're giving developers tools. The other thing I would say is that we said DevOps and then everybody pretended that there was no security in DevOps. So now we say DevSecOps, because we have to make everybody feel better.

I'm a hater on the term DevSecOps, because it implies that it wasn't a part of the mix before. I'm okay if we add that phoneme in, because it makes people feel warm and fuzzy. We're just going to add Sec in there. Now, I know that DHS likes to say SecDevOps. I know there are others.

[00:13:10] MC: That always threw me off.

[00:13:11] TB: Oh, my gosh. Because that's where they want the emphasis.

[00:13:14] MC: Yeah. In public sector, I see that. I was like, “Wait. I got to make sure I get my acronym straight.”

[00:13:18] TB: Yeah. No, it just made – it is personal preference by organizations where they want the emphasis. I'm okay with that. Think about what that meant for the developers. When I say developers, these are software engineers. These are software architects that – as anybody who's part of that, really is part of the delivery team, who's trying to crank through creating those features in an effective way. Well, they're being asked to do more. Can you put more automated tests here? Can you learn how to do these additional types of automated tests? Oh, and by the way, we need you to make sure that you are watching the pipeline, the DevOps pipeline, along with that DevOps engineering team that's over there. There's a cognitive overload that is happening now.

I think that where people may have placed some blame on the developers in the past, they're learning it's not just the developers fault, but at the same time, we're now creating a situation that I'm fearful of. We’re loading everybody with too much. We're running too fast, and we're even running too fast with our security pros. I'm not one to say the security pros on the right and the dev team on the left. But there are fewer security pros.

When you look at some of the statistics on how many you have, oh, my goodness. It's tremendous, right? Then what is it? It's hundreds, or thousands to one when we talk about the number of security pros.

[00:14:45] MC: I saw a statistic and I'm going to round this out, because I don’t know the exact number. But I think (ISC)² says, there's 2.4 million cybersecurity professionals worldwide. Then the CNCF says, there's over 5 million cloud native developers worldwide. It's just like you said, it's a matter of magnitude, more developers than there will probably ever be cybersecurity professionals. There's just a mathematical challenge there.

[00:15:12] TB: What's interesting to me is that from my perspective and it's probably because of my heritage with the different types of programs and different types of clients that I work with, for a long time, it's been probably the last two decades, the majority of what I've focused on has been government. Not all at the federal level. A lot of it at the state level. Well, security's always been a part of that. I can't allow somebody’s child support records to become public. I have to protect everything at all times.

The fact that it's becoming more important strikes me personally as a little strange, because it's always been important to me. I understand, if you are in a different domain space, if you think everything is inside your walls, you are going to pay less attention to it, if it's inside the moat. Almost everything that I have worked on for the last 20 years has had a constituency piece of it. There was a domain crossing, right? There was a crossing the moat that I always had to be worried about.

[00:16:11] MC: In our sync up prior to recording the podcast, you said that – I was like, “We need to talk about this.” You said that you were anti-culture change, right? We were talking about in the context of DevOps, all those types of things. Wrapping it in to DevOps, what did you mean by that when you said that your anti-culture change as it relates to security and DevOps? What did you mean?

[00:16:35] TB: As you have probably come to realize, there's a lot in the semantics that matter to me, right? I talk about the phoneme and what that really means, because words matter. I suppose, this is being the daughter of a school teacher and a school superintendent that just has me very focused on what some of those words mean. If you come into my house, I invite you over for dinner and you sit down a table, and we're all chatting and you say to me, “You know what? You guys really need to change your culture.” I would be like, “All right, there's the door, bud. Head on out.”

We talk about culture change in that way. We're going to come in and we're going to somehow rejigger the mindset immediately. I don't believe that's possible with humans. We do have to have new mental maps. I usually use the word culture building, because we have to demonstrate the behaviors that we want, and then we will begin to build a new culture together.

It's not that we're going to come in and suddenly say, “Okay, everybody. Tonight for dinner, we're all going to start eating with our fork in the opposite hand, then that's the way that things are going to be. Or we're going to take a German approach and we're never going to switch our hands with our knives and forks when we cut.” You wouldn't say that. If you were at the table and you started to model a different behavior and the next night we invited you over to dinner again, and maybe it was that you poured the wine for everybody. The next night, maybe my son noticed that and he opts to pour it. That's a real positive behavior.

The next night, maybe you picked up your dishes and took them out to the kitchen yourself. The next night, maybe my husband did that as well. You're modeling behaviors and building a culture together. I know, it sounds hokey and the example sounds hokey, but it matters when we're talking about security posture. It matters when we're talking about how developers are together with security.

We are not going to suddenly change everything on a dime. Yes, I know there's a carrot and there's a stick, and we need to build that new culture together by surfacing that security's responsibility of us all. We have to understand how we can impact security. I mean, security as a big brushstroke word, right across everything. That's what I mean when I'm anti-culture change. Don't come in and tell me you're going to change this. Come in and help me to model what we need to do, and then let's build that new behavior set together.

[MESSAGE]

[00:19:07] MC: Prisma Cloud secures infrastructure, applications, data and entitlements across the world's largest clouds, all from a single, unified solution. With a combination of cloud service provider APIs and a unified agent framework, users gain unmatched visibility and protection. Prisma Cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan infrastructure’s code templates, container images, serverless functions and more, while gaining powerful, full-stack runtime protection. This is unified security for DevOps and security teams. To find out more, go to prismacloud.io.

[INTERVIEW CONTINUED]

[00:19:56] MC: Let's bring this down to a pedestrian street level. Tell us a story about modeling behavior from your experience. What does this look like?

[00:20:05] TB: Well, if I think about it as being the leader of a team and we have decided – I'm going to use an agile example for this, just to bring it home for modeling behaviors. It's new to us. We've had our 101 education. They've assigned us with a coach. I've got some pretty tremendous muscle memory. I'm not feeling it, but I'm the team lead, and so I'm vested in what those behaviors should be.

I've made a mistake in my code, and it comes to light in a more public way than what I'd like. I've stopped the build. The endline cord has been pulled. Everybody's crushing over to see what's going on, because I'm the tech lead on this. My model of behavior is to work together to fix it. It's not to take a begrudging attitude. It's not to feel defensive. It's to rally my peeps and say, “Okay, here's what I did. Oh, I see. Here's a better way to do this. How can we approach this in the future, guys? What can we do to avoid this another time?” Whether it would be a security flaw, whether it be a logic flaw. It doesn't matter, as long as I am publicly making a mistake and I'm okay with that mistake. Because we are human and zero defects is foolhardy. That's what I mean by modeling those behaviors. Be what you want the team to do.

[00:21:22] MC: I know that from stalking your LinkedIn profile that you've done quite a bit of work with Department of Defense, specifically surrounding the risk management framework, or the RMF. Where does cloud come into play with the RMF?

[00:21:35] TB: That's an interesting question, because – so RMF, the risk management framework is part of determining when a system can truly go into production. What happens generally is that you will define and design the system. Once you have defined and designed the system and you really have a pretty detailed understanding of all of the boundaries, all of the identities and all of the data flows, you’ll put together what's called a [inaudible] package. We'll put together this package of all of this information, and it goes to essentially, an auditing team, their security pros who are studying this and really understand, have you mitigated all the risks and addressed all the controls?

It applies whether or not you are cloud or not. My exposure to it has all been with cloud efforts. I would say, the challenge that I faced with this was trying to avoid it being a big bang at the end, because as I said, you have to have a pretty detailed view of what that system looks like. You have to have pretty decent understanding of all the flows. One of my projects, I think this is end of 2018, beginning of 2019 working with the Navy and fantastic group of folks. I thought, we’re running pretty quickly and there's going to be a lot of change as we go. Maybe I can invite those RMF folks to be a part.

I'm going to invite them to some early reviews. That way, they will not have as heavy a lift later on. I'm trying to shift our EMF left on my own and I will say that they made a noble try, but the first time they looked at stuff and said, “Well, this isn't complete.” I said, “Well, of course, it's not complete. That's why I'm showing you.” There was this why. Why isn't this complete? I don't understand. There was tissue rejection I will say, put it right out there. Epic fail. It did not work. We ended up coming at it in a more traditional way. But it was a short burn. It wasn't as though this was a two-year project and then we were working under what's called an OTA, it has to do with contractually — essentially, it's a critical prototype, or experimenting that you're doing that can then be moved forward and you needed to create those packages. 

There have been other folks more recently, like Hannah Hunt, who is coming out of the army. She works with Create, which is their software factory underpinnings. That is their digital platform. She is doing some stuff with this concept of continuous RMF. I don't want to bore people with that, because it gets really down into how much of this can we automate, when can we automate it, how far can we go with this? That's what that RMF piece is all about. It's absolutely well-intended, because somebody has to take ultimate responsibility for saying, “Yes, this is – that the quality and the security level that it needs to be to be in production.” Because we're talking about government stuff, especially with the Feds, pretty much want to make sure, right?

[00:24:38] MC: One of the things that's really driven, I think, some of the recent executive orders that have come out over the last year was the SolarWinds incident. We've talked about supply chain issues for years, but we're talking about the digital supply chain that really brought it to the forefront. Let's talk about supply chain security as it relates to cloud.

I was doing a little research here leading up to this and found that in a recent Palo Alto Networks unit 42 throughout report, their researchers found that 63% of third-party code templates used in building cloud infrastructure contained insecure configurations. 63%, the vast majority of that third-party code. When numbers are this big, are there tangible ways that organizations, public and private, can go about addressing security in the supply chain when it comes to cloud and open source? Is there a play for zero trust here?

[00:25:40] TB: Let's peel this back just a little bit. The study that you're looking at was talking specifically about infrastructure templates. I agree. Infrastructure templates are not the same as your production code, but they're in support of your production code. They're not necessarily compiled, or interpreted logic that's executing. It is still a challenge. There are efforts right now specifically on the government side to make sure that all of those configurations can – They're called configurations. They're called stigs. They are security controls. They define what those are, and they have to be pre-applied to any infrastructure, infrastructure’s code.

That's one thing that can be done is looking at a secure source to get any of your templates. If you're working on your home machine and you're toying around, you're looking to learn something, you download whatever you want to download. You go out there to whatever GitHub, GitLab, any repo that you want and go, “That's great.” We don't do that in the enterprise. We are very specific about what happens there.

The second part of that is getting into open source. When I say open source, some delineating between the infrastructure configurations and open-source libraries for a reason. There has been an effort for quite some time. A fellow by the name of Robert Martin has been defining what's called the sBOM. It’s the bill of materials, but it’s a software bill of materials. Been working with NIST. Been working with other regulatory agencies, other standards agencies to define this for a while, a way to simply express it to dependencies.

Imagine back in the day if I gave you a DLL, back when we used to give people DLLs. Oftentimes, that DLL would come with a number of dependencies. I would have to give you that bill of materials. We didn't call them that, though, right? It was manifest. I would give you the install manifest, and it would have all of those dependencies against it. The nature of how fine grained all of these bits and pieces are that we're using have made that much more difficult. Whenever we are using a library, whenever we're using open source, whenever we're using, even if it's not open source, whenever we're getting from a third party, we want that software bill of materials. There are tools right now that are available that will, in my IDE as a developer, keep track of those dependencies, tell me if there has been a change against them, but I can also automate that across my pipeline.

It is a very tangible way to start to deal with this. If I were going to recommend to people something “easy” that they can do today, if you're in charge of a software product, if you are in charge of a grouping of infrastructure, go make your dependency map. If you don't have your own dependency map and don't know what your dependencies are today, I would say, stop listening to this podcast and make a dash for where you can go and do that. It is surprising how many organizations don't have that. I do some work with commercial. I have done work with commercial for a number of years. I did some work with a mergers and acquisitions group. They bought nine different companies and brought them all together. One of nine, one of nine knew what their dependencies were. It didn't make sense to me.

Now, they also had very different technology stacks. They were actually multi-national and US. It wasn't related to government at all. I understood all the other variations and culture variations, but they didn't understand those dependencies. As we are looking to go faster, we want to get as more jumpstarts, right? It’s why we have Home Depot. It's why we have Lowe's. How can I help you to get a jumpstart, to get where you need to go? There are so many of those capabilities that are available to it, those very attractive to go out and pull it down. Sometimes we don't look, we don't turn the package over to read what the ingredients really are, and we don't pay attention to it.

Now, there are a couple of tools that I really like. One in particular is it is not a tool, it's a service. It's a little group called Tidelift. They're doing something cool. If I employed them, they would come and take a look at my dependencies. We would work through my dependencies. Then, they are paying attention to those open-source communities to anything that's happening there. If there is anything that impacts any issue that impacts my organization from that open source. They actually have a paid group of named maintainers that go out and fix it. You're not waiting for the goodness of the community, because that's another place where we get a little nervous, right? We get a little nervous like, so who is that person coming from that particular IP that appears to be off mainland China? Is just that the IP was bounced there, or who is making that?

All that starts to play in to this concept of understanding the lineage. Who made the change? Why was the change made? What are all the dependencies that come with it? That's not exactly the same as zero trust, but you can imagine that it's along the same lines. All of this has to do with no matter what it is, no matter whether it's an operational system, and I'm trying to route somebody to get to the data, or the compute that they need, or I'm building something that will eventually give somebody compute and data, I got to understand everybody that's involved in the mix; everybody that's involved in the mix.

[00:31:26] MC: Have you found in your experience that as both public and private sector organizations are moving to the cloud, obviously, phase one was lift and shift. People just move VMs there and they really got none of the benefits. As they've really started decompose their apps and using microservices, they've moved toward a cloud native approach. Have you found that that traceability, that dependency mapping, have you found it to be with the likes, so we mentioned infrastructure is code, we talked about using containers where they're declarative, things like that. Have you found that that is maybe it's a learning curve, but in the end, is that easier to do those things, because I can inspect it as code, or is there not really much of a difference there?

[00:32:10] TB: The tools that are helping. I'm not want to normally pound on the table and say, “Yay, we've got tools.” Because in the end, it's almost always a human issue. The tools are the fun part. The tools are starting to really help us. When we go to microservices architectures, if that's the right pattern for you, it may or may not be. When you are talking about more fine-grained components, we do have to be more diligent about what's involved. There are two pieces of it. One, developers or those folks who are stitching together all of those small pieces to make something larger, well, there's a lot of cognitive overload that comes with that. It’s actually more complex for the human to understand all of those different Lego parts than it sometimes is in looking at a larger code base, believe it or not.

The second piece, though, you brought up and is spot on, if I'm diligent and I have a set of checks and balances and I've worked that into my pipeline, my pipeline is my safety net. We cannot test in security. We can't test in quality, but we certainly can validate that it's there and we can audit it across that. It is the tools that will help with that. Microservices, containerization, I have a love hate for containers. I have lots of opinions, don’t I? My hate for containers is purely that it's a golden hammer. If I don't know what to do, I should probably put these in containers. Maybe we should and maybe we shouldn’t. I do think that provides us with the ability to have so much better isolation and the monitoring that can go with that isolation.

[00:33:49] MC: There's a lot happening in cybersecurity and with your role, with just the critical nature that is for our government. How do you personally stay current? What are you reading? What are you listening to, other than this podcast?

[00:34:02] TB: The Audible that's currently running right now, there are two. One of them has nothing to do with technology. It's actually a little bit of Russell Brand talking about his own journey, with trying to keep all of his things in life in order. It's called Revelation. It’s pretty great. I'm also listening to something called The Kill Chain. It is written by one of John McCain's second in command. I think, it came out in 2019, or 2020. It really talks about the state of how we got to where we are when it comes to the defense into what's called the defense industrial complex. My books, I've got my zero trust that I just went back through again, because we're talking to the author that's just –

[00:34:40] MC: Now, who is the author of that one? I'm curious. I couldn't say it.

[00:34:43] TB: This is Jason Garbis and Jerry Chapman.

[00:34:46] MC: You recommend that one then?

[00:34:48] TB: I recommend that. I actually have five that are in rotation, because I bounce between topics. My newest one that I have just cracked the cover on is called A Radical Enterprise by Matt Parker. It's more about how you deal with change in the organization. Remember, I said earlier about I don't like the culture change word, but how are we going to make that happen?

One that I am trying to get across to other people, so it's pretty dog-eared at this point is called The Software Architect Elevator. This is really, people have bastardized the name architect. It used to be, it had some assumptions against it. There became the Togath and the Dodath. Then we suddenly had the enterprise architect and then we had the data architect and we had 19 different architects, and then we had agile. All of a sudden with agile, we said, we don't need no stinking architect.

What's happening with architecture is that you have to be able to go from the boiler room to the boardroom and be able to carry concepts, be able to build alliances with people and carry messages. You also have to be able to go elbow to elbow when there's a problem. This is an O'Reilly book by Gregor Hope. The last one that I'll mention, and there are four – there are five of them here, is actually new to me. It's called People Before Tech. Yep, another one of these touchy-feely ones.

[00:36:07] MC: All right.

[00:36:08] TB: Yeah, yeah. It's by Duena Blomstrom. She has a company called People Not Tech, where she's using AI to understand how you build trust in an organization. It’s pretty cool stuff. I need to understand that, because if we want to affect change, we're going to have to deal with the technical part of it, but I also have to worry about those parts. Remember, I went into technology, because I'm not a people person and I don't like people, and all I'm doing is taking all my time with all this people stuff.

[00:36:42] MC: Now you've been at MITRE, if your LinkedIn profile, if I remember correctly, you've been there for about two and a half years. Is that about right?

[00:36:49] TB: Yeah, that's right.

[00:36:50] MC: I did check the website. On last check, you guys had 637 roles open. You're hiring. The question is, you've been there two and a half years, what's kept you there for two and a half years? Why should someone come and work at MITRE?

[00:37:04] TB: I'll start with how I've stayed here for two and a half years. I wasn't looking for my MITRE. They knocked on my door and I ignored them. I probably, for a better part of six months, I ignored them, because I wasn't looking. I had been working at Deloitte Consulting for almost 13 years. Had worked up at global levels, was leading a capability, a cloud native capability in the federal government area. Really happy.

My husband said to me, “How come you haven't picked up the phone and talked to these guys?” They're relentless, but they're typical. He said, “How did you get to Deloitte?” I said, “Well, they started calling me for about 18 months.” He said, “Precisely.” I picked up the phone and I had a conversation, a couple of conversations. I learned the things that I learned at the beginning of this. Where I'm going with that though, is that once I stepped inside, I got bit by what I call the mission bug.

I got to tell you, the first time that I went on to a Navy base and one of the leaders on the government side put his hands on the table and said, “You have to get these capabilities to the warfighter.” Look at me, I'm getting goose pimples now.

[00:38:12] MC: Goosebumps.

[00:38:14] TB: Because it's a different imperative. It's different than anything that I've ever worked on. MITRE’s motto is solving problems, right? It's about solving complex problems for a better world. That actually is their mission. That's what drives people to come there. I have never met a more altruistic group of individuals from that perspective. Why would I come to work there? Gosh, the emphasis on continuous learning, the research capabilities, the breadth across all of the different organizations of the government, if you want to be horizontal.

I work with Navy and Air Force, right? I work with model. I go into the civilian space. being able to look across to all of that and see a difference is tremendous and knowing. I think, that that would be the first part of why I came there and why I want to stay there. I mean, like everybody else. Everybody is looking for good pay in industry, good work-life balance overall. I would say, I travel less than I used to before the pandemic, but I joined right before the pandemic, so who knows? I told my husband the other day, “I don't know if I'll leave. Because how could I serve a lesser purpose?” It sounds hokey. I know. Yeah, it’s pretty cool. Pretty cool from that perspective. That's why you would come to work there.

[00:39:36] MC: Last question. If you could share one piece of wisdom with our audience, or maybe those aspiring to be in a role like yours, what would it be?

[00:39:45] TB: Be bold. Take the opportunities that come to you. Do not wait for something perfect to come along, because things change, in the same way that we see all of these different cyber issues that are coming along and they change. The face of them change. The face of your opportunities would change. Continuous learning. Make sure that you enjoy it. Because if you don't enjoy constant learning, this ain’t the right place for you. That's just it. This is not the right place for you.

[00:40:11] MC: Awesome. Well, Trace, thank you for joining us today. I'm really excited to see the interaction that we get once we release the podcast. Thanks for joining us today.

[00:40:19] TB: You betcha. It was fun. Thank you.

[END OF INTERVIEW]

[00:40:26] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com.

[END]