Computer Security Act of 1987 was repealed by the Federal Information Security Management Act (FISMA) of 2002, which is discussed next.
U.S. Federal Information Security Management Act (FISMA) of 2002
The Federal Information Security Management Act, commonly referred to as FISMA (pronounced “fizz-muh”), is a U.S. law enacted in 2002 that greatly extends the Computer Security Act of 1987. FISMA acknowledges the importance of information security to the United States' economic and national security interests and requires that all U.S. federal government agencies and nongovernment organizations that provide information services to these agencies conduct risk-based security assessments that align with the NIST Risk Management Framework (RMF).
Industry Standards and Other Compliance Requirements
Aside from national, state, and local laws and regulations, your organization may be required to comply with certain regulations and standards based on your industry or the type of services you provide. The most prominent industry standards that you should be aware of include the following:
U.S. Sarbanes–Oxley Act of 2002 (SOX)
System and Organization Controls (SOC)
Payment Card Industry Data Security Standard (PCI DSS)
U.S. Sarbanes–Oxley Act of 2002
Following several high-profile corporate and accounting scandals, the SOX was enacted in the United States to reestablish public trust in publicly traded companies and public accounting firms. SOX required companies to implement a wide range of controls intended to minimize conflicts of interest, provide investors with appropriate risk information, place civil and criminal penalties on executives for providing false financial disclosures, and provide protections for whistleblowers who report inappropriate actions to regulators.
Under SOX, the Public Company Accounting Oversight Board (PCAOB) was established as a nonprofit organization responsible for overseeing the implementation of SOX. PCAOB's “Auditing Standards” identify the role that information systems play in maintaining financial records and requires auditors to assess the use of IT as it relates to maintaining and preparing financial statements. As part of PCAOB standards, auditors should broadly consider information security risks that could have a material impact on a company's financial statements. Even though SOX is largely a financially focused law, the regulation has a real and growing impact on IT and information security.
System and Organization Controls
Often confused with SOX (discussed previously), SOC stands for System and Organization Controls and is an auditing framework that gives organizations the flexibility to be audited based on their own needs. There are three commonly used types of SOC audits and reports, aptly named SOC 1, SOC 2, and SOC 3. The three audit and report types align with standards outlined in Statement on Standards for Attestation Engagements (SSAE) 18, which was published by the American Institute of Certified Public Accountants (AICPA) in 2017 (with amendments made via SSAE 20 in 2019).
SOC 1: An audit and compliance report that focuses strictly on a company's financial statements and controls that can impact a customer's financial statements. A company that performs credit card processing is likely to require a SOC 1 audit and compliance report.
SOC 2: An audit and compliance report that evaluates an organization based on AICPA's five “Trust Services principles”: privacy, security, availability, processing integrity, and confidentiality. Many organizations undergo SOC 2 auditing and present a SOC 2 report to regulators and customers to demonstrate compliance with industry standard security controls.
SOC 3: This is a “lite” version of a SOC 2 report and abstracts or removes all sensitive details. A SOC 3 report generally indicates whether an organization has demonstrated each of the five Trust Services principles without disclosing specifics (like exactly what they do or don't do). Companies make SOC 3 reports available to the public and restrict SOC 2 reports to trusted parties.
Payment Card Industry Data Security Standard
If your organization handles payment card information (i.e., credit or debit cards), you are likely required to demonstrate PCI DSS compliance. PCI DSS is a proprietary security standard established in 2004. PCI DSS establishes technical and operational requirements for merchants and service providers that accept or process cardholder data and/or sensitive authentication data, as well as for software developers and manufacturers of the applications and devices used in payment card transactions.
NOTE The Payment Card Industry Security Standards Council (PCI SSC) was formed in late 2006 with the goal of ongoing management of the PCI DSS. The PCI SSC is composed of MasterCard Worldwide, Visa International, American Express, Discover Financial Services, and Japan Credit Bureau. To learn more about the Council and the PCI DSS, visit www.pcisecuritystandards.org.
The PCI DSS includes more than 200 security controls organized into 12 requirements, further categorized into 6 goals that generally align with security best practices. Per the PCI SSC, the PCI DSS covers the following:
Build and Maintain a Secure NetworkRequirement 1: Install and maintain a firewall configuration to protect cardholder data.Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect Cardholder DataRequirement 3: Protect stored cardholder data.Requirement 4: Encrypt transmission of cardholder data across open, public networks.
Maintain a Vulnerability Management ProgramRequirement 5: Use and regularly update antivirus software or programs.Requirement 6: Develop and maintain secure systems and applications.
Implement Strong Access Control MeasuresRequirement 7: Restrict access to cardholder data by business need to know.Requirement 8: Assign a unique ID to each person with computer access.Requirement 9: Restrict physical access to cardholder data.
Regularly Monitor and Test NetworksRequirement 10: Track and monitor all access to network resources and cardholder data.Requirement 11: Regularly test security systems and processes.
Maintain an Information Security PolicyRequirement 12: Maintain a policy that addresses information security for employees and contractors.
Although PCI DSS is not yet a legal requirement, it is often a contractual requirement, and a prime example of an industry standard that is used to mandate, enforce, and audit security standards for applicable organizations across almost all jurisdictions. Because it is not a legislation, PCI DSS is not governed by or enforced by any government body. Instead, compliance with PCI DSS is assessed and enforced by the payment card companies (e.g., Visa, Mastercard, American Express, etc.) mentioned earlier in this section. Failure to satisfy PCI DSS requirements can cost an organization its ability to receive and process such payment card transactions.
Privacy Requirements
Privacy entails limiting access to personal information to authorized parties for authorized uses; in essence, privacy is maintaining the confidentiality of personal information specifically (as opposed to all sensitive data, in general). As more and more of our personal data moves online, privacy has become one of the biggest security-related concerns for regulators, organizations, and users.
Personal information such as your name, address, and Social Security number is considered personally identifiable information, which must be kept confidential. PII is often subject to some combination of contractual and regulatory privacy requirements. While the source of the requirements may vary, the seriousness with which organizations should take these requirements does not change. As a CISSP, you must know what PII and other personal data your organization handles,