Over the past six months I've been looking at the security
requirements of small and medium enterprises. I've had some fascinating
conversations with numerous security experts, many of whom have varying
theories on how the problem should been tackled.
Some believe that the answer lies in adapting the security
standards used by bigger companies. The standards community seems to be keen on
this approach. They think the answer might be to rewrite existing standards in
simpler English. That would be an improvement. But it won't solve the problem.
Even cut down versions of the ISO 27000 standards are inappropriate, containing
too many irrelevant requirements for small and micro companies, who don't have
policy portfolios, committees and internal audit functions.
Other practitioners view SMEs as an immature version of a
bigger company. They think the answer lies in some form of maturity framework.
The problem with this idea is that not all SMEs aspire to grow into a big
company. Many are quite content earning a living as a small, profitable enterprise.
Pointing out the benefits of achieving a higher level of maturity won't cut any
Most security managers in big companies have concluded that,
left to their own devices, SMEs are a hopeless cause. They must therefore be
compelled by the threat of losing business or being sued for a breach of
contract. These security managers regard SMEs as a major security liability, rather
than a useful, cost-saving business opportunity. That's a serious drag on business,
which needs to exploit the benefits of smarter, cheaper niche services in order
to stay competitive.
Whatever your view, one thing is crystal clear to me, which is
that our traditional approaches to selecting countermeasures are flawed. If
they only work for large organisations, then they are not fit for purpose for
any organisation. Large enterprises themselves are formed of numerous small
business units and functions. If security solutions don't work for small units,
they're not effective for big enterprises.
It's instructive to take a step back and examine how we go
about determining security controls, and why we do it that way. In the early
days of information security, controls were implemented only by a small set of
enthusiastic computer managers with direct experience of specific risks. They
relied on a careful eye and a large degree of imagination. The problem with
such a free form approach, however, was that it produced inconsistent results. The
next generation of security managers aspired to identify risk assessment
methods that might enable an inexperienced practitioner to select an optimal
set of countermeasures. Unfortunately, this approach was also flawed because we
simply don't have the psychic ability to predict risks, which have an annoying
habit of constantly changing.
One answer to this dilemma was to agree a common set of
baseline controls based on established best practice, which prompted a wave of
international standards designed by large organisations to address an internal
controls requirement. Unfortunately these standards were not designed with
sufficient attention to the needs of SMEs or the massive growth in external services.
They also fail to address emerging risks.
In practice, security countermeasures are only implemented
if there is a clear and present danger (as demonstrated by a major incident), a
mandatory requirement (legal or compliance) or if it forms part of a wider system
specification. Talk of security as a business enabler is fine for impressing
the board but the reality is that such claims rarely translate into a concrete,
long term business case.
SMEs, contractors and small business units aim to spend the
minimum possible amount on security. It is a grudge purpose. That means that we
need to emphasise the highest priorities and communicate the most compelling
business drivers, not swamp them with hundreds of good practices to choose
We therefore need to go back to square one and design a more
suitable portfolio of solutions, for a broader set of organisations and
circumstances. Over the last three decades, the security problem space has
grown progressively richer, dynamic and complex, while the recommended solution
space has largely stood still. It's time for a rethink of the fundamentals of