We reviewed Zero Trust in a series of blogs earlier this month. In this blog, we are discussing a new product in tech preview to help address some of the ideas discussed in the Zero Trust Blog Series. You can review the previous blogs here: 

• The End-to-End Zero Trust Journey: How Did We Get Here? 
• What is Zero Trust? 
• Expanding Zero Trust Architecture Concepts to APIs 

Introducing Project Watch 

Last year, VMware announced the industry-first elastic application security edge (EASE), which enables the networking and security infrastructure at the data center or cloud edge to flex and adjust as app needs change. To help customers preserve their investments in expensive hardware appliances that are incapable of adapting to changing app environments, VMware is introducing Project Watch. 

Project Watch (Figure 1) is a VMware initiative in operations manageability of secure multi-cloud connectivity on top of existing or future security controls. Watch will provide: 

• Automated and encrypted multi-cloud connectivity across Clouds (AWS, Azure, and GCP), Cloud Zones (VPCs and VNETs), and security operations increasing service agility and stability (fewer human errors) with less cost. 
• Continuous, end-to-end, risk and compliance assessment and a diverse set of adaptative risk mitigation actions to help ease policy management. 
• Accelerated app time to market. Within a single platform, Project Watch integrates workflows of SecOps, CloudOps, and line of businesses, enabling more efficient communication between teams 

Continuous Risk-based Security and Compliance

When we think in terms of availability, we managed to have industry standard terms like “five 9s” as a measurable way of what our SLOs are. There is much to unpack behind the statement “99.999% availability”: it conveys an SLA. It implies all the associated efforts and best practices needed to achieve that number or the reporting implications if a service fails to achieve its desired SLA threshold. 

Project Watch aims to introduce a new set of security metrics that convey a well-understood and industry-agreed level of risk and compliance. For example: “only end to end (user to app, or app to app) transactions with a risk score less than 73 is acceptable”. This manner of assessing a risk threshold allows for a customizable set of mitigations as the risk approaches, hits, and surpasses the acceptable level: the end goal is to allow more transactions by remediating risks, not to block as much as possible. Risk mitigations are not always binary decisions, like ridged Permit/Deny rules in a standard access policy. You can employ Mitigations to keep the ‘allow’ decision a yes for a better overall experience while satisfying InfoSec lead compliance concerns.  

Working in concert with traditional Permit/Deny gated policies, Project Watch (figure 2) continuously assesses the risk of the sources, destinations, and messages in the form of a transaction and provides the following:  

• Access decisions to become continuous and adaptive – enabling real-time decisions that balance trust, risk, data sensitivity, and business criticality at the speed of digital business. 
• We can now have the confidence to say “yes” or to mitigate risk to be able to say “yes” and enable interactions in situations where previously the default answer would have been “no.” 

This approach requires multiple things need to happen. We need to have an open ecosystem of integrations where the risk/trust factors are going to be provided by multiple products and vendors. Additionally, we need to have a comprehensive industry initiative to standardize the meaning of risk scores and the continual monitoring and evaluation of a stated set of risk/trust factors to guarantee end-to-end risk enforcement. 

VMware is working towards an open set of integration and definitions to rally the industry towards addressing these two mentioned areas. To do this, Project Watch (figure 2) has a flexible and open risk framework that provides: 

• Indicators of Risk (IoRs) can be taken through integrations such as 3rd party security tools, workload labels, environmental context, and as part of the session between sources and destinations in the form of the message that includes the operation and data classification. 
• IoRs can be categorized into buckets, such as Strategic, Operational, Security, and Compliance indicators, and used to measure the risk potential of the sources and destinations.  
• Realized risk is then calculated continuously as part of the transaction, which includes potential risks of the source, destination, and the message to form a transaction risk. 
• This allows for baselining of risks across applications and environments using standard risk profiles, flexible mitigation of risks based on thresholds  

Stay tuned as more about Project Watch is released over the next few months.