![978-1-492-03751-4
[LSI]
Practical Cloud Security
by Chris Dotson
Copyright © 2019 Chris Dotson. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional
sales department: 800-998-9938 or corporate@oreilly.com.
Acquisitions Editor: Rachel Roumeliotis
Developmental Editors: Andy Oram and Nikki
McDonald
Production Editor: Nan Barber
Copyeditor: Rachel Head
Proofreader: Amanda Kersey
Indexer: Judith McConville
Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest
March 2019: First Edition
Revision History for the First Edition
2019-03-01: First Release
See http://oreilly.com/catalog/errata.csp?isbn=9781492037514 for release details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Practical Cloud Security, the cover
image, and related trade dress are trademarks of O’Reilly Media, Inc.
The views expressed in this work are those of the author, and do not represent the publisher’s views.
While the publisher and the author have used good faith efforts to ensure that the information and
instructions contained in this work are accurate, the publisher and the author disclaim all responsibility
for errors or omissions, including without limitation responsibility for damages resulting from the use of
or reliance on this work. Use of the information and instructions contained in this work is at your own
risk. If any code samples or other technology this work contains or describes is subject to open source
licenses or the intellectual property rights of others, it is your responsibility to ensure that your use
thereof complies with such licenses and/or rights.](https://image.slidesharecdn.com/47330-250620111425-e4ac508d/85/Practical-Cloud-Security-A-Guide-for-Secure-Design-and-Deployment-1st-Edition-Chris-Dotson-6-320.jpg)
Practical Cloud Security A Guide for Secure Design and Deployment 1st Edition Chris Dotson
- 1. Practical Cloud Security A Guide for Secure Design and Deployment 1st Edition Chris Dotson download https://textbookfull.com/product/practical-cloud-security-a- guide-for-secure-design-and-deployment-1st-edition-chris-dotson/ Download full version ebook from https://textbookfull.com
- 2. We believe these products will be a great fit for you. Click the link to download now, or visit textbookfull.com to discover even more! Secure and Trustworthy Cyberphysical Microfluidic Biochips: A practical guide to cutting-edge design techniques for implementing secure and trustworthy cyberphysical microfluidic biochips Jack Tang https://textbookfull.com/product/secure-and-trustworthy- cyberphysical-microfluidic-biochips-a-practical-guide-to-cutting- edge-design-techniques-for-implementing-secure-and-trustworthy- cyberphysical-microfluidic-biochips-jack-tang/ Serverless Security: Understand, Assess, and Implement Secure and Reliable Applications in AWS, Microsoft Azure, and Google Cloud Miguel A. Calles https://textbookfull.com/product/serverless-security-understand- assess-and-implement-secure-and-reliable-applications-in-aws- microsoft-azure-and-google-cloud-miguel-a-calles/ Efficient Cloud FinOps: A practical guide to cloud financial management and optimization with AWS, Azure, and GCP 1st Edition Sánchez https://textbookfull.com/product/efficient-cloud-finops-a- practical-guide-to-cloud-financial-management-and-optimization- with-aws-azure-and-gcp-1st-edition-sanchez/ Security Operations Center Guidebook A Practical Guide for a Successful SOC Gregory Jarpey https://textbookfull.com/product/security-operations-center- guidebook-a-practical-guide-for-a-successful-soc-gregory-jarpey/
- 3. Essential Sustainable Home Design A Complete Guide to Goals Options and the Design Process 1st Edition Chris Magwood https://textbookfull.com/product/essential-sustainable-home- design-a-complete-guide-to-goals-options-and-the-design- process-1st-edition-chris-magwood/ Pro Google Cloud Automation With Google Cloud Deployment Manager, Spinnaker, Tekton, and Jenkins 1st Edition Navin Sabharwal https://textbookfull.com/product/pro-google-cloud-automation- with-google-cloud-deployment-manager-spinnaker-tekton-and- jenkins-1st-edition-navin-sabharwal/ Architectural Lighting Design A Practical Guide 1st Edition Admir Jukanovi■ https://textbookfull.com/product/architectural-lighting-design-a- practical-guide-1st-edition-admir-jukanovic/ Signage and Wayfinding Design A Complete Guide to Creating Environmental Graphic Design Systems 2nd Edition Chris Calori https://textbookfull.com/product/signage-and-wayfinding-design-a- complete-guide-to-creating-environmental-graphic-design- systems-2nd-edition-chris-calori/ Semantic Software Design A New Theory and Practical Guide for Modern Architects 1st Edition Eben Hewitt https://textbookfull.com/product/semantic-software-design-a-new- theory-and-practical-guide-for-modern-architects-1st-edition- eben-hewitt/
- 4. Chris Dotson Practical Cloud Security A Guide for Secure Design and Deployment
- 5. Chris Dotson Practical Cloud Security A Guide for Secure Design and Deployment Boston Farnham Sebastopol Tokyo Beijing Boston Farnham Sebastopol Tokyo Beijing
- 6. 978-1-492-03751-4 [LSI] Practical Cloud Security by Chris Dotson Copyright © 2019 Chris Dotson. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Rachel Roumeliotis Developmental Editors: Andy Oram and Nikki McDonald Production Editor: Nan Barber Copyeditor: Rachel Head Proofreader: Amanda Kersey Indexer: Judith McConville Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Rebecca Demarest March 2019: First Edition Revision History for the First Edition 2019-03-01: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781492037514 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Practical Cloud Security, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author, and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
- 7. Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1. Principles and Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Least Privilege 1 Defense in Depth 2 Threat Actors, Diagrams, and Trust Boundaries 2 Cloud Delivery Models 6 The Cloud Shared Responsibility Model 6 Risk Management 10 2. Data Asset Management and Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Data Identification and Classification 13 Example Data Classification Levels 14 Relevant Industry or Regulatory Requirements 15 Data Asset Management in the Cloud 17 Tagging Cloud Resources 18 Protecting Data in the Cloud 19 Tokenization 19 Encryption 20 Summary 26 3. Cloud Asset Management and Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Differences from Traditional IT 29 Types of Cloud Assets 30 Compute Assets 31 Storage Assets 37 Network Assets 41 Asset Management Pipeline 42 iii
- 8. Procurement Leaks 43 Processing Leaks 44 Tooling Leaks 45 Findings Leaks 45 Tagging Cloud Assets 46 Summary 48 4. Identity and Access Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Differences from Traditional IT 51 Life Cycle for Identity and Access 52 Request 53 Approve 54 Create, Delete, Grant, or Revoke 54 Authentication 55 Cloud IAM Identities 55 Business-to-Consumer and Business-to-Employee 56 Multi-Factor Authentication 57 Passwords and API Keys 59 Shared IDs 61 Federated Identity 61 Single Sign-On 61 Instance Metadata and Identity Documents 63 Secrets Management 64 Authorization 68 Centralized Authorization 69 Roles 70 Revalidate 71 Putting It All Together in the Sample Application 72 Summary 75 5. Vulnerability Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Differences from Traditional IT 78 Vulnerable Areas 80 Data Access 80 Application 81 Middleware 82 Operating System 84 Network 84 Virtualized Infrastructure 85 Physical Infrastructure 85 Finding and Fixing Vulnerabilities 85 Network Vulnerability Scanners 87 iv | Table of Contents
- 9. Agentless Scanners and Configuration Management 88 Agent-Based Scanners and Configuration Management 89 Cloud Provider Security Management Tools 91 Container Scanners 91 Dynamic Application Scanners (DAST) 92 Static Application Scanners (SAST) 92 Software Composition Analysis Scanners (SCA) 93 Interactive Application Scanners (IAST) 93 Runtime Application Self-Protection Scanners (RASP) 93 Manual Code Reviews 94 Penetration Tests 94 User Reports 95 Example Tools for Vulnerability and Configuration Management 95 Risk Management Processes 98 Vulnerability Management Metrics 98 Tool Coverage 99 Mean Time to Remediate 99 Systems/Applications with Open Vulnerabilities 99 Percentage of False Positives 100 Percentage of False Negatives 100 Vulnerability Recurrence Rate 100 Change Management 101 Putting It All Together in the Sample Application 102 Summary 106 6. Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Differences from Traditional IT 109 Concepts and Definitions 111 Whitelists and Blacklists 111 DMZs 112 Proxies 112 Software-Defined Networking 113 Network Features Virtualization 113 Overlay Networks and Encapsulation 113 Virtual Private Clouds 114 Network Address Translation 115 IPv6 116 Putting It All Together in the Sample Application 116 Encryption in Motion 118 Firewalls and Network Segmentation 121 Allowing Administrative Access 126 Web Application Firewalls and RASP 130 Table of Contents | v
- 10. Anti-DDoS 132 Intrusion Detection and Prevention Systems 133 Egress Filtering 134 Data Loss Prevention 136 Summary 137 7. Detecting, Responding to, and Recovering from Security Incidents. . . . . . . . . . . . . . . 139 Differences from Traditional IT 140 What to Watch 141 Privileged User Access 142 Logs from Defensive Tooling 144 Cloud Service Logs and Metrics 147 Operating System Logs and Metrics 148 Middleware Logs 148 Secrets Server 149 Your Application 149 How to Watch 149 Aggregation and Retention 150 Parsing Logs 151 Searching and Correlation 152 Alerting and Automated Response 152 Security Information and Event Managers 153 Threat Hunting 155 Preparing for an Incident 155 Team 156 Plans 157 Tools 159 Responding to an Incident 160 Cyber Kill Chains 161 The OODA Loop 162 Cloud Forensics 163 Blocking Unauthorized Access 164 Stopping Data Exfiltration and Command and Control 164 Recovery 164 Redeploying IT Systems 164 Notifications 165 Lessons Learned 165 Example Metrics 165 Example Tools for Detection, Response, and Recovery 166 Putting It All Together in the Sample Application 166 Monitoring the Protective Systems 168 Monitoring the Application 169 vi | Table of Contents
- 11. Monitoring the Administrators 169 Understanding the Auditing Infrastructure 170 Summary 171 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Table of Contents | vii
- 13. Preface As the title states, this book is a practical guide to securing your cloud environments. In almost all organizations, security has to fight for time and funding, and it often takes a back seat to implementing features and functions. Focusing on the “best bang for the buck,” security-wise, is important. This book is intended to help you get the most important security controls for your most important assets in place quickly and correctly, whether you’re a security profes‐ sional who is somewhat new to the cloud, or an architect or developer with security responsibilities. From that solid base, you can continue to build and mature your controls. While many of the security controls and principles are similar in cloud and on- premises environments, there are some important practical differences. For that rea‐ son, a few of the recommendations for practical cloud security may be surprising to those with an on-premises security background. While there are certainly legitimate differences of opinion among security professionals in almost any area of informa‐ tion security, the recommendations in this book stem from years of experience in securing cloud environments, and they are informed by some of the latest develop‐ ments in cloud computing offerings. The first few chapters deal with understanding your responsibilities in the cloud and how they differ from in on-premises environments, as well as understanding what assets you have, what the most likely threats are to those assets, and some protections for them. The next chapters of the book provide practical guidance, in priority order, of the most important security controls that you should consider first: • Identity and access management • Vulnerability management ix
- 14. • Network controls The final chapter deals with how to detect when something’s wrong and deal with it. It’s a good idea to read this chapter before something actually goes wrong! Do you need to get any certifications or attestations for your environment, like PCI certification or a SOC 2 report? If so, you’ll need to watch out for a few specific pit‐ falls, which will be noted. You’ll also need to make sure you’re aware of any applicable regulations—for example, if you’re handling PHI (protected health information) in the United States, or if you’re handling personal information for EU citizens, regard‐ less of where your application is hosted. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program ele‐ ments such as variable or function names, databases, data types, environment variables, statements, and keywords. Constant width bold Shows commands or other text that should be typed literally by the user. Constant width italic Shows text that should be replaced with user-supplied values or by values deter‐ mined by context. This element signifies a tip or suggestion. This element signifies a general note. x | Preface
- 15. This element indicates a warning or caution. O’Reilly Online Learning Platform For almost 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help compa‐ nies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, conferences, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in- depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/practical-cloud-security. To comment or ask technical questions about this book, send email to bookques‐ tions@oreilly.com. For more information about our books, courses, conferences, and news, see our web‐ site at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Preface | xi
- 16. Acknowledgments This book would not have happened without the encouragement and support of my wonderful wife, Tabitha Dotson, who told me that I couldn’t pass up this opportunity and juggled schedules and obligations for over a year to make it happen. I’d also like to thank my children, Samantha (for her extensive knowledge of Greek mythology) and Molly (for constantly challenging assumptions and thinking outside the box). It takes many people besides the author to bring a book to publication, and I didn’t fully appreciate this before writing one. I’d like to thank my editors, Andy Oram and Courtney Allen; my reviewers, Hans Donker, Darren Day, and Edgar Ter Danielyan; and the rest of the wonderful team at O’Reilly who have guided and supported me through this. Finally, I’d like to thank all of my friends, family, colleagues, and mentors over the years who have answered questions, bounced around ideas, listened to bad puns, laughed at my mistakes, and actually taught me most of the content in this book. xii | Preface
- 17. CHAPTER 1 Principles and Concepts Yes, this is a practical guide, but we do need to cover a few cloud-relevant security principles at a high level before we dive into the practical bits. If you’re a seasoned security professional new to the cloud, you may want to skim down to “The Cloud Shared Responsibility Model” on page 6. Least Privilege The principle of least privilege simply states that people or automated tools should be able to access only what they need to do their jobs, and no more. It’s easy to forget the automation part of this; for example, a component accessing a database should not use credentials that allow write access to the database if write access isn’t needed. A practical application of least privilege often means that your access policies are deny by default. That is, users are granted no (or very few) privileges by default, and they need to go through the request and approval process for any privileges they require. For cloud environments, some of your administrators will need to have access to the cloud console—a web page that allows you to create, modify, and destroy cloud assets such as virtual machines. With many providers, anyone with access to your cloud console will have godlike privileges by default for everything managed by that cloud provider. This might include the ability to read, modify, or destroy data from any part of the cloud environment, regardless of what controls are in place on the operating systems of the provisioned systems. For this reason, you need to tightly control access to and privileges on the cloud console, much as you tightly control physical data cen‐ ter access in on-premises environments, and record what these users are doing. 1
- 18. 1 The Verizon Data Breach Investigations Report is an excellent free resource for understanding different types of successful attacks, organized by industry and methods, and the executive summary is very readable. Defense in Depth Many of the controls in this book, if implemented perfectly, would negate the need for other controls. Defense in depth is an acknowledgment that almost any security control can fail, either because an attacker is sufficiently determined or because of a problem with the way that security control is implemented. With defense in depth, you create multiple layers of overlapping security controls so that if one fails, the one behind it can still catch the attackers. You can certainly go to silly extremes with defense in depth, which is why it’s impor‐ tant to understand the threats you’re likely to face, which are described later. How‐ ever, as a general rule, you should be able to point to any single security control you have and say, “What if this fails?” If the answer is complete failure, you probably have insufficient defense in depth. Threat Actors, Diagrams, and Trust Boundaries There are different ways to think about your risks, but I typically favor an asset- oriented approach. This means that you concentrate first on what you need to pro‐ tect, which is why I dig into data assets first in Chapter 2. It’s also a good idea to keep in mind who is most likely to cause you problems. In cybersecurity parlance, these are your potential “threat actors.” For example, you may not need to guard against a well-funded state actor, but you might be in a business where a criminal can make money by stealing your data, or where a “hacktivist” might want to deface your website. Keep these people in mind when designing all of your defenses. While there is plenty of information and discussion available on the subject of threat actors, motivations, and methods,1 in this book we’ll consider four main types of threat actors that you may need to worry about: • Organized crime or independent criminals, interested primarily in making money • Hacktivists, interested primarily in discrediting you by releasing stolen data, committing acts of vandalism, or disrupting your business • Inside attackers, usually interested in discrediting you or making money • State actors, who may be interested in stealing secrets or disrupting your business 2 | Chapter 1: Principles and Concepts
- 19. 2 I recommend Threat Modeling: Designing for Security, by Adam Shostack (Wiley). To borrow a technique from the world of user experience design, you may want to imagine a member of each applicable group, give them a name, jot down a little about that “persona” on a card, and keep the cards visible when designing your defenses. The second thing you have to do is figure out what needs to talk to what in your application, and the easiest way to do that is to draw a picture and figure out where your weak spots are likely to be. There are entire books on how to do this,2 but you don’t need to be an expert to draw something useful enough to help you make deci‐ sions. However, if you are in a high-risk environment, you should probably create formal diagrams with a suitable tool rather than draw stick figures. Although there are many different application architectures, for the sample applica‐ tion used for illustration here, I will show a simple three-tier design. Here is what I recommend: 1. Draw a stick figure and label it “user.” Draw another stick figure and label it “administrator” (Figure 1-1). You may find later that you have multiple types of users and administrators, or other roles, but this is a good start. Figure 1-1. User and administrator roles 2. Draw a box for the first component the user talks to (for example, the web servers), draw a line from the user to that first component, and label the line with how the user talks to that component (Figure 1-2). Note that at this point, the component may be a serverless function, a container, a virtual machine, or some‐ thing else. This will let anyone talk to it, so it will probably be the first thing to go. We really don’t want the other components trusting this one more than neces‐ sary. Threat Actors, Diagrams, and Trust Boundaries | 3
- 20. Figure 1-2. First component 3. Draw other boxes behind the first for all of the other components that first sys‐ tem has to talk to, and draw lines going to those (Figure 1-3). Whenever you get to a system that actually stores data, draw a little symbol (I use a cylinder) next to it and jot down what data is there. Keep going until you can’t think of any more boxes to draw for your application. Figure 1-3. Additional components 4. Now draw how the administrator (and any other roles you’ve defined) accesses the application. Note that the administrator may have several different ways of talking to this application; for example, via the cloud provider’s portal or APIs, or through the operating system access, or by talking to the application similarly to how a user accesses it (Figure 1-4). Figure 1-4. Administrator access 4 | Chapter 1: Principles and Concepts
- 21. 5. Draw some trust boundaries as dotted lines around the boxes (Figure 1-5). A trust boundary means that anything inside that boundary can be at least some‐ what confident of the motives of anything else inside that boundary, but requires verification before trusting anything outside of the boundary. The idea is that if an attacker gets into one part of the trust boundary, it’s reasonable to assume they’ll eventually have complete control over everything in it, so getting through each trust boundary should take some effort. Note that I drew multiple web servers inside the same trust boundary; that means it’s okay for these web servers to trust each other completely, and if someone has access to one, they effectively have access to all. Or, to put it another way, if someone compromises one of these web servers, no further damage will be done by having them all compromised. Figure 1-5. Component trust boundaries 6. To some extent, we trust our entire system more than the rest of the world, so draw a dotted line around all of the boxes, including the admin, but not the user (Figure 1-6). Note that if you have multiple admins, like a web server admin and a database admin, they might be in different trust boundaries. The fact that there are trust boundaries inside of trust boundaries shows the different levels of trust. For example, the servers here may be willing to accept network connections from servers in other trust boundaries inside the application, but still verify their iden‐ tities. They may not even be willing to accept connections from systems outside of the whole application trust boundary. Threat Actors, Diagrams, and Trust Boundaries | 5
- 22. Figure 1-6. Whole application trust boundary We’ll use this diagram of an example application throughout the book when discus‐ sing the shared responsibility model, asset inventory, controls, and monitoring. Right now, there are no cloud-specific controls shown in the diagram, but that will change as we progress through the chapters. Look at any place a line crosses a trust boundary. These are the places we need to focus on securing first! Cloud Delivery Models There is an unwritten law that no book on cloud computing is complete without an overview of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Soft‐ ware as a Service (SaaS). Rather than the standard overview, I’d like to point out that these service models are useful only for a general understanding of concepts; in par‐ ticular, the line between IaaS and PaaS is becoming increasingly blurred. Is a content delivery network (CDN) service that caches information for you around the internet to keep it close to users a PaaS or IaaS? It doesn’t really matter. What’s important is that you understand what is (and isn’t!) provided by the service, not whether it fits neatly into any particular category. The Cloud Shared Responsibility Model The most basic security question you must answer is, “What aspects of security am I responsible for?” This is often answered implicitly in an on-premises environment. The development organization is responsible for code errors, and the operations organization (IT) is responsible for everything else. Many organizations now run a DevOps model where those responsibilities are shared, and team boundaries between development and operations are blurred or nonexistent. Regardless of how it’s organ‐ ized, almost all security responsibility is inside the company. 6 | Chapter 1: Principles and Concepts
- 23. 3 Original concept from an article by Albert Barron. Perhaps one of the most jarring changes when moving from an on-premises environ‐ ment to a cloud environment is a more complicated shared responsibility model for security. In an on-premises environment, you may have had some sort of internal document of understanding or contract with IT or some other department that ran servers for you. However, in many cases business users of IT were used to handing the requirements or code to an internal provider and having everything else done for them, particularly in the realm of security. Even if you’ve been operating in a cloud environment for a while, you may not have stopped to think about where the cloud provider’s responsibility ends and where yours begins. This line of demarcation is different depending on the types of cloud service you’re purchasing. Almost all cloud providers address this in some way in their documentation and education, but the best way to explain it is to use the anal‐ ogy of eating pizza. With Pizza-as-a-Service,3 you’re hungry for pizza. There are a lot of choices! You could just make a pizza at home, although you’d need to have quite a few ingredients and it would take a while. You could run up to the grocery store and grab a take-and- bake; that only requires you to have an oven and a place to eat it. You could call your favorite pizza delivery place. Or, you could just go sit down at a restaurant and order a pizza. If we draw a diagram of the various components and who’s responsible for them, we get something like Figure 1-7. The traditional on-premises world is like making a pizza at home. You have to buy a lot of different components and put them together yourself, but you get complete flexibility. Anchovies and cinnamon on wheat crust? If you can stomach it, you can make it. When you use Infrastructure as a Service, though, the base layer is already done for you. You can bake it to taste and add a salad and drinks, and you’re responsible for those things. When you move up to Platform as a Service, even more decisions are already made for you, and you just use that service as part of developing your overall solution. (As mentioned in the previous section, sometimes it can be difficult to cate‐ gorize a service as IaaS or PaaS, and they’re growing together in many cases. The exact classification isn’t important; what’s important is that you understand what the service provides and what your responsibilities are.) When you get to Software as a Service (compared to dining out in Figure 1-7), it seems like everything is done for you. It’s not, though. You still have a responsibility to eat safely, and the restaurant is not responsible if you choke on your food. In the SaaS world, this largely comes down to managing access control properly. The Cloud Shared Responsibility Model | 7
- 24. Figure 1-7. Pizza as a Service If we draw the diagram with technology instead of pizza, it looks more like Figure 1-8. Figure 1-8. Cloud shared responsibility model The reality of cloud computing is unfortunately a little more complicated than eating pizza, so there are some gray areas. At the bottom of the diagram, things are concrete (often literally). The cloud provider has complete responsibility for physical infra‐ 8 | Chapter 1: Principles and Concepts
- 25. structure security—which often involves controls beyond what many companies can reasonably do on-premises, such as biometric access with anti-tailgating measures, security guards, slab-to-slab barriers, and similar controls to keep unauthorized per‐ sonnel out of the physical facilities. Likewise, if the provider offers virtualized environments, the virtualized infrastruc‐ ture security controls keeping your virtual environment separate from other virtual environments are the provider’s responsibility. When the Spectre and Meltdown vul‐ nerabilities came to light in early 2018, one of the potential effects was that users in one virtual machine could read the memory of another virtual machine on the same physical computer. For IaaS customers, fixing that part of the vulnerability was the responsibility of the cloud provider, but fixing the vulnerabilities within the operating system was the customer’s responsibility. Network security is shown as a shared responsibility in the IaaS section of Figure 1-8. Why? It’s hard to show on a diagram, but there are several layers of networking, and the responsibility for each lies with a different party. The cloud provider has its own network that is its responsibility, but there is usually a virtual network on top (for example, some cloud providers offer a virtual private cloud), and it’s the customer’s responsibility to carve this into reasonable security zones and put in the proper rules for access between them. Many implementations also use overlay networks, firewalls, and transport encryption that are the customer’s responsibility. This will be discussed in depth in Chapter 6. Operating system security is usually straightforward: it’s your responsibility if you’re using IaaS, and it’s the provider’s responsibility if you’re purchasing platform or soft‐ ware services. In general, if you’re purchasing those services, you have no access to the underlying operating system. (As as general rule of thumb, if you have the ability to break it, you usually have the responsibility for securing it!) Middleware, in this context, is a generic name for software such as databases, applica‐ tion servers, or queuing systems. They’re in the middle between the operating system and the application—not used directly by end users, but used to develop solutions for end users. If you’re using a PaaS, middleware security is often a shared responsibility; the provider might keep the software up to date (or make updates easily available to you), but you retain the responsibility for security-relevant settings such as encryp‐ tion. The application layer is what the end user actually uses. If you’re using SaaS, vulnera‐ bilities at this layer (such as cross-site scripting or SQL injection) are the provider’s responsibility, but if you’re reading this book you’re probably not just using someone else’s SaaS. Even if all of the other layers have bulletproof security, a vulnerability at the application security layer can easily expose all of your information. The Cloud Shared Responsibility Model | 9
- 26. Finally, data access security is almost always your responsibility as a customer. If you incorrectly tell your cloud provider to allow access to specific data, such as granting incorrect storage permissions, middleware permissions, or SaaS permissions, there’s really nothing the provider can do. The root cause of many security incidents is an assumption that the cloud provider is handling something, when it turns out nobody was handling it. Many real-world examples of security incidents stemming from poor understanding of the shared responsibility model come from open Amazon Web Services Simple Storage Service (AWS S3) buckets. Sure, AWS S3 storage is secure and encrypted, but none of that helps if you don’t set your access controls properly. This misunderstanding has caused the loss of: • Data on 198 million US voters • Auto-tracking company records • Wireless customer records • Over 3 million demographic survey records • Over 50,000 Indian citizens’ credit reports If you thought a discussion of shared responsibility was too basic, congratulations— you’re in the top quartile. According to a Barracuda Networks survey in 2017, the shared responsibility model is still widely misunderstood among businesses. Some 77% of IT decision makers said they believed public cloud providers were responsible for securing customer data in the cloud, and 68% said they believed these providers were responsible for securing customer applications as well. If you read your agree‐ ment with your cloud provider, you’ll find this just isn’t true! Risk Management Risk management is a deep subject, with entire books written about it. I recommend reading The Failure of Risk Management: Why It’s Broken and How to Fix It by Doug‐ las W. Hubbard (Wiley), and NIST Special Publication 800-30 Rev 1 if you’re interes‐ ted in getting serious about risk management. In a nutshell, humans are really bad at assessing risk and figuring out what to do about it. This section is intended to give you just the barest essentials for managing the risk of security incidents and data breaches. At the risk of being too obvious, a risk is something bad that could happen. In most risk management systems, the level of risk is based on a combination of how probable it is that the bad thing will happen (likelihood), and how bad the results will be if it does happen (impact). For example, something that’s very likely to happen (such as someone guessing your password of “1234”) and will be very bad if it does happen 10 | Chapter 1: Principles and Concepts
- 27. 4 Risks can also interact, or aggregate. There may be two risks that each have relatively low likelihood and impacts, but they may be likely to occur together and the impacts can combine to be higher. For example, the impact of either power line in a redundant pair going out may be negligible, but the impact of both going out may be really bad. This is often difficult to spot; the Atlanta airport power outage in 2017 is a good example. (such as you losing all of your customers’ files and paying large fines) would be a high risk. Something that’s very unlikely to happen (such as an asteroid wiping out two different regional data centers at once) but that would be very bad if it does happen (going out of business) might only be a low risk, depending on the system you use for deciding the level of risk.4 In this book, I’ll talk about unknown risks (where we don’t have enough information to know what the likelihoods and impacts are) and known risks (where we at least know what we’re up against). Once you have an idea of the known risks, you can do one of four things with them: 1. Avoid the risk. In information security this typically means you turn off the sys‐ tem—no more risk, but also none of the benefits you had from running the sys‐ tem in the first place. 2. Mitigate the risk. It’s still there, but you do additional things to lower either the likelihood that the bad thing will happen or the impact if it does happen. For example, you may choose to store less sensitive data so that if there is a breach, the impact won’t be as bad. 3. Transfer the risk. You pay someone else to manage things so that the risk is their problem. This is done a lot with the cloud, where you transfer many of the risks of managing the lower levels of the system to the cloud provider. 4. Accept the risk. After looking at the overall risk level and the benefits of continu‐ ing the activity, you decide to write down that the risk exists, get all of your stake‐ holders to agree that it’s a risk, and then move on. Any of these actions may be reasonable. However, what’s not acceptable is to either have no idea what your risks are, or to have an idea of what the risks are and accept them without weighing the consequences or getting buy-in from your stakeholders. At a minimum, you should have a list somewhere in a spreadsheet or document that details the risks you know about, the actions taken, and any approvals needed. Risk Management | 11
- 29. CHAPTER 2 Data Asset Management and Protection Now that Chapter 1 has given you some idea of where your provider’s responsibility ends and yours begins, your first step is to figure out where your data is—or is going to be—and how you’re going to protect it. There is often a lot of confusion about the term “asset management.” What exactly are our assets, and what do we need to do to manage them? The obvious (and unhelpful) answer is that assets are anything valua‐ ble that you have. Let’s start to home in on the details. In this book, I’ve broken up asset management into two parts: data asset management and cloud asset management. Data assets are the important information you have, such as customer names and addresses, credit card information, bank account infor‐ mation, or credentials to access such data. Cloud assets are the things you have that store and process your data—compute resources such as servers or containers, stor‐ age such as object stores or block storage, and platform instances such as databases or queues. Managing these assets is covered in the next chapter. While you can start with either data assets or cloud assets, and may need to go back and forth a bit to get a full picture, I find it easier to start with data assets. The theory of managing data assets in the cloud is no different than on-premises, but in practice there are some cloud technologies that can help. Data Identification and Classification If you’ve created at least a “back-of-the-napkin” diagram and threat model as described in the previous chapter, you’ll have some idea of what your important data is, as well as the threat actors you have to worry about and what they might be after. Let’s look at different ways the threat actors may attack your data. 13
- 30. 1 Ransomware is both an availability and an integrity breach, because it uses unauthorized modifications of your data in order to make it unavailable. 2 If you have unlimited resources, please contact me! One of the more popular information security models is the CIA triad: confidential‐ ity, integrity, and availability. A threat actor trying to breach your data confidentiality wants to steal it, usually to sell it for money or embarrass you. A threat actor trying to breach your data integrity wants to change your data, such as by altering a bank bal‐ ance. (Note that this can be effective even if the attacker cannot read the bank balan‐ ces; I’d be happy to have my bank balance be a copy of Bill Gates’s, even if I don’t know what that value is.) A threat actor trying to breach your data availability wants to take you offline for fun or profit, or use ransomware to encrypt your files.1 Most of us have limited resources and must prioritize our efforts.2 A data classifica‐ tion system can assist with this, but resist the urge to make it more complicated than absolutely necessary. Example Data Classification Levels Every organization is different, but the following rules provide a good, simple starting point for assessing the value of your data, and therefore the risk of having it breached: Low While the information in this category may or may not be intended for public release, if it were released publicly the impact to the organization would be very low or negligible. Here are some examples: • Your servers’ public IP addresses • Application log data without any personal data, secrets, or value to attackers • Software installation materials without any secrets or other items of value to attackers Moderate This information should not be disclosed outside of the organization without the proper nondisclosure agreements. In many cases (especially in larger organiza‐ tions) this type of data should be disclosed only on a need-to-know basis within the organization. In most organizations, the majority of information will fall into this category. Here are some examples: • Detailed information on how your information systems are designed, which may be useful to an attacker • Information on your personnel, which could provide information to attack‐ ers for phishing or pretexting attacks 14 | Chapter 2: Data Asset Management and Protection
- 31. • Routine financial information, such as purchase orders or travel reimburse‐ ments, which might be used, for example, to infer that an acquisition is likely High This information is vital to the organization, and disclosure could cause signifi‐ cant harm. Access to this data should be very tightly controlled, with multiple safeguards. In some organizations, this type of data is called the “crown jewels.” Here are some examples: • Information about future strategy, or financial information that would pro‐ vide a significant advantage to competitors • Trade secrets, such as the recipe for your popular soft drink or fried chicken • Secrets that provide the “keys to the kingdom,” such as full access credentials to your cloud infrastructure • Sensitive information placed into your hands for safekeeping, such as your customers’ financial data • Any other information where a breach might be newsworthy Note that laws and industry rules may effectively dictate how you classify some infor‐ mation. For example, the European Union’s General Data Protection Regulation (GDPR) has many different requirements for handling personal data, so with this sys‐ tem you might choose to classify all personal data as “moderate” risk and protect it accordingly. Payment Card Industry (PCI) requirements would probably dictate that you classify cardholder data as “high” risk if you have it in your environment. Also, note that there are cloud services that can help with data classification and pro‐ tection. As examples, Amazon Macie can help you find sensitive data in S3 buckets, and the Google Cloud Data Loss Prevention API can help you classify or mask cer‐ tain types of sensitive data. Whatever data classification system you use, write down a definition of each classifi‐ cation level and some examples of each, and make sure that everyone generating, col‐ lecting, or protecting data understands the classification system. Relevant Industry or Regulatory Requirements This is is a book on security, not compliance. As a gross overgeneralization, compli‐ ance is about proving your security to a third party—and that’s much easier to accomplish if you have actually secured your systems and data. The information in this book will help you with being secure, but there will be additional compliance work and documentation to complete after you’ve secured your systems. Data Identification and Classification | 15
- 32. However, some compliance requirements may inform your security design. So, even at this early stage, it’s important to make note of a few industry or regulatory require‐ ments: EU GDPR This regulation may apply to the personal data of any European Union or Euro‐ pean Economic Area citizen, regardless of where in the world the data is. The GDPR requires you to catalog, protect, and audit access to “any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier.” The techniques in this chapter may help you meet some GDPR requirements, but you must make sure that you include relevant personal data as part of the data you’re protecting. US FISMA or FedRAMP Federal Information Security Management Act is per-agency, whereas Federal Risk and Authorization Management Program certification may be used with multiple agencies, but both require you to classify your data and systems in accordance with FIPS 199 and other US government standards. If you’re in an area where you may need one of these certifications, you should use the FIPS 199 classification levels. US ITAR If you are subject to International Traffic in Arms regulations, in addition to your own controls, you will need to choose cloud services that support ITAR. Such services are available from some cloud providers and are managed only by US personnel. Global PCI DSS If you’re handling credit card information, the Payment Card Industry Data Security Standard dictates that there are specific controls that you have to put in place, and there are certain types of data you’re not allowed to store. US HIPAA If you’re in the US and dealing with any protected health information (PHI), the Health Insurance Portability and Accountability Act mandates that you include that information in your list and protect it, which often involves encryption. There are many other regulatory and industry requirements around the world, such as MTCS (Singapore), G-Cloud (UK), and IRAP (Australia). If you think you may be subject to any of these, review the types of data they are designed to protect so that you can ensure that you catalog and protect that data accordingly. 16 | Chapter 2: Data Asset Management and Protection
- 33. Discovering Diverse Content Through Random Scribd Documents
- 34. Incontinency, compurgation for, 87 India, communal organization in, 14 use of oaths, 25 evidence of friends and kinsmen excluded, 38 duel to avert battles, 104 judicial duel not used, 108 limitations on witnesses, 122 champions allowed in ordeals, 179 ordeals of pre-Aryan races, 258, 291, 344 oaths as ordeals, 267 ordeal of fire, 267 complicated ordeal system, 268 is a religious ceremony, 269, 280 ordeal of boiling oil, 283 of red-hot iron, 289 of fire, 303 relics tested by fire, 314 ordeal of cold water, 319 of balance, 334 of endurance, 339 of rice, 344 of cosha, or idol-water, 344 of chance, 352 of poison, 375 only for doubtful characters, 384 either party can undergo the ordeal, 384 minimum limit of ordeals, 391 torture unknown, 431 Infamy of champions, 187 ordeal in cases of, 388 Influence of torture on judges, 534 Informers, responsibility of, in Rome, 440, 446 under Wisigoths, 459
- 35. Injustice of ordeal, explanation of, 401 Innocent I. on use of torture, 477 Innocent II. prescribes compurgation, 62, 71 forbids clerics to fight, 156 Innocent III. modifies compurgatorial oaths, 71 orders purgation for heresy, 89 on failure in duel, 137 forbids clerics to fight, 156, 158 his relation to the duel, 208 suppresses the ordeal, 418 Innocent IV. forbids clerical duels in France, 159 orders torture to discover heresy, 484 Innocent VIII. on torture of clerics in England, 566 Inquest of Fame, 71 Inquests, torture not used in, 499, 512 Inquisition, its use of compurgation, 89 its use of torture, 483 extortion of confession, 485 its influence on use of torture, 486, 512 restricted by Council of Vienne, 511 torture to discover accomplices, 516 Inquisition of State in Venice, 507 Inquisitorial Process, the, 512 becomes general, 499 not used in Poland, 509 retained in Germany, 581 Inquisitors dispensed for use of torture, 484 Insane, the, exempt from torture, 528 Inscription of accuser in Rome, 440, 446 under Wisigoths, 459
- 36. Intervention of God expected in the duel, 135 Inundation of 1219 caused by ordeals, 422 Inverness exempted from duel, 201 Involuntary perjury, penance for, 31 Ipswich, selection of conjurators in, 49 Ireland, solidarity of the family in, 15 levying of fines, 18 tribal responsibility, 42 judicial duel among the Feini, 109 duel in 1583, 243 inspiration of judges, 272 hot-water ordeal in, 273 hot-iron ordeal for women, 292 ordeal of the lot, 354 of the oath, 374 use of the Clog Oir, 397 Irregular ordeals, 377 Irregularity of clerics, 484 Iron bands used as an ordeal, 377 Iron ordeal (see Red-hot iron). Isaac, assassin of Charles the Good, 474 Isidor of Seville on perjury, 31 Islam, reduplicated oaths, 29 accusations of adultery, 46 oaths as ordeals in, 263 Italy (see also Lombard Law, Sicilian Constitutions). conjurators to confirm witnesses, 56 challenging of witnesses, 120 Otho II. enlarges the sphere of the duel, 131 cases admitting the duel, 141
- 37. the Church subjected to the duel, 155, 160 jurisdiction of the Church over duel, 163 oaths preliminary to the duel, 166 penalty for defeat in duel, 169 duels fought to the end, 178 champions always employed, 182 as a profession, 189 restrictions on use of, 189 equalization of, 194 abrogation of duel, 235 bier-right, 365 ordeals prohibited in Naples, 422 in 15th century, 425 reappearance of torture, 481, 484 its development, 506 its abolition, 586 Itzehoe, case of bier-right in, 365 Ivan III., torture introduced by, 509 Ivo of Chartres, distrust of compurgation, 61 refuses to grant the duel, 162 his opinion of the ordeal, 401, 412 claims exemption of ordeal for priests, 414 on extorted confessions, 478 Jacintus, his hot-water ordeal, 279 Jacob’s Review of the Statutes, 86 James I. grants the duel, 240 approves of ordeal for witches, 330 his belief in bier-right, 361 torture under, 567, 568 his torture of Dr. Fian, 573 Jamnuggur, ordeal in 1867, 284 Janssen, Hendrik, torture of, 578
- 38. Jardine on torture in England, 566 Jarnac, his duel with La Chastaigneraye, 106 Japan, judicial duel in, 108 ordeals in, 253 use of torture, 432 Jayme I. (Aragon) restricts torture, 462 prohibits the duel, 214 Jeanne de Bourgogne, offers the combat, 226 Jeffniteed, 97 Jehan de Warlus, case of, 501 Jerusalem, Assisses de, 75 on use of counsel, 70 reject negative proofs, 74 no compurgation, 75 women cannot be witnesses, 122 limitations on duel, 143 limit of value for duel, 148 discrimination of race in, 151 champions supplied to the poor, 152 no duel in mercantile law, 165 lex talionis enforced, 170 penalty of defeat for women, 173 champions as witnesses, 183 punishment of defeated champion, 184 red-hot iron ordeal plebeian, 292 use of iron ordeal, 298 ordeal for all suspects, 388 reappearance of torture, 480 Jew, duel with, ordered by the Virgin, 209 ordeal to convert, 296 Jews (see also Hebrews). their liability to the duel, 149, 151
- 39. asking pardon of a corpse, 360 convicted by bier-right, 362 ordeal of brambles for, 382 torture of, by King John, 477 in Bourges, 492 mode of executing them, 503 John XII. challenged by Bishop Liutprand, 129 John, King (England), favors the duel, 241 tortures Jews, 477 John, King (France), abrogates compurgation, 78 John, Bishop of Avranches, recognizes the ordeal, 412 John, Bishop of Didymoteichos, 402 John of Coldinghame, 191 John of Freiburg on duel in episcopal courts, 165 John of Freiburg—denounces ordeals, 420 Jonah, use of lot, 262 Jonathan, case of, 262 Joseph II. abolishes torture, 581 Jovem lapidem jurare, 270 Judaism (see Hebrews). Judges decide as to compurgators, 53 challenging of, 123 royal, not liable to appeal, 126 discretion in granting duel, 140, 146 inspiration of, in Islam, 263 inspiration of, among Feini, 272 responsibility for torture under Wisigoths, 458, 460 in Castile, 465, 467 in Italy, 507 in France, 515
- 40. in Germany, 523 responsibility elusory, 533 using torture liable for homicide in England, 565 cannot be witnesses, 509 everything left to their discretion, 533, 538, 541, 549 abuse of their discretion, 545 influence of torture on, 534 their abuse of torture, 539 their neglect of favoring evidence, 544 Judgment of God expected, 250 faith reposed in, 102 appealed to by Hebrews, 261 Judgment reversed, penalty of, 124, 126 of blood forbidden to clerics, 471 Judicial duel, 101 Judicium means ordeal, 298 Judicium crucis, 336 Judicium ferri, 287 Judicium offæ, 339 Juise, 287, 298 Julius (Pseudo) forbids evidence of accomplices, 515 Julius II., his bull against duels, 236 Jura de juicio, 22 Juramentum supermortuum, 55 Juratores (see Conjurators). Jurisdiction over duel, profits of, 218 over ordeals, its advantages, 415 Jury and ordeal combined, 388 Jury-trial, rise of, 48
- 41. as substitute for duel, 144 for pleaders unable to fight, 192 in Denmark, 562 influence of, on the duel, 241 in England, 564 Jus cruentationis, 359 Jus feretri, 359 Jus Provinciale Alamannicum (see Schwabenspiegel). Jus Provinciale Saxonicum (see Sachsenspiegel). Jusjurandum in jure, 21, 22 Jusiers, church of, its exemption, 158 Justice, tardy recognition of, 13 Justinian orders torture for adultery, 439 enforces the talio, 440 orders torture of witnesses, 441 Kai Kaoos orders fire ordeal, 266 Kalabarese ordeals, 254 Katrington, his duel, 179 Kayser-Recht, duel limited in, 205 denounces the duel, 212 no allusion to torture, 480 Keller, Fried., opposes torture, 576 Keure de Bruges, 203 Keyser Retenn, 563 Khandogya Upanishad, its explanation of the ordeal, 267 Khonds, ordeals among the, 258 Kilty on duel in Maryland, 247
- 42. Kincaid, a witch-pricker, 571 King vs. Williams, case of, 86 Kinship a bar to duel, 141 Kinsmen, responsibility of, 14, 18, 19 their evidence, 38 not admitted in Castile, 465 as compurgators, 38, 40, 45, 48, 50 as champions, 180 witness not tortured against, 542 Knighthood, oath of, 186 Knipschild on torture of nobles, 526 Knox, John, on Bothwell’s challenge, 240 Koran, accusation of adultery in, 46 Kraku Hreidar, 111 Kshatriya caste, oaths required of, 25 La Chastaigneraye, his duel with Jarnac, 106 Lactantius, his account of persecution, 437 Ladislas, St., prevents collusion in ordeal, 405 regulates fees for ordeals, 416 Lafon, Mary, on affaire Calas, 585 Lag feste men, 41 Lambert of Redenberg, case of, 401 Lambert of Tuscany, his duel, 128 Lamoignon on counsel for accused, 517 Lance of St. Andrew, case of, 308 Lancelotti prescribes compurgation, 93 Land, communal holding of, 14
- 43. acquired by duel, 111, 211 Land-titles decided by ordeal of cross, 339 Lang, J. P., on cold-water ordeal for witches, 330 Languedoc, use of torture in, 495 Laon, theft of sacred vessels of, 136, 324, 474 Lascaris, Theod., invents a torture, 554 La Seauve, Abbey of, its revenue from ordeals, 415 Lateran, council of, 1216, on heresy, 89 forbids clerics to fight, 156 forbids the duel, 208 forbids priestly ministration in ordeals, 419 on purgation of heresy, 484 Latins, ordeals disused among, 270 Lausanne, chapter of, adjudges the duel, 162 Law means compurgation, 57 personal, not territorial, 131 Lawyers, advantage of employing, 70 exempt from torture in Castile, 467 Laymen as compurgators for clerics, 44 sin of shaving by, 403 Lebanon, Ills., bier-right in, 368 Ledesma, case of bier-right in, 366 Legislation, secular, against ordeals, 421 Legislative functions of duel, 129, 133 Legitimacy proved by ordeal, 273, 381 Le Gris and Carrouges, duel of, 229 Lemarinier, Jehan, case of, 517
- 44. Lemgow, cold-water ordeal in, 327 Lent, ordeal administered in, 410 Leo III. (Pope) clears himself by compurgation, 35 cold-water ordeal ascribed to, 321 Leo IV. forbids ordeal of lot, 353 Leo X., his prohibition of duels, 236 Leopold, Gr. Duke, abolishes torture, 586 Leper cured by St. Martin’s relics, 380 battle not allowed to, 141 Les cous lou roi, 163 Lescar, Bishop of, uses the ordeal, 295 Lèse majesté, first recognition of, in France, 495 its appearance in England, 564 Lessingon, patronage of church of, 119 Leudastes, case of, 454 Lex apparens and simplex, 148 Lex Gundebalda, 112 Lex Monachorum, 412 Lex talionis (see Talio). Lhotka, assembly of, 355 Libo, prosecution of, 443 Lie as preliminary to duel, 229 Liége, Bishop of, demands the duel, 160 use of torture in, 505 Liguaire, St., quarrel over his relics, 354 Life not to be jeoparded in torture, 465, 467
- 45. Lilburn and Claxton, case of, 244 Lille, responsibility of kindred, 19 formula of compurgation in, 78 torture not used in, 498 Lillebonne, council of, 1080, on clerical duellists, 156 on fees for ordeals, 416 Lima, fees for torturing in, 511 Limitations on the duel, 140 on use of champions, 189 on torture in Rome, 445 in Castile, 465 none in Châtelet of Paris, 500 in Italy, 506 disregarded, 526 Limbs not to be crippled in torture, 465, 467 Lindisfarne, unchaste priest of, 346 Lioba, St., undergoes ordeal of cross, 337 Lists, biers placed in, 172 Litus, his right to duel, 148 Liutgarda forced to duel, 123 Liutprand (King), on perjury of compurgators, 63 restricts judicial duel, 114 Liutprand, Bishop, his challenges, 129 Liutprand convicts Grossolano by ordeal, 306 Livonians asked to be relieved from ordeals, 423 Livre de Jostice et de Plet requires compurgation, 76 no reference to torture, 488 Ljot the Pale, 111
- 46. Loaf of bread, ordeal of, 357 Lombard law— rules for compurgation, 47, 50, 53 withdrawal of confession, 52 oath of compurgators, 58 ceremony of compurgation, 60 witnesses outweigh conjurators, 62 perjury of compurgators, 63 Otho II. limits compurgation, 67 judicial duel, 113 Otho II. extends use of duel, 118, 131 duel allowed to the guilty, 131 minimum limit for duel, 147 right of slaves to duel, 148 liability of clerics to duel, 155 penalty for defeat in duel, 168 kinsmen as champions, 180 champions always employed, 181 freedmen or clients, 186 restrictions on use of champions, 189 use of hot-water ordeal, 283 cold-water ordeal prohibited, 322 for slaves, 322 duel for cases of sorcery, 326 ordeal of cross prohibited, 338 London, exemption from duel granted, 201 Loquetier, Nicholas, case of, 493 Lord and vassal, no duel between, 146 Lorraine, Dukes of, their rights over duel, 238 Lorris, oaths in laws of, 23 fines for withdrawing from duel, 144 Lot, ordeal of the, 352 among Hebrews, 261
- 47. in Greece, 270 Lothair, King, his divorce from Teutberga, 281 dies of ordeal of Eucharist, 349 Lothair I. (Emp.), formula of compurgation, 53 prohibits cold-water ordeal, 322 prohibits ordeal of cross, 338 Lothair II., his use of torture, 475 Loudon, charter of, 391 Louis le Débonnaire tries Pascal I., 37 on selection of conjurators, 51 compurgation in lack of evidence, 53 on penalty for defeat, 167 condemns cold-water ordeal, 321 prohibits ordeal of cross, 338 orders freemen present at mallum, 472 Louis II. (Emp.), compurgation in lack of evidence, 53 decides cases in favor of Siena, 56 Louis IV. (Emp.), his charter to Dortmund, 205 punishes Ueberlingen, 363 Louis d’Outremer offers duel to Hugh Capet, 130 Louis VI. (France) grants charter of Loudun, 391 Louis VII., his charter to Lorris, 23 exempts the church of Jusiers, 158 Louis VIII., his charter to Crespy, 203 Louis IX. on use of oaths, 23 makes clients responsible for advocates, 70 his Établissements, 76 restricts challenging of judges, 125 prohibits duel between brothers, 141 enforces the lex talionis, 170 his struggle with feudalism, 216
- 48. his restriction of the duel, 217 punishes Enguerrand de Coucy, 221 torture not in his laws, 488 gives facilities for defence, 512 Louis X. endeavors to repress the duel, 227 orders cold-water ordeal for sorcery, 326 maintains use of torture, 494 Louis XIV. revises the torture process, 517 Louis XVI. abolishes torture in France, 585 Louis of Saxony, his use of the ordeal, 400 Lourdes exempted from duel, 202 Low vs. Paramore, case of, 139, 243 Lowe’s case, torture in, 571 Lubeck, introduction of torture in, 483 Lucerne, case of bier-right, 363 Lucius III. annuls judgment by ordeal, 418 Lucretius quoted for bier-right, 360 Ludlow, ordeal of Bible and key, 357 Luitzes, their duel with Saxons, 131 Lust, unnatural, torture for, in Rome, 439 Lycanthropy, prolonged torture for, 529 Lyons, council of, 1080, on simony, 62 Archbishop of, uses ordeal for heretics, 411 Macarius, St., his appeal to God, 251 Maci, Jehannin, case of, 501 Madagascar, ordeals in, 256 Madrid, compurgation in fuero of, 75
- 49. Magdeburg, thieves convicted by the duel, 135 Magi use fire-test on swaddling cloth of Christ, 315 Magic arts in duel, 139 in ordeal, 407, 410 torture in trials for, 469, 554 Magicians lose their specific gravity, 325, 334 tortured in Rome, 439 their evidence not received, 523 Magna Charta, no allusion to torture in, 564 Mahabharata, the, 14 Mahomet on accusations of adultery, 46 on interposition of God, 262 Mahuot and Plouvier, duel of, 232 Maiming, permanent, prerequisite for duel, 142 Mainz, council of, 847, ordeal for slaves, 394 council of, 848, prescribes iron ordeal, 291 councils of, 888 and 1028, prescribe the ordeal, 410 Templars offer the ordeal, 299 Majestas, torture in, 435, 438, 443 its extension, 436 Majjars, ordeals introduced among, 277 Majorca, duel prohibited, 214 ordeal prohibited, 424 Mallum, regulations for holding it, 471 Manasses of Reims deposed for simony, 62 Manava Dharma Sastra, village communities in, 14 oaths prescribed in, 25 on perjury, 267 ordeals described in, 268
- 50. Mandeure, ordeal of staff in, 396 Manichæan defeated by fire ordeal, 304 Manorial courts, compurgation in, 57 Mansuetus, St., power of his intercession, 378 Mantra in Hindu ordeals, 289 for cold-water ordeal, 319 for ordeal of balance, 335 for poison ordeal, 375 Manuscripts tested by fire, 313 Marches, Scottish, duel universal, 145 liability of clerics to duel, 158 death does not release from duel, 174 Marcus Aurelius, his exemptions from torture, 438 Maresca, Marc Antonio, case of, 520 Maria Theresa, torture in her laws, 580 Marguerite de la Pinele, case of, 503 Marmoutiers, Abbey of, case of, 404 Marne, jurisdiction of duel at, 163 Marriage, compurgation to prove nullity, 93 tested by ordeal, 336, 410 Marshal’s court, the, regulates duels, 241 Marschalck, his duel, 172 Marsigli, Hipp. de’, his case of bier-right, 365 his torture of sleeplessness, 535 on abuse of torture, 539 Martial, St., of Limoges, perjury on his altar, 373 Martin of Austrasia, 29 Martin, St., vindicates his relics, 380
- 51. his cope used in compurgation, 60 Martin II. forbids duel of Charles of Anjou, 106 Mary, wife of Otho III., story of, 293 Mary, Queen, torture under, 568 Maryland, compurgation in, 88 appeal of death in, 247 Mass as part of the ordeal, 413 mortuary, in ritual of ordeal, 394 Massachusetts, appeal of death in, 246 use of torture in, 569 peine forte et dure, 575 Masserano, Marquis of, 531 Master’s oath clears a slave, 22, 390 Master and serf, no duel between, 146 his consent necessary to his serf’s duel, 149 slaves not tortured against, in Rome, 442 except in treason, 443 other exceptions, 444 under Ostrogoths, 457 under Wisigoths, 459 in Spain, 464 repaid for damage to tortured slave in Rome, 445 among Barbarians, 452 under Wisigoths, 458 in Castile, 468 Maternal kindred as compurgators, 45 Mathieu le Voyer sues Louis IX., 219 Matthias Corvinus restricts the duel, 237 Maubourguet exempted from duel, 203 Maumarel, Guillaume, 157
- 52. Maur, St., perjury on his relics, 273 Maximilian I. restricts compurgation, 81 Maximus on crimes involving torture of slave against master, 444 Mazdeism, ordeals in, 265, 295 torture not prescribed in, 431 Mecklenburg, ordeal introduced into, 277 Medina del Pomar exempted from duel, 202 ordeals prohibited, 424 Melanesians, judicial duel among, 108 Men, hot-iron or water ordeal for, 292 Menelaus and Paris, their duel, 108 Mennonites, use of the lot by, 355 Mental torture efficacious, 543 Mercantile law, duel not recognized in, 165 adverse to use of torture, 483 torture used in, 530 Merchants, multiple oaths by, 28 exempted from the duel, 204 Merida, council of, 666, on torture by priests, 554 Merovingian laws, accusatorial conjurators, 94 ordeal for slaves, 453 of the lot prescribed, 353 in absence of evidence, 386 precautions against collusion in ordeals, 405 Merovingians, torture used by, 454 Merseburg, thieves convicted by the duel, 135 Messalina, her torture of patricians, 439
- 53. Metz, Bishop of, has jurisdiction over duel, 164 Mexico, ordeal of oath in, 259 Michael Palæologus condemned to ordeal, 299 Milan, disappearance of duel in, 236 fire ordeal in, 306 restrictions on torture in, 506 Miles the Stammerer, his duel, 138 Milhaud, torture used in, 499 Minimum limit of value for duel, 147 for ordeals, 391 for ordeal in India, 290 Mir, the Russian, 15 Miracle, endurance of torture is a, 504 Miraculous hot-water ordeals, 285 red-hot iron ordeals, 301 Miralles, Archbishop, tests relics by fire, 317 Mirandola, limitations on torture in, 507 Miroir de Souabe, ordeals in, 424 Modena, iron ordeal in, 299 Bishop of, claims jurisdiction of duel, 163 Modestinus, his estimate of torture, 446 Modestus tortured by Fredegonda, 455 Moine de Caen, 516 Monasteries, their interest in ordeals, 415 torture in, 560 Monks as compurgators for monks, 93 appear personally in duels, 156 torture of, 560, 568
- 54. Montaigne argues against torture, 576 Montano of Toledo, his ordeal, 305 Montargis, story of dog of, 228 Monte Cassino, test of relics by fire, 316 Montenegro, ordeal for witches, 333 Montesquieu denounces torture, 583 Montigny-le-Roi, ordeal for witches at, 331 Montfort, Simon de, restricts the duel, 208 Montpellier, limitation on duel, 146 on ordeal, 387 Montricher, Sire de, case of, 150 Monza, duel of abbey at, 158 Mt. Gerizim, its claims tested by fire, 314 Moore, Samuel, case of, 510 Morann, his miraculous chain, 272 Moravia, the duel in, 205 Mortuary mass in ritual of ordeal, 394 Motive extenuates perjury, 31, 268 Mowbray, Francis, condemned to the duel, 240 Mozarabic rite defended by duel, 132 tested by fire, 313 Mstislas Davidovich exempts merchants from the duel, 204 Muh-Wang, his instructions to his judges, 252 Multiple oaths, 28 Municipal champions, 196 Muratori on ordeal for witches, 332
- 55. Murder (see Homicide). Mutilation of defeated champions, 184 under torture unusual, 532 Myagh, Thos., his torture, 569 Myrc, John, instructions to priests, 242 Name written on paper and used in ordeal, 398 Namur, council of, sustains the duel, 238 Naples (see Sicilian Constitutions). fire ordeal in 1811, 317 ordeals prohibited in, 422 punishment for suspicion in, 520 torture after conviction, 546 modern torture in, 587 Natives can decline duel with strangers, 141 Navarre and Castile, proposed duel between, 129 late introduction of torture, 469 Neffn i kyn, 41 Nefninge, 562 Negative proofs in Barbarian laws, 73 rejected, 74 unknown to Roman law, 272 Nehring, J. C., oil ordeal for witches, 331 Nempdarii, 563 Nero, his torture of Christians, 436 Netherlands, compurgation in, 81 ordeal of balance in, 335 bier-right in, 365 torture system in, 521 torture abolished in, 578
- 56. Welcome to our website – the ideal destination for book lovers and knowledge seekers. With a mission to inspire endlessly, we offer a vast collection of books, ranging from classic literary works to specialized publications, self-development books, and children's literature. Each book is a new journey of discovery, expanding knowledge and enriching the soul of the reade Our website is not just a platform for buying books, but a bridge connecting readers to the timeless values of culture and wisdom. With an elegant, user-friendly interface and an intelligent search system, we are committed to providing a quick and convenient shopping experience. Additionally, our special promotions and home delivery services ensure that you save time and fully enjoy the joy of reading. Let us accompany you on the journey of exploring knowledge and personal growth! textbookfull.com