Increasingly, organizations have to comply with privacy legislation. Stuart Vaeth asks whether this is the key to improved security.
The internet and online business have created a whole new range of concerns over privacy and security. Some of these the industry itself is trying to address, while legislative bodies around the world are also tackling the issues.
But legislation in this fast-moving area faces many challenges. Write an act that is too prescriptive, and chances are that technological developments will leave it behind; write an act that addresses only abstract principles and it will be hard to establish best practice.
In addition, because the internet is a global phenomenon, web sites can find themselves bound by laws in other countries from where their site can be accessed. So international businesses need to keep an eye on European legislation and that of any other jurisdictions in which they plan to operate.
Data protection is a case in point. The European Union's Data Protection Directive includes stringent measures for ensuring the confidentiality and proper handling of sensitive, personal data. These include restrictions on sending data outside the E.U. - data can only be transferred out of the E.U. to sites which adhere to the directive. The controversy and likely difficulties over this measure were eased by the U.S. Government establishing a 'safe harbor' standard, which the EU accepted as evidence of compliance with the directive.
But native U.S. legislation also requires compliance on the part of businesses and service providers and hence several laws and standards have been created, such as the Healthcare and Insurance Portability and Account ability Act (HIPAA), Federal Infor mation Processing Standards (FIPS) and the Gramm-Leach-Bliley Act (GLBA). Electronic signature acts have also been passed in the U.S. and E.U.
But the question with all these is: are they really a guarantee of improved privacy and security, or do they merely provide a basic minimum that will still require the user to apply good working practices?
HIPAA and privacy in healthcare
HIPAA, passed in 1996, is one of the higher profile pieces of recent legislation, providing a wide range of healthcare insurance reforms. Title II addresses the growing problem of privacy rights relating to the electronic storage of personal healthcare data.
While the use of information technology for data management and storage provide many efficiency advantages, it raises many privacy issues. HIPAA requires that health care organizations provide all patients with written notification about how their data may be used or disclosed. It gives patients the right to access their own records, and ensures that health information is only used for health purposes.
Organizations must establish privacy procedures, designate a privacy officer and train employees in privacy compliance in order to comply with HIPAA. Compliance is required by April 2003, with an extension until April 2004 for smaller healthcare organizations. Those that fail to comply can face both civil and criminal penalties.
Many organizations have looked to their existing software vendors and IT consultants to provide an easy route to compliance via improvements to existing software and hardware. In many circumstances, though, more radical changes to IT infrastructure and procedures may be necessary.
Security and privacy advocates would argue that the provisions of HIPAA establish just a floor of minimum good practice. Organizations should adopt these regardless of the legal incentive to do so.
The Gramm-Leach-Bliley Act
The Gramm-Leach-Bliley Act of 1999 (GLBA) seeks to ensure that financial institutions are respecting the privacy of customers and ensuring the security and confidentiality of their personal data The GLBA set in legislation many trends that were already visible within the financial services industry, while adding a consumer and privacy focus.
Critics argue that the GLBA produced little more than a forest of privacy notices and little actual change in industry practices, therefore the Federal Trade Commission (FTC) began the process of developing a Safeguards Rule under the GLBA which would provide "standards for insuring the security, confidentiality, integrity and protection of customer records and information." This rule would require financial services providers to develop and implement an information security program that was appropriate for the size of the institution and the type of services it offered, and the data that it stored.
According to the FTC: "The Rule will require financial institutions over which the FTC has jurisdiction to develop, implement and maintain a comprehensive information security program that contains administrative, technical and physical safeguards." Financial institutions must now prove that they comply with the standards.
In order to meet the Safeguards Rule, institutions should appoint a member of staff or a team to oversee compliance, perform a risk assessment of information security procedures and identify areas of risk. They should design and implement safeguards against risks identified during the assessment, and monitor their effectiveness. In addition they must ensure that any service providers involved in delivering the service meet the terms of the rule. They should also monitor security and watch for new information security developments, adjusting the security policy to meet them.
However, good business practice and the long-recognized need to protect financial data from external attack had already led many financial services companies to be in the fore-front of privacy and security initiatives. Institutions with a functioning public key infrastructure were already essentially compliant with the Rule.
Security standards
The benchmark set of standards in the U.S. and Canada are the Federal Information Processing Standards (FIPS), which are managed by the U.S. National Institute of Standards and Technology (NIST). FIPS standards address a wide range of computing issues, many of which specifically deal with security technology issues.
Several standards describe the encryption algorithms on which security software and hardware depend. If a product is certified against one of these standards by an accredited testing house, then the user can be assured that the implementation of the algorithm has been tested and been found to be correct.
The FIPS 140 standard covers the security of cryptographic products. The original FIPS 140 standard has recently been updated, such that new products will be validated against the newer FIPS 140-2 standard. Both standards include four levels of security, with level 1 being basic and level 4 being the most secure.
Other security certification schemes include ITSEC and Common Criteria. These are broader than FIPS, and typically apply to system level implementations rather than just the cryptographic processes. Common Criteria also emphasizes secure design and production processes as well as the security of the finished system.
Industry best practices
Irrespective of these initiatives in the legislative environment, industries that rely on trust as a basis of corporate reputations, customer loyalty and competitive advantage have always led the field in developing sound security practices. In many cases this expertise becomes embodied as a series of 'best practices.'
Credit card organizations have taken a great deal of interest in secure infrastructures for online transactions. Visa, for example, has established a program to ensure that its merchants and acquiring banks meet high security standards for online transactions; the Cardholder Information Security Program (CISP). CISP is a much more detailed program than the general provisions written into HIPAA and even the more specific GLBA Safeguards Rule. Compliance with CISP requires 12 steps, which Visa has nicknamed the 'Digital Dozen' (usa.visa.com/business/merchants/cisp_index.html).
Like other schemes, there is an element of scalability in the provisions: 'mom and pop' stores can achieve compliance through simple measures such as completing a checklist, whereas a financial group with millions of customers would need to show a much more complex and complete security system.
Visa CISP's Digital Dozen is a useful starting point for any organization starting to design a security policy. This applies whether the need is compliance with legislation or simply establishing good practice.
Creating policies
Organizations need to be able to prove that their secure systems provide an adequate level of security. One of the easiest ways to do this is to use products that have already been evaluated against well-known security standards. It is helpful if security officers choose computer security products which are built around their company's needs and that have software and management tools designed to make it easy to create security policies and implement them.
For example, the process of administering the archival and operational use of a PKI root key and the separation of administrative and operational functions can be ensured by the use of a good hardware security module (HSM) architecture. FIPS 140 level 3 compliant HSMs are tamper-resistant to protect against physical attacks, and are tamper-evident so that any physical attacks are easy to detect. So, choosing hardware devices will simplify the task of complying with the Safeguards Rule and other similar legislation.
Conclusion
While the advent of legislation has provided an incentive, privacy and security measures are basic good practice for organizations whatever their line of business. Legislation alone cannot provide for good practice as it is purposely short on technical detail.
Companies seeking to create their own policies and procedures should learn from the practical experiences of other companies who have already been working to solve similar problems. Organizations must take security and privacy seriously and not only to ensure their own compliance with both best practice and the law, but ultimately to protect themselves and the customers they serve.
CBK, the policy pioneer
With 15,000 people worldwide now holding the CISSP qualification, this has become the de facto benchmark of proficiency for information security professionals.
Underlying the certification process for the Certified Information Systems Security Professional is the Common Body of Knowledge (CBK), which has been developed and constantly refreshed by the International Information Systems Security Certification Consortium (ISC)2.
The first work on the Common Body of Knowledge began in 1989. "Back in those days, no-one had any idea of what constituted information security," says Bob Johnston, CISSP, manager of credentialing services at (ISC)2, who has been involved in the process from the start and who has also worked on the development of the ISO17799 security standard.
By gathering "input from a group of seasoned professionals," he says, the organization was able to create a framework that has been regularly reviewed and updated every three years to reflect the changing infosec landscape, and which forms the foundation for the CISSP certification.
The framework now, like most other security methodologies and best practice guides, covers a broad range of security aspects, from password control to physical security (see the list below). It is divided into 10 main domains and multiple sub-domains outlining key areas of knowledge.
Johnston sees the CBK and ISO17799 as being complementary to each other. "Organizations that use the CBK for implementing security programs will find it easy to implement the ISO standard," he says. In addition he says that an explicit corporate policy is an essential "armor" to support the security professional, especially when dealing with senior management.
The 10 domains in the CBK
- Access control systems and methodology: centralized and distributed, identification and authentication, single sign-on.
- Telecommunications and network security: protocols, management, internet, multimedia, attack methods, incident response management.
- Security management practices: concepts and objectives, risk management, policies and procedures, roles and responsibilities, awareness, handling incidents.
- Applications and systems development security: goals and threats, life cycles, architecture, change control, databases and knowledge-based systems.
- Cryptography: applications and uses, protocols and standards, PKI, symmetric/ asymmetric, digital signatures.
- Security architecture and models: concepts, evaluation criteria, host-based security and client server security.
- Operations security: resources, privileges, control mechanisms, potential abuses, principles.
- Business continuity planning and disaster recovery planning: concepts, vulnerability assessment, plan testing.
- Law, investigations and ethics: laws and regulations, conducting investigations, information ethics.
- Physical security: facilities management, personnel security, physical controls.
