Security policies are necessary, but their focus is to the detriment of more important security tasks. If auditors had looked for trivial SQL injection on a companies front-page as hard as they have checked for security polices, then maybe our industry would be in a better place. I want to make this go away, I want to help you tick the box so you can focus on the real work. If you just want the "tool" skip to the end.
A year and a half ago, SensePost started offering "build it" rather than "break it" consulting services, we wanted to focus on technical, high-quality advisory work. However, by far the most frequently "consulting" request we've seen has been asking for security policies. Either a company approaches us looking for them explicitly or they want them bolted on to other work. The gut feel I've picked up over the years is that if someone is asking you to develop security policies for them, then either they're starting on security at the behest of some external or compliance requirement or they're hoping that this is the first step in an information security program. (Obviously, I can't put everything into the same bucket, but I'm talking generally) Both are rational reasons to want to get your information security policies sorted, but getting outside consultants to spend even a week's worth of time developing them for you, is time that could be better spent in my opinion. My reasons for this are two-fold:
Saying all of this is fine, but it doesn't make the auditors stop asking, and it doesn't put a green box or tick in the ISO/PCI/CoBIT/HIPAA/SOX policies checkbox. Previously, I've pointed people at existing policy repositories, where sample policies can be downloaded and modified to suit their need. Sites such as CSOOnline or PacketSource have links to some policies, but by far the most comprehensive source of free security policy templates is SANS. The problem is people seem to look at these, think it looks like work, and move on to a consultancy that's happy to charge for a month's worth of time. Even when you don't, the policies are buried in sub-pages that don't always make sense (for example, why is the Acceptable Use Policy put under "computer security"), even then several of them are only available in PDF form (hence not editable), even though they are explicitly written as modifiable templates. What I did was to go through all of these pages, download the documents, convert them into relevant formats and categorise them into a single view in a spreadsheet with hyperlinks to the documents. I've also included their guidance documents on how to write good sec policies, and ISO 27001-linked policy roadmaps. I haven't modified any of the actual content of the documents, and those retain their original copyright. I'm not trying to claim any credit for others' hard work, merely make the stuff a little more accessible.
You can download the index and documents HERE.
In future, I hope to add more "good" policies (a few of the SANS policies aren't wonderful), and also look into expanding into security standards (ala CIS Security) in the future. If necessary, take this to a consultancy, and ask them to spend some time making these specific to your organisation and way of doing things, but please, if you aren't getting the basics right, don't focus on these. In the meantime, if you're looking for information security policies to go away, so you can get on with the bigger problems organisations, and our industry in general are facing, then this should be a useful tool.
Once you get high-level buy in / sign-off on the policy, you can start mapping the business processes to the policy, and then map the procedures (actual controls you mention) in the business process. It can be used as a constructive mechanism and not a 'cover my ass' strategy.
Need to filter what employees surf? Policy says "we will filter your web access". The control is the application or method you use, and then obviously the consequences if they transgress the policy..
Good post, and very helpful as a start for anyone! Hope to see more like it!
Policy says users need passwords on accounts, and those must change / expire etc, and that they're not allowed to share the passwords.
Business process shows that X-user needs Y-role in the accounting system to properly do segregation of duties (ie, user can't create a supplier, receive stock, and invoice the same supplier).
That ties to the process defined for getting the user the right permissions, and changing said permissions in the system(s), instead of users just sharing login details or all having 'super user' status in the system.
If the process isn't followed, it can mess up the business process, and be in violation of the policy..
Make sense?
As and example does you policy cater for iPads or Android Tablets or Blackberry playbooks or what about that one guy with a HP web OS device. And what about the slew of Windows 8 Devices coming on portable devices
Policies attempt to be generic by nature or neccesity - but it opens the door to "granular size" problems.