Designing and Implementing Security Policy in Siloed Organizations

Recently, Angela Moore from the Department of Homeland Security (DHS) IT Management organization, asked the Enterprise CIO Community a question about hierarchical IT Policy management as it relates to Enterprise Information Security and Risk Management. The basis for her question was in FISMA regulations, but the principles apply universally to enterprise business as well, so I after letting it settle for a while I thought I would tackle this issue here on the blog. Given my involvement in the creation and ongoing discussion on the #SecBiz topic, I think this is even more relevant to my readers, I hope you agree.


What's interesting about the responses Angela got was the wide variance in response. Most of the responders centered around the centralized approach with top-down management where the individual siloes are allowed to be free in their implementation of the high-level entity (parent) policy... and my comment on there comment roll agreed.


Without repeating what I originally suggested to Angela my opinion after working in various levels of enterprise IT (in the largest, and smallest, forms) is that the top-level organization should be responsible for setting high-level policy (the what) while the child organizations in increasing specificity should have the implementation details (the how). This applies to the largest organization - such as my role at General Electric, Power Systems division, where we had a high-level 'corporate' entity with multiple levels of siloes depending on what the reorganization that year looked like, all the way down to the organization which has a thousand employees with a central IT and siloes of business units in the branches.


The way I describe it is the only way I believe this type of issue can be resolved sanely. I can claim expertise here since I watched it go back and forth between several different models in my 5 approximately 5 years inside GE ... and the most effective way policy worked was the "what" --> "how" expansion.  Let's take a look at what this really means in practice.


Let's look at the top-level parent organization first. In the very simplest terms, this organization is charged with setting policy that applies to all levels below it so this means it has to be specific enough to serve the organization's goals and good, but loose enough to allow for each unit below it (assumed they are semi-autonomous) to be able to apply it without hardship. As an example let's look at network security policy. The high-level parent policy may require that each network segment is protected and inspected by a managed intrusion prevention appliance, in active defense mode, which is no more than 1 update cycles out of date. Policy also may require that this device be managed 24x7x365 for alerts which should be fed and correlated at two levels: inside the business unit and into the corporate correlation engine, and that there be an analyst ready to act on live alerts. There is likely more, but this will suffice for now, and illustrates my point nicely. This is generic enough where it doesn't dictate which product or service is used, or whether the device is managed in-house or by a service provider. This type of policy provides accurate guidance in the way that the corporate parent entity believes the business units must be protected. Now, let's look at how this policy looks at the bottom of the branch (assuming we have a parent -> child relationship 1 level deep).


In the child note, let's call it the business unit, which is a semi-autonomous business entity which is a direct child of the higher-level enterprise we must address how specifically the policy of the parent is implemented. That high-level network security policy may translate into the implementation of a TippingPoint IPS at each network segment, with updates being tested within 1 day, and pushed within 3 days. This will then be fed into the ArcSight SIEM for analysis at the business unit level, and into the corporate ArcSight SIEM for cross-BU analysis. Since business units are unlikely to be sharing IT resources (even though we'd love them to) this means that the only way to gather intelligence when an attacker crosses Business Unit lines is to correlate and analyze at the top-level. While one business unit may opt to have an in-house analyst for their IPSes, another may opt to outsource the work since a 24x7 managed and staffed SOC is simply not affordable. Internal analysts may be staffed 24x7 or on call per incident - depending on available funds, business model and human resources.


This type of model can be used effectively across the business units where a parent <> child relationship is viable in terms of IT infrastructure and support. This doesn't not always work, however, since many organizations have completely siloed business units such as those that are fully autonomous - but it's more likely, from experience, that this presented model applies.


The policy hierarchy as described here is predicated on solid relationships between the high-level CIO (and CISO) and the sub-business units. Of course, having a mandate from the central CIO or IT leader isn't bad either ... but you still want to make sure you're allowing for a sane way to create a top-down policy which can be implemented across all your IT business assets, regardless of their operating model or financial or IT structure. Therein lies the secret. When creating policy you can safely assume that every business unit which will be trying to implement your high-level policy will do it differently with different resources and serving a different end goal (in the business). If your policy at the high-level is too specific it may not apply universally and then you'll have to make exceptions...and we all know what happens once you make one exception right? You don't want to have to make an exception to the policy for each business units specific needs - so the trick something that applies no matter what the internal model. You also don't want to be too generic. Saying something like "each business unit must protect their network with an IPS" is too broad, as it doesn't necessarily mean the IPS will be in block mode, will be attended or even maintained - which makes the high-level policy worthless.


This policy thing can be tricky when you're setting a policy at a high-level parent business layer, and expecting your child sub-business units to apply it universally without complaint. The goal is to strike the balance between specific and generic - while keeping the individual goals and resources of the business units you support in mind.


What do you think? Does this apply to you? Have you tried this and been successful, or do you have another model that works? Let's hear your opinion and voice! Reply here with your thoughts, and leave your Twitter handle so we can discuss!


This topic will be discussed on Twitter under the #SecBiz hashtag, so feel free to jump in!

Edward Henry(anon) | ‎12-17-2012 10:35 PM

While working as a sub-contractor for a silo of a major goverment contractor, I'd come to realize that exactly what you're explaining is what it will take to handle a multi-silo ogranization, effectively, from the top.


Top down policy management and enforcement is a lot like golf. You need to have the perfect amount of grip, fanesse and skill to implement and manage policy enforcement for it to be effective.


Ultimately, there is no perfect example for all organizations to follow, much like trying to apply the top-down defined policies, there can only be a framework to work with and mold and apply to your organization.

Andrew Yeomans(anon) | ‎12-18-2012 08:56 AM

Certainly it's a good plan to separate the high-level objectives from the implementation details.


However simply taking the approach of centrally defining objectives, then throwing it down the pyramid is pretty much guaranteed to lead to much duplication of effort and lost opportunities for economies of scale and consolidation. If the objectives are flexible enough to cover all parts of the business, they may sound so obvious they add little value.


Those business units may be separate today, but chances are they will be split or combined in future, leading to difficulties when the unit policies and implementations are totally different.


I'd suggest instead that there should be incentives for reasonable consistency, but without full compulsion. So a central group can additionally define the lower-level policies as a worked example, but can allow alternatives to be used where appropriate. A small business unit may decide to take those worked examples as is, without needing to spend extra resources writing and implementing them. But another unit may re-work parts to better meet their specific requirements; but still taking less effort than creating them from scratch.


Products can be tested and specified in a similar manner; centrally create and supply a list of evaluated products, while permitting others to be considered; in turn these may be added to the list.

rjacksix | ‎12-24-2012 03:17 AM

I think you're bang on, especially in large, disparate organizations.  


Rigid top down implementation level guidance will never work because, typically, there is a reason that the organization is siloed.  


Security has to deal with the hand it is dealt and not try to make an organization fit a paradigm that has already proven unworkable, in this case a monolithic system.


The NIST Guidelines are a wonderful example of giving the parameters, without forcing a solution.  Another practical example is the one Richard Bejtlich gave in his recent talk about his experiences at GE.  In an organization that size, at the CIO level, the guidance was "response to an incident anywhere in the organization within one hour." The "how" was left to each of the many business units within GE, but the result was achieved.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation