Cryptography In The Database: The Last Line Of Defense by Kevin Kenan

Cryptography In The Database: The Last Line Of Defense

byKevin Kenan

Paperback | October 19, 2005

not yet rated|write a review

Pricing and Purchase Info

$48.62 online 
$57.99
Earn 243 plum® points

In stock online

Ships free on orders over $25

Not available in stores

about

Cryptography in the Database Preface About This Book This book is about using established cryptographic techniques and algorithms to protect information while it is at rest in a database. The emphasis is on designing and building or selecting and integrating a cryptosystem to protect against clearly identified threats against the database. Security is assumed to be a top priority. As such, the discussions in this book cover not only encrypting the data, but also attacks against the encrypted data. If the cryptography is not implemented carefully, attackers can recover data even if it is protected by strong encryption. Many examples of this have been seen in the field of secure communications. For instance, the widely publicized weaknesses in the encrypted wireless protocol WEP have prompted many to move to WPA even at the cost of buying new equipment. Database encryption can suffer from the same sort of weaknesses. Simple, naive encryption of the data is not enough. My goal is to provide a solid blueprint and execution plan so that a team charged with the task of encrypting sensitive information in a database will be successful. The cryptosystem presented in this book should be seen as a template that outlines threats against data at rest and provides safeguards against those threats. Problems and pitfalls common to implementing cryptography, such as mode selection and key management, are identified and addressed. The architecture is flexible and should be adaptable to many environments. For situations where some element of the presented solution simply does not fit, you should find enough information and guidance to pursue variations in the design. Similarly, when you re evaluating database cryptosystems from vendors, you can use the design in this book and the reasons behind the decisions that shaped that design as a sort of baseline. Even if the proposed system differs markedly from the design in this book, it will still have to map keys to columns and rows and provide a key life cycle. It will still have to store and protect keys, select an appropriate encryption mode, and handle initialization vectors. Most importantly, any solution must adequately reduce the risks outlined in an organization s threat model. You must consider all these details. By working through these issues and presenting a working cryptosystem, my hope is that this book will enable a team to successfully build or buy a database cryptosystem. Who Should Read This Book The core audience for this book is the technical lead responsible for protecting sensitive information in a database. This person might be an architect, a senior system or security analyst, a database administrator, or a technical project manager. Because success requires that the team implement the cryptographic architecture correctly and securely, the lead must provide guidance throughout the project on secure development practices as well as technology. This book assumes that the technical lead is a senior application security analyst. Our analyst is part of a team responsible for an application that handles and stores sensitive information in a database. The analyst s job begins with convincing the team, its management, and the customer that encryption is necessary. From there, the analyst contributes to each stage of the project to ensure that the team specifies, designs, and implements the cryptographic solution correctly and securely. Forprojects that don t have a dedicated security analyst, one of the other roles, such as architect or system analyst, may serve just as well so long as security is explicitly called out as a core responsibility. In some projects, the security analyst role described here might be best split across multiple people. A logical split would be between a security-focused technical lead, such as the architect, and the project manager. Prerequisites This book assumes that you are familiar with databases and have a passing knowledge of cryptography. A brief refresher is offered on databases, and cryptography is introduced and treated in more depth. Experience with Java or some other programming language is necessary to get the most out of the code examples included at the end of the book. Knowledge of application development methodologies will also help provide context for the discussion of secure development practices. Structure This book is divided into four major parts. The opening covers database security at a high level, and the second part details a database cryptosystem design. The third part discusses development practices necessary to implement a cryptosystem securely, and the final part provides working code examples of the design. Part I, "Database Security," opens, unsurprisingly, with Chapter 1, "The Case for Database Security," which looks at why database security is important and what sort of attacks databases face. This discussion culminates in a generalized threat model for database security. The chapter concludes with a brief survey of regulatory requirements to secure data. Then, Chapter 2, "Securing Databases with Cryptography," discusses the kinds of protection that cryptography can provide to a database. This chapter also introduces the idea that the cryptography itself can introduce new risks and sets the groundwork for examining the cryptosystem itself forweaknesses. We can t just assume that encrypted data, even when encrypted with strong algorithms, is secure. Part II, "A Cryptographic Infrastructure," details the design of a cryptographic infrastructure. Chapter 3, "An Overview of Cryptographic Infrastructure," provides an overview of the cryptosystem and presents the fundamentals of key management and how keys are assigned to data for encryption. Chapter 4, "Cryptographic Engines and Algorithms," covers algorithms and engines. An engine is the component that actually carries out the cryptographic operations. Different types of engines are discussed. There are several ways to apply the cryptographic algorithm used in this book which is AES , and the discussion of modes at the conclusion of this chapter explores these as well as considers the vulnerabilities that improper use of a mode can introduce. Chapter 5, "Keys: Vaults, Manifests, and Managers," covers the components that store and manage keys, and Chapter 6, "Cryptographic Providers and Consumers," describes how an application interacts with the cryptosystem. At first, Part III, "The Cryptographic Project," may seem somewhat out of place because it focuses on secure development practices. If you re an expert on developing secure applications, these six chapters may be review. However, experience has shown not to mention the plethora of successfully attacked applications gracing the weekly news that secure application development expertise is far from common. A database cryptosystem is a primary element of an organization s security infrastructure. Other applications will depend on thecryptosystem s security, so every effort must be made to ensure that the implementation is as secure as possible. Vulnerabilities in the database cryptosystem put data throughout the organization at risk. The seriousness of this situation earned the topic this prominent placement. The discussion of secure development practices begins with an overview of managing a cryptographic project in Chapter 7, "Managing the Cryptographic Project." Chapter 8, "Requirements Hardening," covers specifying security and cryptographic requirements and includes a discussion of data classification. Securing the design itself is the subject of Chapter 9, "Design Hardening," which consists of guidelines, threat modeling, and the application of security patterns. General guidelines for secure programming what most people think of as development are covered in Chapter 10, "Secure Development." The last two chapters of this part, Chapters 11, "Testing," and 12, "Deployment, Defense, and Decommissioning," cover testing and the three Ds-deployment, defense, and decommissioning. Part IV, "Example Code," consists of code examples and explanations. Each component discussed in Part II is represented, along with nearly all the core functionality. This code lets you explore and experiment with the functioning of a live database cryptosystem. Hopefully these concrete examples will help remove any ambiguities introduced by the more theoretical exposition in the earlier parts of the book and will prepare you to implement or evaluate a production cryptosystem. The final chapter, Chapter 21, "The System at Work," shows the example system at work.It illustrates everything from setting up key-encrypting keys to searching for encrypted data. /> Copyright Pearson Education. All rights reserved.

About The Author

Kevin Kenan leads Symantec's IT application and database security program. In this position, he works with application development teams to ensure that the applications and databases Symantec deploys internally are secure. This work includes specifying cryptographic solutions to protect sensitive information wherever it is stored.   ...

Details & Specs

Title:Cryptography In The Database: The Last Line Of DefenseFormat:PaperbackDimensions:312 pages, 9.2 × 6.9 × 0.7 inPublished:October 19, 2005Publisher:Pearson EducationLanguage:English

The following ISBNs are associated with this title:

ISBN - 10:0321320735

ISBN - 13:9780321320735

Customer Reviews of Cryptography In The Database: The Last Line Of Defense

Reviews

Extra Content

Read from the Book

Preface About This Book This book is about using established cryptographic techniques and algorithms to protect information while it is at rest in a database. The emphasis is on designing and building (or selecting and integrating) a cryptosystem to protect against clearly identified threats against the database. Security is assumed to be a top priority. As such, the discussions in this book cover not only encrypting the data, but also attacks against the encrypted data. If the cryptography is not implemented carefully, attackers can recover data even if it is protected by strong encryption. Many examples of this have been seen in the field of secure communications. For instance, the widely publicized weaknesses in the encrypted wireless protocol WEP have prompted many to move to WPA even at the cost of buying new equipment. Database encryption can suffer from the same sort of weaknesses. Simple, naïve encryption of the data is not enough. My goal is to provide a solid blueprint and execution plan so that a team charged with the task of encrypting sensitive information in a database will be successful. The cryptosystem presented in this book should be seen as a template that outlines threats against data at rest and provides safeguards against those threats. Problems and pitfalls common to implementing cryptography, such as mode selection and key management, are identified and addressed. The architecture is flexible and should be adaptable to many environments. For situations where some element of the presented solution simply does not fit, you should find enough information and guidance to pursue variations in the design. Similarly, when you're evaluating database cryptosystems from vendors, you can use the design in this book and the reasons behind the decisions that shaped that design as a sort of baseline. Even if the proposed system differs markedly from the design in this book, it will still have to map keys to columns and rows and provide a key life cycle. It will still have to store and protect keys, select an appropriate encryption mode, and handle initialization vectors. Most importantly, any solution must adequately reduce the risks outlined in an organization's threat model. You must consider all these details. By working through these issues and presenting a working cryptosystem, my hope is that this book will enable a team to successfully build or buy a database cryptosystem. Who Should Read This Book The core audience for this book is the technical lead responsible for protecting sensitive information in a database. This person might be an architect, a senior system or security analyst, a database administrator, or a technical project manager. Because success requires that the team implement the cryptographic architecture correctly and securely, the lead must provide guidance throughout the project on secure development practices as well as technology. This book assumes that the technical lead is a senior application security analyst. Our analyst is part of a team responsible for an application that handles and stores sensitive information in a database. The analyst's job begins with convincing the team, its management, and the customer that encryption is necessary. From there, the analyst contributes to each stage of the project to ensure that the team specifies, designs, and implements the cryptographic solution correctly and securely. Forprojects that don't have a dedicated security analyst, one of the other roles, such as architect or system analyst, may serve just as well so long as security is explicitly called out as a core responsibility. In some projects, the security analyst role described here might be best split across multiple people. A logical split would be between a security-focused technical lead, such as the architect, and the project manager. Prerequisites This book assumes that you are familiar with databases and have a passing knowledge of cryptography. A brief refresher is offered on databases, and cryptography is introduced and treated in more depth. Experience with Java or some other programming language is necessary to get the most out of the code examples included at the end of the book. Knowledge of application development methodologies will also help provide context for the discussion of secure development practices. Structure This book is divided into four major parts. The opening covers database security at a high level, and the second part details a database cryptosystem design. The third part discusses development practices necessary to implement a cryptosystem securely, and the final part provides working code examples of the design. Part I, "Database Security," opens, unsurprisingly, with Chapter 1, "The Case for Database Security," which looks at why database security is important and what sort of attacks databases face. This discussion culminates in a generalized threat model for database security. The chapter concludes with a brief survey of regulatory requirements to secure data. Then, Chapter 2, "Securing Databases with Cryptography," discusses the kinds of protection that cryptography can provide to a database. This chapter also introduces the idea that the cryptography itself can introduce new risks and sets the groundwork for examining the cryptosystem itself forweaknesses. We can't just assume that encrypted data, even when encrypted with strong algorithms, is secure. Part II, "A Cryptographic Infrastructure," details the design of a cryptographic infrastructure. Chapter 3, "An Overview of Cryptographic Infrastructure," provides an overview of the cryptosystem and presents the fundamentals of key management and how keys are assigned to data for encryption. Chapter 4, "Cryptographic Engines and Algorithms," covers algorithms and engines. An engine is the component that actually carries out the cryptographic operations. Different types of engines are discussed. There are several ways to apply the cryptographic algorithm used in this book (which is AES), and the discussion of modes at the conclusion of this chapter explores these as well as considers the vulnerabilities that improper use of a mode can introduce. Chapter 5, "Keys: Vaults, Manifests, and Managers," covers the components that store and manage keys, and Chapter 6, "Cryptographic Providers and Consumers," describes how an application interacts with the cryptosystem. At first, Part III, "The Cryptographic Project," may seem somewhat out of place because it focuses on secure development practices. If you're an expert on developing secure applications, these six chapters may be review. However, experience has shown (not to mention the plethora of successfully attacked applications gracing the weekly news) that secure application development expertise is far from common. A database cryptosystem is a primary element of an organization's security infrastructure. Other applications will depend on thecryptosystem's security, so every effort must be made to ensure that the implementation is as secure as possible. Vulnerabilities in the database cryptosystem put data throughout the organization at risk. The seriousness of this situation earned the topic this prominent placement. The discussion of secure development practices begins with an overview of managing a cryptographic project in Chapter 7, "Managing the Cryptographic Project." Chapter 8, "Requirements Hardening," covers specifying security and cryptographic requirements and includes a discussion of data classification. Securing the design itself is the subject of Chapter 9, "Design Hardening," which consists of guidelines, threat modeling, and the application of security patterns. General guidelines for secure programming (what most people think of as development) are covered in Chapter 10, "Secure Development." The last two chapters of this part, Chapters 11, "Testing," and 12, "Deployment, Defense, and Decommissioning," cover testing and the three Ds—deployment, defense, and decommissioning. Part IV, "Example Code," consists of code examples and explanations. Each component discussed in Part II is represented, along with nearly all the core functionality. This code lets you explore and experiment with the functioning of a live database cryptosystem. Hopefully these concrete examples will help remove any ambiguities introduced by the more theoretical exposition in the earlier parts of the book and will prepare you to implement or evaluate a production cryptosystem. The final chapter, Chapter 21, "The System at Work," shows the example system at work.It illustrates everything from setting up key-encrypting keys to searching for encrypted data. © Copyright Pearson Education. All rights reserved.

Table of Contents

Acknowledgments.

About the Author.

Preface.

I. DATABASE SECURITY.

 1: The Case for Database Security.

 2: Securing Databases with Cryptography.

II. A CRYPTOGRAPHIC INFRASTRUCTURE.

 3. An Overview of Cryptographic Infrastructure.

 4. Cryptographic Engines and Algorithms.

 5. Keys: Vaults, Manifests, and Managers.

 6. Cryptographic Providers and Consumers.

III. THE CRYPTOGRAPHIC PROJECT.

 7. Managing the Cryptographic Project.

 8. Requirements Hardening.

 9. Design Hardening.

10. Secure Development.

11. Testing.

12. Deployment, Defense, and Decommissioning.

IV. EXAMPLE CODE.

13. About the Examples.

14. A Key Vault.

15. The Manifest.

16. The Key Manager.

17. The Engine.

18. Receipts and Provider.

19. The Consumer.

20. Exceptions.

21. The System at Work.

Bibliography.

Glossary.

Index.