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:
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.
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.
1. Open only as necessary per app.
2. Deny everything else.
Rule #1 -- Politics always trumps technology.
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.
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.
Comment removed based on user account deletion
Comment removed based on user account deletion
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
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.
So silly.
like no other publisher is under litigation.
with this logic, you could never buy another book, ever!
You are for more right than Bishop is wrong ... or something like that.
...) 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.
... 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 ....
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
Best NetSec advice
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
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.