On this episode, Darren discusses zero trust security with Intel’s Steve Orrin, CTO Public Sector, and Cameron Chehreh, VP-GM Public Sector.
The old model of security could be compared to a castle, with guards along the road and a moat surrounding the castle. All of the crown jewels, in this case, data, would be centrally located and managed inside the castle. The emergence of zero-trust has created a new framework.
The biggest threat to the data is the end-user, so the number one strategy is a framework that starts on the outer edge with pillars of excellence with interior protections. This updated way of thinking allows organizations to bring their mission and business partners into the conversation in a real way.
The old style of thinking was more of a hard-shell approach, with protections and controls in places of vulnerability. A key part of zero trust architecture is a risk-based approach, which is more dynamic based on two things: what has worked and what has not worked in the past. So if the attackers came in the left door the last time, you will, or course, shore up defenses there, but you will also learn from that attack and shore up other places based on new knowledge of how that happened. A risk-based approach is not just solving for the last attack, but thinking ahead and applying the right controls for current and future threats throughout the enterprise.
Part of the risk-based approach is understanding the ecosystem. Customers, partners, and users are all part of the security calculus. The old hard-shell approach doesn’t work. Just as a castle has people and supplies coming in and out, and the riches might be located in various locations around the kingdom, zero trust takes the security one step further, accounting for all the ingresses and exits for the data or the people who are accessing it.
Traditionally, someone could get access with a single sign-on into the corporate castle. There are several zero-trust principles, but the two foundations are default-deny and continuous monitoring & authorization. Trust is not automatically earned, nor is it permanent. For example, if a guest entered the castle, they are validated at the reception desk and then asked what they are visiting. They might be granted access to visit one person in one room for a certain amount of time, and they will be escorted in transit. They will also be monitored for what they bring in and out on their visit.
Zero-trust applies to access in all locations: data centers, clouds, edge devices, business environments, etc…. It’s data-centric and access-centric, married with a risk-based approach. There must be more strategy involved. The resulting zero-trust-based approach does not throw out what has worked well before, but combines the good processes, principles, and technologies and adds a temporal element.
This new element is not as difficult as it has been often portrayed, but it is a process and cultural problem which can be tricky.
Many developers have a fear that a zero-trust architecture will slow them down, but security experts and developers need to have a partnership to overcome that perception. A real-world example is Log4j. Six months ago, developers could download it with no problem, but now the threat environment has changed. Without a risk-based approach, a developer would be able to download Log4j until someone from security came and shut it down. With a risk-based approach, along with access approaches, Log4j would be unavailable and an alternative would be offered. Another example would be when Log4j is already incorporated in a product, the dynamic trust assessment could put in extra controls rather than locking it down entirely. It’s about both sides of the calculus in play.
This partnership is similar to the cross-training and information sharing that goes into building security into the development process. As a product is being built and tested, security is also monitoring and assessing risk for both the entities you are working with and the product vulnerabilities in real time. Building a risk-based approach in the process leverages intelligence that gets to the heart of a lot of what we perceive as difficult.
What is the first step for CISOs, CIOs, or CTOs to initiate zero trust? Cameron suggests quitting “geekspeak” and communicating in common English. Getting the initiative going can be challenging because typically leaders work with an outcome or objective in mind. Zero-trust does not have a defined objective to work toward other than creating a more highly assured environment for users to operate in. There are, of course, KPIs and other measures to show increased security, but it’s a journey, not a destination. He also emphasizes continuous funding; don’t embed the cyber budget in the IT budget. It needs to be separate and distinct.
The best place to find high-level information with practical guidance is the NIST publication SP 800-207. It also lays out the five pillars of trust, which are good starting points.
A primary foundational aspect is to have a good asset inventory of what needs to be protected such as data sources, databases, business processes, and transaction applications. Basically, you need to define the perimeter of your castle. It’s important to not just think about what you own, but what you rely on such as the SAAS environment, the cloud infrastructure, and third-party tools.
The bigger picture is knowing your value chain. It’s not just what’s in your castle, but it’s how you make money, how that money is distributed, whom you pay, and your providers. Each is a critical piece of the chain.
Notices and Disclaimers
Intel® technologies may require enabled hardware, software, or service activation.
No product or component can be absolutely secure.
Your costs and results may vary.
Intel does not control or audit third-party data. You should consult other sources to evaluate accuracy.