Home page logo

basics logo Security Basics mailing list archives

RE: Security Policies
From: "Vic N" <vic778 () hotmail com>
Date: Fri, 20 Jan 2006 22:28:49 -0800

My take is that this is a "tail wagging the dog" question. Writing policy that doesn't fit an obvious business practice is like putting a square peg in a round hole. A more accurate question might be, "Where are we deficient in a process?"

Implementing a policy strictly for an audit requirement that has no business value probably will ultimately fail once you turn your attention away. For example, some developers do not see intrinsic value in formal change management processes. They might argue that the time to market to maximize shareholder value is the overriding concern.

My goal in a situation like that is to apply high level policy language to their existing processes that can be reasonably argued to meet an audit requirement. Where there are true deficiences, the more I can align an audit requirement to an existing practice, the less invasive a needed change *may* be perceived. They are more likely to embed that requirement into their processes than an extneral, rigid process that demonstrably fits a perceived audit requirement.

You should have as few policies as possible. :)

The balance that I have struck is to ask, "What is the audit requirement?" and "How do we meet that audit requirement?" How that requirement is met becomes the basis of policy. Asking, "What is my acceptable usage policy?" may be less relevant than, "What is the intent of an 'Acceptable Usage' policy?" and "How do my existing policies meet that intent?"

Outside of that, it seems most valuable to write a policy where you actually have a demonstrated need. Those policies are self-evident, imho. Policy seems to be most conducive to IT units that aren't necessarily operations-oriented (responsible for generating revenue).

For example, small teams that serve large numbers of internal, non-customer users will be big fans of policies that state something like "dont disable antivirus on your workstation". However, what really makes that effective is the ability to enforce that through something like group policy. The ability to prevent the undesired activity is more valuable than the assertion that the activity is prohibited. If that is not the case, the value in making a policy is minimal. The policy statement affirms an enforceable intent.

Setting policies that can't be enforced are especially problematic. It's not that the policy statement won't have value, but your ability to demonstrate your org *enforces* that policy may be unprovable. You set your team up to fail in that scenario.

Good Luck! :)

We are currently revamping our Incident Response Process which will ultimately be reflected in our Incident Response Policy. How do we spawn changes to other policies, like Information Usage, etc.
I'm not sure where to start?
I'm a little unsure of what we already have policywise and what we need to have a good set of security policies? What are the core policies that every company should have?

The Norwich University program offers unparalleled Infosec management education and the case study affords you unmatched consulting experience. Tailor your education to your own professional goals with degree customizations including Emergency Management, Business Continuity Planning, Computer Emergency Response Teams, and Digital Investigations.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]