Dealing with regulatory requirements is a hard task for many organizations. Troubles come from two directions. First, information technology personnel rarely have a legal background. Second, most requirements lack technical depth. This is because people drafting the regulations lack the information technology background. Many regulations are vague in their requirements. Therefore, proper technologies, depth of controls, and control frameworks become an important tool. Part 2 of this book provides an overview of different frameworks you can leverage.

Nevertheless, it is first important to understand why these requirements exist. In addition, you must have a broad understanding of which requirements exist.

Regulatory requirements exist at different levels. Those levels include state, federal, and international. In addition, industry consortiums propose requirements. It is important to know which regulations apply to your organization. This helps you ensure you stay compliant and prevents trying to solve the same problem twice. In most cases, you should consult corporate counsel or legal to help identify which regulations apply.

So what sources do people consult for IT compliance requirements? In 2005, the Burton Group asked attendees at one of its conferences this very question. The results were as follows:

Regulatory compliance is nothing new. However, government oversight and strong compliance regulations greatly increased in the early 2000s. This was mainly due to corporate scandals—Enron, WorldCom, and others. Consider how quickly the Web and other information technologies advanced. Then, the increased focus on IT and IT security becomes more apparent. Yet regulatory requirements and industry standards are not without their critics. Critics accuse requirements regulating publicly traded companies of putting U.S. corporations at a disadvantage. At the same time, they discourage listing on the U.S. stock exchanges. Further, critics describe laws regulating federal information systems as bureaucratic without helping security. Furthermore, consider the payment card standards. Critics call these standards unfair for small businesses, and criticize the standards for failing to provide enough security.

The Federal Information Security Management Act of 2002 (FISMA) is contained within the E-Government Act of 2002, Public Law 107-347, as Title III. This act grants the importance of sound information security practices. It also controls the interest of national security and the economic well-being of the United States.

The purpose of FISMA is to do the following:

The need for FISMA started during the 1990s. Government agencies became more like commercial organizations. They started to transition from traditional mainframe computing to internetworked systems. As the Web became commonplace, federal agencies started to develop their own Web sites and offer online services. There was a sudden awareness that systems were more open and vulnerable than before. This eventually got the attention of Congress.

FISMA tasked the National Institute of Standards and Technology (NIST) to develop and set standards and guidelines. These apply only to federal information systems. Standards help categorize information and the systems. They are based on a risk-based approach. They include the minimum information security controls. For example, standards include the management, operational, and technical controls to apply to the information systems.

In support of FISMA, NIST developed the following publications:

To comply with FISMA, the appointed inspector general of the agency performs a separate, annual evaluation. The evaluation first tests the value of the IT security policies, procedures, and practices. A subset of the information systems within the particular agency is tested. If no inspector general exists, an independent external auditor performs it. The external auditor submits the results to the Office of Management and Budget (OMB). The OMB is a cabinet-level office within the Executive Office of the President of the United States with oversight responsibilities. The OMB compiles the data from each agency. The OMB then prepares an annual report to Congress on compliance with the act.

At first, it appears only federal agencies need to worry about compliance, but this is not true. Federal agencies, for example, must care about their own systems as well as the systems of other contractors or organizations supporting the agencies. Any company or organization that expects to conduct business with the federal government needs to concern itself with FISMA.

The United States Department of Defense (DoD) is a federal department. It is responsible for all agencies of the government relating to national security and the military. The DoD imposes many requirements upon the management of their information systems for both DoD-related systems. The same goes for organizations that work with, contract, and provide services for the DoD. These requirements are within many federal laws and regulations. These laws span over a period of decades. Given the fast-paced change around information technology, requirements have been rapidly evolving. This is especially true as systems have moved from traditional mainframe computing to more distributed and interconnected computing.

Information resource management (IRM) is the process of managing information resources to improve performance and accomplish the mission of defense agencies. The Paperwork Reduction Act of 1980 introduced IRM into law. This act provides the OMB with oversight concerning IRM. This oversight assumes that within the OMB's policies, individual agencies can maintain their own IRM.

In later years, various amendments strengthened the original implementation of the law. Most notably, agencies needed to develop processes to acquire, control, and assess information systems. In spite of these laws, the 1990s saw a large rise of distributed networking technology. This only created more IT management issues for the DoD.

In 1996, Senator William Cohen led further reform. The reform streamlined the process of acquisition of IT resources. The position of chief information officer (CIO) was formed within federal departments and agencies. This CIO position was previously the senior IRM official. Now the title was more like the civilian role and reported directly to the agency head. This gave it a more strategic focus with greater accountability to solve the IT problems plaguing the agencies.

There are many laws and regulations to the DoD. These laws are both external and internal. They guide the operation, management, and protection of information systems. A summary of the key laws, regulations, and policies include the following:

Certification and Accreditation (C&A)

As part of FISMA, all federal systems and applications must adhere to well-known security requirements. These requirements are documented and authorized. This process is known as Certification and Accreditation (C&A). It is essentially a process of auditing federal systems before putting them in a production environment. C&A recertifies every three years. The C&A process ensures that efforts are made to mitigate risks. Security controls on information systems must be properly implemented and maintained. It supports risk-management activities. At a high level, C&A allows the government to conduct consistent and repeatable assessments of security controls. They also gain awareness into risks and allow authorized officials to more confidently accredit or validate a system. The accreditation aspect is an accountable process. An official reviews the applied security controls. Then, the official approves or accepts risks to the system and organization.

Accreditation holds you accountable for the decision. Therefore, it is important to make the decision after reviewing documentation and supporting evidence. All must be complete, valid, and accurate. This is the certification part of C&A. Certification includes the technical controls as well as the management and operational controls.

Certification and Accreditation use three methodologies:

• DoD Information Assurance Certification and Accreditation Process (DIACAP)

• National Information Assurance Certification and Accreditation Process (NIACAP)

• NIST Guide for the Security Certification and Accreditation of Federal Information Systems

Of the three, most agencies, including civilian organizations, embrace the NIST methodology.

All three methodologies are similar in their intent and require a thorough review of the systems. The information system owner submits a package of documents or accreditation package. The accrediting authority audits the package. A decision is made about accreditation for the information system. An accreditation package includes the following documents:

FYI

DIACAP, the first C&A methodology discussed, replaces the DoD Information Technology System Certification and Accreditation Process (DITSCAP) as the chief process for evaluating and accrediting Department of Defense information systems. At the time of this writing, DoD agencies and military branches are currently switching over. For example, the Department of the Navy expects their transition to be complete in fiscal year 2012.

• System security plan—The requirements, agreed security controls, and supporting documents. Examples are network diagrams, data flows, and risk assessment.

• Security Assessment report—The evaluation results of security controls. This report might also include recommendations.

• Plan of action and milestones—The details mitigating controls. You may plan or apply controls to reduce vulnerabilities. You can also plan or apply measures to correct any deficiencies.

Conducting the C&A process requires four phases. Assigned individuals carry out the various tasks in each phase. Figure 2-1 illustrates the following four phases:

• Initiation—Before certification begins, initiation ensures all parties are in agreement with the plan. Initiation also ensures that appropriate documentation is completed.

• Security certification—Security certification involves the process of actually assessing the security controls on the information system. It assesses controls to ensure they are implemented and operating as planned. A subsequent plan notes and addresses any deficiencies for remediation. When the assessment is done, the security certification documentation is created.

• Security accreditation—With the security certification information, the system might receive accreditation. Remaining system vulnerabilities are considered. If the resulting risk is acceptable, accreditation results in one of three ways:

  • Authorization

  • Denial of authorization

  • Interim authorization

• Continuous monitoring—Continuous monitoring provides ongoing assurance that the security controls stay in place. Configuration management and security monitoring alerts the authorizing authority if changes affect systems.

Figure 2-1. Four phases of C&A.

Figure 2-2. System vulnerabilities, security controls, and mission risk.

Security certification and accreditation pertain to a specific information system. They don't determine the risk level to the agency. To determine risk at the higher agency level, you must take a more holistic view. This must consider all information systems. Figure 2-2 shows how information system controls and vulnerabilities relate to the agency's mission risk.

Information Assurance (IA)

Department of Defense Directive 8500.1 establishes policy and assigns responsibilities under Section 2224 of title 10 USC. They achieve DoD information assurance (IA) through defense in depth and integrating personnel, operations, and technology. IA includes all DoD-owned and DoD-controlled information systems that use DoD information. This is regardless of sensitivity. Information assurance is the controls that protect and defend information and information systems by ensuring confidentiality, integrity, and availability. It also provides authentication and nonrepudiation.

DoD needs to protect information and the systems that support that information. Information assurance grasps the natural vulnerabilities in systems that transmit, store, or process data. The vulnerability stems from the following:

• Reliance upon commercial information technology solutions and services

• Increased complexity through interconnectedness

• Fast pace in which technology changes

• Distributed and nonstandard management structure of a global network

• Low cost of entry for attackers

Protecting the confidentiality, integrity, and availability are common security objectives for information systems. This forms the foundation for information assurance.

Note

Confidentiality, integrity, and availability (CIA) are often referred to as the security triad or the CIA triad.

• Confidentiality—Ensuring that information is not disclosed to unauthorized sources. Loss of confidentiality occurs when data is open to some unauthorized entity or process.

• Integrity—Ensuring the protection against unauthorized modification or destruction of data. Integrity also includes the quality of an information system regarding logical completeness and reliability of the hardware, software, and data structures.

• Availability—Ensuring the timely and reliable access to data and services for authorized users.

Figure 2-3 shows these three security objectives as a protective triangle. If any side of the triangle fails, security fails. In other words, threats to the confidentiality, integrity, or availability represent risk.

In addition, the DoD considers authentication and nonrepudiation as two additional measures. These two are joined along with confidentiality, integrity, and availability. Authentication establishes the substance of a transmission, message, and originator. It also verifies an entity that has authorized access to information. Nonrepudiation provides assurance of proof of delivery and proof of identity. This way, neither party can later deny having processed or received the data.

You can easily describe implementing information assurance as a system for managing risk. It is built upon five principles defined within DoD Directive 8500.2, "Information Assurance (IA) Implementation," These five competencies are as follows:

• The ability to assess security needs and capabilities

• The ability to develop a purposeful security design or configuration that adheres to a common architecture and maximizes the use of common services

• The ability to implement required controls for safeguards

• The ability to test and verify

• The ability to manage changes to an established baseline in a secure manner

In 1996, a U.S. federal law called the Information Technology Management Reform Act of 1996 was passed. The goal was to improve how the federal government acquires, uses, and disposes of information technology. The act is now called the Clinger-Cohen Act (CCA), named after its cosponsors. The CCA worked with other related legislation to spawn the DoD's Acquisition of IA strategy, DoD 5000.02 to ensure compliance. The Acquisition Information Assurance Strategy provides the groundwork for Certification and Accreditation. However, it is a separate process, which requires compliance. Information assurance compliance is required for any IT system, including those IT-based processes that are outsourced.

Figure 2-3. The CIA triad.

Beyond Information Assurance—CIIA

Information assurance as a concept has been around for a long time. It is the defined strategy for the Department of Defense since the early 2000s. However, emphasis on information systems and threats has risen. The idea of assurance of information has grown to better protect the DoD from current and future threats. In addition, it accelerates the secure change to a more network-centric setting. The new strategy calls for Cyber, Identity, and Information Assurance (CIIA).

The Department of Defense sets up information assurance from "five pillars." The five pillars are assurance of confidentiality, integrity, availability, authentication, and nonrepudiation. One criticism might be that authentication and nonrepudiation are the only means of assuring the security triad. On the other hand, confidentiality, integrity, and availability are attributes of the information or information systems.

In 2009, the DoD issued new guidance replacing the DoD 2004 Information Assurance Strategy. This new strategy is all about information assurance. The strategy introduced two new levels of assurance. The two new levels are cyber assurance and identity assurance. Cyber assurance prepares network-centric missions and supporting infrastructure to respond to harmful events more quickly. Identity assurance is about maintaining identity, security, and privacy.

The Sarbanes-Oxley Act of 2002, also known as Sarbox or SOX, is a U.S. federal law. It is the result of the Public Company Account Reform and Investor Protection Act and Corporate Accountability and Responsibility Act. Sarbanes-Oxley dramatically changed how public companies do business.

The bill stems from the fraud and accounting debacles at companies such as Enron and WorldCom. Former President Bush characterized the act "as the most far reaching reforms of American business practices since the time of Franklin Delano Roosevelt." The act's primary purpose was to restore public confidence in the financial reporting of publicly traded companies. As a result, the act mandated many reforms to enhance corporate responsibility, enhance financial disclosures, and prevent fraud. Sarbanes-Oxley consists of the following 11 titles:

Sarbanes-Oxley is quite large and contains many reforms to rally public confidence. It also improves corporate accountability and helps to avoid corporate fraud and dishonesty. Two sections receive much of the attention, especially of IT. The first is Section 302, "Corporate responsibility for financial reports." The second is Section 404, "Management assessment of internal controls." These two sections place vast constraints on IT security. Although neither section mentions IT or IT security, financial accounting systems rely heavily on IT infrastructure. Thus, it has strongly driven the subject of IT security into the boardroom.

Section 302 requires the CEO and CFO to personally certify the truthfulness and accuracy of financial reports. They start and make internal controls. Then, they must assess and report upon the internal controls around financial reporting every quarter. Section 404 goes a step further. Section 404 requires the company to provide proof. Again, they must assess the effectiveness of their internal controls, to which a public accounting firm must audit and attest. They then publish this information in the company's annual report.

SOX is lengthy and is specific in many areas, for example, criminal penalties for noncompliance. It still is very high level and leaves a lot of room for interpretation, especially concerning IT controls. SOX does not directly address IT control requirements. As a result, you need to become familiar with a couple of publications. These include the auditing standards created by the PCAOB and the SEC's release on management guidance—17 CFR Part 241. In this codification, the SEC issued further interpretation and guidance regarding Section 404. It provides "an approach by which management can conduct a top-down, risk-based evaluation of internal control over financial reporting." PCAOB also made a formal process to further define the criteria within Section 404. This process became Auditing Standard No. 2. This standard supersedes Auditing Standard No. 5. Some notable changes to provide greater clarity and a more prescriptive approach include the following four areas:

The standard also states that the auditor should use the "same suitable, recognized control framework" as the management of the company they are auditing. Furthermore, it even goes as far to suggest a suitable framework. That framework is the Committee of Sponsoring Organizations (COSO) of the Treadway Commission. Chapter 4 explores frameworks such as COSO and others in greater depth.

Also known as the Financial Modernization Act of 1999, the Gramm-Leach-Bliley Act (GLBA) repeals parts of the Glass-Steagall Act from 1933. The Glass-Steagall Act prohibited banks from offering investment, commercial banking, and insurance services all under a single umbrella. GLBA deregulates the split of commercial and investment banking.

GLBA also provides provisions for compliance within Sections 501 and 521 to protect the financial information held by the industry. This protection is on behalf of the consumers. GLBA generally applies to financial institutions or any organization "significantly engaged" in financial activities. Examples include banks and securities firms. More examples are firms dealing with mortgages, insurance, tax preparation, debt collection, and much more. The FTC maintains and enforces GLBA.

To protect personally identifiable information (PII), GLBA divides privacy requirements into three principal parts. Those parts are the Financial Privacy Rule, Safeguards Rule, and Pretexting provisions:

The Financial Privacy Rule requires financial institutions to provide notices to their customers. The notices explain their privacy policies, specifically covering the information collection and sharing practices of the company. The consumer is also given control over limiting the sharing of their information or opting out. If the financial institution changes its policy, they must provide another notice to the consumer.

The Safeguards Rule requires financial institutions to develop an information security policy to consider the nature and sensitivity of the information they handle. The plan must include and the company must comply with the following:

Likely, most organizations will protect against pretexting as part of their information security program. The best defense against pretexting is not technical, but rather awareness and training. Training is for both employees and customers. The Pretexting provision makes it illegal to do the following:

U.S. Congress enacted the Health Insurance Portability and Accountability Act (HIPAA) in 1996. The primary purpose of the statute is twofold. First, it provides for helping citizens maintain their health insurance coverage. Second, it improves efficiency and effectiveness of the American health care system. It does so by combating waste, fraud, and abuse in both health insurance and the delivery of heath care. The U.S. Department of Health and Human Services (HHS) is responsible for publishing requirements and for enforcing HIPAA laws. However, the Office of Civil Rights, a subagency of HHS, administers and enforces the Privacy Rule and Security Rule of HIPAA. These laws are divided across five titles, which include the following:

Much of the focus around HIPAA is within the first two titles. Title I offers protection of health insurance coverage without regard to pre-existing conditions to those, for example, who lose or change their jobs. Title II provides requirements for the privacy and security of health information. This is often referred to as Administrative Simplification. The broader law calls for the following:

As a result, the HHS has provided five rules regarding Title II of HIPAA. These include the Privacy Rule, the Transactions and Code Sets Rule, the Security Rule, the Unique Identifiers Rule, and the Enforcement Rule. These five rules impact and affect information technology operations within organizations. Specifically, the Privacy Rule and Security Rule affect information security. HIPAA is primarily concerned with protected health information (PHI). PHI means individually identifiable health information. PHI relates to physical or mental health of an individual. It can also relate to the delivery of health care to an individual as well as payment for the delivery of health care.

The Privacy Rule went into effect in 2003. It regulates the use and disclosure of PHI by covered entities. A covered entity, for example, includes health care providers, health plans, and health care clearinghouses. In many ways, the Privacy Rule drives the Security Rule. Under the law, covered entities are obligated to do the following:

The Security Rule followed the Privacy Rule. Unlike the Privacy Rule, however, the Security Rule applies just to electronic PHI (ePHI). The Security Rule provides for the confidentiality, integrity, and availability of ePHI, and contains three broad safeguards. These safeguards include the following:

Each of the preceding safeguards consists of various standards. All are required or addressable. Required rules must be implemented, but addressable standards provide flexibility. This way, an organization can decide how to reasonably and appropriately meet the standard. Bear in mind, however, that addressable does not mean optional.

Administrative safeguards primarily consist of policies and procedures. They govern the security measures used to protect ePHI. Table 2-1 provides a summary of the administrative safeguards, including the required and addressable standards.

Physical safeguards include the policies, procedures, and physical controls put in place. These controls and documentation protect the information systems and physical structures from unauthorized access. The same goes for natural disasters and other environmental hazards. The physical safeguards include the four standards shown in Table 2-2, along with the implementation specifications.

Technical safeguards consist of the policies, procedures, and controls put in place. These safeguards protect ePHI and prevent unauthorized access. Table 2-3 lists the five safeguards and corresponding implementation specifications.

Although covered entities must comply with the previously listed safeguards and implementation specifications, there isn't a safeguard listed that should surprise organizations. In fact, most of these safeguards are addressed through best practices for any sensitive information.

In 2006, the Final Rule for HIPAA was issued—the Enforcement Rule—and set the penalties to be levied as a result of HIPAA violations. The Enforcement Rule also established the procedures for investigations and hearings into noncompliance. The potential for increased enforcement of noncompliance to HIPAA was later introduced in 2009 when the Health Information Technology for Economic and Clinical Health (HITECH) Act was signed into law. HITECH was signed in as part of the American Recover and Reinvestment Act (ARPA). In addition to laying the groundwork for increased enforcement, HITECH also adds requirements for a breach notification. The notification is what an organization puts in action should PHI becomes disclosed in a readable, that is, nonencrypted, format.

The Children's Internet Protection Act (CIPA) is a federal law introduced as part of a spending bill that passed Congress in 2000. The FCC maintains and enforces CIPA. This act addresses concerns about children's access to explicit content online, such as pornography at schools and libraries, by requiring the use of Internet filters as a condition of receiving federal funds. CIPA is a result of previous failed attempts at restricting indecent content. The Communications Decency Act and the Child Online Protection Act faced Supreme Court challenges over the United States First Amendment. The reason was the act violated the right of free speech contained within the Constitution.

CIPA does not provide for any additional funds for the purchase of mechanisms to protect children from explicit content. Instead, conditions are attached to grants and to the use of E-Rate discounts. "E-Rate" is a program that makes Internet access more affordable for schools and libraries.

CIPA requires schools and libraries to certify compliance to implement an Internet safety policy and implement "technology protection measures." This means having technology in place that blocks or filters Internet access that is either obscene, harmful to minors, or represents child pornography. This includes implementing a safety policy and controls that address the following:

Prior to implementing the policy and controls, however, the law also requires schools or libraries to first provide public notice and to hold a public hearing to address the proposed Internet safety policy.

You might have noticed that the term "inappropriate matter" could be considered vague and controversial. As a result, the act is clear in stating that the government may not establish the criteria for making such a determination. The act states that the determination is made at the local level by the school board, local educational agency, or library.

Finally, schools and libraries must comply with one more step before they can receive the E-Rate. They must certify they have an Internet safety policy in place meeting the preceding requirements. Noncompliance with the law occurs if there is a failure to submit for certification. In this case, the institution will not be eligible for services at the discounted rate. In addition, failure to ensure the use of the computers in accordance with a certification will be required to reimburse all funds and discounts for the certification period.

The Family Educational Rights and Privacy Act (FERPA) of 1974 is a U.S. federal law. FERPA protects the privacy of student education records. It also provides parents certain access rights to the student's educational records. Parental access rights stop once the student enters post-secondary education or the student turns 18 years old. The regulation applies to educational institutions that receive federal funding from the U.S. Department of Education.

Educational agencies or institutions should notify parents or eligible students of their rights under the law annually. The notice includes the right to do the following:

As the name implies, directory information is personal data that you can find in publicly available sources. For example, a publicly available source could be a phone book or yearbook. Such information is not considered a harmful invasion of privacy. Examples of directory information include the following:

Nondirectory information, on the other hand, includes, for example, Social Security numbers and transcripts.

In 2008, two relevant documents were published. The first was "Joint Guidance on the Application of the Family Educational Rights." The second was the "Privacy Act (FERPA) and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) to Student Health Records." Many schools and universities operate health clinics. Thus, it is important that educational and health records kept at health facilities on campus are only subject to FERPA and not HIPAA. If the institution is a post-secondary school that provides health care to nonstudents, the health information of the nonstudent patients is subject to HIPAA.

Compliance with the law is typically the responsibility of the registrar's office, which in turn works with legal counsel. However, IT professionals should be involved in the process and understand FERPA to ensure compliance. The act was originally drafted in 1974, so distributed, networked computer technology was not around yet. Therefore, interpretation of the law is sometimes needed. Recent changes do help accommodate this technical evolution. Consider that the real meaning of FERPA is access and confidentiality. Access in that parents or eligible students must be permitted access to their records. Confidentiality in that education records must be protected and not released without written consent. Then, consider the number of electronic records relating to students that are likely to be stored on file servers and within databases. It is more difficult because IT makes tasks so easy, such as submitting and retrieving grades electronically, Web-based financial aid, and course registration.

Under the FERPA Final Rules issued in 2008, FERPA does address further requirements and guidelines around information systems.

The changes also recommend "educational agencies and institutions to utilize appropriate methods to protect education records, especially in electronic data systems." The update also addresses several examples of data breaches and the unauthorized disclosure of information. It also expresses concerns that data may be compromised as a result of failure to implement proper security controls. Yet the update does not dictate how to properly safeguard electronic records, but instead offers additional resources, for example, NIST, on how to protect the information.

FERPA now provides suggestions on what to do in the case of an inadvertent release of data on the Internet or other unauthorized disclosure. In case of unauthorized disclosure, FERPA doesn't require notification. That is, the school does not have to issue direct notices to the parents or students. However, it does require the school to maintain a record of the disclosure. FERPA advises that direct notification should occur if the unauthorized disclosure might lead to identity theft. Nevertheless, other laws might still require institutions to provide direct notification.

Chapter 1 introduced you to TJX, a company that suffered a serious breach in which it had millions of credit card numbers stolen. TJX was not the first, however, nor are they the last. Individual credit card companies started formulating programs to prevent breaches from occurring. These programs ensured that merchants meet baseline security requirements for how they store, process, and transmit payment card data.

The five leading credit card companies—Visa, MasterCard, American Express, JCB, and Discover—came together and formed the Payment Card Industry Security Standards Council (PCI SSC) in 2004. To help organizations that process card payments prevent credit card fraud, PCI SSC created the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is a set of requirements that prescribe operational and technical controls to protect cardholder data.

Adhering to PCI DSS requires three ongoing steps:

PCI SSC manages the overall program. However, card vendors have their own programs for compliance and enforcement. Determination of requirements depends upon the volume of card transactions that take place. Any organization, however, that holds, processes, or passes cardholder data must undergo annual assessment. The assessment is required regardless of amount. In general, organizations that process a smaller number of transactions might only need to complete a Self-Assessment Questionnaire (SAQ). Organizations with high-volume transactions must meet other requirements, such as assessment by an independent firm. The firm must be designated as a Qualified Security Assessor (QSA). In addition, requirement 11.2 requires vulnerability scans. The scans are done quarterly and are performed by a PCI Approved Scanning Vendor (ASV).

PCI DSS is unlike most regulatory laws in one way. It is very specific in regard to requirements and expectations. The requirements generally follow security best practices and use the 12 high-level requirements, aligned across six goals, as shown in Table 2-4. Each requirement listed in the table consists of various subrequirements. Also included are procedures for testing. These must be documented as either being in-place or not in-place.

Consider requirement 8, for example. It requires a unique ID to be assigned to each person with computer access. Within the security standard, this requirement actually consists of 21 subrequirements. Many of them are very specific, for example:

Since PCI DSS started, the Security Council has released several supplemental documents, including the following:

Based upon the Fair and Accurate Credit Transactions Act of 2003, the Red Flags Rule was created to establish procedure for the identification of possible instances of identity theft. The FTC along with the credit union and banking regulatory agencies created the Red Flags Rule. They are also responsible for enforcing it. The Red Flags Rule requires all financial institutions and creditors to implement an Identity Theft Prevention Program. The goal is to detect warning signs or "red flags" of identity theft.

The law applies to financial institutions, such as banks, savings and loan associations, or credit unions. The law applies to any entity where a consumer has an account that conducts payments or transfers, such as a checking account. In addition, the law also applies to creditors. Creditors extend, renew, or continue credit. Examples include finance companies, mortgage brokers, utility companies, and automobile dealers. In both cases, the law only applies to financial institutions and creditors with covered accounts. Creditors use a covered account when there is a foreseeable risk of identity theft. A common example is an account used for household purposes. This includes such things as credit card accounts, mortgage loans, broker margin accounts, checking accounts, and so on.

To comply with the Red Flags Rule, financial institutions and creditors must follow the four basic elements. These involve having appropriate policies and procedures in place to do the following:

Financial institutions are first responsible for identifying red flags for covered accounts. The regulation does not demand specific red flags. Instead, it requires the financial institution or creditor to identify and create a list of red flags on its own. The regulation offers guidelines, however, in identifying red flags. Table 2-5 lists the five categories provided by the regulation and includes an example of each.

After creating the list of relevant red flags from the preceding categories, the institutions must then put programs and procedures in place to be able to detect the red flags. The regulation provides very little guidance on how to do this, other than saying what most institutions are already doing. For example, guidance might include getting unique information, verifying the person opening the account gives accurate and real information, and ensuring transactions are monitored. For many organizations, effective detection relies upon technology solutions that specifically focus on solutions around authentication and fraud monitoring.

Next, the financial institutions and creditors must respond to the red flags. This prevents and lessens identification theft. Organizations must respond accordingly. For example, this ranges from contacting the customer to notifying law enforcement.

Finally, financial institutions and creditors should know that risks to customers and themselves are constantly changing. On one hand, business changes can affect its risk tolerance. Examples include mergers and acquisitions as well as changes in the type of accounts offered to customers. On the other hand, methods of identity theft and how it's detected and prevented are constantly changing. A game of cat and mouse is the best way to describe the relationship among fraudsters, law enforcement, and vendors that provide prevention and detection tools.

In addition to private industry standards, such as PCI DSS, companies must be concerned with and comply with many laws. Such requirements might affect only specific industries, whereas others can span across industries. PCI DSS, for example, generally affects any organization that holds, processes, or passes payment cardholder information, regardless of industry. HIPAA, on the other hand, primarily affects the health care industry, and Sarbanes-Oxley pertains to any publicly traded company.

Although compliance to regulations can touch many different groups within an organization, IT departments are increasingly discovering they need to stay abreast of the latest regulations as IT has become pervasive throughout organizations. It might seem overwhelming to keep up with the requirements of all the regulations, not to mention new ones. However, a sound governance, risk-management, and compliance program within organizations using a well-defined framework can make the process much more efficient and effective.