In light of the Okta frenzy on March 22, 2022, Okta announced that LAPSUS$ posted screenshots they were able to take from a security engineer’s computer. This security engineer worked for third party company Okta works (or worked) with, Sitel. The low down is that LAPSU$$ was able to access a computer used by this Sitel worker, who was logged into a ticketing service and Slack that Okta uses to support their business. While the Sitel worker was authorized to access these services, LAPSUS$ was able to remotely access this Sitel worker’s computer to grab screenshots and, perhaps, other data.
Because Okta, as they stated, restricted access of this worker per their role soon after detecting this problem in late January 2022, LAPSUS$ could not use this Sitel worker’s online access to perform any other action in Okta (even after they failed to add another factor in hopes to bypass the MFA used by Okta for internal access).
This blog is not another report of the Okta/LAPSU$ event in March. But rather, this blog focuses on the nature many of us IT consultants face in the world of commercial or government services. At the root of it, consulting is the practice of hiring expertise for some period of time, instead of hiring an employee to cultivate or offer the same expertise due to the lack of justification to employ this expert full time.
Employers of these IT consultancy services, including those who are self-employed, must decide whether they will provision their hired consultants with computers to perform works in support of their clients, including accessing the client’s networks or data. Clients of consulting services, in turn, have the responsibility of safeguarding their networks and data, and they must decide how they will allow consultants they’ve hired to access these objects and elements.
There are a few of ways for clients to ensure their data is protected.
Mobile Device Management
One way is by either applying their own mobile device management (MDM) to the consultant’s laptop or other mobile devices, or provision a physical or virtual machine to the consultant.
Endpoint Detection & Response
Another way is to ensure endpoint data and response (EDR) is installed on the consultant’s laptop or other mobile device. This can, of course, be done either by contractual agreements (i.e., manually managed), or MDM. Alternatively, an EDR capability can be installed onto an endpoint through a CASB.
Cloud Access Security Brokers
While Cloud Access Security Brokers (CASBs) attempt to provide an alternate means for data protection (as well as a slew of other benefits), do they truly circumvent the need for MDM? Their intention: “[a] CASB [would allow] businesses to safely use the cloud while protecting sensitive corporate data.” (McAfee) While this may sound like a great alternative to MDM, my colleague, Thomas Jefferies, Head of IT Security, would argue that is truly not the case.
“Having the CASB at the top level,” Thomas shared with me, “[may enable the orchestration of] the mandatory minimum level of access by group or role. [While a CABS may fit] between the disparate cloud solutions [as a] fantastic [idea], it doesn’t remove the need for having device level controls and management in order to enforce [data protection and access compliance requirements]. [On] the contrary, I feel a proper CASB would have integration points to be able to support MDM across the full gamut, if it [is] to be [a] complete [solution].”
You may ask, “Rahul, what does this have to do with the Okta / LAPSUS$ thing?”
Well, when we consider the Okta/LAPSUS$ event in March 2022, we would notice that the Sitel security engineer was actively logged into an RDP session on Okta’s Windows or Linux server, from his or her computer. What allowed LAPSUS$ to compromise this workstation? Okta did not reveal what led up to the observation of the hack, but we do know that LAPSUS$ was able to compromise the endpoint.
Could MDM, EDR or even a CASB have prevented LAPSUS$? Yes!
If an EDR was in play, the endpoint detection effectively could have alerted Sitel and/or Okta, and possibly even terminated the privileged RDP session (this, alone, is another topic altogether).
However, there is still another limitation I’d like to highlight with respect to MDM, which is something CASBs do not seem to offer as better alternative.
In our current capacity, MDM implementation is limited to one device management owner. This limit impacts consultancy in two ways.
One is in an obvious financial way. Let’s assume that iVision provisions laptops to employees and affiliates (i.e., contractors). iVision would want to enroll this device in their MDM. To follow along easily, let’s assume Intune is iVision’s MDM of choice. However, an iVision client may also want to have the iVision consultant’s laptop managed via their own MDM. In our follow-along scenario, let’s assume that to be Jamf. If you have deployed any MDM, you’d know that this is a problem. And thus, either you would need to provision a physical or virtual machine to better control the client data the consultant may need to use or access. Or leverage a CASB. In either case, there is an increase of cost here.
What’s the other impact to consultancy, you may wonder by now? An implicit cost. And what I mean by that: because consulting services apply a certain rate to offset the cost of expertise at a scaled rate – meaning, it may be cheaper to hire a consultant for a short term vs a staffing at a fulltime rate – having to provision the iVision consultant, in our scenario, would require that consultant to now log into the secondary physical or virtual machine. A cost that is implicit in that it now takes some fraction of time longer for the consultant to complete their work. Effort that needs to now be padded into the statement of work or services agreement. Again, a CASB would offer a better solution for data protection, but again, not on the endpoint itself.
There is a third option, however it comes at a loss cost. What do I mean? If the iVision consultant decides to unenroll his or her laptop from iVision MDM, this would not be in iVision’s interest – hence a loss. Is that loss of control worth it to iVision, according to our scenario?
So, what could an effective solution be? Federated MDM should the likes of Microsoft, IBM or Jamf were so inclined. Or even a CASB could take on the implementation of federating MDMs. How so?
The implementation of Single Sign-On (SSO) into Web-based services is made not only possible but is ubiquitous due to rapid adoption – whether SAML and OIDC as the specification of trust. The same concept of “federated MDM” could actually be a viable and more cost-effective solution. Using the same scenario as mentioned earlier, iVision with Microsoft Intune for their MDM of choice, but an iVision client uses Jamf. A standard of federated MDM could allow the Intune app protection policies or configurations to be queried and parsed to determine if the iVision’s MDM suffices for Jamf.
While ideally MDMs would support this type of federation model to provide the ability for a consultant to have their managed mobile device be inherently trusted by client MDMs, a CASB could take on this role and facilitate the policy compliance check between MDMs.
iVision – A Trusted Partner
Regardless of whatever the future may hold, one thing is certain – if Okta had an XDR determination that invoked the RDP session termination through a PAM-governed RDP session, such as BeyondTrust Privileged Remote Access (PRA), we would not have read about this lesson learned LAPSUS$ caused. iVision has expertise in endpoint protection capabilities, such as those offered by via EDR/MDR/XDR solutions, along with thought leadership and experience with identity & access management, to ensure your company or agency isn’tcompromised by nefarious actors out there.