When & Why To Publicly Reveal Internal Security Policies

Never Say Never: In the absence of further information, written information security policies are by default generally considered information that is “for internal use only” or “restricted.” There are many good reasons to refuse to release information security policies to outsiders. But the trend these days is towards greater transparency, greater accountability, and a more holistic understanding of information handling practices across a multiple-party environment. These trends often push organizations to release information security policies, and we will get into the when and why to reveal policies below. But before we get there, let’s just review some of the typical reasons why internal policies historically have been withheld.

Reasons Not to Release Security Policies: The most common reason involves an intention not to give potential attackers any additional information that they could use to break in, or otherwise compromise the information systems at the organization in question. This is particularly relevant now that the Internet makes so many different types of information available. The ready availability of so many different types of information makes the mosaic theory much more of a threat, not just for military agencies (where the theory originated), but also for civilian agencies and commercial firms, as well as non-profits. Before any internal policy disclosure is approved, management needs to ask whether this one additional piece of information is going to create a new picture (a mosaic if you will) revealing what’s going on inside the organization in question.

Other frequently encountered reasons not to release information security policies include the desire not to reveal trade secrets, or internal operating practices, which might be of value to competitors. It is also good to think about whether the release of an information security policy might give adversaries any information that they might use in a court of law. Of course, if the policies reveal practices that are on the edge of what’s legal, that too would be a good reason to withhold disclosure.

Similarly, withholding a policy might be prudent if that information could be used by the news media to color the organization in a bad light. Likewise, if the information might be used by activists to make the organization look bad in the press, that too might be a reason to withhold disclosure. For example, perhaps environmentalists would criticize an organizations computer hardware recycling policy. If management knows that an internal policy is worthy of public criticism, it should get underway with efforts to change the policy (at the very least, this would prevent this same policy from being leaked to the press, thus precipitating a scandal). As a side benefit, internal discussion about these matters is often helpful as a way to motivate management to take action about antiquated or inadequate policies.

Reasons To Reveal Policies: But if internal policies are indeed exemplary, then disclosure can bring favorable publicity and perhaps some marketing benefit to the organization. For instance, when it comes to data retention policies, one vendor may be more forthcoming than its direct competitors. For example, Google may reveal its data retention policy while Yahoo! does not. All other things being equal, that disclosure in turn is likely to incrementally increase the confidence that people have in Google relative to Yahoo! This is particularly true if the topic addressed by the release is a hot topic, something currently in the news, or otherwise a matter of public controversy. In this case, the releasing organization can enjoy significant additional competitive advantage, at least until competitors match the releasing organization by disclosing their own policies in this same area.

Unfortunately, a very prominent release of this nature can set-up an expectation that, in the future, the organization will continue to be progressive and up-to-date. So I don’t urge organizations to make such a release unless management is really committed to not only being consistent with the prevailing standard of due care in the information security area, but also committed to going the extra mile, so that the organization is indeed worthy of the public reputation that it enjoys. This decision partly depends on management’s appetite for risk, and this can of course change when specific managers change. To set the bar high, and keep it there, I suggest that organizations institutionalize this intention through formal policies, descriptions of market positioning, internal staff training materials, etc.

A Business Necessity: In some cases, people won’t do business with your organization unless you show them that the organization is in fact on top of information security. Perhaps the most common example of this involves buying things over the Internet. Here, most customers want to see privacy and security policies related to the handling of their personal data. In some jurisdictions, such as in the UK, there are legal requirements to reveal these policies. As another example, the California Online Privacy Act of 2003 requires that commercial web sites and on-line services that collect personal information post a privacy policy.

But it is also increasingly true that other organizations want to see your organization’s information security policy before they hand-over proprietary or confidential data. I know one large merger that in fact was scuttled, or at least temporarily postponed, because one of the two companies was far behind the other when it came to information security sophistication. The way this fact was readily revealed was by comparing the two companies’ information security policies.

In some instances, releasing security policies to certain third parties, such as an insurance company, may also be in order. And this approach reflects a good rule of thumb when it comes to revealing internal policies: release them only to those organizations that absolutely need access to the policies, and do that only after explicit written permission has been obtained from a vice president or some other higher level executive. In this case, the “need to know” is certainly applicable with an insurance company that seeks to write computer crime related insurance. In order to rate the coverage policy (set premium dollar amounts), the insurance company needs to get a sense for how sophisticated the insured organization is when it comes to information security. And a good way to do that quickly is to look at the latest version of the information security policy.

How To Release Policies: If the internal policy you release to outsiders is more than a year old, that’s a bad sign. Information security policies should be updated at least annually, if not more often (depending on recent events such as: a privacy lawsuit, an adverse audit report, major problems revealed by an intruder, a major system outage, a significant reorganization, recent release of a new product or service, a merger and acquisition, etc.). Some organizations have simply replaced the actual date with a more recent date in order to make it look like the policies they release are “up to date.” This deceptive practice is ill-advised, not only because it is fraudulent, but also because it may ultimately reflect poorly on staff competence at the organization in question. If a recent policy statement doesn’t include words to address a recent and important threat, but the date is current, then it looks like the issuing organization’s information security staff is ill-informed or perhaps incompetent.

As the insurance example implies, it is highly advisable to get a signed non-disclosure agreement (NDA) before releasing policies to any outsiders. This NDA requirement would for example apply to consultants doing an information security risk assessment. Likewise, it is advisable that a formal approval process be used to determine whether information security policies, or for that matter any other documentation about information security, will be released to outsiders. Organizations can for example, require that the Chief Security Officer (CSO) approve all requests for the external release of information security documentation. An internal policy stipulating that all information security documentation is by default classified as “internal use only” should also be adopted. (Examples of these can be found within Information Security Policies Made Easy.) Some information security documentation, such as access control system administration manuals, should additionally be controlled based on the need to know. In other words, unless you can demonstrate that you need it to get your job done, and unless you get a relevant manager to approve the release of the documentation, you don’t get to see it.

Using Third Parties: Even better than going through the NDA process mentioned above would be to use an intermediary. For example, your organization might hire an expert consultant, or an accounting firm, to do a SAS 70 Type 2 review, or perhaps an ISO 27001 security review. Then, provided that your organization received a decent rating, you could share the professional opinion of the intermediary with interested parties, rather than actually disclosing the security policy that was sought. This approach is increasingly being used by Internet Service Providers (ISPs), Software As A Service (SaaS) Providers, and similar firms, because they receive repeated requests from existing and potential customers for the specifics about their internal security infrastructure.

Of course, such a general opinion about the adequacy of information security may not satisfy third parties who want to know the details about your organization’s policy. Intermediaries can still be used in these latter cases, although in a somewhat different way. Instead, intermediaries can be used to look at the security policies in a certain area, such as the handling of personal information, and then express a professional opinion about that. This opinion can then be shared with third parties, but the actual words in the security policy will still be withheld. Decades from now these complications will probably be unnecessary, because we will most likely have independent intermediaries that assess and rank firms by their information security status, much the way that public accounting firms now assess and rank firms by their financial status (aka third party audits).

Another important approach is to split up information security and privacy policies before they are released. If there is good reason to release an information security policy, and if the proper documentation (an NDA for example) has been fully filled out, and if appropriate management approval has been obtained, that still doesn’t mean that the whole information security policy statement should be handed over to an outside party. Instead only the section of the policy relevant to the topic to be addressed should be released. For example, Google has released its security policy addressing anonymizing the final eight bits of user IP addresses. This release may state how long Google retains this information, and what it uses the IP addresses for, but beyond that, the released words reveal nothing. This is a good example of releasing only that part of an information security policy that is relevant to the issue at hand, or the business to be conducted.

Decision to Release Policies: There may be circumstances where management doesn’t have a choice but to publicly disclose its information security policies. For example, if an organization wants to use the Google Adwords advertising service, publishers must post a transparent privacy policy. Even more compelling would be a forced public disclosure that takes place as part of a court case.

Each instance in which there is a compelling call to release a security policy should be thoroughly scrutinized, not only by internal legal counsel, but also by the Chief Security Officer and the Chief Auditor. It is also advisable to have the user department head, or the information owner — the one who implements the policy — that person should also be consulted. For example, the marketing manager should be consulted if the policy about sharing customer personal data with other organizations is about to be released publicly.

In summary, we see that the whole question of public release of security policies is rather complicated and largely dependent on the circumstances, but definitely worthy of some serious management attention. When management has a choice in the matter, the default position regarding public release can and should be: “no, we don’t release that information.” If you must release internal information security policies – do so only after careful planning and thoughtful analysis of the business impact of that release.

Charles Cresson Wood, MBA, MSE, CISSP, CISA, CISM, is an independent technology risk management consultant based in Mendocino, California. The eleventh edition of his book entitled Information Security Policies Made Easy contains 1400+ already-written information security policies in CD-ROM format. His latest book is Kicking The Gasoline & Petro-Diesel Habit: A Business Manager’s Blueprint For Action (www.kickingthegasoline.com). He can be reached via www.infosecurityinfrastructure.com.