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 of security and lose sight of the impact of the controls themselves.
Balance is key in the push-pull between security and business objectives, and sometimes those of us on the security side go too far.
A friend of mine recently hired on as information security manager at a major government 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 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 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 type of list 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 people’s authorization is required to make it all the way through the list, some streamlining is in order.
The classic problem with passwords is that users simply can’t remember them when they follow the rules for minimum complexity, or keep track of them when they have to be rotated frequently.
To compensate, they 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 is used, subverting password standards.
Stern messages and harsh penalties for such practices are often ineffective remedies 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.
In an IT context, notes and patterns introduce an unwanted element of predictability – 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.
That being the case, it’s worthwhile to provide instructions on how to create a password that’s easy to remember but hard to guess. This is a great alternative to mandating password requirements that go too far and which may lead to widespread contempt for security guidelines.
IMPEDIMENTS TO LEARNING
On a document management and extranet project several years ago, we discovered one unpleasant side effect of strong security: It was preventing self-education and learning of new technologies.
To reduce licensing costs, the system in question ensured that people had access to the documentation and tools necessary for their work, and only their work. 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 or 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.
KEEPING IT SIMPLE
The most widespread problem in information security is the constant crying of wolf. 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 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.
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 defences. 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 is Director of Security Consulting at a U.S.-based organization in the Pacific Northwest.
We'd love to hear your opinion about this or any other story you read in our publication. Click this link to send me a note →
Jim Love, Chief Content Officer, IT World Canada