What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2022-03-01 20:18:41 | Infomation security control attributes (lien direct) |  Today I completed and published a 20-page white paper about 'control attributes', inspired by those used in ISO/IEC 27002:2022The concept behind the paper has been quietly brewing for a couple of months or more, taking the past few weeks to crystallise into words in a form that I'm happy to share publicly.In a nutshell, 'attributes' are characteristics or features that can be used to categorise, sort or rank information security controls by various criteria. That simplistic concept turns out to unlock some powerful possibilities, described pragmatically in the paper. It's a more innovative and valuable technique than it may appear.Along the way, I regret inadvertently upsetting the team of JTC 1/SC 27 editors working on ISO/IEC 27028 by sharing an incomplete draft with them in the hope it might become the basis of the initial draft of the new standard. During a Zoom meeting. At 3:00am, NZ time. I wasn't at my best. Ooops.Anyway, now the paper is 'finished' and published, I'm hoping to prompt debate and insightful comments, gathering useful feedback and especially improvement suggestions from readers, leading in turn to a better document to submit (through the proper process, this time!) to the SC 27 project team. We may unfortunately have missed our opportunity to deliver a complete 'donor document' to use as the first working draft of the new standard but all is not lost. The paper's suggestions on how to use attributes will, I hope, make a substantial contribution to the second working draft, and in time inform the issued standard. It is published under a Creative Commons licence. Exposure, discussion and insightful comment is what I'm after so, in addition to this blog, I have notified the 4,500 members of the ISO27k Forum about the paper and released it to an unknown number of LinkeDinners.Care to join the gang? Download the paper here.Share and discuss it with your peers and colleagues.Rip it to shred |
Guideline | ||
|
2022-02-25 12:38:34 | Transition arrangements for ISO/IEC 27001 (lien direct) | 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 on the certification aspects 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 chose 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 Statement of Applicability.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 interim audits and re-certifications.In other words, it's business as usual ... but looking forward, there are of course changes afoot.A formal amendment to ISO/IEC 27001:2013 is currently being prepared:A draft of the amendment is already available through ISO if you can't wait for it to be finalised and released - which I understand is expected to happen in the next few months, possibly as late as August 2022 but hopefully sooner. The draft amendment essentially replaces Annex A with an equivalent that references and summarises the controls from ISO/IEC 27002:2022. It is likely to retain the succinct tabular format of the original Annex A, i.e. it will reference each control by its '27002:2022 clause number prefixed with "A." (for Annex A), then state the control's title, followed by a single sentence outlining the control. As before, it will not elaborate on that outline: readers should consult '27002 for the supporting explanation and implementation advice - typically half a page of detail per control - and/or look to other sources of guidance, of which there are many.There may also be minor wording changes in the main body clause about the SoA, specifically in the notes for clause 6.1.3. More specifically: |
|||
|
2022-02-21 20:23:11 | ISO/IEC 27002 update (lien direct) | 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 ones, 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.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 mitigate the risk of disclosing sensitive personal and proprietary information. ICT readiness for business continuity (5.30) - organisations need to prepare themselves to handle serious incidents affecting/involving critical ICT e.g. through disaster recovery.Physical security monitoring (7.4) - intruder alarms, CCTV, guards etc. for business premises [such a basic control, it's very hard to believe it wasn't in the second edition ...].Information deletion (8.10) - at face value, another 'obvious' control: data should of course be deleted when no longer required to prevent unnecessary disclosure and for compliance reasons. The fine details, however, do matter in practice.Monitoring activities (8.16) - 'anomalies' on IT networks, systems and apps should be detected and responded to, to mitigate the associated risks.Secure coding (8.28) - software should be [designed and] coded securely, reducing the number and severity of exploitable vulnerabilities arising from [design flaws and] bugs. This control almost - but not quite - nailed the widely respected principle of 'secure by design'.Threat intelligence (5.7) - gathering relevant, actionable intelligence about threats to the organization's information, feeding it into the information risk management process. Web filtering (8.23) - limiting our access to inappropriate, unsavoury or plain risky websites is, apparently, an important security control.We've been busy updating the SecAware ISMS templates such as the detailed security controls maturity metric/checklist: | |||
|
2021-11-27 09:26:57 | Weaving strategies with policies (lien direct) | 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 technologies - in particular the cloud (since about 2000) and, of course, IT (since about 1970). Thinking about it, the very concept of 'office work', or indeed 'work', stretches back still further, along with 'business', 'commerce', 'profit' and 'money'. Gradual shifts in human society on an almost evolutionary scale have led to where we are right now ... and will continue going forward, presenting strategic challenges and opportunities to those who are awake to the possibilities ahead (both positive and negative), sufficiently resilient to cope with adversity yet resourceful, strong enough and well-positioned to surge forward when it makes sense. In some organisations, policies and practices for home/virtual working were hastily developed and adopted during and in response to the COVID outbreak. In others, either the policies and practices were already in place, or there was no specific need for them since flexible, tech-enabled working was very much the norm already. A few laggards are still struggling to catch up even today, and failing to thrive in adversity may mean failing to survive in perpetuity. [Aside: how on Earth can today's politicians justify holding a climate change conference as a physical, in-person event, during COVID no less, rather than virtually, on-line? Are we even on the same planet? Shakes head in disbelief.]The relation goes both ways: policies can prompt strategic changes, and vice versa. Thinking forward, virtual working presents opportunities for global collaboration on an unprecedented scale, with reduced costs, increased efficiencies, access to a global talent pool and of course global markets. 'Globalization' is not just about establishing a widespread physical presence and brands: it's also about harnessing a widely distributed and culturally diverse workforce, harnessing technology to link, leverage and exploit the very best of the best. | Guideline | ||
|
2021-11-05 13:07:47 | Topic-specific policies 12/11: concluding the series (lien direct) |  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 general?7. Backup: there's more to information risk management than cyber! 8. Cryptography and key management: important for |
APT 17 | ||
|
2021-10-23 16:00:00 | Topic-specific example 11/11: secure development (lien direct) | The final topic-specific policy example from ISO/IEC 27002:2022 is another potential nightmare for the naïve and inexperienced policy author. Despite the context, 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, 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 potentially substantial 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 associated methods are many and varied, and more poignantly so are the information risks. Your homework challenge, today, is to consider, compare and contrast these five markedly different IT development scenarios:Commercial firmware being developed for a small smart actuator/sensor device (a thing) destined to be physically embedded in the pneumatic braking system of commercial vehicles such as trucks and coaches, by a specialist OEM supplier selected on the basis of lowest price. A long-overdue technical update and refresh for a German bank's mature financial management application, developed over a decade ago by a team of contractors long since dispersed or retired, based on an obsolete database, with fragmentary documentation in broken English and substantial compliance implications, being conducted by a large software house based entirely in India. A cloud-based TV program scheduling system for a global broadcaster, to be delivered iteratively over the next two years by a small team of contractors under the management of a consultancy firm for a client that freely admits it barely understands phase 1 and essentially has no idea what might be required next, or when.A departmental spreadsheet for time recording by home workers, so their time can be tracked and recharged to clients, and their productivity can be monitored by management.Custom hardware, firmware and autonomous software required for a scientific exploration of the Marianas trench - to be deployed in the only two deep-sea drones in existence that are physically capable of delivering and recovering the payload at the extreme depths required.You may have worked in or with projects/initiatives vaguely similar to one, maybe even two or three of these, but probably not all five - and these are just a few random illustrative examples plucked from the millions of such activities going on right now. The sheer number and variety of possibilities is bewildering, so how on earth can one draft a sensible policy?As is the way with ISO27k, the trick is to focus on the information | Patching Guideline | ||
|
2021-10-22 16:00:00 | Topic-specific example 10/11: management of technical vulnerabilities (lien direct) | 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, do 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 information risk management objectives in this regard (more on that below).Hinson tip: what are your information risk management objectives in this regard (concerning 'technical vulnerabilities' ... or whatever aspect/s you believe need addressing)? What information risks are you facing, how significant are they (relative to other things on your plate) and how do you intend to treat them? Seriously, think about it. Talk it through with your peers and professional colleagues. Draft a cunning treatment plan for this particular subset of information risks, discuss it with management and refine it. Lather, rinse, repeat until you achieve consensus (or wear down the blockers and negotiate a fragile settlement), and finally you are primed to craft your policy.Once more, we have your starter-for-ten, a generic patching policy template designed to help get you smartly off the starting blocks: While we don't presently offer a policy template on vulnerability disclosures (something worth adding to our to-do list, maybe?), we do have others that are to some extent relevant to this topic, for instance on change and configuration management and information systems security. I'll pick up on that point at the end of this blog series.Aside f |
Vulnerability | ||
|
2021-10-21 15:57:00 | Topic-specific policy 9/11: information classification and handling (lien direct) | 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. Each level or category of classification covers a range, a spectrum of information risks. Individual items of information falling at any point within the range are likely to be classified, labelled and handled in much the same way - which may not be appropriate in every case. What to do with unlabelled and/or unclassified or misclassified information is another concern, along with classification reviews, as well as the tendency to over-classification which impacts the availability of information for legitimate purposes. Finally, anything marked "TOP SECRET" in big red capitals is surely a magnet for spies, spooks, opportunist thieves, hackers, crackers, journalists, nosy/disaffected workers, fraudsters, criminals ... and even auditors on the prowl. It might as well say "READ ME!". So, although we offer a classification policy template, I'm reluctant to recommend classification as a general approach unless it is mandated for your organisation ... in which case your class/category definitions, processes and handling rules are probably already specified by whoever mandated it (perhaps in law), so you would need to check/update the template accordingly. In summary, the template is here, a basic classification policy starter for just $20. It's not one of the topic-specific policy examples I personally would have selected for the standard, though, and I have serious reservations about the corresponding controls in section 5. To me, it's an outdated, unhelpful and largely irrelevant approach - except perhaps for the |
|||
|
2021-10-20 16:00:00 | Topic-specific policy 8/11: cryptography and key management (lien direct) | Maybe this particular policy was mentioned in previous editions of ISO/IEC 27002 and picked as a topic-specific policy example for the forthcoming 3rd edition in order to include something directly relevant to governmental organisations, although to be fair crypto is a consideration for all of us these days. Many (most?) websites are now using HTTPS with TLS for encryption, for example, while cryptographic methods are commonly used for file and message integrity checks, such as application/patch installers that integrity-check themselves before proceeding, and password hashing.Here's a glimpse of one I prepared earlier: Like all our templates, this one is generic. Organisations with specific legal or contractual obligations in this area (such as governmental and defense companies bound to employ particular algorithms, key lengths and technologies such as physically secure hardware crypto modules, or companies bound by PCI-DSS) would need to adapt it accordingly. You'll see that it mentions the Information Classification Policy: I'll have more to blog about classification tomorrow.If you've been tagging along on my tiki-tour of the topic-specific policy examples in ISO/IEC 27002:2022, and if you read that LinkeDin piece by Chris Hall that I recommended, you will probably by now recognise the standard document structure we've adopted for all our policy templates. The main elements are:Page header with a logo (our logo in the template, yours to download and customise) and a short, pithy, catchy policy title.Information security policy up-front to be crystal clear about the nature and ownership of the policy, since some topics could equally belong to other corporate functions (e.g. our "Fraud" policy template is, in fact, an information security policy addressing the information risks associated with fraud, misrepresentation and so on, not an HR or legal policy about disciplinary procedures and compliance). Policy title, big and bold to stand out. The precise wording is important here (I'll return to that point in another blog piece).Policy summary, outlining |
APT 17 | ||
|
2021-10-19 16:00:00 | Topic-specific policy 7/11: backup (lien direct) | This is an interesting policy example to have been selected for inclusion in ISO/IEC 27002:2022, spanning the divide between 'cybersecurity' and 'the business'.Why do data need to be backed up? What's the purpose? How should it be done? Questions like these immediately spring to mind (mine anyway!) when I read the recommendation for a topic-specific policy on backup ... but as usual, there's more to it than that.Play along with me on this worked example. If you already have a backup policy (or something with a vaguely similar title), I urge you to dig it out at this point and study it (again!) before returning to read the remainder of this blog. Think about it. Does it address those three questions? What else does it cover? What is its scope? Is it readable, understandable, motivational - not just for you but for its intended audience/s? Does it state who those audiences are? Any spelling mistakes, grammatical errors or layout problems? Is it lengthy, officious, boring? Conversely, is it short, cryptic and puzzling? Is it more of a detailed plan for what backups to do, when and how, than a clear and unequivocal statement of management's overall expectations re backups? Is it consistent both internally (no contradictions or omissions) and externally (e.g. does it accord with other policies and adequately reflect any applicable compliance requirements)? All good so far? If not, hopefully this blog series has given you food for thought! Either way, what is it missing? What relevant matters does your backup policy not cover, either failing to mention them at all or perhaps gloss over them too superficially to have any impact?That's a harder question to answer, even if you were the one who wrote the existing policy. We all (me included!) tend to focus on our areas of interest and expertise. Policies are often formulated and written with particular scenarios, situations or incidents in mind, typically forming part of the response that drives continuous improvement. We don't always take the trouble to consult with colleagues, research the topic, explore the risks and controls, and think both broadly and deeply about the subject area - the topic of the policy. Frankly, we just don't think, failing to recognise and address our own biases and failings. Don't agree? OK, look again at the start of my second paragraph. I consciously slipped "data" in there, just as I deliberately mentioned "cyber" in the first one. Did you even notice the bias towards IT? Is your backup policy exclusively about backing up computer data, most likely digital data from corporate IT systems? Does it lay out the technologies, plus the frequencies and types of backup, in some detail?Don't get me wrong, that's a very important topic, essential in fact for virtually all modern organisations and indeed individuals today. My concern is that it still only covers part of the problem space, a peak on the risk landscape you could say.What about information in other forms and locations: | |||
|
2021-10-18 20:19:51 | Topic-specific policy 6/11: information security incident management (lien direct) | I'm intrigued by the title of this topic-specific policy from the [draft] 3rd edition of ISO/IEC 27002, being the only one of eleven example titles in the standard that explicitly states "information security". I ask myself why? Is there something special about the management of events classed as 'information security incidents', as opposed to other kinds? Hmmmm, yes there are some specifics but I'm not entirely convinced of a need for a distinct, unique policy. I feel there is more in common with the management of all kinds of incident than there are differences in respect of infosec incidents, hence "Incident management policy" makes more sense to me.Here's one I prepared earlier. Organisations deal with events and incidents all the time. Aside from the humdrum routines of business, things don't always go to plan and unexpected situations crop up. Mature organisations typically have incident management policies already, plus the accompanying procedures and indeed people primed and ready to respond to 'stuff' at the drop of a hat. Wouldn't it make sense, therefore, to ensure that "information security incidents" are handled in much the same way as others?That's fine for mature organisations. For the rest, the SecAware information security policy template on incident management concentrates on the specifics of infosec incidents and outlines incident management in general. A workable infosec policy can prompt the development and maturity of incident management by:Documenting and formalising things - particularly the process, expressing management's expectations and requirements in clear terms (e.g. striking the right balance between investigating and resolving incidents, especially where business continuity is a factor).Stabilising the working practices, de-cluttering things, making them more consistent and hence amenable to management control.Enabling reviews and audits, leading to systematic process improvement where appropriate.Discouraging inappropriate shortcuts (e.g. ineptly investigating serious issues, compromising important forensic evidence) while facilitating escalation and management decisions where appropriate (e.g. determining whether forensic investigation is justified). |
Guideline | ||
|
2021-10-16 18:08:00 | Topic-specific policy 5/11: networking security (lien direct) | The information risk and security implications of data networking, along with the ubiquity of data networks, makes this an obvious policy topic and naturally we offer a policy template. I alluded to this at the end of the last blog piece as one of several security policies relating to information transfer: Less obviously, there are also potentially significant information risks and security controls applicable to social networking and social media ... and yes, we have a policy template for that too: Although 'social media' generally refers to Facebook, Twitter, LinkeDin and the like, many of the information risks pre-date them, back to the days of in-person personal and business interactions through professional membership organisations, special interest groups, town hall meetings, breakfast clubs and chambers of commerce. Other comms technologies such as the telephone, email and videoconferencing, plus 'groups' and collaborative working, have dramatically expanded our opportunities for social contact, and also materially increased our exposure to global threats. Globalisation is a far bigger issue than 'networking' implies, with pros and cons.On the upside, ready access to peers, knowledgeable and experienced colleagues and heaps of advice through the Internet makes high quality information very available. It's a fantastic resource for the connected global community. On the downside, the sheer volume and variety of information online can be overwhelming. It is tricky to distinguish and sift the wheat from the chaff. Even your ninja Googling skills can only go so far! That dips into the realm of mis/disinformation, bias and fraud, further areas where well-written corporate policies can help. |
|||
|
2021-10-15 12:40:00 | Topic-specific policy 4/11: information transfer (lien direct) |  "Information transfer" is another ambiguous, potentially misleading title for a policy, even if it includes "information security". Depending on the context and the reader's understanding, it might mean or imply a security policy concerning:Any passage of information between any two or more end points - network datacommunications, for instance, sending someone a letter, speaking to them or drawing them a picture, body language, discussing business or personal matters, voyeurism, surveillance and spying etc.One way flows or a mutual, bilateral or multilateral exchange of information.Formal business reporting between the organisation and some third party, such as the external auditors, stockholders, banks or authorities.Discrete batch-mode data transfers (e.g. sending backup or archival tapes to a safe store, or updating secret keys in distributed hardware security modules), routine/regular/frequent transfers (e.g. strings of network packets), sporadic/exceptional/one-off transfers (e.g. subject access requests for personal information) or whatever. Transmission of information through broadcasting, training and awareness activities, reporting, policies, documentation, seminars, publications, blogs etc., plus its reception and comprehension. Internal communications within the organisation, for example between different business units, departments, teams and/or individuals, or between layers in the management hierarchy."Official"/mandatory, formalised disclosures to authorities or other third parties.Informal/unintended or formal/intentional communications that reveal or disclose sensitive information (raising confidentiality concerns) or critical information (with integrity and availability aspects). Formal provision of valuable information, for instance when a client discusses a case with a lawyer, accountant, auditor or some other professional. Legal transfer of information ownership, copyright etc. between parties, for example when a company takes over another or licenses its intellectual property.Again there are contextual ramifications. The nature and importance of information transfers differ between, say, hospitals and health service providers, consultants and their clients, social media companies and their customers, and battalion HQ with operating units out in the field. There is a common factor, however, namely information risk. The in |
General Information Guideline | APT 17 | |
|
2021-10-14 17:20:00 | Topic-specific policy 3/11: asset management (lien direct) |  This piece is different to the others in this blog series. I'm seizing the opportunity to explain the thinking behind, and the steps involved in researching and drafting, an information security policy through a worked example. This is about the policy development process, more than the asset management policy per se. One reason is that, despite having written numerous policies on other topics in the same general area, we hadn't appreciated the value of an asset management policy, as such, even allowing for the ambiguous title of the example given in the current draft of ISO/IEC 27002:2022. The standard formally but (in my opinion) misleadingly defines asset as 'anything that has value to the organization', with an unhelpful note distinguishing primary from supporting assets. By literal substitution, 'anything that has value to the organization management' is the third example information security policy topic in section 5.1 ... but what does that actually mean?Hmmmm. Isn't it tautologous? Does anything not of value even require management? Is the final word in 'anything that has value to the organization management' a noun or verb i.e. does the policy concern the management of organizational assets, or is it about securing organizational assets that are valuable to its managers; or both, or something else entirely? Well, OK then, perhaps the standard is suggesting a policy on the information security aspects involved in managing information assets, by which I mean both the intangible information content and (as applicable) the physical storage media and processing/communications systems such as hard drives and computer networks?Seeking inspiration, Googling 'information security asset management policy' found me a policy by Sefton Council along those lines: with about 4 full pages of content, it covers security aspects of both the information content and IT systems, more specifically information ownership, valuation and acceptable use:1.2. Policy Statement The purpose of this policy is to achieve and maintain appropriate protection of organisational assets. It does this by ensuring that every information asset has an owner and that the nature and value of each asset is fully understood. It also ensures that the boundaries of acceptable use are clearly defined for anyone that has access to |
Tool Guideline | APT 17 | |
|
2021-10-13 15:59:00 | Topic-specific policy 2/11: physical and environmental security (lien direct) | Yesterday I blogged about the "access control" topic-specific policy example in ISO/IEC 27002:2022. Today's subject is the "physical and environmental security" policy example.Physical security controls are clearly important for tangible information assets, including IT systems and media, documentation and people - yes, people.The first "computers" were humans who computed numbers, preparing look-up tables to set up field guns at the right elevation and azimuth angles to hit designated targets at specific ranges given the wind speed and direction, terrain and ordinance - quite a lot of factors to take into account in the field, so the pre-calculated tables helped speed and accuracy provided the gunners used them correctly anyway, and I'm sure they were highly trained and closely overseen!Aside from a little mental arithmetic, most of us don't "compute" many numbers today but we still process staggering quantities of information flowing constantly from our senses and memories. In the work context, the trite mantra "Our people are our greatest assets" may be literally true, given the knowledge, experience, expertise and creativity of workers. We have valuable intangible proprietary and personal information locked in our heads, trade secrets, innovative ideas and more. We are information assets, although to be fair the true values vary markedly (and, yes, some are liabilities!). Why do you think some people are paid more than others?Aside from the commercial value aspect, workers require adequate protection against unacceptable health and safety risks according to national laws and regulations. We also deserve respect, personal space, privacy, understanding, fair and reasonable compensation and so on, raising ethical and further legal or contractual obligations. Environmental protection ensures that workers have reasonably pleasant workplaces, partly for health and ethical reasons, partly for productivity reasons. Computer systems likewise work more reliably under manufacturer-specified ambient temperatures and require appropriate electricity supplies. The total demands for cooling and power can be significant in a large computer room or data centre. Oh and don't forget the physical security and environmental controls for portable equipment and home offices - safe storage, for instance, plus security cables, etched corporate logos, good quality power supplies and UPSs, spare batteries and more. Environmental controls relating to noxious by-products, greenhouse gases, dangerous emissions, excessive noise, explosive/flammable products, dangerous processes etc. are particularly important for chemical and manufacturing industries, among others ... but are they 'information security controls'? I would argue yes for some, perhaps most of them. For instance, electric valve and sluice gate controllers on a sewage treatment plant that are computerised and networked smart things are at risk from malware, hackers, inept system administration or configuration errors, software design flaws and programming bugs, mechanical problems, power glitches and more. So, there is clearly a wide variety of information risks and controls in this area, collectively presenting significant challenges in various organisatio | |||
|
2021-10-12 19:44:00 | Topic-specific policy 1/11: access control (lien direct) | Clause 5.1 of the forthcoming new 2022 edition of ISO/IEC 27002 recommends having a topic-specific information security policy on "access control". OK, fine, so what would that actually look like, in practice?Before reading on, think about that for a moment. Imagine if you were tasked to draft an access control policy, what would it cover? What form would it take?How would you even start? How about something along these lines, for starters: What is access control intended to achieve? In about half a page, the background section explains the rationale for controlling access to assets (meaning valuable things such as information in various forms, including but more than just digital data).The policy goes on to state that, whereas access to information should be restricted where necessary, access by workers should be permitted by default unless there are legitimate reasons to restrict it. In other words, a liberal approach that releases information for use unless it needs to be restricted for some reason ... which in turn begs questions about what are those legitimate reasons? Who decides and on what basis?The alternative approach is to restrict access to assets by default unless there sound reasons to permit access, begging the same questions.The template policy takes both approaches, in the form of these complementary 'policy axioms':Policy axioms (guiding principles) [if !supportLists]-->A. Access to corporate information assets by workers should be permitted by default unless there is a legitimate need to restrict it. [if !supportLists]-->B. Access to corporate information assets by third-parties should be restricted by default unless there is a legitimate need to permit it. The idea is that, generally speaking, "workers" (which is defined elsewhere to include employees on the organization's payroll - staff and managers - plus third party employees and others such as interns, temps and consultants working for and on behalf of the organisation, under its co |
APT 17 | ||
|
2021-10-11 15:57:00 | ISO/IEC 27002\'s overall and topic-specific information security policies 0/11 (lien direct) |  Clause 5.1 of the forthcoming new 3rd edition of ISO/IEC 27002 recommends two complementary types of information security policies.Firstly: At the highest level, organizations should define an “information security policy” which is approved by top management and which sets out the organization's approach to managing its information security.The policy (singular) should address requirements derived from various sources, and include a bunch of general policy statements, for example laying out the organisation's commitments (as stated by senior management) to satisfy applicable requirements relating to information security, and to improve the information security management system continually. In addition:At a lower level, the information security policy should be supported by topic-specific policies, as needed to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned and complementary to the information security policy of the organization.Topic-specific policies (plural) should be aligned with and support the high-level policy, providing additional details in various areas. The standard lists 11 topics as examples ... and I plan to talk about those day by day through this blog. After that, I'll write about integrating all the policies, including the top one, into a coherent and comprehensive policy suite - taking an holistic/system view of the entire policy structure. So, tune in tomorrow for the first of twelve enthralling episodes! |
|||
|
2021-10-07 14:24:08 | An important lesson from the Farcebook Fiasco 2021 (lien direct) |  I gather from friends and the news media that there was an unplanned outage earlier this week at Facebook. I'm told that Facebook is a fairly popular social media platform - some have said addictive. As you can no doubt tell, I don't see the attraction and I'm definitely not hooked. If it weren't for the brouhaha, I wouldn't have even noticed.I understand the outage was caused by a technical issue in the network - something to do with the BGP configuration. I'm not particularly interested in, and probably wouldn't even understand, the details. The self same issue locked Facebook's IT administrators out of their own systems, leaving them cut off and unable to address/reverse/fix the issue for several hours, causing mild panic and a little outrage among its users, customers and other stakeholders. The same issue took down related websites too. Doubtless the admins were stressed out, possibly frantic, while their managers were unimpressed.I'm bringing it up here to point out a lesson for all other organisations, not just those reliant on remote system admin. If the network access is broken and unavailable, for whatever reason, remote admin is also broken and unavailable. That's screamingly obvious to all of us now with 20/20 hindsight thanks to the Farcebook Fiasco, and clearly an issue worth addressing by organisations that use and rely on remote system/network/app/IT admin, of which I'm sure there are many. I'm told that cloud is in, and the Interwebs are quite useful.Less obviously, the incident a neat reminder that foresight is even more valuable, more specifically information risk management. Regardless of the nature of the technical issue and preceding activities that sparked the outage, single points of failure are a class of vulnerability well worth identifying and addressing, especially for anything important. The solution is known as defence-in-depth, an approach that is universally employed by all living organisms - except, it seems, Facebook IT people. As to how they might have mitigated the risks, there are several possible means of administering network systems aside from remote access through the same network. I'm not even going to attempt to list them. Go ahead, Google if you care. There are myriad ways that information services may be interrupted, some deliberate/intentional, many accidental, inadvertent or due to natural causes. It's simply impracticable to attempt to identify and deal with them all, individually, hence the value of a much more generalised approach to specifying, achieving, maintaining and being confident in the required availability. It's called resilience, a natural complement to contingency planning, both of which are parts of the nebulous approach called business continuity management. That's more than enough waffle |
Vulnerability | ||
|
2021-07-29 16:36:24 | Pinball management (lien direct) |  It could be argued that 'management' of all kinds (including information risk and security management) is or rather shouldbe a rational process, meaning that managers should systematically gather and evaluate information, take account of sound advice, make sensible decisions, put in place whatever is necessary to implement the decisions etc., all the time acting in the organization's best interests, furthering its business objectives, strategies, policies etc. In practice, there are all manner of issues with that approach that complicate matters, frustrate things, and lead to 'suboptimal' situations that may be - or at least appear to be - irrational, inappropriate or unnecessary. In particular, there are numerous paradoxes. For examples:The obvious core objective of a typical commercial company to make a substantial profit for its owners may conflict with various ethical and legal objectives to spend money on protecting and furthering the wider interests of society and individuals - including their privacy. There's a fine line between motivating/supporting/encouraging/directing and demotivating/micro-managing/exploiting employees. Efficiency in most matters comes at the cost of effectiveness, and vice versa. They say quality is free, but is that a lie? |
Guideline | ||
|
2021-07-11 09:37:45 | Managing certainty (lien direct) |  'Reducing uncertainty' is the prime focus of information risk management today. We do our level best to identify, characterise, quantify, evaluate and where possible reduce the probabilities and/or adverse consequences of various possible events. Uncertainty is an inherent part of the problems we typically face. We don't know exactly what might happen, nor how or when, and we aren't entirely sure about the consequences. We worry about factors both within and without our control, and about dependencies and complex interactions that frustrate our efforts to predict and control our fortunes. We adopt fallback and recovery arrangements, and apply contingency thinking with the intention of being better prepared and resourced for unanticipated situations ahead. A random comment on LinkeDin set me thinking about the converse: 'reducing uncertainty' is the flip side of 'increasing certainty', in other words information risk management is equally about increasing certainty of beneficial, valuable outcomes such as not suffering the adverse consequences of incidents as often and/or as severely. It's also about increasing certainty in general, which is why we put so much effort into gathering and assessing information, monitoring and measuring things, implementing mitigating 'information security controls' that give us some semblance of control over the risks.Assurance is a big part of reducing uncertainty. We check and test things, review stuff and conduct audits to increase both our knowledge of, and our confidence in, the arrangements. We seek to identify and tease out potential issues that need to be addressed in order to avoid nasty surprises. Resilience is another chunk. Building the strength and capability to respond effectively and efficiently to whatever might happen, maintaining critical activities throughout, is a powerful approach that extends from individuals through families, teams and departments, to organisations, industries and society at large.Thanks to those uncertainties, we are inevitably building on shaky foundations. Our information risk management practices and information security controls are imperfect ... but at the same time they earn their keep by generating more value than they cost, for example by:Providing credible information about various situations, allowing us to make rational decisions, prioritise and plan things, allocate appropriate resources etc.;Reducing or constraining the problem space where possible, increasing our ability to focus on The Stuff That Really Matters;Allowing us to consider and deal with potential incidents in advance, knowing that we will struggle to do so during some future crisis. Along with |
|||
|
2021-06-26 17:27:23 | Are our infosec controls sufficient? (lien direct) |  ^ Although it's tempting to dismiss such questions as rhetorical, trivial or too difficult, there are reasons for taking them seriously*. Today I'm digging a little deeper into the basis for posing such tricky questions, explaining how we typically go about answering them in practice, using that specific question as an example. OK, here goes.The accepted way of determining the sufficiency of controls is to evaluate them against the requirements. Adroitly sidestepping those requirements for now, I plan to blabber on about the evaluation aspect or, more accurately, assurance.Reviewing, testing, auditing, monitoring etc. are assurance methods intended to increase our knowledge. We gather relevant data, facts, evidence or other information concerning a situation of concern, consider and assess/evaluate it in order to:Demonstrate, prove or engender confidence that things are going to plan, working well, sufficient and adequate in practice, as we hope; andIdentify and ideally quantify any issues i.e. aspects that are not, in reality, working quite so well, sufficiently and adequately. Assurance activities qualify as controls to mitigate risks, such as information risks associated with information risk and security management e.g.: Mistakes in our identification of other information risks (e.g. failing to appreciate critical information-related dependencies of various kinds); Biases and errors in our assessment/evaluation of identified information risks (e.g. today's obsessive focus on “cyber” implies down-playing, perhaps even ignoring other aspects of information security, including non-cyber threats such as physical disasters and hum |
Malware Guideline | ||
|
2021-05-25 14:27:57 | Stepping on the cracks (lien direct) |  Anyone seeking information security standards or guidance is spoilt for choice e.g.:ISO27k - produced by a large international committee of subject matter experts and national representatives NIST SP 800 series – well researched, well written, actively maintained ... and FREE!IT Grundschutz - a typically thorough Germanic approach, to the point of absurdity (4,800 pages!) CSA - cloud security guidance is their home turfCOBIT - takes a deliberately different perspective on 'risk' and 'control' Secure application development standards such as those from OWASP IT standards and methods as a whole: relevant because IT or cyber security is clearly a big part of information security HR, physical security, privacy and business continuity standards and methods as a whole: filling-in the substantial gaps in IT or cyber security Risk management standards, the best of which at least mention the importance of identifying and managing information risksPCI DSS - not really an infosec standard so much as a contractual mechanism forcing organizations using credit cards to play their part in maintaining card security |
|||
|
2021-05-24 17:23:22 | News on ISO/IEC 27002 (lien direct) | Today I've slogged my way through a stack of ~50 ISO/IEC JTC1/SC27 emails, updating a few ISO27001security.compages here and there on ongoing standards activities. The most significant thing to report is that the 3rd (2013) edition of ISO/IEC 27002 appears on-track to reach final draft stage soon and will hopefully be approved this year, then published soon after (during 2022, I guess). The standard is being extensivelyrestructured and revised, collating and addressing about 300 pages of comments from the national standards bodies at every stage. The editorial team are doing an amazing job! The new '27002 structure will have the controls divided into 4 broad categories or types i.e. technical, physical, people and 'organizational' [=other]:  For comparison, the standard is currently structured into 13 security domains:  '27002 will nearly double in size, going from 90 to 160 pages or so, thanks to new controls and additional advice including areas such as cloud and IoT security. Virtually all of the original controls have been retained but most have been reworded for the new structure and current practice … and there's an appendix mapping the old clauses to the new. '27001 Annex A is being updated to reflect the changes, and a new version of that standard is due to be published in the 2nd quarter of 2022. I presume other standards based on '27002 (such as ' |
|||
|
2021-04-24 09:47:20 | Pre-shocks and after-shocks (lien direct) |  Just a brief note today: it's a lovely sunny Saturday morning down here and I have Things To Do.I'm currently enjoying another book by one of my favourite tech authors: Yossi Sheffi's |
Guideline | ||
|
2021-04-23 15:58:38 | KISS or optimise your ISO27k ISMS? (lien direct) | From time to time as we chat about scoping and designing Information Security Management Systems on the ISO27k Forum, someone naively suggests that we should Keep It Simple Stupid. After all, an ISO27k ISMS is, essentially, simply a structured, systematic approach for information risk management, isn't it? At face value, then, KISS makes sense. In practice, however, factors that complicate matters for organizations designing, implementing and using their ISMSs include different: Business contexts – different organization sizes, structures, maturities, resources, experiences, resilience, adaptability, industries etc.; Types and significances of risks – different threats, vulnerabilities and impacts, different potential incidents of concern; Understandings of 'information', 'risk' and 'management' etc. – different goals/objectives, constraints and opportunities, even within a given organization/management team (and sometimes even within someone's head!); Perspectives: the bungee jumper, bungee supplier and onlookers have markedly different appreciations of the same risks; Ways of structuring things within the specifications of '27001, since individual managers and management teams have the latitude to approach things differently, making unique decisions based on their understandings, | Guideline | ||
|
2021-04-19 14:51:35 | Policy development process: phase 2 (lien direct) |  Today we completed and published a new "topic-specific" information security policy template on clear desk and screen.Having previously considered information risks within the policy scope, writing the policy involved determining how to treat the risks and hence what information security or other controls are most appropriate. Here we drew on guidance from the ISO27k standards, plus other standards, advisories and good practices that we've picked up in the course of ~30 years in the field, working with a variety of industries and organizations - and that's an interesting part of the challenge of developing generic policy templates. Different organizations - even different business units, departments, offices or teams within a given organization - can take markedly different attitudes towards clear desk and screen. The most paranoid are obsessive about it, mandating controls that would be excessive and inappropriate for most others. Conversely, some are decidedly lax, to the point that information is (to my mind) distinctly and unnecessarily vulnerable to deliberate and accidental threats. We've picked out controls that we feel are commonplace, cost-effective and hence sensible for most organizations.COVID19 raises another concern, namely how the risks and controls in this area vary between home offices or other non-corporate 'working from home' workplaces, compared to typical corporate offices and other workplaces. The variety of situations makes it tricky to develop a brief, general policy without delving into all the possibilities and specifics. The approach we've taken is to mention this aspect and recommend just a few key controls, hoping that workers will get the point. Customers can always customise the policy templates, for example adding explicit restrictions for particular types of information, relaxing things under certain conditions, or beefing-up the monitoring, oversight and compliance controls that accompany the policies - which is yet another complicating factor: the business context for information security policies goes beyond the written words into how they are used and mandated in practice.Doing all of this in a way that condenses the topic to just a few pages of good practice guidance, well-written in a motivational yet generic manner, and forms a valuable part of the SecAware policy suite, explains the hours we've sunk into the research and writing. Let's hope it's a best seller! |
|||
|
2021-04-13 11:17:11 | Policy development process: phase 1 (lien direct) | On Sunday I blogged about preparing four new 'topic-specific' information security policy templates for SecAware. Today I'm writing about the process of preparing a policy template.First of all, the fact that I have four titles means I already have a rough idea of what the policies are going to cover (yes, there's a phase zero). 'Capacity and performance management', for instance, is one requested by a customer - and fair enough. As I said on Sunday, this is a legitimate information risk and security issue with implications for confidentiality and integrity as well as the obvious availability of information. In my professional opinion, the issue is sufficiently significant to justify senior management's concern, engagement and consideration (at least). Formulating and drafting a policy is one way to crystallise the topic in a form that can be discussed by management, hopefully leading to decisions about what the organisation should do. It's a prompt to action.At this phase in the drafting process, I am focused on explaining things to senior management in such a way that they understand the topic area, take an interest, think about it, and accept that it is worth determining rules in this area. The most direct way I know of gaining their understanding and interest is to describe the matter 'in business terms'. Why does 'capacity and performance management' matter to the business? What are the strategic and operational implications? More specifically, what are the associated information risks? What kinds of incident involving inadequate capacity and performance can adversely affect the organization?Answering such questions is quite tough for generic policy templates lacking the specific business context of a given organisation or industry, so we encourage customers to customise the policy materials to suit their situations. For instance:An IT/cloud service company would probably emphasise the need to maintain adequate IT capacity and performance for its clients and for its own business operations, elaborating on the associated IT/cyber risks.A healthcare company could mention health-related risk examples where delays in furnishing critical information to the workers who need it could jeopardise treatments and critical care.A small business might point out the risks to availability of its key workers, and the business implications of losing its people (and their invaluable knowledge and experience i.e. information assets) due to illness/disease, resignation or retirement. COVID is a very topical illustration. An accountancy or law firm could focus on avoiding issues caused by late or incomplete information - perhaps even discussing the delicate balance between those two aspects (e.g. there a |
Guideline | ||
|
2021-04-11 14:52:31 | Infosec policy development (lien direct) |  We're currently preparing some new information risk and security policies for SecAware.com. It's hard to find gaps in the suite of 81 policy templates already on sale (!) but we're working on these four additions:Capacity and performance management: usually, an organization's capacity for information processing is managed by specialists in IT and HR. They help general management optimise and stay on top of information processing performance too. If capacity is insufficient and/or performance drops, that obviously affects the availability of information ... but it can harm the quality/integrity and may lead to changes that compromise confidentiality, making this an information security issue. The controls in this policy will include engineering, performance monitoring, analysis/projection and flexibility, with the aim of increasing the organisation's resilience. It's not quite as simple as 'moving to the cloud', although that may be part of the approach.Information transfer: disclosing/sharing information with, and obtaining information from, third party organisations and individuals is so commonplace, so routine, that we rarely even think about it. This policy will outline the associated information risks, mitigating controls and other relevant approaches.Vulnerability disclosure: what should the organisation do if someone notifies it of vulnerabilities or other issues in its information systems, websites, apps and processes? Should there be mechanisms in place to facilitate, even encourage notification? How should issues be addressed? How does this relate to penetration testing, incident management and assurance? Lots of questions to get our teeth into!Clear desks and screens: this is such a basic, self-evident information security issue that it hardly seems worth formulating a policy. However, in the absence of policy and with no 'official' guidance, some workers may not appreciate the issue or may be too lazy/careless to do the right thing. These days, with so many people working from home, the management oversight and peer pressure typical in corporate office settings are weak or non-existent, so maybe it is worth strengthening the controls by reminding workers to tidy up their workplaces and log off. It's banale, not hard! The next release of ISO/IEC 27002 will call these "topic-specific information security policies" focusing on particular issues and/or groups of people in some detail, whereas the organisation's "information security policy" is an overarching, general, |
Guideline | ||
|
2021-03-11 12:10:12 | NBlog Mar 11 - book review on "Cyber Strategy" (lien direct) |  Cyber StrategyRisk-driven Security and ResiliencyAuthors: Carol A. Siegel and Mark SweeneyPublisher: Auerbach/CRC PressISBN: 978-0-367-45817-1Price: ~US$100 + shipping from AmazonOutlineThis book lays out a systematic process for developing corporate strategy in the area of cyber (meaning IT) security and resilience. ProsAn in-depth exposition on an extremely important topicIt emphasises risks to the business, to its information, and to its IT systems and networks, in that orderSystematic, well structured and well written, making it readable despite the fairly intense subject matterLots of diagrams, example reports and checklists to help put the ideas into actionTreating strategy development as a discrete project is an intriguing approachConsDescribes a fairly laborious, costly and inflexible approach, if taken literally and followed STEP-by-STEPImplies a large corporate setting, with entire departments of professionals specializing and willing to perform or help out in various areas A little dogmatic: alternative approaches are not only possible but sufficient, appropriate or even better under various circumstances, but strategic options and choices are seldom mentionedAs described, the strategy planning horizon is very shortAn entirely defensive risk-averse strategic approach is implied |
|||
|
2021-01-10 10:34:21 | Y2k + 20: risk, COVID and "the Internet issue" (lien direct) |  It feels like 'just the other day' to me but do you recall "Y2k" and all that? Some of you reading this weren't even born back then, so here's a brief, biased and somewhat cynical recap.For a long time prior to the year 2000, a significant number of software programmers had taken the same shortcut we all did back in "the 90s". Year values were often coded with just two decimal digits: 97, 98, 99 ... then 00, "coming ready or not!"."Oh Oh" you could say. "OOps".When year counters went around the clock and reset to zero, simplistic arithmetic operations (such as calculating when something last happened, or should next occur) would fail causing ... well, potentially causing issues, in some cases far more significant than others.Failing coke can dispensers and the appropriately-named Hornby Dublo train sets we could have coped with but, trust me, you wouldn't want your heart pacemaker, new fangled fly-by-wire plane or the global air traffic control system to decide that it had to pack up instantly because it was nearly 100 years past its certified safe lifetime. Power grids, water and sewerage systems, transportation signalling, all manner of communications, financial, commercial and governmental services could all have fallen in a heap if the Y2k problems wasn't resolved in time, and this was one IT project with a hard, immutable deadline, at a time when IT project slippage was expected, almost obligatory. Tongue-in-cheek suggestions that we might shimmy smoothly into January 1st [19]9A were geekly-amusing but totally impracticable. In risk terms, the probability of Y2k incidents approached 100% certain and the personal or societal impacts could have been catastrophic under various credible scenarios - if (again) the Y2k monster wasn't slain before the new year's fireworks went off ... and, yes, those fancy public fireworks display automated ignition systems had Y2k failure modes too, along with the fire and emergency dispatch systems and vehicles. The combination of very high probability and catastrophic impact results in a risk up at the high end of a tall scale. So, egged-on by information security pro's and IT auditors (me, for instance), management took the risk seriously and invested significant resources into solving "the Y2k issue". Did you spot the subtle shift from "Y2k" to "the Y2k issue"? I'll circle back to that in just a moment. Individual Y2k programming updates were relatively straightforward on the whole (with some interesting exceptions, mostly due to prehistoric IT systems still in use well past their best-before dates, with insurmounta |
Guideline | ||
|
2020-11-15 10:43:57 | NBlog Nov 15 - the trouble with dropping controls (lien direct) | I literally don't understand a question that came up on the ISO27k Forum this week. A member asked:'Should a control be discontinued because a reassessment showed a lower acceptable risk score?' I find it interesting to pick apart the question to explore the reasons why I don't understand it, and the implications. See what you think ... Any control may legitimately be 'discontinued' (removed, unimplemented, retired, replaced, modified etc.) provided that change has been duly thought-through, assessed, justified, and deemed appropriate for whatever reasons. It may be important, though, to be reasonably certain that discontinuation is, in fact, in the best interests of the organization, and that's often hard to determine as controls can be quite complex in themselves, and are part of a highly complex 'control environment'. A seemingly trivial, unimportant, even redundant control (such as an alert) might turn out to be critical under specific circumstances (where other alerts fail, or were accidentally disabled, or were actively and deliberately bypassed by an attacker or fraudster). So, it may be preferable to 'suspend' the control for a while, pending a review to determine what the effects truly are … since it is probably easier and quicker to reinstate a 'suspended' control if needs be, than it would have been if the control was completely removed and trashed. A dubious firewall rule, for example, might be set to 'warn and log only', rather than simply being dropped from the ruleset, the reverse o |
|||
|
2020-10-08 05:41:06 | NBlog Oct 8 - is Facebook an asset? (lien direct) |  Yet another good question came up on the ISO27k Forum today*. Someone asked whether to add the company's Facebook page to their information asset register (implying that it would need to be risk-assessed and secured using the Information Security Management System processes), or whether the asset should be the Facebook account (ID and password, I guess)**.From the marketing/corporate perspective, good customer relations are perhaps the most valuable information assets of all, along with other external relations (e.g. your suppliers, partners, prospective and former customers, regulators/authorities and owners) and internal relations (the workforce, including staff, management, contractors, consultants and temps, plus former and prospective workers). It's tempting to think of these as just categories or faceless corporations, but in reality the interactions are between individual human beings, so social relationsin general are extremely important in business. There are numerous mechanisms that generate, support and maintain good customer relations, Facebook for example. Likewise for other relations (e.g. ISO27k Forum!). You might think of them as simply apps or information services, often cloud based, often commercial services provided by third parties hence limiting what is on offer and your options or influence over the infosec, privacy and other requirements. There are also related processes and activities, some of which have infosec, privacy and other implications e.g. I have a bank pestering me right now for identification info which they need from me as part of the anti money laundering regs: it's a pain for me and for them, but they have to comply with the laws and regs. Workforce relationship management and 'industrial relations' is a huge part of 'management', with governance, compliance and other implications and risks. Overall, relationship management is, clearly, an important part of business success, or indeed failure when things go horribly wrong (e.g. look up the Ratners jewelers fiasco in the UK, and just look around at the difficulties arising from COVID-19: our people and myriad relationships are under extreme stress this year, not just our organisations). Summing up, I encourage everyone to think big in terms of the scope of information assets, with a strong emphasis on the information that matters most to the business, the organization, and its strategic objectives. The IT systems and services are merely business tools: what matters most is the business information generated/processed by them.* As I've said before, it's funny how often a simple, seemingly basic or naive question on ISO27k Forum leads to something more revealing when the answers and debate sta |
Guideline | ||
|
2020-09-27 17:59:17 | NBlog Sept 27 - 2021 infosec budget (lien direct) |  Are you responsible for your organisation's information security or cybersecurity budget? Are you busily putting the finishing touches to your 2021 budget request, still working on it, just thinking about it, or planning to do it, honestly, when you next come up for breath?Budgeting is generally a dreaded, stressful management task. Not only do we have to figure out the figures but we typically anticipate a tough battle ahead leading (probably) to a disappointing outcome and yet more problems.On top of that, 2020 has been an exceptional year thanks to COVID. The business and information security implications of knowledge workers suddenly working from home, en masse, are still playing out now, while the economic impacts of COVID do not bode well for any of next year's budgets except perhaps for the manufacture of vaccines, masks, gloves, sanitiser and respirators.A substantial part of information security expenditure is (whatever we may believe as professionals) discretionary. The decision to go for ISO/IEC 27001 certification, for instance, flows largely from management's appreciation of the business value of investing in information risk and security management good practices. There may be specific drivers such as incidents, compliance pressures or demands from business owners, partners and prospective customers, but even then there are numerous options and factors to consider such as:The objectives for the Information Security Management System - what it is expected to achieve;How broadly or narrowly to scope the ISMS;At what pace to implement the standard, and how precisely;What resources to assign to the implementation, not least a suitable implementation project manager/consultant and project team;Priorities for this work relative to other business activities, objectives and requirements, making adjustments as necessary (both initially and as the project proceeds when stuff comes up - as COVID did, for instance);Alignment with other corporate projects and initiatives e.g. exploiting strategic opportunities to update various systems, policies and processes for security and other reasons, at the same time;Change management aspects: does the organisation have the capacity and appetite first to adopt and assimilate the ISMS, and secondly to get the most out of it; Project risks e.g. the possibility that things probably w |
Guideline | ||
|
2020-09-24 11:12:00 | NBlog Sept 24 - status of ISO27001 Annex A (lien direct) | One of the recurrent (zombie) threads on the ISO27k Forum concerns the status of ISO/IEC 27001:2013 Annex A. Typically the zombie is prodded from its slumber by a relatively inexperienced member naively suggesting that certain security controls from Annex A are essential, implying that they are mandatory for certification.In the course of debating and attempting to bury the zombie, some members trot out their own curious interpretations of the standard, pointing out actual and apparent discrepancies in the wording which, to them, indicate that Annex A is at least partly mandatory. I'm too polite to say they are wrong, but I believe they are misguided or mistaken - partly, it must be admitted, because the standard is ambiguously worded in some areas, hence it has to be interpreted carefully in practice. To be clear, based on my three decades' professional experience and membership of ISO/IEC JTC 1/SC 27, my position is that none of the controls outlined in Annex A are mandatory. None at all. Zero.This is a fundamental but complex issue to explain, so please forgive this lengthy post. In hope of decapitating the zombie, once and for all, I feel the urge to explain in detail. To kick off, I'll emphasise the critical distinction between two key terms: Mandatory |
|||
|
2020-09-04 14:26:51 | NBlog Sept 4 - standardising ISMS data interfaces (lien direct) |  We've been chatting on the ISO27k Forum lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that "Each organisation trying to implement an ISMS will find it's own way based on their requirements."Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular security controls (as happens with PCI-DSS). ISO27k is designed to apply to any organisation. That thought sparked a creative idea that I've been contemplating ever since: wouldn't it be wonderful if there was a standard for the data formats allowing us to migrate easily between IT systems supporting ISO27k ISMSs?I'm idly thinking about a standard file format with which to specify information risks (threats, vulnerabilities, impacts and probabilities), controls, policies, procedures, metrics, objectives etc. - maybe an XML schema with specified field names and (where applicable) enumerated lists of values.Aside from migrating between ISMS IT support systems and services, standard data formats would facilitate data sharing between application systems, services or sub-functions (e.g. for vulnerability management, incident management and information risk management), and between departments or even organisations (e.g. insurance companies, auditors and advisors and their clients and partners).Perhaps we should develop an outline specification and propose such a standard to ISO/IEC JTC1 SC 27. A New W |
Tool Vulnerability | ||
|
2020-09-04 14:22:25 | NBlog July 15 - ISO27k ISMS products (lien direct) |  Having drafted a generic requirement specification for systems supporting an ISO27k ISMS, I'm slowly trawling the Web for products in the hope of finding apps, templates and services that we would be willing to use ourselves and recommend to our consulting clients.So far I've found about 20 commercial or open-source ISMS systems plus maybe twice that number of risk management systems, plus quite a variety of more focused systems supporting incident management, business continuity, vulnerability management, patch management etc. It's a confusing, sprawling and dynamic market … so I'm also working on a structured evaluation process that will help us pick out gems from the stones on offer, depending on our own and our clients' specific needs.Along the way, I've picked up murmurings of discontent from customers saddled with low-quality content supplied with some ISO27k ISMS systems and toolkits. Aside from variation between the products, could it be, I wonder, that some of the products currently on offer are inadequate because customers vary so much in size, complexity, maturity etc. having different expectations or requirements? Could this be a side-effect of ISO27k's intended application to all organizations, resulting it being jack-of-all-trades and master-of-none? We could develop generic content specifically targeting particular market segments or types of organisation ... but instead we've started with the basics that every ISO27k ISMS needs with the intention of offering optional add-ons, giving customers more choice. One of those options is to develop custom materials and support individual customers to implement and optimise their ISMSs using appropriate systems/tools, provided we can convince management of the value of our consultancy services - and that's a tough sell, especially during COVID-19. Doing it all in-house may be a viable option if the organisation has the people with the requisite skills, competencies, knowledge and experience. That seems unlikely if there is no ISMS already in place - catch 22. There's also the matter of the time needed for people to learn the ropes and get up to speed with the ISMS, given all the other things on the go: the longer things drift along, the more the organisation remains subject to information risks that may not be managed effectively.I'm working on other options too. More info to follow. Watch this space. |
Vulnerability | ★★★ | |
|
2020-09-03 16:03:50 | NBlog Sept 3 - ISO27001 rocket fuel (lien direct) |  We're on a mission to convince every organisation that managing information risks properly is more than just a compliance imperative. It's good for business.Is your organisation looking to raise its security game? Are managers worried about ransomware, privacy breaches and intellectual property theft, especially now with so many of us working from home? What about the business continuity risks as supply chains are stressed to breaking point by COVID-19? Are your suppliers cutting corners on privacy and security, hoping nobody will notice? Are desperate competitors taking advantage of the disruption to undermine your cyber-defences?Worse still, is management blissfully unaware of the issues, with everyone heads-down, rowing hard, too busy to notice the icebergs dead ahead?... Or is there a strong drive to secure and exploit information as an integral part of operations? Does being trusted by customers and stakeholders equate to brand value, new and repeat business, opening up strategic opportunities?This is a great opportunity totake the first step on your mission!We have developed a modular approach based on ISO/IEC 27001. An Information Security Management System facilitates the management of information risks, information security controls, governance and assurance arrangements and so forth, 'systematically' i.e. in a structured and coherent way.Despite being standards, ISO27k acknowledges that each organisation needs to adapt the ISMS according to the business situation and the associated information risks. Within the same general governance structure, the specific requirements vary markedly between organisations and industries. With that in mind, we've developed a suite of materials covering the mandatory requirements for every ISMS, plus add-ons for the discretionary parts. In truth, all of them - even the mandatory ones - are templates, designed to be customised ... and we can even help you with that if you like!Through SecAware.com, we offer several packages:ISMS Launchpad is a minimalist set of templates for the mandatory |
|||
|
2020-08-28 15:19:43 | NBlog Aug 28 - NZ Stock Exchange DDoS continues (lien direct) |  The New Zealand Stock Exchange is having a rough week. Under assault from a sustained DDoS attack, its web servers have crumpled and fallen in an untidy heap again today, the fourth day of embarrassing and costly disruption.DDoS attacks are generally not sophisticated hacks but crude overloads caused by sending vast volumes of data to overwhelm the servers. The Host Error message above shows "RedShield" which appears to be a security service remarkably similar to a Web Application Firewall (although the company claims to be producing something far better) ... If so, RedShield appears to be passing DDoS traffic to the stock exchange web servers which can't cope. Presumably, this particular DDoS attack does not fit the profile of the attacks that RedShield is designed to block, in other words RedShield is patently not preventing the DDoS.I don't know whether RedShield is supposed to block DDoS traffic and is failing to do so, or if DDoS protection is simply not part of the RedShield service. Either way, it appears a DDoS attack is causing business impacts. |
Guideline | ||
|
2020-08-27 18:50:44 | NBlog Aug 27 - creative teamwork post-lockdown (lien direct) |  A couple of days ago I blogged about MURAL, just one of many creative tools supporting collaborative working. If you missed it, please catch up and contemplate about how you might use tools such as that right now for teamworking during the COVID19 lockdowns.Today I've been thinking about 'the new normal' as the world emerges from the pandemic, inspired by the intersection of two threads.Firstly, thanks to a Zoom session with participants and presenters from Queensland, I've been reading-up on "industry 4.0". I'm not totally au fait with it yet but as I see it the key distinguishing features are:Ever-increasing automation of manufacturing, with smart devices and robotics supplementing the capabilities of both manual and knowledge workers;Industrial IoT, coupling sensors and actuators on the production line with each other, allowing workers to interact with the machinery through screens and keyboards etc. and a growing layer of automation smarts and networking;Ever-increasing reliance on IT, data, analytics, systems and artificial intelligence (with implications for risk, resilience, reliability and security);New capabilities, particularly in the specification and design areas - such as virtual reality simulations and rapid prototyping of jigs, machines and products by "additive manufacturing" (industrial 3D printers);An increasing focus on adding value through knowledge work in research and development plus product service/support, de-emphasising the manufacturing production core activities (which, I guess, started with the off-shoring of manufacturing to low-wage economies, and is now leading to both on- and off-shore automated manufacturing); Rapid innovation and change, leading to difficulties in strategic corporate planning (with credible planning horizons falling to just a couple of years!) and personal career planning (e.g. how can workers learn to use tools and techniques that either aren't refined enough to be taught, perhaps not even invented yet?);Shortages of people with the requisite skills, knowledge and adaptability, able to thrive despite the challenges and seize opportunities as they arise. |
Guideline | ||
|
2020-08-26 12:41:58 | NBlog Aug 23 - ISMS comms plan (lien direct) |  Yesterday I started preparing an ISMS communications plan to satisfy ISO/IEC 27001:2013 clause 7.4, with a little help from the Web.Naturally I started out with the standard itself. Clause 7.4 doesn't literally demand that organisations must have a "communications plan" as such, otherwise it would have been one of the mandatory documents included in SecAware ISMS Launchpad. Oh no, it's more circumspect: the standard says "the organization shall determine the need for internal and external communications relevant to the information security management system" ... and proceeds to outline - yes, you guessed it - a "communications plan".ISO/IEC 27003:2017 confirms our assessment by stating explicitly:"Documented information on this activity and its outcome is mandatory only in the form and to the extent the organization determines as necessary for the effectiveness of its management system". In other words, a documented comms plan is discretionary - advised as good practice but not strictly demanded of every organisation for '27001 compliance certification.Well anyway, let's do it! To comply with the standard, what should typically be communicated in respect of the ISMS, when, to and by whom, and by what means?ISO/IEC 27003 offers examples of the things that should be communicated:Information security policies and procedures, plus changes thereto;[The organisation's] Information [risk and] security objectives;Knowledge on information security risks; Requirement |
|||
|
2020-08-26 12:38:57 | NBlog Aug 26 - ISMS templates (lien direct) | Systematically checking through ISO/IEC 27001:2013 for all the documentation requirements is an interesting exercise. Some documents are identified explicitly in the standard and are clearly mandatory, while many others are only noted in passing, often in ambiguous terms or merely alluded-to ... which can make it tricky to both comply with the standard and persuade the certification auditors of that.Here's an example, one of the document templates from SecAware ISMS Launchpad: That succinct one-pager addresses two requirements from the standard:Clause 9.2 (c) says (in part) "The organisation shall plan, establish, implement and maintain an audit programme(s)" - an explicit documentation requirement that the certification auditors will definitely check for compliance;Clause 9.3 says (in part) "Top management shall review the organization's information security management system at planned intervals to ensure its continuity suitability, adequacy and effectiveness." - an implicit documentation requirement that the certification auditors will probably check for compliance, and although the standard doesn't literally demand it, they may well insist on seeing written evidence that management reviews have been planned.Those clauses lay out fairly succinctly what it means to internally audit or management review the ISMS: I have interpreted the requirements in terms of activities that might be performed quarterly over two years as shown on the schedule, with brief descriptions about the approaches to be taken ... but, as with all the SecAware materials, they are merely generic suggestions that customers are encouraged to adapt. Large, mature organisations with Internal Audit functions, for instance, may well engage them to plan and perform the ISMS internal audits using their conventional audit approach and whatever associated documentation they normally produce. They may prefer to audit the ISMS just once during the three year certification cycle, or conversely they may want to focus on a series of specific areas of risk and concern over successive audits, perhaps integrating the ISMS audit work with other IT, risk, cybersecurity or complian |
|||
|
2020-08-21 05:23:45 | NBlog Aug 20 - creative teamwork in lockdown (lien direct) | Inspired by a heads-up from a colleague on LinkeDin, I bumped into MURAL today.MURAL is a 'digital workspace for visual collaboration' by virtual teams. The animated demonstration on their home page caught my beady eye. Here's a static snapshot as a small group of people are busy placing/moving blobs on a graphic, presumably while discussing what they are doing on a parallel channel (e.g. Zoom): | Guideline | ||
|
2020-08-19 19:48:48 | NBlog Aug 19 - IAAC Directors\' Guides (lien direct) |  Some time back I bumped into a handy management guide on information risk - a double-sided leaflet from the Information Assurance Advisory Council. In 2015, it inspired a security awareness briefing explaining that colourful process diagram, which has now morphed into a further 5-page briefing on Information Risk Management, soon to join the SecAware ISMS templates.Googling for the IAAC guide led me to a cluster of FREE Directors' Guides from the IAAC offering useful, relevant guidance for senior management:Why Information Risk is a Board Level Issue - is a backgrounder including this apt and succinct explanation:"Information Risk encompasses all the challenges that result from an organisation's need to control and protect its information."Governance and Structures - describes directors' governance responsibilities relating to information risk:"Directors need to put in place the arrangements and processes by which responsibilities are distributed and significant information risk decisions are to be made and reviewed."Information Risk Management Approach - encourages directors to support the remainder of the organisation in fulfilling their responsibilities for information risk, ensuring strategic alignment between risk management and business objectives.Realising the Benefits - outlines the business benefits of good information risk management in terms of: efficiency; agility; manageability; exploitation of new opportunities (more confidently expanding into new areas of business); customer retention; brand strengthening; cost-efficient compliance; and dealing efficiently with incidents."Good information risk mitigation supports organisational strategies and tactical agil |
Studies Guideline | ||
|
2020-08-13 06:05:41 | NBlog Aug 13 - Google customers phishing (lien direct) | We're seeing a steady stream of 'update your email'-type crude phishers along these lines: I have lightly redacted the URL, but those action buttons are clearly not pointing to an IsecT domain. Firebase Storage is a Google cloud storage/app service: Google promotes Firebase security in terms of high availability and authentication for their customers i.e. web developers using Firebase to host content on the web. No mention of security for their customers' victims though and although Google can't be held entirely responsible for its customers' nefarious activities, I presume (hope!) they have the processes in place to identify and respond efficiently to incidents of this nature.I've reported this incident through a Firebase customer support channel as there is no obvious way for us to report misuse of their services by phishers etc.I'll let you know how they respond. |
|||
|
2020-08-10 11:44:49 | NBlog Aug 8 - musing on ISO/IEC 27014 & infosec governance (lien direct) |  This morning I've been studying the final draft of the forthcoming second edition of ISO/IEC 27014 "Governance of information security", partly to update ISO27001security.com but mostly out of my fascination with the topic.Section 8.2.5 of the standard specifies the governance objective to "Foster a security-positive culture":"Governance of information security should be built upon entity culture, including the evolving needs of all the interested parties, since human behaviour is one of the fundamental elements to support the appropriate level of information security. If not adequately coordinated, the objectives, roles, responsibilities and resources can conflict with each other, resulting in the failure to meet any objectives. Therefore, harmonisation and concerted orientation between the various interested parties is very important. To establish a positive information security culture, top management should require, promote and support coordination of interested party activities to achieve a coherent direction for information security. This will support the delivery of security education, training and awareness programs. Information security responsibilities should be integrated into the roles of staff and other parties, and they should support the success of each ISMS by taking on these responsibilities."Not bad that although, personally, I would have mentioned senior management setting 'the tone at the top', in other words influencing the entire corporate culture through their leadership, decisions, direction and control, particularly in the way they behave.For example, even though management may formally insist upon ethical behaviour as a policy matter, if managers in fact act unethically, push the boundaries of ethicality through their decisions and priorities, or simply tolerate (turn a blind eye to, fail to address) unethical/dubious activities, that can severely erode if not destroy the value of the policy. Workers observant enough to spot the disconnect between theory and practice are, in effect, enabled or even encouraged to decide for themselves whether to comply with the policy. In a disciplinary situation, management's failure to enforce compliance with |
Guideline | ||
|
2020-08-10 11:41:46 | NBlog Aug 7 - what is operational resilience (lien direct) |  Seeing the term 'operational resilience' being bandied about right now, I thought I'd take a closer look, starting with the definitions.So what is 'operational resilience'? It is:"a set of techniques that allow people, processes and informational systems to adapt to changing patterns. It is the ability to alter operations in the face of changing business conditions. Operationally resilient enterprises have the organizational competencies to ramp up or slow down operations in a way that provides a competitive edge and enables quick and local process modification." says Gartner."both a process and a characteristic of an organization to adapt rapidly to changing environments and needs. It is an organizational trait that allows it to carry out its mission or business despite the presence of operational stress and disruption. In other words, it is the organization's ability to handle and control external factors that may hinder it from functioning." says Techopedia."financial resilience" says Accenture (begging the question: What is financial resilience?)."the ability of firms and the financial sector as a whole to prevent, adapt, respond to, recover, and learn from operational disruptions" says the Bank of England."the ability of an organisation to adapt rapidly to changing environments. This includes both the resilience of systems and processes and more generally the ability of the organisation to continue to operate its business in the event of disruptive events." says KPMG.... and so on.Some commentators focus on specific aspects that interest or concern them - financial stability for example, and systemic failure of highly integrated and interdependent industries. |
|||
|
2020-08-07 16:05:08 | NBlog July 23 - infosec roles & responsibilities (lien direct) |  For the next phase of SecAware ISMS, I'm documenting the management process for determining and allocating information risk and security responsibilities. The procedure itself is straightforward - just one page of written instructions covering a simple four step process - but a raft of examples of the activities various functions perform in relation to information risk and security takes it up to six pages, even though the examples are presented tersely as bullet points.It turns out there may be several corporate functions, teams and individuals, each performing numerous activities relating to information risk and security. Admittedly, my knowledge in this area has accumulated in the course of working mostly for large, relatively mature organisations, a couple of which had all of the functions staffed by professionals busily performing virtually all of the activities. Small-to-medium sized organisations don't have the luxury of being able to carve-up the work among dedicated teams of specialists, so they usually get by with multi-tasking and perhaps assistance from third parties. Information risk and security is tougher for micro-organisations, particularly if they don't even have anyone who appreciates the need to manage information risk and security, privacy, compliance, business continuity etc. The ISO27k framework can help all types and sizes of organization provided it is interpreted and applied sensibly according to the business context and needs. Even though a multinational bank, say, might have specialists within HR and other functions whose job it is to prepare job descriptions, vacancy notices, training plans etc., our generic list of information risk and security activities may be a useful prompt to confirm that they have all the bases covered. A micro-company will not need to perform every listed activity, and will have no choice but to concentrate on the few that matter most. Either way, the process of management deciding what the necessary activities should involve and, where appropriate, assigning responsibilities to the relevant workers, corporate functions or third parties, is much the same and hence worth laying out in a generic procedure.As I'm drafting the procedure, I'm itching to mention related aspects such as governance, accountability, access cont |
|||
|
2020-07-31 08:58:07 | NBlog July 31 - who\'s for a Pimms? (lien direct) |  Within a year or so, organisations will be able to have their Privacy Information Management Systems certified compliant with ISO/IEC 27701, thanks to a new accreditation standard ISO/IEC TS 27006 part 2, currently in draft.A PIMS is very similar to an Information Security Management System, hence compliance auditing and certification are also very similar – so much so that I've heard some certification bodies are already taking the initiative by issuing PIMS certificates despite their not being formally accredited for that.Potentially, a PIMS certificate may become the generally-accepted means of demonstrating an organisation's due care over privacy and personal data protection – a way to assure data subjects, business partners, the authorities and courts that they have, in fact, adopted good privacy practices. A PIMS should materially reduce an organisation's risk of suffering privacy breaches. However, as with an ISMS, 'materially reduce' is not quite the same as 'eliminate'. In the less likely event that a privacy breach occurs, despite having a PIMS, compliance certificates for the organisation and if appropriate its information service suppliers (e.g. cloud or marketing services) may be a credible part of the organisation's legal defence against prosecution under GDPR or other privacy laws and regs, but they would still need to explain why the breach occurred and what they have fixed to prevent a recurrence. The PIMS should at least structure the response to the breach, including corrective actions addressing the root causes, hence there should be something substantial behind the usual vacuous PR statements about 'taking this matter very seriously'. |
|||
|
2020-07-29 14:10:44 | NBlog July 29 - boost your ISO27k ISMS with SecAware Take-off (lien direct) |  SecAware ISMS Launchpad comprises a set of templates for the mandatory documentation that every compliant Information Security Management System must have: a basic ISMS strategy, scope, Statement of Applicability, Risk Treatment Plan, information security policy, that sort of thing. If your organisations only needs an ISO/IEC 27001 certificate, this tidy stack of templates forms a stable, compliant platform from which to launch your ISMS. For a paltry $99, download Launchpad and get started today!Hot on its tail, today we announce the next phase of our mission to convince every organisation to manage its information risks properly.If your organisation sees the value in going a little beyond the bare minimum, SecAware ISMS Take-off takes you to the next stage. Take-off provides all of these: The Take-off materials primarily concern management. An ISO27k ISMS is, after all, a management system.Template #2 "Strategic objectives for information risk and security management" for instance specifies:"Enhance and protect the value of information by ensuring adequate confidentiality, integrity and availability""Manage (i.e. identify, evaluate, treat and monitor) information risks cost-effectively and competently" ... plus four other key objectives. It also lays out four n |
|||
|
2020-07-28 13:38:59 | NBlog July 28 - an interesting risk metric (lien direct) |  We were chatting over coffee this morning about an organisation that is recruiting at the moment. Having been through the cycle of advertising, preselecting/long-listing, interviewing and short-listing candidates, their references came back negative, forcing the organisation to reboot the recruitment process.On the one hand, that's a disappointing and somewhat costly outcome. It suggests, perhaps, that the preselection and interviewing steps could be tightened up. Were there warning signs - yellow or red flags that could/should have been spotted earlier in the process?On the other, it also indicates that the selection/recruitment process is effectively identifying and weeding-out unsuitable applicants, avoiding what could have turned out to be even costlier incidents down the line if the appointments had been made and the new recruits had turned out to be unsuitable.So, Proportion of shortlisted candidates rejected as a result of poor references is one of several possible measures of the recruitment process, with implications for risks and opportunities, costs and benefits. Very high or low values of the metric, or adverse trends, or sudden changes, may all be cause for concern and worthy of investigation, whereas middling, "neutral" values are to be expected.The metric probably wouldn't have even occurred to me except that I happen to be documenting information security controls for joiners, movers and leavers at the moment for the next phase of SecAware ISMS templates. Information risks should be taken into account during the recruitment process. Confirming applicants' identities, taking up references, confirming employment histories and qualifications on their CVs, and running other background checks (e.g. for criminal records or credit issues) can be important controls if legally permissible, especially for appointments trusted roles - and, by the way, that includes internal transfers and promotions as well as new recruits. |
To see everything:
Our RSS (filtrered)
