IA policies (part 1)

Do we allow any wiggle room?

How do we resolve the issue of acknowledging (to ourselves) that some of our information assurance (IA) policies cannot, or should not, be strictly enforced, while at the same time conveying to staff the importance of always following IA policies?

My friend and colleague Adjunct Professor Richard Steinberger, CISSP, CISM from the MSIA Program at Norwich University recently raised the issue of rigidity of security policies and how employees get around those policies. I invited him to expand on his thoughts; everything that follows is entirely Ric's work with minor edits.

* * *

A recent article asked readers the following question: "Got your own file-sending solutions for places where the filters are strong? Tell us all about them in the comments." The context was a story about an employee who had used Gmail to send himself material that his organization's deployed IA policy was blocking. Many Lifehacker readers happily contributed their not-especially-sophisticated approaches, such as, "Use https instead of http," or "Zip the document, and then add a password," or simply, "Change the file suffix to something that doesn't get filtered."

The Lifehacker article helps remind us of a few important points, including:

1) No matter what an organization's IA policies are, some staff members convince themselves that they have a legitimate need, even a right, to bypass them.

2) Unless an organization's IA policies reflect the existing business culture, then at least some staff members will feel they have a right or even a need to ignore some of these policies.

3) Employees, i.e., insiders, can be quite skilled and persistent at discovering new approaches towards subverting, ignoring or going around inconvenient policies.

Consider an analogy with traffic laws (i.e., policies). Does this sound like someone you know? Joe (or Joan) always comes to a complete stop at red lights. At stop signs, Joe reduces his speed to about 5 mph, and if it's clear to cross the intersection, he speeds up and drives through. On the highway, where the speed limit is posted as 65 mph, Joe usually drives about 70 to 75, especially if other drivers do the same. Joe recently purchased a radar detector to notify him of local policy enforcement zones. Joe's been driving for many years and receives an insurance discount that reflects his safety record.

Almost all of us have employees like Joe where we work (and indeed, we may even be a Joe or Joan). We do our best to create and deploy IA policies that:

1) Keep the organization in compliance with statutes and regulations.

2) Make sure that our organizations follow our own rules (e.g., we will strictly limit access to customer data).

3) Follow best practices for our industries.

4) Implement any special requirements we may have (e.g., protect our intellectual property, require strong passwords).

As IA professionals, we would be naïve to imagine that Joe doesn't work as he drives: Joe understands the traffic laws, and bends them when he judges it's in his best interests to do so. If he is a good employee, he may bend our security policies when he judges it's in the organization's best interests. The question we should be asking ourselves is not, "How do we find and discipline (or fire) Joe?" Instead, we should think about these issues:

• To what extent do our IA policies reflect our business values and culture? Have we done our best to make sure that staff understand specifically those policies which will frequently seem to be especially inconvenient?

• How tolerant/flexible are we prepared to be with policy infractions and how much effort are we willing or able to spend on detecting them?

In the next of these two articles, Ric and I discuss the issue of fair vs arbitrary flexibility in IA policies.

* * *

Steinberger, CISSP, CISM has more than 20 years of hands-on and supervisory experience with computers and networks with special expertise in Internet and network security; security principles and products including firewalls, routers, VPNs, vulnerability assessment tools, intrusion-detection systems, and hacking tools; advanced Unix software development; and system administration. He has taught network security at University California Berkeley Engineering Extension and for several years as Adjunct Professor of Information Assurance in the MSIA Program at Norwich University. You may reach Ric by e-mail.

Learn more about this topic

Pentagon scraps IPv6 testing program that provided enterprise guidance

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:
Now read: Getting grounded in IoT