Network Security Consulting Blog

Companies of all sizes continue to struggle with information security policies or other rules designed to help protect their information. In 30 years of information security practice some issues come up time and time again that contribute to the problem of inadequate information security policies. While few would argue the need to have actual policies about information security, often that’s where agreement stops. The concept of having policies, defining policies and enforcing them is often more than a little controversial for many companies.

Most information security policies evolved out of the old familiar “do’s and don’ts” set of rules.  Often times the do’s and don’ts were the least controversial of policies and included such things as guidance on what not to say in an e-mail, how to handle confidential company information, what usage of the Internet is permissible, and so forth. Too often the do’s and don’ts policy was a clone of a year’s earlier article in an HR manager journal and has received almost no attention since then.  Companies often lack the resolve to use the do’s and don’ts policy as a basis for disciplinary measures of any kind, let alone as the basis for termination.  However, the one thing the do’s and don’ts policy did enable everyone to do was to righteously claim, “yes, Boss, we do have an information security policy.”

The do’s and don’ts policy almost never covers important areas such as business resumption planning, compliance, systems development, and other areas. Upon review of a draft of a comprehensive ISO 27002 based set of policies I’ve had a client’s systems development manager cross out every mention of systems development because he was simply unwilling to acknowledge that systems development played a role in effective information security or was unwilling to allow another part of the company to define policies that might actually affect the behavior of professionals within the systems development organization. Similarly, I’ve seen network and operations managers attempt to exempt themselves from rules about the secure management of networks and operations when it becomes apparent that a comprehensive policy usually covers those areas.

A major gap in most do’s and don’ts based policies is the lack of a clear differentiation of roles within the organization and an additional set of rules for managers within the organization. Managers have a higher standard of behavior when it comes to information protection. Unless you believe that security is someone else’s job managers throughout the organization have some basic roles and responsibilities that must be acknowledged, trained in, and complied with before any organization can claim it has reached the first step in effective information security policy governance. Among these special manager obligations are approval of access requests, answering of subordinate questions about situations where security potentially conflicts with other operational objectives, implementation of security controls needed within individual organizations,  regular review of open access requests on file, etc., etc. An organization desiring to move past the evolutionary do’s and don’ts policy should focus on the manager’s role and how managers contribute to better security of organizational information.

Beyond the manager role, other roles may need to be defined that capture the reality of effective policy-based governance inside the organization. For example, internal IT auditors often require read access to a broad array of information they use in order to perform their jobs. It is important that this access be read only so that they can retain effective independence from any information integrity issues that may exist.  Another area for special role based policies focuses on special rules for those who have administrative access to systems. Such matters as snooping through e-mails without specific direction and authorization by upper management are covered here. Also, policies that define when a privileged account may be used versus a personal account are examples of special case situations that need to be part of the overall policy fabric to protect those with high access and also to reassure others that policies are not just about being “trustworthy.”

Policy should fit the organization. It may make sense for policies to define the over 200 standards needed in a typical ISO 27002 based policy set. However, if it is a very small organization or a relatively immature organization in terms of either established business operations or the experience and maturity of those who work in the organization it may make sense for policies to be at a more summary level as a way to put a toe in the water of governance without overcommitting the organization to structure it can’t cope with. One inflection point that can be used effectively in this regard is the use of imperative language versus merely providing guidance or passive voice policies as a first step in policy language. In an immature company facing its first policy need, it may make sense for the “do’s and don’ts” policies to be defined with imperative language. For example “passwords must not be shared with others.” But for higher-level concepts passive voice may make more sense.  For example, “At Acme Company employees must protect Acme-confidential information.  Here there may be 100 standards eventually defined by Acme Company to protect its data. But if the desire is to get on the scoreboard and start a discussion, a passive voice statement such as this is often the best route to take.

A major issue in the adoption and uptake of policies by large organizations is the complete failure or in adequate socialization of the policies throughout the organization. Senior management must be personally involved in the overall effort and communicate that involvement and the importance of success in policy-based governance personally to the organization. When the CEO has taken time to write a paragraph or to deliver a 3 min. video message to all managers and employees about the new information security policies, everyone will know that their attention is required.  Further, managers within the organization must receive their own message that their acknowledgment and support of the information security policies is critical to the overall success of policy-based governance. Many issues are avoided by effective socialization. The “book on the shelf” reputation acquired by many policies is an example. If the policy manual is never consulted except when an outside entity such as an auditor or a consultant asks, they are not providing much value to the organization.  Yet another pitfall of inadequate socialization: when the policies are only dusted-off so they can be used in a punitive way but no broad effort is ever made to encourage compliance.  Avoid these issues by effectively socializing your policies through the organization.

Finally, culture is an extremely important yet poorly understood aspect of policy-based governance for information protection. How does your company articulate policies and rules that everyone understands and observes? Make your information security policies align in language and tone with the best of the policies already in place within the company. Here an example might illustrate the issue. Many years ago the IBM company purchased a Silicon Valley-based maker of telephone equipment called Rolm. Shortly after the deal was closed, two senior IBM executives showed up at a regular Friday afternoon get-together of Rolm employees. The IBMers had on their suits, white shirts and ties and were rather startled to see T-shirt clad engineers gathered around a beer keg enjoying a quintessentially Silicon Valley social event.  At that time, alcoholic beverages of any kind were prohibited at IBM premises.   It took a minute for the IBMers to get oriented and understand that the correct response in this situation was not to go over and shut down the beer and give Rolm managers a stern talking to. Rather, the IBMers were the ones who needed to adapt and their ultimate adaptation arguably helped IBM on its journey to a new leadership role in technology when so many of their competitors of the era would fall by the wayside. Culture is important and cannot be forgotten when defining policy about something most knowledge workers think about every hour of every day on the job: how they handle and protect company information.

News of RIM’s apologies concerning the multiple-day outage of its services beginning Saturday morning October 8 illustrates a very important point. At the retail level it may be okay to remain silent or mumble about the circumstances of an outage (as my cell provider did in this case).  However, when dealing with enterprises which purchase services in mass quantities as part of a broader strategy of delivering services to their customers through a well-equipped employee base the reverse is true.  RIM had remained silent for five days about the details, causes – and most importantly – the estimates for remediation of this outage. This is inexcusable for anyone offering an enterprise class product.

A company that understands the process of maintaining its systems and services and guaranteeing the reliability of those systems and services (and the revenues they support) will over-communicate about the circumstances of any unplanned outage.  By over communicating about an outage, the company shows the extent of its understanding, preparation, and detailed response plans. Obviously, developing incident response in a professional way is time-consuming and requires a great deal of maturity on the part of the company.  After all, you might never need these procedures and processes.  Most companies discover that developing incident response processes, tests, metrics, and plans is in and of itself a developmental activity for any large organization. These benefits can take many forms but two that are relevant here are: (1) improvements in the processes that underpin reliability itself such as reliable systems and applications development and (2) improvements in the incident response process such as better root cause analysis.  A company that can discuss these issues openly with its customers can subtly communicate that it has already brought a high level of professionalism to the problem and is in a position to leverage that professionalism for the benefit of its customers and for the reputation of the company. No amount of promise making or apologizing can substitute for this.

RIM did not do this and apparently cannot do it.  In the absence of communication during an outage, one of two explanations can be considered. The company either cannot figure it out (the most generous explanation) or they know the answer but the answer is so ugly they cannot afford to tell their customers the truth. No matter how heartfelt the apology, RIM’s enterprise customers don’t want or need apologies. What they need is information, substantial and detailed assurances about future support and possibly refunds. In a sense the damage to RIM is done. Emails were dropped and the corporate processes they supported were let down in a very public way. This debacle comes at a critical and unfortunate moment for RIM in light of iPhone and Android successes. As the outage unfloded, many people were already questioning RIM’s competitiveness and the longevity of its product line.  While it is true that no other provider even comes close to the quality of RIM’s product and service design and specifications for mony corporate procurement officers, the execution in this case shows that RIM is not able to walk the talk. This brings into question the true definition of “enterprise class.” And the tide of “bring your own device to work” is coming in inexorably and threatens to isolate RIM on a shrinking island of customer loyalty.

I can’t think of a worse time for RIM to be facing serious questions about its product and service reliability. In 30 years of professional information security practice, I have often observed that ways can be found to cut corners when it comes to the security of information systems and “bring your own device to work” is a perfect example of this. However, when it comes to reliability enterprise buyers stick to their guns and insist on the contracted reliability or else take their business elsewhere. I wonder what deals RIM has cut over the past weeks for aggrieved companies who were harmed by RIM’s outages.  Since I am a retail, second tier customer, I have been offered “free premium applications” by RIM.  What a scream! It might be more successful to take out an ad in the Wall Street Journal apologizing for RIM’s lame offer of compensation.  I probably spent four hours trouble shooting the problem at the time.  Oh, well.   It would also be interesting to see how many inquiries have been received by insurers lately about the availability of insurance against an outage of RIMs BlackBerry enterprise service. Not a good sign for RIM in the future.