When risk is present it calls for treatment, and security is a never-ending process… right? Yes, but as a security professional, it’s easy to become focused on the hard problems (download PDF) of security — falling into the arms race for more, more, more security controls — and lose sight of the impact of the controls themselves.
Balance is key in the push-pull between security and business objectives, and sometimes we on the security side go too far. (After all, the most truly secure computer is one that’s unplugged, boxed up and dropped down a deep well. And sometimes that’s tempting.) Here are some ideas for recognizing and pulling back from the edge when security controls or processes become unreasonable.
Locked out
A friend of mine recently hired on as information security manager at a major state agency. When I met him for lunch a month after he started, he was still sporting a stick-on visitor badge that indicated he needed an escort within the secure areas of his building. Likewise, I saw an international client’s new helpdesk coordinator repeatedly locked out of her shared office when co-workers departed for a smoke break. Both of these people have significant levels of access to sensitive data, but end up locked out of their own workspaces — physically as well as virtually — because the identification and access management methods are overwrought or out of sync with the employment process.
The lack of coordination between issuance of physical and logical access indicates both problems in the hiring process and disjointed management decisions regarding access. I haven’t seen many instances where new employees in any organization are greeted on their first day with a coordinated issuance of access credentials, computer, phone, and keys. It’s a challenge for most to simply get an ID badge on the first day.
A handy solution is to use the list of things that have to be done when someone is terminated. Human Resources usually has a termination checklist (download PDF) of tasks that includes obtaining the employee’s ID and keys; disabling system, network and application accounts; and ensuring that computers, mobile phone and other company property are returned. If one takes this list or another example and turns it around as a guideline for the access- and asset-granting process when a new employee is hired, it’s easy to see where the delays and other problems might lie. The same people that authorize revocation of access upon termination ought to be the ones who grant it to begin with. If more than two or three peoples’ authorization is required to make it all the way through the list, some streamlining is in order.
The every-time pad
The classic problem with passwords is that system and application users are overwhelmed by the required complexity, or by the password rotation frequency. They simply can’t remember passwords that follow the rules for minimum complexity, or keep track of their new passwords when they have to be rotated frequently.
To compensate, people resort to repeating patterns that are easy to remember — and predict, or write down passwords on notepads, whiteboards or even right on the case of the computer. Instead of the uber-secure one-time pad method for passwords, where a series of single-use passwords is given to a user (usually on a tear-off pad of paper) and replenished when used up, the sticky-note-by-the-monitor pad of paper is used to subvert password standards.
Stern messages and harsh penalties concerning these practices are often ineffective, because most people’s memory simply isn’t enhanced by punishment. Those who have difficulty remembering names, for example, have far more success when they resort to mnemonics or imagery-based association methods, as opposed to being sanctioned or threatened. Insistence on unworkable security rules may even lead to a tragedy of the commons (download PDF), where people stop caring about much besides their own functional well-being within an IT environment even as they accept actions that diminish the security of everyone.
In an IT context, notes and patterns introduces an element of predictability that one wants to avoid when using passwords — or so we’re used to thinking. In practice, however, the trade-off between accepting some degree of patterning and recording of passwords is often well worth the return in increased password strength and rotation.
The solution, such as it is? It’s worthwhile to provide instructions on how to create a password that’s easy to remember but hard to guess. Some examples are here and here. This is a great alternative to mandating password requirements that go too far — for example, by demanding they can’t even be derived from dictionary words — which may lead to widespread contempt for security guidelines.
Why Jane can’t learn
On a document management and extranet project several years ago, we discovered one unpleasant (and more or less unexpected) side effect of strong security: It was preventing self-education and learning of new technologies.
The system in question was intended to serve operations and development information to individuals according to the systems installed in their local operations center. This reduced the licensing costs by ensuring that people had access to the documentation and tools necessary for their work — and only their work. Accordingly, access to documentation for other systems, or to more advanced tools for operations and development, was perceived as unjustified and a license violation.
It doesn’t take long for this to create a stifling environment, and put personnel in the Catch-22 position of having to know information or have certain skills before being granted access to that information and the resources to develop those skills.
The answer is simply to back off, or provide an alternative in a non-production environment, either by borrowing some corner of the technical test environment or by establishing a dedicated educational environment. An extra or unused copy of software, development tools, and/or documentation should be made available through an internal library, or installed on a system dedicated to testing and education.
Unless employee turnover is constant and licensing restrictions are intractable, there’s little excuse for preventing learning and cutting off career growth. This small expense in both simple and complex IT environments can usually be justified by pointing out that lack of knowledge and human error are the single largest contributors to security problems.
Signal to noise
The most widespread problem in information security, however, is the constant crying of wolf. Within an organization, executives quickly become jaded when every security problem is referred to as “critical” and risk summaries contain page after page of technical esoterica cut-and-pasted from Nessus scanning reports.
Conversely, even the lowest-level users start to ignore risks over which they have no control. When the smallest detail is broadcast to the lowest level, it’s not surprising to see people set up email rules to automatically delete every security alert from IT.
Outside the organization, certain security consultants and so-called-experts become known for fear mongering in professional circles, and are eventually dismissed as blowhards after drowning others in false positives in the present, or by endlessly recounting war stories of times long past.
I suggest sticking to the facts, and presenting conditions and discoveries in a sane, context-appropriate manner. Give executives risk information that pertains to the business instead of details about technical infrastructure that’s intended to insulate the business from risk. Don’t ever dump raw security data on unprepared people. Give them information they can use, and ask them questions they can answer.
Likewise, don’t bother office workers with alerts and cranky warnings about security risks when they have no control or authority over preventive or reactive defenses. Tell ’em what they need to know, and let them come looking if they want more.
If it’s useful — for political, budgetary or just general-interest reasons — one can increase the signal-to-noise ratio of information security status and incidents by establishing a security topics mailing list. The content of such a list shouldn’t provide current vulnerability details that would be of significant help to a troublemaker, but might convey the dashboard-style status within the organization, with links to explanations and more reading. If nothing else, this is a nice way to address another classic security problem: If we’re doing our jobs right, no one knows we exist.
Jon Espenschied has been at play in the security industry for enough years to become enthusiastic, blase, cynical, jaded, content and enthusiastic again. He is Director of Security Consulting at a Pacific Northwest organization, and continues to have his advice ignored by CEOs, auditors and sysadmins alike.
