Don’t Emphasize Security

Don’t emphasize security. In fact, let’s avoid the word “security.” Talk, explain, in terms of availability, confidentiality, integrity and authenticity. These are concerns of our jobs, all of our jobs.

As a security professional, you help others do their jobs. Calling these considerations “security” adds a layer of abstraction to that assistance, when you should be pursuing detailed and specific assistance. Calling these considerations “Governance, Risk and Compliance” (GRC) also relies upon abstractions and emphasizes uses regulations as implementation goals. Regulations are audit goals. Your advice and recommendations should be accessible, implementable, useful and used.

In the January 14, 2009 presentation “Risk Management Processes & Tools to Know”, Raisa Loboda (Quality Assurance Manager for Bio-Rad Laboratories) could have been addressing an Information Management Security organization; the presentation was to the Organization of Regulatory and Clinical Associates (ORCA).

In the November 19, 1009 Cisco presentation “Network Security Survival Guide,” a presenter said you could look at a display panel and say “there’s your security.” That’s so wrong, so sloppy, so misleading.

Breaking out “security” as a separate characteristic of responsibility misleads people into believing that there are special security tasks to be done, a security layer to be designed, installed and maintained by a special security team. That’s not the message we want to deliver. “Security is everyone’s job” only because availability, confidentiality, integrity and authenticity are everyone’s job.

Breaking out “security” as a separate review phase brings the danger of reviewing only a particular sort of asset at risk. A security review may end with premises and data may receiving adequate attention, while safety of personnel and public reputation have been ignored.

When creating a budget, avoid the word “security”. Describe the purpose of the expenditure in terms of availability, confidentiality, integrity and authenticity. You can’t keep asking for money for security products every cycle. Explain how the money reduces risk without using the word “security.”

As a security professional, you’re taught to use the correct terminology if you wish to communicate intelligently. If you’re helping others do their jobs, the use of correct terminology will prevent you from communicating intelligently. Be prepared to leave the security lingo and speak in terms of availability, confidentiality, integrity and authenticity.

Another reason to throttled-back the its “all about security” mindset: Too often a new server is implemented by using the base install and applying and “security patches.” What about all the other patches? Daylight Saving Time updates, for example, are not considered security patches but are important updates. (CDO.DLL version less than 6.5.7651.61 for Blackberry Enterprise Server or Exchange with Outlook Web Access is a recurring issue.) A standard, supported configuration includes relevant non-security patches as well as security patches.

The counter-argument: Security, even with the best of implementations, is never built-in. In a best case scenario, a system can be built without known vulnerabilities. Eventually, vulnerabilities are discovered. Impractical scenarios become practical. Information which not considered sensitive becomes sensitive. Someone must be tasked with being informed about the vulnerabilities, determining risk and coordinating the mitigation measures (if any). Economies of scale would suggest that not everyone is involved in this task, and there should be specialization.

The mixed message: Don’t reuse passwords (don’t use a password for more than one account), and change passwords frequently (more frequently than they can be cracked). That’s good advice, but difficult to implement if you also ban writing down passwords. Banning password reuse and requiring password changes requires each person have a password management system, perhaps a piece of paper or a file, and protection for these passwords (such as a wallet or encryption tool, such as KeePass). Stopping at the “no password reuse” and “change passwords frequently” requirements sends a mixed message; you want “security” but don’t offer any plan to accomplish what you want.

If you then ban all USB devices, you further dilute your “we take security seriously” message. Persons who tried to implement your requires with a KeePass file on a USB storage device are thwarted.

Offer the situation you want. A system consisting of only prohibitions sends a mixed message.