Legislation is Changing Cybersecurity
This is the tenth in our series sharing thought pieces from the CISO Desk Reference Guide: A Practical Guide for CISOs, Volume 1. In the following excerpt from Matt Stamper’s essay for Chapter 10, Matt explains why he thinks legislation is changing Cybersecurity. This is one of our longer excerpts, which I suppose speaks to the issue! Please enjoy.
Now, let’s look at how federal and state legislation impacts cybersecurity practices and risk analyses. While many essential laws speak to security, I would like to highlight and discuss the following based on their cyber impact:
Landmark Legislation with Cyber Impact
The oldest act is also the most impactful. It is arguably the case that the Federal Trade Commission Act that created the U.S. Federal Trade Commission (FTC) in 1914 has had the most significant impact on cybersecurity practices in the U.S. Section 5 of the FTCA prohibits ‘‘unfair or deceptive acts or practices in or affecting commerce.’’ This single phrase has done more to create a minimum set of cybersecurity practices across the economy than any other line in regulation (even the famous Section 404 of the Sarbanes-Oxley Act). In addition, the FTC has dramatically expanded its role in protecting consumers by leveraging Section 5 to require consumer-facing organizations to protect the privacy and security of non-public information. The FTC’s primary enforcement tool is the now-famous consent decree. Consent decrees function in practice as settlement agreements, although the respondent does not admit liability related to “alleged” practices.
While certainly a good read, an overview of the FTC’s judgment actions is beyond the scope of this chapter. However, there are a couple of actions that warrant specific review. Two key actions in 2002 created the precedent for established and audited security practices within an organization. The first is the consent order with Eli Lilly. I cannot overstate the impact of this order. A security breach on the Prozac site resulted in the disclosure of personally identifiable information for many consumers. In response, the FTC ordered Eli Lilly to:
… establish and maintain an information security program for the protection of personally identifiable information collected from or about consumers in connection with the advertising, marketing, offering for sale, or sale of any pharmaceutical, medical, or other health-related product or service, in or affecting commerce, by respondent’s Lilly USA division, directly or through any corporation, subsidiary, division, or other entity. Such program shall consist of:
A. designating appropriate personnel to coordinate and oversee the program;
B. identifying reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of personal information, including any such risks posed by lack of training, and addressing these risks in each relevant area of its operations, whether performed by employees or agents, including: (i) management and training of personnel; (ii) information systems for the processing, storage, transmission, or disposal of personal information; and (iii) prevention and response to attacks, intrusions, unauthorized access, or other information systems failures;
C. conducting an annual written review by qualified persons, within ninety (90) days after the date of service of this order and yearly thereafter, which review shall monitor and document compliance with the program, evaluate the program’s effectiveness, and recommend changes to it; and
D. adjusting the program in light of any findings and recommendations resulting from reviews or ongoing monitoring, and in light of any material changes to its operations that affect the program.
You can view the press release titled: Eli Lilly Settles FTC Charges Concerning Security Breach from the Federal Trade Commission here: https://www.ftc.gov/news-events/press-releases/2002/01/eli-lilly-settles-ftc-charges-concerning-security-breach.
Effectively, the FTC mandated, as part of its overall corporate responsibility, the establishment of the following:
The December 2002 consent order with Microsoft furthered the FTC’s oversight of security to require an independent, qualified, third-party audit of Microsoft’s security practices. The FTC order required a Certified Information System Security Professional (CISSP) to prepare this third-party report. This consent order, similar to the case of Eli Lilly, has a 20-year term.?
You can view the press release titled In the Matter of Microsoft Corporation from the Federal Trade Commission here: https://www.ftc.gov/enforcement/cases-proceedings/012-3240/microsoft-corporation-matter.
Beyond the operational impact of these orders, the FTC can also impose significant fines for failing to comply with consent orders. For example, the January 2016 amended order with LifeLock includes fines totaling $100 million. The effect of these three consent decrees is not lost on the executives running our organizations and the boards who oversee them.
Now, let’s switch gears to bribery. Interestingly enough, the 1977 Foreign Corrupt Practices Act (FCPA), enforced by the Department of Justice (DOJ) and the Securities and Exchange Commission (SEC) for public companies, indirectly lays the groundwork for the current focus on security controls. Compliance with the FCPA requires establishing an appropriate internal controls framework to prevent or detect the bribery of foreign officials or other fraudulent activities. While the FCPA does not reference information technology, the Act’s provisions require internal controls to be in place to ensure that accounting transactions are accurate, complete, and valid. Effectively, these transaction attributes ensure that accounting procedures and practices reflect managerial authorization and preclude inappropriate financial activity, such as bribery. The FCPA’s emphasis on a program of internal controls laid the groundwork for Sarbanes-Oxley’s impact on IT, where accounting practices are underpinned and supported by pervasive IT general controls.
Before turning to SOX, let’s look at the Gramm-Leach-Bliley Act (GLBA) of 1999. GLBA, enforced by the FTC and other government agencies, is focused on the privacy and protection of non-public information maintained by financial institutions. The FTC’s consent decrees create an expectation of security practices, as noted in the cases of Eli Lilly and Microsoft. The effect of GLBA is to mandate specific security requirements for the financial services industry. GLBA requires that financial services organizations—broadly defined as “significantly engaged” in financial services—comply with the security guidelines delineated in Section 501(b) of the Act. The guidelines formally establish the compliance requirements for financial services organizations to include the following:
领英推荐
GLBA Security Compliance Requirements
GLBA is significantly more prescriptive concerning IT and security practices than Sarbanes-Oxley. The Sarbanes-Oxley Act of 2002 (SOX) barely touches upon IT in the actual language of the law. The role of IT with SOX is mostly by inference. It never ceases to amaze me how much is attributed to SOX, especially by vendors, which is not part of the law. The Sarbanes-Oxley Act directly resulted from the Enron and Arthur Andersen collapses and other accounting scandals. At the time, investor confidence in the public market and the agencies regulating and auditing these firms was low. Congress designed the Sarbanes-Oxley Act to restore investor confidence in the market.
SOX focuses on internal controls over financial reporting (ICFR) and having mechanisms in place for executive accountability, board oversight, and the independence of external auditors. I’ve heard numerous vendors proclaim that Sarbanes-Oxley compliance requires email retention. Email is not part of the law, but vendors attribute it to SOX based on the requirement in Section 103 for auditors to maintain their records for five years. Caveat emptor to any security professional procuring new products or services based solely on SOX requirements, or for that matter, any other regulation.
While SOX does not overtly prescribe practices such as those required by GLBA, SOX did contribute to cybersecurity in that the law effectively created linkages between accounting and business processes and the underlying IT infrastructure and IT practices. Auditors expanded their review of internal controls to encompass enterprise resource planning, general ledger systems, and line-of-business applications that ultimately inform or feed financial data to these accounting systems. The audit community quickly expanded the scope of ICFR to include IT general controls—security being a domain in this assessment. Effectively, publicly traded firms and certain real estate investment trusts (REITs) meeting a defined threshold of qualified investors are required, similar to FCPA, to establish, test, and report on the effectiveness of ICFR, where IT and IT security are lower-level considerations in this assessment.
California’s SB 1386 (passed in 2002 and enacted in 2003) was the first state law requiring breach notification if non-public information (NPI) of California citizens was compromised. SB 1386 did provide an exclusion for encrypted data. The law was complemented the following year with AB 1950. AB 1950 added two important extensions to SB 1386’s requirements. Specifically, AB 1950 requires “entities…to implement and maintain reasonable security procedures to protect personal information from unauthorized access, destruction, use, modification, or disclosure.” AB 1950 further requires that similar security procedures protect third parties processing NPI on the entity’s behalf and that the service contract contain these provisions. The California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), further codified the requirement to have “reasonable” security procedures for in-scope entities.
You can read An act to add Section 1798.81.5 to the Civil Code relating to privacy here:
Third-party contractual obligations—effectively requiring supplier due diligence—began with GLBA. As we will see, supplier security standards continue with HIPAA-HITECH in the form of business associate agreements (BAAs).
The culmination of HIPAA-HITECH requirements is driving necessary security reforms in IT. The impact of HIPAA-HITECH on IT practices, and security and privacy specifically, is similar to the effect of SOX on IT, despite SOX’s relatively limited legal requirements for IT and security. While the impacts of both laws on IT and security practices are profound, HIPAA-HITECH shares more common prescriptive elements with GLBA. HIPAA-HITECH requires organizations that store, process, or otherwise use protected health information (PHI), including electronic forms of PHI (ePHI), to implement prescriptive practices spanning administrative, technical, and physical controls. HIPAA-HITECH requirements incorporate both “required” and “addressable” controls that have some nuance related to the environment’s size, risk, and complexity.
Here are some of the fundamental requirements of HIPAA-HITECH:
Administrative Safeguards: Security Management Processes (risk analyses, risk management, system review, and sanction policies) are all considered required activities. There is also a requirement to assign security responsibility. Incident management and contingency planning are also required. Critically, the regulation requires that business associate agreements with service providers that store, process, or otherwise use PHI or ePHI on behalf of a covered entity or another business associate codify security and privacy controls. CFR 164.308 highlights the required and addressable administrative safeguards mandated by HIPAA-HITECH. These boil down to security and privacy governance. There’s a requirement for a designated individual within the organization to establish and be accountable for mandated security programs.
Physical Safeguards: The required and addressable controls related to physical safeguards encompass workstation security, controls over physical media (including disposal), and facility access. CFR 164.310 covers these.
Technical Safeguards: The required controls related to technical safeguards can be quite challenging where there are “emergency access” procedures that potentially trump other requirements. Exceptions strike at the inherent conflict between the three critical security attributes: confidentiality, integrity, and availability. Availability of systems in healthcare, for example, is truly a life-and-death matter and outweighs the important confidentiality and integrity objectives with security. The necessary balancing act between these three attributes highlights the inherent conflict between confidentiality and integrity (which require potentially performance-impacting controls) and availability. The technical safeguards of HIPAA-HITECH incorporate audit controls, access controls (including unique user identification—required for non-repudiation), and authentication procedures. Unfortunately, perhaps reflecting the challenge of “emergency access,” the regulations note the requirement to encrypt ePHI as addressable. CFR 164.312 outlines the technical safeguards within HIPAA-HITECH. The Department of Health and Human Services’ HIPAA Security Information Series is well worth a read for healthcare professionals.
You can read Security Rule Guidance Material, U.S. Department of Health and Human Services, here: https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html.
?I would also recommend reading the Department’s fact sheet on ransomware, which you can find here:
While focused on the financial services sector, New York State’s Department of Financial Services’ Cybersecurity Regulation is prescriptive and further helps define minimum baseline security requirements, including multifactor authentication, governance requirements, and more frequent risk assessments. Like the CCPA, which was updated with the CPRA, New York’s Department of Financial Services continues to update 23 NYCRR Part 500.
The Defense Federal Acquisition Regulation Supplement (DFARS) 7012 Requirement has the potential to be one of the most impactful cybersecurity regulations to date, notably for organizations that work with the Federal Government. The 7012 requirement obligates in-scope entities to successfully implement and monitor the 110 controls over controlled unclassified information (CUI) outlined in NIST SP 800-171 and its corresponding assessment guide NIST SP 800-171a. While the focus is on the defense industrial base (DIB), the applicability of NIST 800-171 to other Federal environments will likely see a broader emphasis on these controls and the Cybersecurity Maturity Model Certification (CMMC) used to independently assess the design and operational effectiveness of the controls outlined in NIST 800-171.