TRAINING‎ > ‎RESOURCES‎ > ‎The Dreezlog‎ > ‎

MDM Architecture - Part II

posted Oct 28, 2011, 5:41 AM by Michael Endrizzi   [ updated Oct 28, 2011, 6:49 AM ]
 
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). 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).
 
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
 
 
I'm sure I'll think of more, but that's it for now. This should get you started...
 
 
Comments