Angela Moore asks:

The Federal Information Management Security Act (FISMA) directs CISO's to develop and maintain security policy for the enterprise. Should the policy be uniform across the entire organization or can individual department CISOs develop their own policies? For example, can the Department of Homeland Security (DHS) delegate to FEMA or the Immigration and Customs Enforcement (ICE...both are agencies under the DHS) the responsibility of developing and maintaining their own policy? Should DHS act as the governing body, or does FISMA allow each agency to develop their own policy, thereby eliminating the need for an enterprise wide policy for the whole DHS?

CIO Questions by Angela Moore, Wed, 11/21/2012 - 14:53




This is clearly a “hot” topic and one for which you have received a lot of good feedback already.   

In any enterprise-wide IT effort such as a security policy, governance mechanism or organizational structure, to name a few, I have found that there are almost always two options; the ideal one and the one that will actually work in practice.  They may not be the same.

In an ideal world a single policy that would require one set of training materials, one set of criteria to audit against and the proverbial “one throat to choke” when something goes wrong may be ideal but it appears from some of your comments, may not be workable in practice.  In these situations a single policy would have to incorporate the unique needs of each unit and would thus impose needless and costly requirements on some agencies in order to meet the needs of others.

Perhaps the best approach in this case is a federated model.  It is a bit like the US government.  We have a constitution, which is the “law of the land”, but individual states can enact laws that support their unique needs provided they do not conflict with the constitution. We have a judicial branch of government to oversee that aspect.

In your case, I would suggest that you identify those aspects of policy that cannot be compromised and these become your “constitution.”  This is an overarching set of rules that everyone must adhere to. Then allow individual agencies to supplement this with rules and policies that may be specific to their mission provided they do not conflict with the overarching policy.  You will need some form of “Judiciary” to sort out differences and that may fall to the Department’s CISO’s office.

Implementing something like this will require not only knowledge of security best practices and regulations but good political and salesmanship skills because a lot of people will be affected. Good luck!

(1) (1)

Would you like to comment on this content? Log in or Register.
John Dodge 1472 Points | Tue, 12/04/2012 - 15:59

This post is very relevant to the question. "Challenges of Implementing an enterprise-wise security program."


John Dodge 1472 Points | Tue, 12/04/2012 - 00:53

Good analogy, Joel. I especially liked your cautionary tale: "I have found that there are almost always two options; the ideal one and the one that will actually work in practice." 

jamal khawaja 107 Points | Wed, 11/28/2012 - 04:24

This inspired me to write a blog.  

In the short term, I think that security policies should be departmentally specific.  The threat profile and subsequent consequnces of a hack will differ dramatically for an agency like the Secret Service than for the Office of Immigration Statistics.  Creating an over-arching policy that can marry the disparate policies needed for these two examples is not just technically unsound; it is also a waste of time and money.  Let agencies conduct their own threat and risk assessments, and craft policies germane to their oeprating environment.  

What is needed at the top is not the mechanism that should be mandated, but rather thought leadership around best practices, technology options (like anapproved vendor's lsit or reference architectures), and executive committment to coherent, productive metrics.  In addition, a long-term strategy that does describe a cloud-enabled securit world should be socialized and defined now, in order to give cloud providers an idea of what DHS will expect the security model to look like.

As data and compute capabilities are moved to the cloud, this department-specific model will change.  Security profiles can become part of a service catalogue that is offered to cloud tenants when applications or data are brought on line.  The cloud provider can be subject to penalties for failing to meet security requirements, putting the onus on them for a coherent security mechanism.  

My blog on cloud computing security (I blog on this site):

John Gallant 15 Points | Tue, 11/27/2012 - 21:38

After reading the question and the answers, I was wondering what issues you think need to be handled uniquely by the different groups that wouldn't be handled well by a global policy? I wonder if there are really all that many unique requirements and, more important, if handling things 'uniquely' is opening the door to issues and risks. With all the collaboration that one supposes occurs amongst these organizations, can unique approaches to any situation really work?

Angela Moore 2 Points | Thu, 11/29/2012 - 18:15

Thanks. The DHS Components/Agencies such as FEMA, ICE, etc., should fall under the governance of Headquarters of DHS. The Components have unique missions, functions, and lines of business. As a result, a one size fitss all solution will not work in this environment. I think an overarching Departmental policy should exist that consists of high level baseline policy that every Component must follow. That policy should include the NIST 800-53 dash one security controls, PM controls and bits and pieces of other enterprise wide controls that makes sense. Components should be allowed to enhance the policy, but must at least adhere to the policy set forth at the Department level. Collaboration? What's that? lol

Regulatory Cybersecurity
Bruce Levinson 1 Point | Tue, 11/27/2012 - 20:07

The model for DHS delegation of authority for information security policies is found in the Information Quality Act, also known as the Data Quality Act.  Under the IQA, the White House Office of Management and Budget (OMB) used a notice-and-comment process to establish government-wide information quality guidelines as well as related information quality guidance documents, such as the Updated Principles for Risk Analysis. 

Each Department's CIO then developed, through a public notice-and-comment process, their own agency-specific implementing guidelines which simultaneously complied with OMB's requirements while tailoring the implementing guidelines to meet their own specific needs.  In some cases, a single set of guidelines were issued for the entire Department while in other cases the Secretary delegated authority to operating component agencies.

It is important to note that OMB retains authority over the Data Quality issues on a government-wide basis.  Thus, even in event of DHS delegation of cybersecurity authority to operating agencies, the CISO would still retain overall responsibility and control. OMB's government-wide information quality guidelines may be found here,

It should also be noted that the IQA has cybersecurity-specific elements.  For example, OMB has defined the "integrity" component of quality to mean compliance with federal cybersecurity requirements.  For more information about the IQA and cybersecurity, please see CircleID here,

Bill Laberis 154 Points | Tue, 11/27/2012 - 19:49

I suppose if we were to try to make an analogy between these federal agencies, which are very large and sprawling, and, say, a global multinational conglomerate, you'd almost have to come down on the side of some over-arching policies or at least best practices along with discrete policies that are agency-specific. But clearly someone at the top, or more likely some group of individuals, needs to be aware of and totally responsible for everything orchestrated and put in place and amended in the layers below. This may be over-simplifying the matter at hand. But there are considerations such as the present and future potential for sharing data among these sub-groups that have to be taken into account as well.

Angela Moore 2 Points | Tue, 11/27/2012 - 20:40

The Department security control family policy should be exactly that... an overarching policy "the what". The Component specific policy could augment the Department's overarching policy in accordance with agency mission, function, etc. The remaining policy or "the how" may very well be the developed by the Agency.

jamal khawaja 107 Points | Wed, 11/28/2012 - 04:29

There should be some guidance around technolog choices; otherwise, you are going to end up with a huge technology jigsaw puzzle on your hands in a few years.  A good way to avoid this would be to establish reference architectures that describe certain classes of solutions.  Another option would be to create an "approved vendor" list or something of the sort, so that our middle management doesn't start experimenting with technologies that should best be avoided for whatever reason (too old, too new, too expensive, past performance, etc.)


My $.02

Rafal Los 111 Points | Tue, 11/27/2012 - 19:20


  You're dead on with your comment in the discussion. While it makes no sense to have a single monolithic policy, there are elements to a cascade approach that make the most sense. Having worked for an organization of global size with many various sub-units before this is how I see it, and I believe it matches much of what you already see...

  At the global level (whatever level that is) is a set of high-level policy directives which outline guidance for the 'what'. This should outline things like 'thou shalt use multi-factor, high-grade authentication mechanisms for systems classified as criticality level 2 and higher' (I just made that up)... while at the department level should be the 'how' for implementation of those policy directives.  Using this method the policy can be enforced and governed at the high level without getting into the specifics of how each department conducts their business - thus avoiding any conflicts where a high-level policy is too specific and forces one department to change to conform to another's standards

  While the high-level policy must answer the 'what' question, there must also be a way to avoid loop-holes through audit and governance, not just the typical compliance ruse.

Hope this helps!


Angela Moore 2 Points | Tue, 11/27/2012 - 20:43

Perfect! Your description of the "what" and the "how" is exactly how we are trying to sell this concept.

John Dodge 1472 Points | Wed, 11/28/2012 - 14:57

Angela, aren't there some DHS and agency infosec policies already in place that can be built on? You can't be starting from square one, no?    

Rafal Los 111 Points | Tue, 11/27/2012 - 20:47


 I've got some experience with this in organizations large and small, so if you need to bounce an idea or structure off of someone, my email is public (first name and I'm happy to help.

Best of luck!


Jerry Bishop 100 Points | Tue, 11/27/2012 - 12:33

Not withstanding the specifics of FISMA, I think this question is a non-starter.

That view is based on it being a question about the organizational level where a compliance policy should be set. The answer to the question is an issue of institutional (enterprise) governance. If institutional governance is driven from a particular level - White House, agency (DHS) department (FEMA, ICE, etc...) than that is the likely level for all institutional governance including governance driving compliance and IT controls.

To take this to its absurdity, why not just have one security policy for the entire US federal government – all branches, agencies, etc…. The objections to this ridiculous suggestion should frame the rationale for why each agency shold have their own security policy issued at the level of accountability for agency governance and accountability.

As to uniformity, in my view uniformity is not an element of compliance and would not necessarily strengthen compliance or the security posture. Uniformity may make compliance easier for those CISO's that need to develop or update their programs, just not better.

Bob Gourley 0 Points | Mon, 11/26/2012 - 22:42

Some thoughts:

- Regarding FISMA and what it allows, from my perspective FISMA allows CIOs to make determinations on how agencies execute. My time in government was as a CTO at a DoD subordinate agency (DIA).  Our department CIO wanted agencies and Services to comply and report compliance etc at their level. We were also part of the IC and had to do things their way too, but for us the agency level was right. 

- As for the policy, I would strongly advocate for an approach that has a department-wide policy but allows for subordinate agencies to modify that as required.  For DoD, that meant security policies were coordinated and promulgated from OSD level, and in many cases those issued direct guidance that had to be complied with for every agency and subordinate element, but each subordinate element has a different mission and different environment so it is wise to let them specify more detailed policies and even push back and articulate when the overall policy does not apply. 


Just some food for thought. 





Doug Goddard 123 Points | Mon, 11/26/2012 - 20:32

Since policies are about priciples and priciples are about universals, or as close as we can get to them, I would think the policy would be consistent across the entire organizational domain. How and who translates the policies into actual controls is probably a function of governance, how you as an organization have decided to allocate governance decision rights and provision security services. 

Martin Davis 129 Points | Mon, 11/26/2012 - 19:54

Maybe I should ask the obvious question, why would you consider doing the same work twice? Surely you would want consistency of policy? There may be exceptions granted at a lower level, but I would have thought overall you would drive a single consistent policy across the enterprise.

Angela Moore 2 Points | Tue, 11/27/2012 - 18:32

That's the point... we don't want to do the same thing twice.  We'd like to approach the use of common controls from a top down approach. That way common controls for the enterprise are defined at the highest level in the Department while system specific controls remain at the lowest level, resulting in only the minimum number of controls being assessed, thereby reducing overall costs. That is not what is happening and I am trying to sell the concept... unsuccessfully so far.

John Dodge 1472 Points | Tue, 11/27/2012 - 18:46

Department of redundancy department...again...

Martin Davis 129 Points | Tue, 11/27/2012 - 18:34

Agree with you - that would make the most sense.

John Dodge 1472 Points | Mon, 11/26/2012 - 20:16

I would ask if there are needs at the agency level that do not exist across the entire Dept. of Homeland Security. Could a sweeping and uniform policy across ther department miss something at the agency level?

Angela Moore 2 Points | Tue, 11/27/2012 - 18:42

NIST 800-53 defines 18 control families and the "dash one" control in each family should define the policies and procedures for the other controls listed in the family. I think that policy should be defined at the Department level. The Components/Agencies under the Department can develop more stringent policy but can not follow policy that is less stringent than the baseline policy developed by the Department. The CIO designates to the Department CIO the development and maintenance of such policy. I don't think it should be delegated below the Department, but I am trying to find out if it is even legal under FISMA... or is it a matter of interpretation of the law.

John Dodge 1472 Points | Mon, 11/26/2012 - 15:49

I think the question is relevant to all enterprises. Should security policy common across the enterprise or tailored for each unit or division? Could the DHS approach be a model for private enterprise?