So I think I’ve established you can’t design your MDS architecture just thinking about 1 parameter…security…or your job security. You have to think about the whole environment over the whole MDM life cycle. Ease of administration is a huge criteria here.
Global sharing is a great concept, but it does have pitfalls (can’t rename globals, can’t delete some global objects (policies), can’t delete global objects in local policies, hard to locate global objects, can’t nest global policies, global database locked out by single administrator, few global tools like global provisioning/monitoring/strict IPS/logging), subnet hell. Until MDM is implemented in a true SQL database I don’t feel that they will fix many of these problems.
SOOOOO Until that day happens we have to live with what we have…which is still the greatest enterprise management tool on the planet.
Solutions:
1) Common Policies: Think about it from a policy point of view. Is there a group of local policies that are 80/90% similar? Group similar local policies into one domain and use either the INSTALLON field or separate saved policies to install on groups of firewalls. Now these are a bit tricky because you need procedures to make sure the a rule is installed on the correct firewall. If you have maverick gunslinging administrators, you may want to think twice about doing this.
2) Mavericks: Do you have administrative mavericks that need their own playpen? Do you do a lot of M&A’s with their own administrators? Separate them into their own set of isolated domain(s).
3) Decentralized administration: Are you like Berkshire Hathaway Company – the 8th largest company in the world but only 50’ish employees at headquarters in Nebraska (look at their web page once). I can assure you they have decentralized administration. A decentralized firm should have (maybe even multiple MDM environments) a global policy (or set of global policies) for each of the subfirms, then delegate administration to sets of domains for that firm. Note that this will require strict procedures so that sub-firms respect the integrity of other sub-firms global policies if they have write access.
4) Global VPNs: If you want to setup Check Point VPNs between Domains NOT under that same global policy…Research global VPNs before you do.
5) Ignore IPS: IPS really doesn’t impact MDM architecture. MDM can’t enforce IPS on domains, only offer IPS profiles to use if they want.
6) Separation of Duties: Remember that if you have separation of duties between security admins that create policy and NOC/Help Desk that REASSIGNS and installs policy, that the NOC will then have to have superadmin permissions and access to all global domains. If this is a problem, you may consider having multiple MDMs.
7) Security Zones: Let’s say you want to map PCI security zones into global policy or isolated Domains. The problem here is that it may be at cross-purpose with the other policies that are business based so now you are crossing administrative boundaries. Make sure you factor in the administrative overhead to do that. Look at who the administrators are and what the business rules are and if it crosses administrative boundaries. There are better ways to make the auditors happy then only doing this security mapping in MDM (like Tufin).
8) Business Risk: Remember that thing called ‘business’ that is suppose to function and write your paychecks. Well you can divy it up into microscopic chucks (i.e. firewall per server) so that malware outbreaks are contained as well as your paycheck. OR you can take an economic view of the organization and break it into economic risk categories. So if your Product A production line is 80% of revenue, then firewall it off and let Product B,C,D,…..E etc function behind a second set of firewalls. Marketing and sales….ugh put them together. I mean put operational staff together because they only suck money and do not produce it. I think you get the picture, think like a business economist, not a security geek.
9) Geographical Separation: I was wrong here. I couldn’t think of any reason but just heard a great one. Let’s say you have huge policies or lots of logging from Botswana. Do you need to backlog that over your WAN. Or doing installs with long delays and you get ERROR-Install Failed..but in reality it installed just timeouts? Locate a secondary HA mgt near where the firewalls are located so that policy pushes and logging is targeted to the shortest network connectivity to these sites.
10) The Risk – Let’s just say your patching, IPS, AV is stellar. But you have a slew of systems
that can’t be patched (3rd party systems, legacy systems, appliances that don’t autopatch). So place the well maintained systems behind one set of firewalls, and the unpatched ones behind a second set of firewalls. So I know the security geeks will scream “But what if unmaintained system A infects unmaintained system B??? Hereasy!!!” My comeback is “What if the rules get so complex and by the 10th firewall administrator (everyone else quit because it became so complex they couldn’t administrate it) your rules wind up being Swiss cheese. NOW try and remove the firewalls and consolidate. Good luck, going backwards is a nightmare. If you DO have malware problems, then isolate those systems based on actual risk instead of potential risk which you can’t reverse engineer.
11) The Submarine – Think about how submarines are built. In water tight containers based on function. Now wouldn’t it be cool to build a container for each crew member!!! Think about all the doors you’d have to go through and the cost involved. YIKES! Instead why don’t we build containers based on function. The control room, the engine room, the torpedo room all have their own. Of course the crew all dies together in one container. Similarly break your business into business functions. As the ship is sinking which functions can you afford to kill off. Obviously most the staff goes first, marketing, suppliers, etc. But the execs, manufacturing and accounting have to stay alive at all costs. “The Golden Rule” I guess.
12) MDS separation – This category is somewhat overlapping on the others, and I got this from a CheckPoint SE. There is a customer that has XX MDS servers in XX countries. The point being you can have unique global instances for each of your “zones” no matter how you divy them up.
Guidelines:
1) Never Never Never use global objects in local rules.
2) Create a written naming standard for global objects and enforce it. You cannot rename global objects.
3) As long as you are creating a naming standard, might want to create a object color standard too. And then
use it to color your security zones. You can change colors, but not names.
3) Global policies are forever. You can’t delete them. Use gently
4) Warning. As of R75 there are no more MDS containers so the max domain count is about 250.
32-bit SPLAT just can’t handle more. Once GAIA and its 1200 commands come out you will probably be able to support more. Another area where the theory runs into the brick wall of reality.
5) There is this thing called budget. Believe it or not businesses can only afford so many $150,000/year CCSA’s. So your manager says “We have budget for 3 firewalls geeks”. That’s the upper limit. From that number determine how many domains you can humanely administrate with spending weekends and nights debugging. Perhaps assign 40 to each of the 3 and then 120 is your upper limit. The point is pick an upper limit of something..money, people, domains, rules. If you go above that then go back to the well and justify based on metrics your keep on activity to date on existing infrastructure.
I’m sure I’ll think of more, but that’s it for now. This should get you started…
DreezSecurityBlog 