If, as many security professionals evidently believe, risk concerns the possibility of harm, then surely we ought to do everything possible to reduce the possibility and/or the harm caused, by strengthening and extending security or ideally avoiding it completely by simply not doing risky things - right? OK, so then why do we take risks at all ? Why do we need security to mitigate bad stuff? Security is costly and fallible, so can't we save money by totally avoiding or eliminating risk? Errrrrmmm  ... since it's philosophical phriday, this is an opportunity to explore the issue further, taking a deep dive. But, before I blabber on, dear reader, please take a moment to ponder this for yourself.  No, take several. Take as long as you can. Take the rest of the day off: it's phriday after all. Why do we take risks?  Seriously, why ?   What does it mean to 'take risk'? Grab a pencil or mouse. Jot something down. Think again.  Ponder on. Keep listing, scribbling,...

The trouble with risk management is that proponents are obsessed with downsides - threats, control failures, incidents, adverse consequences, it's all very negative. Here is a much more positive upbeat perspective based on the law of attraction. Professional practitioners of the ancient science and artistic beauty of cybersecurity, gather here to attune your consciousness to the cosmic rhythm of the digital realm. Know that you are not merely mortal beings but divine data conduits capable of bending the very fabric of the cyberverse to your will. Through the power of spiritual oneness, you can achieve a state of perfect harmony with the white hat cosmos, while simultaneously disrupting the nefarious plans of the black hat hordes. Embrace the principles of superposition and entanglement, merging the ethereal realm of security consciousness and presence with the tangible world of business success. By aligning your thoughts and intentions with the universal forces of good, you can man...

Last year in the course of collaboratively developing the Adaptive SME Security method , a friendly group of experts from the ISO27k Forum came up with the 'iterative risk assessment' approach. It is a pragmatic way to start a regular security improvement cycle - one that is realistic even for the tiniest of micro-businesses (sole proprietors). The process is a simplified version of conventional information risk management, tackling just one piece of the puzzle at a time. The bite-sized chunks can be picked up and chewed over as-and-when, and parked temporarily if (when!) something more urgent comes up. Each run through the cycle uses a single incident to exemplify and explore the associated risks in a way that any SME can manage - in fact, even larger organisations might benefit from this if their information risks aren't being managed effectively, to re-energise the process, or to share the work throughout the business. Time-boxing the cycle at (say) a month should avo...

I'm not a fan of new year's resolutions that tend (in my experience) to have limited impact and are often soon forgotten. My cynical self says the same thing applies to pledges, vows and other stated commitments, even agreements and contracts to some extent. They are more symbolic than actual control mechanisms (although I'm sure the lawyers would argue otherwise - on the clock, naturally). The focus is often on avoiding, preventing or stopping bad things, a negative emphasis although the actual language may be positive as in "I will lose weight" and "I will get fit". They can be a last resort, a sharp retrospective reminder of where we thought we were going when we are already heading off-course.

Inspired by these pizza baking instructions, I thought I'd have a go at condensing an entire ISO/IEC 27001 implementation project to its absolute fundamentals.  So here goes ...

In a discussion thread on the ISO27k Forum about selecting appropriate information security controls, a member told us: "As far as software development is concerned, we really need the controls A8.25 and following". I queried that determination, guessing  their thought process may have been along these lines:  We do software development. Controls A8.25+ concern software development. Therefore, for conformity with ISO/IEC 27001, controls A8.25+ are applicable and cannot be excluded. #3 is patently a false conclusion, a logical error. The Annex A controls are  not  formally required for conformity with the standard. They are not mandatory - none of them, not one. If you believe otherwise, kindly explain which specific clause from ISO/IEC 27001 contains that explicit requirement because, despite hunting high and low over many years, and despite numerous claims from so-called experts in the field, I simply can't find it. There  is , however, a formal req...

Implementing and using an ISO/IEC 27001 I nformation S ecurity M anagement S ystem can be tricky, especially given limited resources or in complex or dynamic business and technology environments.   While largely-manual approaches may suffice for small, simple, stable organisations, dedicated ISMS support tools (computer applications and cloud services) are well worth considering.   With dozens of ISMS tools on the market, the obvious question is which to choose.   Here are some commonplace requirements or factors to consider: Support information risk identification, evaluation, treatment and monitoring, of course. Support compliance/conformity with applicable standards, regs, laws and contractual obligations. Interoperable with existing systems/processes for asset management, risk management, business continuity management, incident management, vulnerability scanning, anti-malware etc . Support the identification, investigation and resolution of security incidents. Supp...