The federal government is unique in that it can identify the standards it wants to follow and passes laws requiring the standards to be followed. The Federal Information Security Management Act (FISMA) of 2002 is a good example of government self-regulation. FISMA requires government agencies to adopt a common set of information security standards. Some parts of the government, such as the military, go beyond these standards. For many government agencies, FISMA creates mandatory requirements to ensure the integrity, confidentiality, and availability of data. If your organization processes data for the government, you may be required to follow these same standards. FISMA also requires that agencies send annual reviews to the Office of Management and Budget (OMB). For example, an audit of the Veterans Affairs (VA) Department in 2012 found 15,000 security policy violations. As a result, the VA was found to be noncompliant with FISMA. In 2018, a report was released of the FISMA audit of the Securities and Exchange Commission (SEC). It recommended 20 different corrective actions.⁸ These two case studies would tend to indicate that FISMA compliance is still not where it should be with many federal agencies.

The National Institute of Standards and Technology (NIST) is responsible for developing FISMA-mandated information security standards and procedures. Each agency is then responsible for adopting them as part of their agency’s information security policies. NIST standards, processes, and guidelines are available at http://csrc.nist.gov/publications/sp/.

NIST publications outline a complete set of security standards and processes. To be compliant, your policies must include key security control requirements. Some of these key requirements include:

• Inventory—An inventory of hardware, software, and information identifies the type of information handled and how data passes to the systems, and pays special attention to national security systems.
• Categorize by risk level—Inventory needs to be classified. The idea is that this classification will highlight higher-risk areas that need more protection.
• Security controls—The NIST standards outline which controls should be applied and when. They also outline how these controls are documented and approved. The approach is risk-based, which gives some flexibility to the agency to tailor controls to meet its operational needs.
• Risk assessment—Risk assessments are also required. Risk assessments are an essential part of a risk-based security approach. The risk assessment results drive the type of security controls to be applied.
• System security plan—A formal security plan for major systems and for the system or application owner is also required. The security plan serves as a road map. It is updated to keep current with threats and is an important part of a certification and accreditation process.
• Certification and accreditation—This process occurs after the system is documented, controls are tested, and risk assessment is completed. It is required before going live with a major system. Once a system is certified and accredited, responsibility shifts to the owner to operate the system. This process is also referred to as the security certification process.
• Continuous monitoring—All certified and accredited systems must be continuously monitored. Monitoring includes looking at new threats, changes to the system, and how well the controls are working. Sometimes a system has so many changes that it must be recertified.

The Health Insurance Portability and Accountability Act (HIPAA) became law in 1996. The law protects a person’s privacy. If you handle someone’s health records, you must adhere to HIPAA. This includes doctor’s offices, hospitals, clinics, and insurance companies. The law recognizes that digital data exchange of health records, such as between insurance companies and doctor’s offices, is a necessity. But in 2013, new restrictions were placed on access to health records by subcontractors and vendors. The law wants to make sure that patient privacy is maintained.

The HIPAA law defines someone’s health record as protected health information (PHI). The term PHI refers to both digital and physical paper copies of health records. Electronic PHI (EPHI) refers to the electronic form of PHI records. HIPAA establishes privacy rules that outline how EPHI can be collected, processed, and disclosed. There are significant penalties for violating these rules. In 2013, these fines were increased to a maximum of $1.5 million per violation. This regulation applies to any covered entity that manages health records, including:

• Healthcare providers—Doctors, hospitals, clinics, and others
• Health plans—Those that pay the cost for the medical care, such as insurance companies
• Healthcare clearinghouses—Those that process and facilitate billing
• “Business associates”—Vendors and subcontractors of any covered entity

For your security policies to be HIPAA-compliant, they must include the following key control requirements:

• Administrative safeguards—Refers to the formal security policies and procedures that map to HIPAA security standards. It also refers to the governance of the security policies and their implementation.
• Physical safeguards—Refers to the physical security of computer systems and the physical health records.
• Technical safeguards—Refers to the controls that use technology to protect information assets.
• Risk assessment—Refers to a standard requirement of a risk-based management approach to information security.

HIPAA was enhanced in 2009 with the Health Information Technology for Economics and Clinical Health (HITECH) Act.⁹ Among other enhancements, HITECH imposes data breach notification requirements for unauthorized uses and disclosure of unsecured or unencrypted PHI. HITECH also expanded HIPAA compliance requirements to business associates of medical providers.

The Gramm-Leach-Bliley Act (GLBA) became law in 1999. The law is not focused on technology; rather, it was meant to repeal existing laws so that banks, investment companies, and other financial services companies could merge. Prior to GLBA, banks, for example, were restricted on the types of products they could offer. However, in addition to this, under what is known as Section 501(b), the law outlines information security requirements for the privacy of customer information.

The law is enforced through regulators who are members of the Federal Financial Institutions Examination Council (FFIEC). The FFIEC publishes booklets of what type of computer security policies and controls must be in place for an institution or company to be compliant with GLBA. These booklets define availability, integrity, confidentiality, accountability, and assurance as key objectives.

The FFIEC booklets are publicly available through the council’s website. The following website introduces the 501(b) rules: http://ithandbook.ffiec.gov/it-booklets.aspx.

To be GLBA-compliant, your security policies must include the following key components:

• Governance—Requires a strong governance structure in place. This includes designating someone in an organization as accountable for information security. This is often the chief information security officer (CISO) or chief information officer (CIO). Most boards receive formal GLBA reporting through the audit committee. The head of information security usually writes this report each quarter.
• Information security risk assessment—Requires a well-defined information security risk assessment to identify threats, potential attacks, and impacts to the organization.
• Information security strategy—Requires a formal security plan to reach compliance.
• Security controls implementation—Requires a process to properly design and install security controls that meet the security plan objectives.
• Security monitoring—Requires continuous monitoring of security controls. This is to ensure that the design meets the objectives. This is event-based monitoring and includes incident response.
• Security monitoring and updating—Requires monitoring of trends, incidents, and business strategies, and appropriate updates to the security plan.

The Sarbanes-Oxley (SOX) Act became law in 2002. The law was enacted in reaction to a series of accusations of corporate fraud. Some companies were accused of “cooking the accounting books” or making illegal loans to their top executives. Companies such as Enron and WorldCom became symbols of corporate greed and corruption. Enron filed for bankruptcy in 2001 amid accusations of cooking the books to inflate its stock price. WorldCom filed for bankruptcy in 2002 amid accusations of illegal loans to its chief executive officer (CEO), as well as billions in accounting fraud to inflate the stock price. These two highly visible corporate fraud cases shook shareholder and public confidence. SOX was enacted to restore confidence in the markets.

SOX goes well beyond information security policies. It also describes how a company should report earnings, valuations, corporate responsibilities, and executive compensation. The act is intended to improve the financial accuracy and public disclosure to investors. In fact, some argue the act goes too far and is too costly. This chapter focuses on those portions that affect security policies known as SOX 404.

The basic idea behind SOX 404 is to require security policies and controls that provide confidence in the accuracy of financial statements. In other words, security policies must ensure the integrity of the financial data. Independent testing of these controls is required. Additionally, top executives are required to sign off quarterly that these controls meet SOX 404 requirements or explain why they do not.

One of the challenges of SOX is cost. It is expensive and nearly impossible to test all a company’s controls. The requirement to test all possible controls drew many complaints from companies, so in 2007, the government changed the rules for SOX. The change allowed companies to limit testing to only the most important controls—those in areas of high risk. This lowered costs for many companies. It also made it easier for a company to prove it was compliant. All security controls are important. Well-written security policies highlight key controls to indicate which are most important.

The act created the Public Company Accounting Oversight Board (PCAOB). The PCAOB sets accounting and auditing standards. The Securities and Exchange Commission (SEC) is responsible for enforcing SOX. The challenge for information security is that SOX 404 sets broad IT objectives. It does not define how to comply. Rather than developing new information security and control standards, the PCAOB and SEC have endorsed using industry best practice frameworks. The following are endorsed frameworks that companies commonly use to meet SOX 404 requirements. These frameworks are widely used by external auditors as well to certify SOX compliance:

• Committee of Sponsoring Organizations (COSO)—As it relates to security policies, this organization creates rules for implementing internal controls and governance structures.
• Control Objectives for Information and related Technology (COBIT)—Created by ISACA, formerly known as the Information Systems Audit and Control Association, this framework is an internationally recognized best practice. Keep in mind that although many are still using COBIT 5.0, there is a newer version, COBIT 2019, that has some additions.

In many ways, COBIT is “one-stop shopping” for SOX security policies and controls. The controls within COBIT are a rich range of activities: strategic planning, governance, life cycle, implementation, production support, and monitoring. The framework fits in and supports the COSO framework. The COBIT framework allows COSO to focus on the business side while COBIT focuses on the IT side. By leveraging both, you are able to bridge control requirements, technology issues, business risk, and shareholder concerns. The reason the framework is so popular among regulators, auditors, and IT risk professionals is that if you implement the COBIT framework, you are most likely SOX 404–compliant.

The Family Educational Rights and Privacy Act (FERPA) was put into law in 1974. This law applies to educational institutions such as colleges and universities. Any educational institution must protect the privacy of its student records and must provide students access to their own records. This gives students a way to correct errors and control disclosure of their records.

The Family Policy Compliance Office of the U.S. Department of Education enforces the act. The law broadly defines education records as any information related to the educational process that can uniquely identify the student. This has been widely interpreted as any student information, from financial means to class lists to grades. The student records can be in any form, from handwritten notes to digital files. There are exclusions such as law enforcement or campus security records. For the purpose of this discussion, the important point is that this broad set of student records (in any form) must be protected.

To be FERPA-compliant, security policies must contain the following key elements:

• Awareness—The school must post its FERPA security policies and provide awareness of them.
• Permission—Generally, schools must have recorded permission to share the student’s education records.
• Directory information—The school can make directory information (such as name, address, telephone number, and date of birth) about the student publicly available but must provide the student with a chance to opt out of such public disclosure.
• Exclusions—The school can share information without permission for legitimate education evaluation reasons as well as for health and safety reasons.

Security policies must ensure records are kept when student permissions are not obtained under the exclusions. In addition, policies must ensure that opt-in and opt-out records are properly maintained for historical purposes to record student permissions.

In January 2013, two important changes were made to the law. First, it became easier to share records with child welfare agencies; for example, child welfare agencies would be able to confirm that children in foster care are actively attending school. Second, the change eliminates some requirements to notify parents when school records are being released—to a court, for example.

The Children’s Internet Protection Act (CIPA) was put into law in 2000. The law tells schools and libraries that receive federal funding that they must block pornographic and explicit sexual material on their computers. The law attempts to limit children’s exposure to such material.

The Federal Communications Commission (FCC) establishes the rules that schools and libraries must follow. The CIPA regulation was challenged in a lawsuit heard by the Supreme Court. The basis of the challenge was that restricting access to information is unconstitutional. Additionally, there were questions about whether the technology would end up blocking sites not originally intended by the law. The result of the court challenge was mixed. The court held that the CIPA law was constitutional; however, the courts do require schools and libraries to unblock sites when requested by an adult. The FCC has several publications on CIPA available at http://www.fcc.gov/cgb/consumerfacts/cipa.html.

Here are key CIPA components that your security policies must include:

• Awareness—The school or library must post its CIPA security policies and provide awareness of them.
• Internet filters—Best efforts must be made to keep Internet filters current so that only the targeted material intended by CIPA is blocked.
• Unblocking—There must be a process to allow the filter to be unblocked or disabled for adults who request access to blocked sites.
• Education—Children must be provided education on Internet safety and on cyberbullying and how to respond.