Slashdot Mirror


Building an Effective Information Security Policy Architecture

Ben Rothke writes "Security policies are like fiber, that is, the kind you eat. Everyone agrees that fiber is good for you, but no one really wants to eat it. So too with information security policies. They are sorely needed, but most users don't go out of their way to comply with them. And in many firms, they are not even trained in what they have to do. But failure to have adequate information security policies can lead to myriad risks for an organization." Keep reading for the rest of Ben's review. Building an Effective Information Security Policy Architecture author Sandy Bacik pages 340 publisher CRC rating 8 reviewer Ben Rothke ISBN 978-1420059052 summary Good book for information security policy development For the sake of a basic definition, a policy is a formal, brief, and high-level statement or plan that embraces an organization's general beliefs, goals, objectives, and acceptable procedures for a specified subject area. The purpose of information security is to protect an organization's resources. The cornerstone of any information security strategy is a robust set of policies, procedures, standards and guidelines.

There are many reasons what information security policies are needed. Some of the most imperative reasons are:
  • To inform users of their information protection duties
  • Advise them what they can and cannot do with respect to sensitive information.
  • Define how users are permitted to represent the organization, what they may disclose publicly, and how they may use organizational computer resources for personal purposes.
  • To clearly define protective measures for these special information assets. The existence of a policy may be a decisive factor in a court of law, showing that the organization took steps to protect its intellectual property.
  • Define both acceptable and unacceptable behavior. For example, spending a lot of time surfing the web and downloading videos off the net are both generally unacceptable.
  • Policies are needed to establish the basis for disciplinary action, up to and including termination.


Building an Effective Information Security Policy Architecture does a good job of showing the reader how to start from scratch and build their security policy infrastructure. The book starts off at a high-level about the need for policies, and then goes into details on how to develop, write and sell these policies to management.

The book is a good guide to the entire policy lifecycle, and how to use various means to get to the ultimate goal. At 340 pages, the first ten chapters comprise 155 pages and deal with creating the policy infrastructure, communicating with management, and putting the entire policy puzzle together. The final 185 pages comprise 21 appendices of various examples of different policies.

A most significant downside and frustrating part to the book is that there is no CD-ROM with it, or companion website in which to download and use the numerous policy and process examples. At $80.00, such an option should be de rigueur. The lack of electronic versions of the policies in a book such as this is senseless.

Also, this is the first technology book that I have ever seen that did not cite a single reference. It is hard to imagine writing a book on this topic without using some sort of external reference. While the author may not want to quote sources, she should at least point the reader to other sources of information about security policies. Two notable and essential sources in the information security policy space are the SANS Institute — SANS Security Policy Project, which is free, and Information Security Policies Made Easy from Information Shield, Inc., which is $795.00, but worth every penny for a serious security policy effort. Full disclosure: I am on the Information Shield Expert Panel, but get no financial incentives or compensation.

Overall, Building an Effective Information Security Policy Architecture is a good resource to use if you are tasked to create or modify your organizations set of information security policies. The book will likely find itself on the desk of many information security professionals.

While it is frustrating that the book makes you reinvent the wheel by not having electronic versions of the polices, its value still can't be underestimated. Let's hope future versions of the book will fix that anomaly.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase Building an Effective Information Security Policy Architecture from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

11 of 70 comments (clear)

  1. First and most important rule by willyhill · · Score: 5, Insightful

    Never, ever do this yourself. Hire an consulting firm to come in and give you an outsider's view of your dirty laundry. More often than not when you're just used to how "things work around here" you end up overlooking an amazing amount of stuff that happens around you, which in turn leads to all the effort, time and money being wasted.

    Trust me on this one, my company tried to hot dog this ourselves twice and we failed both times. It wasn't until we brought someone else in that we ended up with a good working policy that really worked.

    Some people will get their egos dinged and feelings hurt in the process (including some near the top), but a VP's indigestion is far more manageable than a massive level I breach. This is especially true if your company handles anyone else's financial or personal data for a living.

    --
    The twitter monologues. Click on my homepage and be amazed.
  2. Slashvertisement by Anonmyous+Coward · · Score: 3, Insightful
    I mean, come on, who really cares about information security policies. The only thing they're good for is figuring out where to place the blame if something goes wrong. They're the tools of Mordac and something pushed by consultants who don't know security from the hole in their ass but want to sell you the very expensive service of developing a detailed policy that's completely impractical to follow.


    You can't identify sensitive information assets because there's just too much data and no one can agree on what's sensitive and what's not. You shouldn't bother telling uses what they can and can't do because they aren't paying attention and even if they are, when a situation comes up where they should actually be using that info, they've forgotten it. And users who can't figure out on their own that surfing the net for pr0n on company time is unacceptable will probably do it anyway.


    The only thing he got right is "Policies are needed to establish the basis for disciplinary action, up to and including termination." But it's an excuse for firing someone you probably didn't like anyway. If they're actually a valuable employee, you'll probably have to overlook whatever they did.

  3. Comment removed by account_deleted · · Score: 3, Insightful

    Comment removed based on user account deletion

  4. Comment removed by account_deleted · · Score: 4, Insightful

    Comment removed based on user account deletion

  5. CIO and CSO by Anonymous Coward · · Score: 1, Insightful

    I can see that there will be a new job in future for "Chief Security Officer" in addition to "Chief Information Officer" in every organization. The penguins of the board room will all get together and decide how best to separate information-tech from security because CIOs today don't know sh** about security, but they pretend and talk like they do. Of course there must be a few good ones, but the majority are a waste of cash and stock options. If they had been doing their job well, we wouldn't need these kind of books such as "Information Security Policy made easy" or "IS for Idiots"..

  6. Unfair punishment by Federal Trade Commission by Benjamin_Wright · · Score: 2, Insightful

    As part of a general security program, an information security policy can help to reduce exposure to legal liability for break-ins. . . . However, FTC did punish TJX (unfairly) even though it had a good faith security program. --Ben http://hack-igations.blogspot.com/2008/03/ftc-treats-tjx-unfairly.html

    --
    Benjamin Wright, Dallas, Texas, benjaminwright.us
  7. Re:Tight, but effective.... by Bishop · · Score: 4, Insightful

    If you break the security polices you should be fired. I don't care if it is trivially easy to tunnel protocol X over HTTP. If you are willing to break the IT security policies why should you be trusted?

    The problem with the "block known bad things" approach is that there are a lot of unknown bad things. It is far easier to profile for, and allow "known good things."

    Watching all traffic for anomalies is a joke. No one has figured out how to do it yet and they have been chasing that goal for a decade at least. I have seen countless demos of "network anomaly detectors" that have all failed. Anomaly detection probably requires AI to work.

    Given the technology available today the only effective technical controls we have to enforce an IT security policy is a default deny policy.

  8. So Dilbert.com is a security risk? by Broken+Toys · · Score: 2, Insightful

    From the summary:
    "Define both acceptable and unacceptable behavior. For example, spending a lot of time surfing the web and downloading videos off the net are both generally unacceptable."

    Acceptable behavior in the workplace should certainly be codified but by and large it is not a security issue. Gawking at YouTube videos all day is counter productive and probably not what your employers had in mind when they hired you. But it is not a security issue, it's a peformance issue and should be dealt with accordingly.

  9. Re:Tight, but effective.... by Jansingal · · Score: 2, Insightful

    >>If you break the security polices you should be fired. I

    that is sooooo stupid.

    Not every policy violation deserves the worker to be fired.

    What's next? Kill the jaywalkers?

  10. Re:Tight ... I was going to reply to Bishop .... by OldHawk777 · · Score: 2, Insightful

    You are for more right than Bishop is wrong ... or something like that.

    THE MISSION IS ALL! Security that prevents mission/CoreBiz+ performance is more harmful than valuable to the mission. However, probable mission success without some respectable and reasonable degree of security can be problematic.

    Don't let security stop reality. Keep security in perspective and segment the critical (plans, G2, accounts ...) content & systems from the daily office/public traffic. Security policy fails when you rely on people (the general office/public) keeping all the SecBS as ITgods-laws. Pay for a quality IT staff, retain them, keep them trained, outside-audit and stress-test your NetSec (OEM/OSD/OSP products/services updates, methods, edge-test/eval ...). Secure your network, systems, servers/services, content ... and be ready to share as much as possible or collaboration synergy without letting the evil ones know everything. Security is not a job for fools or dictators.

    Best NetSec advice ... GetSmartStaySharp and it will always be about Information Management and Sharing IMS with the best possible NetSec invisible to your staff, customers, and public. Never TripUp your users, layer your security, one level never fits all and is never effective from ... use PKI, Biometrics, monitoring, forensics ....

    --
    Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
  11. Security policies by Beryllium+Sphere(tm) · · Score: 3, Insightful

    You always have a policy. It may be implicit, relying on the experience and intuition of the technical people. It may be dysfunctional, like "everything goes". Or it may be written down, which I gather is the sort you find useless.

    Written security policies are just plain indispensable if you're covered by PCI/DSS or HIPAA, since both standards require them. They also give you a way to do knowledge transfer: before a written policy, the technogeeks know not to download free toolbars, after a written policy everyone does.

    Anything good has a policy underpinning it. Are the backup tapes encrypted? If so, it's because there was a policy decision to encrypt them, even if that decision was made by an empowered IT person rather than a suit or a consultant.

    >You can't identify sensitive information assets because there's just too much data and no one can agree on what's sensitive and what's not.

    You can identify enough to be useful. Customer credit card information and health records are things people can agree on, especially when external forces require them to. Protect the things you know are sensitive, and you can reduce the risk of something damaging or embarrassing happening, and reducing the risk is all you can hope for anyway.