Implementing Micro-Segmentation- Insights from the Trenches, Part One

Recently I have been personally engaged in implementing microsegmentation for our key customers, which include a top US retail brand, major Wall Street bank, top international pharmaceutical company, and leading European telco. Having spent significant time with each one of the customers including running weekly project calls, workshops, planning meetings, and more allows me a unique glimpse into the reality of what it means to implement such projects in a major enterprise – a point of view that is not always available for a vendor.

I would like to share some observations of how those projects roll out, and hope you will find these insights useful and especially helpful if you are planning to implement microsegmentation in your network. Each blog in this short series will focus on one insight I’ve gathered from my time both in the boardroom and in the trenches, and I hope you find some practical pieces to help you improve your understanding and implementation of any current or upcoming security projects.

Application segmentation is not necessarily the short-term objective

If you look into the online material for microsegmentation, vendors, analyst and experts all talk about breaking your data center into applications and those applications into tiers, and limiting the access among those to only what is needed by the applications.

I was surprised to discover that many customers look at the problem from a slightly different angle. For them, segmentation is a risk-reduction project driven by regulations, internal auditing requirements, or simply a desire to reduce the attack surface. These drivers do not always translate into segmenting applications from each other; if segmentation is a priority, it usually is not as the primary objective but instead a means to an end, and is not necessarily a comprehensive process in the short term as they look to achieve their goals. Let me give you a couple examples:

  1. A major Wall Street bank was required by the auditor to validate that admin access to servers is only done through a Jumpbox or a CyberArk-like solution. It means in reality the bank wanted to set a policy that “Windows machines can only be accessed from this set of machines’ RDP – all other RDP connections to it are not allowed. Linux machines are only allowed to be accessed from this set of machines by SSH – all other SSH connections are not allowed.” I think there is no need to explain the risk reduction contribution of such simple policy, but this has nothing to do with segmenting your data center by applications. Theoretically speaking one could achieve this goal as a side effect of complete data-center segmentation, but that would require significantly more effort and in fact the result would be somewhat implicit and a bit harder to demonstrate to the auditor.
  2. A European bank needed to implement a simple risk reduction scheme – to mark each server in their DC as “accessible from ATMs,” “accessible from printer area,” accessible from user area,” or “not accessible from non-server area” with very simple, well-defined rules for each one of the groups. Again, the attack surface reduction is quite simple and in their case is in fact very significant, but it has little to do with textbook application segmentation. Here too you could theoretically achieve the same goal by implementing classic microsegmentation, but Confucius taught us to not try to kill a mosquito with a cannon. Most of those organizations do plan to implement microsegmentation as the market defines it, but they know it takes a bit of time and they want to first hit the low-hanging fruit in risk reduction early on while implementing this crucial security project incrementally in a way that makes the most sense for their business.

So if you are looking to implement a microsegmentation project – understand your goals, drivers and motivations and remember that this is a risk reduction project after all and as they say there are many ways to peel an orange – some of them are simpler, faster, more straightforward, and more efficient than the others. But the sooner you get started, the sooner you can enjoy the taste of your success. In any case, when choosing technology to help you with a segmentation project, make sure you choose one that is flexible enough that will help you do textbook microsegmentation, but also address those numerous other use cases that you might not even be aware of at the initial stages.

Stay tuned to our blog to catch more of my upcoming insights from the trenches.

Learn more information about choosing a microsegmentation solution.

From Guardicore's
Resource Center

Ransomware Prevention & Remediation using Guardicore Centra

Ransomware Prevention & Remediation Using Guardicore Centra
Once we implemented Guardicore, we could identify traffic patterns that were not only unnecessary but also were previously unknown.
Ransomware, once simply a nuisance strain of malware used by cybercriminals to restrict access to files and data through encryption, has morphed into an attack method of epic proportions. While the threat of permanent data loss alone is jarring, cybercriminals and nation-state hackers have become sophisticated enough to use ransomware to penetrate and cripple large enterprises, federal governments, global infrastructure and healthcare organizations.
 

Subscribe To Our Newsletter

No spam, we promise. We’re only going to send you insights on how to reduce risk in your data center and clouds.

See Centra in Action

Reduce your attack surface and prevent lateral movement with fast and simple segmentation that works everywhere.

See Guardicore Centra in Action

Schedule a demo customized to your specific security needs

Coming to Black Hat? Make sure you come say hi 👋