Application owners are used to a distant relationship with their security and network teams. The network is supposed to “just work” and firewalls are a pain to be endured infrequently. After all, the infrastructure doesn’t feel “close” to the average application owner. But when the security and infrastructure teams announce that they want to move the enforcement boundary onto the operating system or to ring-fence the application, suddenly abstract concepts take on a new reality.
The primary fear is that implementation of the controls will be incomplete, causing outages, or perhaps that they will degrade performance or otherwise cause headaches that didn’t exist before. It is also generally true that on the application server instances, the application team wields considerable control and can often delay implementations if their concerns are not addressed. So, how do we develop a durable, trust-based relationship with our application owners, DevOps and cloud teams?
TAKE THE HIPPOCRATIC OATH
For application owners, service availability is at the top of their list, and often comprises a portion of their MBO’s or performance bonuses. Anything that threatens application uptime will encounter immediate resistance. For this reason, it is import for the application and automation teams to know that you’ve effectively taken the Hippocratic Oath – you won’t allow their application to be harmed in the development of the micro-segmentation policy. Remember that they have been conditioned by firewall cutovers and re-configurations to expect breakage any time micro-segmentation rules are adjusted. But it doesn’t have to be that way. By choosing a solution with a strong “Build, Test, Enforce” methodology, all micro-segmentation policy will be thoroughly tested for as long as it takes to ensure correctness.
During the initial deployment, don’t try to sprint past requests to test or certify host-based agents. Any quality agent will fly through testing. Choose an agent that is not in-line to traffic, that isn’t a virtual network adapter and that doesn’t modify the kernel and application owner acceptance will skyrocket. Avoid in-line agents that fail either open (no firewall policy) or closed (the app breaks). Choose an agent that is certified to run in mission critical environments, like Oracle Exadata, and there becomes very little question that the agent is unsafe. When you combine a safe agent with a safe path to enforcement, the application owners and operational teams can understand that you share their concern for the safety and uptime of the application.
EMPOWER THEM TO PARTICIPATE
But any quality Zero Trust Segmentation solution will go far beyond assurances of safety and offer the ability for the application owners to participate meaningfully. At a minimum, give application owners access to the visualization of their application using Role-Based Access Control (RBAC). As soon as they see the application dependency map, the app owner can verify that the flows observed are expected and should be permitted. As the policy develops, the app owner can see that the necessary core services, database connections, and user access methods are permitted. They get to be part of the approval chain to ensure that the policy both secures and enables. Some organizations go further and give the application owners control to author the internal application policy. When provided under tight RBAC controls, each app owner is only able to see their own app, and policy control can be delegated and limited as desired. With final approval reserved for the security and infrastructure teams, this gives true ownership to the operations teams and increases confidence and connection to the outcome.
PROVIDE THE ABILITY TO AUTOMATE
Almost all apps built in the last several years are automated to a large degree. They stand up using scripts provided by the vendor. They offer API’s and often integrate with SaaS, cloud instances, containers or other advanced application hosting technologies. For DevOps teams, anything lacking an API might as well not exist!
Historically, application teams have been frustrated with the slow pace of manually typed micro-segmentation rules and the processes that surround them. So, deliver segmentation as a service! Give them API keys to your Zero Trust Segmentation solution. Ask them to use their metadata as the source of label/tags/policy abstraction. If their metadata becomes the starting point for visualization and policy, micro-segmentation can simply be requested from the API, and automated from day one. Show the application teams how to access segmentation as a service – encourage them to build it into their run-books and golden images and then you will be talking their native language. Everyone benefits when the micro-segmentation policy is continuously updated throughout the application lifecycle.
The business depends on applications, and the teams that provide and support them are not used to the detailed technical asks a firewall team traditionally requires. But Zero Trust Segmentation doesn’t have to bog them down, or cause them to put up roadblocks. Properly communicated and resourced, a micro-segmentation deployment will safely let the application owners interact with the project. The best project teams further invite them to consider micro-segmentation as an available API-driven service – just like the other SaaS services they regularly consume. When advanced micro-segmentation is easy to consume, safe to operate, and under their ability to control and influence, you will find the application teams willing to help you secure their systems from the threats that no one wants to affect their systems.
Learn more about application segmentation today.
Questions About Micro-Segmentation You Don't Know To Ask: What Does It Take To Get Your Application Team on Board?
