“When I use a word,” Humpty Dumpty said, in a rather scornful tone, “it means just what I choose it to mean - neither more nor less.” Lewis Carroll, Through the Looking Glass
Information security is often thought of in terms of technology - firewalls, anti-virus, code vulnerabilities and the like. However, security is fundamentally a 'people problem.' People, rather than systems, are the ones that make configuration mistakes, create and exploit vulnerabilities, steal passwords, divulge information, and in general make a nice living for those of us who get paid to clean up after them and find their blunders. While a router can understand its entire command set and will predictably respond to commands, humans rarely understand their complete native language, and are as unpredictable as tornados.
As security practitioners, our activities focus on identifying, quantifying and mitigating risk. The deliverables of this activity are communicated through policies and standards, white papers, diagrams, emails and memos. In short, security engineering is delivered through language. How we communicate when stating opinions and interpreting policy may seem clear-cut and pristine when we create the communication. Where we get into trouble is when recipients of the information can't read our minds, and what we intended to say often doesn't come out quite right.
Our messages are open to interpretation by human beings who are prone to errors of omission, perception and judgment, with different viewpoints from the author. There is also the environment to consider, particularly the effect of 'timing' (recent information carries more weight than previous information). It's no secret that most performance appraisals largely reflect your recent performance instead of a level assessment over the entire year. Your communications are no different, and will be interpreted based on recent events, even if those communications were separated from recent events by months.
Because of the people-focused nature of information security, improving security requires language to inform users of the security posture of their organization. If the language of information security is unclear, uses jargon or complex terms, then information security itself will suffer. What is sorely lacking from most policies is a simple and clear glossary of terms, which have hopefully been obtained from a well-accepted source (dictionary, NIST, etc.). Information security professionals toss around words like 'non-repudiation,' 'adjudication' and 'certified,' without establishing what those terms mean. 'Authentication' is often used instead of 'identification' or 'authorization,' as though they were interchangeable concepts. The same goes for 'vulnerability,' 'risk' and 'threat,' which are often abused. 'Encryption' seems to have been mangled in modern English to be a ready substitute for 'encipherment,' 'cryptography,' and even 'decryption.'
Have you ever had a co-worker who was notorious for publishing emails in horribly mangled English? If you had the time and the inclination you might have edited and wordsmithed the message, and sent it back, asking "Is this what you meant?" If you didn't, more fog covered the horizon. You don't want your intended audience left with a feeling of confusion when trying to understand your opinion. If you don't make clear and unambiguous sense, they will stop asking.
Tone and word choice are particularly critical in policy documents. Earlier in my career, I came across a malformed security policy that simultaneously bridged behavior and possession. It forbade possessing or distributing anything that "could be used to test or compromise security" (e.g., hacking tools). The intent was, presumably, to prohibit 'hacking tools' on company premises. Unfortunately, the policy didn't draw the line at hacker tools, but included anything that "could be used to test or compromise security," which was the fatal flaw. Since everyone in the company is expected to use log-in prompts, web browsers and operating systems, all of which 'can be used' to threaten security, then no one was compliant with policy.
This well-intended policy statement mixed behavior (hacking) with possession (tools). We can look to our own laws to find simple examples of where possession of an item (weapon, burglary tools, unlicensed explosives) and behavior (burglary, assault, vandalism) are separated for very good reasons. Using a chair is clearly OK unless I hit you across the head with it. A technical writer or communications expert could have fixed the ambiguity and passivity of our security policy right away, but they were not consulted and a subtle but significant difference was clouded.
None of us are perfect in this regard. But, like addiction, admitting the problem is the first step to recovery.
Do yourself and your organization a huge favor and take pro-active steps to ensure that language is a bridge to communication and not a barrier that decreases your security team's effectiveness. Write cleanly and clearly with your intended audience in mind. Brush up on grammar and word choice in your documents, and have peers review documentation before you ship it to your clients and customers. Ensure that your next policy re-write includes a technical writer as the editor, with general counsel as the likely co-editor for appropriate word choice.
Before you can define your organization as 'secure,' you must agree on what secure means. To ensure consistent language and clear terms, create an enterprise-wide dictionary of security terms that are commonly referenced by all security documents. Ensure the definitions themselves are clear and based upon a well-respected source, such as the National Institute of Standards and Technology (www.nist.gov), or whomever your industry looks to for standards. To address verbal communication issues, I heartily recommend Toastmasters International and Dale Carnegie training as excellent sources for helping you effectively communicate in a variety of situations.
Like any skill, communication skills will only improve with practice, so you will need to find a way in your organization and community to practice your communication skills. Write an article for the company newsletter, speak at internal and external events, write poetry, take a college writing course, or write white papers. Most importantly, have someone critique all of it to ensure you are improving.
Communication and language problems in security policy are not insurmountable, but these issues will be your constant companion as you try to change the behavior of people in your organization to improve security. By making language your ally, you have already solved one of your pressing security awareness problems: understanding.
Dan Houser, CISSP, SSCP, CCP is a senior security engineer for a major U.S. insurance carrier.
