Shared security standards - learn from the DoD

GCN points out that the DoD and ODNI are establishing a collaborative security standard policy. There are a few useful points made here that any organizations seeking to work together on security would do well to observe. The bullets below are from the article, with commentary interspersed.

• Define a common set of trust levels so both departments share information and connect systems more easily.

This is crucial when working between different organizations or systems. Building a mapping of trust levels and a policy and procedure for how to map those levels should be a part of any security program that has to interface different entities.

• Adopt reciprocity agreements to reduce systems development and approval time.

Trust is at the heart of this bullet. If your organizations have equivalent security policies and have a trust level to match this will work. If not, then sharing systems development and approval will likely fail. Shared standards and practices are absolutely vital if your organization attempts this!

• Define common security controls using the National Institute of Standards and Technologys Special Publication 800-53 as a starting point.

Another good place to look for security controls would be the CIS benchmarks or the NSA security configuration standards. The keys here are establishing a standard, keeping it up to date, and making sure that you adjust the boilerplate to fit your needs if you use a standard. No matter what standard you use, documentation is key. I like to suggest wikis as a great way to develop and maintain living documents for standards.

• Agree to common definitions and an understanding of security terms, starting with the Committee on National Security Systems 4009 glossary as a baseline.
  

The glossary can be found here in PDF form. This is a handy tool - it helps eliminate semantic debate (we've seen it ourselves in our comments). Arguing over the meaning of the word vulnerability might be avoided with an agreed on definition.

• Implement a senior risk executive function to base an enterprise view of all factors, including mission, IT, budget and security.
  

This might involve organization wide risk assessment, communication, and possibly most important - ownership and responsibility by senior management. Without strong upper management support and ownership, any large scale security project will fail.

• Operate IT security within the enterprise operational environments, enabling situational awareness and command and control.
  

In short - use operational security monitoring. There are technical, administrative, and policy/procedure elements here - all the elements of a full information security program.

• Institute a common process to incorporate security engineering within life cycle processes.

Lifecycle design is one of the most crucial things for security to be involved in. Establishing security reviews and consultation into the project management and lifecycle will help ensure that new projects are build on a solid foundation, and that existing systems and designs will receive periodic review.

It is good to see government agencies planning ahead, and the outline above is a good high level starting point for organizations seeking to share security practices. Standards, trust, and executive backing are key to this entire process. It will be interesting to see what comes out of the process.