John Tolbert: Zero Trust for Reducing the Risks of Security Incidents

So, yeah, that's our topic today. And I thought it's good to begin at the beginning and cover, you know, some of our core security concepts like CIA confidentiality, integrity and availability. And in this case with regard to zero trust, confidentiality, meaning not allowing unauthorized access to information or resources, integrity being, not being able to have those resources changed by unauthorized parties. And then availability is simply keeping services and, and resources up and running and available.

So some of the risks that we see that were made the news in late 2020, and continue to make the news even today, as they relate to confidentiality and integrity are the solar winds incident. It has mini names today. Sunburst is the malware gate is micro Microsoft's name for it, but I also wanted to point out the Ticketmaster finding and then the Oldsmar water treatment plant in Florida that you may have heard about just in the last couple of weeks.

And on the availability side, there were some fairly significant cloud outages, as you can see listed here over the last three or four months, that did impact not only consumers, but many businesses as well. So availability is also an ever present concern as we head into 2021. Something happened there. Okay. So on the confidentiality and integrity perspective.

So with solar winds, the solar gate event that as you know, probably had to do with getting malware, actually into an it supplier solar winds network management software, what was particularly insidious about this is they were the a P T threat actor was able to get that into the build process. And then that in turn was able to be used against thousands of downstream organizations with Ticketmaster. It was a case that, and it's insider threat. Former employee essentially copied a whole bunch of competitors, intellectual property and provided that to Ticketmaster.

There was legal judgment against Ticketmaster, but you know, it wasn't a particularly heavy fine, but again, that's a breach of confidentiality by having a former employee take intellectual property from one company to the competitor. And really what's common between all three of these in some ways. And with regard to the Oldsmar Florida water treatment plant, it's about too much access.

You know, the, the former employees shouldn't have had access to Ticketmaster data. Malicious actors shouldn't have been able to get access to the solar winds build environment. And then the water treatment plant should not have been able to have been compromised from outside, especially threats to availability include the ever popular DDoS attacks. They're still out there. They may not make the news as much, but they're ongoing all the time.

And then just general cloud service provider outages that may not be a result of a cybersecurity incident, but still can have a very negative effect on business performance. So what do we know so far about solar winds? We'll do a real quick overview of what's been published. Like I said, this solar winds was just one of the major vectors, but this has a lot of names you see now, solar gate and sunburst. This was actually a timeline published by solar winds themselves.

We see that activities started way back in September of 2019 when the threat actor first accessed solar winds build environment. And this was a very methodical campaign.

They, they built the code, they tested it. They figured out that they could make sure that it was always present in the builds and, and had configuration control over it.

I mean, it was, it was quite sophisticated. That word gets used a lot with the tax, but it's certainly not overhyped in this case. Then at the end of February, it was compiled and deployed to customers. It's believed that it was live from March through June or thereabouts about 18,000 solar winds customers reportedly had downloaded that. And then as we often hear, the meantime to detection can be five or six months.

It went from June until about December when fire eye noticed activity and alerted solar winds within a few days, solar winds made their filing and notified customer shareholders and then produced a software fix for it. Cybersecurity agencies around the world issued alerts soon thereafter. And we're still learning about, you know, the effects and how it was perpetrated even today. So meantime to detect kind of follows that pattern of six months, meantime to resolve is, you know, we're two months into it now and it's, it's still not over. We'll likely be working on this for months to come.

The companies and organizations that have fallen great to it. So besides solar winds, or at least with solar winds, we know, or the Orion management product also the serve U FTP server was recently reported to had been compromised. FireEye forensics tools may have been copied, but they weren't compromised. Office 365 email was compromised for some customers of solar winds. That's how they were one of the targets that they had attempted to acquire on Microsoft ADFS.

It's also recently been learned that Microsoft MQ server and old version was used by the solar winds deployment and it was compromised. And at least one case they were able to compromise the Cisco do multifactor authentication for one customer in order to gain access to their outlook. Web access. Malwarebytes bites is also believed to have been affected by the same threat actor, but probably through a different vector. Mine cast may have been a, a victim too, but there's uncertain attribution around that. What impact does this have?

Well, largely attention has been focused on government agencies, particularly us, UK, Belgium, Canada, Israel, Mexico, Spain, and UAE. So it really has a global impact on government agencies, but also up to 18,000 companies, including 250 other major companies, including other members of the it supply chain. So that's why this is fairly significant. There have been three identified stages in the attack.

Stage one would be the simple implantation of the malware, those 18,000 companies that downloaded it signs that that has happened, or some that something more than an innocuous software install happen would be initial signaling to the command and control domain stage two, a little bit more serious where different C2 domains may have been contacted. There may have been a reconnaissance or looking around the internal environment.

There are multiple indicators of compromise available that are available through cyber threat intelligence sources to help companies or organizations determine whether or not they've made it to stage two. Stage three is, you know, full compromise, lots of signs of threat activity or activities, including data exfiltration, manipulation of active directory accounts. They added accounts to talk more about that in a minute SAML tokens, and even the unauthorized edition of federated trusts.

So that's another way in which, you know, this is when people say it's a sophisticated attack, it really is pretty sophisticated. So what do we know about the solo winds posture over the course of the last year?

Well, it's been widely reported that on their update server, solar winds, 1, 2, 3 was the password it's recently been discovered that the password was used inside the Microsoft SQL server express edition that shipped with solar winds, Orion management password spraying attacks may have been used to get initial access or some accounts say that insider accounts were found on the dark web. That could have been the initial vector into solar winds itself. Solar winds told customers that they should turn off anti malware scans from the directories where it was installed. That's really a bad idea.

They didn't have a CS C I O until fairly recently. And then they used out date Microsoft message, queue server, and SQL express. And with those, they did not require authentication, authenticating the messages that went into the queue and the admin user password was recorded in plain text. So how did they conceal what was going on at victims? They use VPNs for data X filtration that's, you know, fairly standard in some cases, what made it really different here though, was the use of in-country IPS for command and control that decreases suspicions.

If you're using things like EDR or XDR or sore products, you know, you're not necessarily phoning home to some, you know, distant location where it would automatically erase suspicions of large data transfers were happening. It was also reported that stagger geography was used hiding data and nontraditional file types, sandbox detection, where the malware would refuse to run. If it thought it was in a sandbox, that's also a capability that's found in more commonly in advanced malware this way, it doesn't set off alarms and can conceal itself variable communications delays.

That that's also a technique that's been used by a P T actor groups in the past, you know, just exfiltrate everything all at once. It's slow and randomized again. So as not to trip over any sore SIM type products, and then lastly here, spoof Sam tokens without a corresponding local login event, generally there needs to be a local authentication event, but the malware itself was taking control of the Sam infrastructure and generating Sam tokens for the use by the threat actors, persistence like many forms of malware. It would load as in native service.

So every time you would boot it would come up again, it had fairly complex process monitoring. It would only allow one instance of itself at a time to run. And it insured that the proper infected version only ran during the period when the campaign was going on, it added specific accounts to victims, active directories, and those accounts were different between each victim. So far as has been discovered, they also added tokens and certificates to different target services. This is how they were able to get access to like Microsoft office 365 and exchange.

And then again, the addition of ADFS trust to allow the threat actors to more easily federate into their victim environments. So how to detect U S C I S a has put out a Sparrow script. It's a PowerShell script, open source thing, GitHub, but three major conceptual ways to look for it are impossible. Travel between login events for the threat actors.

You know, one account, maybe it's an account that shouldn't be in your active directory anyway. But if you notice it's logging in from different locations where it's physically impossible to do the travel, that's a good reason to suspect it. These SAML tokens, they were noticed to have some unusual features like long validity duration, durations that are far longer than what most company policies would allow. They may not be conveying authentication level information inside them when it's required.

And again, there may not be a corresponding local login for this SAML token. There are indicators of compromise available for threat intelligence providers. And if you're subscribing to those services, which probably should then as they are discovered, they're released. So companies in stage one and two, if you suspect you're in that state, then you have to rebuild your hosts. You should create brand new accounts for solar winds usage. You should require multifactor authentication for users of solar winds.

And then since service accounts were affected too, you should use privileged access management products use Pam to lock those accounts up into vaults and record activity for stage three victims. You have to rebuild solar winds, but it's really, here's where the hard work comes in. You really need to perform a full IAM audit. Look at all your active directory accounts, Azure ad, look at your ADFS configuration, other sale infrastructure and purge it if necessary. It's time probably to do a full access reconciliation, look at all the permissions.

I mean, if, if the threat actor has edited accounts, permissions, certificates, tokens, whatnot, it all has to be cleaned up or, you know, they could, you know, reestablish a foothold and then there may be other apt response actions you have to take depending on what your IR team or consultants may advise you to the, so just a little more on Ticketmaster and Oldsmar, not to forget them, different actors, different motives. The Ticketmaster case, again was a former employee who copied confidential information. That was a case where it was too much access.

That user should have been deprovisioned Oldsmar, an unknown actor got access through an unused team viewer account. So, you know, from a zero trust perspective, get rid of software that you don't need get rid of inappropriate remote access and use multifactor authentication to discourage password guessing.

So, as we've been talking about today, zero trust architecture is more than just networking. It's about authenticating and authorizing every action in an environment. I won't say on the network, cuz it's more than just a network it's, you know, users and what do we mean by users? It covers not just partners or employees of partners, but contractors and consumers as well.

They have to be provisioned appropriately with the right amount of access, but also deprovisioned immediately so that you don't wind up in a situation like the Ticketmaster event, compromised credential intelligence can help prevent unauthorized account takeovers devices. This is, you know, not just computers and mobile phones, butt devices can be part of an authentication environment that can collect environmental attributes, you know, especially location and time to day and things like that.

And then there are device intelligence sources that can provide you with additional factors about the device identity, the health of the device and the reputation of the device as well. And then it should be considered on a resource by resource basis.

And again, this is more than just networks, but the actual endpoint devices, themselves data elements, and then the servers, applications and services that host the data. Ideally we would all be using policy based access controls with really rigid data access governance processes.

But again, it's the authentication of users, applications, devices upon every request to a resource with proper authorization as well. So how does this affect the supply chain?

Well, if we improve confidentiality, integrity and availability in the supply chain, one way of doing that is implementing zero trust architecture, which is a process, not a single product it's it's about right sized access for any, any resource request in the environment, especially in the case of like remote access for the Oldsmar, Florida water treatment facility and deprovisioning, deprovisioning, terminated employees and contractors, you know, on the solar wind side, I think we have to subject vendors to much more rigorous security scrutiny.

There's, there's a trust that's implicit and zero trust means, you know, trust, but verify. So I think it's imperative that we, as a community put more pressure on the it supply chain to ensure that they are following best practices and can demonstrate that on the threats to availability, we see more and more companies and organizations using edge services, doing that authentication and authorization for resource to access at the edge. I think 2021 on again on the availability side will be the year where we talk a lot about multi-cloud.

If you're running services and infrastructure as a service public providers, I think now is the time to start thinking about multi-cloud strategy for availability. If you are using SAS application providers, you may want to inquire whether or not they are also doing multi-cloud hosting. And we see on the horizon, multi-cloud hosted and synchronized Ida or ID as a service. And I think this is especially in response to cases where you have large IDPs with major outages affecting business application and authentication for lots of different enterprise services.

This is something that we're gonna see a lot of development of in the not too distant future, just to meet the availability needs of enterprises today.