I believe that organizational security is to the post-9/11 world what ISO 9000 was to the 90s. Applying the Pareto principle, in the 20% of cases where it is implemented correctly, it will streamline operations, reduce costs and provide better physical & data security. In 80% of organizations, new security practices will be implemented for bad reasons and will make the organization more bloated, bureaucratic and less secure as a result.
If you have heard anything like the following statements with regard to a security initiative in your organization, then it is quite likely that you are going to be in the 80% that is doing this for the wrong reasons and will end up with the wrong results.
- “Everyone else is doing it, so we should do it.”
- “Our most important customer requires us to do it. Just get a consultant to come up with something, will you?”
- “We've got to implement all this new security for privacy legislation, let's just do it for everything.”
- “Our COO/CIO got sold this security methodology by a consultancy. Now she's hired them to just whack it in without consulting anybody else.”
- “We don't have time to do requirements for our security initiative, just get in the best name in the business.”
- “Our website/system/database got hacked. Fix these holes and do it quick.”
- “We're small but experiencing rapid growth – we'll need a robust security methodology like ISO 27002 to see us through.”
- “We need to protect every piece of information in the business – I don't care about the cost.”
1 - Follow the leader
Always a bad reason to implement anything, yet this is one of the most common reasons that any IT project gets up in an organization. Often driven by fear of what the competition's doing and hype from vendors and commentators, the herd mentality is rife in enterprise IT.The answer is to always assess your organization's requirements in light of current and future business practices. What benefits does the service or product deliver? Will it save time or money? Will it fit right into your business, or will you have to implement a program of ancillary services in order to get it to work? If you can't get concrete answers to these questions and the best reason you can come up with to implement a product or service is that “everyone else is doing it”, then you shouldn't do it.
2 - External requirement to implement
When a customer or a key stakeholder requires us to implement new policies and procedures, we usually resent them, often because we don't understand the need for them. While externally generated requirements can be a good push to action, a golden rule is “never implement anything unless the need is real, well understood and will benefit the organization”.3 - Getting sold
This is not always a bad thing. Consultants, IT vendors and standards organizations are the generators of new ideas for managing IT and often their products and services are capable of delivering the promises they make. However, buying the first service that comes along without investigating your organization's unique requirements and comparing other services and products in the market will almost always end in implementation of a “white elephant” system.4 - Reactive response
The nature of managing IT systems means that your department is often under-staffed, overworked and just managing to cope with day-to-day business. There is usually little time or availability for big projects with no immediate return. Therefore, unfortunately, most security is implemented in a haphazard, reactive manner with no over-arching strategy or co-ordination. In the long-term this results in fragmented, often duplicated security measures that are not well documented or understood by your staff.The answer is to make the time and people available to implement security at the appropriate level for your organization's IT structure. Having a chief security officer (CSO) with a documented job specification and KPIs should be the first step. Ensuring that they have the authority to enforce their policies is the next. This doesn't mean I'm advocating a purely centralized IT structure. It just means that you need co-ordinated planning and documentation of security practices.
5 - Over-emphasised risk
If your systems were to be hacked and, for example, your HR policies were changed or stolen, does it really matter? Really? While it may be annoying, the cost of fixing the policy pages on your Intranet would pale in comparison to implementing best-practice security to ensure the likelihood of this happening was incredibly small. Is the extra cost worth it? Judging by the number of organizations that have secured their entire private network with the most robust security, the answer would seem to be yes. However, I question whether this approach is really providing value-for-money for your organization.To me a better solution would be to perform a comprehensive review of your data and classify it into several categories of required secrecy and therefore required security. You should then aggregate the content by classification into different areas of your network with different security. Yes, this is harder than just telling someone to “just secure everything”, but this kind of analysis and planning has the capability of saving buckets of money, that could be better put to use in providing better functionality for your internal users and external stakeholders.
Additionally, you need to ensure that the security measures you implement are the right fit for your business. Gaining ASIO T4 or ISO 27002 certification may look good on your product brochures, but unless you are a defence contractor or dealing with high-level government secrets, is the huge cost actually worth it? In most cases, even in financial institutions, the answer will be no. A better way is to look at the ISO certification and implement the pieces that fit your business. Unless your customers require actual certification, the external auditing process is usually a waste of money.
Posts
