![Solving for Machine Identity Visibility [Venafi + Palo Alto Networks] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2Fa8d37975-6319-427a-9a4e-fdd5b03e206c%2Faid_field_img__9bc9a14016594c0cf2bdcbff02c4e79a.jpg%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_BHtzFuj7x8fHcssjFHrhmmifkwhC){kind=small}
The ability to discover ALL machine identities belonging to an organization has always been a bit of a challenge. There is a LOT to consider when attempting to build a complete and accurate inventory. Organizations must consider factors, such as unreachable network segments, air-gapped environments and/or other blockers that limit Venafi’s built-in discovery functionality—all of these should be accounted for during the initial discovery phase. As our industry has seen time and time again, it only takes one misconfiguration or one expired certificate to bring down an entire application, potentially impacting not only revenue, but also brand reputation.
There is some good news, though. The process doesn’t have to be complex. Using Venafi and Palo Alto Coretex Xpanse together, organizations can ensure they’ve got a comprehensive inventory of ALL machine identities used throughout their infrastructure. And, with the full inventory imported into Venafi, automation can be configured and tested and ultimately replace manual, error-prone processes that lead to those certificate misconfigurations that cause outages and result in lost revenue and damaged reputation.
CIO Study: Outages Escalating with Massive Growth in Machine Identities
Where are all my machine identities?
Consider a public facing web application utilizing a TLS machine identity to secure traffic. For this example, let’s say that web application is https://bank-app.com. As an end-user of that application, you’re presented with the TLS machine identity for “bank-app.com” when you visit the proper URL. Behind the scenes, that application may be served to you by a stand-alone web server (unlikely), or it may be fronted by a load balancer, WAF, proxy, etc. (more likely). In the latter case, the “bank-app.com” machine identity is presented to you, the end-user, by the load balancer and that’s all you see from an end-user perspective.
On the back-end, additional machine identities may then be used to secure the connection between multiple web server nodes and the load balancer itself. These TLS certificates (appserver1.bank-app.com and appserver2.bank-app.com, for argument’s sake) may not be important to you as an end-user, but they are vitally important to the application itself. If just one of those machine identities is mis-configured or isn’t renewed and put in place before an expiration, a certificate outage will happen.
Another, related risk is unnecessary certificates which are left exposed, but which no longer serve a purpose. Consider the same infrastructure from above. There are only two web server nodes currently serving the load balancer. Last month there were three, but a decision was made that the third server was an unnecessary expense. There’s only enough traffic to warrant two app servers, and so the order was given to spin down appserver3.bank-app.com. The team responsible for the load balancers removes the third server from the configuration and so it’s no longer serving traffic to end users. BUT, the infrastructure team is busy and doesn’t get around to decommissioning the server for a few days…a week…or maybe it’s forgotten about completely. What that leaves behind is a legitimate TLS machine identity that belongs to the organization and is still active, but which is left vulnerable due to an incomplete or manual remediation process.
It’s those unknown or lesser-known machine identities that usually catch organizations off-guard, and that makes sense when thinking about things from an operational perspective. It’s very likely that the team managing the load balancers is not the same team who’s responsible for the application servers. If the company utilizes traffic inspection devices to monitor and prevent threats hiding in encrypted traffic, there’s another, separate team. The InfoSec team who is responsible for creating and providing machine identities to these teams, different still. For the record, that’s four different teams, all responsible in one way or the other for the security of the application and the users. In that scenario, it’s easy to see how manual or siloed processes can cause issues—and that’s only considering a single application. How many organizations can you think of that only have one application?
Attack surface management: Discover, Automate, Repeat
Palo Alto Cortex Xpanse is an automated attack surface management (ASM) platform that provides a complete and accurate inventory of an organization’s global internet-facing assets, including TLS machine identities and, more importantly, any misconfigurations associated with them.
When Venafi’s built-in discovery capabilities are augmented with data from Xpanse, it ensures organizations have a comprehensive inventory that includes all internet-facing AND internal-only machine identities. With the complete picture, it’s easy to see every machine identity associated with an application and ensure that they are all managed securely with the same level of importance and urgency.
Full automation is the final piece of the puzzle and should be the target end state for every organization. With the combined solution in place, ALL TLS machine identities for the organization are renewed according to policy before they expire and provisioned down to the end devices that utilize them to secure traffic and communications, without the need for any hands-on keyboards.
Venafi + Palo Alto Networks integration
Good automation saves companies time and resources by removing manual process from what should be hands-off operations. Misconfigurations become a thing of the past since the entire process has been tested and automated—normal human errors like typos and accidentally missed notifications simply disappear. What would you do if you didn’t have to worry about manually managing machine identities for your application? Most people’s answer: “Literally anything else.”
Let us help you get there! If you are attending Palo Alto Networks Ignite 2021, November 15-18, come stop by the Venafi booth and speak to one of our representatives. You can also learn more about the Venafi and Cortex Xpanse integration on the Venafi Marketplace.
This blog features solutions from the ever-growing Venafi Ecosystem, where industry leaders are building and collaborating to protect more machine identities across organizations like yours. Learn more about how the Venafi Technology Network is evolving above and beyond just technical integrations.