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 andask people what the most common pitfalls are, using Twitter andLinkedIn 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 intomy presentation. Otherwise, hope to see you bright and early on May 7in Toronto.
Without a doubt the biggest mistake I see is the attempt toimplement an information security program without first properlydefining (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 acceptablelevel. The concept of “acceptable level” means that not only is there aproper balance of usability and security, but this concept ofacceptable level can be different for different organizations. Withoutproperly defined P&P the organization has not decided on its ownacceptable level, and is therefor assuming residual risk blindly.
2) Information security controls are being implemented withoutany concept of what they are there to support. In a best case scenariothis 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 bedefined first because technology is there to support policy andprocedure, not the other way around.
– Aaron Hughes, CISSP
Settling on security with outdated standards. Far too manymanagers are too content with settling on the minimum requirements tomeet compliance, etc., they’re often using the same re-hashed standardswritten long ago. While many provide a decent framework, many areoutdated and do not reflect the latest changes. Not to mention, onestandard won’t necessarily apply to your business.
I’ve seen it in many places, read it in many discussions. Theoverall emphasis seems to meet the minimal requirements based on highlyoutdated frameworks. Grow some cojones, create your own frameworks thatalign with your own business needs. Don’t rely on ancient data.Remember things change at such a rapid pace by the time someone isfinishing 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 companyfrowned on them sitting at their desk too much, rather than being outand 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