Let me start by sharing the foundational and most important aspect of our view of cybersecurity operations and the genesis of why we created JupiterOne. Prior to JupiterOne, I was leading the cybersecurity operations teams as a CISO at LifeOmic, a precision health software company. LifeOmic stored and processed, sensitive and protected health data. During my tenure, we built our security on a Data-Centric Model and Zero-Trust Architecture and built a software platform to support this approach.
We not only invested heavily in automated security from our inception but, based on feedback from other software companies, we productized the security management platform that we created as JupiterOne – effectively delivering "Precision Security".
Data-Centric Model and Zero-Trust Architecture
There's lots of chatters online and promotions by cybersecurity vendors of the zero-trust model recently. Yet the concept is not new. Back in 2006, IBM published a data-centric security model. Forrester and NIST jointly promoted the concept of zero-trust network security in 2010.
It is actually quite easy to understand. First, get a good grip on your data – the types of data you have, where they are stored, who needs access, etc. – and then segregate your networks into smaller, protected segments based on data criticality. Access to each network segment should be independently granted and verified based on the principle of "least-privilege", and all traffic should be inspected and logged. This extends the practice of "trust but verify" to "never trust, always verify".
If this is a model that can significantly improve the security posture of an organization, why hasn't it been more broadly adopted yet? Because it is hard – implementing a data-centric, zero-trust model using conventional IT systems and traditional operational processes is extremely costly, if not completely infeasible. This is especially true for a large, established enterprise battling against decades of legacy.
Luckily, today we have the opportunity to take advantage of the increasingly mature cloud infrastructure and software defined networks to make this happen.
Let's talk about what this meant for my security team at LifeOmic. Keep in mind I am describing one approach, not the only approach. And while this approach works for us, and hopefully many others, it may not be suitable for everyone.
Bear with me on a little more context ...
Most attacks start by taking advantage of vulnerabilities at a relatively low risk system – usually an end-user device. This gives attackers "a way in" to the corporate environment. After gaining a foothold, the attacker can now try to escalate privilege and move laterally to compromise other devices on the internal network, until the final targets are reached.
How do you ensure, at any given time and at all times, that none of the user systems on the internal network are compromised and therefore cannot further infect and impact others on the same network?
Regardless of the size of your organization, the probability of someone's system getting compromised at some point is practically guaranteed.
What if we completely take that away? What if we don't have an internal network altogether?
No internal network. (Almost) 100% cloud. Fully segregated.
That's exactly what we chose to do at LifeOmic. Each end-user system is fully independent. They are not on an "internal" network that grants them a level of inherent trust or any access to other systems.
Wait, does that mean LifeOmic's workforce is 100% remote? No. We do have physical office locations. We provide gigabit fiber Internet at the office. There is a guest wireless network separated from employee access. However, the key differences are:
- There is absolutely no sensitive data on our office networks. If you manage to get onto our office network – welcome to the Internet – but you can get online much more easily (and legally) at a Starbucks near you.
- We operate (almost) exclusively in the cloud. We use Atlassian Jira for issue tracking, backlog management and ticketing; Bitbucket as the repository for source code; Office 365 for email and document sharing; AWS for our software development, infrastructure, and production; Slack for collaboration and communication and more. Our security controls such as identity and access provider are also in the cloud.
- Each environment (cloud or on-prem) is completely self-contained. There is no network connectivity between them. Users must obtain separate access to gain access to the resources. Access policy is enforced based on the data criticality of each environment. Multi-factor authentication (we use Okta) is a basic requirement.
No production access. No domain. Individually secured devices.
Let's not kid ourselves. We've tried for decades to lock down all users and all endpoints. It hasn't worked yet and it probably never will. In a zero-trust model, if a user can never have access to critical data, why waste the energy and resources putting up unnecessary constraints that accomplish nothing but generate noise and complaints? Trust me, it's not worth it. We need to take a more targeted approach.
- LifeOmic users do not have privileged access to production systems. Unless, of course, in an emergency which follows a defined procedure that grants temporary access to only a very limited number of individuals.
- The end-user devices are not part of an active directory domain. There are simply no "keys to the kingdom". Those are Christmas gifts to the attackers, nightmares to the security team.
- Each user's device is individually secured and centrally monitored in JupiterOne with a next-generation endpoint security agent. If suspicious activities are detected or the agent is deactivated, the user's access to critical business systems will be revoked. This provides the flexibility to allow users to be a local administrator of their machines.
To sum up ...
The data-centric, zero-trust architecture gives us greater visibility and more focused controls. It allows us to create virtually air-gapped environments to better protect customer data. At the end of day, we cannot guarantee that none of our systems will ever be compromised. But we are doing everything we can to ensure that the compromise of any user, device, or network means the compromise of that environment itself and it alone.
" ...the compromise of any user, device, or network means the compromise of that environment itself and it alone."
We are "trapping" the attackers within the smallest blast radius possible that is very difficult, if not impossible, to expand. It's not a good place to be for an attacker.
This approach dramatically decreases the chance of a compromise replicating into our mission-critical environments and significantly increases the chance of detection before it is too late – effectively ensuring the security team can always stay one step ahead of the bad guys. This one step ahead is often all that matters.
You may have more questions than answers at this point. That's okay, we are here to help. We'll get there. So far, I've only described the most foundational layer of our security model. For this to work, we have implemented many other controls to allow the level of flexibility and security mentioned above. They work collectively in one cohesive ecosystem – the lack of any will significantly weaken the overall design. That's why we developed JupiterOne, putting precision in modern cybersecurity operations. #PrecisionSecurity
This article was originally published on LinkedIn.
