[The following is an excerpt from a 57-minute long webinar on Zero Trust you can watch on-demand here.]
Zero Trust is not just a tool: it’s a journey. And just like going on a journey, there isn’t a single route you must take to get from here to there. Your route will depend on many factors unique to your business. To help you find the right route you should take along your Zero Trust journey, our security experts have compiled seven guidelines you can use to plot your own course.
1. There Is No “Best Practice”
Clients often ask us for Zero Trust best practices. The truth is there is no singular best practice. There are simplistic foundational components, but best practices can greatly differ from business to business based on your requirements, industry, etc.
2. Always Plan for Exceptions
This guideline is often ignored, but it’s critical to success. As you build your policies (like Azure Directory and conditional access policies), examine how you’re building them and ensure you detail the circumstances that necessitate building an exception. A good example is a conditional access policy that will allow a user to access your environment if they haven’t yet enabled Multi-Factor Authentication (MFA).
Look at your exceptions from a process perspective; if you have to create an exception for a particular component of the controls in your environment, ensure the exception only affects that control. Know that any policy you implement will probably need an exception now or later.
3. Don’t Fall into the Trap of Allowing “Any, Any”
When implementing new products – especially restrictive security products – the easy path is to click that “allow all” option at the end of a statement so you can watch it, gather data, and get more restrictive…and then go back later for cleanup. But there’s never a good time to go back and clean up. There’s always that fear of, “What am I going to break?”
Therefore, it’s much easier in the long run to go through the process right away and, if things do break, fix them that first time. The proper approach is to establish a process that requires any new additions to go through that validation and education process so you’re not going back and cleaning it up because every three or four months it’s changing.
We often see people fall into this trap in firewall and datacenter segmentations. There’s always that “allow any any” at the end to not block traffic but get the rules that’s generated. And those projects, that should only take 12 to 18 months, often go 36 months or more and the clients are still nowhere towards the actual goal because you can never keep up unless there’s a good process that the users are adopting for change.
In the days of Active Directory we would see administrators give domain names to applications because it was easy. You didn’t have to look and see what permissions were needed. Unfortunately, we see the same behavior with Azure Directory where admins make a goal and think that solves the problem. Don’t do that because it’s going to make it more difficult to reduce threats to the environment, and it’s not doing it at least privilege.
But if you do it correctly at the beginning, then you can also test your processes. When new items are identified, run them through the addition process to ensure they work well for your environment. Review and clean up should also be included in processes that are established, agreed upon by the business, and can be easily tracked for modifications. This simple task can lay the groundwork for security enforcement elsewhere in the business.
4. Simulate First Before Putting into Production
We always encourage our clients to simulate their environment with live data to ensure they have the right components. With Microsoft, you can enable a “report only” mode or a “what if” scenario to evaluate how a certain policy will behave, if it will do the right things, and if it will block the right traffic (or block too much).
These tests will show you if your policies appropriately solve your vulnerability concerns. When you’re satisfied, then put it into production. Many enterprise grade applications have a “report only” or “discovery only” option for testing without having to put a policy into enforcement mode.
This guideline is crucial to include in your Zero Trust adoption to clearly see what your policies are doing before going into full production. One certain benefit of doing this will be that it’ll help you alleviate helpdesk tickets.
5. End User Education and Communication
End user education and communication is critical to the adoption of security tools and security changes within an organization. Some users will try to circumvent security so you need to ensure they understand the rationale behind your security policies.
Even though most people understand the importance and benefits of security (from seeing constant news reports of breaches), some will still resist your security policies – especially if they break their process workflows. So, be very involved in your end user community to learn of these issues and quickly resolve them so end users won’t be tempted to circumvent security.
6. Define Success & Failure Criteria
In planning a Zero Trust strategy, clients often talk about what they want to access and test for it. That’s a successful scenario. But make sure you also define what shouldn’t work.
For example, in Azure directories, you may be allowing Windows, Mac OS, and iOS Android devices. But what about a Raspberry Pi? If that device isn’t allowed to access your environment, then make sure you identify that it shouldn’t work nor be able to access your environment. As you build those policies, make sure you test both successful access and failed access scenarios.
7. Plan for Failure (fallback options)
In the event of a failure, you have to identify your fallback options. Often, if a proof-of-concept went well, the organization is ready to put it in production, but you still have to plan for unknowns. If something catastrophic happens, what do you do?
Often, when implementing things like MFA, there may be accounts that aren’t part of MFA in case MFA breaks during that implementation. Or, on the networking side, if you’re doing things like TACACS or secure means for routers and switches to be added to the network, there has to be some kind of fallback if that initial application doesn’t go smoothly.
We recommend maintaining Azure Directory break class accounts so, in case you create a policy that accidentally locks you out of your environment, you can fall back on those accounts to get you out of trouble. Always planning for failure is crucial to the success of an implementation.
Conclusion
Zero Trust isn’t a tool or a single technology that enables Zero Trust for you. This is a framework and a methodology to “never trust, always verify” devices, users, and integrations within your business.
As with any change in security, it is best to approach it as a way to enhance the business and change the culture to think “security first”. With this approach, users understand why and how to adopt these changes, and it can also show you ways to optimize business workflows throughout this change. This is not an overnight item so be sure to plan ahead, get executive sponsorship, and have a solid plan from design, to implementation, and Day 2 operations.
At Core, we have helped businesses across many industries make the plan, create the justification, implement the solution, and manage the environment. Feel free to reach out, ask questions, and see how we can help you start your journey into Zero Trust.
