Last week's release of a completely restructured ISO/IEC 27002:2022 has naturally prompted a rash of questions from anxious ISO27k users around the world about the implications for ISO/IEC 27001:2013, particularly around certification since '27002:2022 no longer aligns with '27001:2013 Annex A. The situation, today, is that ISO/IEC 27001:2013, plus the associated accreditation and certification processes, remain exactly as they were: Organisations that choose to adopt the standard are required to use Annex A of '27001:2013 to check that they have not accidentally neglected any relevant/necessary information security controls, documenting the associated justified decisions to include/exclude the controls in a S tatement o f A pplicability. Accredited certification bodies are required to confirm that clients comply with the mandatory obligations in '27001:2013, including that SoA requirement among others, both during the initial certifications and any subsequent inter...

The newly-published third edition of ISO/IEC 27002 is a welcome update to the primary ISO27k controls catalogue (officially, a 'reference set of generic information security controls').  Aside from restructuring and generally updating the controls from the 2013 second edition, the committee (finally!) seized the opportunity to beef-up the coverage of information security for cloud computing with new control 5.23, plus ten other new controls, mostly in section 8 (technological controls):   Configuration management (8.9) - concerns the need to manage security and other configuration details for [IT] hardware, software, [information] services and networks. Data leakage prevention (8.12) - DLP is required to protect sensitive information against unauthorized disclosure/extraction (theft, surveillance). Data masking (8.11) - in line with the organisation’s access control policy, plus other business requirements and compliance obligations, scurity controls are apropriate to mitig...

I mentioned recently here on the blog that there can be strategic elements to policies, just as there are operational aspects to the supporting procedures and guidelines. With the new year fast approaching, I'd like to explore that further today. Warning : your blinkers are coming off. Prepare for the glare. Take for instance the corporate responses to COVID-19. Out of necessity, organisations in lockdown shifted rapidly from on-site office work and in-person meetings to home-working, using video conferencing, email and collaborative approaches. Although that may have been a purely reactive, un-pre-planned response to the global crisis that erupted (despite prior pandemics and warnings arising from increasing international travel) , it was facilitated by longer-term planned, strategic changes and investments in a resilient workforce with flexible working practices and positive attitudes, strong relationships within and without the organisation, plus appropriate tools and technolog...

Congratulations on completing this cook's tour of the topic-specific information security policies in ISO/IEC 27002:2022 (forthcoming). Today we reach the end of the track, reflecting back on our journey and gazing forward to the next objective. Through the blog, we have stepped through the eleven topic-specific policy examples called out in clause 5.1, discussing various policy-related matters along the way:  0.   Introduction : an initial overview of the classical 'policy pyramid'.  1.   Access control : 'policy axioms' are key principles underpinning policies.  2.   Physical and environmental security : ignore these aspects at your peril! 3.   Asset management : using templates/models to develop your policies. 4.    Information transfer : consider the business context for policies.  5.   Networking security : risks associated with data and social networks. 6.   Information security incident management : unique or gener...

The final topic-specific policy example from ISO/IEC 27002:2022 is another potential nightmare for the naïve and inexperienced policy author.    Policy scoping Despite the context and presumed intent, the title of the standard's policy example ("secure development") doesn't explicitly refer to software or IT. Lots of things get developed - new products for instance, business relationships, people, corporate structures and so on. Yes, even security policies get developed! Most if not all developments involve information (requirements/objectives, specifications, plans, status/progress reports  etc .) and hence information risks ... so the policy  could  cover those aspects, ballooning in scope from what was presumably intended when the standard was drafted. Even if the scope of the policy is constrained to the IT context, the information security controls potentially required in, say, software development are many and varied, just as the development and associat...

With respect to whoever crafted the wording of the 10th topic-specific example policy for ISO/IEC 27002:2022 , "management of technical vulnerabilities" is the kind of phrase that speaks volumes to [some, switched-on, security-aware] IT pro's ... and leaves ord'nry folk perplexed, befuddled and nonplussed. In this case, that may be appropriate if it aligns with the intended audience for the policy, perhaps not if the policy needs to be read, understood and complied with by, say, workers in general, for whom "Patching" is arguably a more apt and widely-known term. So, d o you need to tell workers to keep their IT systems, smartphones and IoT things up to date with security patches? If so, before launching into the policy development process, think very carefully about the title, content and style of your policy - plus the associated procedures, guidelines, awareness and training materials, help-desk scripts or whatever you decide is necessary to achieve your ...

I'll admit up-front that I have very mixed feelings about the utility and value of classification as a form of control, at least in the civilian/commercial world outside of the government and defence realm anyway. On the one hand, it is (or rather it  should be, thanks to the policies, procedures, guidelines, training and awareness materials and activities) reasonably obvious how to handle correctly classified and labelled hardcopy documents. Computer data - not so much, unless you are using mil-spec classified systems and networks with all manner of mandatory hard-coded built-in bullet-proof controls.  Do your corporate information security controls include automatic rifles and attitude? Are you at the very top of your game? On the other hand, even in mil/govt circles, classification and labelling can be tricky and consistency is always an issue. E ach level or category of classification covers a range, a spectrum of information risks. Individual items of information falling ...