STRATEGY THROUGH ARCHITECTURE

Kip Boyle: 

Hi, everyone. This is Your Cyber Path. We’re the podcast that helps you get your dream cybersecurity job, and I’m Kip Boyle. Wes Shriner is here. We are experienced hiring managers of cybersecurity professionals, and we want to help you get your dream cybersecurity job. 

You can get this episode a couple of different ways. We’ve got an audio-only version, just grab your favorite podcast listening app and look for us there, Your Cyber Path podcast. And we have a video version, which you should check out on YouTube, because we’re actually showing some visuals here that you’re going to want to see. You can download those visuals as well if you hit the link in the YouTube video description.

So if you haven’t been here before, we’re in the middle of a long series, and it’s a series that’s designed to tell you all about the ways cybersecurity organizations are put together, in a pretty large organization. And we’re doing this so you can understand what the opportunities are out there. There are a ton of opportunities, but if you don’t know about them, then you can’t aim for them. 

So today, we’re going to talk about a service that’s called security, strategy, and architecture, and we’ve got a service catalog that we’re going through, episode by episode, and this is number 10 in that service catalog. We’re going to show you the place mat here in a moment, if you’re watching us. And today, we’re going to explore this service with the help of our guest, and our guest today is Peter. But before we meet Peter, Wes, do you have a farm story for us? 

Wes Shriner:

Oh, it’s good to be here, Kip. It’s been a good week on the farm as well. I need to call out that this week was a special week in our house. It’s not an animal story. This is a people story.

This week, we celebrated Easter in our house, but in doing so, I need to explain that our family has five children. And of those five children, we’ve made two, we’ve adopted one, and we have two foster children in our house that have been with us for a couple of years. We have over the last many years, built a relationship with our adopted daughter’s maternal grandfather. Okay? 

And so this weekend, for the first time, we were able to invite Grandpa Leon to come from Texas up to Seattle, and spend a week with us, living in our house and being a grandpa to all five kids, not just the one that is his granddaughter. And it was a world-class, phenomenal experience. You could see an eight-year-old looking in the eyes of her biological grandfather, and seeing herself a little bit in that history.

Some of my favorite parts was nobody was stressed about whose role is whose, because it’s okay to be a grandfather to one and to five, and it’s okay to be a dad of one and to five, and there was a beautiful respect that happened with the grandpa and I’m just really proud of it. It’s just one of those weekends that will be remembered 50 years from now. It’s one of those weekends that this eight-year-old, when she’s 58, will be telling her grandchildren about the time she got to spend the weekend with her biological grandfather.

So what a special weekend it was. Thanks for asking. This was [crosstalk]- 

Kip Boyle:

Yeah, that’s great. Doesn’t always have to be about the animals, although the animal stories are funny, Wes, to be honest. 

Wes Shriner: 

Ah, they’re good. They’re good. [crosstalk]- 

Kip Boyle: 

But this was a great one, thank you. I’m glad you shared that. 

Wes Shriner: 

Yeah, it was a good time. 

Kip Boyle: 

So there’s my buddy Wes architecting amazing human experiences in addition to- 

Wes Shriner: 

Wow, look at that! 

Kip Boyle: 

cybersecurity solutions. Well, let’s introduce Peter. Wes, tell everybody about Peter, would you? 

Wes Shriner:

Well, I would like to. I think his name is Peter Gregory. He goes by Might Be Peter. You can also find him as Peter H. Gregory. Here’s our slide on Peter. He lives in Central/Eastern Washington. We call it Wenatchee. That is the heart of apple country. Peter can be found on LinkedIn as Peter H. Gregory. He’s also got his own Wikipedia page. 

Kip Boyle: 

Have we had a guest with their own Wikipedia page yet? I don’t think so. 

Wes Shriner: 

If we did, we haven’t called it out. 

Kip Boyle:

We didn’t know it. 

Peter Gregory: 

You’ve got to get some better guests, guys. 

Kip Boyle:

Come on, we’re trying to level up right now. Geez. 

Wes Shriner: 

Well, Peter has written probably 50 different articles or books in the security field over his career. He has written, written, written. And he’s also done the work. He’s currently at a telcomm company. He is on the security board at University of South Florida and University of Washington. I’m sorry, I should have done that in reverse, because we know the University of Washington is a better university than South Florida. 

Peter Gregory: 

You saved the best for last, Wes. 

Wes Shriner: 

There you go. 

Kip Boyle: 

We all know that. 

Wes Shriner: 

A co-founder of the CISO Forum, and a big contributor to advancing the state of the art, with many of the C-ISAM, CDP, PSE, and the CISA how-to books that become the canon for understanding those disciplines. Peter, tell us a little bit about yourself. 

Peter Gregory: 

Well, let’s see. I’ve been in technology longer than I’m going to admit here today. But my pivot into cybersecurity started a little over 20 years ago. In the late 90s, I was at AT&T Wireless doing IT architecture operations in a secret, Skunkworks startup inside of AT&T Wireless, and security was really, really important to our executives there. 

And they tagged me with making sure that cybersecurity was the best it could possible be at that time. And I enjoyed doing it. I found through some events and incidents over the next couple of years that I seemed to be pretty good at it. 

Kip Boyle: 

Well, that’s a great mandate to cut your teeth under. 

Peter Gregory: 

Well, and I got good at it because I had a really good foundation in TCPIP networking. I knew operating systems, internals, Unix mainly. Windows, eh. Windows was not impressive in those days, but I knew OS internals. I had been a software engineer. I had worked with relational databases. So I had a lot of practical experience in a lot of things in IT. So cybersecurity came fairly naturally to me. My first job title with security in the name was in late 1999, and I haven’t looked back since then. I’ve had just marvelous opportunities to grow and learn new things.

Kip Boyle: 

I think there’s a takeaway there, [crosstalk] Wes, right? Because Peter had experience in technology before he crossed over into cybersecurity, right? And that’s really, really common. 

Wes Shriner:

It’s [crosstalk] actually really, really valuable as well, as my understanding. Peter, did you find, is that table stakes for a lot of folks who want to step into an architecture role in security? 

Peter Gregory: 

It really is. The two reasons why you need to have a solid technology background going into IT security, first of all, IT security is called IT security. So you need to know the IT part. 

People who are interested in getting into any IT security role need to understand how does the technology itself work? How can you possibly understand an attack in detail, or how to build defenses in detail if you don’t understand the technologies in play? It just doesn’t happen. Now, that’s not to say that you can’t be successful without an IT background.

But if you’re lacking in an IT background, then your career opportunities are going to be more limited. You probably could still do okay in third party risk management, or risk management in general in a larger org, where your lack of a solid technology background is compensated by others on the team who do have that background. But in a really small organization, the security people have to be really solid in the tech. 

Kip Boyle: 

Yeah, yeah, that’s right. But just to be clear, we also know that if you want to get into the cybersecurity industry, and you don’t have a tech background, there are some non-technical jobs that you can go for, if you’ve got some transferable skills, right? And I don’t really want to drill into that in great detail. We’ve talked about that in other episodes, but yeah. That’s great. 

Wes Shriner:

This one is security architecture, and we’ve got our expert on the line. So let’s jump in and see what we can find. To remind you, this is the 23 common services of a security service catalog. Of those 23 common services, you can see they’re split between the governance risk and compliance. The product security space, the security operations space, and then the engineering, architecture, and test. Today, we’re going to be focusing specifically in that top right corner for security strategy and architecture. 

Kip Boyle: 

This is our place mat. 

Wes Shriner: 

That’s number 10 on this place mat, yep. And that’s where we’ll be. Jumping ahead, actually, yeah, we’ll go ahead and jump ahead and see where we go. In the security strategy and architecture discipline, there are generally three different types of security architects. Understand, I’m trying to nail a gummy worm to the wall right now when I say there are three types of security architects. But if you can see that the uniqueness of each of these three, you may find that you’re putting on all three hats in a given day. Or you may find that you want to focus in one of these areas, and grow your career. 

So let’s take a look. The first one on the left here is the enterprise architect security. That enterprise architecture security focused individual reports usually into IT with a dotted line to the security organization. They’re focused on security support of the business strategy. To be clear, I said business strategy, not technology strategy. This can be as much a business architect as a technology architect, and it integrates security with all disciplines. This is not isolated only to security, and in some cases, that EA is responsible for more than one discipline, more than just the security discipline, but might have several disciplines there that they represent at the Architecture Council. 

The second one, and we will go in deeper on each one of these on the future slides. The second one I want to call out I’m going to call the security strategy architect. That strategy architect is one who works closely with security leadership, focuses on the business side, on the business of the security organization, that plan the security organization for three to five years ahead, and they build a reference architecture for capabilities the security organization is going to deliver against. 

The third column to the right there is security solution architect. Now, this is probably the hardest one to define. Think about this person as working with business units, or specific pillars within your organization. They work closely with those business unit leaders to design each security solution. They might even build a road map for that business unit for six months to two years ahead, of which security features we’re going to prioritize, and how we’re going to work together to secure the product base that this unit delivers. And they’re going to be focused on security strategy in every design. 

Kip Boyle: 

Before we put the slide deck together, I didn’t even really in my own mind separate out that there’s three different types of architects. Let alone a fourth type, which you mentioned at the bottom of the page, and just want to say to folks that if you’re not working in a large enterprise where there’s actually four different seats, then you might see people wearing more than one hat.

Wes Shriner: 

And you should. And you should. In fact, if you’re doing these roles and you find that you’re the one wearing those hats and you don’t have an opportunity to do some of one of these three, that’s a great place to grow. 

Kip Boyle: 

Mm-hmm (affirmative). 

Peter Gregory:

I’d say in a lot of organizations, all of this is one person. Until you get into- 

Wes Shriner: 

Very much so. 

Peter Gregory: 

security orgs that have say, more than 50 people- 

Wes Shriner: 

Agreed. 

Peter Gregory:

this would be one or two people sharing all the things here. 

Wes Shriner: 

Agreed. I’m going to call out that fourth type of architect. That’s actually covered in our service catalog number 11, and think of that as more of an engineering and architecture-type role. It’s very tactical. Very operational. Very much hands-on for every IT change that happens in your organization. 

It’s specific to, “Wait, you want to do what?” I believe is the phrase that most often comes out of their mouth, and we’ll have an opportunity to look at them in greater detail in service catalog item 11. So for now, we’re just going to smile and wave and stay focused on the three roles of architecture that are here across the top. 

Kip Boyle: 

Yeah, I can’t wait until we get to another episode, where we get to talk about Dr. No. 

Wes Shriner: 

No, that is not what we are. We do not put the no in technology. 

Peter Gregory: 

Wes, to your point about the solution engineering and architecture of, “You want to do what?” I mean, that’s in better companies. In other companies, it’s like, “You did what?” Right? 

Kip Boyle: 

Good point. Yeah. 

Wes Shriner:

And that’s your software development lifecycle. We’ll get into SDLC in the future, but for today, we’re jumping ahead. This specifically is the enterprise architect. We’re looking at four different pieces. You can see there’s a graph on our screen with four different corners. In the top left, we’re talking about what the position is. The top right is what that role creates. What are the primary deliverables? 

The bottom left is what kind of behaviors do we often see from that person? And then the bottom right is the success criteria. So let’s take a look at the enterprise architect focused on security who maybe dotted lined your CTO or CIO, and sits on that architecture council. That person is creating architectural axioms for the organization, directional big ideas that may not be directly translatable to tomorrow’s project, but will guide what we’re going to do for the next five years of our organizational direction. 

Kip Boyle: 

And isn’t that why this person is always being accused of talking in such sweeping generalities, that nobody can understand what they’re saying? 

Wes Shriner: 

They’re accused of that. They’re also accused of taking over meetings and talking about ideas in the clouds, or rabbit trails. What are we doing? Come on, we got to solve problems and make decisions. No, no, no. We need to talk about the theoretical opportunity available to us. 

Peter Gregory: 

Yeah, well, their heads are in the clouds, in many ways. And their tool set is our point. 

Wes Shriner:

It is, and they’re talking about quantum encryption. How do we do quantum encryption? If you’re asking about quantum encryption, you might be interested in the enterprise architect security role. 

Peter Gregory: 

Yeah, true that. 

Wes Shriner: 

The behaviors of this person might be tracking industry thought leadership. They might read a lot. They might drive organizational goals, and they might be pretty responsive to risk management.

If we’ve got a huge risk in one area of our business, they should probably be paying attention to area and helping us shore that up with some big ideas that might change our whole paradigm for how we look at that risk, and look at that business. These folks are going to know their technology, they’re going to know their business. They’re going to know security, and they’re going to be able to create trust with those they advice. This is a trust role. 

Peter Gregory: 

It’s very much an influencer role as well. I mean, they’re not really influencing tomorrow, and maybe not even next year, but they’re influencing the year after that. So they really have to have good relationships with business leaders, who need to be willing to share their visions with that enterprise architect and others, so they can be sure that whatever the business wants to be doing in a couple of years, that the tech will be there, and that the tech will be safe. 

The security that needs to be there will be there, and not through last minute planning and scrambling, but through long-term thought and consideration. 

Kip Boyle: 

These are the big decisions. 

Wes Shriner: 

These are the people reading white papers. These are the people who are getting patents with their hobbies on the weekends. 

Peter Gregory:

Yeah, they’re not just reading them, they’re writing them. 

Wes Shriner: 

[crosstalk] Had you known anyone who was successful in a role like this, and can you think a little bit about what they brought that helped them be successful? 

Peter Gregory: 

Well, just very broad, very broad technology, knowledge, relationships with like-minded people in other companies, relationships with futurists, even. Because they really have a task of applying some degree of imagination to help form the technology of the future in that business. In some companies, security- 

Wes Shriner: 

These are the people who imagined we may all work from home, as remote, at some point. These are the people who imagine we may never need passwords again. 

Peter Gregory: 

Yes, and yes. And other things like that, and to whom that quantum crypto is not necessarily a threat, but just another opportunity. 

Wes Shriner: 

Indeed, indeed. All right. Let’s see what we’ve got on the next security architect. This is the security strategist. This person reports into the security leadership. They’re usually building a three to five-year roadmap for what the security organization can do today, and should do tomorrow. They’re doing an internal assessment of what are we good at, and an honest assessment of what can we improve on. When they’re building a reference architecture, they’re building it for the security business as, “What are our capabilities as a security business, and what do we want to be able to be capable of next year, or the year after?”

They’re probably looking at the business continuity disaster recovery plan, and saying, “We want to shore up this area before we have a pandemic and all have to work from home?” Or something like that. Probably won’t ever happen. 

Kip Boyle: 

And they’re the ones that are identifying [crosstalk]… Sorry, Peter, I didn’t mean to talk on you. But I was going to say, they’re the ones that are deciding what’s the relative importance of identity, as compared to some other thing like digital certificates and where are we going to invest our limited research and development budget? Which one’s more important? So it’s about developing new capabilities, just like you said, Wes. 

Wes Shriner: 

If your organization has a hard shell and a soft center, it’s these guys who need to fix it. If you’re not treating identity as your new firewall, it’s these guys. If you don’t have people talking about an internal threat as your most likely threat, or even if you don’t have a phishing capability at this point, it’s probably these guys who didn’t prioritize that yet. Or how [crosstalk] do you use zero trust architectures, or zero trust networks? 

Peter Gregory:

Or even what happens after zero trust architecture isn’t the new thing? What’s going to be the next new thing? 

Wes Shriner: 

Is there a fraction of zero we could use? 

Peter Gregory:

In imaginary numbers, or real numbers? 

Wes Shriner: 

Yeah, I don’t think we can get below zero trust, but zero trust will be compromised, and we’ll have to have another digital revolution like we’ve had three times in my career so far. We are digitizing our organization, whatever that means. 

Kip Boyle: 

I thought we had already done it, I was surprised that it came around again. 

Wes Shriner: 

But you’ve seen it too, haven’t you? 

Kip Boyle: 

Yeah. 

Wes Shriner:

We’re going to digitize our organization. We’re going digital. The behaviors of this person, they’re going to track industry thought leadership. They’re going to drive risk management priorities into the projects that come up next, and we’re going to align them to organizational goals. These folks are passionate learners. They’re going to practice humility and confidence both. They’ve got to set a direction and be the rudder, but just be the rudder. You don’t have to be the whole ship. And they’re going to build alignment, growing consensus, so that they don’t run alone, they run together. If you want to get somewhere fast, you go alone. If you want to stay there when you get there, you bring the group on the way. And this person’s going to be good at that. 

Kip Boyle:

Notice the human factors in play here, right? It’s not all about technology. 

Peter Gregory: 

Well, and even for roles like this and the prior role, I mean, all of these are just one player. It’s all a team sport. This is not a super star thing, but it’s a team thing. 

Kip Boyle: 

It really is. 

Peter Gregory: 

And the humility is what really helps you, because even the best strategists don’t know everything. I mean, if they think they do, then I don’t know. 

Wes Shriner:

And the team doesn’t stop. The team doesn’t stop at your company. It doesn’t stop with your security team. In fact, inside the security team, we can reach out to folks in our product team to better understand how they recommend we design a security solution. We can reach out across organizations to another company, probably not a direct competitor, and calibrate how does that security person recommend solving a problem? 

I know I’ve seen Kip, Peter, and myself reach out to each other on a regular basis. We try to keep that off of public channels, but very much, “How do you handle HSM in the cloud?” is a question I saw recently. It’s a good conversation to have, and to have a team of folks behind you that are helping you succeed. We all need each other in that way. 

Peter Gregory: 

Yeah. Wes, I would add to that success criteria that you’re networking with your peers in your industry, and even into other industries, at times. And that’s really essential, because generally, an organization is going to have one strategist, if any. And there may not be suitable peers for that strategist to bounce ideas off of all the time, so that’s why that networking through private channels is so important. 

Kip Boyle: 

I want to add a caution here too. I think Peter’s right. You do need to talk to other people and other organizations, both inside and outside your industry. But be careful about trying to advocate for reference architectures and strategies that are not appropriate for your size of organization, or the industry that you’re in. I mean, just because the giant bank down the street where your buddy works is doing something… It may seem cool, but that doesn’t necessarily mean it’s a good fit for you, not in the banking industry, at a mid-size company. I mean, you could get in trouble real fast if you’re not paying attention to that. 

Peter Gregory: 

If we could pause there for a minute, that is really just the tip of a bigger iceberg, where so many organizations, security and technology even, they adopt technologies and techniques because their friends do, their peers do. And even companies that aren’t their peers. There’s so much doing what other companies are doing, because they think it might be cool or because their peer in another company across town said, “Hey, we just implemented this tool and it really was good for us.” And people who are not as mature as they need to be as a strategist or architect might think, “Well, if it helped them, it’s going to help me.” Which is not the right approach to take at all. 

Those kinds of decisions should be risk-driven and business-aligned, and not because your neighbor’s doing it. 

Wes Shriner:

Yep, although that’s a very human reaction, to look and see what the crowd’s doing, and then go along with that. It’s hitting the easy button. 

Peter Gregory: 

Totally. 

Wes Shriner: 

But it can be very dangerous. 

Peter Gregory: 

Absolutely. 

Wes Shriner: 

One of the mistakes… sorry. One of the ways this person can fall in a hole is actually to be labeled as a tools guy. If you become labeled as the shiny object tools person, I don’t really understand the problem, I don’t understand what our processes are, but I know that if we buy this thing, it’s going to make our lives better. That is not the right approach for your organization, or any organization. And in fact, is the fastest route for this person to be shown the door, in many ways. We lose trust in the person who says, “Just go spend money on tools.” 

Peter Gregory:

It could make the vendor’s life better. It can pay for the kid’s braces, or get that new ski boat, or whatever, but- 

Kip Boyle: 

Yeah, and you might get a steak dinner when the restaurants open back up. 

Peter Gregory:

Yeah, maybe. 

Kip Boyle: 

Maybe. 

Peter Gregory: 

Maybe, if my gift policy lets me do it. And if we live in the same city, because with the pandemic, we’re not just limited to business relationships where we live, because location no longer matters. 

Wes Shriner:

Right. So I’ve got a vendor that I actually agreed to sit down with. I’m working at a company that’s an East Coast company now, and I’m on the West Coast. So they have a happy hour meeting that’s going to take place at 5:00 PM East Coast time, which is still actually mid-afternoon for me here in Seattle. And they’re having mint juleps shipped to my home for that. And I had to ask for the non-alcoholic option. 

Peter Gregory:

2:00 in the afternoon, right? That’s happy hour somewhere. 

Wes Shriner: 

I’ve still got a lot of day left. 

Peter Gregory:

True. 

Wes Shriner: 

All right. So that tells you a little bit about the security strategist. Let’s take a look at that third role. 

Peter Gregory: 

Where is that button? There it is. 

Wes Shriner: 

The security solution architect. What’s that? 

Peter Gregory: 

I said, “Where is that next button?” 

Kip Boyle:

Hit the easy button, Wes. Hit the easy button. 

Wes Shriner: 

I know. Computers are hard. Don’t you guys know? All right, security solution architect, reports into usually business unit leadership, so not into the security team. Or if does report into the security team, it’s dotted line to different business unit leaderships. This is the person that’s creating the security business unit roadmap for a specific business unit. Now, that business unit may be your frontline organization that includes your sales and care. 

That business unit might be your mergers and acquisitions group that you just bought. Maybe it’s a whole subsidiary of your organization. Maybe that business unit is your primary product line. You’re not going to have one of these for every business unit of every company. In fact, this person is going to be in the most strategic business units that need that dedicated security leadership. They’re going to design risk reduction. Their day job is take down the risk, and I’m using an acronym, BISO, and the acronym QVR here. A BISO is a business security… or what is the acronym BISO? 

Kip Boyle: 

Yeah, it’s [crosstalk] business information security officer, yeah. 

Wes Shriner: 

Officer. And that’s a person dedicated to a specific business unit for the purpose of building out their security capabilities. A quarterly business review is a QVR. And that might be something that the security officer, the BISO, would conduct with their business organization to talk through what kind of security awareness and training have we done? What kind of projects have we evaluated? What kind of vulnerabilities do we have in our environment? And a whole host of security-related metrics that we can track in a single scorecard, and check in on a quarterly basis for what’s going on. 

All right, that was a lot of detail on that QVR, but I find it’s a function that gets lost a lot of times, and when we build it out, it actually gamifies security across the company and makes it really an effective way to have a conversation about how we’re using security here.

Some of the behaviors of this person, they’re going to be building trusted alignment across the business unit and security. Please don’t underestimate the effort involved in that bullet. That is one of the hardest things. The business unit is here to make money, and security is here to slow us down. No, that’s not what it is. I’m pretty sure it’s not. In fact, as a security professional, I want that business unit to make money, because then my kids are going to go to college. 

That person is working with priorities one to three years ahead, and they’re driving security into the highest risks of that business unit. These people are going to be technical leaders. They’re going to be trusted partners, and they’re going to use a lot of social engineering. I can almost guarantee it, because you have to. You’re hacking your organization to get the organization to a healthier, better place. 

Kip Boyle: 

Yeah, one of the metrics that I would use in this goes back to something we said earlier, which is you want to do what, versus you did what? If you’re in this position, and the more you’re saying, “You did what?”

The less effective you’re being, because what you really want is for people to come to you and say, “We’re thinking about doing this. Seems risky. What’s your take on it?” Boy, when people start saying that to you a lot, you know you’re doing really well. 

Peter Gregory: 

Well, right. It’s because the more they trust you, the more they trust you, the further to the left they’re going to let you go, is what that’s all about. And by the way, that term further to the left really means just getting involved in initiatives and things earlier in time, when ideas are just ideas and before there are requirements. Before there are architectures, before there are designs.

Early in my career, I have experienced many times where in a large, large, large company, where engineering would call us up literally mid-week, late in the week saying, “Hey, security department. We’re going live with this new service next week. Can you come and check it out?” 

Kip Boyle: 

Yeah, or make it secure.

Peter Gregory:

You would have to hit mute on the phone and slam our damn it all on the desk, or just curse or laugh, or cry or something. And then get back, and just say, “Well, sure. Yeah. We’ll look at it.” 

Kip Boyle:

Well, and that’s one of the ways that you have to earn trust. Because you’re typically starting in that position. And it’s a delicate thing, because you want to be trusted, but you don’t want to be so good at securing things at the last minute that you’re actually enabling behavior that you don’t want to see all the time. It’s really tough. 

Peter Gregory: 

Well, for sure. I mean, it’s like if you were security at an aircraft company, and they wanted you to check things out at the last minute, you basically have to stand on the runway as a plane comes and runs you over on takeoff. It’s like at that point, you’re not going to be stopping anything. 

Kip Boyle: 

Yeah. The way I- 

Peter Gregory:

If you try, it’s going to go badly, if you try. 

Kip Boyle:

The way I describe the business value, one of the ways that I’ve had some success describing the business value of bringing me in early is I say, “Look, I know you guys, and I’m talking to the tech leaders and the business leaders,” and I’ll say, “I know you guys think security’s expensive, but if you can bring us in earlier, actually it can be less costly. Just like if you’re building a house and you figure out where you want those power outlets to be before the sheet rock goes up, it’s way less expensive.”

Peter Gregory:

Yes, that’s a good metaphor. I’ll have to use something like that. 

Kip Boyle: 

Yeah, because you’re going to be working for another 20 years, right, Peter? 

Peter Gregory: 

Yeah. 

Wes Shriner: 

If you bring me in when the code is written, that’s going to be pretty close to deployment. If you can bring me in when the PowerPoint is written, I’m going to have a chance to influence it for a much less expensive price. If you bring me in when the white board is drawn, that’s even cheaper for me to make changes before the PowerPoint is made and the code is written. If you bring me in when the napkin is drawn, that’s even further left. And if I may, if I’m there when the beers are consumed and the idea is spawned, that is where we want to be in the moving left in the lifestyle. 

Peter Gregory:

The beard and the napkin happens at the same time, Wes. Right? That’s the same sit-down. 

Wes Shriner: 

All right, fair enough. 

Peter Gregory: 

Sorry. 

Kip Boyle:

Don’t spend too much time in the bathroom, though. 

Peter Gregory: 

Good point. Something that I thought of, although I usually don’t use this metaphor, but something I learned from a colleague years ago, he used to talk about the 110/100 Rule, which is that the later you wait to bring security in, the more expensive it’s going to cost. It can cost one unit if you bring us in at the beginning. It might cost 10 units if you bring us in, say, after the design is done. It might cost 100 units of work including say, rework and so forth, if you bring us in after you’ve built it. 

Wes Shriner: 

Yeah, that’s good. 

Peter Gregory: 

110/100. 

Wes Shriner: 

And these three architecture roles that we’ve talked about today are the architects that can help us move left in that life cycle, to build the security axioms for how we want to enable our business and direct our business in the future. They can build the security strategy, so we know what pillars we want to align our projects to. And they can help us architect and design the next two years of priority, so that we are building that direction. Fun. Let’s take a look at that last one which is actually service number 11, so we’ll get to it later. 

This one reports to security and does the rubber meets the road security design work. This is for the IT change that’s coming out next week, next month, or the project that comes out this summer. They will have the technical chops, the humility, and the partnership to be successful. And they will own the organizational appetite for risk. If we design a $10 solution to a million dollar problem, we didn’t understand the problem. If we design a million dollar solution to a $10 problem, we didn’t understand the problem, and there’s an escalation coming, right? 

Peter Gregory:

Yeah, totally. 

Wes Shriner: 

So your boss will hear about it. Yeah, these are folks who when they see something, they have to say something. It’s a very high-integrity role. We’ll get into more of this role in the future, but I wanted to call it out here, because it is an engineering architecture [inaudible]. 

All right, and yeah, this is the one most often you find yourself standing in front of the jet plane, and becoming part of the tarmac. It’s a fun role, because you’re in the middle of the operations of the organization. All right. Oh my goodness, I hope you enjoy the colors on this slide. 

Peter Gregory: 

Love it. Wes, is that a beer can? 

Wes Shriner: 

Yes, sir. These are [crosstalk]- 

Peter Gregory: 

Seriously? 

Wes Shriner: 

These are examples of reference architecture. I almost made it architecture, because it’s a good pirate slide.

Peter Gregory: 

I want to know what the beer can is doing there. 

Wes Shriner:

Well, there- 

Kip Boyle:

I think that’s leftover from the conversation that we brought in early on. 

Peter Gregory:

Was that the part of the cocktail napkin thing? Was that the logo on the napkin that they thought was part of the design? 

Kip Boyle: 

Nice. 

Wes Shriner: 

No, what I’m trying to do here is call out there are four different types of reference architectures that we might see in our organization, that we might create in our organization. And in fact, when you see the differences between these four, you’re going to find that there’s actually 100 more types of reference architecture, because there’s not a clear definition of what exactly they need to look like. 

So if I can point you to this top one first, that’s got capabilities across the top, perimeter, or identity or end point. And then down the left-hand side, it has part business units. IT, HR/Finance, frontline, supply chain, and then it has a list of well, what tools are actually operating in that intersection? And then once we understand the tools, it’s red, yellow, or green, based on how they’re operating for that business unit in that intersection. This is really a capabilities for business unit matrix, that helps us understand where we may want to increase our investment in our organization. This is an organization view. 

The next one is here on the top right. The physical topology versus the logical topology, and it’s really laying out your network diagram with your VLANs and your firewalls all included, so you can better understand how do I get from here to there? Where does my DMZ reside, and if I were building an application on this network, what’s the right way to do that from moving from high to low? And never moving from low to high in my security zones? All right, I’m going to leave security zone architecture as a nebulous thing, and just let you look it up on Wikipedia if you want to later, because it’s a fun topic. 

This bottom left one is actually more of AWS components. And it’s just AWS components and arrows. You’ll notice that there are some numbers on there, and so probably beneath this are descriptions of what does one… going to be emphasized? What is number two going to emphasize? What is number three going to emphasize? So there’s probably a key underneath this that explains a lot of what is happening in this diagram. And then your fourth reference diagram is here in the bottom right, and that’s your beer cans and lightning bolts. 

Peter Gregory: 

That’s where it came from. 

Wes Shriner: 

All four are reference architectures, and all four can be templates for how do I evaluate my organization? How do I design my next application? Or how do I want to implement my own network in some cases? All four will get you where you want to go. Choose the diagram that’s going to work best for you. In the architecture role, you’ve got that freedom. 

Peter Gregory: 

So one thing Wes, I’m wondering about here, is it seems as though there are levels of abstraction and I wonder what thoughts you might have about that. 

Wes Shriner:

Tell me, take me there. What do you mean? 

Peter Gregory: 

Well, for instance, the diagram at the bottom right looks like it’s talking about some different networking or computing zones, maybe. Maybe that’s what those lines mean, is that those are components in different regions. And so very abstract. I mean, that’s nowhere near an architecture… Well, I guess you could call it architecture, but conceptual. Very conceptual.

But sometimes, abstraction I think can be more powerful because depending on who you’re talking to, putting the technology in is just going to be noise. So if you’re talking to executives, I’d probably use a diagram like at the bottom right, but probably not a diagram like a the top right. I probably wouldn’t use either of those topology diagrams, if I was talking to executives. Because they won’t even know what I’m saying. 

Capabilities, I like the capabilities at the left. That’s also super abstraction, there. But it helps just understand what do we have in different places, in different contexts? 

Wes Shriner:

It does. 

Peter Gregory: 

So I think abstraction for the architect is a really powerful tool, but you have to be able to think non-literally, and think conceptually, and be able to take things out of focus, and get more general. I think that’s an area where an architect can have trouble going, until they get some experience or have a mentor who can help them understand this is how you talk to business people. I mean, you don’t bring network diagrams into a discussion with C-level people. I mean, not even the CISO. I mean, don’t do it, or that’ll be the last time you ever see them. 

Kip Boyle: 

Yeah, my friend Wes has a little saying, “Be brief, be brilliant, be gone.” 

Peter Gregory: 

Oh, I like that. That’s right. That’s right. 

Kip Boyle: 

Yeah, and you really have to understand your audience. Peter, I love what you were saying there, because it’s not just a matter of the position of the person that you’re trying to communicate with. It also has a lot to do with just how they see the world. So there’s a lot of concrete linear thinkers that I’ve worked with, and if you try to show them something that’s abstract, they’ll fuzz out on you in two seconds. And they’ll think you’re weird. 

Peter Gregory: 

Yeah. But you do the- 

Kip Boyle: 

Because they can’t understand you. 

Peter Gregory: 

reverse. Yeah, but if you do the reverse, they’ll think you’re weird, right? If you take a network diagram into the board room? 

Kip Boyle: 

Yeah, yeah. 

Peter Gregory:

They’ll think, “Oh, what a nerd. We don’t even know what he’s saying. Get him out of here.” 

Kip Boyle: 

Yeah, yeah. He’s from the planet [Bynar]. Get him out of here. We can’t do this. 

Peter Gregory:

Right. Well- 

Kip Boyle: 

So just the human factors, right? You’ve really, really got to know your audience. 

Peter Gregory:

Yes. And you know what’s interesting? Is so much about these architecture roles aren’t about the technology always. They are so big picture. I think that’s why this is episode 42, right? The answer to life, the universe, and everything? Because the architect role is the everything role. 

Wes Shriner: 

That’s awesome. Well done. 

Kip Boyle: 

Thanks for all the fish, Peter. 

Peter Gregory: 

Yeah. 

Wes Shriner:

Nice. 

Peter Gregory: 

Yeah, you bet. 

Wes Shriner:

Nice. We need dolphins on the slide. All right, I’m jumping ahead here. Thank you, guys. That was really good input. I think it makes a lot of sense to take it from where we are into the abstract, and then to be able to bring it back out of the abstract in a new way, and really help the listener connect with it, and see a new paradigm is exactly what we’re asking the architect to do. 

Kip Boyle: 

Oh, you’re talking just like an architect right now, Wes. Careful, careful. 

Wes Shriner: 

Should I use buzzwords? Should we get out a bingo sheet, and see how many we- 

Kip Boyle: 

You already did. You used paradigm. Whenever you use paradigm, I’m like, “Okay, here we are. 50,000 feet, got to turn on my oxygen.” 

Wes Shriner: 

Ah. 

Peter Gregory: 

As long as you’re buzzword compliant, you’re fine. 

Wes Shriner: 

Well, now we’re looking at the SIPOC. We’ve introduced this before. This is all about your suppliers, your inputs, processes, outputs, and customers or consumers of the service that is architecture. Some of the suppliers, I’m going to be gathering information from company strategists. I’m going to get it from the risk story of our organization, and I’m going to get it from industry leaders. My inputs might be new regulations, whether that’s governmental or industry regulations. It might be the new acquisitions our company just bought. It might be changes in our technology organization, or even better, changes in technology in the industry. 

A new language comes out. A new capability comes out. I may be using industry reports, and my company may be reacting to a recent security event that may or may not be called a breach. And so if we have a breach threat or a breach reality, there maybe an architect involved in designing away from that in the future. And then lastly, if the architect isn’t taking into account those business objectives, the architect’s architecting for the wrong things. 

Kip Boyle: 

Where I see architects falling down, when we think about inputs, is they often are looking at what’s going on inside the four walls of their organization, and they can miss taking time, forcing time into their calendar to see what’s actually going on outside their organization, and bringing that in. I see that all the time in my vCISO work where I’m telling customers about how the bad guys and the bad girls out there, what they’re actually doing now, and how they’re innovating with ransomware as a service, and all this stuff. 

And they’re shocked. Sometimes, completely disbelieving me, that I’m actually coming around with fud, because they just don’t pay attention to what’s going on outside. 

Wes Shriner:

I think it’s going to be cool, next episode, we’re going to talk about threat intelligence and the fear, uncertainty, and doubt that comes with that, of what the bad guys and bad gals are doing out there. 

Peter Gregory:

Yeah, do remember though that threat intel is about what’s happening right now today that we need to go and dial in and keep out of our network. But I mean, the architect jobs, they need to know the trends and more generally, what’s going on now. And where they cyber criminal innovation is likely to go. 

Kip Boyle: 

Yep. 

Wes Shriner: 

Good words. 

Kip Boyle:

Super important. Skate where the puck’s going. 

Peter Gregory: 

Oh, yeah. I love that phrase. I use it a lot, especially in Canada. The further south you go, the less people understand what you meant by, “You got to skate to where the puck’s going to be.” 

Wes Shriner:

Can you say it with a good accent too, so you can… I’ll just leave that one alone. 

Peter Gregory:

Eh?  

Wes Shriner: 

Leave it alone. So the processes might be research. We’re going to prioritize. We’re going to make recommendations, and we’re going to create white papers, create recommendations for where our organization is going to go. 

Kip Boyle: 

We’re going to create our outputs. 

Wes Shriner: 

We are, which are the policies, the axioms, the roadmaps, and the reference architectures. 

Kip Boyle:

Every time you say axiom, all I can think about is the Disney movie. All I can think of is Wall-E. 

Wes Shriner: 

Why is that? 

Kip Boyle: 

Because that’s the name of the spaceship that everybody escaped from planet Earth on to avoid all the pollution. It’s the Axiom. Yeah. 

Wes Shriner:

And the architectural axioms may save us one day also. That’s beautiful.

Kip Boyle: 

So Wall-E’s flying around in my head. 

Peter Gregory:

I wonder if there’s a hidden meaning in that. 

Wes Shriner: 

That’s beautiful. All right, and the consumers, the customers of these deliverables may be the design teams. It may be your organizational project governance, where we’re spending money on what we’re going to build or fix next. And lastly, it’s going to be organizational leaders who make the decisions on that money spent. So that’s your SIPOC of architecture. 

Let’s take a look at that next slide we have, which are the people of security architecture. We’re going to see security architecture. That enterprise architect is usually an MTS-level experience. MTS is a member of technical staff, and you’re going to find those are your principles who are involved in your organization and who are driving, and highly trusted by your founders, your board, and your C leadership? 

Kip Boyle: 

The 20 plus year experience people, right? 

Wes Shriner:

Potentially, yeah. Often times, MTSs do have a couple books behind them before they step into an MTS chair. 

Okay. That security strategist usually has 10 years of experience in both technology and security, and that solution architect has usually at least five years of experience in the technology space, and in some security, to be able to make recommendations for how that business unit is going to be more secure tomorrow then it was today. That BISO role, that solution architect is a great transfer in opportunity for someone looking for their next opportunity in the security space. You’re moving from a technology to a security role. 

I want to call out that each one of these is an individual contributor role, for the most part. Most architects prefer to be in technical leadership, and not in people leadership. And so it’s pretty common that an architecture chair is not a personnel management chair, but that architect is still invited into the leadership committee of that organization. 

Kip Boyle: 

And we really don’t want to report to those people anyway, so it’s a good deal for everybody. 

Peter Gregory: 

Yeah, I think you’re right about that, Kip. You don’t want those people writing your performance review, right? 

Kip Boyle: 

No. No, and I don’t want to go to them and ask, “Hey, where’s my cost of living adjustment?” And they’re like, “What? Didn’t we talk 48 hours ago?” 

Peter Gregory: 

“Can I have the day off?” Yeah. 

Wes Shriner: 

We have talked about some of the key success criteria of different architects, and I can look at some of the architects that I’ve worked with in the past, as a junior project coordinator, just moving out of the call center into IT. 

Sandy was a phenomenal mentor for me. Jason was a phenomenal mentor. And then there was another person at that company, and he was a senior principal solution architect-type person, and if I had to call him as the senior project coordinator, he answers the phone, “Shit, what you want?” He did. 

Peter Gregory:

People skills. He had people skills? 

Kip Boyle:

I’m good with people. 

Wes Shriner: 

He scared me so much!

Peter Gregory: 

Oh, man. 

Wes Shriner: 

He scared me. But he knew everything, and when we had an outage, we could call him and he could break glass, grab the credentials, and fix things that nobody else could. And so- 

Peter Gregory: 

So he was like crazy Ivan in… What was Das Boot? Yeah. 

Wes Shriner:

He was one tough dude, but he was there when you needed him, and that was pretty cool. So the skills that we need for these roles, they need to be able to research. We need to be able to influence without authority. 

We see that one. And they need to be able to communicate at every layer of the organization, and have a strong technical background to back up the recommendations they make. 

Peter Gregory: 

In that communication, there’s a term I use a lot, is that they need to be bilingual. They need to be able to talk to technologists with credibility, because they have experience. 

They have to be able to talk to business leaders because they know how, and they know how to use which dialects and which languages, depending on who they’re talking to. So they have got to be super aware of who they’re talking to, and what they’re trying to say. 

Wes Shriner: 

Indeed, indeed. These folks are going to be using their industry connections and their reference documents as their primary tools. They’re going to be using Microsoft Office tools. They’re going to be PowerPoint wizards, and that is the tool set of the security architects. 

Peter Gregory:

I’d almost say no Vizio, even. 

Wes Shriner:

I do find sometimes, if you’re running a pilot, that security architect may end up grabbing a DOS prompt, and start installing a pilot evaluation. But I find that never ends well, because if the architect did the install, then I don’t really know. I don’t have any documentation about how it was installed. 

Peter Gregory: 

Right, because he didn’t write it down. 

Wes Shriner: 

No, but they’re architect. All right. We just disparaged the thing we spent an hour talking about. Sorry, architecture friends. It is a great role and a fun place to be. 

Kip Boyle: 

We [crosstalk] can’t live without you.

Wes Shriner: 

Indeed, indeed. All right, I’m looking forward to this next slide, because Peter gets to give us the last word. Peter, what have been the keys to your success over the years? 

Peter Gregory: 

Let’s see. I’ve been asked this question a few times, and one of the most important ones, and this is just going to be a little story, that I’ll just give one example. Very early in my career, I was a programmer in this new language at Unisys called Mapper, that was a little bit like Basic and a little bit like Excel. And they asked me to teach the other programmers in what they called the MIS department at that time how to build programs in Mapper, and then after a few of those courses went well, they asked me to teach them to the department heads. 

But before they let me do that, my boss’s boss took me into his office and he says, “Okay, Peter. We’re going to roleplay here, and you’re going to start the Mapper course for the department heads, right now. Grab a pen and start writing and talking.” And so I did. And Ralph Pratt, who was the IT manager, I mean, I would say like five words, and he goes, “Stop! You can’t use technical words like that. 

Start over.” And then I’d start again, and I’d get maybe two sentences in, and he’d say, “Stop!” It’s like, “Oh, you used technical terms again.” And we had about a 30-minute session and he… I mean, it was so difficult. I was emotionally exhausted, but in that one session, he taught me how to talk about technology to people who don’t understand it. And I’ve had to use that again and again, and I had great opportunities for developing that skill and using it. Sometimes, it was very difficult. 

But it was really instrumental to my success, because without some of those experiences, I’d be another one of those technologists that you don’t let out to talk to business people, because they’ll embarrass you. And so that’s really been important for me career. 

Kip Boyle: 

Peter, there’s a little turn of phrase that I learned about which is when you talk about things, and you assume too much about your audience, what that sometimes is called is the curse of knowledge. You forget just how much you really know and so you had a curse lifted off of you. 

Peter Gregory:

Ah! 

Kip Boyle: 

That’s great. 

Peter Gregory:

Interesting. 

Wes Shriner: 

I’m going to speak into that as well, because I think you brought up with this Mapper technology, once you learned it, you had to teach it. And I see you doing that over and over and over in your career. Once you’ve learned it, you teach it to the next person behind you. And when you learn it, you teach it. You also really consume it. You really know it, at that point. 

Peter Gregory: 

Darn right. Darn right. 

Kip Boyle: 

That’s real leadership, right? When you’re teaching other people how to do stuff, I’ve heard some people say when you get to the top floor, send the elevator back down. 

Peter Gregory: 

Yeah. 

Wes Shriner: 

Well, and I remember having a conversation about these three different chairs of architects, and how sometimes, you don’t really think about there’s actually three different types of roles. The strategist, the solution architect, and the EA. But actually, when you put it all together, there’s a lot there. And we wouldn’t probably have recognized that, if we hadn’t stopped to teach it today, so it’s fun. 

All right, Peter, if you had a mentee in school right now, who said they want to be in security some day, what would you tell them to focus on?

Peter Gregory:

Good question, Wes. And there’s a two-part answer. Two-part answer. First, I would do everything I could to help them understand that they need to learn the basics of information technology. They need a lot of knowledge about how networks work, down to the packet level. What is a packet? How do they work? How do routers work? How do switches work? What do they do? How do they do it that way? How does DNS work, and other foundational technologies, as well as how do operating systems work?

How does software work? All those things are really vital. And that’s the first part, and then the second part on what to focus on is I would say, do what you love. There are so many specialties and sub-specialties in information technology and in cybersecurity. Find something that you dig doing, and do that. Because there’s plenty to do. There’s so many different jobs out there, and if you do what you love, then you’re going to like going to work. And you’re going to make pretty good money anyway, but you might as well do what you like doing. 

Wes Shriner: 

Oh, yeah. 

Peter Gregory: 

Because the money is not a substitute. If you don’t like the job, then you’re just going to resent. You’re just going to have a thought process that’s more resentful than grateful, and- 

Kip Boyle:

And everyone’s going to know it. 

Peter Gregory: 

Yeah, yeah. There are opportunities in every industry, in ever geography, and in every sub-specialty. So find what you love, pursue it with passion, and never stop learning. 

Wes Shriner:

Really good advice, and I’ve actually found myself explaining to some young folks lately, “If you don’t understand how it works, you’ll never be able to break it. And if you can’t break it, you’ll never be able to defend it.” So it’s actually three layers of depth. The first is how does it work? 

And the second is how can I attack it or hack it? And then the third is, “Well, how could I protect against that person?” And understanding the controls and levers for that protection is really hard, and part of the skill that security professionals bring to the table. So, thank you for emphasizing that.

Peter Gregory: 

Sure. 

Wes Shriner:

So what do you know now that you wish you knew then? Back in the early 90s, when you were running around in an MIS department? 

Peter Gregory:

Well, that was actually earlier than the early 90s, but I’ll just stop there. 

Kip Boyle: 

Just run with it, Peter. 

Peter Gregory:

I wish I would have taken the red pill earlier. I took the blue pill and took the safe route for a long time, early in my career. Until I realized that my career was actually in my hands, and not in someone else’s hands. And to be bold and to get out of my comfort zone. As soon as I realized that I could do better by getting out of my comfort zone, then great things have been happening. If you just play it safe, you’re just going to stay in one place. 

Wes Shriner: 

That’s been true for me as well. That’s excellent, excellent advice. All right. Thank you, Peter, this has been a lot of fun. 

Peter Gregory:

Yeah. 

Kip Boyle: 

Really glad you were here. 

Wes Shriner: 

Me too. Me too. 

Peter Gregory: 

Likewise, good to see you guys. 

Wes Shriner:

Indeed. Our key takeaways for security architecture are that architecture roles are very senior positions, with significant influence across the organization, the industry, and in some cases, America. If you find yourself architecting for more than just your organization, the reference architecture is a primary tool that cannot be defined by any one diagram or picture.

And it can be used to understand an environment and plan for the future. Next up, we’re looking forward to threat intelligence. It’s going to be a fun topic. I hope you stick around for that one. Kip, back to you. 

Kip Boyle: 

Yeah, thanks a lot. Hey, guys. Listen, everybody. Thank you for being here. We made you something. We want you to go get it. It’s a free guide. It’s called Play to Win: Getting Your Dream Cybersecurity Job. And if you’ve ever played Capture the Flag, well, what we thought was, “Hey, why couldn’t you take the skills that you use when you play Capture the Flag and apply them to actually going out there, finding your dream job, and getting your dream job?” So that’s what we did. It’s a 20-page PDF. It’s very visual. You can see pages six and seven right there on the screen.

And just go get it. Tell me, if you like it, I’d love to get some feedback. If you hate it, you absolutely have to tell me that you hate it. And you have to tell me why you hate it, because I want to fix it. This is something that we’ve made for you, we want it to be helpful. So we just need to hear what you think about it. So if you want to go get it, and I think you should, go to YourCyberPath.com/PDF and you’ll find that link in the video description in the show notes. Remember, everybody. You’re just one path away from your dream cybersecurity job. Go get it, and we’ll see you next time.