This section of the ISO27k FAQ addresses typical questions relating to the way an ISMS matures over time:

• What Content Management System should we use?
• Should we roll our own Policy Management System or buy one?
• Which laws & regs do we need to comply with?
• How can we generate a security culture?
• What should the ISMS implementation project manager do to succeed?
• What ISMS/information security metrics should we measure?

FAQ: “What CMS should we use for our ISMS?”

A: We cannot recommend a specific Content Management System for you without knowing your specific requirements, and yes they do vary from organisation to organisation. You really ought to consider a structured specification and evaluation process such as that recommended for choosing risk analysis/management methods.

Implementation tip: start by clearly defining your functional requirements before evaluating potential CMS candidates. Be crystal clear about the business objectives for the CMS. If you don’t know what you’re looking for, how can you tell when you’ve found it? See Wikipedia’s Content Management Systems entry for pointers to the different types of CMS including document management systems and web content management systems.

Top

FAQ: “Should we roll our own Policy Management System or buy one?”

A: [This excellent advice was kindly contributed by Michael Rasmussen. Thanks Michael!]

The mismanagement of policies has grown exponentially within organisations with the proliferation of collaboration and document sharing software such as Microsoft SharePoint. These solutions to their credit as well as downfall enable anyone to post a policy. organisations end up with policies scattered on dozens of different internal websites and file shares, with no defined audit trails or accountability for them. This produces policies that are written poorly, out of sync, out of date, and with no evidence of how the policy was communicated, read and understood.

Collaboration and content software is a great tool for managing and sharing content in a general way — such as wikis, blogs, Web content and documents usually shared among a specific group. While collaboration and document-sharing software appears easy and cheap to implement, the reality is that the cost to the organisation is significant in the liability and exposure of ineffective policy management if not done properly. Many organisations have decided to take that path only to find that it is cumbersome for policy management.

There are strict compliance and legal requirements that must be instituted when managing policies — requirements that a build-your-own policy management system makes difficult to achieve and come at a significant cost to the organisation. Some organisations feel that they could accomplish at least some of the necessary features, requiring significant internal IT development effort to achieve an appropriate and effective policy management environment. The cost actually exceeds the cost of purchasing a policy and procedure management (PPM) software platform. Add ongoing maintenance and support of a build-your-own policy management system, and the costs grow higher.

Consider that an organisation will have to dedicate IT development resources to this project for several months and ongoing years. Is the organisation willing to maintain the policy portal project as the priority for that long — and will it continue to test it and support it with updates as needed? Can it continually verify an audit trail that can hold up in court and with critical regulators? Can the organisation demonstrate a strong policy management program that maintains and keeps policies current while showing who accessed them and when?

Another point of consideration is whether the organisation wants to live with a home-grown system that will most likely have a fraction of the features contained in a purchased system. Companies can spend as much as 10,000 man hours to build a policy portal on collaboration technologies — and increase that development time every year thereafter trying to enhance it and provide the features an organisation learns it needs to manage policies correctly. What are the opportunity costs an organisation is losing by focusing on this a custom approach to policy management?

Some specific features to consider when building your own policy management solution:

• The desirability of a consistent platform for the entire enterprise instead of each department implementing their own policy portal;
• The ability for the platform to manage the lifecycle of policies through creation, communication, assessment/monitoring, tracking, maintenance/revising, to archiving and record keeping;
• The ability to restrict who can read what documents and determine who has the permission to edit, review and approve;
• The training requirements needed to show that individuals understand what is required of them through linkage to learning systems/modules, quizzing and attestation;
• The accessibility of the system, with the ability to communicate policies in the language of the reader as well as provide mechanisms of policy communication for those with disabilities;
• The requirement to be able to gather and track edits and comments to policies as they are developed or revised;
• The mapping of policies to obligations (e.g. regulatory or contractual requirements), risks, controls and investigations so there is a holistic view of policies as they relate to other areas of Governance, Risk management, and Compliance;
• The ability to provide a robust system of record to track who accessed a policy as well as dates of attestation, certification, and read-and-understood acknowledgments;
• The ability to provide a user-friendly portal for all policies in the environment that has workflow, content management, and integration requirements necessary for policy management;
• The capability to provide a calendar view to see which policies are being communicated to areas of the business, so that policy communications do not burden the business with too much in any given month of the year;
• The need to provide links to hotlines for reporting policy violations;
• The ability to publish access to additional resources such as helplines and FAQs to get questions answered on policies;
• The cross-referencing and linking of related and supporting policies and procedures so the user can quickly navigate to what they need to understand;
• The ability to create categories of metadata to store within policies and to display documents by category so that policies are easily catalogued and accessed;
• The requirement to restrict access and rights to policy documents so that readers cannot edit/change them and sensitive policy documents are not accessible to those who do not need to see them;
• The necessity that the organisation keep a system of record of the versions and histories of policies to be able to refer back to when there is an incident or issue that arises from the past and the organisation must defend itself or provide evidence;
• The capacity to enforce templates and style on all policies with the ability to guide policy authors and prompt them to maintain the corporate brand as well as associate specific properties, categories, or regulatory obligations with the document;
• The need for accountable workflow so certain people can approve policy documents and then tasks can be moved to others with full audit trails on who did what to the policy;
• Deliver comprehensive reporting — consider the time it takes in a build-your-own approach, and organisation could spend months or years trying to create the depth and breadth of reports included in commercial policy and procedure management software.

Implementation tip: although you may be able to implement a few of these features using a build-your own approach, the cost in training, maintenance and management time, let alone the legal ramifications due to lack of proof of reader signoff and comprehension, makes it a risky venture for policy and procedure management.

Top

FAQ: “Which laws and regulations do we need to comply with, according to ISO/IEC 27002?”

A: [Important caveat: I Am Not A Lawyer. This is not legal advice.]

Here is a far from comprehensive or accurate list of ten kinds of laws and regulations that may or may not be applicable to your organisation, and may or may not fall under the remit of your ISMS:

1. Privacy or data protection acts if you are handling personal data (client data or employee data).
2. Computer misuse act or equivalent laws about hacking, unauthorized network access, malware etc.
3. Telecommunications laws and regulations concerning lawful/unlawful interception etc.
4. General business laws around company structure, taxation, governance (e.g. SOX), business records, HR, health & safety, building codes, fire escapes etc.
5. Other laws e.g. theft, fraud, misrepresentation, deception ...
6. Consumer laws concerning how your company represents its products, warranties, fitness for purpose, merchantability, quality (and by implication, security) etc.
7. Contract law concerning contracts with third parties (suppliers, partners, customers), liabilities, commitments etc.
8. Intellectual property protection laws including copyright, patents, trademarks and trade secrets, protecting both your own IP and that of third parties.
9. Industry-specific laws and regulations e.g. finance industry (banking laws, money laundering), PCI-DSS, government & defence industry (freedom of information, official secrets, critical infrastructure, terrorism ...), medical & healthcare industry (more privacy requirements, sometimes regulations about data formats) etc.
10. International laws, or rather the laws of foreign jurisdictions, if your company does business with (and processes information on) foreigners, uses overseas facilities or services, has an Internet presence etc.
11. ++ Others: speak to your lawyers/corporate legal counsel about this, and/or your compliance function if you have one. Aside from the more obvious laws and regs about information security, several “non-IT” laws have an impact on IT and information security in the sense that the laws concern protecting or using or abusing information, or concern business processes and individual activities which are often computerised. Therefore there can be compliance obligations affecting the way the IT systems and information processes are designed and/or used, even from “non-IT” laws.

Implementation tip: compliance with externally-imposed obligations can be an important driver to implement an ISMS, not least because the ISMS can take some of the weight off management’s shoulders. Managers generally either accept the need to comply, or can be persuaded to do so in order to avoid the personal adverse consequences (typically fines, prison time and career limitations). However, the formal rules tend to be minimalist, meaning that mere compliance is seldom sufficient to protect the organisation’s wider interests. Compliance may be important but it alone is insufficient for security.

Top

FAQ: “How can we generate a ‘culture of security’?”

A: Generating a security culture is certainly a challenge in several respects. organisational cultures are easier to experience than to describe, and hard to change (influence is probably a better term in fact). Here are five Hinson Tips:

1. Culture is heavily influenced by management, especially senior management. This is one of the key reasons that genuine senior management support is essential when implementing an ISMS ... which implies the importance of addressing senior management, helping them understand and appreciate the value of information security from the earliest opportunity.
2. Corporate culture is also heavily influenced by powerful opinion-formers within the organisation (at any level of the hierarchy), by internal communications and networks (both formal and informal), and by the wider business/industry and national cultures in which people live. These are influencable to varying degrees. An effective information security awareness program will identify and target the people, themes, messages and mechanisms across all these areas.
3. Culture is an emergent property or characteristic of the organisation, that is it is demonstrated by people's actions and belief systems in practice, when they are behaving normally and not being watched, whatever the formal mission statements or fancy posters about corporate values may state. [Security awareness posters, for example, are unlikely to be sufficient to change culture by themselves, no matter how sexy they appear.] This includes management: it is no good management telling staff “Don’t share your passwords” if they share their passwords with their PAs, for example, as this cultural dissonance is unhelpful.
4. Changing corporate culture may be viewed as a massive organisation-wide long-term change management activity. Anyone who truly understands how to do massive change management reliably can make a fortune! It is a very complex and difficult topic, with many different approaches, some of which are complementary and others are conflicting. It is also highly dependent on the specific context, plus the history leading up to the decisions to change. A serious information security incident, for example, might be the trigger to “do something” about information security which could include implementing an ISMS, but that's a different starting point than, say, having a cost-benefit justified business case for information security, or legal/regulatory compliance pressures, or pressure from within (e.g. the CISO, ISM, CEO or Risk Manager). Experience with whatever precedes the ISMS may be positive or negative, and to some extent can be used accordingly by selectively reminding people about and reinterpreting the history.
5. Culture is dynamic: it will continue to change or evolve after it has been (somehow) pushed in a certain direction, and that future evolution is not entirely controllable. This is the main reason that we promote the idea of rolling or continuous security awareness programs, since a single event will gradually be forgotten and awareness levels will decay unless constantly refreshed. Using a sequence of security topics is a good way to make sure that the materials remain interesting and engaging, along with having excellent awareness content prepare by people who understand the audiences' needs. It's also why we like using security metrics and news of security incidents, especially how they were addressed and resolved, in order to generate positive feedback and so continue driving the ISMS ever onward and upward. It requires management of perceptions.

Implementation tip: plan your approach to developing and establishing a security culture over the long term. If you expect overnight success, you will surely be disappointed but please don’t assume that it is impossible and give up before your initiative has had a chance to get going. Investing time and effort consistently into this will pay dividends in the long run - in other words, it is worth it. Tackle it in bite-sized chunks rather than all at once, aiming for incremental, solid improvements rather than dramatic but often short-lived changes. Use suitable metrics to measure your corporation’s security culture and confirm that it is moving in the right direction, adjusting your approach as you go.

Top

FAQ: “What can the ISMS implementation project manager do to ensure success?”

A: We can’t guarantee your success but here are some of the trade secrets from successful ISMS project managers:

• Become familiar with the business you serve. Get to know the department heads and the challenges they face. Try to see information risks and controls from their perspectives, and look hard for situations in which strong, reliable information security is taken for granted or presents opportunities for new business activities that would otherwise be too risky.
• Cultivate business champions for information security in key areas, for example by talking to sales people on how they win business and what would help them be more successful, asking R&D people about the importance of keeping research secrets from commercial rivals, and checking how finance department satisfies SOX and similar integrity obligations.
• Make friends with colleagues in related functions such as risk management, compliance, internal audit, site security/facilities and IT. Take time to explain to them how an ISMS will support what they do, and garner their explicit support for the implementation project. These people are often influential with senior management.
• Present ISO27k as a practical solution to the organisation’s current and future business problems rather than an academic set of controls or generic good pracices. Solutions are more palatable than controls. Focus on the business outcomes of the ISMS rather than the ISMS itself. Continue to sell the ISMS as a solution to business needs and encourage other managers involved with security to adopt a similar business-focused attitude. Seek out and exploit strategic alignments.
• Remember that if the business is to adopt ISO27k and take on board a culture change, it should both be, and be perceived as, empowering and enabling rather than restrictive and disabling.
• Tone down the technobabble and learn business-speak. Remember, IT is only part of the ISMS albeit an important one. Make a special effort to reach out to, inform and engage senior management up to board level: their understanding and support for the ISMS will facilitate the numerous changes necessary to business processes and systems as they are secured, and conversely their active or passive resistance will make your job much harder. Consider starting your management-level security awareness activities early in the ISMS implementation - even before your project is proposed and approved.
• Celebrate successes. Take every opportunity to write-up and share situations in which information security helps the organisation mitigate risks. Case studies and direct quotations from managers or staff who appreciate the value of the ISMS all help to spread the word: security is as much about saying “Yes!” as “No!”

Got other tips? Please contact us directly or by all means share your good ideas with the ISO27k Forum.

Implementation tip: learn and adopt worthwhile approaches from other initiatives, both internal and external to your organisation and whether entirely successful or not (it’s better to learn from other people’s mistakes than to make your own, given the chance!). Many experienced project managers keep little black books of things that worked for them or others, things to avoid, and ideas to try out when the opportunity arises. Seek out and adopt good ideas from all quarters.

Top

FAQ: “Our organisation is planning to implement metrics to measure the effectiveness of both information security and management controls. What is the starting point and process? What metrics should we use?”

A: It's tough to give simple advice on metrics: it is arguably the hardest part of what we do. But here goes.

It is unrealistic to expect a standard set of security metrics, in just the same way that there is no universal set of security controls: there are simply too many variables. In time, a core set of common controls and metrics may emerge from the mire but there will probably never be total consensus. Even if there was a standard set, you would still have to extend it to suit your unique situation anyway. In short, there is no way around figuring out the information risks, controls and metrics that matter to your particular organisation.

Metrics-related references that you should check out include:

• ISO/IEC 27004 - the current version is well-written and useful, a big improvement over the initial release;
• PRAGMATIC Information Security Metrics by Krag Brotby and Gary Hinson - an eminently practical guide for security practitioners;
• IT Security Metrics by Lance Hayden - IT-specific, eloquently explains the Goal-Question-Metric approach;
• You are what you measure by Hauser and Katz - warns about driving the organisation the wrong way as a result of an inappropriate choice of metrics (Google “surrogation” for more on this);
• SP800-55 Performance Measurement Guide for Information Security by NIST - focused on measuring FISMA compliance but the principles are broadly applicable. It is well-written and FREE!

As you read through that lot, start thinking hard about what you and your management might really want to know about how you are doing on information security, and start defining and prioritizing the collective requirements. This is the crux of your problem. Management probably wants to know things like “Are we secure enough?” and “Are we more secure today than we were this time last month?” and “What are the most significant information risks we are facing?” and “Why is information security so expensive?”! These are really tough questions to answer, so work hard to refine them and make them at least partly answerable.

Hint: look at those parts of the ISMS which caused you the most grief when designing and implementing it. Are there parts of the ISMS that are self-evidently painful to operate? If so, these are classic ISMS process improvement opportunities, and hopefully good places to gather metrics that will help you justify, plan and make those improvements, with the spin-off benefit that you will be making things easier for those involved.

It may seem too early but it's almost certainly worth talking to your management about what they might expect during this metrics design phase. Look at what kinds of metrics they get from other management systems. Find out what they actually use versus what they get, and look for clues about what kinds of things work best in your organisation. Consider phoning your peers at other similar organisations for some good ideas. Find out what formats and styles of reporting they like best or hate most. Ask them what few reports they could really not do without. Think minimalist at the start.

Next, start looking at the realities of gathering information on those things you really want to know, and continue refining your requirements. Some metrics will be straightforward (great! These are probably keepers), some will be feasible but more difficult (bear these in mind - may need more work) and some will be so awkward and/or costly that the effort required to measure them will outweigh any benefit obtained (park these, at least for now: you may revisit them later as your ISMS matures).

Be careful with any existing infosec metrics: some of them may be being measured simply because they are easy to measure, such as simple counts of things (“23 malware incidents this month”, “23 million spams blocked today” or whatever). Unfortunately, such simple metrics typically don't tell management, especially senior management, anything really worthwhile. While a few may have value to the Information Security Manager as operational metrics, most are at best ‘nice to have’ numbers rather than “Oh boy, this one is in the red, we’d better turn dial ZZY to the left 20 degrees”!

Most of all, avoid the temptation to list and discuss all the information security-related things you can measure, like a giant shopping list. Some of them may be worthwhile ingredients, but most will be distracting and unhelpful. Trust me, this is not an effective way to start designing your ISMS metrics. If you must have one, keep the shopping list to yourself but share the menu.

Finally, towards the end of your lunchtime (!), it's time to start experimenting, trialling a few metrics, getting the data gathering, analysis and presentation processes working and getting feedback from management. Give them some ‘sample’ reports and ask them if they know what to do about the things you are reporting. This is where all your pre-work starts to pay off, hopefully. If you have chosen well, you should by now be ready to routinely report a few good metrics, and more than that use management should be using them to make decisions. Management should be saying “Ah, I see, yes, nice, let's have more of these ...” and “Mmm, that's not quite what I had in mind. I really need to know about ...”.

During this stage, you will inevitably find that you need to gather more detailed ‘supporting’ metrics to underpin the high level/strategic management stuff, and you will also figure out that there are various routine/operational issues and controls within the ISMS that deserve measuring and using for day-to-day purposes by the Information Security Manager and team.

Now is the time to work on defining targets. At what level, exactly, does metric 26 go ‘into the red’? At which point on the scale can we relax?

Then, over the next several decades (!!), keep on refining your metrics, testing new ones, dropping the ones that aren't working and responding to changes in your ISMS, the risks and controls, the people, the fashions, the good ideas you pick up at conferences ... and extending the answer to this FAQ with your expertise!

Implementation tip: see SecurityMetametrics.com for an FAQ on security metrics and security maturity metrics designed to support ISO/IEC 27002. Selecting security metrics that are appropriate for your organisation starts by figuring out things such as who are the audiences for the metrics, and what do they expect to achieve with the information. If metrics are to provide management with the Answers, what are their Questions? Why are those Questions relevant - what business objectives or Goals are at stake? Work with management to figure that out and, believe me, the rest is a breeze. The Goal-Question-Metric method eloquently described by Lance Hayden in IT Security Metrics is an excellent, proven approach.

Top

< Previous FAQ section   FAQ index   Next FAQ section >