This week, I am preparing a new template for the SecAware policy suite covering the information risks and security, privacy, compliance, assurance and governance arrangements for A rtificial I ntelligence or  M achine L earning systems. With so much ground to cover on this complex, disruptive and rapidly-evolving technology, it is quite a challenge to figure out the key policy matters and express them succinctly in a generic form. Just for kicks, I set out by asking GPT-4 to draft a policy but, to be frank, it was more hindrance than help. The draft was quite narrowly focused, entirely neglecting several relevant aspects that I feel are important - the information risks arising from the use of commercial AI/ML services by workers, for instance, as opposed to AI/ML systems developed in-house. The controls it espoused were quite vague and limited in scope, but that's not uncommon in policies. It noted the need for accountability, for instance, but didn't clarify the reasons nor...

Choosing/designing, using and improving metrics can be modeled as a rational process: A. The starting point is to determine or clarify the ultimate/strategic goals for the area being measured (e.g. information risk and security management), plus any interim/tactical objectives , preferably in business terms. These may already be documented in the form of, for example, the rationale in a business case proposing an ISO/IEC 27001-style  I nformation S ecurity M anagement S ystem, the mission statement for the Information Risk and Security department/function, and/or the organisation’s information risk management strategies. B. The information risk and security goals and objectives will often beg questions or imply success/fail criteria. For example, the objective “To comply with applicable legal, regulatory and contractual obligations concerning information security and privacy” begs questions about the nature and number of those obligations, the compliance status, the costs...

This final episode in the series about specifying and selecting ISMS support tools/systems concerns the general usability requirements typical of almost any computer system, such as: Intuitive, easy to use; Interoperable; Facilitates customisation where appropriate; Readily maintained; Well supported, documented  etc .;

So far, I've waffled on about the variety of ISMS support tool types on the market , and about gross differences between ISMS user organisations in terms of industry, size etc . Next, think about the kinds of things they might expect their ISMS support tools to do. Digging beneath the superficial "support our ISO/IEC 27001 ISMS", organizations may well expect/require the tools to help them with security controls such as: Access rights and permissions; Alerts or alarms; Anti-spam; Antivirus; Assorted security processes; Backups;

Previously I blogged about the bewildering variety of tools, systems and services supporting ISO/IEC 27001 Information Security Management Systems . The tools, in turn, are being used in various ways for various purposes by a bewildering range of organisations. The ISMS specified by ISO/IEC 27001 is "intended to be applicable to all organizations, regardless of type, size or nature", a deliberately broad scope that takes in: Conventional commercial companies, government agencies and departments, charities and not-for-profits, conglomerates, kieretsu and groups, schools, colleges and universities ...;  Organisations of all sizes, micro-to-macro;

From time to time, members of the ISO27k Forum seek opinions about systems on which to run their ISO/IEC 27001 I nformation S ecurity M anagement S ystems, anticipating feedback or recommendations for certain products. Unfortunately, it's not quite that simple! For starters, the ISMS support systems come in several flavours. Our toolboxes are bulging ... Supposedly comprehensive ISMS systems These claim to support every conceivable aspect of information risk and security management, incident management, business continuity, compliance, governance, assurance and more. Whether that reflects a comprehensive architecture and design from the ground up, or a more limited core system on to which various adornments have been tacked over the years (sometimes including functional units from totally different systems and suppliers), is not necessarily obvious until users explore the limits and perhaps fall between the cracks. More focused ISMS systems

This morning,  a new member of the ISO27k Forum asked us some questions about his organisation's upcoming ISO/IEC 27001 certification audit (paraphrased below).  Since these are commonplace issues, I address them here on SecAware blog for the benefit of others in the same situation now ... or at earlier stages.  Management being ready for the certification audit has implications for the way an ISO/IEC 27001 I nformation S ecurity M anagement S ystem was originally initiated/conceived, scoped, planned and approved, as well as how it is managed once it comes into operation. 1. Does the auditor need to talk to the CEO or would another member of Top Management such as the COO or a VP be sufficient? That is for the auditor to decide. CEOs are invariably busy people ... but the CEO's non-involvement (even before being asked!) hints  at a lack of support or engagement from senior management*. If other senior managers are more willing and able to be interviewed, that ...