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 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 is Director of Security Consulting at a US-based organization in the Pacific Northwest