Home / Resources / ISACA Journal / Issues / 2020 / Volume 1 / The NIST Cybersecurity Framework Third Parties Need Not Comply

The NIST Cybersecurity Framework—Third Parties Need Not Comply

The NIST Cybersecurity Framework Third Parties Need Not Comply
Author: Thea Janeway, CISA
Date Published: 12 February 2020

“How can an organization make third parties comply with NIST?” This question haunts risk management professionals (and their lawyers) who are familiar with all five functions, 23 categories and 108 subcategories of the Cybersecurity Framework (CSF), published by the US National Institute of Standards and Technology (NIST).1 Achievement of all CSF objectives just does not seem possible. There is a good reason for that: The CSF is not intended to be “complied with.” In fact, according to the US regulator of consumer data protection laws, the CSF is “meant to be used by an organization to determine its current cybersecurity capabilities, set individual goals, and establish a plan for improving and maintaining a cybersecurity program, but it doesn’t include specific requirements or elements.”2

The following is intended for risk management professionals responsible for making recommendations and third-party risk assessments. By answering the following questions, the risk management professional may make useful observations about the organization’s risk management process maturity:

  • Is the CSF an appropriate third-party risk assessment model for the organization?
  • What is third-party risk in the organization?
  • What third-party security controls are required by CSF?
  • What should be the relationship between third-party security controls and third-party contracts?

Is CSF an Appropriate Third-Party Risk Assessment Model for the Organization?

Many organizations lack clear understanding as to whether, or to what extent, they must adhere to the CSF. NIST proposes baseline security and privacy controls for organizations’ federal information systems.3 Federal information systems are information systems “used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency.”4 Organizations retain the authority to decide how to incorporate the CSF and to what extent as a policy or standard.5 In other words, the CSF should not be used as a checklist or compliance standard unless it has been ratified as such by the organization or its regulator.

A federal information system likely includes any information system used or operated by a governmental organization or quasi-public organization. Private and foreign organizations may also be subject to the CSF if the private or foreign organization’s business is dependent on a contract that expressly incorporates provisions of CSF. International organizations, which are likely subject to non-US legal jurisdictions, may look to a CSF equivalent that preempts CSF itself (e.g., the Ontario, Canada, Cybersecurity Framework, Switzerland’s Information and Communications Technology Minimum Standard, and the UK’s Cabinet Office Minimum Cybersecurity Standard).6 In any event, the core principles of the CSF are not new in the sense that they combine already-known information security frameworks (e.g., NIST Special Publication [SP] 800-53 Revision 4) into a searchable index of guidelines relating to identification and protection of data and systems, detecting and responding to threats, and recovering data and systems when necessary.7

When considering whether the CSF applies to an organization or the systems therein, these questions must be kept in mind:

  • Has the organization adopted the CSF through formal or informal information security policies?
  • Does the organization solely operate IT systems within the United States?
  • Does the organization have significant business relationships dependent on data owned or processed by a quasi-governmental organization?

If the answer to any of these questions is “no,” the CSF may not be appropriate for an organization.

What Is the Third-Party Risk in the Organization?

In addition to considering first-party risk, organizations are challenged to reach internal agreement on significant third-party information system risk (figure 1). The NIST Information Technology Laboratory Glossary defines third party as an external entity, including, but not limited to, service providers, vendors, supply-side partners, demand-side partners, alliances, consortiums and investors, with or without a contractual relationship to the first-party organization.8 Risk is “an expression of the combination of the probability of an event and its consequence.”9, 10 Therefore, the definition of third-party risk can be defined as an expression of the combination of: (a) the probability of a third party causing an event, and (b) the event’s consequence.

Figure 1

The CSF and its implementing NIST publications seek to ensure the confidentiality, integrity and availability of data.11 Similarly, US law defines a security breach as a failure to maintain confidentiality, integrity or availability of data.12 One way the CSF promotes confidentiality, integrity and availability of information systems is by assigning impact into categories: high impact, medium impact and low impact. Each impact category requires an understanding of potential impact to the business in the event of breach.13

ORGANIZATIONS MAY OVERCOMPENSATE ON SECURITY CONTROLS WHERE CLEAR AND CONSISTENT DATA MANAGEMENT POLICIES ARE LACKING.

This impact analysis flows from inherent risk in creating, using or transmitting certain types of data.14 In other words, if a data breach occurs, what is the risk? For example, an enterprise may determine “all data at rest in third party hosting systems must be encrypted.” However, some data hosted by a third party may reside in the low-impact category (meaning, in the event of a confidentiality breach, the business effect is low impact). The CSF provides that, for low-impact information systems, encryption at rest is not recommended.15

 

It follows from this example that organizations may overcompensate on security controls where clear and consistent data management policies are lacking. For a risk-based and impact-based approach to managing third-party security, consider:

  • The data the third party must access
  • The likelihood of unauthorized data disclosure, transmission errors or unacceptable periods of system unavailability caused by the third party
  • The support for this third-party risk assessment:
    • Historic records
    • Recognized industry standards
    • Statistical theories
    • Controlled experiments
  • The business impact if the risk event occurs (e.g., loss of money, breach of contract, loss of business opportunity, personal injury, statutory violation, reputational harm)

What Security Controls Are Required by the CSF?

Another issue to be explored is the challenges faced by organizations to define adequate security controls for third-party risk without unduly burdening business interests. Organizations are responsible and accountable for managing information security risk arising from their own information systems.16 Such risk is addressed by implementing relevant CSF requirements with third parties “where appropriate.”17 The term “where appropriate” can be construed to mean the CSF does not mandate specific third-party risk controls.

Technologies and activities—not third parties—carry inherent risk. For example, third-party hosting of critical functions is an inherent risk. Interestingly, US bank regulators indicate that third-party hosting has the same inherent risk as direct employment of 50,000 or more employees.18 The takeaway from this is: do not assume that in-housing IT is the answer to mitigating third-party risk. Rather, first-party and third-party risk should be tracked and monitored concurrently and in accordance with the principle of least privilege.19

Organizations should consider the following when designing third-party security controls:

  • What is the inherent risk of the activity performed by the third party? Would the activity be less risky if performed by the first party?
  • What security controls have been adopted by the organization with respect to other globally accepted frameworks (e.g., International Organization for Standardization [ISO], COBIT)? Can these controls be cross-referenced within the CSF?20
  • Is it feasible for the third party to implement the security control, given the overall business relationship? If not, what is the best workaround that meets the security objective without impairing business functions?

Once the organization has identified relevant third-party risk controls, the professional may look to the CSF for its position on how, or to what extent, security controls should be documented by a third-party contract. The CSF suggests, but does not require, the third-party contract as a source document for security controls.

The Relationship Between Third-Party Security Controls and Third-Party Contracts

A contract is formed when: (a) one party makes an offer, and (b) the offer is accepted by the other party.21 The result of a legally enforceable contract is the ability to ask a judge to force performance of a party’s express contractual obligations.

The CSF recommends contractual agreements as part of a third-party risk management program.22 Similarly, the US Federal Information Security Modernization Act of 2014 (FISMA) requires US federal agencies sending federal information to external service providers to:

  • Assure that service providers adhere to the same security requirements as the agency
  • Express security requirements in contracts or other formal agreements23

Organizations may delegate nearly all CSF responsibilities to third parties, but organizations may decide how, and to what extent, the contract identifies the specific security controls. For example, a business owner may decide the third-party contract reflects appropriate security controls by referencing certain sections of the framework.24 In summary, organizations may, but are not required by the CSF to, implement security policies in third-party contracts.

THE CSF IDENTIFIES THE THIRD-PARTY CONTRACT AS AN IMPORTANT COMPONENT OF THIRD-PARTY RISK MANAGEMENT.

The CSF identifies the third-party contract as an important component of third-party risk management. However, the CSF does not define exact contractual terms and, therefore, organizations have significant leeway to draft contractual terms that are acceptable to all parties.25

Risk management professionals may define each party’s responsibility for security controls by asking the following questions and documenting responses, whether or not the responses are documented in the contract:26

  • Will the third party require access to the organization’s sensitive or confidential information? If so, are there clear guidelines and procedures on organizational requirements for provisioning access?
  • Who, between the organization and third party, is responsible for:
    • Design, implementation, performance and monitoring of controls
    • Data and application privacy and confidentiality
    • Systems, communications, operating system, utility software, data, and application software access controls and administration
    • Monitoring of assets and related data and response, and reporting procedures (routine and incident)
    • Specifying ownership of information assets, including data and domain names
  • What are the parties’ rights if the controls change? For example, what are the third party’s rights if the customer refuses to implement a requested change? In the event of a dispute, what is the procedure to resolve the dispute?
  • Are there service levels defined for achieving security objectives (e.g., system functionality, security assessments, plan development and testing, remediation processes, producing documentation relating to the organization’s information systems, information protection requirements)?
  • Finally, and importantly, could the organization manage all this in some vehicle other than the third-party contract? For example, does the organization conduct an effective audit program that identifies third-party risk and effectively resolves the risk? This could offer a business-friendly workaround to papering security requirements in third-party contracts.

Conclusion

Using the analytic framework provided herein, the risk management professional may provide useful observations about the CSF and the extent to which it should apply to organizational risk management objectives vs. whether the organization complies with the CSF. Risk management professionals can also avoid the organizational pitfall of implementing the CSF “checklist.”

Endnotes

1 ISACA, Implementing the NIST Cybersecurity Framework, USA, 2014, http://store.3898368.com/s/store#/store/browse/detail/a2S4w000004KoZREA0 Item BAI03.04 on page 58 correlates to the COBIT 5 process Build, Acquire, Implement (BAI) and exhorts the risk management professional to ensure that all legal and contractual requirements are met by the third party.
2 Arias, A.; “The NIST Cybersecurity Framework and the FTC,” US Federal Trade Commission, 31 August 2016, http://www.ftc.gov/news-events/blogs/business-blog/2016/08/nist-cybersecurity-framework-ftc
3 National Institute of Standards and Technology, “Security and Privacy Controls for Federal Information Systems and Organizations,” NIST Special Publication (SP) 800-53 Revision 4, USA, April 2013, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf. To determine a “baseline” security control, the organization first must establish that it (i) is operating a “federal information system” pursuant to FIPS Publication 199 (Standards for Security Categorization of Federal Information and Information Systems) and (ii) derives the information system impact level from the security category in accordance with FIPS Publication 200.
4 National Institute of Standards and Technology, “Computer Security Resource Center Glossary,” USA
5 National Institute of Standards and Technology, “Framework for Improving Critical Infrastructure Cybersecurity,” USA, 16 April 2018, http://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
6 National Institute of Standards and Technology, “International Resources,” USA, http://www.nist.gov/cyberframework/international-resources
7 National Institute of Standards and Technology, “Framework Resources,” USA, http://www.nist.gov/cyberframework/resources
8 National Institute of Standards and Technology, “Third-Party Relationships,” USA
9 International Organization for Standardization (ISO), ISO 31000:2009, Risk management—Principles and guidelines, http://www.iso.org/standard/43170.html
10 International Organization for Standardization, ISO Guide 73:2009, Risk Management—Vocabulary, http://www.iso.org/standard/44651.html. For illustrations of certain types of third-party threats, consult the Framework’s “Supply Chain Threat Events” at NIST Special Publication 800-161.
11 National Institute of Standards and Technology, “Protect,” USA, http://www.nist.gov/cyberframework/protect
12 National Institute of Standards and Technology, “Standards for Security Categorization of Federal Information and Information Systems,” Federal Information Processing Standards Publication (FIPS PUB) 199, USA, February 2004, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf
13 Ibid.
14 Op cit National Institute of Standards and Technology, April 2018
15 Op cit National Institute of Standards and Technology, April 2013
16 Op cit National Institute of Standards and Technology, February 2004
17 Op cit National Institute of Standards and Technology, April 2018
18 Federal Financial Institutions Examination Council, “Inherent Risk Profile,” USA, May 2017, http://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_May_2017_Inherent_Risk_Profile_June2.pdf
19 Federal Financial Institutions Examination Council, “Appendix B: Mapping Cybersecurity Assessment Tool to NIST Cybersecurity Framework,” USA, June 2015, http://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_App_B_Map_to_NIST_CSF_June_2015_PDF4.pdf
20 Op cit National Institute of Standards and Technology, April 2018, p. 24
21 United Nations Commission on International Trade Law, “United Nations Convention on Contracts for the International Sale of Goods,” USA, 2010, http://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/19-09951_e_ebook.pdf
22 Op cit National Institute of Standards and Technology, April 2018
23 Op cit National Institute of Standards and Technology, April 2013
24 Ibid. Organizations can require external providers to implement all steps except the security authorization step, which remains an inherent federal responsibility directly linked to managing the information security risk related to the use of external information system services.
25 For example, the CSF recommends including access control policies in agreements but does not specify the policy level that contributes to achieving the security objective (i.e., the third party does not inadvertently cause unauthorized release, modification or destruction of sensitive information). As another example, the CSF recommends including data leakage prevention coordination procedures in the contract but leaves it to the parties to define what “coordination” looks like. See National Institute of Standards and Technology, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” NIST SP 800-161, USA, April 2015, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf
26 Ibid.

Thea Janeway, CISA
Is a lawyer with more than 10 years of experience advising business and risk management professionals on legal issues relating to technology and cybersecurity. Her recent assignments have involved clients within critical infrastructure domains such as global financial services, healthcare data clearinghouses and information technology outsourcing.