Introduction
How Do Regulations, Frameworks, and Standards Impact Cybersecurity and Audit Practices?
In this chapter, we review strategies and techniques to assess and address the seemingly infinite number of regulations and standards that impact cybersecurity practices and the ensuing audits used to validate security controls. Each of us touches upon some of the more common regulations we face as CISOs, including those that impact sectors such as healthcare and financial services as well as critical infrastructure. We each emphasize the importance of taking a collaborative approach to regulatory compliance…working with other stakeholders within our respective organizations to understand the requirements of the security programs we oversee. Key actors in these processes include the organization’s legal counsel, its chief risk officer, and other C-level executives that have a fiduciary responsibility to oversee the governance of the organization.
Bill begins this chapter with the basic premise that regulations and compliance requirements mandate “minimum standards of due care.” Bill’s experience working with publicly-traded organizations that are subject to both Sarbanes-Oxley compliance and regulatory audits offers excellent guidance on how to approach an audit as a CISO and how to work with colleagues throughout the organization to prepare for this level of oversight. Bill also notes how important it is as the CISO to evaluate the organization’s contractual obligations. These may be especially impactful for organizations in healthcare that are subject to HIPAA-HITECH.
Matt continues with an assessment of the regulations that mandate specific security practices and suggests that we’ve entered an era where boards of directors and our colleagues in the C-suite can no longer ignore security. The CISO is now the advocate for legally-defensible security practices. Matt also highlights the unique role that the Federal Trade Commission (FTC) has had in establishing minimum security practices with its enforcement of Section 5 of the Federal Trade Commission Act (FCTA), which addresses “unfair and deceptive trade practices.”
Gary emphasizes how critical it is for the CISO to “meet and greet” fellow executives and stakeholders. This informal discovery leads to actionable guidance related to regulatory compliance and the required controls. Gary’s analysis also suggests that the regulatory requirements should inform the type of controls and techniques deployed. Gary warns CISOs not to make controls, processes, and techniques overly complex as this will typically overwhelm the organization and have the opposite of their desired effect. Despite Gary’s background with the Navy, the Department of Defense, and municipal government, he brings a refreshing “business perspective” to dealing with regulations and compliance.
Consider these questions as you read this chapter:
♦ Do I have any regulatory requirements?
♦ How do I position my security program and organization for success with regard to compliance?
♦ What policies, processes or procedures should we leverage to successfully engage our auditors and/or regulators?
Regulatory Requirements and Audit – Bonney
In the first chapter, I talk a little about regulatory oversight. I point out, for instance, that in the overall scheme of information security, regulatory requirements are really cover charges. I also noted that typically, in mature organizations with well-known or substantial regulatory requirements, corporate governance would be structured to comply with mandatory management oversight obligations. To be clear, I believe that regulations and compliance requirements mandate minimum standards of due care.
The reality is that while regulatory and compliance requirements do not in and of themselves keep your data secure, they are obligatory, with the specifics depending on the industry, locale, and organizational structure. But, truth be told, despite the disdain that many people hold for compliance activities and requirements, they can often be leveraged as a foundation for a good information security program.
In this chapter, I will expand on some of those thoughts and talk about setting up your program for regulatory success, leveraging that foundation for successful governance, and engaging with your internal and external audit teams as key partners in your governance program. I will take the questions for this chapter in order. What are my regulatory requirements? How do I set up my program for success? And how do I engage my auditors and regulators?
How Do I Know What My Regulatory Requirements Are?
That brings us to the first question I am going to address: how do I know what my regulatory requirements are? I’m going to take an expansive view of this. By expansive, I mean I’ll consider a broader range of compliance regimes that aren’t all strictly regulatory.
Let’s begin with the obvious: if the organization is a publicly-traded company listed in the U.S., it is subject to the Sarbanes-Oxley Act of 2002, which was enacted to ensure reliability in financial reports filed by public companies with the U.S. Securities and Exchange Commission. Check with your Chief Information Officer (CIO), Chief Technology Officer (CTO), Chief Operations Officer (COO), Chief Financial Officer (CFO) or Corporate Controller to understand how your organization is currently managing these obligations and how you should engage with the appropriate teams. In general, you’ll be responsible for some subset of the Information Technology General Controls (ITGCs) that your organization has defined to comply with Section 404.
If the organization holds personal data for employees or customers, it is likely subject to privacy regulations from applicable state privacy and breach laws, along with potential international implications depending on the localities involved. U.S. multinationals who do business in the European Union (EU) or hold data for EU citizens must comply with the General Data Protection Regulation (GDPR). Check with your Chief Privacy Officer (CPO), Chief Risk Officer (CRO), or Chief Legal Officer (CLO). If your organization doesn’t have these leadership positions, a good fallback is the CFO, who will often own risk for medium-sized firms. Here you’ll again have a subset of IT controls.
For good proxies of what is required to meet these controls, you can use the following. For preventative control requirements use the Massachusetts privacy regulations (201 CMR 17.00). Use the Nevada breach notification law (N.R.S. § 603A.010) and the California data breach notification law (SB 1386) for breach notification requirements. And to provide a sober reminder of the reach of some state regulations, review the Texas extreme notification requirements (Texas Medical Records Privacy Act), which are more stringent than those found in the federal Health Insurance Portability and Accountability Act (HIPAA).
Of course, HIPAA is one of the other major regulatory regimes you’ll need to pay attention to if you are a “covered entity,” which are generally healthcare clearinghouses, employer-sponsored health plans, health insurers, and medical service providers. One of the more interesting features of HIPAA is that covered entities are required to cascade their obligations to Business Partners and Business Associates (look for any business associate agreement (BAA) your organization has signed) to ensure that all third parties that are involved in handling Protected Health Information (PHI) are obligated to safeguard the PHI in their care.
Besides healthcare, other industries have specific regulatory regimes. Some examples:
Federal agencies must comply with FISMA, the Federal Information Security Management Act. DoD contractors are subject to DFARS 252.204-7012, which requires a subset of NIST 800-53 controls and DoD contractors that handle classified information are subject DFARS Rule 78 Fed. Reg. 69273.
Organizations that accept credit cards for payment or process credit cards are subject to the Payment Card Industry Data Security Standards (PCI-DSS) and organizations that use Experian data agree to comply with the Experian Independent Third-Party Assessment (EI3PA).
Finally, similar to the contractual requirement of adhering to PCI-DSS controls (these are not regulations, you agree to comply in your contract with the Payment Card Industry), organizations often agree to data handling requirements that usually include security requirements by accepting contract language specifying security and privacy related duties.
It is best to start with your executive peers for a general idea of what contractual security compliance requirements you have in place, but do a deep dive with the procurement department or whichever group is responsible for managing contractual compliance. Contractual compliance is something most audit firms will look at while conducting financial audits, which implies that some group within the organization will be responsible for tracking the agreed-to obligations. If the structure within your organization is not apparent, you can start with the CFO or Controller.
Typically, signed addendums, engagement letters for third-party assessors, and the resulting attestations will list the individuals in the organization who are authorized to represent the organization, and that is an excellent place to start to determine what has been committed and who is executing and testing controls.
For banks and certain other financial institutions, there are a host of compliance regimes, including compliance with the Gramm–Leach–Bliley Act (GLBA) and adhering to guidance from the IT Examination handbook of the Federal Financial Institutions Examination Council (FFIEC), the multi-agency bank regulator. Other organizations that provide services to the financial industry are often required to provide third-party attestations about their controls. These attestations used to be called a “Statement on Auditing Standards No. 70” (SAS-70) report, but in 2011, the American Institute of Certified Public Accounts (AICPA) replaced the over-burdened SAS-70 with a new standard called the “Statement on Standards for Attestation Engagements No. 16” (SSAE-16) and then in May of 2017, updated that standard with the “Statement on Standards for Attestation Engagements No. 18” (SSAE-18). This replacement was more than a series of name changes.
In addition to creating extra burdens on the organization obtaining the audit (called the “Service Provider”) and transferring some responsibility from the auditing firm (called the “Service Auditor”) to the Service Provider, the changes also defined and formalized additional types of attestations (SOC2 and SOC3) based on trust principles, including: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Financial institutions typically have mandated management duties as well, and the CFO or Chief Audit Officer (CAO) can be consulted to start your discovery for these compliance requirements.
What I have covered above is not meant to be 100% complete. We could dedicate an entire book to listing and describing all the compliance regimes touching information (or data) security. Instead, I have laid out several fundamental principles. First, there are some mandatory security regulations for nearly every organization, indeed any organization that would require a full-time CISO. Second, compliance obligations come in both mandatory (regulations) and voluntary (contractual) varieties. And third, for each requirement, there are logical places to start your discovery about what is required and determine the role you must play.
