Should all applicable controls be mentioned in documenting an ISMS?
In my very first job we were told, repeatedly told, to document everything and keep our personal journals up to date. Not just with what we did but the reasoning behind those decisions. This was so that if anything happened to use kn knowledge about the work, the project, what had been tried and thought about was lost, if, perhaps, we were 'hit by a bus on the way to work'.
At that point whoever was saying this looked toward a certain office or certain place in the parking lot. One of the Project managers drove a VW bus and was most definitely not a good driver!
So the phrase 'document everything in case you're hit by a bus' entered into the work culture, even after that individual had left.
And for the rest of us it entered into our person culture and practices.
Oh, and the WHY is very important. How often have you looked at something that seems strange and worried about changing it in case there was some special reason for it being like that which you did no know of?
Unless things get documented .... Heck a well meaning 'kid' might 'clean it out' ignorant of the special reason it was like that!
So here we have what appear to be undocumented controls.
Perhaps they are just controls that were added and someone forgot to mention; perhaps the paperwork for these 'exceptions' is filed somewhere else[1] or is referred to by the easily overlooked footnote or mentioned in the missing appendix.
It has been pointed out to me that having to document everything, including the reasons for taking one decision rather than another, "slows down work". Well that's been said of security, too, hasn't it? I've had this requirement referred to in various unsavoury terms and had those terms associated with me personally for insisting on them. I've had people 'caught out', doing one thing and saying another.
But I've also had the documentation saving mistakes and rework.
These days with electronic tools, smartphones, tablets, networking, and things like wikis as shared searchable resources, its a lot easier.[2]
Sadly I still find places where key documents such as the Policy Manuals and more are really still "3-ring binder" state of the art, PDF files in some obscure[1] location that don't have any mechanism for commenting or feedback or ways they can be updated.
Up to date and accurate documentation is always a good practice!
[1]http://hitchhikerguidetothegalaxy.blogspot.ca/2006/04/beware-of-leopard-douglas-adams-quote.html
[2] And what surpises me is that when I've implemented those I get a 'deer in the headlight' reaction from staff an managers much younger than myself. Don't believe what you read about 'millennials' being better able to deal with e-tools than us Greybeards.
Related articles
The Truth About Best Practices
An article on Linked entitled 'The Truth about Practices" started a discussion thread with some of my colleagues.
The most pertinent comment came from Alan Rocker:
I'm not sure whether to quote "Up the Organisation", ("If you must have a
policy manual, reprint the Ten Commandments"), or "Catch-22" (about the
nice "tidy bomb pattern" that unfortunately failed to hit the target), in
support of the article.
Industry-wide metrics can nevertheless be useful, though it's fatal to
confuse a speedometer and a motor.
However not everyone in the group agreed with our skepticism and the observations of the author of the article.
One asked
And Anton aren't the controls you advocate so passionately best practices? >
NOT. Make that *N*O*T*!*!*! Even allowing for the lowercase!
"Best practices" is an advertising line of self-aggrandization invented by the Big Name Accounting Firms when operating in Consulting Mode.
Does ISO 27001 compliance need a data leakage prevention policy?
On one of the ISO-27000 lists I subscribe to I commented that one should have a policy to determine the need for and the criteria for choosing a Data Loss Prevention mechanism.
I get criticised occasionally for long and detailed posts that some readers complain treat them like beginners, but sadly if I don't I get comments such as this in reply
Anton
Data Loss is something you prevent; you enforce controls to prevent data
leakage, DLP can be a programme, but , I find very difficult to support
with a policy.
Does one have visions of chasing escaping data over the net with a three-ring binder labelled "Policy"?
Let me try again.
Policy comes first.
Without policy giving direction, purpose and justification, supplying the basis for measurement, quality and applicability (never mind issues such as configuration) then you are working on an ad-hoc basis.
An OP-ED by Richard Clarke on China
http://www.nytimes.com/2012/04/03/opinion/how-china-steals-our-secrets.html
This is better written than most 'chicken little' pieces, but please can we have 'history' of how most nations, including the USA, have engages in 'industrial espionage'.
I recall a presentation by CSIS that was making the point that Canada's greatest threat on the Industrial Espionage scene was France, and France had been practising Industrial Espionage against the "English Speaking World" for centuries. And he had evidence to back that up from at lest Napoleonic times.
But then don't forget that the "English Speaking World" stole such secrets from China as "Tea":
For centuries, the secret of growing tea was one of China's
most closely-guarded treasures. Along with silk, tea was an
extremely valuable agricultural commodity, prized as a luxury
item across Asia and into Europe.In the mid-19th century, however, Briton Robert Fortune
dressed as a Chinese man (complete with queue) and set out
to discover the secret of tea-growing. He located the bushes
that produce tea, and stole seedlings that he transported to
British India. China's tea monopoly was broken.Robert Fortune (1812-1880) (Photo credit: Wikipedia)
Fortune's explorations are detailed in a new book, For All
the Tea in China, by Sarah Rose. She frames this not
simply as a tale of Victorian exploration, but as early
industrial espionage - which, of course, it was.
I'm not saying this justifies anything, any more that the Opium trade or forcing products from the Industrialized West onto Asian markets, also part of or common historic context, justifies any reprisals.
I'm just saying Context is Everything and if you ignore history (especially when dealing with people for whom history is an important context) then you are setting yourself up for a sea of troubles.
Related articles
- For All The Tea In China - Sarah Rose (scottjb.wordpress.com)
- Different Ethical Issues Faced by the Global Software Companies (thinkingbookworm.typepad.com)
- Howes calls for cyber espionage inquiry (news.smh.com.au)
- Corporate Espionage Is Real - Even In The Pharma Industry (bioresearchonline.com)
- "Cyber Czar" wants Homeland Security to patrol America's Internet borders (blacklistednews.com)
- Former Pentagon Official Says All Chinese Electronics In The US Could Have Built-In Trapdoors (businessinsider.com)
- FBI: Economic Espionage (gloucestercitynews.net)
- Trade Secrets and The Economy (psliplaw.wordpress.com)
- Richard Clarke: China has hacked every major US company (zdnet.com)
- FBI cracks down on economic espionage (wjla.com)
- Peter Thomas Senese's THE DEN OF THE ASSASSIN Is A Geopolitical Financial Espionage Thriller Thrust In The World Of Cyber, Biological and Chemical Warfare (prweb.com)
- Chinese Economic Espionage: An Overlooked Concern (heritage.org)
Managing Software
Last month, this question came up in a discussion forum I'm involved with:
Another challenge to which i want to get an answer to is, do developers
always need Admin rights to perform their testing? Is there not a way to
give them privilege access and yet have them get their work done. I am
afraid that if Admin rights are given, they would download software's at
the free will and introduce malicious code in the organization.
The short answer is "no".
The long answer leads to "no" in a roundabout manner.
Unless your developers are developing admin software they should not need admin rights to test it.
Social Engineering and sufficency of awareness training
Someone asked:
If you have a good information security awareness amongst
the employees then it should not a problem what kind of attempts
are made by the social engineers and to glean information from
your employees.
Yes but as RSA demonstrated, it is a moving target.
You need to have it as a continuous process, educate new hires and educate on new techniques and variations that may be employed by the 'social engineers'. Fight psychology with psychology!
About ISO 27001 Risk Statement and Controls
On the ISO27000 Forum list, someone asked:
I'm looking for Risk statement for each ISO 27k control; meaning
"what is the risk of not implementing a control".
That's a very ingenious way of looking at it!
One way of formulating the risk statement is from the control
objective mentioned in the standard.
Is there any other way out ?
Ingenious aside, I'd be very careful with an approach like this.
Risks and controlsare not, should not, be 1:1.
How to decide on what DVD backup software to use
You do do backups don't you? Backups to DVD is easy, but what software to use?
- Do you want the DVD backup 'mountable'?
If it is then you can see each file and selectively restore using the normal file management tools (cp, rsync etc)
If you use some sort of 'dump' format (tar, cpio, zip or proprietary) then you will need the corresponding tool to access the backup - Why not simply k3b?But if it some down to it, there's a decision tree you can and should work though.
My choice, based upon both K.I.S.S. and bitter experience is to go with the mountable.
- - How are you 'snapshoting' your files?
If you are backing up a live system[1] then there is the risk that the backup is out of phase with itself as files get changed during the time it takes to make the backup.
My solution to this is to use the snapshot mechanism of LVM.
Logical Volume Management
- - How are you managing the backup archives?
Do you need a specific dated version of a file or directory?
Would a VCS be more appropriate than a backup system?
Sometimes you need both. I maintain changes to config (mainly in /etc/) with a VCS - AND take periodic snapshots.
- Ultimately its not about making backups, even if that seems to be the
most of the work, but the ability to restore.
A client found it easier to take whole image backups but once when having to restore a single file there was a finger-slip and he restored the complete machine state of three years previously, loosing all that days work plus the next day when the machine was out of service being restored to the last (previous) backup. The moral here is that your RESTORE strategy, as determined by your normal business functions and NOT by the convenience of the IT department, should determine your backup strategy.
- - How "automated" do you want this backup to be?
Sometimes you'll find the automation tail wags the normal operation dog.
My use of K3B means I do disk-to-disk-to-DVD. (Using LVM's snapshots)
It also means I structure my file systems so that they can be imaged onto a DVD. It means I can retrieve single files or mount the DVD and use it in place of the file system. It also means that I can create arbitrary backups, cherry-picking the files and folders to backup.
I realise this is going to be inappropriate for many sites and business functions.
This is why I STRONGLY suggest that instead of simply asking for suggestions you work through what are the key, the critical and the nice-to-have features of your backup AND RESTORE functionality.
Any package you might choose is going to have constraints and assumptions about The Way Things Are. You need to be aware of those and need to consider if they fit in with The Way You Work. A backup system that works well for a data center of ISP might be totally inappropriate and troublesome for a SMB.
[1] Once upon a long time ago systems were shutdown or all jobs
suspended for the backup. This has disrupted projects for me a number
of times.
Related articles
- Backup Programs (wiki.archlinux.org)
- Call for back up (johnlewis.com)
- O&O DiskImage 7 Professional review (betanews.com)
- Why use Online Backup? (safedatastorage.wordpress.com)
On the HP Printer Hack
The hack to make the HP printers burn was interesting, but lets face it, a printer today is a special purpose computer and a computer almost always has a flaw which can be exploited.
In his book on UI design "The Inmates are Running the Asylum", Alan Cooper makes the point that just about everything these days, cameras, cars, phones, hearing aids, pacemakers, aircraft, traffic lights ... have computers running them and so what we interface with is the computer not the natural mechanics of the device any more.
Applying this observation makes this a very scary world. More like Skynet in the Terminator movies now that cars have Navi*Star and that in some countries the SmartStreets traffic systems have the traffic lights telling each other about their traffic flow. Cameras already have wifi so they can upload to the 'Net-of-a-Thousand-Lies.
Some printers have many more functions; some being fax, repro, and scanning as well as printing a document. And look at firewalls. Look at all the additional functions being
poured into them because of the "excess computing facility" - DNS, Squid-like caching, authentication ...
I recently bought a LinkSys for VoIP, and got the simplest one I could find. I saw models that were also wifi routers, printer servers and more all bundled onto the "gateway" with the "firewall" function. And the firewall was a lot less capable than in my old SMC Barricade-9 home router.
I'm dreading what the home market will have come IP6
I recall the Chinese curse: yes we live in "interesting security issue" times!
But in the long run of things the HP Printer Hack isn't that serious. After all, how many printers are exposed to the Internet. We have to ask "how likely is that?".
Too many places (and people) put undue emphasis on Risk Analysis and ask "show me the numbers" questions. As if everyone who has been hacked (a) even knows abut it and (b) is willing to admit to the details.
No, I agree with Donn Parker; there are many things we can do that are in the realm of "common sense" once you get to stop and think about it. Many protective controls are "umbrellas", that its about how you configure your already paid-for-and-installed (you did install it, didn't you, its not sitting in the box in the wiring closet) firewall; by spending the money you would have spent anyway for the model that has better control/protection -- you do this with your car: air-bags, ABS and so on so why not with IT equipment? The "Baseline" is more often about proper decisions and proper configuration than "throwing money at it" the way governments and government agencies do.
Which Risk Framework to Use: FAIR, FRAP, OCTAVE, SABSA …
What framework would you use to provide for quantitative or qualitative risk analysis at both the micro and macro level? I'm asking about a true risk assessment framework not merely a checklist.
Yes, this is a bit of a META-Question. But then its Sunday, a day for contemplation.
When does something like these stop being a check-list and become a framework?
COBIT is very clearly a framework, but not for risk analysis and even the section on risk analysis fits in to a business model rather than a technology model.
ISO-27K is arguably more technology (or at least InfoSec) focused that COBIT, but again risk analysis is only part of what its about. ISO-27K calls itself a standard[1] but in reality its a framework.
The message that these two frameworks send about risk analysis is
Context is Everything
(You expected me to say that, didn't you?)
I'm not sure any RA method works at layer 8 or above. We all know that managers can read our reports and recommendations and ignore them. Or perhaps not read them, since being aware of the risk makes them liable.
Ah. Good point.
On LinkedIn there was a thread asking why banks seem to ignore risk analysis .. presumably because their doing so has brought us to the international financial crisis we're in (though I don't think its that simple).
The trouble is that RA is a bit of a 'hypothetical' exercise.
The Decline of the Physical Desktop
http://www.eweek.com/c/a/IT-Management/As-Foretold-by-Desktop-Managment-Tools-588370/
What's interesting here is that this isn't preaching "The Cloud" and only mentions VDI in one paragraph (2 in the one-line expanded version).
Also interesting is the real message: "Microsoft has lost it".
Peter Drucker, the management guru, pointed out that the very last buggy-whip manufacturer in the age of automobiles was very efficient in its processes - it *HAD* to be to have survived that long. (One could say the same about sharks!)
"Keeping desktop systems in good working order is still a labour of Sysiphus .."
Indeed. But LinuxDesktop and Mac/OSX seem to be avoiding most of the problems that plague Microsoft.
A prediction, however.
The problem with DOS/Windows was that the end user was the admin and could fiddle with everything, including download and install new code. We are moving that self-same problem onto smart-phones and tablets. Android may be based on Linux, but its the same 'end user in control' model that we had with Windows. Its going to be a malware circus.
Related articles
- eWEEK Review: Unidesk Simplifies VDI Deployment and Management (prweb.com)
- Dell Delivers Desktop-as-a-Service (informationweek.com)
- Zenk GmbH to Distribute Unidesk VDI Management Software in Germany (prweb.com)
- The key questions you must ask to save your virty desktop dream (go.theregister.com)
- 6 Common Desktop Virtualization Mistakes (informationweek.com)
- 5 Best Alternatives of Windows 8 (indianbloggist.com)
In praise of OSSTMM
In case you're not aware, ISECOM (Institute for Security and Open Methodologies) has OSSTMM3 - The Open Source Security Testing Methodology Manual - http://www.isecom.org/osstmm/
There's an interesting segue to this at
https://www.infosecisland.com/blogview/14651-How-to-Pen-Test-Crazy.html
Skip over his ranting about the definition of "hackers"
This is the meat:
Wewrote the OSSTMM 3 to address these things. We knew that penetration
OSSTMM Logo
testing the way it continued to be marginalized would eventually hurt
security. Yes, the OSSTMM isn't practical for some because it doesn't
match the commercial industry security of today. But that's because the
security model today is crazy! And you don't test crazy with tests
designed to prove crazy. So any penetration testing standard, baseline,
framework, or methodology that focuses on finding and exploiting
vulnerabilities is only perpetuating the one-trick pony problem.
Furthermore it's also perpetuating security through patchity, a process
that's so labor intensive to assure homeostasis that nobody could
maintain it indefinitely which is the exact definition of a loser in the
cat and mouse game. So you can be sure it also doesn't scale at all with
complexity or size.
I've been outspoken against Pen Testing for many years, to my clients, at conferences and in my Blog. I'm sure I've upset many people but I do believe that the model plays up to the Hollywood idea of a Uberhacker,
produces a whack-a-mole attitude and is a an example of avoidance behaviour, avoiding proper testing and risk management such as incident response good facilities management.
I've seen to many "pen testers' and demos of pen testing that are just plain ... STUPID. Unprofessional, unreasonable and pandering to the ignorance of managers.
In the long run the "drama-response" of the classical pen-test approach is unproductive. It teaches management the wrong thing - to respond to drama rather than to set up a good system of governance based on policy, professional staffing, adequate funding and operations based on accepted good principles such as change management.
And worse, it
- shows how little faith your management have in the professional capabilities of their own staff, who are the people who should know the system best, and of the auditors who are trained not only in assessing the system but assessing the business impact of the risks associated with a vulnerability
- has no guarantees about what collateral damage the outsider had to do to gain root
- says nothing about things that are of more importance than any vulnerability, such as your Incident Response procedures
- indicates that your management doesn't understand or make use of a proper development-test-deployment life-cycle
Yes, classical hacker-driven pen testing is more dramatic, in the same way that Hollywood movies are more dramatic. And about as realistic!
"Crazy" is a good description of that approach.
BCP or BIA
- Image via Wikipedia
A business might possibly choose not to have a BCP but they might be interested in doing a BIA
After all, the "impact" might be something positive resulting from some change.
Oh, the Irony!
Expeditious and cost effective.
I've audited BCPs and always found them lacking. They are difficult to build and often make assumptions that are necessary to get the plan done but are unreasonable in reality.
You don’t need a Firewall Security Policy
A member of a discussion list I subscribe asked for a Firewall Policy template.
A usual, I was alarmed enough by this to want to comment and drag it back to the discussion on "assets".
I don't think you should have a "Firewall Security policy".
This is why.
A great book on firewalls once described the firewall as
The network's response to poor host security
You can occasionally see articles on host-centric security drifting by ...
A firewall is a "network PERIMETER protection device".
Do you have a well defined perimeter to which you can apply enforcement policies, or is your 'perimeter' like so many businesses these days, a vague and nebulous concept that is weakly defined? One thing that is "in" these days is "De-perimiterization". See "The Jericho Forum".
The firewall model is inherently one of a 'hard outer shell and soft vulnerable centre'. As I said, its based on the idea of poor host security. Good host security will mean that the hosts don't have any un-necessary open ports. Scan you network. If there are no open ports why do you need a firewall?
Oh, right: port 80. And all the hundreds of services behind it.
In effect those are your 'open ports'. Yes, there are firewalls that claim to do 'deep packet inspection'. Check what they actually do.
There are other uses for a firewall? Well some people use it as a NAT device. Some people use it to control outbound connections - "data leakage". What they are really saying is that they haven't built their information architecture in a robust and secure manner. Back to the 'poor host security'. Perhaps you should be doing this sort of thing in your switch or router with ACLs. Partition your network.
So why did I start by saying "assets"?
Some people think that the assets are the hardware.
Focusing on the hardware as opposed to the services, the information and the processes leads you to think in terms of things like 'firewalls' rather than in abstracts like "perimeters" and "access controls".
By addressing a "Firewall policy" you are focusing on equipment rather than fundamentals.
A Security Policy needs to be abstract not specific
- Image via Wikipedia
There's much I don't like about many of the published security policies an the ones I see in use at many sites I visit and audit. But lets pick on ones that deal with passwords.
Firstly, the concept of passwords are limiting.
Are you going to add a "pass-card policy" and a "iris scan policy" and a "fingerprint policy" ?
Of course not. its all "Authentication".
And it doesn't matter where or how or even WHAT you are accessing - policy applies. So the policy has to be general.
The workshops I've run on policy writing open with an explanation of what makes good and bad policy and use this point as an illustration. Good policy is general and isn't going to need to be revised as business
needs or technology - and hence risk and how its addressed - change.
Access to corporate Information System resources
will be restricted to authorized users in accordance
with their roles. Users will uniquely identify
themselves and will be accountable for the actions
carried out under this identification.
Simple language, very general.
You could say it even applies to the to the parking lot at the data centre.
It doesn't address passwords or swipe cards or fingerprints directly for a simple reason.
THEY ARE NOT POLICY ISSUES.
Le me say that again.
Specific controls and specific control technology are not policy issues.
They are standards.
Refer to them. Refer to NIST, refer to the Microsoft documents.
They are not policy.
The _general_ example I gave above is POLICY.
Can you see the difference?
Now read that paragraph again.
Does it say anything about HOW you access corporate IS resources?
No.
So it doesn't matter if you do it at the computer at your desk in the office; from your laptop when working at home over the VPN; from the airport using your smartphone over the Internet. It doesn't matter if the 'resource' is a parking lot, the email server or in 'The Cloud' somewhere.
You don't need separate policies for all of them.
I picked on 'password policy' because its easy to illustrate how a specific like this is wrong-minded and can easily be invalidated by a shift in technology. But the principle applies to the whole of the proposed document.
Why does this matter?
A minimalist approach has much to recommend it.
Quite apart from making the document shorter an hence easier to communicate, it eliminates redundancy and with it the opportunity for sections that talk about what is essentially the same thing but end up
being contradictory.
The example I gave avoids there being questions like
Does remote access use passwords or certificates?
because its NOT a policy issue. A 'remote access policy' might or might not talk about passwords, about SSH, kerberos or X.509 depending on the the bias of a technical writer. In which case its about standards, not policy, and its about access controls, no policy.
Implementation details - controls - must not be embedded in policy.
There a lot more potential for conflict in the document structure as its laid out at the moment.
Why do I talk about it?
Lets leave a policy document aside or a moment and thing of our jobs as Information Security specialists. part of our roles is thinking about what can go wrong, the weaknesses in the configuration and management of the Information systems, management, communication and storage. We think about threats and vulnerabilities.
Now apply that same approach to the document. this one you are calling a "policy manual". Don't take a bottom-up approach, such as arguing over the length of a password or how often it should be changed. That isn't policy. At best its a standard and a highly context sensitive one at that!
Identify what is in common and make it a policy.
I gave the example above of access control.
It doesn't matter whether its access to the workstation, the server, that CRM database, the "pipe" out to the Internet, or the Citrix array inbound over the 'Net from home or an Internet caf�.
It all access to corporate IS resources. It should have one and only one policy. It should not be spread over a number of policies with ifs and buts and different technologies and phases of the moon.
Remember: you have to write policy that can be followed and can be enforced. If users )or sysadmins for that matter) have to remember lots of different circumstances and special conditions then they are less
likely to conform. "Oh, I forgot"; "Oh, I was confused"; "Oh, I didn't think it applied here"; "Oh, I didn't think it applied to me".
That's a start.
Yes, I've picked on "access", but I could equally well have picked on "virus" or "email" or "mobile".
About Social Networking policy
Policy development is one of my areas of practice, so when a colleague on a mailing list asked about how to phrase policy to deal with the social networks (Facebook, Twitter, Myspace, etc.) and what the "best practices" are, I came out of my shell to reply.
(We'll skip over the oxymoron "best practices" since "Context is Everything".)
The phrase
"Use of corporate resources ..."
is a wonderful one to use to prefix just about any policy statement or justification. In one workshop on policy development that I ran someone pointed out that it applied to access to the company parking lot!
The issue here isn't "social networking", no matter how much the media and ZDNet would have you believe. It boils down to a few very clear and easy to enumerate issues:
About creating Corporate IT Security Policies
As I've said before, you should not ask yourself what policies to write but what you need to control. If you begin with a list of polices, you need to adapt the reality to the list. The risk is that you create a false sense of control of security.
The threat-risk approach is 'technical', and as we've discussed many times, the list of threats cannot be fully enumerated, so this is a ridiculous approach.
Basing policy on risk is also a fruitless approach as it means you are not going to face some important points about policy.
Policy is for people. Its not technical, its about social behaviour and expectations.
Policy can be an enabler, but if you think only about risk you will only see the negatives; your policies will all be of the form "Don't do that".
Policies should tell people what they should do, what is expected of them, give them guidance.
Policies also have to address the legal and regulatory landscape. As such they may also address issues of ethics, which again is not going to be addressed by a threat-risk approach.
All in all, if you follow Mark's advice you may write policies that seem OK, but when it comes to following them it will be like the song from the 70s by The Five Man Electric Band:
Sign Sign everywhere a sign
Blocking out the scenery breaking my mind
Do this, don't do that, can't you read the sign
and people will feel put upon and that the company is playing Big Brother. You will have heavy-handed rules that are resented and not clearly understood by all employees.
Policies are there to control the behaviour of people in the corporate setting. Think in terms of people and behaviour, not in terms of threats and risks.
Policies are to guide and control behaviour of people, not of machines and software.
Think of policies as having these kinds of objectives and you will be on a firm footing:
- Shift attitudes and change perspectives
- Demonstrate management support
- Assure consistency of controls
- Establish a basis for disciplinary action
- Avoid liability for negligence
- Establish a baseline against which to measure performance and improvement
- Coordinate activities
and of course something important to all of us toiling in InfoSec
- Establish a basis for budget and staffing to implement and enforce the policies
Policies need to be created from the point of view of management, not as a set of techie/geek rules, which the threat/risk approach would lead to.
Not least of all because, as I'm sure Donn Parker will point out, managers don't want to hear all that bad stuff about threats; they want policies that encourage staff to contribute to the profitability of the
company.
Related articles
- How to create an effective social-media policy for your company (smartblogs.com)
- 6 Tips For Great IT Security Policies (itexpertvoice.com)
- Helping Employees Get Corporate Security Policy (pcworld.com)
- Creating an Enterprise Employee Social Media Policy (itexpertvoice.com)
Make your policy generic, not specific
Some of us security types were discussion policy, login notices and the like.
Someone commetned on a badly written poicy about the use of corporate e-mail and discussion about the company.
... I recently worked at a place that had an weak and over specific email policy.
One day management realizes there are other areas where "contraband communication" can take place - internet groups, blogs, forums, IM, Blackberries, etc. If the policy hadn't been wrtten to deal specifically with "email" or been more general about the level of technology it would have saved us some hassle.
As it was, our policy development and approval process was too sllw and ciumbersome.
This is a generic issue and not limited to e-mail, IM, etc.
Long ago in a policy development workshop that I was running we thrashed out how to express ACCESS CONTROL so that it was perfectly generic, applied to
everything from the parking lot to the executive washroom, was in language everyone from the Board of Directors to the Janitor could understand. Of
course it applied to computer/network access, and its wording marched the requirement of the 'restricted access' logon notices.
I've been told the lawyers didn't like it but the reasons seemed to boil down to the fact that the language was so straight forward and unambiguous that there wouldn't be enough billable hours if it came to a court case.
If you structure your policy management properly so there is a succinct POLICY STATEMENT and ancillary sections that address
- Justification
- Consequences of Non compliance
- Roles and Responsibilities
- Who/When/Where/Why Does this Apply?
- Guidelines for Interpretation
- Relevant Standards (Internal and External)
and of course
- Procedures
then its a very effective and efficient way to work.
This is because
a) You don't need a lot policies if they are "general"
b) It makes them easy to learn and remember
c) You don't have to keep going back to the board to get picayune changes approved