Part 2 - Zero Trust Architecture With Vincent Romney

TLDR;

• To implement Zero Trust as part of the security program, understand the current Architecture first and then introduce Zero Trust in each layer one by one. Follow the NIST 800-207 guidelines closely.
• Security debt is nothing but Tech Debt for Security. Have clear communication with Leadership team to find a balance between business growth and reducing the risk.
• When working with Executives, tailor the message & add context to show the Risk and challenges in the security infrastructure.

Transcript

Host: So I want to sort of move to a little bit of planning of Zero trust, right? So when setting up security programs in an organization, it is often difficult, right? And when you throw in zero trust into the mix, it becomes even more challenging. So,

What are the challenges you have seen in organizations to set up a robust security program and how did you overcome them?

Vince: Well, I would say that the very first thing, again, was getting to the point of understanding what was there in the previous life. I came into an entity that really had no formal security program, but they were a large enough entity that they were doing a billion dollars a year in revenue. And so that’s an interesting dichotomy. You’ve got a lot of revenue, you haven’t been pwned yet. Nobody’s actually completely pwned. You’ve had some infractions of things, but very interesting circumstance. Well, the first thing we did was understand what could we apply today, what existed in the ecosystem that we could apply today.

We did that. Whatever was available, we turned it on, we configured it and we got it operationalized. Then the next step was to do a gap analysis. Where are we missing for this now with 802,007 in place? If you’re looking at that zero trust model. I don’t think the complexity is necessarily as heavy as people think it is. Because if you look at that model and you appropriately analyze the tooling. So you look at vendors that have tooling that fits with this.

You can find ways to implement zero trust in a fairly non complex way by picking correct vendors that fit within your ecosystem and match your technology stack well. And there may be some refactoring of your tech stack. Again, you come into an organization, you find out the entire network is flat. Well, we’ve got to start there because we can’t implement Zero trust deep perimeterization when we only have one perimeter.

Host: That makes a lot of sense.

And as part of this, there are many areas also, right? When you go into the implementation of, let’s say, zero trust or defining a security program, you have app security infra security network security compliance, many areas and in each of these areas there are many vendor tools as well, right? So,

When it comes to having a holistic view of your organization’s security posture, what metrics are the most important to look at and how do you set it up accurately and how do you set it up as well?

Vince: So to restate that from a security architecture perspective, what’s the kind of most important thing to line up first? I think when anyone is evaluating their security architecture, we have to back up to their technical architecture because security architecture really is dependent on what you’re applying it to. So looking at your technical architecture, what is the environment you’re actually functioning? Are you an on prem data center centric model with just a network that’s tied into that data center? It’s very straightforward then from a security architecture perspective, we understand what we’re dealing with. Whereas if we’re a multi-cloud hybrid environment with some on prem multinational clouds across a global enterprise, now the security architecture gets more complicated merely because we have differing tech stacks throughout an ecosystem that is part of the enterprise. So again, evaluating that part once you have that. I have always felt that as perhaps arduous as it is. The CIS (Center for Internet Security) top 18 now used to be the top 20, but the CIS top 18 give you a very good structure. If you start at one and then move to two and three and four and five, you are able to constrain around the most risky environments.

If you don’t know what you have, you’re at great risk because you don’t even know what to protect. Hence CIS One and two are all about what you have. Moving on to that stack, you start to get a little more granular about your ability to control things. So I have always used that to help build architecture around a given tech stack because as I go up through that CIS top 18 I can identify what does apply because I actually have that kind of text ad and what doesn’t.

Host: That makes a lot of sense. This also touches on your initial answer to the first question that inventory is the key. You have to understand what inventory you have before acting on it, right?

Vince: Right. And even small organizations are challenged with that because from an organizational standpoint you have a business idea and you’re a business leader and you get out and you start building this business. The It componentry is just dragged along as a necessary part of supporting that business. And so nobody thinks to actually define that and say we’ve got to start an inventory process that’s sustainable throughout the life cycle of our business.

It’s nothing that most people haven’t started. It that’s great. Start it now that becomes your foundation.

Host: Makes a lot of sense. So now let’s say you define a security program and you are implementing that security program. Sometimes we take shortcuts or we sort of push a couple of things into the backlog in a way, right? So that your business growth is not affected at all while implementing the security programs. This is very similar to like tech debt or product, right. Which is if not addressed properly, could affect the overall productivity, performance and many areas of the organization. So,

What are your thoughts on debt in the security space, like security debt and how do you define it and what measures should we be taken to address it as?

Vince: I think one of the most important elements of tech debt, security debt of that environment and in reality security debt is nothing more than tech debt that’s applied to security. But it’s explaining to in a language that’s understandable the risk associated with that tech debt to leadership. Because leadership has to make a decision on resources. They have to decide are my resources going to be used to make more money or to reduce risk? And those are really their two decision points because if you make more money it’s build stuff that makes money and if it’s reduced risk it’s take that resource away and put it over here and reduce risk. So I think every discussion from a security practitioner standpoint to the C staff to executive committee to a board is all about balancing business with risk and not coming in with your hair on fire about the sky is falling and we’re going to get poned tomorrow and it’s all going to be terrible. But coming in with a realistic method of describing the real risk associated with the tech debt and some of that tech debt obviously on the say the It infrastructure side has both security and stability problems because we build enough tech debt on our infrastructure, our applications become unstable. If we have old enough code in our applications they become unstable.

And then with that unstable applications and unstable infrastructure provide entry points for vulnerabilities in the cybersecurity side, creating that balance to the executive team so they can make a decision on putting resources to reduce that tech debt. On the flip to that is selling the idea to your executive team and it’s hard but selling the idea to your executive team, that slow is fast.

When you’re building a new business model to make money, some new features, some new application, whatever, there’s always this tendency from executive leadership to say here’s the date, this is when we’re going live. And I get that and that’s an important thing to do. But I think the counter to that is have we analyzed this product enough even in an agile development environment to understand what security we need to do from the beginning. So this early stage threat modeling of anything early stage threat modeling around an application, around a feature, around a new infrastructure, set up, move to the cloud, any of those things, start your threat modeling on the far left and do it immediately and communicate that to the executive team. So as they’re formulating that business plan and roll out, they understand what risk has to be mitigated upfront properly so that you don’t end up with that tech debt or that security debt we just talked about.

Host: That makes a lot of sense. And you touched upon executive communication, right. Communication to the executives and getting their buy in or making them understand so that they can take the informed decision between business growth and improving the security. Right. So,

What type of metrics do you use to report to your leadership or CEO and how do you show your, let’s say, overall security posture and how are you planning to improve in future?

Vince: So first off, all executive teams are not created equal. They all speak different languages, they all come from different backgrounds. And fundamentally, it’s incumbent on the security leadership to try to understand what communication methods work best with the CEO, the CFO, the CTO, the group that they are working hand in hand with to protect the business.

Some people are fine just understanding that there is a risk, it represents a significant vulnerability. Go fix it. They want that, they’re willing to do it. Others want to understand down to a very molecular level, if this risk were to occur, or if the realization of this risk were to occur, what would the financial impact be? And then you balance that against, well, what’s the financial impact of moving the release date of our product out? 60 days to compensate for that? Some leadership wants that level of detail. So learn the level of detail that they want and build your metrics to that detail. It’s one thing to go in and say, well, the SIM captured that we had 10,000 events, and of the 10,000 events, 800 were critical and we blocked all of them. Yeah, us, that doesn’t really tell a story other than what the SIM happened to observe in that time frame, putting that in context of the overall enterprise and saying that of those critical vulnerabilities that someone was trying to attack us on, we actually have ten of those and observed it and our defenses blocked it, but we still have the vulnerabilities.

Now the conversation can happen with the executive team. Should we spend the money to go fix those vulnerabilities? Because we know somebody is aware of them and they’re trying to get in with that attack that contextualizes the numbers for them. So I think that’s a real key element in communicating to executive staff is contextualizing our security metrics that we love and adore as we get into our professions, but we don’t necessarily understand what those mean to an executive leader.

Host: Right. So tailored messaging with the right context adds a lot of value when you are sort of communicating with the executive.

Vince: It’s imperative to do that because otherwise you’re just that voice screaming, the sky is falling.

Host: Yeah, that makes sense. So you have worked with many organizations, right. And you advise a ton of organizations on security as well. So according to you,

Is security like a bottom up approach or it should be a top down approach. Can you give some examples around it?

Vince: Sure. First off, I’ll say unequivocally, it’s a top down approach. It is an incredibly hard fight to push uphill from a security practitioner’s perspective if you’re fighting an insecure mentality at the top, gaining resources, being able to spend money on tooling, being able to take resources from again, that make money side and move it over to the reduced risk side, if that part of the entity is not supportive of that. It’s an uphill battle. And honestly, if you’re out looking for a job in security, interview the company you’re working or you’re interviewing with to find out what their attitude is as much as you can, because that will tell you how much of a fight you’re going to have every day of your working life.

If it’s a bottom up, the only successful method I’ve seen, and I have seen this worth I’ve had personal experience with it, is bottom up means starting to provide a consensus among an influential group of people in the organization. So you start friend people and understand their come from and what their responsibilities are in the organization. And so maybe you talk to the lead developer for one of the key features of the application that’s in that business and you start talking security with them and you bring them in and you show them some great YouTubes about how to use a good CSRF vulnerability to hack a website and then talk about the fact that we have those bringing that consensus into where you have a large enough base of consensus. You can move to the next tier. Which is maybe the VP of Application development. And talk to that person and bring them in and little by little grow that consensus of desire for a secure infrastructure to where you’re having these same conversations with the executive team. But the problem there is you still got to understand what that executive team’s language is.

And I’ll be honest, most of the time it’s money. It’s how are we making money as a business? Because that’s what keeps us employed. And we’re certainly not going to take the money away from there and put it over to risk management if it means we don’t have a business. So it’s grow consensus from the bottom up if that’s the position you’re in. But the most important position is to get leadership into a position where they are championing your security and privacy right.

Host: So if I understand correctly, top down is relatively easier to implement security versus bottom up where you need influencers who are very keen on improving the security overall. And then you go up the stack, right, and you go to the executives at the end and you get their fine. Makes a lot of sense.

So yeah. Thank you so much for sharing these insights. I personally learned a lot about Zero Trust and setting up the security program.

Rapid Fire

Host: A one-liner quote that keeps you going.

Vince: Do a little better each day.

Host: I love that a lot.

Vince: You have to do a lot better. Just a little better.

Host: I think there is a book from Atomic Habits, right. Atomic Habit talks about 1% growth every day. So that makes a lot of sense.

Assuming you are hiring in one sentence, what stands out in a candidate resume for you? One sentence is fine learners mentality.

Vince: One word, one sentence I can do. The ability and desire to always learn, because in this industry, unless you have a couple of books you’re reading and a couple of courses you’re taking, you’re falling behind. And even then, it’s hard to keep up. But you can stay relevant if you’re always reading and always studying and taking courses.

So if I’m hiring somebody, I want them to have that same attitude.

Host: On the same line, how do you stay up to date to current events or new threats that are happening in the security landscape?

Vince: I have a number of things I subscribe to. Ian Sands, Ceci, all of the feeds just to understand and contextualize attack patterns, what’s happening out there. And then I try to entertain most of the vendors that I get hit with that are trying to sell me a product. They need to get that appointment. I know how the sales process works. I’m willing to take those appointments because I want to understand their approach. I do ask them when I get those appointments to give me the tech guy.

I don’t want to get their sales. I want to understand what their technology does, because by understanding what that technology does as an architect, that’s one more potential tool in the quiver. But it’s also understanding how the industry is adapting to what I’m learning from ions and sans and CISA and all of the threat feeds

Host: Makes sense. So thank you Vince, it was very helpful. There were many nuggets of wisdom to learn for me and the viewers as well. Looking forward to learn more from you in future.

Vince: Great. Thank you, Puru. Appreciate the time.

Host: Absolutely. And to our viewers, thanks for watching. I hope you learned something new. If you have any questions around security, share those at scaletozero.com. We’ll will get those answered by an expert in the security space.

See you in the next episode. Thank you.