On Thursday I’ll be hosting a ComputerWorld Canada Technology Insights event that’s focusing on risk management and compliance challenges, along with Adobe Systems and a couple of CIOs.
To get prepared, I decided to tap into the wisdom of the crowd and
ask people what the most common pitfalls are, using Twitter and
LinkedIn primarily. Below are some of my favourite responses so far.
Feel free to add your own and if it looks good I’ll incorporate it into
my presentation. Otherwise, hope to see you bright and early on May 7
in Toronto.
Without a doubt the biggest mistake I see is the attempt to
implement an information security program without first properly
defining (and communicating!) proper policy and procedure.
Failure to define P&P causes a couple of situations:
1) Proper information security is mitigating risk to an acceptable
level. The concept of “acceptable level” means that not only is there a
proper balance of usability and security, but this concept of
acceptable level can be different for different organizations. Without
properly defined P&P the organization has not decided on its own
acceptable level, and is therefor assuming residual risk blindly.
2) Information security controls are being implemented without
any concept of what they are there to support. In a best case scenario
this causes wasted resources (money, manpower, business process, etc.)
in a worst case scenario this may actually open up attack vectors.
I guess the lesson here is that policy and procedure needs to be
defined first because technology is there to support policy and
procedure, not the other way around.
– Aaron Hughes, CISSP
Settling on security with outdated standards. Far too many
managers are too content with settling on the minimum requirements to
meet compliance, etc., they’re often using the same re-hashed standards
written long ago. While many provide a decent framework, many are
outdated and do not reflect the latest changes. Not to mention, one
standard won’t necessarily apply to your business.
I’ve seen it in many places, read it in many discussions. The
overall emphasis seems to meet the minimal requirements based on highly
outdated frameworks. Grow some cojones, create your own frameworks that
align with your own business needs. Don’t rely on ancient data.
Remember things change at such a rapid pace by the time someone is
finishing figuring out NIST 800.xx, it’s almost 5 years too late.
–J Oquendo
My gut feeling from working a variety of sites, is that a top down plan, by itself, is fairly meaningless except as a box-tick.
I recall some Toyota QA engineers who told me that the company
frowned on them sitting at their desk too much, rather than being out
and about on the floor.
On that note - I’d suggest that people go out, “kick-the-tyres” and communicate.
If nothing else, it’ll help that top down report (prepared later I hope) to get accepted.
–Richard Gowan
