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.

There are information risks associated with people joining any corporate function – information risks that deserve to be identified, assessed, evaluated and treated appropriately like any other. If your organisation currently pays little if any attention to these risks, how about developing and trialling a suitable strategy and approach for, say, the information risk and security management function, as a pilot or demonstrator for other corporate functions and rôles that place a high reliance on the personal integrity of their people?

Individuals chosen by senior management to audit Information Security Management Systems are not necessarily well-trained, highly qualified, experienced and (to be frank) competent professionals. ISO/IEC 27001 certification auditors from accredited certification bodies definitely should be, but for various reasons, some of them are, let's say, winging it. Reports indicate that some simply do not understand or accept that Annex A is a set of DISCRETIONARY controls, for example. As to ISMS internal audits, well Internal Audit Departments are commonly only found in large, mature, heavily-regulated organisations: most either contract out their internal audits, pick whoever failed to duck at the right moment, or simply forgo the pleasure - and value - of independent examination and evaluation. This week, I've developed a succinct guideline for ISMS auditors , laying out for each of the main body clauses of the standard: (a) The types or items of evidence worth hunting down: the ...

This morning, Greg asked us on the ISO27k Forum for advice on ISO/IEC 27001:2022 security control A.5.7 Threat Intelligence. "I've read the details in ISO 27002 and understand it in theory. But what does a threat intelligence program consist of and look like when implemented? What tools would a infosec team use to collect threat intel, how would they analyze it and use it, etc? What have you seen in your own environments or those of clients?" FWIW here's my response: I agree with you Greg: the page of advice on threat intel in '27002 is all well and good, but what does this look like in practice? It's not entirely obvious. At a basic level, it starts with 'situational awareness' - someone simply watching out for potential or actual threats in the organisation's external and internal environments, spotting them, tracking them, thinking about and maybe responding to them. Threats become evident when incidents occur, of course, but also events and ne...

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, ...

Abandonware - left to rot in a cul-de-sac off the information superhighway Adware - pushes products like a street dealer Alienware - arrived from another universe Aware - clues provided, boxes ticked, back to normal, things to do  Badware - should be sent to the naughty step Betaware - beta hope it works Blackware - interleaved with whiteware, forms a zebra crossing Bloatware - so fat it has its own postcode Bundleware - less bundle of joy, more bundle of old rags Cloudware - play misty for me Copware - press the wrong button and get hit with 50,000 volts Crapware - press the wrong button and evacuate your bowel Creepware - started lower-left, imperceptably heading upper-right Crimeware - reveals the secret password character-by-character on TV Crippleware - almost does what you want, but not quite Crudware - the oh so polite version of crapware Donationware - like being mugged by the tin-shakers Dribbleware - something to keep old aunt Doris amused before bingo  Everyware...

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...