The concept of "Zero Trust" has been around for a while, but it has been rekindled recently and is trending. This approach has many benefits, especially when it comes to non-human interactions with devices, applications, services, etc. And, although true Zero Trust is a longer-term aspiration that effectively ignores most boundaries, you can look for opportunities to gain short-term advantages while creating your long-term foundation. [See our previous post on "Left-Shifting" for more details.] If you have technology trust boundaries, this post will have something for you.
Even on a path to Zero Trust, you must still be diligent to maintain an understanding of your trust boundaries, integrations, and endpoints as well as the associated controls. We'll start with an example that should be relevant to anyone building technology solutions:
WitJets company has a set of legacy capabilities that have high-value in their road-map, even without significant refactoring and extension (but they still do that, too). They make material changes to their configurations to meet the needs of a growing partner and client base with releases and deployments aligned to their road-map. This includes repackaging client-server implementations such as (web) services and migrating those to the private cloud. At the same time, they are migrating some of their private cloud to a public cloud while making use of open source and mobile/devices. This is not uncommon for established businesses that have evolved through mergers and acquisitions — few have the resources to rewrite and re-architect to meet the needs in a timely fashion.
WitJets has a good Security Development Lifecycle (SDL) and uses modern processes such as Agile, DevOps, and "Continuous" (e.g., CI/CD). So, their foundation and capabilities are reasonably secure through static and dynamic analysis techniques in the context of their usual scenarios. However, as they make changes to packaging, deployments, and configurations and then add new boundaries (e.g., mobile/devices, public cloud, and partners), the scenarios and attack surfaces change in some serious and non-obvious ways.
Existing vulnerabilities get surfaced and new vulnerabilities are found in real-time, which degrades WitJets security (and privacy) posture without any changes to code or capabilities. Even their more dynamic controls such as perimeters/firewalls, active endpoint protection, and monitoring and alerting can degrade if they aren't aligned with refactored deployments and configurations.
Recently, WitJets suffered a serious and unexpected injection exploit as part of their repackaging client-server capabilities into a mobile/device application integrated with migrated private cloud web services. Their client-server application had robust injection defenses, but some were missed during the port to mobile. Further, the services had few injection defenses since that had always been a client responsibility. Hackers, including nefarious client insiders, were able to exploit injection and replay vulnerabilities in the mobile clients and web services.
WitJets was able to respond to this incident, although it was more than a little awkward to have been detected and reported by a client. They avoided any further public disclosure, but it definitely shook their internal and external confidence. Because this exploit was so unexpected and went undetected for such a long time, WitJets is now doing a more holistic evaluation of its security and privacy posture.
So, how does WitJets move forward? How do we move forward? Zero Trust should figure into any plan, but here are a few tips and practices to help to keep security and privacy aligned with your capabilities and Zero Trust aspirations:
Implement threat modeling and keep the models current for each deployment, reanalyzing the model on any changes to boundaries, endpoints, configurations, controls, etc. [See our previous post on "Left-Shifting" for practice details.]
Employ dynamic controls such as perimeters, active endpoint protection (including AV/AM), monitoring & alerting — and then reevaluate, update, and extend on any deployment changes.
Avoid the "it's just another data center or client" trap — evaluate your controls and tools to make sure they meet the specific needs of your deployments. Mobile/devices, services, and clouds have different needs that should not be ignored or underestimated. Public clouds (e.g., Azure and AWS) represent a material shift in approaches and implementations (apples to oranges in some cases) — but they also have significant benefits including for security and privacy.
Unify and converge your security, development, operational, support, and services teams so they are aware of upstream and downstream changes — make sure they are working together to add controls and mitigation early and respond to issues as they arise. [See our previous post on Ops Venn.]
Cylidify recommends that you develop a deep and documented understanding of your capabilities, scenarios, deployments, operations, and trust boundaries as well as the associated controls. Also, know your risks and your enemies, combining these details to form a security and privacy posture covering all phases of a cyber-framework: Identify, Protect, Detect, Respond, and Recover. Reevaluate on change and make steady proactive improvements while keeping your reactive capabilities sharp.
Here is some detail and debunking on Zero Trust via Dark Reading:
https://www.darkreading.com/cloud/debunking-5-myths-about-zero-trust-security/a/d-id/1334064
Comments