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?
---------------------------------------------------------------------------
EARN A MASTER OF SCIENCE IN INFORMATION ASSURANCE - ONLINE
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.
http://www.msia.norwich.edu/secfocus
---------------------------------------------------------------------------
