ACCESS CONTROL IS A TOOL we can use to help secure systems. It should never be viewed as an end result. In this chapter, we will discuss the various reasons access control is used in real-world situations. You will discover the important role access control plays in business, government, and critical infrastructures, and how it is used to enforce policies.
We will also discuss what happens when access controls fail. Security breaches can have serious implications ranging from loss of profitability to fines and prison time. The goal of this chapter is to highlight the important role access control plays in the larger scheme of business, governmental regulation, and the operation of critical infrastructures such as the electricity grid.
Modern corporations are required to be compliant with various government standards. Depending on the industry and the organization, various laws like the Health Insurance Portability and Accountability Act (HIPAA) for the health care industry and Sarbanes-Oxley (SOX) for public companies shape the business landscape, requiring organizations to adhere to these standards. Compliance is necessary from an organizational standpoint. It also ensures that organizations implement more secure business practices. Secure business practices helps organizations avoid the costs associated with security lapses. Another benefit is that secure business practices can enhance customer confidence by assuring customers that their private information is stored securely.
Creating and adhering to the requirements of these laws can be a difficult task initially. It is usually costly and time consuming to build a complaint infrastructure. Once an organization creates a compliance framework as a way to protect its sensitive information, compliance with the applicable government regulations can become the priority it needs to be.
In IT, it is imperative that you keep up to date with regulatory compliance laws. Understanding which regulations affect your business can help create a strategy for designing your infrastructure to meet the regulations. The U.S. compliance laws covered in this chapter are shown in Figure 4-1.
Your organization may already have various security measures in place to maintain compliance, but you must update and maintain them regularly. You must also keep thorough documentation of the systems and procedures that are in place. Your documentation shows the regulatory bodies which steps your organization has taken to be in compliance.
Note
Having controls already in place gives your organization a good start towards compliance. You should also set up auditing procedures to keep track of hardware, software, and other IT devices to understand what areas are at higher risk and need further protection.
Different industries need to deal with compliance in different ways. Companies in the financial and health care industries, for example, are more strictly regulated than companies in most other industries. Financial and health care companies should consider specialized software systems to help meet compliance and track compliance efforts. This is especially useful for companies that have periodic regulatory compliance audits.
Regulatory compliance is an important part of the modern business world. A company that complies with regulatory obligations builds consumer trust—consumers know their information and data is secure. Acting on regulatory requirements helps a corporation build and maintain a secure IT infrastructure, which saves it time and resources. In addition, keeping up to date with regulatory issues makes it easier to remain in compliance when laws and policies are updated in the future. The following sections cover several major regulations that may affect the organization or industry in which you work.
The Gramm-Leach-Bliley Act (GLBA), otherwise known as the Financial Modernization Act of 1999, is aimed primarily at the financial services industry. This covers not only banking but also insurance, securities, brokers, lenders, real estate settlement, tax preparers, and others.
Note
GLBA covers a wide range of businesses; however, not every type of business is included. GLBA specifically covers any institution that is significantly engaged in financial activities. This covers not only traditional financial institutions but also companies that offer self-financing, and debt collectors. For example, a university that offers student loans falls under GLBA.
GLBA takes compliance and information security outside of an IT-only world and into the realm of the entire company, requiring every department to be responsible for the security of consumer privacy. Information technology is a major component of the process, but the overall implementation of the security processes is not the sole responsibility of IT.
Under GLBA, policies should be drafted and finalized in a written format. GLBA requires companies to "develop, implement, and maintain a comprehensive written information security program that contains administrative, technical, and physical safeguards that are appropriate to the size and complexity of the entity, the nature and scope of its activities, and the sensitivity of any customer information."1
Companies are also required to implement a continuous risk management program. In this program, you must identify potential risks to your company's infrastructure and information. After your company meets GLBA's initial risk identification requirement, you must reassess for risks any time your business or technology changes. After the reassessment, you must update your written policies and procedures. Many companies utilize a configuration management policy to handle this process. These policies may require any IT project to go through a security audit and that you document the findings of the audit after project completion.
GLBA contains provisions for the protection of nonpublic personal information that financial institutions and their affiliates receive about individuals. The law regulates with whom and how the institution may share that information and provides consumers with the ability to opt out of some types of data sharing arrangements.
A company's privacy policy is more than just a note on its Web page. GLBA requires that companies notify customers of the privacy policy and receive acknowledgment from the consumer. The notice must be conspicuous and delivered as part of the transaction. If the customer acknowledges receipt of the policy, the company has fulfilled part of its obligations. The notice must remain accessible, and the company is obligated to communicate any change in the same manner.
Companies are obligated to select and retain service providers that are capable of maintaining appropriate safeguards for nonpublic customer information at issue. Your service contracts with providers should require them to implement and maintain these safeguards.
One of GLBA's major components requires companies to have a security program in place that limits access to and protects a consumer's financial data. The institution must protect against any perceived threats to the security and integrity of the consumer's information. Additionally, the institution is obligated to protect against the unauthorized access or use of customer information or records.
When discussing GLBA in the terms of access control policy, an organization should define who can access data and for how long. Any access to sensitive data must be logged to provide accountability to the company and deter misuse of the information.
Data security goes beyond storage and encompasses all aspects of an organization's policies, procedures, and equipment where you hold sensitive data. A company's storage systems must protect against unauthorized access. The company should always know who is accessing the data when, and why. Technical solutions and strict policies and procedures are all tools your company should use to protect sensitive customer information and prevent legal liabilities.
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 has two main parts. Title I protects health insurance coverage for workers and their families if they change or lose their job. Title II, known as the Administrative Simplification provisions, requires the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers. It also addresses security and privacy of health data. Title II has the most significant impact on IT departments.
The following Title II rules directly affect an IT department:
The Privacy Rule took effect on April 14, 2003. It regulates the use and disclosure of protected information held by covered entities. It establishes regulations for the use and disclosure of protected health information (PHI), which is any information that concerns health status, health care, or any payment for health care that can be linked to the individual. This is interpreted very broadly and includes all of an individual's medical record and payment history.
Note
A "covered entity" is a health care clearing house, health plan, health insurer, or medical service provider.
If HIPAA applies to your organization, you must protect this medical information, and may only be disclosed in the following circumstances:
To the individual within 30 days of a request
When the covered entity has obtained written permission of the individual
When required by law
To facilitate treatment, payment, or health care operations
When disclosing PHI, it's the covered entity's responsibility to disclose the minimum amount of information necessary. If your organization is a covered entity, you must secure all communications and transmission of PHI.
The Transactions and Code Set Rule of HIPAA requires a common standard for the transfer of all health information between health care providers and the organizations that process payment for these services. Before HIPAA, different entities had different methods to exchange information. This was a cumbersome and expensive system for health care providers. With HIPAA, all payees must accept a common standard for electronic data.
The Unique Identifier Standards Rule handles the creation and use of unique identifiers for providers, health plans, employers, and patients. The identifiers are as follows:
The employer identifier, which is based on the IRS-assigned Employer Identification Number
The patient identifier, which will be a standard unique way of identifying patients; currently on hold due to privacy legislation
The national provider identifier, which was originally developed for the Medicare system
The health plan identifier, which is a nine-digit number with a check digit developed for HIPAA
The Security Rule is a complement to the Privacy Rule that covers how PHI is secured. The Security Rule deals specifically with electronic protected health information (EPHI). It lays out three layers of security safeguards required for compliance: administrative, physical, and technical. For each type, the rule specifies various standards and implementation specifications.
If your organization is a covered entity, you must follow these administrative safeguards:
Adopt a written set of privacy procedures and designate a privacy officer who is responsible for developing all required procedures.
Reference policies and procedures to ensure organizational buy-in and management oversight to comply with documented security controls.
Identify employees or groups of employees who have access to EPHI in your procedures.
Restrict access to EPHI to only those employees who need the information for their job function.
Address access authorization, modification, and termination in your procedures.
Show that you are providing ongoing PHI training to employees.
Ensure all of your third-party vendors have a framework in place to comply with HIPAA regulations.
Implement contingency plans for responding to emergencies and ensure you have backup and recovery procedures in place for all PHI.
Perform internal audits to review HIPAA compliance.
Implement procedures for addressing and responding to security breaches.
Be sure to put these technical safeguards into action:
Protect information systems containing PHI from intrusion.
Note
When information flows over public network, you must apply some form of encryption. If the information is on a closed network, existing access controls are sufficient and encryption is optional.
Ensure the PHI contained within your systems are not changed or erased in an unauthorized manner.
Use data corroboration, such as the use of check sum, message authentication, and digital signature to ensure data integrity.
Authenticate the identity of all entities that your organization communicates with. You can do this with password systems, two- or three- way handshakes, telephone callbacks, and token systems.
Document all of your HIPAA procedures, and make this documentation available to the government to determine compliance.
Include a written record of all configuration settings on all components of the network in information technology documentation.
Implement documented risk analysis and risk management programs.
You must ensure the following physical safeguards:
Put controls in place to govern the addition and removal of software and hardware to the environment.
Carefully control and monitor access to equipment containing EPHI.
Limit access to equipment and software to authorized individuals.
Create physical access controls that consist of facility security plans, maintenance records, visitor records, and escorts.
Incorporate proper security policies for workstations that access EPHI.
Train contractors or third-party agents on their physical access responsibilities.
The HIPAA Enforcement Rule was created in February 2006 by the Department of Health and Human Services (HHS). It is the final rule that details the basis and procedures for imposing civil monetary penalties on covered entities that violate HIPAA.
This rule is a unification of the patchwork of existing rules and regulations that governed the enforcement of different parts of HIPPA. The HHS Office for Civil Rights (OCR) is responsible for enforcing the Privacy Rule, and the Centers for Medicare and Medicaid Services (CMS) is responsible for the Security Rule. The Enforcement Rule brings together and extends all of the other rules, resulting in a unified comprehensive policy on enforcement of compliance.
The rule requires HHS to try to resolve compliance issues in an informal manner before resorting to monetary penalties. In the informal process, the covered entity must submit a corrective action plan to show how they are going to remedy the non-compliance. If these means do not work, HHS proceeds to the civil monetary penalty phase.
Note
The Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 extended HIPAA to include an update to the civil and criminal penalties section and requires notification of the information owner if any breach causing the disclosure of PHI occurs.
Civil penalties in the Enforcement Rule are $100 per violation up to a maximum of $25,000 for all violations of an identical requirement or prohibition during a calendar year. The Enforcement Rule identifies the following three factors to be used in calculating the number of violations:
The number of times the covered entity takes the prohibited action
The number of people affected
The duration of a violation in days
HIPAA compliance is an all-encompassing endeavor. It requires every level of an organization to be on board. By fully understanding your business model and goals, you can help your company comply with HIPAA, ensuring your organization is a more secure environment for customer information. Organizations must realize that HIPAA is not just an IT issue; HIPAA affects every aspect of the organization. Anything from failing to utilize network security to failing to implement an awareness program can result in an organization being out of compliance.
The Sarbanes-Oxley (SOX) Act of 2002 was created to protect investors by improving the accuracy and reliability of the financial disclosures of publicly traded companies. SOX accomplishes this by strengthening existing penalties and making corporate officers personally responsible for the disclosures. It imposes harsher punishment, large fines, and prison sentences for any individual who knowingly alters or destroys information with the intent to obstruct an investigation. This affects IT departments in the form of record retention policies and access to an organization's electronic records such as e-mail and accounting system data.
Note
SOX requires your organization to have recorded retention policies that are strictly followed. Your organization is required to implement internal controls ensuring that records are complete, correct, and quickly accessible. SOX also explicitly deals with records retention at third-party accounting firms. Firms that audit publicly traded companies must keep all audit-related records for a minimum of seven years.
SOX contains 11 titles that describe specific mandates or requirements for financial reporting:
Title I: Public Company Accounting Oversight Board (PCAOB)—Provides independent oversight of public accounting firms. The PCAOB exists to prevent third-party accounting firms from using fraudulent accounting practices on behalf of their clients. The PCAOB's 'Auditing Standard No. 5" specifies a top-down approach that might limit the scope of review of IT systems.
Title II: Auditor Independence—Establishes standards that require external auditors to be completely independent from the firms they audit, which limits conflicts of interest.
Title III: Corporate Responsibility—Mandates that executives must take individual, personal responsibility for the accuracy and completeness of corporate financial reports. It also deals with the integrity of financial data contained within those reports.
Title IV: Enhanced Financial Disclosures—Describes enhanced reporting procedures required for financial transactions. Also requires internal controls that assure that financial reports and disclosures are accurate.
Title V: Analyst Conflicts of Interest—Establishes standards designed to prevent conflicts of interest among securities analysts and to improve investor confidence in analysts' reporting.
Title VI: Commission Resources and Authority—Defines the conditions under which the Securities and Exchange Commission (SEC) has the authority to censure or bar securities professionals from practice.
Title VII: Studies and Reports—Defines the studies the Comptroller General and the SEC are required to perform and report upon.
Title VIII: Corporate and Criminal Fraud Accountability—Imposes documentation retention requirements on companies and auditors. It also describes specific criminal penalties for manipulation, destruction, or alteration of financial records.
Title IX: White Collar Crime Penalty Enhancement—Increases the criminal penalties associated with white-collar crimes and conspiracies.
Title X: Corporate Tax Returns—States that the chief executive officer should sign the company tax return.
Title XI: Corporate Fraud Accountability—Identifies fraud and records tampering as criminal offenses and specifies penalties for those offenses.
SOX regulations, especially parts I, III, IV, and VIII, have a direct impact on corporate IT. Your organization needs to secure financial data with strong access controls to guarantee its integrity. If your company is a public entity, you are obligated to secure financial data so it is not modified or removed by anyone.
The role of IT in a SOX environment comes in the form of controls. You must put controls in place to handle how information is generated, accessed, collected, stored and processed, transmitted, and used throughout the organization. Implementing controls makes your organization more efficient and protects the integrity of that data.
Note
The main role of SOX is to stop internal fraud. Internal fraud is one of the most difficult crimes to stop because the perpetrators understand the systems and controls in place. The layered controls, and external independent audits mandated by SOX, are not foolproof but will make the organization more resilient.
For example, SOX Section 404 requires publicly traded companies to have policies in place to secure, document, and process any information dealing with financial results. This requires IT to have strict procedures when dealing with the electronic versions of these documents. You must have these controls and procedures certified by an outside auditing firm.
The Family Educational Rights and Privacy Act (FERPA) of 1974 is a federal law that protects the privacy and ensures the accuracy of student educational records. Educational institutions are required to protect educational records by adhering to the strict guidelines set in the act. The faculty and staff must be familiar with FERPA before they may release any student's educational record. This regulation requires physical access controls, requiring people to adhere to established regulations.
FERPA establishes a student's right to know the information, location, and purpose of an educational record. Information in that record must be kept confidential unless the student has explicitly given permission for disclosure of the information. Educational institutions must control access to a student's record by physical, logical, and administrative processes and procedures.
Educational records may appear in the following forms:
Written documents stored in the students' folders
Computer media
Microfilm and microfiche
Video tapes, audio tapes, or CDs
Film
Photographs
Any record that contains personally identifiable information
The following items are exempt from FERPA:
Private notes made by faculty or staff for the purpose of assisting memory; as long as they are kept in the sole position of the maker, they may be shared with substitute teachers
Note
Some information that's exempt from FERPA, such as medical records, is covered by other federal regulations. Safeguards must be in place to guard against disclosure of that information, even though it is not covered by FERPA.
Law enforcement records
Medical records
Statistical data that does not contain personally identifiable information
Pre-graded materials before the final grade is determined by the faculty
There are two types of educational records under FERPA, each with its own rules for disclosure:
Directory information—May be released by the educational institution without the written consent of the student. Directory information includes name, address, phone number, e-mail address, dates of attendance, degree earned, enrollment status, and field of study. Students have the right to limit the release of directory information. This can be done by submitting a formal written request to the school to limit disclosure.
Non-directory information—Any educational information not explicitly considered directory information. Non-directory information may not be disclosed to any party including the parent or guardian of the student without the student's written consent. Faculty and staff can only access non-directory information for legitimate academic purposes.
To protect student privacy and maintain compliance with FERPA, an educational institution must implement administrative and technical safeguards to disclosure. To ensure compliance, an institution must get a student's written consent for the release of any educational information. Administrative measures can consist of consent forms that outline the specific records being disclosed, with a space for the student's signature. Technical safeguards need to be both physical, such as a locking cabinet, and logical access controls on all electronic documents. Procedures and controls must be in place to prevent unauthorized access to the educational records.
The Children's Internet Protection Act (CIPA) is the federal law enacted in 2000 that addresses Internet access in public schools and libraries. Any school or library using the federal E-Rate program is subject to CIPA. E-Rate offers discounts to libraries and schools ensuring they have affordable access to modern telecommunications and information services.
CIPA deals with the implementation of protection systems meant to handle inbound threats, such as viruses and spam, and outbound information leaks. Failure to be in compliance will result in a loss of federal funding.
The safety measures that are required by this regulation are as follows:
Filter or block pictures that are obscene, contain child pornography, or are harmful to minors on computers that minors can access.
Adopt a policy addressing the following:
Access by minors of inappropriate materials
The safety and security of minors when using electronic communications such as e-mail
Unauthorized access, including hacking and other unlawful activities by minors
Unauthorized disclosure of personal information regarding minors
Restricting minors access to materials that are harmful to them
Having effective access controls is imperative for entities covered by CIPA. Other security safeguards are also necessary, which include Web filtering, firewalls, virus and spyware protection, and monitoring systems. These regulations affect all Internet-accessible computers in the covered entities including staff, administrative, and student workstations. There are provisions within CIPA to permit disabling of these safeguards for adults conducting research or for other lawful purposes.
Title 21 CFR Part 11 of the Code of Federal Regulations (21 CFR Part 11) deals with Food and Drug Administration (FDA) guidelines on electronic records and signatures. This title requires industries that fall under FDA regulation to implement controls such as audits, audit trails, electronic signatures, and policies for software and systems that process electronic data.
Note
21 CFR Part 11 applies to any organization involved with the production of food, prescription and nonprescription drugs, medical devices, cosmetics, dietary supplements, veterinary medicines, and other related fields. The goal of this regulation is to define standards for electronic records and signatures, which are considered equivalent to paper records and handwritten signatures.
21 CFR Part 11 calls for all FDA-regulated organizations to implement the following:
System access limited to authorized individuals
The use of operational system checks
The use of authority checks
The use of device checks
Appropriate education and task training for anyone who develops, maintains, or uses electronic systems
Appropriate controls for documentation are in place
Controls for both open systems and closed system requirements related to electronic signatures
In addition, there are requirements for entities that keep paper copies of all records. Organizations can use paper copies for regulatory purposes, but the paper copies must be certified as being complete and accurate.
The North American Electric Reliability Council (NERC) handles regulation of energy and utility companies. NERC was created in 1968 to ensure that the North American energy network is secure, adequate, and reliable. IT security is mostly concerned with the creation of guidelines for strong access controls and processes.
Note
Compliance with NERC standards requires dealing with physical, electronic, and personal security as well as training and awareness programs. NERC also requires documentation and auditing of all protective measures of critical resources.
Physical guidelines include physical protective measures for all critical infrastructures. A physical barrier must be in place, access points identified and controlled, and all access must be logged, either electronically via video or written in a logbook.
Electronic security guidelines include procedures meant to provide protective measures for assets. If your organization falls within this industry, you should ensure you've accurately inventoried your systems, limited access to systems by role, created an electronic security perimeter, and implemented account management procedures. These procedures include audits, passwords, and network security policies. You are also required to create a disaster recovery plan that includes backup and data restoration strategies and the documentation of spare parts and equipment. You must document all procedures, which can be subject to yearly audits and reviews.
You must also have requirements in place to handle background checks for employees and contractors. You are required to document procedures for contractor and vendor risk assessments.
It is also mandatory that you provide training for anyone with access to the energy or utility infrastructure, including contract workers, employees, and vendors.
The Homeland Security Presidential Directive 12 (HSPD 12) issued in August 2007 was initiated to enforce the standardization of security identification credentials for government employees and contractors. This standard covers both physical and logical access to government resources.
The standard is broken into two parts with the requirements of Part 2 built upon the requirements of Part 1.
Part 1 covers common identification, security, and privacy requirements. The minimum requirements for a federal personal identification system include personal identity proofing, registration, and issuance process for employees and contractors.
To comply with Part 1, an organization must:
Adopt and accredit a registration process in line with National Institute of Standards and Technology (NIST) standards
Initiate the National Agency Check with Written Inquiries (NACI) or other suitability or national security investigation prior to credential issuance
Include language implementing the standard in all contracts with third-party vendors and contractors
Verify that all current employees and contractors have gone through the appropriate background checks, and develop a plan for those who have not
Part 2 deals with the uniformity and portability of identification. This contains detailed specifications to handle technical interoperability of identifications between departments and agencies. This includes card elements, system interfaces, and security controls required to store and retrieve data from the identification card.
All U.S. government departments and agencies must deploy products and systems that meet these requirements to comply with Part 2:
Issue and require the use of identification credentials for all employees and contractors, compliant with Part 1 of the standard.
Implement the technical requirements of the standard for card hardware in the areas of personal authentication, access controls, and card management.
Use the appropriate card authentication mechanism with the additional reliance on visual authentication depending on the level of risk in the facility accessed.
Use digital certificates to verify authentication.
These standards exist to make it easier for governmental agencies to exchange information securely and reliably.
Best practices cover the policies, standards, procedures, and guidelines for a given topic. This section covers best practices for access controls, which can help your organization implement a strong access control environment.
Access control security policies are generally different for enterprise-level organizations than they are for smaller organizations. An enterprise organization may have employees across a wide geographic area, even in multiple countries. These organizations often have a complex organizational structure with several fairly autonomous divisions, each with their own critical assets and access control policies.
Security policies for enterprise organizations must take this complexity into account and balance the business needs of each division with the access control and security needs of the organization as a whole. In this section, you will learn more about how large enterprises manage access control.
An "authorization policy" is a high-level document that defines how an organization will assign and enforce access control rights. It is important to write a formal authorization policy rather than simply implement random access controls. A written policy defines a high-level strategy for access control security, and identifies the organization's security goals and compliance obligations.
An authorization policy should also take into account the fact that access controls do not exist in a vacuum. Access controls for systems are dependent upon physical access controls, and application security is interrelated with systems and data security. An authorization policy defines these relationships and ensures that steps taken to secure one element of an organization's infrastructure will promote the security of all the other elements as well.
Securing the data center or other facility that stores sensitive resources is a vitally important part of an access control plan. You can encrypt and protect a database server that holds customer records with a multi-stage authentication system, but what happens if someone physically steals it? The data is unavailable to those with legitimate access.
An authorization policy for facilities should dictate the following points:
Appropriate entry system access controls—An authorization policy should specify which areas should be locked at all times, and may dictate whether a one-, two-, or three-stage locking mechanism is appropriate given the resources in that area. For example, a data facility housing an organization's database servers may justify a two- or three-stage locking mechanism that incorporates both a token and a biometric authentication mechanism. You would elaborate on the specific implementation details of what type of biometric system to use in a separate, lower-level document.
Note
The authorization policy should also anticipate and account for employees who may find the entry system inconvenient and disable it by propping doors open. To compensate, the policy may specify repercussions for employees who undermine the locking mechanisms or simply call for automatically closing and locking doors.
Secondary locks on equipment and storage cabinets within the facility—To further secure specific pieces of equipment, such as a database server that stores mission-critical data, the policy may call for secondary locks on that equipment. This section of the policy should also dictate which employees should be given keys to that equipment.
Prevention of social engineering—The authorization policy should specify goals for the prevention of social engineering. These goals should focus primarily on training employees and on their acceptance of their role in preventing social engineering attacks.
Once you dictate how to secure the data center or other facility, you should secure the systems within that data center as well. This is doubly important for systems that are not stored in a dedicated facility with strong physical security.
A good authorization policy includes goals for securing systems. Some points to include are:
Limit access to those employees who have a legitimate need for resources. Which employees need access to specific resources varies by organization. In general, if an employee does not need access to a system in order to perform his or her duties, you should not grant access regardless of the employee's position.
Describe a strong password policy that includes password length requirements, use of several types of characters (uppercase and lowercase, numeric, and special characters), and change frequency. In this section, you should be careful to balance employees' need for passwords that are easy to remember and the ideals of robust passwords. If the policy dictates that users should change their passwords weekly, for example, employees might begin reusing old passwords, use the same password with a minor change, or simply write them down. These practices make it easier for employees to remember their frequently changing passwords. They also make those passwords less secure, defeating the purpose of the policy.
Applications are one of the most common sources of vulnerability in any system. They are often designed with functionality in mind, not security. This can lead to security testing as an afterthought. Because you cannot control the practices of various software vendors, your access control policy should include as many precautions as possible on the systems end to safeguard the environment for which you are responsible.
Key elements to include in the policy are:
Standard testing procedures for any third-party application installed in the environment—The authorization policy should dictate that all access controls within applications be examined and tested for security. You should replace applications that do not handle access controls securely—for example, by storing application user data in an unprotected flat file or unencrypted database table—with more secure alternatives, update to a newer version, or secure on the systems end.
Tip
You should detail the actual methods for testing and securing third-party applications in a lower-level document. Keep the policy document generic so that it can remain in effect for many years. If the policy dictates specific testing procedures, you would have to update it as technology evolves.
Sequestering applications—Sequester applications from human users by running applications as their own user or as a shared "Nobody" user. This prevents unsecure applications from providing an access point to user's data.
Data access is the core of any authorization policy. Access control for facilities, systems, and applications all exist to protect the data stored in those facilities and systems, and the applications used to access and process that data. An authorization policy for data should include these points:
Specify which data should be encrypted—Passwords are an obvious example, but other data may also justify encryption, depending on the organization's regulatory compliance needs and other factors. The authorization policy should not dictate specific data elements to be encrypted, but rather provides criteria for encrypted data. For example, a policy might specify you must encrypt any data defined as protected health information under HIPAA. This allows systems engineers and database administrators to decide whether a specific data element qualifies for encryption, even if that data did not exist when you wrote the policy.
Enforce the principal of lowest possible access—This states that if read access is sufficient for an employee to perform a necessary task, they should not be granted read-write access.
Providing remote access capabilities can greatly increase employees' productivity by allowing them to do their jobs wherever they need to be, from a hotel room to a job site. However, with increased levels of access come new access control challenges. When every person who connects to the internal network does so from a workstation on that network, you don't have to worry about communications being hijacked. When employees gain remote access, they can use any Internet connection to access the internal network via a virtual private network (VPN). Because you have no control over those Internet access points, you should always assume the worst—that they are being actively monitored by hackers.
Including the following points in an authorization policy will provide direction for implementing specific countermeasures to secure remote access:
Provide remote access only to those employees who have a legitimate need to work offsite. Grant it on a temporary basis for those who travel or work offsite occasionally.
Grant access to the VPN through a two-stage authentication process that includes both a strong password and a token device. You should document specific password creation guidance in a separate password policy document.
Outline specific guidelines in your authorization policy on acceptable activity while connected to the VPN.
In the public sector, the use of best practices is often required. In the case of access control, best practices are essential to an organization's information technology infrastructure. In the public sector, you are required by regulation to create access controls to prevent unauthorized access and disclosure to both logical and physical assets. Establishing documented policies, procedures, and safeguards to address the regulations is also often mandatory. Best practices can help meet these regulatory requirements, and groups like NIST often provide organizations in the public sector a road map towards compliance.
The Federal Information Security Management Act (FISMA) of 2002 sets forth specific requirements for implementing best practices in federal government agencies. In the public sector, best practices are more than simply recommended guidelines or strategies for successful access control. These legally mandated practices include:
Conduct periodic risk assessments to ensure that security activities and resources address the highest priority risks an organization faces at the present time
Tip
Design policies and procedures to lower risks to an acceptable level and ensure that information security is addressed throughout the life cycle of applications and systems.
Implement policies and procedures based on the most recent risk assessment.
Create plans for the security of networks, systems, and other resources.
Conduct employee and contractor training to ensure that all personnel that interact with sensitive data are aware of the security implications of their activities and know how to comply with policies designed to minimize those risks
Note
Test policies and procedures annually, at a minimum. The frequency with which you perform tests within a 12-month period depends on the risk involved.
Test periodically to ensure that policies and procedures designed to lower risk are working correctly.
Create processes to address any shortcomings in the organization's information security policies, procedures, and practices
Implement processes for detecting, reporting, and responding to security incidents
Note
The Department of Defense Information Assurance Certification and Accreditation Process, or DIACAP, is designed to ensure that risk management is a fundamental concern for all information systems within the Department of Defense. It sets out best practices for evaluating the validity of information, assuring that data has not been tampered with.
Incorporate continuity plans for the organization that will allow critical operations to continue in the event of a disaster, including but not limited to natural disasters, serious security incidents, and other crises
The best practices required by governmental regulations are similar in practice and intent to those used in the private sector.
Modern society depends on complex systems to work. These systems are known as critical infrastructures (see Figure 4-2). Critical infrastructure provides essential services necessary for modern life. This includes water supply; roads, rail, and other transportation networks; sewers; the energy grid; emergency services; communications networks; governmental and military facilities; and more. Best practices for how to handle failure in this infrastructure is critical.
Critical infrastructure assets can fall under the public or private sector. The water supply system is clearly within the public sector domain, while most communication networks are owned by companies in the private sector. Transportation systems often fall under both public and private sectors. Consider Amtrak, for example. It is a private company but it is heavily subsidized by the government. When implementing best practices for critical infrastructure, choose the best practices that apply based on the infrastructure in question.
There are some special considerations to keep in mind when you deal with critical infrastructure, especially with the devices and systems that control elements of that infrastructure. The next section deals with these special considerations in greater depth.
Supervisory Control and Data Acquisition (SCADA) process control systems are at the heart of much of societies' critical infrastructures. SCADA systems monitor and control telecommunications, water and waste control, energy, and transportation among other industries and utilities. SCADA devices use local area network (LAN), wide area network (WAN), and wireless communications infrastructures for monitoring and control purposes. These systems can be very complex. The systems are used for everything from monitoring the temperature in a room within an electrical substation to monitoring all the activity in a waste management plant. Access controls to these devices are critical.
Note
A SCADA system is considered to include hardware, controllers, networks, user interfaces, software, and communication equipment, used together to monitor and manage utilities. SCADA systems have monitors both in close proximity to the control center and offsite.
SCADA systems have the ability to monitor and control utility systems in real time. The monitoring provides readings from meters and sensors to a central facility through devices called remote terminal units (RTUs) to the user interface at regular intervals. The operator at the central facility is able to interact with the SCADA system to modify or override settings as necessary.
This interface, called a human machine interface (HMI), is where the operator views the data that is received and processed. The HMI is connected to a database that gathers information from the RTUs. Programmable logic controllers (PLCs) are also connected to this system. PLCs are designed to generate graphs on logistical information and trends. They also provide access to trouble shooting guides. These devices allow SCADA operators to efficiently monitor and manage the infrastructure.
SCADA systems are a point of risk for the utilities that use them. These systems were often designed with the assumption that they would not be connected to outside networks. They were also designed with misplaced faith in the practice of security through obscurity. The designers of SCADA systems also relied on logical security and did not consider physical security. This has left a critical system that is inherently insecure.
Efforts are underway to regulate SCADA system security. Regulations are scheduled for implementation in 2011 when the ISA Security Compliance Institute (ISCI) industry standards go into effect. Until then, it's up to business best practices to secure these systems. It is imperative that organizations understand the limitation of SCADA system security. You must physically secure devices and WANs. Strong access controls, such as the following, in both the physical and logical realm are necessary:
Physical security on collection points
Encrypted communications between collection points, controllers, and the central hub
Two-way authentication between remote points and centralized controller
Easily managed user rights for removing or modifying users
Segregation of SCADA systems from the rest of the network systems
Following these practices will make SCADA systems more secure and lessen the risk of a security breach.
It is imperative to conduct a threat and vulnerability assessment of critical infrastructures. Some of the more difficult to handle are those threats and vulnerabilities related to interdependencies and interoperability of the various systems. Understanding these interdependencies is essential to securing the most critical systems. Identifying single-point vulnerabilities is also essential to risk mitigation.
One of the first steps you must take when analyzing risk and developing a mitigation plan is to identify which assets are more critical. Determining what systems rely on each other is vital. If a water treatment plant is damaged, how will that affect other services? It is essential that you identify critical points that can cause multiple systems to fail.
Tip
Critical infrastructures are threatened by more than just manmade threats. Natural events can also seriously threaten critical infrastructures. Any plan developed to protect these systems must account for all threats.
Redundancy for these critical systems is also vital to risk mitigation. They must be completely separate systems. Two power lines running on the same path do not achieve redundancy. One event, whether it's natural or unnatural, could take out both systems. To mitigate risk, infrastructure design must avoid single points of failure.
Organizations have policies and procedures in place for various business units such as accounting and human resources. They also have essential policies for information security and access. The challenge for IT departments is to establish and continually update access control policies in an evolving technology and business environment. Creating and documenting standards for logical and physical security of the organization is essential in the protection of the organization's infrastructure as shown in Figure 4-3.
The size of the organization, the types of information utilized, and the industry the company exists in are all factors to consider when building an IT security policy framework. This framework must address both logical and physical security. The human aspect of security is vital as well. Without training and awareness programs, the best defense can fail. At the heart of these systems is a strong access control policy.
Figure 4-3. Protecting the infrastructure through logical and physical security policies and procedures.
Note
Failure to require strong access controls in a company's security policy framework will contribute to vulnerabilities and breaches in the system. These breaches may result in the disclosure and loss of valuable information and assets and can expose the organization to civil and legal penalties.
Before discussing security policy frameworks, it is helpful to define a few terms that are often used interchangeably:
Policy—A policy is a document that describes specific requirements or rules that must be met in a given area. An organization's acceptable use policy typically describes what is and is not acceptable use of the organization's computing resources.
Standard—A standard is a collection of requirements that must be met by anyone who performs a given task or works on a specific system. An organization might have a standard that describes the specific tests that must be performed before an application can be released to the production environment.
Guideline—A guideline is a set of suggestions and best practices for meeting standards and policies. An organization might have strong password guidelines that describe the use of mnemonic devices or passphrases for creating strong passwords. Guidelines are strongly recommended practices but do not carry the weight of a mandatory requirement. An employee could use a random password generator to create a strong password, and thus meet the organization's strong password policy without following the guidelines laid out for choosing passwords.
Procedure—A procedure is a set of specific steps to be taken to achieve a desired result. Procedures are often written to ensure that tasks are completed in the same way each time, preventing unexpected problems. For example, an IT department might have a procedure for changing a password on a workstation. That procedure will include a step-by-step workflow with enough detail that anyone in the IT department could follow it and expect the password to be changed correctly. Well-written procedures eliminate the problem of critical information being stored in one individual's mind. If that individual leaves the organization, the information is lost.
A policy is a general-purpose document that describes high-level organizational rules and requirements. A standard is a more specific implementation of a policy. Guidelines are strong suggestions for implementing policies and standards. Procedures are step-by-step outlines for completing a specific task as outlined in the guidelines and standards.
The specific policies needed for access controls vary by organization, but in general, organizations should have policies that describe which users have access to sensitive systems and data, for what purpose, and for how long.
The following are common organization policies:
Acceptable use policy (AUP)—Describes what tasks can and cannot be performed using the organization's computing resources
Password policy—Describes the organization's requirements for strong password creation and maintenance
Account management policy—Describes how new accounts are to be created, secured, and old accounts deleted
Remote access policy—Defines standards for connecting to the organization's network offsite
These policies provide a basis for an organization's access control systems. You should base them on the organization's business needs and risk assessment.
A "standard" is a set of detailed processes or methods for implementing technology, hardware, or software solutions. Access control standards are the rules that an organization utilizes to control access to its IT assets. You need these standards for all points in access control from creation of the users, to granting and revoking of rights, to user removal. Standards are important guides for evaluating an organization's compliance with regulation.
Standards documents, established by collective agreement and approved by management, provide for common repeatable rules. This helps to safeguard access controls and policies. This allows an organization better control in protecting its infrastructure and assets. Some common standards documents that many organizations use are:
User account standard—Describes the various types of user accounts on specific systems and networks
Identification standard—Describes how user IDs will be defined based on the individual's name, job function, or other identifying information
Remote access standard—Describes the specific tools to be used to implement the organization's remote access policy
Application development standard—Describes the security precautions that must be designed into any application developed in-house
Every organization will have a unique set of standards based on business needs. These are the most common standards that most organizations use.
You must establish access control procedures by outlining the steps needed to access organizational IT assets. Procedures should be included that detail authentication, account management, password management, and remote access. Additionally, you will need access determination policies and systems to restrict unauthorized access.
Procedures outlining specific steps for each process should be developed and utilized. The following is an example of an access request change procedure:
User fills out an access request form.
IT receives the form and passes it to the correct authority for approval.
The form is reviewed and authorization is granted or denied.
IT implements the access rights modification.
After signoff, IT files the request in the user's file to verify access and to provide information to an audit if required.
This is a simple example of a procedure. Having explicit procedures are vital for the efficient and consistent application of an access control policy. Without written procedures, the risk of mistakes and errors in an organization's access controls grow dangerously high.
Guidelines are a collection of suggestions and best practices relating to a standard or procedure. A guideline doesn't necessarily need to be met but compliance is strongly encouraged. Any access control policy in an organization will make reference to guidelines that are in existence in the organization. Although these actions are strongly encouraged, it is important to remember that these are not fixed rules. Guidelines are best viewed as recommendations.
An organization can have various guidelines for department and end users relating to access control policies. All of the information pertaining to the guideline should be included within a policy or procedure that a department or end user is required to follow. Inclusions into these official documents will lend weight to the guideline and allow a system for easily getting them to the end users.
Some examples of departmental guidelines are:
Department heads and managers should review access control systems periodically, but not less than annually.
User accounts should be disabled after 30 days of inactivity.
Some examples of individual guidelines are:
Individuals should periodically review access control policies, standards, procedures, and guidelines.
Individuals should not store critical information in their e-mail accounts. Rather, critical information should be stored as a document on the file server.
Users should not write down their passwords or base them on personally identifiable information. Instead, they should use a mnemonic to create a strong password that is also easy to remember.
Both individual and departmental guidelines should be written as helpful guidance for compliance with more official documents such as policies, standards, and procedures.
You have seen different types of access control policies and the way standards and procedures are used to implement them. Now let's look at some real-world examples of access control policies being utilized.
A large private pharmaceutical corporation created a new public entity called Acme, a medical devices company. Acme's staff already had experience with HIPAA and knew that it would have to set up procedures and policies to enforce compliance. As a new public company, however, it would also have to deal with SOX and a new set of regulations.
Acme was at an advantage from the start with staff already experienced in HIPAA. Not only was the business intelligence in place on how to navigate HIPAA regulations, there was already compliance buy-in at the employee and management level. A multi-departmental compliance team was created to bring the company into compliance. This could have been a major hurdle for the company, but it was easily achieved.
HIPAA polices were cloned from the former parent company, compliance forms created, and electronic and physical document repositories were created to store compliance documents. The company secured these repositories with physical and logical access control policies. They also developed automated processes for storing, updating, and removing documents. Access was limited to a strict need basis, with a role-based access control (RBAC) system put in place to determine if users had rights to access or modify documents. Regulations were created for handling EPHI. The staff created training documents for new hires. The compliance team also identified and trained privacy officers in all of Acme's business units. By leveraging existing business knowledge, HIPAA compliance was quickly achieved and the compliance team could focus on a brand new set of regulations with Sarbanes-Oxley.
Note
Role-based access control (RBAC) is an alternative to traditional discretionary access control (DAC) and mandatory access control (MAC) policies. RBAC is becoming more common, particularly for commercial applications. It utilizes individual and group roles as the basis for organizing access. You'll learn more about RBAC, DAC, and MAC in Chapters 6, 8, and 10.
SOX was a brand-new challenge. The first step towards compliance for Acme was to research the new regulations. Already having a business culture that was accustomed to the need for regulatory compliance was a big advantage. The team quickly realized they could expand and reuse many of the HIPAA policies to gain SOX compliance as well.
They created new classes of information and roles in the access control systems. The document repositories already had the necessary safeguards in place to protect SOX documents, so they created a new class of document in both the physical and logical repositories. Compliance officers were already in place in the form of HIPAA privacy officers. They further trained these individuals to be aware of SOX regulations and how they affected the officers' department. Acme's vendors posed the biggest challenge with SOX compliance. Acme needed to find and develop new business relationships with auditing and accounting vendors that were SOX compliant.
Note
The new roles and permissions created to achieve SOX compliance were auditors (read documents, view change logs), document owners (create, modify, and remove draft documents), compliance officers (promote a draft to an official document), and document consumers (read official documents).
Once an organization has management and employee buy-in for the need for compliance, it can attain regulatory compliance with a minimum of cost and effort. The heart of any compliance effort is a strong access control policy, both physical and logical. You cannot achieve compliance without robust access controls compliance, as documents cannot be trusted.
The Los Angeles County Department of Health Services handles and distributes a dozen serious health alerts monthly. These alerts go to physicians, hospitals, and emergency response agencies in Los Angeles County.
These alerts range from disease outbreaks, epidemic and pandemic warnings, and bioterrorist alerts. The department has to ensure that this sensitive data reaches the correct people in a timely manner without an information leak. If the information is leaked to the wrong outlets, it could cause a panic.
To handle this task, the department implemented a RBAC-controlled messaging system. This supports the county's distributed network, and validates users in a collaborative health alert network.
"Physicians and other health care providers need to know they can send us information on their patients, and it's going to be a secure transmission," explains bioterrorism IT coordinator David Cardenas, who oversees security for the county's Bioterrorism Preparedness and Response Unit and Acute Communicable Disease Control.
The system implemented in Los Angeles encrypts the information with a two-way authentication system for validating both the message sender and receiver. The RBAC allows the department to handle who can send and who can receive, as well as what each user sends and who they can send to. This level of granularity allows the system's operators to determine which messages go to which recipients as well as how and when they arrive, which helps protect against information leakage.
The entire system is behind a firewall for further protection, and is set up in a redundant load-balanced cluster. This allows for a backup system in the case of a system failure.
Heath alert communications must be secure and timely, employing a role-based authentication messaging systems allows the department to achieve both of these goals.
A Washington-based company is developing and constructing seaport gate control systems to be installed in Florida's deepwater seaports. They are installing thousands of access control readers to manage physical access. These readers utilize identification badges and biometrics to handle access.
Access control to port facilities is a major problem. On a normal day employees, truck drivers, and vendors all show up needing different levels of access. The current access control process is to check driver's licenses against paperwork. Although this system is relatively secure, it is a time-consuming process subject to human error.
In the new system, the security policy requires that companies and individuals will apply for access. The state will then perform background checks. When an individual is cleared, a smart card will be issued. The smart card will contain the individual's credentials as well as a photograph and fingerprint. Each smart card is designed to work at all of the state's sea ports so that once a user is registered into the system granting access to any, some, or all of the ports is an easy task. The smart cards grant users contactless access to the ports, greatly reducing the time it takes to pass through the security points. This is a major benefit and increases the efficiency of the ports. The smart card solution also brings the ports closer to compliance with HSPD 12.
In this chapter, you read about several scenarios where access control is mandated by law and others where controlling access to information is critical to achieving basic business goals. You learned about best practices, standards, policies, and procedures for implementing an access control policy. Finally, you explored several case studies that illustrate the concepts discussed in this chapter.
21 CFR Part 11
Best practice
Children's Internet Protection Act (CIPA)
Directory information
Electronic protected health information (EPHI)
Family Educational Rights and Privacy Act (FERPA)
Gramm-Leach-Bliley Act (GLBA)
Guideline
Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009
Health Insurance Portability and Accountability Act (HIPAA)
Homeland Security Presidential Directive 12 (HSPD 12)
Human machine interface (HMI)
North American Electric Reliability Council (NERC)
Programmable logic controllers (PLCs)
Protected health information (PHI)
Remote terminal unit (RTU)
Sarbanes-Oxley (SOX) Act of 2002
Standard
Supervisory Control and Data Acquisition (SCADA) process control systems
In IT, it is imperative that you keep up to date with regulatory compliance laws.
True
False
The Gramm-Leach-Bliley Act regulates which industry?
Health care
Energy
Financial services
Automobile
Education
A company regulated by GLBA is only required to protect against proven security threats, not perceived threats.
True
False
HIPAA regulates which industry?
Health care
Energy
Financials
Automobile
Education
Protected health information is interpreted very broadly and includes all of an individual's medical records and payment history.
True
False
The HIPAA Security Rule requires a set of _________, technical, and physical safeguards to electronic protected health information (EPHI).
The Sarbanes-Oxley Act regulates all _________ companies.
The Family Educational Rights and Privacy Act establishes a student's right to know the information, location, and purpose of an educational record.
True
False
Which regulation defines a standard for electronic records and signatures?
Children's Internet Protection Act
21 CFR Part 11
HIPAA
Sarbanes-Oxley
HSPD 12
_________ access controls enforce access created by the owner of the object.
_________ are a collection of suggestions and best practices.