Security Q&A on Zero Trust with Mark Morrison, CSO at Options Clearing Corporation: Part 2

In our first segment with Mark Morrison, Chief Security Officer for The Options Clearing Corporation (OCC), we discussed his beginnings in cybersecurity and what has changed over the years. In this Q&A, we continued from where we left off with identity management and take a deep dive into his thoughts on cyber resilience and zero trust.  

As a reminder, before joining OCC, Mark served as SVP and Chief Information security officer at State Street Corporation. There, he provided strategic direction and oversight of the company’s information security program, concentrating on cybersecurity defense, identity and access management, cyber threat intelligence, cloud and virtualization security technologies, and risk-based information security architecture. He also held security leadership positions at the United States Department of Defense, and the Defense Intelligence Agency. 

SailPoint: How important is identity governance in terms of cyber resilience and being able to see what’s going on? 

Mark: It’s one of the most critical aspects. I’m sure you’ve heard of zero trust that everyone’s now moving toward, at least to varying degrees. Identity and access management is critical to establishing a zero-trust model. Essentially, zero trust is about providing the right information to the right people at the right place and at the right time. That means enterprises need to have very proactive identification and authentication in place. I have to know it’s you, or I have to learn that you are dressed as somebody else. I also need to know what device you’re using. That is more important than ever now that the corporate network perimeters don’t really exist anymore, especially as enterprises are moving increasingly to cloud environments.  

Enterprises must know what the entitlements are for user roles to make sure that they can enforce some concept of least privilege and to make sure the user only has the entitlements necessary to do their job, whether they’re birthright entitlements or based on whatever role the user is assuming. 

These are certain capabilities that software like SailPoint does a very good job of performing. Enterprises need to make sure that they are correctly managing privileged users, including using multifactor authentication. Try to put as many interconnected security controls together as you can so that you can limit both unauthorized access and control the accounts. 

If the proper controls are not in place, once an attacker gets within a network, they can move laterally or conduct account and privilege escalation.  

How feasible is it for enterprises to implement a zero-trust architecture?  

That’s hard to answer. If you’re starting from scratch and you know what you’re doing, it’s not that hard to move to zero trust. What’s hard is trying to convert a legacy system into a zero-trust model. Most large organizations may not know who has access to what, and they need to solve that issue before they can move to zero trust.  

Any medium to large organization has identity programs in place, and they want to keep the business running. They have their asset management and entitlement management in a legacy environment that’s been around for a while and is very difficult for them to unwind. 

That makes it a lot more challenging; it takes a lot longer, and it’s more difficult in established organizations because every rock you turn over uncovers something that no one knew existed.  

Such stones include dead accounts. There’s always a lot of dead accounts. One issue I ran into was with legacy client/server systems built with automated service accounts. These accounts were hardcoded into the application. When implementing zero trust, you will run into such situations, and you will need to figure out how to unwind them so that you can implement zero trust in these systems and conditions.  

I think many companies are just starting to go down the zero-trust path in a serious way. What is some advice you have for them? 

Movement to the cloud is helping this process. Because the cloud has a different paradigm, your applications can run your containers and apply different IAM principles at different abstraction levels. That helps quite a bit, but that’s just one part of it. The other part is knowing your assets: your systems, applications, and people. It’s getting down to working with security, working with the business, and mapping the entitlements. And whether it’s activity-based or a role-based, there are two main ways of doing it that are structured: attribute-based access control and role-based access control. 

Once you define what the roles and entitlements areas well as all your attributes, then it’s a lot easier to implement the zero-based model because you can then isolate your back office from your production systems. Then you can tier your infrastructure into your DMZ. 

You’ll see organizations that have 800 people, for example, and they’ll have 12,000 roles. Organizations must figure out how to enable a role, define a role, eliminate roles and eliminate complexity. Instead of just continuing to build upon itself, they need to step back and rebuild the structure almost from the ground up. 

It’s not an easy road, but everybody that’s gone down it and come out the other end, from the security perspective, will tell you that it’s worth it to end up with a stronger security environment for your company. 

Is it possible that foundation can help with business efforts, as well? I’d imagine, once you have good role-based controls, the business can allocate resources more quickly and reposition people to have access to what they need more rapidly in a way that doesn’t increase risk. 

It does. And it also allows them to do it in a more automated way by enabling them to recertify this recertification. If you’re in a highly regulated environment, one of the requirements in government is a periodic revalidation of who has access to what. Having an automated program, like SailPoint and others, allows the managers to validate the joiner, mover and leaver lifecycle. 

This way, if somebody joins, and they joined this specific role or a specific department, you can set the appropriate birthright activities when they join. There are always certain birthright activities that one gets when joining an organization, like email access and access to the internet. Then there are the specific entitlements that one needs for whatever role they’re going to perform. For instance, a financial person won’t need access to the same systems a security person uses.  

Another aspect is that role-based access control enables one to transfer rights. This way, when someone transfers their job, perhaps within a department or with another department, it allows the reassignment of their current entitlements to somebody else. Alternatively, they can take those entitlements with them for a short period.  

More importantly, when it comes to the leavers in a lot of organizations, these accounts remain lingering long after someone has left their job. Sometimes this is because the accounts aren’t properly removed, and sometimes it’s because the credentials are hardcoded into the systems, as I described earlier.   

Our adversaries are aware of this, and that’s what they look for as part of their attack.  

Removing these dead accounts and shadow IT are two big things that are difficult to control in a company. Many well-known public breaches have been caused by shadow IT situations where the security organization didn’t know that a server or subnetwork existed.  Adversaries can find the resource and a way to exploit it because it wasn’t secured, and it often turns into an entry point into the corporate network because it’s connected. 

How should companies go about securing their shadow IT? After all, it’s impossible to secure what you don’t know about, so it strikes me that enterprises need to figure a way to find what is being deployed and used by their people. 

Many enterprises do use discovery tools, because discovery tools go a long way to help you find shadow IT. Enterprises also need a close relationship with the IT department within the organization. Additionally, a good portion of all of this is governance. Security professionals must sit on change and architecture boards. It’s amazing what you learn when you go to an architecture meeting and see what people try to do.  

At my company, security has to sign off on all technology. Before that, we perform an information technology risk assessment or an ITRA. In an ITRA, we look at the cybersecurity aspects of new technology or capability, and we rank it. We then apply our controls and requirements to technology, such as how people want to use it. Then we make a mutual risk-decision about the technology, depending on the technology risk we want to accept.  

We know that process is part of the inventory and our architecture. It’s very difficult when using a discovery tool to bring security in and make those decisions because it’s after the fact. It’s also more difficult at larger organizations, but it’s critical to bring security in early to make these decisions. It takes time and work, but the more energy you put into it, the better your relationship will be with the rest of the business, and you will improve the organization’s security.