7 Data Security Management

Data Security Management is the fifth Data Management Function in the data management framework shown in Figures 1.3 and 1.4. It is the fourth data management function that interacts with and is influenced by the Data Governance function. Chapter 7 defines the data security management function and explains the concepts and activities involved in data operations management.

7.1 Introduction

Data Security Management is the planning, development, and execution of security policies and procedures to provide proper authentication, authorization, access, and auditing of data and information assets.

Effective data security policies and procedures ensure that the right people can use and update data in the right way, and that all inappropriate access and update is restricted. Understanding and complying with the privacy and confidentiality interests and needs of all stakeholders is in the best interest of any organization. Client, supplier, and constituent relationships all trust in, and depend on, the responsible use of data. Time invested in better understanding stakeholder interests and concerns generally proves to be a wise investment.

An effective data security management function establishes judicious governance mechanisms that are easy enough to abide by on a daily operational basis by all stakeholders. The context for Data Security Management is shown in Figure 7.1.

7.2 Concepts and Activities

The ultimate goal of data security management is to protect information assets in alignment with privacy and confidentiality regulations and business requirements. These requirements come from several different, very important sources:

• Stakeholder Concerns: Organizations must recognize the privacy and confidentiality needs of their stakeholders, including clients, patients, students, citizens, suppliers, or business partners. Stakeholders are the ultimate owners of the data about them, and everyone in the organization must be a responsible trustee of this data.
• Government Regulations: Government regulations protect some of the stakeholder security interests. Some regulations restrict access to information, while other regulations ensure openness, transparency, and accountability.
• Proprietary Business Concerns: Each organization has its own proprietary data to protect; ensuring competitive advantage provided by intellectual property and intimate knowledge of customer needs and business partner relationships is a cornerstone in any business plan.
• Legitimate Access Needs: Data security implementers must also understand the legitimate needs for data access. Business strategy, rules, and processes require individuals in certain roles to take responsibility for access to and maintenance of certain data.

Figure 7.1 Data Security Management Context Diagram

Data security requirements and the procedures to meet these requirements can be categorized into four basic groups (the four A’s):

• Authentication: Validate users are who they say they are.
• Authorization: Identify the right individuals and grant them the right privileges to specific, appropriate views of data.
• Access: Enable these individuals and their privileges in a timely manner.
• Audit: Review security actions and user activity to ensure compliance with regulations and conformance with policy and standards.

7.2.1 Understand Data Security Needs and Regulatory Requirements

It is important to distinguish between business rules and procedures, and the rules imposed by application software products. While application systems serve as vehicles to enforce business rules and procedures, it is common for these systems to have their own unique set of data security requirements over and above those required for business processes. These unique requirements are becoming more common with packaged and off-the-shelf systems.

7.2.1.1 Business Requirements

Implementing data security within an enterprise begins with a thorough understanding of business requirements. The business mission and strategy that percolates through the data strategy must be the guiding factor in planning data security policy. Address short-term and long-term goals to achieve a balanced and effective data security function.

The business needs of an enterprise define the degree of rigidity required for data security. The size of the enterprise and the industry to which it belongs greatly influence this degree. For example, a financial or a securities enterprise in the United States is highly regulated and, irrespective of the size, is required to maintain stringent data security standards. On the other hand, a small scale retail enterprise may not choose to have an extended data security management function compared to a large size retailer, even though both of them may be involved with similar core business activities.

Business rules and processes define the security touch points. Every event in the business workflow has its own security requirements. Data-to-process and data-to-role relationship matrices are useful tools to map these needs and guide definition of data security role-groups, parameters, and permissions. In addition, data security administrators must also assess the administrative requirements of software tools, application packages, and IT systems used by the enterprise.

Identify detailed application security requirements in the analysis phase of every systems development project.

7.2.1.2 Regulatory Requirements

Today’s fast changing and global environment requires organizations to comply with a growing set of regulations. The ethical and legal issues facing organizations in the Information Age are leading governments to establish new laws and standards.

Requirements of several newer regulations, like the United States Sarbanes-Oxley Act of 2002, Canadian Bill 198, and the CLERP Act of Australia, have all imposed strict security controls on information management. The European Union’s Basel II Accord imposes information controls for all financial institutions doing business in its related countries. A list of major privacy and security regulations appears in section 7.5.1.

7.2.2 Define Data Security Policy

Definition of data security policy based on data security requirements is a collaborative effort involving IT security administrators, data stewards, internal and external audit teams, and the legal department. Data security professionals sometimes take an ironclad approach to security, and in the process may cause inconvenient impediments for data consumers. Develop data security policies so that compliance is easier than non-compliance. The data governance council should review and approve high-level data security policy.

The enterprise IT strategy and standards typically dictate high-level policies for access to enterprise data assets. It is common to have the IT Security Policy and Data Security Policy be part of a combined security policy. The preference, however, should be to separate them out. Data security policies are more granular in nature and take a very data-centric approach compared to an IT security policy. Defining directory structures and an identity management framework can be the IT Security Policy component, whereas defining the individual application, database roles, user groups, and password standards can be part of the Data Security Policy.

7.2.3 Define Data Security Standards

There is no one prescribed way of implementing data security to meet privacy and confidentiality requirements. Regulations generally focus on ensuring achievement of the ‘end’, yet rarely define the ‘means’ for achieving it. Organizations should design their own security controls, demonstrate that the controls meet the requirements of the law or regulations, and document the implementation of those controls.

Information technology strategy and standards can also influence:

• Tools used to manage data security.
• Data encryption standards and mechanisms.
• Access guidelines to external vendors and contractors.
• Data transmission protocols over the internet.
• Documentation requirements.
• Remote access standards.
• Security breach incident reporting procedures.

Consider physical security, especially with the explosion of portable devices and media, to formulate an effective data security strategy. Physical security standards, as part of enterprise IT policies, provide guidelines including:

• Access to data using mobile devices.
• Storage of data on portable devices such as laptops, DVDs, CDs or USB drives.
• Disposal of these devices in compliance with records management policies.

An organization, its stakeholders, and its regulators have needs regarding data access, privacy, and confidentiality. Using these as requirements, an organization can develop a practical, implementable security policy, including data security guiding principles. The focus should be on quality and consistency, not creating a voluminous body of guidelines. The data security policy should be in a format that is easily accessible by the suppliers, consumers and stakeholders. An organization could post this policy on their company intranet or a similar collaboration portal. The Data Governance Council reviews and approves the policy. Ownership and maintenance responsibility for the data security policy resides with the Data Management Executive and IT security administrators.

Execution of the policy requires satisfying the four A’s of securing information assets: authentication, authorization, access, and audit. Information classification, access rights, role groups, users, and passwords are the means to implementing policy and satisfying the four A’s.

7.2.4 Define Data Security Controls and Procedures

Implementation and administration of data security policy is primarily the responsibility of security administrators. Database security is often one responsibility of database administrators (DBAs).

Organizations must implement proper controls to meet the objectives of pertinent laws. For instance, a control objective might read, ‘Review DBA and User rights and privileges on a monthly basis’. The organization’s control to satisfy this objective might be implementing a process to validate assigned permissions against a change management system used for tracking all user permission requests. Further, the control may also require a workflow approval process or signed paper form to record and document each request.

7.2.5 Manage Users, Passwords, and Group Membership

Access and update privileges can be granted to individual user accounts, but this approach results in a great deal of redundant effort. Role groups enable security administrators to define privileges by role, and to grant these privileges to users by enrolling them in the appropriate role group. While it may be technically possible to enroll users in more than one group, this practice may make it difficult to understand the specific privileges granted to a specific user. Whenever possible, try to assign each user to only one role group.

Construct group definitions at a workgroup or business unit level. Organize roles in a hierarchy, so that child roles further restrict the privileges of parent roles. The ongoing maintenance of these hierarchies is a complex operation requiring reporting systems capable of granular drill down to individual user privileges. Security role hierarchy examples are shown in Figure 7.2.

Security administrators create, modify, and delete user accounts and groups. Changes made to the group taxonomy and membership should require some level of approval, and tracking using a change management system.

Data consistency in user and group management is a challenge in a heterogeneous environment. User information such as name, title, and number must be stored redundantly in several locations. These islands of data often conflict, representing multiple versions of the ‘truth’. To avoid data integrity issues, manage user identity data and role-group membership data centrally.

Figure 7.2 Security Role Hierarchy Example Diagram

7.2.5.1 Password Standards and Procedures

Passwords are the first line of defense in protecting access to data. Every user account should be required to have a password set by the user (account owner) with a sufficient level of password complexity defined in the security standards, commonly referred to as ‘strong’ passwords. Do not permit blank passwords. Typical password complexity requirements require a password to:

• Contain at least 8 characters.
• Contain an uppercase letter and a numeral.
• Not be the same as the username.
• Not be the same as the previous 5 passwords used.
• Not contain complete dictionary words in any language.
• Not be incremental (Password1, Password2, etc).
• Not have two characters repeated sequentially.
• Avoid using adjacent characters from the keyboard.
• If the system supports a space in passwords, then a ‘pass phrase’ can be used.

Traditionally, users have had different accounts and passwords for each individual resource, platform, application system, and / or workstation. This approach requires users to manage several passwords and accounts. Organizations with enterprise user directories may have a synchronization mechanism established between the heterogeneous resources to ease user password management. In such cases, the user is required to enter the password only once, usually when logging into the workstation, after which all authentication and authorization is done through a reference to the enterprise user directory. An identity management system implements this capability, commonly referred to as the ‘single-sign-on’.

Ongoing maintenance of passwords is normally a user responsibility, requiring users to change their passwords every 45 to 60 days. When creating a new user account, the generated password should be set to expire immediately so users can set their passwords for subsequent use. Security administrators and help desk analysts assist in troubleshooting and resolving password related issues.

7.2.6 Manage Data Access Views and Permissions

Data security management involves not just preventing inappropriate access, but also enabling valid and appropriate access to data. Most sets of data do not have any restricted access requirements. Control sensitive data access by granting permissions (opt-in). Without permission, a user can do nothing.

Control data access at an individual or group level. Smaller organizations may find it acceptable to manage data access at the individual level. Larger organizations will benefit greatly from role-based access control, granting permissions to role groups and thereby to each group member. Regardless of approach, granting privileges requires careful analysis of data needs and stewardship responsibilities.

Relational database views provide another important mechanism for data security, enabling restrictions to data in tables to certain rows based on data values. Views can also restrict access to certain columns, allowing wider access to some columns and limited access to more confidential fields.

Access control degrades when achieved through shared or service accounts. Designed as a convenience for administrators, these accounts often come with enhanced privileges and are untraceable to any particular user or administrator. Enterprises using shared or service accounts run the risk of data security breaches. Some organizations configure monitoring systems to ignore any alerts related to these accounts, further enhancing this risk. Evaluate use of such accounts carefully, and never use them frequently or by default.

7.2.7 Monitor User Authentication and Access Behavior

Monitoring authentication and access behavior is critical because:

• It provides information about who is connecting and accessing information assets, which is a basic requirement for compliance auditing.
• It alerts security administrators to unforeseen situations, compensating for oversights in data security planning, design, and implementation.

Monitoring helps detect unusual or suspicious transactions that may warrant further investigation and issue resolution. Perform monitoring either actively or passively. Automated systems with human checks and balances in place best accomplish both methods.

Systems containing confidential information such as salary, financial data, etc. commonly implement active, real-time monitoring. In such cases, real-time monitoring can alert the security administrator or data steward when the system observes a suspicious activity or inappropriate access. The system sends notification to the data steward, usually in the form of email alerts or other configurable notification mechanisms.

Passive monitoring tracks changes over time by taking snapshots of the current state of a system at regular intervals, and comparing trends against a benchmark or defined set of criteria. The system sends reports to the data stewards accountable for the data. While active monitoring is more of a detection mechanism, consider passive monitoring to be an assessment mechanism.

Automated monitoring does impose an overhead on the underlying systems. While advances in technology have reduced resource consumption concerns in recent years, monitoring may still affect system performance. Deciding what needs to be monitored, for how long, and what actions should be taken in the event of an alert, requires careful analysis. Iterative configuration changes may be required to achieve the optimal parameters for proper monitoring.

Enforce monitoring at several layers or data touch points. Monitoring can be:

• Application specific.
• Implemented for certain users and / or role groups.
• Implemented for certain privileges.
• Used for data integrity validation.
• Implemented for configuration and core meta-data validation.
• Implemented across heterogeneous systems for checking dependencies.

7.2.8 Classify Information Confidentially

Classify an enterprise’s data and information products using a simple confidentiality classification schema. Most organizations classify the level of confidentiality for information found within documents, including reports. A typical classification schema might include the following five confidentiality classification levels:

• For General Audiences: Information available to anyone, including the general public. General audiences is the assumed default classification.
• Internal Use Only: Information limited to employees or members, but with minimal risk if shared. Internal use only may be shown or discussed, but not copied outside the organization.
• Confidential: Information which should not be shared outside the organization. Client Confidential information may not be shared with other clients.
• Restricted Confidential: Information limited to individuals performing certain roles with the “need to know”. Restricted confidential may require individuals to qualify through clearance.
• Registered Confidential: Information so confidential that anyone accessing the information must sign a legal agreement to access the data and assume responsibility for its secrecy.

Classify documents and reports based on the highest level of confidentiality for any information found within the document. Label each page or screen with the classification in the header or footer. Information products classified “For General Audiences” do not need labels. Assume any unlabeled products to be for General Audiences. Document authors and information product designers are responsible for evaluating, correctly classifying, and labeling the appropriate confidentiality level for each document.

Also, classify databases, relational tables, columns, and views. Information confidentiality classification is an important meta-data characteristic, guiding how users are granted access privileges. Data stewards are responsible for evaluating and determining the appropriate confidentiality level for data.

7.2.9 Audit Data Security

Auditing data security is a recurring control activity with responsibility to analyze, validate, counsel, and recommend policies, standards, and activities related to data security management. Auditing is a managerial activity performed with the help of analysts working on the actual implementation and details. Internal or external auditors may perform audits; however, auditors must be independent of the data and / or process involved in the audit. Data security auditors should not have direct responsibility for the activities being audited, to help ensure the integrity of the auditing activity and results. Auditing is not a faultfinding mission. The goal of auditing is to provide management and the data governance council with objective, unbiased assessments, and rational, practical recommendations.

Data security policy statements, standards documents, implementation guides, change requests, access monitoring logs, report outputs, and other records (electronic or hard copy) form the basis of auditing. In addition to examining existing evidence, audits may also include performing tests and checks.

Auditing data security includes:

• Analyzing data security policy and standards against best practices and needs.
• Analyzing implementation procedures and actual practices to ensure consistency with data security goals, policies, standards, guidelines, and desired outcomes.
• Assessing whether existing standards and procedures are adequate and in alignment with business and technology requirements.
• Verifying the organization is in compliance with regulatory requirements.
• Reviewing the reliability and accuracy of data security audit data.
• Evaluating escalation procedures and notification mechanisms in the event of a data security breach.
• Reviewing contracts, data sharing agreements, and data security obligations of outsourced and external vendors, ensuring they meet their obligations, and ensuring the organization meets its obligations for externally sourced data.
• Reporting to senior management, data stewards, and other stakeholders on the ‘State of Data Security’ within the organization and the maturity of its practices.
• Recommending data security design, operational, and compliance improvements.

Auditing data security is no substitute for effective management of data security. Auditing is a supportive, repeatable process, which should occur regularly, efficiently, and consistently.

7.3 Data Security in an Outsourced World

Organizations may choose to outsource certain IT functions, such as batch operations, application development, and / or database administration. Some may even outsource data security administration. You can outsource almost anything, but not your liability.

Outsourcing IT operations introduces additional data security challenges and responsibilities. Outsourcing increases the number of people who share accountability for data across organizational and geographic boundaries. Previously informal roles and responsibilities must now be explicitly defined as contractual obligations. Outsourcing contracts must specify the responsibilities and expectations of each role.

Any form of outsourcing increases risk to the organization, including some loss of control over the technical environment and the people working with the organization’s data. Data security risk is escalated to include the outsource vendor, so any data security measures and processes must look at the risk from the outsource vendor not only as an external risk, but also as an internal risk.

Transferring control, but not accountability, requires tighter risk management and control mechanisms. Some of these mechanisms include:

• Service level agreements.
• Limited liability provisions in the outsourcing contract.
• Right-to-audit clauses in the contract.
• Clearly defined consequences to breaching contractual obligations.
• Frequent data security reports from the service vendor.
• Independent monitoring of vendor system activity.
• More frequent and thorough data security auditing.
• Constant communication with the service vendor.

In an outsourced environment, it is critical to maintain and track the lineage, or flow, of data across systems and individuals to maintain a ‘chain of custody’. Outsourcing organizations especially benefit from developing CRUD (Create, Read, Update, and Delete) matrices that map data responsibilities across business processes, applications, roles, and organizations, tracing the transformation, lineage, and chain of custody for data.

Responsible, Accountable, Consulted, and Informed (RACI) matrices also help clarify roles, the separation of duties and responsibilities of different roles and their data security requirements.

The RACI matrix can also become part of the contractual documents, agreements, and data security policies. Defining responsibility matrices like RACI will establish clear accountability and ownership among the parties involved in the outsourcing engagement, leading to support of the overall data security policies and their implementation.

In outsourcing information technology operations, the accountability for maintaining data still lies with the organization. It is critical to have appropriate compliance mechanisms in place and have realistic expectations from parties entering into the outsourcing agreements.

7.4 Summary

The guiding principles for implementing data security management into an organization, a summary table of the roles for each data security management activity, and organization and cultural issues that may arise during data security management are summarized below.

7.4.1 Guiding Principles

The implementation of the data security management function into an organization follows fifteen guiding principles:

1. Be a responsible trustee of data about all parties. They own the data. Understand and respect the privacy and confidentiality needs of all stakeholders, be they clients, patients, students, citizens, suppliers, or business partners.
2. Understand and comply with all pertinent regulations and guidelines.
3. Data-to-process and data-to-role relationship (CRUD–Create, Read, Update, Delete) matrices help map data access needs and guide definition of data security role groups, parameters, and permissions.
4. Definition of data security requirements and data security policy is a collaborative effort involving IT security administrators, data stewards, internal and external audit teams, and the legal department. The data governance council should review and approve high-level data security policy.
5. Identify detailed application security requirements in the analysis phase of every systems development project.
6. Classify all enterprise data and information products against a simple confidentiality classification schema.
7. Every user account should have a password set by the user following a set of password complexity guidelines, and expiring every 45 to 60 days.
8. Create role groups; define privileges by role; and grant privileges to users by assigning them to the appropriate role group. Whenever possible, assign each user to only one role group.
9. Some level of management must formally request, track, and approve all initial authorizations and subsequent changes to user and group authorizations.
10. To avoid data integrity issues with security access information, centrally manage user identity data and group membership data.
11. Use relational database views to restrict access to sensitive columns and / or specific rows.
12. Strictly limit and carefully consider every use of shared or service user accounts.
13. Monitor data access to certain information actively, and take periodic snapshots of data access activity to understand trends and compare against standards criteria.
14. Periodically conduct objective, independent, data security audits to verify regulatory compliance and standards conformance, and to analyze the effectiveness and maturity of data security policy and practice.
15. In an outsourced environment, be sure to clearly define the roles and responsibilities for data security, and understand the “chain of custody” for data across organizations and roles.

7.4.2 Process Summary

The process summary for the data security management function is shown in Table 7.1. The deliverables, responsible roles, approving roles, and contributing roles are shown for each activity in the data security management function. The Table is also shown in Appendix A9.

Activities	Deliverables	Responsible Roles	Approving Roles	Contributing Roles
5.1 Understand Data Security Needs and Regulatory Requirements (P)	Data Security Requirements and Regulations	Data Stewards, DM Executive, Security Administrators	Data Governance Council	Data Stewards, Legal Department, IT Security
5.2 Define Data Security Policy (P)	Data Security Policy	Data Stewards, DM Executive, Security Administrators	Data Governance Council	Data Stewards, Legal Department, IT Security
5.3 Define Data Security Standards (P)	Data Security Standards	Data Stewards, DM Executive, Security Administrators	Data Governance Council	Data Stewards, Legal Department, IT Security
5.4 Define Data Security Controls and Procedures (D)	Data Security Controls and Procedures	Security Administrators	DM Executive	Data Stewards, IT Security
5.5 Manage Users, Passwords and Group Membership (C)	User Accounts, Passwords, Role Groups	Security Administrators, DBAs	Management	Data Producers, Data Consumers, Help Desk
5.6 Manage Data Access Views and Permissions (C)	Data Access Views Data Resource Permissions	Security Administrators, DBAs	Management	Data Producers, Data Consumers, Software Developers, Management, Help Desk
5.7 Monitor User Authentication and Access Behavior (C)	Data Access Logs, Security Notification Alerts, Data Security Reports	Security Administrators, DBAs	DM Executive	Data Stewards, Help Desk
5.8 Classify Information Confidentiality (C)	Classified Documents, Classified Databases	Document Authors, Report Designers, Data Stewards	Management	Data Stewards
5.9 Audit Data Security (C)	Data Security Audit Reports	Data Security Auditors	Data Governance Council, DM Executive	Security Administrators, DBAs, Data Stewards

Table 7.1 Data Security Management Process Summary

7.4.3 Organizational and Cultural Issues

Q1: How can data security really be successful?

A1: Successful data security is deeply incorporated into the corporate culture, but this is not the case in many companies. Organizations often end up being reactive on data security management instead of being proactive. The maturity level in data security management has increased over the years, but there is still opportunity for improvement. Data security breaches have shown that companies are still struggling and faltering in becoming organized. On the positive side, recently introduced regulations are increasing accountability, auditability, and awareness of the importance of data security.

Q2: Can there be good security while still allowing access?

A2: Protecting and securing data without stifling user access to data is a daunting task. Organizations with a process management culture will find it relatively less challenging to have a formidable framework for data security management in place. Regularly evaluate data security policies, procedures, and activities to strike the best possible balance between the data security requirements of all stakeholders.

Q3: What does data security really mean?

A3: Data security means different things to different people. Certain data elements may be considered sensitive in some organizations and cultures, but not in others. Certain individuals or roles may have additional rights and responsibilities that do not even exist in other organizations.

Q4: Do data security measures apply to everyone?

A4: Applying data security measures inconsistently or improperly within an organization can lead to employee dissatisfaction and risk to the organization. Role-based security depends on the organization to define and assign the roles, and apply them consistently.

Q5: Do customers and employees need to be involved in data security?

A5: Implementing data security measures without regard for the expectations of customers and employees can result in employee dissatisfaction, customer dissatisfaction, and organizational risk. Any data security measure or process must take into account the viewpoint of those who will be working with those measures and processes, in order to ensure the highest compliance.

Q6: How do you really avoid security breaches?

A6: People need to understand and appreciate the need for data security. The best way to avoid data security breaches is to build awareness and understanding of security requirements, policies, and procedures. Organizations can build awareness and increase compliance through:

• Promotion of standards through training on security initiatives at all levels of the organization. Follow training with evaluation mechanisms such as online tests focused on improving employee awareness. Such training and testing should be made mandatory and made a pre-requisite for employee performance evaluation.
• Definition of data security policies for workgroups and departments that complement and align with enterprise policies. Adopting an ‘act local’ mindset helps engage people more actively.
• Links to data security within organizational initiatives. Organizations should include objective metrics for data security activities in their balanced scorecard measurements and project evaluations.
• Inclusion of data security requirements in service level agreements and outsourcing contractual obligations.
• Emphasis on the legal, contractual, and regulatory requirements applicable to their industry to build a sense of urgency and an internal framework for data security management.

Q7: What is the one primary guiding principle for data security?

A7: Success in data security management depends on being proactive about engaging people, managing change, and overcoming cultural bottlenecks.

7.5 Recommended Reading

The references listed below provide additional reading that support the material presented in Chapter 7. These recommended readings are also included in the Bibliography at the end of the Guide.

7.5.1 Texts and Articles

Afyouni, Hassan A. Database Security and Auditing: Protecting Data Integrity and Accessibility. Course Technology, 2005. ISBN 0-619-21559-3.

Anderson, Ross J. Security Engineering: A Guide to Building Dependable Distributed Systems. Wiley, 2008. ISBN 0-470-06852-6.

Axelrod, C. Warren. Outsourcing Information Security. Artech House, 2004. ISBN 0-58053-531-3.

Calder, Alan and Steve Watkins. IT Governance: A Manager’s Guide to Data Security and BS 7799/ISO 17799, 3rd Edition. Kogan Page, 2005. ISBN 0-749-44414-2.

Castano, Silvana, Maria Grazia Fugini, Giancarlo Martella, and Pierangela Samarati. Database Security. Addison-Wesley, 1995. ISBN 0-201-59375-0.

Dennis, Jill Callahan. Privacy and Confidentiality of Health Information. Jossey-Bass, 2000. ISBN 0-787-95278-8.

Gertz, Michael and Sushil Jajodia. Handbook of Database Security: Applications and Trends. Springer, 2007. ISBN 0-387-48532-5.

Jaquith, Andrew. Security Metrics: Replacing Fear, Uncertainty and Doubt. Addison-Wesley, 2007. ISBN 0-321-349998-9.

Landoll, Douglas J. The Security Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessments. CRC, 2005. ISBN 0-849-32998-1.

Litchfield, David, Chris Anley, John Heasman, and Bill Frindlay. The Database Hacker’s Handbook: Defending Database Servers. Wiley, 2005. ISBN 0-764-57801-4.

Mullins, Craig S. Database Administration: The Complete Guide to Practices and Procedures. Addison-Wesley, 2002. ISBN 0-201-74129-6.

Peltier, Thomas R. Information Security Policies and Procedures: A Practitioner’s Reference, 2nd Edition. Auerbach, 2004. ISBN 0-849-31958-7.

Shostack, Adam and Andrew Stewart. The New School of Information Security. Addison-Wesley, 2008. ISBN 0-321-50278-7.

Thuraisingham, Bhavani. Database and Applications Security: Integrating Information Security and Data Management. Auerbac Publications, 2005. ISN 0-849-32224-3.

Whitman, Michael R. and Herbert H. Mattord. Principles of Information Security, Third Edition. Course Technology, 2007. ISBN 1-423-90177-0.

7.5.2 Major Privacy and Security Regulations

The major privacy and security regulations affecting Data Security standards are listed below.

7.5.2.1 Non-United States Privacy Laws:

• Argentina: Personal Data Protection Act of 2000 (aka Habeas Data).
• Austria: Data Protection Act 2000, Austrian Federal Law Gazette Part I No. 165/1999 (DSG 2000).
• Australia: Privacy Act of 1988.
• Brazil: Privacy currently governed by Article 5 of the 1988 Constitution.
• Canada: The Privacy Act - July 1983, Personal Information Protection and Electronic Data Act (PIPEDA) of 2000 (Bill C-6).
• Chile: Act on the Protection of Personal Data, August 1998.
• Columbia: No specific privacy law, but the Columbian constitution provides any person the right to update and access their personal information.
• Czech Republic: Act on Protection of Personal Data (April 2000) No. 101.
• Denmark: Act on Processing of Personal Data, Act No. 429, May 2000.
• Estonia: Personal Data Protection Act, June 1996, Consolidated July 2002.
• European Union: Data Protection Directive of 1998.
• European Union: Internet Privacy Law of 2002 (DIRECTIVE 2002/58/EC).
• Finland: Act on the Amendment of the Personal Data Act (986) 2000.
• France: Data Protection Act of 1978 (revised in 2004).
• Germany: Federal Data Protection Act of 2001.
• Greece: Law No.2472 on the Protection of Individuals with Regard to the Processing of Personal Data, April 1997.
• Hong Kong: Personal Data Ordinance (The “Ordinance”).
• Hungary: Act LXIII of 1992 on the Protection of Personal Data and the Publicity of Data of Public Interests.
• Iceland: Act of Protection of Individual; Processing Personal Data (Jan 2000).
• Ireland: Data Protection (Amendment) Act, Number 6 of 2003.
• India: Information Technology Act of 2000.
• Italy: Data Protection Code of 2003 Italy: Processing of Personal Data Act, Jan. 1997.
• Japan: Personal Information Protection Law (Act).
• Japan: Law for the Protection of Computer Processed Data Held by Administrative Organizations, December 1988.
• Korea: Act on Personal Information Protection of Public Agencies Act on Information and Communication Network Usage.
• Latvia: Personal Data Protection Law, March 23, 2000.
• Lithuania: Law on Legal Protection of Personal Data (June 1996).
• Luxembourg: Law of 2 August 2002 on the Protection of Persons with Regard to the Processing of Personal Data.
• Malaysia: Common Law principle of confidentiality Draft Personal data Protection Bill Banking and Financial Institutions Act of 1989 privacy provisions.
• Malta: Data Protection Act (Act XXVI of 2001), Amended March 22, 2002, November 15, 2002 and July 15, 2003.
• New Zealand: Privacy Act, May 1993; Privacy Amendment Act, 1993; Privacy Amendment Act, 1994.
• Norway: Personal Data Act (April 2000) - Act of 14 April 2000 No. 31 Relating to the Processing of Personal Data (Personal Data Act).
• Philippines: No general data protection law, but there is a recognized right of privacy in civil law.
• Poland: Act of the Protection of Personal Data (August 1997).
• Singapore: The E-commerce Code for the Protection of Personal Information and Communications of Consumers of Internet Commerce.
• Slovak Republic: Act No. 428 of 3 July 2002 on Personal Data Protection.
• Slovenia: Personal Data Protection Act , RS No. 55/99.
• South Korea: The Act on Promotion of Information and Communications Network Utilization and Data Protection of 2000.
• Spain: ORGANIC LAW 15/1999 of 13 December on the Protection of Personal Data.
• Switzerland: The Federal Law on Data Protection of 1992.
• Sweden: Personal Data Protection Act (1998:204), October 24, 1998.
• Taiwan: Computer Processed Personal data Protection Law - applies only to public institutions.
• Thailand: Official Information Act (1997) for state agencies ( Personal data Protection bill under consideration).
• Vietnam: The Law on Electronic Transactions (Draft: Finalized in 2006).

7.5.2.2 United States Privacy Laws:

• Americans with Disabilities Act (ADA).
• Cable Communications Policy Act of 1984 (Cable Act).
• California Senate Bill 1386 (SB 1386).
• Children’s Internet Protection Act of 2001 (CIPA).
• Children’s Online Privacy Protection Act of 1998 (COPPA).
• Communications Assistance for Law Enforcement Act of 1994 (CALEA).
• Computer Fraud and Abuse Act of 1986 (CFAA).
• Computer Security Act of 1987 - (Superseded by the Federal Information Security Management Act (FISMA).
• Consumer Credit Reporting Reform Act of 1996 (CCRRA) - Modifies the Fair Credit Reporting Act (FCRA).
• Controlling the Assault of Non-Solicited Pornography and Marketing (CAN-SPAM) Act of 2003.
• Electronic Funds Transfer Act (EFTA).
• Fair and Accurate Credit Transactions Act (FACTA) of 2003.
• Fair Credit Reporting Act.
• Federal Information Security Management Act (FISMA).
• Federal Trade Commission Act (FTCA).
• Driver’s Privacy Protection Act of 1994.
• Electronic Communications Privacy Act of 1986 (ECPA).
• Electronic Freedom of Information Act of 1996 (E-FOIA).
• Fair Credit Reporting Act of 1999 (FCRA).
• Family Education Rights and Privacy Act of 1974 (FERPA; also known as the Buckley Amendment).
• Gramm-Leach-Bliley Financial Services Modernization Act of 1999 (GLBA).
• Privacy Act of 1974.
• Privacy Protection Act of 1980 (PPA).
• Right to Financial Privacy Act of 1978 (RFPA).
• Telecommunications Act of 1996.
• Telephone Consumer Protection Act of 1991 (TCPA).
• Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001 (USA PATRIOT Act).
• Video Privacy Protection Act of 1988.

7.5.2.3 Industry-Specific Security and Privacy Regulations:

• Financial Services: Gramm-Leach-Bliley Act (GLBA), PCI Data Security Standard.
• Healthcare and Pharmaceuticals: HIPAA (Health Insurance Portability and Accountability Act of 1996) and FDA 21 CFR Part 11.
• Infrastructure and Energy: FERC and NERC Cybersecurity Standards, the Chemical Sector Cyber Security Program and Customs-Trade Partnership against Terrorism (C-TPAT).
• U.S. Federal Government: FISMA and related NSA Guidelines and NIST Standard.
  CAN-SPAM - Federal law regarding unsolicited electronic mail.