Security Confidential S5 E4 Sean Sweeney

Manoj Tandon:
Hello everyone, and welcome to another episode of Dark Rhino Security Confidential. I’m your host, Manoj Tandon, and today we are honored to have Sean Sweeney join us.

Sean is a very special guest. He’s a frequent author and speaker on the subject of cybersecurity. He currently leads the Field CISO and Cloud Security Advisor Group within Oracle North America Cloud Engineering.

Sean joined Oracle from Microsoft, where he was the Global Chief Security Advisor. He has held the CISO position at the University of Pittsburgh, has been the CTO of a legal technology discovery startup, CIO of a national law firm, and litigation support applications manager for the U.S. Department of Justice.

He’s got an illustrious resume and a lot of knowledge, and he started his career as a database administrator for ExxonMobil. So he’s come a long way since then, and he’s in Pittsburgh, so we’re partial to him in that way.

But in his current role at Oracle, he and his team focus on advising customer CISOs on security and compliance issues related to the cloud. Boy, that is a big topic, and that’s what we’re going to talk about today: cybersecurity in the cloud and compliance.

It’s a subject that is near and dear to a lot of people, and hopefully, Sean, you can shed a lot more light on it than others can.

Sean Sweeney:
Yeah, I’m looking forward to doing that. Thanks for the opportunity.

Manoj Tandon:
Thank you for being here. So, I’ve got to ask: how did you go from database admin to cybersecurity? I mean, that’s a jump, man.

Sean Sweeney:
All right. Well, this is the part of the podcast where I’m supposed to lie to the audience and say that I planned it all out, because if you look at my resume, it actually does look like there’s some rhyme or reason to it.

I started as a DBA at ExxonMobil and then moved to the Department of the Interior, which actually regulated ExxonMobil to a certain extent. I moved over to the Justice Department, and the Department of the Interior was their customer or client.

The reality is, look, I grew up in the Washington, D.C. area. I actually have a humanities degree. I have an undergrad in history and did my graduate work in education, but I grew up in a house where technology was prevalent. Both my parents were network engineers—my mom for the Army, my dad for some intelligence agencies, we’ll say.

So I swore I would never do it, but I got into technology and I loved it. My humanities degree actually served me well, since I spend a lot of my day communicating, both in writing and orally.

But I saw the industry grow. Back when I started in 2000, and even when I took over security at the University of Pittsburgh in 2012, cybersecurity was still somewhat in its infancy. It was still very much a network-focused occupation. Some 80% of the people on my team at Pitt had “network security” in their title.

But I had the pleasure of working in different-sized organizations in different parts of the technology stack, but always those parts that were at the intersection of IT and the actual users and business units. And that’s really where cybersecurity can do its best work, really in terms of enabling the businesses that they support.

So it just happened that I learned all the skills I needed to eventually become a successful CISO and then move on to Microsoft and now Oracle, where I can share that work with others.

Manoj Tandon:
Specifically—

Sean Sweeney:
Oh, go ahead.

Manoj Tandon:
No, go ahead. Finish your thought, please.

Sean Sweeney:
No, and I was going to say, how did I specifically make the jump? Because you see in my resume, I went from the legal world to the university to run their security program.

For those that were in and around Pittsburgh in 2011, they would have known that the university was under a number of threats, specifically bomb threats from a foreign actor that actually shut the university down during the weeks leading up to and including finals week.

The then-U.S. Attorney, David Hickton, activated the Joint Terrorism Task Force to help address these threats at Pitt. When I was CIO of a firm called Burns White and Hickton, Dave and I had a relationship. I helped Dave and the U.S. Attorney’s office with that case, and that’s what really ultimately led to my transition into the university.

It’s just a great story, and it was the beginning of Dave Hickton getting the Justice Department at a national level really into the business of prosecuting cybercriminals. He had a long history of that, including the Chinese and the Russians, which is now the policy of our Justice Department going forward.

Manoj Tandon:
Well, I have a lot of questions on that, and we’re going to get to that specifically here, but that’s a wonderful story at multiple levels because one of the things that you’ll see—and for our listeners, if you go back to past episodes and watch—you’ll see the diversity of backgrounds that CISOs and cybersecurity professionals come from.

We do a lot of support with the veterans community. We hire a lot of veterans, we support them in making the transitions from military to civilian life. I don’t think anyone should exclude themselves from a career in security if they are genuinely looking to do it. There’s an avenue by which it can be pursued. It’s not confined to being a computer science major and coming from that background.

Sean Sweeney:
That’s so true. We have so many slots open. We need diverse skill sets and mindsets. There is a place for everyone under this tent that is cybersecurity.

Manoj Tandon:
Absolutely. And there are very few cybersecurity professionals that have really, really good people skills. I think as we look at cybersecurity programs develop, that’s a key element of it, because engaging the broader population in an organization in defending the organization is a key part of cyber, and you have to have some skills to get people on that track.

Sean Sweeney:
Absolutely. The future of cyber isn’t in how good we are at operating the nerd knobs of the technology; it’s how good we are at translating cyber risk into a language that the businesses we support can understand. That’s where the rubber meets the road.

Manoj Tandon:
You know what? You just gave us the title of this episode. Thank you very much.

Sean Sweeney:
You’re very welcome.

Manoj Tandon:
Well, that’s what we’re going to begin with. So, let’s start with the cloud. This is a big topic. Everyone has a cloud-first initiative, and especially now with COVID and remote work, a lot of organizations that were on the bench with that are no longer on the bench. They were forced to make certain decisions.

But there is a difference between being in the cloud and being on the cloud, and there’s a shared responsibility in cybersecurity. There’s a myth out there that if I am just subscribing to cloud-based services, it’s all secure. What do I have to worry about? Help us break that down a little bit.

Sean Sweeney:
Yeah, absolutely. It is a point of confusion for many out there, and it doesn’t help that there are multiple flavors of cloud. So it can be confusing.

Let me sum it up and make it kind of easy for everyone.

No matter what flavor of cloud you as a customer are using, whether you’re using Software as a Service, Platform as a Service, or Infrastructure as a Service, there are three things that you are always going to be responsible for.

First is the security around the users that you are bringing to bear in that cloud. Now, that cloud provider may provide you tooling to help with that, but those identities are your responsibility.

The second thing is the security of the devices that you are connecting to that cloud. That is always your responsibility, regardless of what flavor.

And then the last is the security around the data that you use in that cloud. Now, that one’s a little more confusing; I need to put a little asterisk next to it. Because that cloud service is obviously going to have things like—or should have things like—encryption in place, but the cloud service itself isn’t going to know your crown jewels from your cookie recipes. Right? And so you as a customer are going to be responsible for wrapping extra layers of security around your most important information.

So that holds true in all three flavors of a public cloud.

Beyond that, what’s the difference from a security model between SaaS, PaaS, and IaaS? I have an analogy I like to use, and it starts with on-prem.

On-prem is your house. When you own a house, you’re responsible for everything. You’re responsible for the yard, the picket fence around it, the four walls of your house, the roof, all the electricals inside—everything.

As you move from on-prem to Infrastructure as a Service, which is where you’re peeling off the first layers and providing them over to the cloud service provider—specifically those around the physical layer, the data center, the physical networking, the physical hardware—think about that as an apartment.

The building is provided to you: the front door, the walkways, the mailboxes, the hallways. When you get into your apartment, though, everything is up to you. You have to provide the furniture, hang the pictures on the walls, all that good stuff. That’s Infrastructure as a Service, so you’re just peeling off the initial layer to the service provider.

The next layer is what we call Platform as a Service. These are things like Oracle’s autonomous database offering or Microsoft SQL platform service. This is where they’re providing both the underlying physical infrastructure as well as some of the application plumbing. To me, that’s more like a furnished apartment. It’s still that same model, but I’m giving even more responsibility over to the cloud service provider.

The last piece, Software as a Service, is like the hotel. You just kind of show up, decide what you want to put on TV, throw some clothes in the drawer, and keep yourself showered, but everything else around you is taken care of.

Those are good analogies because ultimately, in all three of those models, the cloud service provider is essentially patrolling the hallways of those buildings, and it’s going to leave you to do inside your apartment or your hotel room what you see fit—unless what you’re doing in your apartment or your hotel room spills out into the hallway and starts to impact the other guests.

That’s how I like to think about cloud and cloud responsibility.

Manoj Tandon:
That’s a very good analogy because in all three of those cases, who knocks on your door and who you let in is completely up to you.

So getting back to securing the identity, that’s yours to contend with. If you’re leaving your data open in your hotel room and someone walks in and the cleaning service picks it up, well, that’s on you; you should have put it in the safe.

Sean Sweeney:
Absolutely. That’s exactly right.

It is a big mind shift because, as I mentioned when we did the introduction, security grew out of the network control plane because that was the control plane that security could glom onto. So if you had a security problem, it started with firewalls and IDS and IPS. If you had a data problem, you got a network-based DLP appliance. It was all network-centric.

But the world of the digital estate that we’re helping to secure lives outside the four walls of our network, and so the network-heavy approaches aren’t as useful, and the identity-heavy approaches become that much more important in the cloud, namely because those interfaces are largely open to the internet.

Manoj Tandon:
Right. The traditional perimeter has been completely obliterated. Everything used to be behind our firewall, and we were controlling that entire experience. Now the perimeter is out there, and it’s not completely in our control.

But it doesn’t alleviate the responsibility of securing that information. For example, let’s say you’re using Box, Dropbox, or Microsoft’s shared drive, whatever it may be. If your intellectual property gets exfiltrated from those environments, from what I have seen in the contract language on all three, those cloud providers are not responsible for your IP, generally speaking, because the security of that data lives in your area of responsibility.

Now, if that data were compromised through some failure of the cloud service provider’s obligations on their end—it was compromised at a service level—that would be a different story. But those aren’t what we’re seeing out there.

What we see is that customer tenancies get popped by bad actors because of poor configuration, whether that be in terms of identity and access management or in terms of information protection—either not gating it properly or not having the right protections around the information.

Really, the secret sauce is the combination of the two, plus layering on a proper threat detection strategy to monitor it all.

Sean Sweeney:
Yep.

Manoj Tandon:
I would imagine putting in some kind of DLP or CASB is a part of that equation as well, if you’re worried about exfiltration of information.

Sean Sweeney:
Absolutely.

Manoj Tandon:
Zero Trust and SASE are two terms that are thrown out there quite often. If you could enlighten our listeners a little bit: what’s the difference between the two? Is this just a Forrester/Gartner thing, or is there a substantial difference here?

Sean Sweeney:
There is and there isn’t.

Zero Trust is championed by Forrester, specifically by Chase Cunningham, a great guy over at Forrester. SASE is a reboot of an older concept from Gartner. They both are trying to address the same thing, essentially the problem set that we’ve been talking about: this digital estate that expands outside the network perimeter and really brings the data to the users where they are, on whatever devices they want to be using. This is the modern working environment that security professionals find themselves in today.

The big differentiator between the two is Zero Trust tends to focus less on network-based controls. Certainly network companies will have an offering of a Zero Trust flavor, but identity plays a lot in controlling all the pieces of the puzzle: the endpoint, the users that are accessing those endpoints, and the cloud services. The telemetry around both devices and the users and their health, feeding into what data they’re trying to access, is much more important in that Zero Trust model.

SASE focuses—Zero Trust to a SASE person—is a subset. They say Zero Trust is important to do, but the other thing we need to do is extend the network out to the users. So SASE is both about security and using a lot more network-based security controls, because SASE is also about connectivity and making sure that those users have adequate bandwidth to be running these applications remotely.

If you’re focused on that in the SASE world, then it makes much more sense to include your security controls around the network, because you’ve taken care to extend that network all the way to the users.

Whereas the Zero Trust model would say, “I don’t care what network you use; open internet is fine,” because I’m controlling the endpoint, the device, and the data that they’re getting to. I can make sure the tunnel in between is secure.

I don’t think companies need to get too worried about whether we are a SASE shop or a Zero Trust shop, because both of them are security strategies to tackle this modern world. Take what works for your organization and use that. Don’t get caught up in the lingo.

Also, challenge your vendors. Zero Trust has had a little more time in the market. I remember before RSA went virtual—I was at RSA when COVID first came into the U.S. back in 2020—every vendor on the floor was all about Zero Trust. When we go back in person, whenever that happens to be, you’re going to see a lot more SASE there.

It is gaining traction, and I think you will hear more about that. The vendors that have traditionally spoken through a Zero Trust lens will now also start complementing that with a SASE talk track or reference architectures as well.

Manoj Tandon:
For a company—a lot of our listeners are small businesses, and when I say small businesses, those organizations that have less than 2,000 employees—when they are trying to implement SASE or Zero Trust, if you read all the literature on it, there’s no way they can implement every single thing that’s part of it. It would be cost-prohibitive.

What are some of the fundamentals that you would suggest to these organizations to prioritize first?

Sean Sweeney:
It starts with identity health. That’s thing number one. If you don’t have your identity estate in order—and what I mean by that for these organizations is that if you don’t have what we would have called ten years ago a single sign-on strategy—you really need to start there.

In this cloud world, identity is the perimeter and identity is key. For a Zero Trust strategy, identity is what you’re building on. That’s thing number one.

Part of that is making sure that not only is your organization using a single identity to authenticate to the myriad of services that your users use, both on-prem and in the cloud, but that you’re also wrapping levels of assurance around those identities, using things like multi-factor authentication, whether you use it in an always-on fashion or you use it in a more risk-based approach. Either way, it needs to be part of your strategy.

That is thing number one.

The second thing that’s going to be super important is device health. We live in this distributed work world now because of COVID, and that cat is not going back in the bag. Even when workers return to the office, they’re going to demand that fifth day a week from home, or they’re going to demand to go to Grandma’s house in Tennessee and be able to work there that week. The flexibility they have now is not going to go away.

So we need to make sure that we can ensure the trustworthiness of the devices they’re connecting from, or limit what they have access to based on the device they’re coming from—managed versus unmanaged. So that’s where you focus number two.

Once you’ve gotten those two things done, then you can start adding on number three, which is really more robustness around your data protection strategies. That’s not to say I don’t care about data protection while I’m doing one and two; it’s just I’ve got to walk before I can run.

Those would be the order I would focus on.

What data protection looks like are things like data classification, data masking, and data protection above and beyond standard encryption at rest and in transit. To me, those are just table stakes.

Manoj Tandon:
That’s fantastic practical advice, and all you folks listening out there, go back and evaluate your organizations against what Sean just said, because it’s critical. Those are the foundations of building a fantastic cybersecurity program.

In this arena of managing identities, especially with BYOD becoming as prevalent as it has, what is the role of MDM, and do you see pushback in the CISOs that you consult with? Do they encounter pushback in deploying MDM on BYOD devices because the end user is giving over personal control of an asset owned by them to the company they work for?

Sean Sweeney:
The first thing I’ll say—and I’ll steal a line from Brett, who was the CISO of Microsoft, my previous organization—“I don’t even have enough time to read my own email, let alone yours.”

The point is that the organization’s interest isn’t in looking at pictures on your phone; the organization’s interest is in protecting corporate assets that also reside on that phone.

For organizations that determine that MDM is the way they are going to do that, what’s key for them is ensuring they have the proper policies and related procedures in place to protect personal information that also lives on those devices.

How do you define corporate versus personal information, and how will that personal information not be used in the corporate environment? What will occur on that personal device if there is a compromise—aka, that whole device potentially gets wiped and that personal information is lost?

That’s thing number one around MDM.

The other thing is that organizations can evaluate strategies that don’t include full-blown MDM. There is technology known as Mobile Application Management (MAM), which containerizes corporate information in specific applications on the device based on the user’s identity, so they can actually have both personal and private information in the same app. I’m talking your email apps and your productivity apps.

For some organizations, that protection is enough for those BYOD scenarios, and therefore limits the spread of that corporate information to only those areas that are protected.

Note that I’m not talking about containerization, which is an older technology. I’m talking more about going full-blown MDM or meeting in the middle with Mobile Application Management. Those are the two prevalent choices that organizations have.

What I’ve found from a user perspective, though, is if you clearly outline what protections my personal information has even if you’re managing the device—aka, you’re not going to use my browser history against me in the workplace—and I understand what benefit I get by wiring up that personal device—aka, flexibility and the ability to work remotely from a single device and not have to carry around two—then most users in organizations are going to make that choice and say, “Yeah, this is what I need to do to get my job done.”

Manoj Tandon:
Well, it opens up a can of worms from a compliance perspective, whether you’re writing policies for SOC 2, HITRUST, or HIPAA. When you introduce personal devices, it’s a big can of worms.

I really like what you’re suggesting with Mobile Application Management because it avoids some of the sticky topics. A typical use case we see a lot in healthcare is—it’s not supposed to be, but oftentimes patient information is sent to a physician and it lands on their personal phone. With radiology, you see it all the time; X-rays or MRIs can go on the radiologist’s phone, and they can look at it and respond, which is great because the time to respond goes way down and the quality of service goes up. But then the data is sitting on someone’s personal device.

Sean Sweeney:
That brings up a second point that’s related. Where it starts is at an organizational level: the organization has to think about the risks they’re trying to protect against, and they need to remember that too much friction is also a risk.

Let’s go back to those physicians. I remember being in a hospital and looking over the shoulder of a physician who was using his personal phone to take a picture of information on his work-based phone to text it to another physician because it was just too cumbersome and complicated to use the “secure” systems on that corporate device.

Users are like water: they will find the path of least resistance to get their job done. They’re not trying to be a pain; they’re just trying to get their job done. They’re not security people. It’s our job as security people to give them pathways to get it done securely at the same time.

That takes an organization understanding what the important information is, how their users work with it, and how they facilitate those avenues with a strategy that allows them to balance compliance obligations, security obligations, and the productivity obligations they have to their workforce.

Manoj Tandon:
That right there was worth the price of admission. I hope our listeners—especially since 20% of our customer base is from healthcare—heard that advice.

One thing that we say in conjunction with that is, oftentimes what we have found is—like in the case of the physician—I bet no one from their security teams actually sat down with those people and explained the “why” behind things.

By and large, that’s where we see the wheels fall off the bus. A lot of people are very reasonable if you explain the “why” behind a policy. It can’t just be, “Well, it’s not in HIPAA compliance.” I can tell you that’s going to be the story of water following the path of least resistance. But if they are genuinely told the realities of the risk it presents, then people are generally reasonable and apt to follow directions.

Sean Sweeney:
I would say to that point—let’s stick with healthcare as the example—if you want to make it real for a physician or any clinician—nurses, all of them—bring it back to patient safety. Explain why what they’re doing could impact patient safety in terms of the confidentiality of information, the integrity of that information, or even the availability. We live in a day of ransomware; that’s going to hit home with that clinician.

The other thing, though, is on the security departments. You said, “I bet they never sat down and explained why it was important.” What I also bet they haven’t done is sat down with that physician to understand what they do on a daily basis and why quick and immediate access to these records is important to them.

It’s a two-way street. We need to make sure we, as security professionals, fully understand the businesses that we are trying to enable with security.

Manoj Tandon:
And that, sir, is the business side of security; it’s the human side of security. It’s something that I give our industry pretty low grades on in general. That’s just my opinion—it’s not my company’s opinion, but my personal opinion from what I’ve seen: we’re often turning knobs in a dark room somewhere, and that’s what people see as cybersecurity. It’s a people problem.

Sean Sweeney:
It is a people problem, and I think the other problem, too, is that we as security professionals take on a level of ownership of the problem that I don’t think many understand and appreciate.

That burden of keeping your organization secure is a big one, and it tends to turn us into “Dr. No” or the team that put the “no” in technology, because we just become so risk-averse.

What we forget is that the burden of the security of our organization doesn’t actually live on our shoulders; it actually lives on the business’s shoulders. It’s our job to consult with the business, advise them of that risk, and allow them to accept, mitigate, or transfer—all the things that you can do with risk. Ultimately, that’s cybersecurity’s job.

The risk that they choose to mitigate—we may implement and run those tools, depending on the governance structure of your security organization—but that’s our role. Our role isn’t just to carry that weight on our shoulders day in and day out. I think that’s important to remember.

Manoj Tandon:
Sean, let me ask you a question in terms of structures of our security teams. Do you think it would make sense to pull the CISO out from underneath the CIO and put them in a separate, totally parallel lane? I think there’s a conflict of interest there because if someone is paying your paycheck and you’re called on to critique the environment they are responsible for, it becomes a very heavy lift. That’s my take, but I’d love to get your opinion.

Sean Sweeney:
I’ve seen it done a lot of different ways. Therefore, I do have to give the consultant answer: it depends.

It depends on the maturity of the organization and what the CISO’s office is going to do.

If you are going to both be a governance organization and an operational organization, it often makes sense for the CISO to still report under the CIO for the economies of scale of systems that the CISO is using, because they’re riding on that CIO. They’re both creating the rules and enforcing the rules at the same time.

What I’ve seen in organizations where the CISO has that operational responsibility and reports separately from the CIO’s office is that you have a buildup of duplicative technology on both stacks. In an ideal world, if that CIO and CISO could work together kumbaya hand-in-hand, that wouldn’t happen, and that reporting structure of them being peers would work. But in reality, you end up with two competing technology organizations, and so you can end up with competing spend. That’s the downside.

Now, if you are a governance-only CISO and you’re relying on the CIO’s team to implement, then you absolutely have to be a peer of the CIO, reporting elsewhere in the organization, whether it’s through Legal or through Risk—which is where, in FinServ, a lot of CISOs report. Then it makes a lot more sense.

Ultimately, it’s about organizations looking at what they’re trying to accomplish, the current structure, and the ideal structure, and road-mapping out where they want to go.

But the CIO and the CISO have to do it together, whether one reports to the other or they are peers.

When I was at Pitt, the CIO was my boss from a performance review perspective, but when it came to matters of security, we very much had the understanding that it couldn’t be the fox guarding the henhouse, and that I had to have the authority to step out and contradict her or her own team—my other peers—in matters of security.

In that respect, at that leadership table, I was separate. I was the only one that had a “C” in addition to the CIO at that leadership table. That was an important distinction to make for our organization to propel the security of the university forward.

Manoj Tandon:
That’s a cultural thing, too. If the company’s culture is set up where they will permit such discourse—I know in a lot of organizations that may not be the case where you cannot contradict.

I’ve seen it a lot on cloud, where the person who’s in charge of cloud security is also in charge of the DevOps team. I’m like, “Whoa, that’s a huge conflict of interest.” The speed at which we roll things out and the way in which we secure them are under the same hat. It’s one thing if that person is monitoring the security, but it’s another if they’re setting the security policy as well. That’s where you can get yourself into trouble.

Since you brought up cloud, let’s circle back to that and hit on multi-cloud and hybrid cloud. How do you secure a multi-cloud hybrid cloud environment? Give us some thoughts there.

Sean Sweeney:
Every organization I talk to says they have a multi-cloud strategy. In reality, they tend to have a primary IaaS and PaaS provider and then a bunch of SaaS services. That’s what they mean by multi-cloud. That’s not actually multi-cloud. That’s all your eggs in one basket, plus some SaaS.

I spend a lot of time now on how to operationalize a true multi-cloud where you have two or three or four Tier 1 public cloud providers in your portfolio, and you’re leveraging those cloud assets for their various strengths.

What that takes from a security perspective is ensuring, one, that the cloud provider is going to work with you to tell you what pipes you need to plumb to securely operate their environment. That is incumbent on the cloud provider, and I don’t see it happening as often as it should.

Ideally, depending on the investment you’re making in that public cloud provider, they should be helping you do some level of that work as well.

Where I am today, we work with customers in a maturity acceleration program where we help customers do 11 key steps toward cloud maturity with our own cloud, Oracle Cloud Infrastructure. Things like ensuring that they’re using centralized identity and they’ve got their IAM roles defined, and ensuring that their SIEM is wired up, regardless of what SIEM they’re working with. And steps like ensuring that FastConnect or the network is extended in a secure way down to their on-prem hybrid environment.

Step one is ensuring that you’re secure in Cloud Number One. You need to do that across all of your clouds.

Then the challenge becomes: how do you normalize all that information?

Quite frankly, I’ve seen different organizations do it different ways. If you choose to normalize that information by just consuming all the dashboards directly from each cloud provider as they provide them, then you’re going to end up with a security team that specializes in each individual cloud. That is super expensive.

So what we advocate is not necessarily going that route, but using the native tooling from the cloud providers and plumbing that into a common set of tools that your organization is using to manage its hybrid environment. Oftentimes that will be your SIEM and your SOAR, in order to do not just incident event management, but also orchestration and automation on top of that to provide those initial layers.

Also, work to ensure that at the endpoint—whether you’re talking about an endpoint connecting to the cloud or an endpoint running in the cloud—you have a common set of visibility there as well, so that way you can, in essence, manage your clouds from a single pane of glass. But to do that means you have to do all that plumbing work.

Have your cloud provider help you with that plumbing work because the complexity in the cloud is, from a conceptual level, all clouds operate the same, but from a practice and nomenclature perspective, I at Oracle could be talking about something with one of my colleagues from Microsoft, and we’re talking about the same thing but call it two different things.

We’re in the industry, so we’re used to translating, but our customers aren’t. They rely on each individual cloud provider to help them with that nomenclature and understand what that security best practice is.

Sadly, what often is happening when customers are trying to go after these multi-cloud strategies is a cloud provider may give them a whole bunch of tools but no instructions on how to use them. If that’s the case, then what I would advise those customers to do is work with a good partner that can show you how to use that toolbox, or how to take all those Legos and build a house as opposed to just having a bunch of Legos.

Manoj Tandon:
We see that all the time. The tools are dropped off at the shipping dock in the back, and now people are trying to figure out what to do with them. It’s a real problem.

Sean Sweeney:
It really is.

More and more, I see—it’s our strategy at Oracle—to not just provide the security, but provide prescriptive security for customers and provide programs that help wire customers up, like our accelerator program for maturity.

At the end of the day, the customer needs to install the plumbing and then monitor accordingly.

Manoj Tandon:
On the accelerator program at Oracle, is this something that is offered as a standard offering with every cloud service that you bring to your customers, or is this something specialized that’s part of the implementation team?

Sean Sweeney:
This is more on the implementation side.

We start at a platform layer and ensure that we have security baked into everything we do, all the way down to the hardware root of trust. In terms of our cloud services, it’s not just that you have the security option; that security option is on by default. We try to protect the customers out of the box.

The next layer is, “Okay, I’m building workloads; how do I do them securely?” We worked with the Center for Internet Security to come up with benchmarks for OCI and then turn those benchmarks into landing zones. Customers can organize their architectures against these landing zones and actually use them to build out a secure architecture. We just launched, actually this week, V2 of that OCI landing zone based on those CIS benchmarks.

For some customers, we then take it a step further and bring in my team as field CISOs to advise them on their maturity against our own programs, but also anything related to our cloud.

Specifically to that maturity program, what we’ll do with those customers is, in many cases, bring the resources to bear to help them plumb their SIEM, or help them deploy FastConnect. Our level of investment in customers in those scenarios is obviously going to be based on those customers’ level of investment in us. It’s a bit of a give-and-take because we’re making an investment, but we feel strongly that that investment is important.

Our customers using our platform securely is key to the future of customers using our platform.

When there’s a blip in the news related to security, I can look at it and understand, “Oh, that was on the customer side of the cloud responsibility matrix.” The customer doesn’t care as much about that. They just know they got hit; they just know their house is on fire, or their apartment or their hotel room is on fire, and they want help.

We try to prevent the fire from happening in the first place, but when they do break out, we want to limit the blast radius.

Manoj Tandon:
Let’s talk about ransomware, because that is part of creating this blast radius. It’s been in the news all over the place, and I hear a lot of people in Washington give a lot of useless information about it.

At a policy level, is there anything that could be done? Is there a legislative solution to this?

Sean Sweeney:
I think there can be.

Here is what needs to happen. The thing that’s important to understand about the ransomware that we’re seeing today—I tend to refer to it as human-operated ransomware—is it differs from the CryptoLocker days, which was really kind of spray-and-pray ransomware. That was limited to single machines or single systems.

What we have today are determined adversaries using advanced persistent threat techniques to get into organizations, locate crown jewels, lay in wait, and execute their mission: encryption at an opportune time in order to force a specific outcome. That specific outcome is payment. It’s a business model.

In the sense that the intent—even though they’re using advanced persistent techniques—they’re using whole sides of buildings are missing that they’re walking in through.

One of the most common ways these actors are getting in is through unsecured RDP and SSH ports open to the internet, or using known vulnerabilities that have had patches out for 30-plus days to get into these organizations.

Once they get into the organization, they’re doing all kinds of complex and cool things to work stealthily, but from a prevention perspective, there’s a lot of low-hanging fruit we can be doing from a hygiene perspective to help out with the issue and force them onto other customers that have easier targets. Again, they’re a business model, so they’re going to go after lower-hanging fruit every time.

Where a government can help is to come up with a unified national standard, in the case of the United States, as opposed to the state-by-state approach that we’ve seen to date.

That unified national standard needs to focus on the lowest common denominator. It needs to be simplified; it needs to look more like something like the CIS Critical Security Controls, what used to be known formally as the SANS Top 20. Something like that needs to be put into place as opposed to something as big and lofty as GDPR, if we’re really focused on solving the ransomware problem right now.

Establishing that baseline across the nation would really help and would give these organizations a roadmap of what they need to tackle.

What I feel—and it’s not just based on feeling, because it’s what I’ve seen in talking with customers—is that for many of them, there’s still a lack of understanding of what the actual problem is and how these bad actors are getting in. They’re equating SolarWinds, which was a nation-state going after intelligence operations, with ransomware. The news isn’t helping because the news is like, “Whoa!” They don’t know the difference between a cybercriminal and a nation-state.

Don’t worry about that; worry about the way these actors are actually getting into your organization. It’s through really stupid baseline hygiene stuff that they’re generally getting in through.

Once you’ve shored those up, then you can start focusing on other things.

One of the interesting things they’re doing is, once they get in, they tend to turn off security controls to hide their movements. The next step in maturity, after you’ve closed the front door and put a deadbolt on it, is monitoring when my security controls get turned off. That should throw an alert because that means there might be a bad guy traversing my network.

There are certainly lots of other things we can do, but it really starts with the basics. Change the default password on your Oracle databases. I know there are listeners out there whose companies still have default passwords in there.

Manoj Tandon:
Oh yeah, you’re absolutely right. It’s those basics.

When it comes to nation-states, I don’t know that you’re going to stop PhDs who are working on ways to compromise the system. That’s not a worry that is addressable quite easily.

In a nation-state example, it’s more about detection than it is about protection. For these ransomware scenarios, there is a strong protective strategy that can prevent many of the instances that we have seen before it even gets to our detection.

A lot of companies struggle with the basics of vulnerability management. We can’t seem to get that right.

Sean Sweeney:
Yeah. I take it back a step further. Back in 2019 at the RSA Conference, they have this Innovation Sandbox award that happens the first couple days. In 2019 the winner of the Innovation Sandbox was an asset management company.

Really, what does that tell you? That tells you that we’re failing all the way at the most basics of knowing what assets we have.

And this is where cloud comes in because, if you want to take a very cynical view of cloud, there’s one thing that cloud service providers are great at: we never fall down on telling you what assets you have, because we charge you for those assets. So it’s in our best interest to tell you what that is.

Your ability to see your assets and deploy security controls to those assets and understand when those security controls or where that baseline deviates on those assets is so much simpler to do in cloud. You’re able to do it at a scale that you could never do on-prem. So that’s just another kind of feather in the cap for cloud.

But yeah, I mean, it really is the most basic stuff.

At Microsoft, I worked on a project that’s still ongoing with NIST and their National Cybersecurity Center of Excellence around how do we help organizations move their patching strategy forward. How do we help solve a 20-year-old problem?

Yes, it does start with a foundational asset management issue, but building on from there it also includes understanding the way modern patches work.

We have this legacy mindset of, you know, we need to test every patch in every environment six ways to Sunday before we can roll it out. Patches aren’t built the way they used to be. You don’t hear about or see these patches breaking systems like they used to do.

Patches for critical security vulnerabilities—it should be a matter of the risk of the testing time versus the risk of exposure of the security vulnerability you’re patching for. That needs to weigh into the equation.

So a lot of these organizations really need to stop kicking the can down the road.

The other issue though is, let’s face it, patch management, vulnerability management, asset management—it’s not sexy. It’s not managed detection and response. It’s not SIEM-as-a-Service offerings. It’s hygiene. It’s basics. But it’s important, and it’s what’s going to get you popped. Nine times out of ten, it’s what’s going to get you popped if you don’t do it right, so it needs to be invested in.

Manoj Tandon:
That’s absolutely correct, and I hope people take heed of that. Vulnerability management is a key area, and it’s one that people can work on. A lot of the tools are already there; it’s just making the necessary efforts inside the organization to make it a very high priority and execute it well.

We are already at the hour, and I want to give you a chance to plug anything you’d like to: any appearances, talks, things that you’re going to be doing, anything you’d like to let our audience know about.

Sean Sweeney:
I appreciate that.

If this was a year ago, pre-COVID, we’d be talking a lot more speaking appearances and things like that. But I’m pretty heads-down on the work that I’m doing over at Oracle and working with our customers and onboarding them to our cloud in a secure fashion.

So what I want to plug here is the advice that I’m kind of exposing, because it’s the advice I live by. It’s what I told my customers at Microsoft, it’s what I tell my customers now at Oracle, and it’s what we as a community need to be following. To me, that’s what’s most important.

I’ll be sure to come back when my next book comes out, and we can talk about some other things.

Manoj Tandon:
Please. We would love to have you. That would be fantastic. Just last week, we had Michelle Wucker on, who wrote You Are What You Risk. She’s a New York Times bestselling author. When you put a book out there, it would be great to have you back here, Sean.

Sean Sweeney:
Love it. I will definitely do that.

Manoj Tandon:
Sean, thank you so much. You’ve been very generous with your time.

If people want to reach out to you, is your LinkedIn profile the best place? Should we have them message you there?

Sean Sweeney:
Yeah. In post-production, we’ll throw up the URL for that, and folks can reach out to me that way. That’d be the best starting point.

Manoj Tandon:
That’s great. I’ll put that in the show notes; we’ll make sure it’s there.

Sean, again, thank you so much. I appreciate it. It’s been a wonderful conversation and great advice.

Sean Sweeney:
Thank you. I appreciate it as well. I’ve enjoyed it and I’m looking forward to doing it again sometime.