In this engaging episode, Sean Martin and Steve Orrin, Federal Chief Technology Officer at Intel Corporation, discuss how integrating cybersecurity seamlessly into solution architecture paves the way for innovation and business growth. They explore the transformative potential of proactive security measures to not only safeguard but also enhance operational efficiency and scalability within organizations.
Guest: Steve Orrin, Federal CTO, Intel Corporation [@intel]
On LinkedIn | https://www.linkedin.com/in/sorrin/
____________________________
Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]
On ITSPmagazine | https://www.itspmagazine.com/sean-martin
___________________________
Episode Notes
In this episode of the Redefining Cybersecurity Podcast, host Sean Martin is joined by Steve Orrin, Federal Chief Technology Officer at Intel Corporation, to delve into the intricacies of solutions architecture within the cybersecurity realm. The discussion bridges the often-separate worlds of business architecture and infrastructure with security architecture and infrastructure, arguing that these elements are fundamentally intertwined.
Steve Orrin shares his extensive background in cybersecurity, highlighting his journey from leading multiple security startups to his current role at Intel, where he focuses on integrating technology to enhance government and enterprise systems. His experience underscores the importance of developing innovative security solutions that not only address current problems but anticipate future challenges.
A central theme of the conversation is the concept of operationalizing cybersecurity measures to ensure they are effective and manageable. Orrin emphasizes the need for solutions that are not overly complex or burdensome, which can lead to them being unused or ineffective. This point segues into an exploration of the evolution of mainframe systems to today's distributed computing environments. Orrin and Martin discuss how lessons from the past can inform current practices, particularly in creating resilient and secure systems.
Further, the dialogue covers the potential for cybersecurity practices to catalyze business innovation. Rather than viewing security measures solely as a risk management tool, Orrin posits that proactive security planning can enable new business capabilities and efficiencies. This perspective is elaborated through examples, such as leveraging cloud services and multi-factor authentication to improve business scalability and resilience.
Lastly, the conversation touches on the broader implications of fostering a security-aware culture within organizations. By aligning security objectives with business goals and embracing a proactive approach to cybersecurity, Orrin suggests that companies can not only protect against threats but also unlock new growth opportunities. Listeners are left with a comprehensive overview of how integrating cybersecurity into solution architecture can not only mitigate risks but also drive business innovation and efficiency.
Key Questions Addressed
___________________________
Watch this and other videos on ITSPmagazine's YouTube Channel
Redefining CyberSecurity Podcast with Sean Martin, CISSP playlist:
📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq
ITSPmagazine YouTube Channel:
📺 https://www.youtube.com/@itspmagazine
Be sure to share and subscribe!
___________________________
Resources
___________________________
To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit:
https://www.itspmagazine.com/redefining-cybersecurity-podcast
Are you interested in sponsoring this show with an ad placement in the podcast?
Learn More 👉 https://itspm.ag/podadplc
Redefining Solutions Architecture: Cybersecurity as a Catalyst for Business Innovation | Steve Orrin
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] Hello everybody. This is Sean Martin, the host of redefining cybersecurity. You're very welcome to a new episode today, where as usual, we're going to talk about something fun. At least I, I nerd out on, on this stuff where we get to connect technology and, and operations to, uh, to real world business activities.
And, uh, today I'm thrilled to have Steve Orn on Steve. Thanks for joining.
Steve Orrin: Thanks. Glad to be here, Sean.
Sean Martin: It's good, good to have you on. And, uh, thanks for, thanks for joining me for this conversation. We're going to talk about solutions architecture in the world of cyber security. And of course, I don't think you can decouple business architecture and infrastructure from security architecture and infrastructure.
So that's probably something we'll talk about here. Um, I'm excited about this because I, many people listen to the show probably hear me ask my guests, well, how do we. How do we redefine, obviously [00:01:00] the name of the show, how do we redefine what we're doing with security, but more importantly with the business earlier, so that we reduce the impact on the team.
Cybersecurity team, InfoSec teams, as we're trying to help the business, uh, protect and grow and, uh, I wholeheartedly believe, and I'll probably have many conversations on this topic, that it's the definition of the infrastructure and the architecture of the infrastructure. Driven by the business with security in mind that will really help here.
And, and Steve, I think you, you have some interesting insights to share on this, but before we get into that, some interesting insights on who Steve is, what have you been up to and what are you up to now?
Steve Orrin: Sure. Um, so I'm the federal chief technology officer for Intel corporation. And in that role, I helped the U S government adopt.
Uh, advanced technology integrate both Intel's capabilities as well as our ecosystem into their mission and into the enterprise systems as well as help translate government [00:02:00] requirements back into the Intel business units so that we can build better solutions for the public sector and commercial solutions writ large.
My background is in cyber security. I haven't run multiple security startups. In the nineties and two thousands in the areas of desktop security, mainframe security, help create the web security market back in the day. Um, and then when I first joined Intel, uh, a number of years ago, I led our security pathfinding team, and that was a team that was focused on bridging the gap between long term research in security and the products and what was coming out the door and innovating using software to bring next generation capabilities, uh, quicker.
And you can sort of look at how do you define whether it be security pathfinding or coming up with innovative solutions. It's looking at the overall problem space, understanding the business problem or the business challenge or the risks to that and finding ways to help the customer either accelerate their security or apply security to various different parts of their [00:03:00] domains.
That may not be getting the, uh, the attention that your standard security capabilities and vendors and ecosystems are providing today. So a lot of what I've done over my entire career is, you know, look for those interesting problems and come at it from both a technology perspective, but also understanding how that gets adopted.
How do you scale security? How do you get it in the hands of customers in a way that they can easily consume and operationalize it?
Sean Martin: Yep. I love that word operationalize. And yeah, sometimes, and I've seen this in stuff that I've built, uh, when I was actually building stuff for security company, if it's too complex, too heavy.
Too much tech, too much, you need so many hands and people to do something meaningful with it. We've heard the term shelfware and I think, I think that things break down. And if, so just architecting a solution or a product, it's important, but then you have that product fits into a bigger, bigger [00:04:00] picture. I want, I want to take you back a couple of days.
Steve, um, I had the, I had the fortune of, Working on mainframe stuff back in the day to what, and I think there's a resurgence actually in the mainframe for a number of reasons. But I think what's your take on the world of the mainframe? Because in my perspective, those were very well architected systems.
You knew what was what, how it connected. What it was supposed to do seems today we're a little more loose in, in how things are built and deployed with containers and all kinds of weird things. So take me back to the mainframe days. And have we, we missed a lot with, with the flexibility and scalability that, that we've enabled today.
Steve Orrin: So that's a really good question. And, uh, Back in, back in the 90s, when we were doing that mainframe security, uh, uh, product and capabilities, um, there was really interesting things [00:05:00] about the mainframe market. You know, like you said, it was a stable environment. You know, there were applications that we were working with that had been up and running for 17 years, have never gone down.
And that was the, you know, the SLA you got out of these core business systems. They were also the things that were running the most mission critical applications to an organization. Um, Um, and they worked really well when in a given and defined environment and operational state where things started to go, let's say, Hey, wire where our opportunity as a startup was, is as people started connecting those mainframes to open systems, to the internet, to, uh, uh, external capabilities beyond sort of the green screen, dumb terminal.
And that's where the, uh, a lot of the issues rose up because these mainframes were never built to service. These kind of environments, the authentication and security models were built on some key assumptions that it was a dumb terminal connecting in. It was an internal user inside the main environment that was hardwired into the system and that the application code had gone through the [00:06:00] scrutiny that of 17 years of uptime and there was a level of of Um, testing and analysis for any application got loaded.
And I learned a lot of really important things in that process. There was a whole area as we were building our product to run on the mainframe and run natively in those MVS systems around the change control processes and the business operations of how applications got deployed or updated on mainframe was so different than what we saw happening in the I T world.
Um, you know, we've built a version for our customer and then it would be okay. Well, you can come and install it in six months because that's the one window for doing any updates on the mainframe system. And that level of rigor is something we've absolutely lost in the agile CICD, CICD world, um, around making sure that an application had to run, had to be able to perform, had to be able to operate without downtime.
On the flip side, the distributed nature of our systems today, whether it be in the cloud or at the edge, [00:07:00] affords us sometimes that lackadaisical approach as well. If that one goes down, I can always spin up another. I have real time failover. I don't need that level of rigor. Uh, because I've got the cloud that could just spin up or spin down based on capacity.
And so in some cases, we've gotten, uh, lulled into a sense of, of, of security in that, well, you know, we know the cloud will be up and so therefore it should be good enough. We've also seen, and this is something that's been, uh, rampant in all aspects of the modern, you know, internet and technology build outs, is time to market trumps security.
And back in the old days, we'd say it trumps reliability, and I think what we're seeing now with the sheer volume of security events that we hear about every day, the massive data breaches and ransomwares and attacks that are happening all the time, um, people start to think differently that we can't just.
Take this idea of, well, if as long as it functions, it's good enough as the only metric by which we deploy an application. And that's where we have things like DevSecOps, [00:08:00] building security and security requirements and controls earlier in the development cycle so that it is secure by design. As, as a mantra, try to get back to some of those, you know, tenants, if not the actual systems that we had in the mainframe world, that it has to be reliable.
By design. Uh, there's another term that's used a lot nowadays in the last five years. Resiliency that if something happens, I can recover in a quick, you know, not six days, but six minutes or less and be able to do that real time recovery because you know you're going to get attacked or you're not going to have a downtime.
And so resiliency is something you've got to build for. Um, and so we're seeing these tenants come back. And so the things that we sort of learned back in the mainframe days and forgot for 20 years are coming back and they may have new names that may have new, uh, new approaches and they're definitely new languages, but we're starting to see some of those things percolate back up that we, we actually rely on this infrastructure and on these applications for our car business, like we did in the mainframe world.
But now those are distributed systems or the hyper scaled [00:09:00] systems. And how do we get that, those tenants. back from the mainframe days, um, and be able to secure those systems to be able to survive when you're at, when you know you're under attack, which every day we know every system is being pinged.
Every system is being targeted.
Sean Martin: And I, I go back to AS 400 days where we were Connecting mainframes to your point to the internet through other systems, typically Windows systems, network systems, and connecting CAD devices and another Windows applications. And the AS400 team had the stable environment.
They're like, don't mess with our stuff. We'll give you an interface. You can, you can go wild on your own things, but you're not going to mess with the core core business functions on, on our end accounting and finance and all that stuff. Um, but use the word build. And I think that's where we, I think that's where [00:10:00] we started to take off because we were able to build a lot of stuff.
And today we can build every, a lot of things and we can pull in other services to create even bigger systems of things. And. Where I think we've kind of lost our way is on the architecture, which is the whole point of, of this conversation. Um, we're all, we might architect our own little piece of the puzzle.
Well, maybe, maybe we don't , maybe we don't shift left and upper design with security in, in mind in the first place, but hopefully we do. But it's that big picture of the multiple elements within the system. If a, if a piece of the code. We're relying on a third party to deliver that, that function in our app.
We don't architect it in a way that. There's a failover or something happens when that service goes haywire, either the integrity of the data or the service is a lot offline, then that that individual application is at risk. But then we also have to remember that that [00:11:00] application is probably connected to other things, our CRM and our ERPs and our, uh, our marketing engines and all this stuff and things can go really.
Really crazy, really quickly. And for most organizations, I don't know if a little, little downtime might not be a huge deal, but if we're talking critical infrastructure or a financial sector that relies on a, on a system that's shared across multiple things, I'm thinking Swift, that's an example, right? If we don't, if we don't integrate that and architect our solution around a piece of the component or piece of the pie that, that, uh, We recognize could have a problem.
Then we're setting ourselves up for some, for us, a disaster. So how do we get, how do we get to a point where not just the large organizations that have a lot of money, how do we get to a point where most of us can architect? our environment in a way that's more resilient.
Steve Orrin: So it's a great question, Sean.
[00:12:00] And I'm going to hit on something you said is that system of systems, most applications today are exactly that a system of system, a combination of services and code and applications and infrastructure from a variety of places, um, internal developed hosted by your cloud provider, open source code modules, third party vendors, and multiple applications in that workflow.
And it can become a very complex system fairly quickly. Um, and a lot of organizations focus on their little piece of the pie. Like you said, that I'm going to lock down my little widget and it's really good. But every one of those things live in, You know, in the real world, they live amongst these other flows, these dependencies, if you will, um, one approach that, uh, people are taking is, uh, and it's a, you know, it's, it's a classic model of solutions architecture.
And again, you're not, we're not trying to say you have to build this most complex map of dependencies of dependencies and inner, you know, the mind map kind of pictures, but understanding the workflow, the business operation, like you mentioned that you're trying to [00:13:00] enable. And that your piece of the pie is a critical component of, or even a supporting player and how you fit into that overall architecture, how you fit into that over solution, and this is, you know, then how do you understand the, your dependency?
So your module depends on data coming from one place and storage services from another, and maybe network connectivity, or relies on a UI over here, understanding your direct dependencies, your information flows, and what you're relying upon to be able to operate. And then taking it one step further and understanding your dependencies, dependencies.
And once you get to that level of complexity, which can be pretty complex pretty quickly, it allows you to draw a box. It allows you to say, okay, here's where our database is, and it's running on this kind of infrastructure. Here's our application server. Here's our, our front end UI. Here's where we send the data to another repository.
And you understand those flows. And that's why What a solution architecture really is, is understanding the system of systems that are involved and the flows. And that's a lot. Sometimes the technical folks get really focused on the systems. This is why I've always [00:14:00] felt it was important to have the business people along for the ride from the beginning to understand the flow of information or the flow of value, depending on the kind of application you're doing, why it matters or what it's being used for.
The fact that your application may be a reporting engine and you've got all your pieces of the puzzle. But your reporting engine is the reporting engine for the financial data at the end of the quarter. So knowing that is important because it tells you the risk appetite that the customer may have, your organization may have.
It tells you what's critical and also tells you where your data is going because that means that some other system or service is going to be on the receiving end and is going to be relying on you. So understanding that full workflow in a solution architecture allows you to start to apply the right Security controls, whether those be actual confidentiality, integrity, availability, or the failover resiliency requirements for each part of that.
At application flow. And so that's where this this notion of looking at the system of systems and the flows of information was really helps you when [00:15:00] you're looking at, well, how do I secure the system? And what are the requirements? Having the business people along and having the infrastructure people in with the development team will better allow you to understand both the capabilities.
And what's available and what maybe you have to augment, you know, the infrastructure say, Hey, here's your network pipe and it's automatically encrypted. Great. I can take advantage of that. I need authentication. Well, we don't supply that. Well, that tells you, you need to get that someplace else. When you look at the business flow, you say, well, the end customer for this is going to be external.
So an internal system of authentication is going to help you. It gives you the requirements you need for applying the right security controls. When we look at some of the more modern frameworks, and I'll pick on the NIST cybersecurity framework, one of the tenets of how you identify, you know, your risk is understanding the flow of, of, of your data and the flow of your systems across the different domains and how they come together and apply the right risk rubric, if you will, for your application.
Um, one, some great examples are out there. [00:16:00] Not every application needs military grade security. But what you often find in these, in these, you know, these security maturity frameworks is that there are things that are your dependent upon that weren't considered mission critical because they're not, they're, they're the backup system, but your mission critical application is relying on that.
Suddenly that gets pulled into the scope of needing higher level of due diligence and security. So it's really understanding the dependency chain. To enable that business operation or that workflow is a is a foundational way today of how we get a better understanding of what are the requirements. What are the risks that we're, we're willing to accept or that we need to mitigate against for a given application and the same technology stack could be servicing two completely different business applications that have completely different risk postures.
And so just assuming well, we built it once for this system. It should just work for the next one isn't. Always true. And that's why bringing the business people along is absolutely critical because they're going to tell you what that business application is [00:17:00] or how often it needs to be, what their SLA is.
You know, is it need to be real time? Can it be, you know, uh, up down for two days and then come back up? You don't know that unless you understand what the actual application is and what the business requirements are.
Sean Martin: So, uh, I'm a simple guy. I have to look at things usually in blocks of blocks of pictures, if you will.
So I'm picturing two parts here. One is identifying gaps. So I'm looking at the flow where data is going out, systems are connecting. I'm looking at where critical points are identified, where downtime is unacceptable or a lack of flow or delay in flow or, you know, Transaction can't complete whatever that's one part of it for me.
And then the other part is we got, we just have this rat's nest of workflow that in and of itself, [00:18:00] uh, is risky, um, because there's many more points of failure perhaps, but also just, uh, it could, it could also impact, uh, The, the efficiency of things. So in, in your conversations with, uh, with organizations that you've had.
That you've helped with some of this stuff. Are those the two pictures that usually come to the surface? And if so, does one kind of rise before the other? Did you, do they care about the complexity? As long as, as long as we get, we get the points of failure sorted out and then the risk mitigated, or I don't know, cause I have a strong feeling about.
The, the complexity piece, but if it's taken, if it's taken 10 hops, so you can do it in one and eliminate five systems or whatever, I think you're in better shape anyway, what are your thoughts on that?
Steve Orrin: So it's an interesting, uh, conversation looking at sort of the, it is world versus the to be world. So a lot of [00:19:00] business processes, a lot of it infrastructure is a hodgepodge of middleware and well, we had this thing working, we slapped something new on it to get this new capability and you get this rat's nest or spaghetti.
Of flows and information dependencies and infrastructures that have been cobbled together over the last 20, 30 years, and the fact that it's running is by, you know, by sheer will of force and an act of God. But at the same time, there's sort of two aspects that get looked at. One is, okay, how can we make this system more efficient?
And by indirectly, therefore, easier to secure if there's less moving parts is one exercise. If you have the time, the funding and the and the patients to go at it and look at the operational efficiencies, the other side is, well, I can't go spend the time and I've got to protect this. How do I protect the thing that I have?
And so there are two ways to come out that problem. And one is yeah. If you can sort of reduce your dependency on things that are critical or that you have a better way of doing things, that's obviously it can be reduce your [00:20:00] complexity and therefore increase your ability to secure. Um, the other is looking at modularization.
So that most workflows that especially in complex business are very complex and multi, like I said, many points of light of hopping around and interdependency across systems that have been deployed many years now and keep getting, uh, you know, reused in the new infrastructures is being able to, you know, from a Solutions perspective or, you know, an architectural perspective due to segmentation, be able to sort of separate the key parts of that business workflow to be able to atomize it, bring it down to something a little bit more solvable.
You start with the big macro picture, but then you start drawing these key circles of what are the, whether from a service perspective or from a business function perspective, create these modulars or containers. I'm not talking Kubernetes container. I'm talking sort of drawing a box around it and then being able to analyze that box.
defining a structured, whether it be API or set of services capabilities that the box will handle. And [00:21:00] so the other people, other organizations, other code or other applications that are dependent on it have a defined way of interacting with that module. And then the folks that are responsible for that module can dive deeper into that in order to sort out their inner complexity and inner workings.
That's one way that a lot of the enterprise architecture folks and solution architects work together with cyber operate, you know, the I. T. security operations in order to be able to unpack this highly complex environment. Because you look at these maps that take up whole walls and your brain starts to melt.
Um, but it's being able to sort of lock down. And one of the things that people have found is once you start defining whether at the technical level, it could be an A. P. I. contract between two modules or in a, in the cloud environment, you start identifying the key services. And you can bound them and say, okay, here's the service I'm taking advantage of.
There's two benefits you see. Number one, it allows you to more quickly understand how your architecture works so that you can make changes by abstracting, you know, the same idea we used to use it, you know, modular code [00:22:00] development, the same idea now at the services and the, and the infrastructure level, but also allows you the opportunity to say, you want, this one isn't working for me.
All I have to do is find something to drop in, replace, but everything else is built to a common interface or a common set of services. Agreements. And so it allows you to be more modular in tuning or making the systems more efficient from a security perspective. Ultimately, you're gonna have to apply security controls throughout that entire workflow, having defined places to be able to wrap a picture around.
You know, I'll take the idea of micro segmentation. If I can create a Tight area of what this is, you know, all the same domain, all the same risk or the same kind of service. I can apply a common policy, which means I can get to a quicker path to securing or making that more liable, whatever the security, you know, confidential integrity protected for that particular, uh, sub part of my overall workflow.
And again, it allows you to then apply a common security problem, uh, model to that. To those individual components, and then when you start to bubble up to the [00:23:00] workflow, you get these building blocks that you can then, you know, Lego together. So, okay, I've got confidentiality handled for the data repository.
I know that when I get it out to into the customers, and they need to have an integrity protected, and I can start to draw this. This risk map, if you will, of how I, how I'm able to securely communicate that information in a confidentiality and integrity protected way, without having to understand the guts of every one of those little modules, because I've created this sort of boundary that I can then apply, you know, risk posture to, because I have an API or a, a services interface, or at least a, uh, a model.
For how that, that up the operational capability is being deployed that also will then help your infrastructure team know what they got to do. They're going to, you know, if you're going to go into the cloud, you're going to subscribe to a series of security services for your cloud environment. Having that understanding of what your keys security dependencies are.
You're going to need a, you know, a software defined, uh, firewalls and capabilities you're going to need in monitoring. [00:24:00] You're going to need, you know, Data encryption for these kind of for this data set. Having those informing the infrastructure team as you're building the application that's again built on the workflow allows for them to be ready for your application so that you can deploy securely or meet your audit from a regulatory perspective.
So it's that I think the core of it is getting the right teams together as part of that planning process and then leveraging each one's expertise to help build that model going forward. And then as you One of the key things a lot of people do is they do the exercise. They're like mission accomplished.
Let's move on No, that data is critical Understand having that business model and that infrastructure, uh template for your business applications being able to use that for the next application or for the update and reuse that and update it because Let's face it, the threat world and the risk world doesn't stay static.
And if you have this good model that you've created, this good architectural approach, you can then adjust for what's new. You know, like say we've got now a new kind of ransomware we have to deal with. It does attacks the backups repository. So we need [00:25:00] to focus on how do I enhance my backup as a service to all my applications.
It allows you to be modular in your approach of the changing world we live in.
Sean Martin: So, so maybe if you can name the role. I think I heard, yeah, I can't remember what I heard. Sorry, , but I'm just picturing who, who's leading this charge. So it's not security leading this charge. It, it's the, the office of the CTO and, and probably somebody on their team or team of team on their team, team within the organization, kind of leading the charger, bringing in security and the business.
Um. We're also talking about risk. So if an organization approaches risk management a certain way, by having this solutions architecture role, identifying the gaps, does that feed the risk management or does risk management turn to you? The, the, the solutions architecture group and say, we're running, we're looking [00:26:00] at our risk exposure exposure level here.
Can you give us information that to support us? Or how does that relationship work?
Steve Orrin: And I think it is bidirectional. Um, so there has to be two way conversations because if in a modern risk management. Office understands that risk is constantly changing both the risk in the external world, as well as the kind of applications and data that the company in the business is operating on.
They're looking at it from a risk perspective, both risk prevention and risk appetite. The operations team and the line of business that owns the business understands their infrastructure and the security team are identifying both what security capabilities we have in the gaps. And the, you know, one question that's asked is, well, we've identified this gap.
Maybe the attack scenario that they've identified, that's a problem, Is out of scope for the risk, you know, I'll give a great examples, you know, oftentimes many applications deployed and they, they say, you know, physical attacks are out of scope because we have [00:27:00] guards with guns. Like we have mitigating controls to prevent somebody coming in.
We have an insider threat program that's monitoring people. So I don't, I'm not going to spend time, energy, and money to go lock down the physical attack of a given server with an additional control because I've got mitigating controls elsewhere within the organization or monitoring in order to be able to compensate.
And that's where the RISC team working with the security teams work really well hand in hand is not just understanding the particular requirements of that application or that piece of infrastructure, but what are the broader controls? That are being brought to bear and then the what the risk team is doing is informing them of what the real time considerations need to be well, we've seen now, uh, you know, we're being targeted by these adversaries are willing to spend 100, 000 to get one of our insiders to go drop a USB into a server.
Well, that changes the risk posture. So I now have to maybe put locks on the USB ports. That's another compensating control. So it's a dynamic process, but it does require bidirectional communication. between the, [00:28:00] you know, I T security teams and the, and the risk management teams along with the business application folks who understand, you know, a, what are the critical requirements and the value of our application.
I often joke that, you know, you're not going to apply the same amount of security and risk management to the football pool for the internal company as you would for the cash management system for a bank. They may be running on the same cloud infrastructure. And suddenly now I've got to ask the question, Should the internal football pool be running on the same set of virtualized servers as the cash management?
The answer usually is no, but that's again, a compensating control to help reduce the risk of one and lessen the burden on the other.
Sean Martin: Can you, can you paint a picture for us? I know every organization, every situation is different, but is, is there a general flow for how an organization. Let's just say they haven't done it yet, so they're, they're going to start, uh, looking at this, doing their mapping or the diagrams and then [00:29:00] analyzing the points and then doing the mapping to risks and applying policies and controls.
How does that, how does that line up? Is that, I don't know, it's hard to ask specific questions because everything's different, but the two week program, two month program, two year program. I don't know anything you can share to help. People listening kind of get a sense of here's how I would go about this with my organization.
I start with my CEO and I bring a working group together and, and these teams come together. What, tell us, tell us a little bit about that.
Steve Orrin: So Sean, I'll give you a couple of real world examples without naming the innocent or guilty. Um, it's, uh, Many organizations are trying to get a better handle on their overall risk and cyber security operations.
And so they are looking at, well, what should we do? How do we approach this? How do we do different from what we're doing today? Part of the guidance that I've given many CIOs, and it's typically driven by the CIO, Organization or the, you know, the CTO that works for the [00:30:00] CIO is, is the two, three key things.
Number one is start with getting the right team together. As I mentioned earlier, you want to have representatives from those different domains, from risk, from IT operations and security, from the business unit and development team, they're building the application, get them together. And one of the decisions that CIOs need to make, and it really is an indicator of success is picking the right team.
application to start with. Oftentimes organizations go one of two directions. They either say, well, our business is this, that's the most important thing. So let's focus on the most important thing. And the problem is if you mess that up, then your most important thing is at in jeopardy. Then the other side is to say, well, this is scary.
We're going to do something, you know, inconsequential over here. So if we screw it up, it's not, no one's, you know, no problems, but we'll try it out over here where it doesn't matter. And both of those strategies are actually not the best strategy. Because again, if you script the most important thing, the company's down, you know, the light's shining on you and it's really bad.
And if you're in the, it's a consequential thing, if [00:31:00] you're successful, no one cares. Like, well, that's, that was fine, but I, you know, why does that mean to me? So I often advise start with something that's sort of in that, in that Goldilocks zone, it's important enough to the organization that people care about it, that you're, you know, it's a regularly funded project.
It's getting constant updates. It's important to your customers or your partners, but it's not your most mission critical thing that operates your business. And that way you guys get that sort of the evens on that. If you are successful, it's impactful to business and people will see, Hey, I see that. This is, you know, this worked for that, and I can figure out how it applies to my business application.
And similarly, if it takes you a couple starts to get it right, it's not like you're catering the, you know, catering the business along the way. And so that, that mid tier application, a mid tier business flow is one of those key things. Another thing is trying to find something that doesn't require real time.
So think about the requirements. Real time, uh, Uh, 100 percent uptime, those kinds of requirements make it harder to be successful when you're trying new things. One other piece of guidance is that, you know, many applications are [00:32:00] just super complex. Try to find one that's at least not as complex as the other ones so that you can bound it, or at least try to bound it out of the gate.
And then from there, the other piece of advice is go do. A lot of organizations get stuck in analysis paralysis. They want to create lots of documents and big pictures and nice diagrams, and they want to run it through 12 review cycles, and it could take them two years, and they all they end up with is a big, you know, 100 page paper.
My advice is start with the plan, absolutely have the plan, and learn on the flight. Actually build the environment in the lab, get things up and running, start applying the technologies or the controls, seeing how they work. Learning is living in that respect. And so the key is to get to have a goal to get started as part of your plan so that you can move from the whiteboard to the actual implementation and be ready to do updates along the way.
And that's where the agile process of architecture comes into play of don't get too excited. Locked into this is the only way to do things because the real world is never going to let you stick with your [00:33:00] plan. Be agile to changes, whether it be the risk was, you know, you got the risk wrong or, Oh, we did the analysis and there's this other piece of infrastructure we forgot about.
That's okay. Build that into the, build your plan to be able to deal with that uncertainty as you build out and you will learn along the way. And what you'll end up with is a much more robust, uh, not only architecture, but implementation that then can be more easily applied to other parts of the organization.
Sean Martin: So I'm, I'm, I'm picturing a matrix management, uh, program here where somebody holds the, the keys to, or holds the schedule and the, and the, the plan to make this happen, uh, with a bunch of people who have other stuff that they're presumably being, uh, graded on for their annual reviews. Sure. Some organizations may place this on there if it's an important thing, but how do you, how do you find getting.
People invested in the right ways throughout the whole process.
Steve Orrin: So early buying is important with [00:34:00] proper executive air cover. Um, the other is oftentimes there's this notion, well, the CIO should run the whole show, but we have to remember at the end of the day, CIO doesn't own the business. They own the IT infrastructure and a lot of the infrastructure that supports the business.
And they're a key player, but oftentimes you can have a lot of success by getting the business owners, not just an early buyer. you know, send their people along for the ride, but to have ownership of the outcome. And so have it be part of the business transformation, if you will, be the leader to drive them because number one, they have, they're ultimately the one who's going to receive the value of this application, getting up and being more resilient, being more secure and, and operating in a, in a better fashion.
And so sometimes it's the line of business that is the right stakeholder, at least the right executive to be, get, Early buy in on even if it's run by the I. T. Or our C. I. O. Office having that executive on the business side, not only be bought in, but keep him here him or her regularly updated. Get a dashboard and show them.
Here's our plan. And here's how we're achieving. [00:35:00] But again, don't come at them with well, we configured 12 ports on the firewall. Don't give them let them understand how you're enabling their business. How is this process as you move through the process? It is. Is it reducing the amount of time it takes to get a product out the door?
So that's time to market advantage. Is it increasing the efficiency of the developers because I'm reducing the amount of complexity? So it's costing them less or am I reducing the number of security vulnerabilities that you're going to have to go back and patch? Which is a cost downstream of having of the the production system being offline because of a security event Map it to the business values and that's what you report to them So that as they're as you're moving along they can see the improvements in Terms that they can understand in terms that they value.
So when you're done, they can say, look, we were able to reduce the complexity, meaning we were able to get the job done quicker with less resources. And we're going to have better uptime because we're not going to have the same number of security events. I mean, you'll still have some, but you're reducing that overall burden.
Those are business values and that's how they get measured. They get measured on the operations of their business applications. [00:36:00]
Sean Martin: So I want your, your thoughts on two things that they're always swirling around in my head. The first is. And I've heard people say, no, we've, we've had our time as well. Um, but I've, I've not really seen it.
I believe security is due for its own transformation. Every other part of the organization's had some form of transformation that some feedback I got, we'll look at security tools and move to the cloud. I'm like, I don't know that that's really transformation of cybersecurity program, but so that's the first part.
Security is due for transformation. Um, And I also believe, well, I'll just start there, leave it there. Cause the other one is a little too little too on the other side. So what are your thoughts there? Can, can we improve the efficiency and the effectiveness of our cybersecurity program from this exercise that's ongoing?
And do you have any examples where. Something changed with the cyber program that as a result of this.
Steve Orrin: So it's a really good question. And you're absolutely [00:37:00] right. Cybersecure teams across organizations, public and private sector are due for a major transformation. Where that's going to come from is it could be from a variety of places, both from how they operate.
Um, The, you know, everyone's right now talking about the buzzword of zero trust architecture, and it's a lot of things. It's a, it's a, it's not a product you can buy. It's a, it's a methodology and a philosophy in some respects in a journey, but how we implement zero trust architecture is at its core going to transform how we operate our cybersecurity teams.
Moving away from the firefighting approach of, well, every time a vent comes in, I got to go track it down and then see what happened and close another firewall. Uh, port or deploy another update to this, you know, virus scan or what have you to a more policy driven, risk driven approach to applying security.
And then the other thing that's underneath that, that doesn't get us talked about is the understanding that it's a data centric security model or transaction centric. Security model. It moves away from the systems based approach, which a lot of IT security is. I've [00:38:00] got my, my network I'm going to secure.
I've got these systems. This one's in the DMZ. This one's in the public. This is on the inside. It's a system approach to a, uh, a transactional data push, knowing that data flows everywhere. The transaction is what I want to protect at a moment in time. And so that dynamic nature of zero trust of what's in those tenants is going to drive a change in how we apply security and where.
We apply those security controls and how they get wrapped together is fundamentally going to shift the way we implement security, the way we buy security products, how we deploy those security products are going to be shifted based on this notion of, well, I'm going to understand the thing I actually care about is the transfer of that data from the database to the user at that moment in time.
And so if I can create a policy that controls that and apply a set of controls on the access And be able to do it there It eliminates a lot of the the systemic stuff that we just kept focusing on allows me to focus it on security And if I really implement a default deny [00:39:00] secure by design kind of approach then again I'm not saying that it's okay to have a system compromised But if you've protected the data independent of the systems they're running on Then you can have an event that doesn't recreate the fire drill.
You're still going to want to patch into all your cybersecurity hygiene, but it takes away the fire drill because I know that my data or that transaction will operate independent of the given system or network that happened to be running through, because I've done the encryption later, I've done the authentication later correctly to protect it.
across those systems. And so that change in philosophy that Zero Trust is starting to get us down the road will ultimately help change the way we apply the security technologies and controls and therefore the team that's, you know, underfunded and overtaxed today can focus in on the key things that actually matter.
So I think that's one key area of how security is going to transform is moving away from the firefighting to more How do I protect the things we care about?
Sean Martin: I love it Kind of connected to this before I get to my other [00:40:00] question Mark always jokes and have too many questions. But anyway when when this exercise is being done we've talked about The diagrams and pinpointing the areas of risk.
So our conversations primarily been around risk and we talked a little, little bit about efficiency of, of the, of the op, of the system of systems. Do organizations, have you seen it where, and maybe this is common and I'm just not familiar with it. In addition to the risk overlay on that, Do we see a, what revenue we make overlay on top of that so we can see where, where the money's coming from in this view, as well as where we spending the most money, and it's that second, well, all of it together, but that second part of if we're just spending so much.
On [00:41:00] security for this area. That's not making a bunch of money. And because, because it's so complex that we're trying to do too much control and putting too much team on dealing with that complexity and exposure, that would be a beautiful thing for me to see. Do we get that?
Steve Orrin: So I would say that it's something that.
It's a pitfall that a lot of organizations fall into. Mature organizations, and again, if you read the documentation on something like cybersecurity for instance, they aspire to that goal of where you're tracking your security operations to the value chain. That's the vision. We're not, I mean, most organizations aren't there yet, but they're working towards that.
What you described is a great state to be where I've got a detailed understanding of how my cybersecurity team and my I. T. operations team are spending their time and energy. So that's the cost structure and where it's being applied and your overlay that with the value chain from the business operations.
What applications are either driving revenue or keeping the [00:42:00] doors open so they're reducing our costs and be able to map those two worlds together. And like I said, in theory, these frameworks are supposed to help you accomplish that. In practice, it's really hard, but the organizations that are starting to are starting to see some of that value.
They're not doing it for the whole macro organization yet, but when they look at particular workflows, they, you know, by having the business people, they know what the value is. They know what that particular application, you know, the rev, either the revenue generates or what it's, you know, Piece of their overall business operations is and then they can apply to understand.
Okay, where are we spending our dollars based on the current risk of the environment? And so they can start to create this, you know, this mathematical model of are we getting the most value out of what we're spending our money on? And what you'll find is that that's a conversation. What we're talking about here is not the kind of conversation your typical C.
I. S. O. With a tech background. can have. Some of the best CISOs I've worked with actually have MBAs or have got a finance background as well as a technical background because they understand ultimately when you present to the [00:43:00] board and you present to the C suite, talking about, you know, cross site scripting vulnerabilities and buffaloes isn't going to get you anywhere.
Talking about firewalls and antivirus, it's how do we apply the right risk management frameworks. To enabling the business and understanding the business environment you're living in and where you're doing value creation or value savings for the organization. And so the successful CIOs and CIOs bring that financial model to bear as part of that.
But again, it's a maturing as an overall industry, um, that we do see points of light and we've seen that we've seen some really successful ones do this.
Sean Martin: Yeah, because I, I don't know if we, we've put ourself in the corner or we've been put in the corner, but I look at sales and marketing transformation, tons of money spent.
Certainly somebody who, and I'm no offense to the marketing folks, but they're not mathematicians. What do they know? They know their marketing [00:44:00] data. What do salespeople know? Yeah. They know their sales data. And somebody in the organization says, we need to drive sales, and we, we need to, uh, leverage marketing to do that.
Let's analyze your data. Let's look at different ways and tools to, to make this possible. Go . I don't know why we can't, I can't know. I, I don't understand why Got, why we don't say, here's our risk and vulnerability and controls data. CISOs know that stuff. How can we use that to drive change for the business?
I don't know. I think we're missing the most.
Steve Orrin: I think the key there is, is measurement, metrology. In the cybersecurity domain, we have a hard time as an industry measuring both the effectiveness of our controls, the measuring risk, And measuring what, you know, our operations based on metrics that then a C suite can understand.
And there's, there are a variety of security people out there that actually writing over the last couple of years about the importance of measurement and metrology [00:45:00] as applied to cybersecurity, whether it's coming up with a better calculus for risk. That actually can hold water, uh, to something that can map to where do I spend if I've got 100 that I'm going to spend on I.
T. Security, how do I measure the more effective application of those 100 against the business operational goals at the core is being able to measure the effect of security? That has been a challenge. What's interesting is, like you said, we have a lot of the data, but we also have this sort of uncertainty problem in the Sales and marketing world.
They can say, well, we we've issued this number of emails. We had this many people come by our booth at the show. We sell this many eyeballs on our social media. They have real dollars and they can then translate to how many leads that generated, even if there's a little funny math behind the scenes, there's a tie there.
Cyber security, we often get wrapped around the fact that we the security event is unknown. I don't know how many attackers are attacking us. I'm only ones I detected. I don't know the adversaries financial model of how much money they have to bring to [00:46:00] bear. So what level of attacker I'm dealing with. So I have to assume worst case scenario.
Our measurement of risk, we always fall back on the uncertainty part. Like, do you know how many times, you know, if we're going to get data breach? I don't know. I know that we've got these compensating controls. I know that we have these risks and we have these things where, you know, gaps we've got some mitigations for, but I can't tell you how many data breaches I'm going to prevent.
It's the, that uncertainty. And so that's why it's changing the way we talk about the problem from, I just don't know why it's this amorphous risk that we have to worry about to something I can measure, which is, you know, I'm more efficiently deploying the security controls I have. I'm applying security to the risk areas that we've identified from a business perspective.
So measuring the right information and communicating that is ultimately how we can become more successful. Understanding that we, you know, the uncertainties exist for the sales and marketing. And they don't talk about the fact that. If a, you know, if, uh, an earthquake happens in some, you know, country that they were marketing to that caters their campaign, they don't have to plan for that.
That's uncertainty that's out there, but their math is what they're measuring is what [00:47:00] actually matters is how efficient was the use of my, of that social media campaign? How many eyeballs did I get? What did I reduce my, uh, customer acquisition costs, whatever those numbers are, and we need to adopt those same kind of metrics.
For security operations.
Sean Martin: Ah, well, this is something in my head all the time. Uh, it's, it's sad that it's there all the time, but it's, I'm always thinking about it. Um, all right. I, the other. Question, I'm conscious of time here, but the other question I had, and maybe just a quick thought on this, it's the other end of the extreme and it's kind of connected to this and, and the point that's in my head still that forget the risk for the moment, because if we can actually build something that has less exposure, it's going to help with the risk.
So what the question is, have you seen solution architect programs, the analysis of all this stuff where it [00:48:00] drives. Capabilities for the business that were not possible before, where security has a role and says, if you apply a secure cloud service, or if you implement MFA, or if you apply encryption to this part of the business flow, you can actually do this instead of The thing you're doing now that's very limiting.
Um, you can scale more, you can build a new product, you can reach more people, whatever it is, have you seen a way or in, in your dealings with, with folks where security has driven an innovation in business? It wasn't possible before.
Steve Orrin: So it's an interesting question, Sean, and some of it is looking at. How security plays with the business operations.
So if you take the classic model, well, business operation took an application and put it in the cloud and then came back and said, Oh, by the way, we did this, can you secure it? And the cloud people are ripping out there, you [00:49:00] know, the security people are ripping their hair. I'm like, Oh my God, you don't have anything securing it over there versus the other model, which is if security was proactive and going to a business, I think it says, Hey, you could scale your operations.
If you use this cloud service. If you flipped on multi factor authentication and turned on the security services at the cloud provider One area we've seen some success is in the case of failover and redundancy And being able to say hey there are these cloud, you know Especially like the multi cloud model where if you adopt a secondary cloud Service provider and you migrate your workloads into a bucket over there and you have them ready You can get much quicker time to recovery Because you're not having to upload your data to the cloud to another cloud.
At that time of the event, you have it already prebuilt, and so here's a mechanism of how you can get lower, you know, less downtime in the event of a, of a failure or in the case of an outage at your cloud provider. So there are examples like that's a good one. It's an easy one to describe of where it and it security can help the business unit get a value by.[00:50:00]
Adopting a technology, uh, that, that actually enables the business. Some of them, you know, like I said, if you turn on multi factor thing, and nowadays, especially in regulated industries, it's almost the rigor you got to helping them to adopt a multi factor authentication that scales with their, with their customer base.
So, Having to deploy tokens to your, your customers is a dead in the water. We've seen those examples where banks have tried that and it just was, it didn't scale well, the maintenance cost was high, but now everyone's pushed, moved to this sort of app on your phone model that, and there's some really good secure ones for doing that.
Having IT be proactive and saying, Hey, here's the approved app for phones that you can point your customers to. And you put this little barcode, you know, QR code in your application. They could sign up for multi factor. You can now scale. To all these different cloud services that you couldn't do before.
So there are ways that it can actually help the businesses scale their business or be more reliable. Um, but it's, it's not a technology. In particular, there are multiple technologies can be very it's that mindset of [00:51:00] instead of being reactive waiting for it You know for the business, you're gonna come and bother you again to being proactive And working with the business and say hey, I think I have a way to help you More quickly get adopted in the cloud or more quickly take advantage of this edge computing workflow for your for your factory By being able to provide these right security solutions so you can quickly scale, um, some of that's going to be in the update, making it easier.
So I don't have to send a human out to the field. I could do secure update to a system that lowers the cost of maintenance. That could be a business value to an organization.
Sean Martin: Yeah. I, I, uh, I want to talk to you for hours and days, Steve. Um, people would probably get tired of me, uh, ranting and raving though.
So, um, I'm going to, I'm going to thank you as I ask you for the final question in what is your, if you had to pick one thing, what would you do differently to help organizations [00:52:00] redefine cyber security?
Steve Orrin: But what I do differently, I think one thing I would do, uh, and I've tried to do this with a lot of the organizations I work with.
Is find that consumable that that easy to adopt thing to do is to get the ball rolling. Um, oftentimes organizations, you know, have that moonshot and they kind of shoot for the moonshot. And the, some of the guidance I've been given recently to a lot of CISO, both in government and in, in the private sector is look at some key things you can do to win now.
To show that you've achieved a goal in the short term as you buy yourself the credibility to get to that moonshot. And whether that's, you know, simple things like asset inventory and transparency in your supply chain or network micro segmentation, little things you could do to better secure your environment that actually have an impactful impact.
Against your risk can be very impactful. They're not always the sexiest things. It's not, well, I'm going to take this cool AI widget and apply it to online security, but you can actually create some really valuable [00:53:00] security mechanisms, some valuable security risk mitigations with some of those simple controls.
If you deploy them and that gives you the quick win and you, when you get that quick one, make sure to tell people about that quick and Communicate, here's what we implemented. We got it done in three months and we have the benefit we've gotten for the organization. So get those balls rolling is one of the recommendations that I give to a lot of organizations, uh, when they, when they do have a big moonshot of securing, you know, Chris mission, critical systems.
Sean Martin: Yeah. My favorite boss in the world gave me that advice as a, she brought me into her team once or when she brought me into her team. So, uh, I wholeheartedly agree with you. Uh, quick, meaningful wins for the win
Steve Orrin: for the win. Exactly.
Sean Martin: I love it. Steve. Well, it's been fantastic. Uh, pleasure to meet you. Pleasure to chat with you.
Uh, I'm serious when I say I could talk about this for hours, but then maybe you'll come back. We can, we can take a deeper dive on something that, uh, that is lingering in both of our minds. Uh, and so then. I'll [00:54:00] ask everybody to, uh, to follow Steve, uh, subscribe to the show, share with your friends. I think there's a lot of opportunity.
I truly wholeheartedly believe cybersecurity has an opportunity here. Uh, it's for, for transformation for itself and, and huge impact on business success. Thank you, Steve.
Steve Orrin: Thank you, Sean. It was a pleasure to be here today. I'm absolutely happy to come back again.
Sean Martin: Wonderful. Wonderful. Uh, thanks everybody.
Stay tuned for more here on redefining cybersecurity.