An interesting topic cropped up on the ISO27k Forum this week. In essence, the issue is whether a small, immature company without an I nformation S ecurity M anagement S ystem could or should have an information security policy. ​ Speaking as an infosec pro, the knee-jerk response is "Yes, of course!". Why do I say that? If SmallCo's CEO or owner asked me to explain, how would I justify my recommendation to have a policy? Hmmm. Tag along or watch from the precipice as I dive into another rabbit warren.

Whereas ISO/IEC 27001 indicates that only fourteen (14) types of ISMS documentation are strictly required  (mandatory), they are barely a start, even for a barebones ISMS.  In practice,  both mandatory and  discretionary documents are valuable . ISO/IEC 27001 c lause 4.4   states: “The organization shall establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document.” Documentation (termed 'documented information' in the standard - see clause 7.5) is generally the best way for management to inform workers about their information security responsibilities  e.g. through written policies, procedures/work instructions and job/role descriptions, accompanied by awareness and training materials such as guidelines and briefings. In addition, many security-related processes generate 'records' such as completed forms, ...

Yesterday I blogged about ISO/IEC 2382 - Information technology - vocabulary . In particular, one of the ~2,000 ISO definitions stood out enough to catch my beady eye: “ Computer-system audit : examination of the procedures used in a data processing system to evaluate their effectiveness and correctness, and to recommend improvements”. Errrr, that covers  some of the audit work I have undertaken, led/managed, been subjected to or heard about in my career* but omits rather a lot e.g. :   IT governance arrangements, strategies, information risk and security management, direction and oversight, structure, integration with other business functions, rôles and responsibilities, accountabilities, reporting lines, assurance, continuous improvement, barriers and progress; Staffing levels and competencies, recruitment and retention, succession planning, contractors and consultants; Security administration, joiners/movers/leavers, culture, awareness and training, accounts/identif...

Recovering from a ransomware incident is costlier, more complicated and much slower that people commonly assume. "Just restore the backups and you're good to go, right?". Spoiler alert: restoring networks and IT systems from backups is only a fraction of this.  Here's a reasonably complete set of ransomware recovery activities that would normally led by general business and IT managers : Wake up and smell the coffee! Deal with the unfolding crisis and a degree of confusion. Invoke the crisis management process. Settle things down. Assemble the business incident management team. Invoke the incident management process. Form the IT incident management team. Contact insurers, law enforcement and security experts for guidance.

In the past few days, I have been triggered yet again by someone fearing that ISO/IEC 27001 certification auditors may insist that various Annex A controls are applicable and must therefore be implemented for conformity. Apocryphal nightmares about auditors doing exactly that tend to stoke the fear and prolong the myth. Myth, yes, myth. I've said it before and no doubt I'll say it again: the Annex A information security controls are not formally required for conformity with the standard - none of them, not even one. If you or your auditors believe otherwise, kindly tell us which clause of the standard applies. What are the exact words leading to that conclusion? Spoiler alert: there are none. There is no such requirement. IT DOES NOT EXIST. There is , however, a conformity requirement to check through Annex A for any controls that might reduce otherwise untreated information risks, but even then there is no (repeat, no ) obligation to implement the controls as stated in A...

Truly effective deception isn't even recognised as such - it passes completely unnoticed.  There is no shortage of now-recognised examples that the deceived didn't spot at the time and maybe still haven't noticed. Here's a sample: A stick insect appears to a predator to be an inedible stick, not a tasty insect Spotted from an enemy's reconnaisance biplane, an inflatable tank or field gun may appear solid, a credible threat at least While an accomplice distracts a resident by knocking at the front door on a pretext, the cunning thief slips around the back Phishers emulate the look and feel of legitimate emails, senders and websites to dupe victims into visiting and disclosing their credentials, using spurious urgency to shortcut or bypass checks, specific timing and wording, and sheer volume to exploit the offguard vulnerables

First, two definitions: " Certification " is the process of checking something against defined criteria, and if it passes (meets the criteria), issuing a certificate of compliance or conformity or assurance or whatever. Certification gives some assurance that the certified organisation or individual meets the criteria ... provided the certification body or person is competent and trustworthy, the checks were done properly, and the certificate itself is authentic. Hmmm, quite a few caveats there ... " Accreditation " is the process of confirming that whoever is checking and issuing certificates is properly qualified, competent and trusted to issue meaningful certificates by following prescribed processes. It adds credibility, meaning and value to the certification and issued certificates ... provided the accreditation body or person is competent and trustworthy, the checks were done properly, and the a...

Someone who is actively involved in, or is managing, an activity is patently not independent of it. They may well make a conscious, rational and determined effort to be objective, dispassionately reviewing evidence etc ., but their subconscious/emotional biases/prejudices and beliefs/value-systems will inevitably influence what they do. With the best will in the world, they will struggle to challenge and assess their past decisions and activities, especially if they were "certain" or "determined" or genuinely believed they were "doing the right thing". Furthermore, it is very hard for anyone to review the things they did not do, decisions they did not make or options they did not even consider. Mostly, they remain out of sight or out of the question.

Full-on business continuity exercises can be big, intimidating, lengthy, costly (although hopefully still valuable!) and (to some extent) risky affairs for complex organisations or industry groups that really go to town on them ... but that's not the only way. Alternatives include: Solitary plan review/maintenance update - where the person responsible for a particular part of the whole plan (such as a section or department head) sits quietly in a dark corner imagining how things would play out in practice, carefully checking their part, liaising with colleagues as appropriate ( e.g . on interfaces, coordination and reporting), taking advantage of their knowledge of that part of the business and any results from previous checks, working within the constraint of agreed strategies, policies and objectives .

NIST has just released SP 1314 Risk Management Framework (RMF) Small Enterprise Quick Start Guide  as a lightweight form/introduction to the full RMF. ... and, despite having said the steps are not necessarily sequential ... It's interesting to compare and contrast the NIST RMF against the  Adaptive SME Security  approach we released just last week: 

ISO/IEC 27001 formally requires just 14 types of "documented information" of  every organisation competently certified conformant with the standard, as a minimum: 1.        ISMS scope (Clause 4.3); 2.        Information security policy (Clause 5.2); 3.        Information security risk assessment procedure (Clause 6.1.2); 4.        Statement of applicability (Clause 6.1.3 d); 5.        Information security risk treatment procedure (Clause 6.1.3); 6.        Information security objectives (Clause 6.2); 7.        Personnel records (Clause 7.2); 8.        ISMS operational information (Clause 8.1); 9.        Risk assessment reports (Clause 8.2); 10.    Risk treatment plan (Clause 8.3); 11. ...

Prompted by a thread on the ISO27k Forum, I've been contemplating the categorisation planning process I mentioned in yesterday's blog . This is just a rough diagram to illustrate the concept.  Very rough.  "Rough as" as we say down here on the Far Side.

Yesterday, someone sought guidance from the ISO27k Forum on categorising vendors by risk. Here's my coffee-fueled early-morning response, lightly edited for this blog. Risk assessment criteria In the context of an ISO 27001   I nformation S ecurity M anagement S ystem, information risk in the upstream supply chain/network, viewed from the customer organisation's business perspective, is the primary concern in relation to vendors.  Breaking that down, the kinds of factors that may affect the information risk levels include:

Once again, my day kicked off with a stimulating and fruitful debate on the ISO27k Forum as members responded to a request for help to find accredited I nformation S ecurity Management S ystem certification auditors who will add value to the organisation above and beyond the ISO/IEC 27001 conformity certificate. The original poster copped some grief from the forum in appearing to seek certification auditors who would be kind on the organisation, supporting its business objectives more strongly than its conformity with the standard ... but a follow-up message clarified the position. Aris confirmed to us that he sought:  "advice on where (in cases of an ISO audit) and how (in cases of an Internal audit) our ISMS could/should be improved, but I need that advice to be meaningful, grounded, and delivered in a way that has the best probability it will be absorbed by the business. In other words, I would like this process to offer real value to the business, besides just bein...

ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons: It is deliberately generic, being applicable to all manner of organisations regardless of difference in location/s, size, industry, maturity, structure, information risk and security status ... and so on. In effect, it specifies the lowest common denominator - the things that ALL organisations should be doing to manage their information security controls, as a minimum. The hurdle is set low enough that every organisation ought to find value in designing, implementing and operating an I nformation S ecurity M anagement S ystem as laid out in the standard. It is a certifiable standard, explicitly specifying the characteristics that every certified organisation's ISMS is expected to have. Again, it is a minimal specification with no concept of typical, average or maximum security: that is entirely down to the organisations themselves to determine, following the information risk management processes minimally de...

Since home and mobile workers rely on IT to access critical business systems and corporate data, and to communicate with others, organisations need a robust IT network infrastructure that extends to workers' homes or wherever they hang out. If, in reality, the infrastructure turns out to be fragile and unreliable, business activities are likely to be equally fragile and unreliable, leading to frustration and grief all round. In other words, the extended IT infrastructure is quite likely business-critical. W orking F rom H ome or on the road can increase various information risks relative to conventional office-based work, due to factors such as: Use of cloud computing services*; Workers using their own or shared devices and internet connections for work purposes, raising questions about their suitability and security, ownership of and access to any intellectual property or personal information on them;

A post on LinkeDin this morning led me to a news piece  about an IT professional's attempt to divert/steal his employer's payoffs for a ransomware infection, back in 2018. According to the article, his attempt ultimately failed, largely due to his inept and naive execution ... but I have not come across this particular insider threat before. It was a new one on me, a man-in-the-middle attack layered on top of the ransomware.

A warning in the New Zealand Information Security Manual  caught my beady eye yesterday: “Electrical and electronic equipment contains a complex mix of materials, components and substances, many which can be poisonous, carcinogenic or toxic in particulate or dust form. Destruction and disposal of WEEE [Waste from Electrical and Electronic Equipment] needs to be managed carefully to avoid the potential of serious health risk or environmental hazard.” Disposing of eWaste presents environmental and safety hazards arising from noxious/toxic/carcinogenic chemicals such as gallium arsenide (GaAs) and polychlorinated biphenyls (PCBs), plus the obvious dangers when handling sharp-edged metal or plastic chassis fragments, wires, printed circuit boards and CD/DVD discs plus  leaky electrolytic capacitors and old batteries . While there may be money to be made by extracting and recycling valuable metals  and reusable components ,  subsystems and modules , that's really a jo...

Over on the ISO27k Forum  this week, Ray asked us for  "guidance on conducting and documenting 'Management Reviews' that include the agenda items required by the standard in 9.3. Any templates shall be much appreciated."  Forumites duly offered advice and agendas. So far so good! However, I made the point that  ISO/IEC 27001 does not require/insist that management reviews take the form of periodic management meetings, specifically, although that is the usual approach in practice.  Personally, since they are both forms of assurance, I advise clients to plan and conduct their ISMS management reviews and ISMS internal audits similarly, with one critical and non-negotiable difference: auditors   must  be independent of the ISMS, whereas management reviews   can  be conducted by those directly involved in designing, operating or managing the ISMS. This is not merely a compliance matter or protectionist barrier: auditor independence bri...

For about a week, I've enjoyed following and participating in an expansive discussion thread on LinkeDin about the value of measurement and metrics for management , debating various issues that can occur both in theory and in practice. One straw-man argument is that 'managing by the numbers' can imply a myopic focus on commonplace business metrics such as stock price or annual profit, both of which can be manipulated to some extent by managers even at the expense of long term resilience and commercial success, let alone other business objectives. Despite Taylor's outmoded 'scientific management' experiments having been debunked a century ago, some LinkeDinners in the thread evidently still believe that science (in the form of numeric data) and management are poles apart.  I beg to differ. That's so last century! Management is complex, dynamic and nuanced, hence I accept that simplistic or crude metrics can't possibly address the entire practice. For exam...