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.

Introduction

There are few topics more critical in cybersecurity than the establishment of proper data classification and protection programs within an organization. For many organizations, data and information are their most valuable assets, the new currency in the digital economy. In this chapter, we explore how aligning data and information protection with business objectives is a core element of good data governance.

Data classification influences the three central tenets of security: confidentiality, integrity, and availability (CIA).  While each of these three attributes is important, their relative values vary from industry to industry. Data classification is critical in prioritization because we cannot protect all data equally. A critical part of the CISO’s role is to understand which data is most important to the organization.

In addition to data classification, you should conduct formal data-flow analysis within the organization. We share approaches to documenting information flows within an organization that range from non-technical “meet-and-greets” to more technical packet analysis. The resulting data flow diagrams (DFDs) are a valuable tool for your information security and governance program.

Finally, treat data as a strategic asset. Make data classification activities as pragmatic as possible. Be aware that exhaustive data classification projects become “shelfware.” It is critical to have the data classification and governance activities aligned with the organization’s risk management practices and ultimately the organization’s risk appetite.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  What type of information and data does my organization create, use, and share as part of our operations?

♦  Do we have data that is subject to specific regulatory or contractual controls and practices?

♦  Do I know the lifecycle of this data and the systems, processes, applications, individuals, and third parties that have access to this data?

♦  Are our organization’s data governance practices consistent with the value of this data and our regulatory or contractual obligations?

Data Mapping – Stamper

In this chapter, we will be discussing the critical requirement to classify and map data. As I explained in the previous chapter, laws, regulations, and industry standards are placing greater emphasis on knowing the types of data within organizations and its governance. Before focusing on data governance, let’s take a quick detour to the world of economics.

Transaction costs, according to economists, can influence which functions are handled internally within the organization or outsourced to an external provider. When transaction costs are high, there is a tendency to maintain these activities internally. These functions are often transferred to more cost-effective, external providers when transaction costs are low. What we have seen over the last twenty-plus years is the widespread reduction of transaction costs for many core enterprise functions and across many industries including healthcare, financial services, manufacturing, and professional services. In addition to outsourcing wide-scale functions, we are now outsourcing niche activities at the margin (i.e., shadow IT). As an economist might note, most everything happens at the margin. What does this have to do with cybersecurity? Everything.

For the CISO today, it has never been more critical to understand the types of information moving into and out of the organization. The effect of reduced transaction costs, coupled with new technologies such as mobile telephony and cloud services, has introduced significant challenges for CISOs charged with protecting organizational assets, including information and data. Let’s take a few moments to understand how pervasive outsourcing of specific functions is in today’s economy and its impact on knowing where our data resides.

Most organizations have common departments including human resources, finance and accounting, sales and marketing, information technology (IT), operations (including manufacturing), and legal. The reduction of transaction costs related to core activities within these departments has effectively made the organizational boundary semi-permeable. What is outside the organization is now inside, and what’s inside is now outside. Those of us in security feel this viscerally when we think of our own organization’s perimeter. It’s hard to find and nearly impossible to secure.

Where’s Our Data?

Let’s look at some concrete examples of how fluid information is within, and more importantly, outside of an organization. It’s not uncommon for organizations to outsource their payroll services to third-party processing organizations. Payroll data includes personally identifiable information (PII), including the employees’ social security numbers (SSNs), salaries, dates of birth, and addresses. That same organization may also outsource its accounting function. The accounting firm would have access to sensitive financial information including profit and loss detail, the value of assets, and the particulars about significant transactions. External auditors will validate the financial reports prepared by the firm and may request samples of specific transactions to support their assertions regarding the quality of the financial reporting.

The organization may leverage external legal counsel to file patent applications, handle merger and acquisition (M&A) activities, and other highly-sensitive projects. A third-party marketing application sends e-mails to clients and prospective clients containing personally-identifiable information (the name and e-mail address of the recipients). Independent contractors may be providing support on critical projects with access to material non-public information (MNPI). The organization may outsource manufacturing to a contract manufacturer in another country. The manufacturer could be using patented processes or other intellectual property of the organization. An external DevOps team may be handling application development and might have real production data to test functionality.

The organization’s applications reside in multiple locations across multiple states and several countries. Some applications and data are “in the cloud” and many lines of business, given the responsiveness challenges with traditional IT, use SaaS services to meet their requirements. Employees have personal mobile phones that they use to receive e-mail outside of the office. This e-mail includes attachments containing any number of data elements. Employees also bring their devices to work and take these devices with them when they leave the office each day, including when the firm terminates their service. Employees use third-party file-sharing tools, personal e-mail accounts, and external media to store information. Suffice it to say that the average organization does not know where its critical data and information are and, equally important, how they are protected, if at all, outside the organization.