Fundamentals Of Information Security 05

Information Security Laws and Regulations

We are going to turn our attention to the laws and regulations that will apply to cybersecurity. In a sense, there will be parts of the discussion that will sound like alphabet soup. Like any other profession, cybersecurity practitioners have a language that may be difficult for those new to the field to understand.

Health Insurance Portability and Accountability Act (HIPAA)

The Health Insurance Portability and Accountability Act (HIPAA) is a federal statute in the United States signed into law by President Bill Clinton in 1996. It advocates for the security and privacy of personal medical information. HIPAA pertains to covered entities and their business associates who help carry out health care activities and functions. In general, if a company simply captures information to provide to an insurance company as part of their HR function, they will not be subject to HIPAA compliance.

HIPAA lays out three different types of information safeguards: 1) administrative, 2) physical, and 3) technical. First, administrative safeguards are policies and procedures that detail how an organization is complying with the law. For example, identity and access management policies and standards govern account creation and termination functions.

The administrative controls fall into five key areas:

• Having a security management process
• Designating security personnel
• Implement information access management
• Providing workforce training
• Performance of periodic security assessments

Organizations can benefit from implementing these regardless of whether they are required to comply with HIPAA or not.

 Physical safeguards are controls that physically protect against inappropriate access. For example, one provides direction for the proper disposal of IT equipment. Let’s think about the processes used by our organizations. How do we verify that we’ve removed potentially sensitive data such as health information? In general, we should maintain data destruction policies and ensure users are following them.

Sensitive data will end up in some of the most unlikely places. My first experience with data loss prevention was at a local state college. Our team deployed agents on all college systems, including those in the common spaces where it did not seem to make sense as computers in those areas did not process personal data. Our first round of scans discovered more than 76,000 social security numbers in local system caches located on public systems!

I have noticed that the screens used by office staff in doctors and dentist offices are often left unprotected. There have been many times I’ve been able to read patient data on a screen while interacting with office staff. HIPAA physical security safeguards prohibit access to patient data. Remediation would be installing privacy filters that will limit viewing angles from which a person views on screen data.

Technical safeguards control access to systems containing personal health information. Access controls are an example of these. We need to make sure technical policies and procedures are implemented appropriately in our organizations. Another example would be audit controls which are hardware, software, and procedural mechanisms focused on recording and exam access to systems containing electronic health information. Integrity controls make sure that information has not been altered or destroyed. Transmission security is the final category. Covered HIPAA entities must implement technical security measures to guard against unauthorized access to electronic health information flowing through our networks.

Sarbanes-Oxley Act (SOX)

Sarbanes-Oxley is a U.S. federal act passed in 2002 following several high-profile accounting scandals. Its goal was to provide reforms focused on accounting practices to protect against failures seen at Enron, Worldcom, and Tyco International.

Congress’s aim in passing SOX was to eliminate the ability of management to interfere with independent financial audits. We see this, especially in Sections 302 and 303, which focus on enhancing audit independence via regulation focused on internal procedures and management actions. The following are examples of requirements introduced by SOX.

1. Organizations are now required to perform cyber risk assessments. We have already discussed that common frameworks like NIST and ISO provide references to develop cybersecurity risk management plans. These will include taskings that will consist of processes for risk identification, creation of risk registers, and developing risk treatment plans focused on mitigation measures to implement.
2. An additional requirement is for organizations to identify disclosure controls and policies to ensure relevant risk information is processed and reported to the appropriate personnel. The act’s authors wanted to ensure that disclosure decisions and certifications were accurate. Requirements for procedures focused on prohibiting corporate insiders from insider making investment decisions (i.e., insider trading) based on material non-publicly disclosed information regarding internal cybersecurity risks and identified incidents. The act requires CISOs to provide attestation to the Chief Financial Officer (CFO) that the organization has not experienced any data breach resulting in a material loss requiring public disclosure.
3. SOX also requires adopting cybersecurity controls using commonly adopted frameworks like the CIS Critical Controls. We use frameworks to provide a baseline for establishing SOX controls in our organizations. Remember, though, that these guide control implementations as technology are ever-changing. So our controls must also be flexible to ensure they are always appropriate for current operational environments.
4. The final requirement states all SOX controls must be monitored and tested. A disaster recovery plan is an example. These are great to have in place, but many organizations will never test them to ensure that the recovery plan will work. I worked at a state college with an offsite network for operational transfer should the campus data center experience an outage. Our network manager arranged to visit the new site shortly after hire and was shocked to discover all equipment was still in boxes and had never been connected. The college had shipped all required components years before but never sent an engineer to set up or test them!

Gramm-Leach-Bliley Act (GLBA)

The Gramm-Leach-Bliley Act is also known as the Financial Services Modernization Act of 1999. It requires all financial institutions to protect personally identifiable information (PII) by implementing controls such as employee background checks, adopting acceptable use policies, and limiting access to PII based on a need-to-know basis.

Gramm-Leach-Bliley introduced prohibitions on how a financial institution can use personal data they have collected. It provides the provision to allow consumers to either opt-in or opt-out of certain practices. GLBA compliant privacy notifications must include listings of collected private information, its use, and any organizations that may be granted access to it. GLBA compliant privacy notifications must include listings of collected private information used, who they share it with, and if they will provide consumers with options to limit sharing of said data. 

Federal Information Security Management Act (FISMA)

FISMA was first enacted in 2002 and then modernized by the Obama administration in 2014. It mandates processes and system controls for federal agencies to ensure the confidentiality, integrity, and availability of system-related information. The law emphasizes risk based policies for cost effective security. The original iteration of FISMA established a formal Certification and Accreditation (C&A) process that requires implementing minimum sets of security controls validated through a formal audit process.

Federal agencies in the United States include FISMA requirements in all contracts and grant awards involving sensitive data and where that data is being created, how it is accessed, and where it is stored. Data must be categorized in systems as Low, Moderate, or High regarding sensitivity.

FISMA provides a compliance framework for any systems designated as federal information systems in the United States. Compliance requires organizations to meet requirements detailed in NIST standards and guides that provide us with minimum security requirements and associated controls. 

FISMA compliance will require implementing seven main controls that make up the FISMA cybersecurity framework.

1. Information System Inventory: FISMA requires organizations to create an information system inventory that maps out the boundaries of networks and associated connections between each information system.
2. Information System Categorization by Risk Level: Each system listed in the inventory must be categorized by risk level from any potential breach to determine the necessary level of protection. The risk level is critical to FISMA as the act focuses on risk-based IT security management methods.
3. System Security Plan: FISMA requires organizations to maintain documentation providing an outline of cybersecurity policies and procedures and key milestones for achieving compliance that must be reviewed and updated regularly.
4. Security Controls: All systems must meet minimum security requirements specified in relevant NIST publications. Baseline security controls retain a level of flexibility to enable adaptation to an organization’s specific network requirements. All adjustments must be documented in the system security plan.
5. Risk Assessment: The risk assessment plan assists in identifying and mitigating cybersecurity threats and potential network vulnerabilities. 
6. Certification and Accreditation: The organization must thoroughly review new systems, software, assets, or hardware before being accredited and certified for use by the organization. 
7. Continuous Monitoring: Security controls shall be continuously monitored and refined to ensure they are updated and relevant to current threat environments. 

Some consider the award of a FISM authorization to operate (ATO) a significant accomplishment. While this may be true, we must not forget that having an ATO is meaningless if the commensurate security protections are not implemented correctly. FISMA provides us the structure, but we still must ensure that all systems are adequately protected within the provided framework.

General Data Protection Regulation (GDPR)

The European Union enacted GDPR (EU) May 25, 2017. It is focused on data protection and privacy within the EU and European Economic Areas. It has become an essential component of EU privacy and human rights laws.

GDPR compliance requires an organization to meet stated requirements and provide policies and procedures to govern all client interaction points. The organization must regularly review all GDPR controls, policies, and procedures to ensure ongoing compliance.

A unique aspect of GDPR is its broad definition of personal data. We must keep this in mind, including even an individual’s IP address and cookie data. The act requires equal levels of protection for these as it does for a person’s name, address, and birth date.

One challenge with GDPR compliance is that many requirements are deliberately vague. For example, it requires us to apply a “reasonable” level of protection for data processed in our systems but does not define this. GDPR requires that the organization gain consent to collect personal data, which is difficult in light of the vague requirements. The level of approval needed will vary according to the types of personal data collected. 

A fundamental principle of data protection is “by design and by default,” which guides the implementation of security protocols. An additional phrase found in the GDPR articles is “appropriate technical and organizational measures,” which most interpret as a requirement to ensure data privacy and protection. Example measures by which we may comply with these requirements are data encryption, data anonymizing, or pseudonymization of information.

GDPR includes data minimization requirements. These state that all personal data must not be stored unless there is a documented business need. One way these requirements are applied pertains to the reasons we collect data. In other words, we cannot use data for any purpose other than the documented requirement for which we collect data. For example, if data is collected to populate client records, we cannot use it to profile consumers for marketing purposes.

There is a wide range of privacy rights provided to individuals by GDPR regarding the data organizations are collecting. These include everything from requesting copies of personal data collected to asking that we delete data. We must work with our legal counsel and compliance groups to ensure our organization meets the requests within the timescales stated in the legislation. In most cases, this will be one calendar month to review and either take action or provide feedback to the requestor. Organizations must maintain awareness of where collected data is stored and its usage. We must understand who has access to the data, when it is accessed; and business needs to govern its access.

Data privacy rights are the most challenging area for organizations subject to GDPR compliance. They require levels of transparency that are traditionally not provided to individuals and eliminate the ability for companies to classify personal data as proprietary and confidential, thus rendering it inaccessible to the people it identifies.

One of the most overlooked aspects of GDPR privacy rights is the “right to be forgotten.” If an individual does business with our company, we must provide the opportunity for them to request the erasure of all data about their identity from our databases. 

California Consumer Privacy Act (CCPA)

The California Consumer Privacy Act (CCPA) went into effect on January 1, 2020. Its primary focus is the provision of new privacy rights for California consumers. The following are examples of rights provided in the act.

1. The right to know what personal information is collected, used, shared or sold, both as to the categories and specific pieces of personal information;
2. The right to delete personal information.
3. The right to non-discrimination in terms of price or service when a consumer exercises a privacy right under CCPA.

CCPA and GDPR are different legal frameworks with different scopes, definitions, and requirements. They are similar regarding consumer privacy rights, regulation of data belonging to individuals, and internet activities (i.e., cookies, IP addresses, etc.) The following list provides examples of additional obligations an organization may be required to meet if it is subject to both.

1. GDPR requires that data inventories and data flow maps be maintained. The CCPA has an expanded definition of data mapping; meaning organizations must create additional data flow maps to show compliance with its requirements.
2. GDPR requires the organization to develop processes and/or systems to allow individual requests for access to personal information and erasure of personal information. Organizations apply these to CCPA consumer requests with the caveat that submissions must be reviewed and reconciled to reflect the different definitions of personal information and rules focused on verifying consumer requests.
3. GDPR and CCPA require disclosure of data privacy practices in the form of privacy policies made available to customers.
4. GDPR requires the organization to draft and execute written contracts with service providers (“processors), and we must review to ensure they comply with CCPA requirements.

The CCPA requires organizations to provide the opportunity for California residents to request deletion of personally identifiable data or even to opt-out of having any data collected by our organization. The act forbids any reduction in service for individuals who choose to opt-out of data collection that could potentially identify them.

Organizations are subject to the CCPA only if the following are true:

1. Gross revenues in excess of $25 million.
2. The organization buys, receives, or sells the personnel information of 50,000 or more consumers, households, or devices.
3. Derives 50 percent of annual revenues from selling consumers’ personal information.

Payment Card Industry (PCI) Data Security Standard (DSS)

The payment card industry (PCI) data security standards (DSS) is a global information security standard focused on fraud prevention via security controls specific to credit card data. PCI DSS is a framework of security standards issued by the PCI Security Standards Council to encourage and enhance the broad adoption of consistent data security measures globally. Any organization accepting payment from Visa, MasterCard, American Express, Discover, and the Japan Credit Bureau must maintain compliance with PCI DSS standards.

At the time of writing, the latest version is PCI DSS 4.0. Requirements include the need to secure networks and systems, protect cardholder data, implement strong access control measures, improve weak access control measures, monitor and test active controls, and maintain an information security policy.

PCI DSS provides a series of twelve requirements distributed across six goals:

1. Build and Maintain a Secure Network
   • Install and maintain a firewall configuration to protect cardholder data. 
   • Do not use vendor-supplied defaults for system passwords and other security parameters.
2. Protect Cardholder Data
   • Protect stored data.
   • Encrypt transmission of cardholder data across open, public networks.
3. Maintain a Vulnerability Management Program
   • Use and regularly update anti-virus software or programs.
   • Develop and maintain secure systems and applications.
4. Implement Strong Access Control Measures
   • Restrict access to cardholder data by business need-to-know
   • Assign a unique ID to each person with computer access.
   • Restrict physical access to cardholder data.
5. Regularly Monitor and Test Networks
   • Track and monitor all access to network resources and cardholder data.
   • Regularly test security systems and processes.
6. Maintain and Information Security Policy
   • Maintain a policy that addresses information security for all personnel.

PCI DSS requirements are not overly complex. In one sense, they reflect Security 101. Any organization with an information security program focused on even minimal security controls should be able to pass a PCI DSS audit.

Cybersecurity Maturity Model Certification (CMMC)

The Cybersecurity Maturity Model (CMMC) is a relatively new requirement from the Under Secretary of Defense for Acquisition and Sustainment Office. It represents a new paradigm for the DoD regarding cybersecurity practices within the Defense Industrial Base (DIB). CMMC combines security standards and best practices mapped across three maturity levels.

1. Foundational: 17 practices
2. Advanced: 110 practices aligned with NIST SP 800-171
3. Expert: 110+ practices aligned with NIST SP 800-172

The U.S. DoD developed the CMMC to unify standards to ensure DoD contractors appropriately protected sensitive data due to the growing number of data breaches occurring in the Defense Industrial Base (DIB). CMMC focuses on providing a means of implementing adequate security controls in a means considered to be cost-effective for small businesses.

We have been very US-centric in this chapter. I recognize other privacy acts such as the UK Data Protection Act, Australian Data Privacy Act, and Singapore’s Personal Data Protection Act exist. The key is to develop an awareness of the jurisdiction in which our organizations are operating.

Thank you for stopping by today. If you have enjoyed this post, please consider sharing it with your friends and family.

Our new book, Fundamental Keys To Unlock The Plan of God is now available on Amazon.com in hardcover, paperback, and Kindle versions.