The Information Security Leadership Forum is proud to annouce our new ISO 42001 Lead Implementer - Artificial Intelligence Management System Course, debuing in Ottawa, Ontario, Canada September 16 - 22, 2024.

With the proliferation of Artificial Intelligence based systems, the International Organization for Standardization or more commonly known as ISO, has publised the first international standard on the topic of Artificial Intelligence. The ISLF is currently translating this standard into a 5 day certification course, the first session for which can be accessed by clicking here.

Introduction

On Wednesday October 26^th, 2022, International Organization for Standardization (ISO) released the long-awaited revised edition of the ISO 27001 standard. In general, the new version is a bit of a letdown, with few material changes other than those in Annex A, which we previewed in February’s release of ISO 27002: 2022, the new guide for the implementation of the ISO 27001 standard.

This article is intended for ISO 27001 practitioners familiar with, and actively using the ISO 27001 standard to build or operate an information security management system (ISMS). It has been written to help the audience quickly understand what changes are in the 2022 version of the standard, from its previous 2013 release, without having to do the line-by-line review that was done to prepare this article for you. It will make more sense to you if you have a copy of the standard on hand while reading through the detailed analysis provided below, but is not necessary. This article should not be considered a primer on the standard, as it only highlights changes. As Clauses 2 and 3 of the standard are administrative only, these areas are not addressed by this article.

If during your review of the article, you find any inaccuracies or erroneous information, kindly leave us a note and we will review and amend the article to ensure it remains an invaluable resource for others. Please note, comments to articles on the Information Security Leadership Forum are restricted to members of the Forum. This was implemented to avoid SPAM and the added overhead of moderating such content. If you are not a member of the Forum and wish to communicate an observation, please feel free to use the contact form here.

Clause 3 – Terms and Definitions

What’s the Same

Terminology reference document remains as ISO 27000. At the time of publication of this article ISO 27000’s current release is 2018.

What’s Different

Added links to online resources for ISO & IEC terminology database, where a visitor can do a search by word.

Clause 4 – Context of the Organization

4.1 Understanding the organization and its context

What’s the Same

The control heading remains the same and the control has not changed.

What’s Different

Replaced the referenced to ISO 31000 from the 2009 to the 2018 publication release.

4.2 Understanding the needs and expectations of interested parties

What’s the Same

The control heading remains the same. The wording of control 4.1 remain exactly the same.

What’s Different

The wording of the control 4.2 is reworded generalizing removing the specific focus “relevant to information security.” Essentially, they have taken this portion and created a new subsection “c”

The new 4.2 c) mandates identifying which of the requirements of the identified interested parties will be addressed in the organization’s Information Security Management System (ISMS).

4.3 Determining the Scope of the ISMS

What’s the Same

The complete text remains unchanged.

What’s Different

There are not changes to this subsection.

4.4 Information Security Management System

What’s the Same

The general context of the control remains the same.

What’s Different

The control has added a qualification or, called out that “processes needed and their interactions,” need for the ISMS must also be established, implemented, maintained, and continually improved upon.

Clause 5 – Leadership

5.1 Leadership & Commitment

What’s the Same

The control heading and content remains the same.

What’s Different

Added a qualifying note at the bottom of the control, giving reference to the interpretation of the word “business.”

5.2 Policy

What’s the Same

The control heading and content remains the same.

What’s Different

No changes were identified.

5.3 Organizational Roles, Responsibilities and Authorities

What’s the Same

The control heading remains the same.

What’s Different

The wording of the opening sentence of the control includes a new qualifier, “within the organization.”

In 5.3 a) an insignificant change that changed the reference to “this International Standard” to a more generic statement of “this document.”

In the control “NOTE” text, they have changed the statement from “may” to “can,” which presumably is to conform to revised terminology or more appropriately align with existing official terminology definitions. There does not appear to be any material impact result from this change.

Clause 6 – Planning

6.1 Actions to Address Risks and Opportunities

What’s the Same

The control heading and content for subsection 6.1.1, and 6.1.2 remains the same. The general contents of subsection 6.1.3 also remain materially consistent, with the exceptions noted below.

What’s Different

The “NOTE”s in subsection 6.1.3 have had some revision, as follows:

• Formerly the first note under 6.1.3 b) was not numbered, however in the new version it has been assigned “NOTE 1,” however its contents remain the same.
• Notes 1 and 2 under 6.1.3 c) have been renumbered to “NOTE 2” and “NOTE 3,” respectively.
• NOTE 3 in the new version has been revised with the qualification that:
• The focus is not on “control objectives” but rather “controls” from Annex A of the standard.
• The reference to control objectives being implicitly included in controls chosen from Annex A, has been removed. This change does not appear to have any material impact.

Subsection 6.1.3 d) has restructured the content of the control’s wording into bullet points, however no material change has resulted from this.

The final note (“NOTE 4”) in the new version, again changes the language “in this International Standard” to “in this document.” No material impact has resulted from this change.

6.2 Information Security Objectives and Planning to Achieve Them

What’s the Same

The control heading and content for 6.2 remains generally consistent with the exception of those noted below.

What’s Different

Two new qualifying requirements have been added in the 2022 version (“Edition 3”) in subsection 6.2, and has been inserted at 6.2 d) and 6.2 g).  All other requirements under 6.2 have remained intact, and simply reordered.

The new 6.2 d) mandates information security objectives must be “monitored.”

The new 6.2 g) mandates the objectives must be available as documented information. It is unclear if this was an oversight or why they added this, as the immediately following sentence states, “the organization shall retain documented information on the information security objectives,” which sounds the same.

6.3 Planning Changes

What’s the Same

Nothing … this subsection is new.

What’s Different

Subsection 6.3 is brand new to clause 6. In the new one sentence control, it mandates changes required of the ISMS must be done in a planned approach.  The inference here is that in addition to proper planning when implementing an ISMS, it requires an organization when making changes to an established ISMS, the changes must similarly be planned. One of the keys to ISO controls is to document and retained the planning documentation as an ISMS record (audit artifact or evidence of having performed it). It is unclear based on the writing in the new version of the standard, why the committee did not perceive this to have already been covered under clause 8.1

Clause 7 – Support

7.1 Resources

What’s the Same

The control heading and content for subsection 7.1 remains the same.

What’s Different

There have been no changes in this subsection.

7.2 Competence

What’s the Same

The control heading and content for subsection 7.2 remains the same.

What’s Different

There have been no changes in this subsection.

7.3 Awareness

What’s the Same

The control heading and content for subsection 7.3 remains the same.

What’s Different

There have been no changes in this subsection.

7.4 Communication

What’s the Same

The opening sentence and sub-subsections 7.4 a), and b), and C) are consistent, reflecting no changes.

What’s Different

In 7.4 d) and e) which previously offered “who shall communicate” and “the process by which communication shall be effected,” has been consolidated into one new 7.4 d) mandating the organization must also determine “how to communicate.”

7.5 Documented Information

What’s the Same

The control heading and content for 7.5 remains generally consistent with the exception of those noted below.

What’s Different

The subsection opens with a general housekeeping change in 7.5 a) with the wording “… by this International Standard,” which is generalized in the new version worded, “… by this document.”  Subsection 7.5.3 makes a similar amendment in the opening sentence.

Clause 8 – Operation

8.1 Operational Planning and Control

What’s the Same

The control heading and content for 8.1 remains generally consistent with the exception of those noted below.

What’s Different

Paragraph One

Changes in this clause begin in the opening sentence of 8.1 where it removes the qualifying text “… to meet information security requirements, …” and leaves it with only “… to meet requirements …, suggestive that it may have broadened expectations outside of solely information security requirements. As this sentence continues, ISO has also generalized in the new version “… requirements, and to implement the actions determined in Clause 6 ...,” which essentially summarized what it was saying the in previous version in less words.

This paragraph in the new version, now offers two new qualifying bullets mandating the requirement to establish criteria, and implement control of processes in accordance with the criteria.

Paragraph Two

The changes to this paragraph appears to be cosmetic as it is merely a rewording of the opening of the sentence from, “The organization shall keep documented information … “ to “Documented information shall be available …”

Paragraph Four

This is another one sentence area, which has had significant qualifying requirements added into the new version. Specifically, the 2013 version generally stated that “outsourced processes” be determined and controlled. It did not delineate one outsourced business process from another. Under the 2022 version it now offers “eternally provided processes, products or services that are relevant to the information security management system are controlled.” While I think these represent potentially needed qualifications rolled into this one sentence, I still see the possibility for the open interpretation or subjectiveness of what “relevant to the information security management system” means. Presumably this refers to, within the scope of the ISMS.

8.2 Information Security Risk Assessment

What’s the Same

The control heading and content for subsection 8.2 remains the same.

What’s Different

There have been no changes in this subsection.

8.3 Information Security Risk Treatment

What’s the Same

The control heading and content for subsection 8.3 remains the same.

What’s Different

There have been no changes in this subsection.

Clause 9 – Performance Evaluation

9.1 Monitoring, Measurement, Analysis and Evaluation

Paragraph One

What’s the Same

The control heading and content for 9.1 remains generally consistent with the exception of those noted below.

What’s Different

The opening, one sentence paragraph has been removed leaving no qualifying opening to the second paragraph, which reads, “the organization shall determine: ...” before going into a bulleted list of six specific requirements. Other than the heading, it does appear a bit odd not to have that qualifying requirements before going into the bulleted requirements. So, did they throw this out or do something else with it? If you look to the end of 9.1, you will find that they have moved it verbatim to the end.

In 9.1 b) they have moved the contents of the “NOTE” into the body of the bullet, so clearly only a cosmetic change.

Paragraph Two

In this single sentence 2^nd paragraph, it is net new to the subsection, however mandating documented information be retained as evidence should not be a surprise to anyone who lives in an ISO standards world. I find it even more perplexing why ISO feels it relevant to only specifically mandate it here and there, where ISO audits are designed and appropriately so, as evidence-based audits. To be clearer, ISO should consider incorporating this into clause 7.5.3 as a general requirement.

9.2 Internal Audit

In the 2013 version of the standard, 9.2 was one consolidated topic with seven bulleted requirements (“a)” through “g)”), which has been broken into two area in the 2022 release. The bullets “a)” through “b)” inclusive are now in 9.2.1, whereas “c)” through “g)” are now in 9.2.2. Below are the changes noted in these new numbered areas.

9.2.1 General

What’s the Same

The control content for bullets “a)” through “b)” remains the same.

What’s Different

There have been no changes in this subsection.

9.2.2 Internal Audit Programme

What’s the Same

The control content for bullets “c)” through “g)” remains the same.

What’s Different

The contents of bullet “c)” has been restructured into an opening paragraph to 9.2.2.

The contents of bullet “g)” have been restructured as a closing paragraph with minor editorial changes that do not materially affect the control statement. This is another example where ISO could have been a little more efficient by centralizing the requirement under 7.5.3, as this is yet another statement that documented information must be retained.

9.3 Management Review

Similar to the previous control area, clause 9.3 had everything under one area, and has broken into three (3) sections as provided below, in its 2022 version.

9.3.1 General

What’s the Same

The opening sentence of the old version has been migrated into this area; however, the text has remained consistent.

What’s Different

As 9.3.1 is net new, there are no changes per se.

9.3.2 Management Review Inputs

What’s the Same

The control content for bullets “a)” through “b)” have been migrated into this area, but have remains the same.

What’s Different

Bullets “c)”  through “f)” have been migrated to 9.3.2, with no change to the content of the text, however they have been bumped down the line to become bullets “d)”  through “g)” in the 2022 version.

A new bullet has been introduced as the new “c)” mandating, “changes in the needs and expectations of interested parties …” relevant to the ISMS shall be reviewed. This one could be a material change, especially to organization’s that focused not on setting up a comprehensive ISMS, but rather focusing on meeting minimum necessary only. In the past, the minimum necessary might have been seen as only having to understand interested parties needs and expectations at the beginning, whereas this change suggests an ongoing need to solicit, and assess for changes in the needs and expectations of interested parties.

9.3.3 Management Review Results

What’s the Same

The last two paragraphs have been moved into this new sub area, with only cosmetic changes to the text. Specifically, in the second last paragraph it previously opened, with “the output of the management review …” and changed to “the results of the management review …”

What’s Different

As 9.3.3 is net new, there are no changes per se.

Clause 10 – Improvement

In the 2022 version they flipped the sub areas upside down, making 10.1 now 10.2, and 10.2 now 10.1 in 2022. This does appear to make sense, as this change now give clause 10 a qualified opening.

10.1 Continual Improvement

What’s the Same

The control content imported from 20.2 of the 2013 version and is now referenced as 10.1 remains the same.

What’s Different

Nothing.

10.2 Nonconformity and Corrective Action

What’s the Same

The control content imported from 20.1 of the 2013 version and is now referenced as 10.2 remains materially the same, with the exception noted below.

What’s Different

In the qualifying statement opening for bullets “f)” and “g)”  the previous version opened with “the organization shall retain documented as evidence of: …” and has been reworded in the 2022 version to state, “documented information shall be available as evidence of: …”

Annex A

Annex A is really where there have been a number of material changes. That said, the majority of Annex A has remained the same.

For a high-level overview of the changes here, please read our article entitled, “ISO 27002: 2022 - What Has Changed,” published on our site in March 2022.

Closing

If you are planning to implement the standard, or are supporting an organization already ISO 27001 certified, and need to better understand the full requirements, consider taking the Forum’s 5-day ISO 27001 Lead Implementer or Lead Auditor courses. By training with the Forum, you’re not just taking training, your support an institution that we’re building together to make training accessible by keeping costs down, as well as promoting the development of new practice models and methodologies.

The New ISO 27002 Is Finally Here 

The new revision of ISO 27002 was published on February 15th, 2022 and there are some major changes from the 2nd edition released in 2013 that you should be aware of.  The main focus of this revision was to improve the guidance for implementation of ISO 27001 Annex A controls.   

This won’t be the only ISO standard revised this year, as ISO is expected to release a new version of ISO 27001 soon. 

* UPDATE (June 12, 2023): for a detailed breakdown of changes in Clauses 4 through 10 of ISO 27001 in the 2022 release, please see our earlier article entitled, "ISO 27001: 2022 - A Detailed Summary of Change from 2013 to 2022 Version?"

What Changed? 

The number of controls has been reduced from 114 to 93, and they’re now organized in 4 categories.  These categories are: 

• Organizational controls (Clause 5) 

• People controls (Clause 6) 
  

• Physical controls (Clause 7) 

• Technological Controls (Clause 8)
  

The new categorization will help organizations determine the applicability of the controls along with determining who or what department is responsible for the control. 

The controls in ISO 27002 now also have attributes designated to each control.  These new attributes are: 

• Control types: Preventive, Detective, and Corrective 

• Information security properties: Confidentiality, Integrity, and Availability 

• Cybersecurity concepts: Identify, Protect, Detect, Respond, and Recover 

• Operational capabilities: Governance, Asset management, Information protection, Human resource security, Physical security, System and network security, Application security, Secure configuration, Identity and access management, Threat and vulnerability management, Continuity, Supplier relationships security, Legal and compliance, Information security event management, and Information security assurance 

• Security domains: Governance and ecosystem, Protection, Defense, and Resilience 

This brings ISO 27002, and 27001: 2022, upon its release later this year, more in line with other cybersecurity frameworks like NIST.  

The correlation of controls between the different frameworks can be a headache for organizations.  The addition of attributes to the 27002 controls will make correlating the controls a bit easier. 

New Controls 

There are 12 new controls in the standard, a result of the ever changing InfoSec environment, technology, and practice. Many of these controls reflect the expected addition of personal information (PI) and personally identifiable information (PII) as an information asset under the new 27001 revision. 

Controls that Have Been Deprecated

While some of the controls have been merged, 16 controls have been removed from the newest version of the standard.  These are:

•   5.1.2 – Review of InfoSec policies 
•   6.2.1 – Mobile device policy 
•   8.1.2 – Owndership of assets 
•   8.2.3 – Handling of assets 
•   9.4.3 – Password management system 
• 11.1.6 – Delivery and loading areas 
• 11.2.5 – Removal of assets 
• 11.2.8 – Unattended user equipment 
• 12.4.2 – Protection of log information 
• 12.6.2 – Restrictions on software installation 
• 13.2.3 – Electronic messaging 
• 14.1.2 – Securing application services on public networks 
• 14.1.3 – Protecting application services transactions 
• 14.2.9 – System acceptance testing 
• 16.1.3 – Reporting InfoSec weaknesses 
• 18.2.3 – Technical compliance review

The last control, Technical compliance review, has been split into two controls: 5.36 – Conformance with policies, rules, and standards for information security and 8.8 – Management of technical vulnerabilities. 

What Does This Mean For ISO Security Practitioners? 

The biggest impact is in your organization’s risk treatment and risk register.  When the new ISO 27001 Annex A is released, it will be imperative that your organization review your risk treatment, review and realign the controls in you Statement of Applicability, and update or even create policies, processes, and procedures for the new controls. 

Organizations already certified, will have to certify to the new ISO 27001 standard within 2 years of release.  This gives organizations time to review, revise, and improve their Information Security Management Ssystem (ISMS) before having to seek recertification by 2024.  

Questions For You!

What are your thoughts on this topic?

Is ISO going in the right direction by reducing the volume of controls?

What do you see as the next steps forward?

Do you have any unique insights on where ISO security is going that you'd like to share with other readers?

If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.

Crypto Exchanges and NFTs - Is This the New Dot Com Bubble?

Crypto Exchanges and NFTs - You can’t go too far in a day online without finding someone talking about either crypto currencies or Non-Fungible Tokens (NFT). Whether it is on social media or financial news programs, it seems like these two topics are all people is talking about. If you watched this year’s Superbowl.

One of the most talked about was the ad for Coinbase, which was simply a QR code floating on the screen. So many people scanned the code, they crashed the Coinbase servers.                    

Sidenote – millions of people mindlessly scanned a QR code on their TV screen was a big topic of discussion on infosec driven social media accounts, with most people in a state of disbelief that the public would do such a thing.

There is a feeling of manufactured urgency over the crypto market, like the Dot Com bubble of the 1990s. Crypto, once the exclusive playground of nerds and hackers, is now being flooded with celebrity endorsers and Instagram influencers.    

With notoriety and popularity comes bad apples looking to take advantage of people and, more to the point, they are coming to steal your investment by hacking the Crypto exchanges.

NFTs are on the same trajectory. An NFT is a digital asset that represents real-world objects like art, music, in-game items, and videos. They are bought and sold online, frequently with cryptocurrency, and they are generally encoded with the same underlying software as many cryptos.  NFTs, like cryptocurrency, have been around for nearly a decade but only recently have been gaining popularity. Over $174 million has been spent on buying, selling, and trading NFTs since 2017.

When “Secure” is not Secure

 Some analysts see that the rise of crypto exchanges and NFT marketplaces have more to do with the “Fear of missing out” (FOMO) than about investing for the future. It is also inevitable that the more of these websites that exist, the bigger target they are for hackers and other malicious actors.

In 2021, hackers went after crypto exchanges with a vengeance. The five biggest crypto hacks of 2021 were:

1. Poly Network - $611 Million
2. BitMart - $196 Million
3. Cream Finance - $148 Million
4. Vulcan Forged - $140 Million
5. Badger Finance - $120 Million

That is over $1.2 BILLION stolen by hackers in just those five hacks alone. In 2021, there were more than twenty exchange hacks where over $10 million was stolen.

NFT market places are not faring any better. In January:

• $2.2 million worth of NFTs were stolen from Todd Kramer in the “Bored Ape” hack.
• A hacker exploited a vulnerability in Open Sea, the largest NFT marketplace, which allowed them to buy already owned NFTs at their previous lower prices and then turn around and sell them for vastly higher prices, defrauding the legitimate asset owners.

And in February, FortiGuard released a notification that NFTs are being utilized to distribute the BitRAT malware.

And these are just the incidents that have been reported. Crypto exchanges and NFT marketplaces are often hesitant to notify the public of an attack for fear of the reputational and financial damage the news could bring.

Hackers Jump on The Trend

Unfortunately, as crypto and NFTs become increasingly “trendy” and more and more celebrities are pushing investment in these markets, hackers will have an endless supply of easy targets. People eager to get into these markets will often do so without ensuring that they, their systems, and the markets/wallets they utilize are as secure as can be. With the rise of end users being targeted with spear phishing attacks, expect the number of hacks to only increase over the next few years.

Questions For You!

Where do you see things going in the future?

Are you aware of someone you know directly that has been affected by this? If so, do you have any insights you'd like to share on the topic?

What are your thoughts on the future of cryptocurrency and NFTs, as it relates to hackers continuing to target them?

What needs to happen, if anything, to address this growing concern?

If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.

With the explosive growth of internet connected medical devices, hackers are targeting healthcare companies. As a result the industry and companies in it are quickly becoming a high priority target for hackers and ransomware attacks.  In 2020, according to industry statistics, healthcare companies experienced a 71% increase in security breaches and incidents and a 45% increase in ransomware attacks.  Overall, more than 1 in 3 health care companies reported being the victim of a ransomware attack. 

It’s no surprise that personal information is regularly bought and sold on the dark web.  Industry experts identified the average selling price for personal information, such as social security numbers sold for about fifty cents, while a health care record sold for over $250. Given that math, it is apparent why a database of client records might be more valuable to a hacker selling on the black market over your social security number.

Hackers are also finding that hospitals are more likely to pay ransoms because they cannot afford to be unable to operate for even a few hours.  They’re also finding many entry points into hospital systems through internet connected medical devices.  In the US, there can be anywhere from 10-15 internet connected devices per hospital bed, meaning hackers have multiple modes of attack. 

The large number of Internet connected devices also puts patients at risk.  Just a few years ago, Abbot Laboratories was forced to recall some 500,000 pacemakers due to security vulnerabilities. 

What Does This Mean? 

Despite HIPAA and HITECT regulations, healthcare companies continue to be challenged with implementing sound and holistic security.  This includes everything from major hospitals to local doctor’s offices.  No healthcare company is too small a target for hackers. 

It also means that governments should be stepping up their cybersecurity rules and regulations for partner healthcare companies. 

If you’re a health care company, you should be looking to upgrade your security posture in order to protect not only Protected Health Information (PHI), but also the lives of those patients. 

Questions for You!

What are your thought on this topic?

Do you have any special insights on this topic that you'd like to share?

What needs to happen and by whom for this to be in our past?

If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.

In March 2022, the Payment Card Industry Security Standards Council (PCI SSC) issued the newest edition, version 4.0, of the Payment Card Industry Data Security Standard (PCI DSS). The latest revision is a modernization of the standard to address emerging threats, include new security technologies, and provide an overhaul and upgrade of the standard. PCI DSS v4.0 is also intended to allow organizations more flexibility in the methods used to meet their security goals. 

What is PCI DSS? 

PCI DSS is a security standard for organizations that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Cardholder data and sensitive authentication data are defined as follows:

PCI DSS is a security standard for organizations that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Cardholder data and sensitive authentication data are defined as follows:

PCI DSS also applies to an organization’s cardholder data environment (CDE), particularly if they transmit an account holder’s PAN by itself or with other CDH, such as cardholder name and/or expiration date. 

Changes to PCI DSS 

Since the publication of the previous version, v3.2.1, in February 2018 the technology and environment for the payment industry has continued to evolve.  The growth in payment processors, technologies, and the increasing use of cloud service providers necessitated the PCI SSC to look at ways for the standard to be more inclusive, provide clearer guidance, and provide organizations more flexibility in how they protect CDH and SAD. 

The changes in the PCI DSS are classified per the PCI SSC into three specific types: 

• Evolving Requirement – Changes to ensure the standard is up to date with emerging threats and technologies, and changes in the payment industry. 

• Clarification or Guidance – Updates to wording, explanation, definition, additional guidance and/or instruction to increase understanding or provide further information or guidance on a particular topic. 
  

• Structure or Format – Reorganization of content, including combining, separating, and renumbering of requirements to align content. 

All the changes in PCI DSS v4.0 fall into one of these three categories.  The Evolving Requirement category covers the most substantial changes to the standard. 

Flexibility in Implementation 

PCI DSS is introducing a new method of validation known as Customized Implementation. This will allow organizations to implement security solutions that meet the specific PCI DSS objective instead of having to follow the specific methods prescribed by the standard.  This will also free organizations from having to implement compensatory controls that may be a burden on their organization. 

To help implement this, PCI DSS has removed “firewalls” and “routers” in Requirement 1 and replaced them with the broader term “network security controls”. This change means PCI DSS now supports a broader range of security technologies organizations can utilize to meet their security objectives. 

More Stringent Access Controls

PCI DSS v4.0 comes closer in alignment with the National Institute of Standards and Technology (NIST) guidance on digital identities and Identity and Access Management.  The changes in v4.0 include: 

• Multifactor Authentication (MFA) will be required for all accounts that have access to cardholder data, not just administrators. 

• Passwords for accounts used by systems and applications: 

• Must be changed at least ever 12 months or whenever compromise is suspected. 

• Must contain at least 15 characters including alphabetic and numeric characters. These passwords must be compared against the PCI DSS list of known bad passwords. 

• Access reviews must be performed at least every six months 

• Third party accounts may only be enabled as needed and monitored when in use. 

The new standard will also allow for organizations to build their own unique, pluggable authentication solutions. 

Expanding Encryption Requirements

Encryption requirements are being expanded to include all transmission of CHD, including transmissions on trusted networks. The reason behind this change is to counter the rising threat of malware that, once on a system, can exfiltrated CDH through data transmissions. 

In addition, organizations will be required to implement methodologies to locate all sources and locations of cleartext PANs and the data discovery will need to be performed at least annually or upon any significant change to the CDE or processes.

Other Changes 

The PCI DSS is moving towards a more ‘risk based’ framework instead of mandating the controls to be implemented. Organizations will have to evaluate their CDE through a risk assessment model and provide justifications for including, excluding, or customizing the controls they use to meet the objectives of the standard.  This will help ensure organizations are taking an active role in evaluating and upgrading the security posture of their CDEs. 

Security Awareness Training requirements are also being strengthened and expanded to include current threats and vulnerabilities including Phishing and Social Engineering. 

Organizations will also have to document and confirm the accuracy of their PCI DSS scope annually or upon any significant changes to their CDE. For service providers, the requirement for reviewing and confirming their PCI DSS scope will be every three months or upon changes to their CDE. 

Timeline for PCI DSS v4.0 Implementation 

The previous version of PCI DSS (v3.2.1) will remain operational until March 2024, two years after the release of version 4.0. As of March 31, 2024, the previous version will be retired. 

The two year rollout will allow organizations time to understand and implement the changes required by v4.0.  Organizations will need to be compliant with v4.0 by March 31, 2025. 

Sources: 

• PCI Security Standards official website 

• PCI DSS v4.0 

• PCI DSS v4.0 Resource Hub 

• PCI DSS Document Library
  

The United States federal government has been working to bolster cybersecurity protections for Department of Defense (DoD) confidential unclassified information (CUI) handled and stored by companies that are part of the Defense Industrial Base (DIB). The outcome of these efforts has been the creation of the Cybersecurity Maturity Model Certification (CMMC) based on the cybersecurity framework and controls defined in NIST 800-171.

In September 2020, the DoD issued an interim rule through the Defense Federal Acquisition Regulation Supplement (DFARS) which went into effect in November 2020. 

The interim rule informed DoD contractors that CMMC will be the cybersecurity framework relevant to their industry and that they, and their subcontractors, will need to provide self-assessment scores based on NIST 800-171 to the Supplier Performance Risk System (SPRS).

The DoD has planned to finalize the interim rule by December 2022, with CMMC requirements added to procurement contracts by March 2023.

Self-Assessments and SPRS Scores

As part of the CMMC rollout, the DoD introduced two new DFARS clauses, 252.204-7019 and 252.204-7020. DFARS 7019 defines the following requirements for contractors:

• Contractors bidding on new contracts, and options on their current contracts, must continue to continue to perform self-assessments and report their scores to SPRS.
• All contractors who handle CUI must perform at least a basic level assessment using NIST 800-171 assessment methodologies.
• Self-assessments will be scored with a maximum score of 110 based on the 110 controls listed in NIST 800-171.
• Companies may end up with a negative SPRS score because the DoD assessment methodology assigns more than one point to some of the controls.
• SPRS scores must be filed by the time of contract award and maintained throughout the life of the contract.
• Companies that score less than 110 must submit a Plan of Action and Milestones (POAM) detailing the actions and deadlines for remediating cybersecurity gaps detailed in the self-assessment.
• All self-assessments must have been completed within the previous 3 years.

It should be noted that while currently a SPRS score of less than 110 triggers the POAM requirement, when the DoD formalizes and implements CMMC, POAMs will no longer be acceptable for DIB companies bidding on DoD contracts.

DFARS 7020 requires that prime contractors must flow down the DFARS 7019 requirements to all subcontractors and forbids the awarding of contracts to subcontractors if they have not completed a self-assessment and submitted their SPRS score.

The only exception to this rule is in contracts for the acquisition of Commercial Off The Shelf (COTS) items.

CMMC Transition in DFARS 7021

The third change to DFARS is the inclusion of clause 7021, which details the transition from NIST 800-171 to CMMC certification. It further states that both Prime Contractors and Subcontractors must meet the required CMMC certification level by the time of contract award and must maintain the required level of certification throughout the life of the contract.

DoD Audits of Cybersecurity Postures

To demonstrate the importance of meeting cybersecurity requirements, the DoD has begun auditing more defense contractors and randomly reviewing their SPRS scores. This is to ensure that Prime Contractors and Subcontractors are not misrepresenting their cybersecurity posture or SPRS score to qualify for contract awards.

Companies that are found to be in non-compliance will face significant penalties from the DoD along with possible legal repercussions from the Department of Justice False Claims Act of the Civil Cyber Fraud Initiative.

What Does This Mean?

This means that DIB companies looking to bid on new solicitations and those who are looking to bid on options to their current contracts must prepare their organizations to meet the new cybersecurity requirements. Organizations that do not meet requirements will not be considered for contract award by the DoD.

In addition, DFARS defines three levels of assessment – Basic, or self-assessment, Medium, and High. Both the Medium and High Assessments include the requirements of the Basic assessment but give the DoD the option to audit a company’s cybersecurity posture. It is expected that organizations that will be required to meet CMMC Level 2 and Level 3 will likely be subject to a Medium or High assessment. Initially, companies required to meet CMMC Level 2 will be required to be certified by a CMMC Third Party Assessment Organizations (C3PAO). Due to the sensitivity of the CUI for organizations required to meet CMMC Level 3, it is expected that DoD officials will be performing the assessment and certification.

The DoD is expected to finalize the CMMC rollout by March 2023 with CMMC requirements added to contract solicitations by May 2023.

Sources:

• Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7019, 7020, 7021
• NIST SP 800-171 DoD Assessment Methodology
• “Securing the Defense Industrial Base” – Office of the Under Secretary of Defense, Acquisition and Sustainment Website

Introduction

On February 16th, Cybersecurity and Infrastructure Security Agency (CISA) along with the FBI and the NSA issued a joint Cybersecurity advisory detailing the years long attacks on US Cleared Defense Contractors (CDCs) by Russian aligned actors. 

Over the last two years CDCs, meaning a private entity granted clearance by the Department of Defense to access, receive, or store classified information for the purpose of bidding for a contract or conducting activities in support of any program of the Department of Defense, supporting all branches of the US Department of Defense, have been compromised by malicious actors.

The information targeted by these hackers includes CUI such as proprietary and export-controlled information on weapons development, communications infrastructure, and other sensitive technological and scientific areas. 

Attack Patterns 

The advisory listed the tactics used by these Russian hackers and they include: 

• Brute force techniques to identify valid account credentials for domain and M365 accounts and then use those credentials to gain initial access in networks. 

• Spearphishing emails with links to malicious domains, to include using methods and techniques meant to bypass virus and spam scanning tools. 

• Using harvested credentials used in conjunction with known vulnerabilities to escalate privileges and gain remote code executions on exposed applications. 

• Mapping Active Directory and connect to domain controllers, which would enable credentials to be exfiltrated. 

• Maintained persistent access, in multiple instances for at least six months, which is likely because the threat actors relied on possession of legitimate credentials enabling them to pivot to other accounts 

These hackers have been able to access systems and grant themselves escalated privileges using some of the more well known MS365 vulnerabilities including: 

• CVE-2018-13379 (CVSS score: 9.8) – Path traversal vulnerability in Fortinet's FortiGate SSL VPN 

• CVE-2020-0688 (CVSS score: 8.8) – Microsoft Exchange validation key remote code execution vulnerability 

• CVE-2020-17144 (CVSS score: 8.4) – Microsoft Exchange remote code execution vulnerability 

Exploiting these vulnerabilities have allowed these actors to maintain their access for six months or more while they utilize virtual private servers to exfiltrate emails and other information. 

The Future of DoD Cybersecurity 

There are already DoD Cybersecurity requirements for contractors and subcontractors, specified in DFARS clause 7012.  The problem is the requirements rely on self-reporting a NIST SP 800-171 self-assessment and SPRS score to the DoD. 

Without independent verification, this cybersecurity requirement is open to fraud and pencil whipping, which is alleged to be rampant among second tier defense contractors outside the big 4 (Raytheon, Lockheed, General Dynamics, and Northrop Grumman).

The DoD attempted to move away from the NIST self-reporting method towards the Cybersecurity Maturity Model Certification but after pushback from Defense contractors over the time and cost of implementing CMMC controls, the DoD reversed course and neutered the CMMC.  Now CMMC 2.0, as it’s known, is just the NIST self-assessment under a different name. 

The DoD supply chain utilizes hundreds, if not thousands, of small and medium size businesses across the US.  With that large of an attack surface, the DoD supply chain remains exceptionally vulnerable as long as strict and independently verified cybersecurity controls and programs are not enforced. 

Questions For You!

In your opinion, is this really a problem or just media hype?

In your experience, how well do organizations manage the supply chain weak link?

Does your organization have an official vendor information security risk monitoring program?

Do you have any war stories (without naming companies) you'd like to share to help others better understand this issue?

If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.

There’s Only Two Types of Companies 

There’s an old adage that some people have and continue to share that says, there’s two types of companies; 

1. Ones that have been hacked; and
2. Ones that have been hacked but don’t know it.
   

If this is true, which one is your organization?

Most business owners don’t think cybersecurity is an important part of their business operations.  Why?  Perhaps it’s because they believe their business is not big enough or important enough to be a target. 

Cybersecurity-apathy can leave an organization vulnerable to hackers and other malicious actors. 

Small Business – Big Target

In the US, many Data Consumer Protection laws either currently in place or wandering through various state legislatures have two things in common. 

1. Number of record triggers; and
2. Revenue triggers
   

With over 80% of businesses in the US being small and medium sized companies, these triggers exempt most American businesses from compliance. Additionally, business owners are opposed implementing even the most basic cybersecurity controls because they believe they are too costly or too restrictive to business operations. 

Hackers know small businesses are more likely to have weak or non-existent cybersecurity controls in place shown by the statistic that nearly half of all the cyber-attacks each of the last three years have targeted small businesses. 

Small Business – Out of Business 

In general, a small business is categorized by those that have fewer than 500 employees, with only few exceptions.  Most Cybersecurity firms that generate yearly reports use this number. 

The statistics of the impacts of cybersecurity incidents on small businesses are shocking: 

• The average cost of a data breach is $2.98 million 
• 93% of data breaches are financially motivated 
  
• 63% of Small Businesses report a data breach within the last 12 months 
• 41% of Small Businesses report poor security awareness of their employees 

These are sobering, but the most sobering fact regarding Cybersecurity-apathy is that over 60% of Small Businesses that experience a cyber attack are out of business within 6 months. 

Updating the Adage

Year after year, there is little change in the statistics of small business and cyber security.  Perhaps it’s time to update the saying.  Instead of there being two types of companies, there are four: 

1. Those that have been hacked 
2. Those that don’t know they’ve been hacked 
3. Those too apathetic or cheap to prevent being hacked 
4. Those that a hack put out of business

Questions for You!

What are your thoughts on this article?

Do you see this in your world or around you?

Have you been able to successfully address this issue in your organization, and if so, how to you do it?

If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.

Twenty years ago, the popular tactic in phishing emails was for scammers to use the Unicode character U+202e in malicious attachments to fool users into opening malicious attachments.  The character reverses the text and displays it from right to left.  This allowed scammers to reverse the “exe” extension with an innocuous “txt” extension or even seemingly innocent voicemail file extensions “mp3” or “wav”. 

Vade spotted more than 400 attacks in the last two weeks using the RLO method targeting Microsoft 365 users.  As of this writing only 2 out of 58 malware detection tools were able to detect the threat.

More Unicode Trouble? 

In November, two CVEs were released with disturbing Unicode vulnerabilities.  CVE-2021-42574 allowed attackers to disguise and insert malicious code using the U+202e character, hiding vulnerabilities in code that wouldn’t be caught by human reviewers. 

The other, CVE-2021-42694, allowed the injection of malicious code using near identical characters, or homoglyphs, during software development.  Homoglyphs are nearly impossible to detect visually. 

Developers note that the best way to combat these vulnerabilities is to ban text directionality in compilers and language specifications. 

Questions For You!

Do you have any thoughts on this topic?

How do we prevent exposure to vulnerabilities of the past?

ON a slightly different but related topic, is there a role for government to regulate technology companies to ensure known vulnerabilities do not continue to haunt us?

If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.