Building Secure and Reliable Systems. Best Practices for Designing, Implementing, and Maintaining Systems Heather Adkins, Betsy Beyer, Paul Blankinship

Spis treści książki

• Foreword by Royal Hansen
• Foreword by Michael Wildpaner
• Preface
  • Why We Wrote This Book
  • Who This Book Is For
  • A Note About Culture
  • How to Read This Book
  • Conventions Used in This Book
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• I. Introductory Material
• 1. The Intersection of Security and Reliability
  • On Passwords and Power Drills
  • Reliability Versus Security: Design Considerations
  • Confidentiality, Integrity, Availability
    • Confidentiality
    • Integrity
    • Availability
  • Reliability and Security: Commonalities
    • Invisibility
    • Assessment
    • Simplicity
    • Evolution
    • Resilience
    • From Design to Production
    • Investigating Systems and Logging
    • Crisis Response
    • Recovery
  • Conclusion
• 2. Understanding Adversaries
  • Attacker Motivations
  • Attacker Profiles
    • Hobbyists
    • Vulnerability Researchers
    • Governments and Law Enforcement
      • Intelligence gathering
      • Military purposes
      • Policing domestic activity
      • Protecting your systems from nation-state actors
    • Activists
      • Protecting your systems from hacktivists
    • Criminal Actors
      • Protecting your systems from criminal actors
    • Automation and Artificial Intelligence
      • Protecting your systems from automated attacks
    • Insiders
      • First-party insiders
      • Third-party insiders
      • Related insiders
      • Threat modeling insider risk
      • Designing for insider risk
  • Attacker Methods
    • Threat Intelligence
    • Cyber Kill Chains
    • Tactics, Techniques, and Procedures
  • Risk Assessment Considerations
  • Conclusion
• II. Designing Systems
• 3. Case Study: Safe Proxies
  • Safe Proxies in Production Environments
  • Google Tool Proxy
  • Conclusion
• 4. Design Tradeoffs
  • Design Objectives and Requirements
    • Feature Requirements
    • Nonfunctional Requirements
    • Features Versus Emergent Properties
    • Example: Google Design Document
  • Balancing Requirements
    • Example: Payment Processing
      • Security and reliability considerations
      • Using a third-party service provider to handle sensitive data
        • Benefits
        • Costs and nontechnical risks
        • Reliability risks
        • Security risks
  • Managing Tensions and Aligning Goals
    • Example: Microservices and the Google Web Application Framework
    • Aligning Emergent-Property Requirements
  • Initial Velocity Versus Sustained Velocity
  • Conclusion
• 5. Design for Least Privilege
  • Concepts and Terminology
    • Least Privilege
    • Zero Trust Networking
    • Zero Touch
  • Classifying Access Based on Risk
  • Best Practices
    • Small Functional APIs
    • Breakglass
    • Auditing
      • Collecting good audit logs
      • Choosing an auditor
    • Testing and Least Privilege
      • Testing of least privilege
      • Testing with least privilege
    • Diagnosing Access Denials
    • Graceful Failure and Breakglass Mechanisms
  • Worked Example: Configuration Distribution
    • POSIX API via OpenSSH
    • Software Update API
    • Custom OpenSSH ForceCommand
    • Custom HTTP Receiver (Sidecar)
    • Custom HTTP Receiver (In-Process)
    • Tradeoffs
  • A Policy Framework for Authentication and Authorization Decisions
    • Using Advanced Authorization Controls
    • Investing in a Widely Used Authorization Framework
    • Avoiding Potential Pitfalls
  • Advanced Controls
    • Multi-Party Authorization (MPA)
    • Three-Factor Authorization (3FA)
    • Business Justifications
    • Temporary Access
    • Proxies
  • Tradeoffs and Tensions
    • Increased Security Complexity
    • Impact on Collaboration and Company Culture
    • Quality Data and Systems That Impact Security
    • Impact on User Productivity
    • Impact on Developer Complexity
  • Conclusion
• 6. Design for Understandability
  • Why Is Understandability Important?
    • System Invariants
    • Analyzing Invariants
    • Mental Models
  • Designing Understandable Systems
    • Complexity Versus Understandability
    • Breaking Down Complexity
    • Centralized Responsibility for Security and Reliability Requirements
  • System Architecture
    • Understandable Interface Specifications
      • Prefer narrow interfaces that offer less room for interpretation
      • Prefer interfaces that enforce a common object model
      • Pay attention to idempotent operations
    • Understandable Identities, Authentication, and Access Control
      • Identities
        • Example: Identity model for the Google production system
      • Authentication and transport security
      • Access control
    • Security Boundaries
      • Small TCBs and strong security boundaries
      • Security boundaries and threat models
      • TCBs and understandability
  • Software Design
    • Using Application Frameworks for Service-Wide Requirements
    • Understanding Complex Data Flows
    • Considering API Usability
      • Example: Secure cryptographic APIs and the Tink crypto framework
  • Conclusion
• 7. Design for a Changing Landscape
  • Types of Security Changes
  • Designing Your Change
  • Architecture Decisions to Make Changes Easier
    • Keep Dependencies Up to Date and Rebuild Frequently
    • Release Frequently Using Automated Testing
    • Use Containers
    • Use Microservices
      • Example: Googles frontend design
  • Different Changes: Different Speeds, Different Timelines
    • Short-Term Change: Zero-Day Vulnerability
      • Example: Shellshock
    • Medium-Term Change: Improvement to Security Posture
      • Example: Strong second-factor authentication using FIDO security keys
    • Long-Term Change: External Demand
      • Example: Increasing HTTPS usage
  • Complications: When Plans Change
  • Example: Growing ScopeHeartbleed
  • Conclusion
• 8. Design for Resilience
  • Design Principles for Resilience
  • Defense in Depth
    • The Trojan Horse
      • Threat modeling and vulnerability discovery
      • Deployment of the attack
      • Execution of the attack
      • Compromise
    • Google App Engine Analysis
      • Risky APIs
      • Runtime layers
  • Controlling Degradation
    • Differentiate Costs of Failures
      • Computing resources
      • User experience
      • Speed of mitigation
    • Deploy Response Mechanisms
      • Load shedding
      • Throttling
      • Automated response
    • Automate Responsibly
      • Failing safe versus failing secure
      • A foothold for humans
  • Controlling the Blast Radius
    • Role Separation
    • Location Separation
      • Aligning physical and logical architecture
      • Isolation of trust
        • Limitations of location-based trust
      • Isolation of confidentiality
    • Time Separation
  • Failure Domains and Redundancies
    • Failure Domains
      • Functional isolation
      • Data isolation
      • Practical aspects
    • Component Types
      • High-capacity components
      • High-availability components
      • Low-dependency components
    • Controlling Redundancies
      • Failover strategies
      • Common pitfalls
  • Continuous Validation
    • Validation Focus Areas
    • Validation in Practice
      • Inject anticipated changes of behavior
      • Exercise emergency components as part of normal workflows
      • Split when you cannot mirror traffic
      • Oversubscribe but prevent complacency
      • Measure key rotation cycles
  • Practical Advice: Where to Begin
  • Conclusion
• 9. Design for Recovery
  • What Are We Recovering From?
    • Random Errors
    • Accidental Errors
    • Software Errors
    • Malicious Actions
  • Design Principles for Recovery
    • Design to Go as Quickly as Possible (Guarded by Policy)
    • Limit Your Dependencies on External Notions of Time
    • Rollbacks Represent a Tradeoff Between Security and Reliability
      • Deny lists
      • Minimum Acceptable Security Version Numbers
      • Rotating signing keys
      • Rolling back firmware and other hardware-centric constraints
    • Use an Explicit Revocation Mechanism
      • A centralized service to revoke certificates
      • Failing open
      • Handling emergencies directly
      • Removing dependency on accurate notions of time
      • Revoking credentials at scale
      • Avoiding risky exceptions
    • Know Your Intended State, Down to the Bytes
      • Host management
      • Device firmware
      • Global services
      • Persistent data
    • Design for Testing and Continuous Validation
  • Emergency Access
    • Access Controls
    • Communications
    • Responder Habits
  • Unexpected Benefits
  • Conclusion
• 10. Mitigating Denial-of-Service Attacks
  • Strategies for Attack and Defense
    • Attackers Strategy
    • Defenders Strategy
  • Designing for Defense
    • Defendable Architecture
    • Defendable Services
  • Mitigating Attacks
    • Monitoring and Alerting
    • Graceful Degradation
    • A DoS Mitigation System
    • Strategic Response
  • Dealing with Self-Inflicted Attacks
    • User Behavior
    • Client Retry Behavior
  • Conclusion
• III. Implementing Systems
• 11. Case Study: Designing, Implementing, and Maintaining a Publicly Trusted CA
  • Background on Publicly Trusted Certificate Authorities
  • Why Did We Need a Publicly Trusted CA?
  • The Build or Buy Decision
  • Design, Implementation, and Maintenance Considerations
    • Programming Language Choice
    • Complexity Versus Understandability
    • Securing Third-Party and Open Source Components
    • Testing
    • Resiliency for the CA Key Material
    • Data Validation
  • Conclusion
• 12. Writing Code
  • Frameworks to Enforce Security and Reliability
    • Benefits of Using Frameworks
    • Example: Framework for RPC Backends
      • Example code snippets
  • Common Security Vulnerabilities
    • SQL Injection Vulnerabilities: TrustedSqlString
    • Preventing XSS: SafeHtml
  • Lessons for Evaluating and Building Frameworks
    • Simple, Safe, Reliable Libraries for Common Tasks
    • Rollout Strategy
      • Incremental rollout
      • Legacy conversions
  • Simplicity Leads to Secure and Reliable Code
    • Avoid Multilevel Nesting
    • Eliminate YAGNI Smells
    • Repay Technical Debt
    • Refactoring
  • Security and Reliability by Default
    • Choose the Right Tools
      • Use memory-safe languages
      • Use strong typing and static type checking
    • Use Strong Types
    • Sanitize Your Code
      • C++: Valgrind or Google Sanitizers
      • Go: Race Detector
  • Conclusion
• 13. Testing Code
  • Unit Testing
    • Writing Effective Unit Tests
    • When to Write Unit Tests
    • How Unit Testing Affects Code
  • Integration Testing
    • Writing Effective Integration Tests
  • Dynamic Program Analysis
  • Fuzz Testing
    • How Fuzz Engines Work
    • Writing Effective Fuzz Drivers
    • An Example Fuzzer
    • Continuous Fuzzing
      • Example: ClusterFuzz and OSSFuzz
  • Static Program Analysis
    • Automated Code Inspection Tools
    • Integration of Static Analysis in the Developer Workflow
    • Abstract Interpretation
    • Formal Methods
  • Conclusion
• 14. Deploying Code
  • Concepts and Terminology
  • Threat Model
  • Best Practices
    • Require Code Reviews
    • Rely on Automation
    • Verify Artifacts, Not Just People
    • Treat Configuration as Code
  • Securing Against the Threat Model
  • Advanced Mitigation Strategies
    • Binary Provenance
      • What to put in binary provenance
    • Provenance-Based Deployment Policies
      • Implementing policy decisions
    • Verifiable Builds
      • Verifiable build architectures
      • Implementing verifiable builds
        • Untrusted inputs
        • Unauthenticated inputs
    • Deployment Choke Points
    • Post-Deployment Verification
  • Practical Advice
    • Take It One Step at a Time
    • Provide Actionable Error Messages
    • Ensure Unambiguous Provenance
    • Create Unambiguous Policies
    • Include a Deployment Breakglass
  • Securing Against the Threat Model, Revisited
  • Conclusion
• 15. Investigating Systems
  • From Debugging to Investigation
    • Example: Temporary Files
    • Debugging Techniques
      • Distinguish horses from zebras
      • Set aside time for debugging and investigations
      • Record your observations and expectations
      • Know whats normal for your system
      • Reproduce the bug
      • Isolate the problem
      • Be mindful of correlation versus causation
      • Test your hypotheses with actual data
      • Reread the docs
      • Practice!
    • What to Do When Youre Stuck
      • Improve observability
      • Take a break
      • Clean up code
      • Delete it!
      • Stop when things start to go wrong
      • Improve access and authorization controls, even for nonsensitive systems
    • Collaborative Debugging: A Way to Teach
    • How Security Investigations and Debugging Differ
  • Collect Appropriate and Useful Logs
    • Design Your Logging to Be Immutable
    • Take Privacy into Consideration
    • Determine Which Security Logs to Retain
      • Operating system logs
      • Host agents
      • Application logs
      • Cloud logs
      • Network-based logging and detection
    • Budget for Logging
  • Robust, Secure Debugging Access
    • Reliability
    • Security
  • Conclusion
• IV. Maintaining Systems
• 16. Disaster Planning
  • Defining Disaster
  • Dynamic Disaster Response Strategies
  • Disaster Risk Analysis
  • Setting Up an Incident Response Team
    • Identify Team Members and Roles
    • Establish a Team Charter
    • Establish Severity and Priority Models
    • Define Operating Parameters for Engaging the IR Team
    • Develop Response Plans
    • Create Detailed Playbooks
    • Ensure Access and Update Mechanisms Are in Place
  • Prestaging Systems and People Before an Incident
    • Configuring Systems
    • Training
    • Processes and Procedures
  • Testing Systems and Response Plans
    • Auditing Automated Systems
    • Conducting Nonintrusive Tabletops
    • Testing Response in Production Environments
      • Single system testing/fault injection
      • Human resource testing
      • Multicomponent testing
      • System-wide failures/failovers
    • Red Team Testing
    • Evaluating Responses
  • Google Examples
    • Test with Global Impact
    • DiRT Exercise Testing Emergency Access
    • Industry-Wide Vulnerabilities
  • Conclusion
• 17. Crisis Management
  • Is It a Crisis or Not?
    • Triaging the Incident
    • Compromises Versus Bugs
  • Taking Command of Your Incident
    • The First Step: Dont Panic!
    • Beginning Your Response
    • Establishing Your Incident Team
    • Operational Security
    • Trading Good OpSec for the Greater Good
    • The Investigative Process
      • Sharding the investigation
  • Keeping Control of the Incident
    • Parallelizing the Incident
    • Handovers
    • Morale
  • Communications
    • Misunderstandings
    • Hedging
    • Meetings
    • Keeping the Right People Informed with the Right Levels of Detail
  • Putting It All Together
    • Triage
    • Declaring an Incident
    • Communications and Operational Security
    • Beginning the Incident
    • Handover
    • Handing Back the Incident
    • Preparing Communications and Remediation
    • Closure
  • Conclusion
• 18. Recovery and Aftermath
  • Recovery Logistics
  • Recovery Timeline
  • Planning the Recovery
    • Scoping the Recovery
    • Recovery Considerations
      • How will your attacker respond to your recovery effort?
      • Is your recovery infrastructure or tooling compromised?
      • What variants of the attack exist?
      • Will your recovery reintroduce attack vectors?
      • What are your mitigation options?
    • Recovery Checklists
  • Initiating the Recovery
    • Isolating Assets (Quarantine)
    • System Rebuilds and Software Upgrades
    • Data Sanitization
    • Recovery Data
    • Credential and Secret Rotation
  • After the Recovery
    • Postmortems
  • Examples
    • Compromised Cloud Instances
    • Large-Scale Phishing Attack
    • Targeted Attack Requiring Complex Recovery
  • Conclusion
• V. Organization and Culture
• 19. Case Study: Chrome Security Team
  • Background and Team Evolution
  • Security Is a Team Responsibility
  • Help Users Safely Navigate the Web
  • Speed Matters
  • Design for Defense in Depth
  • Be Transparent and Engage the Community
  • Conclusion
• 20. Understanding Roles and Responsibilities
  • Who Is Responsible for Security and Reliability?
    • The Roles of Specialists
    • Understanding Security Expertise
    • Certifications and Academia
  • Integrating Security into the Organization
    • Embedding Security Specialists and Security Teams
    • Example: Embedding Security at Google
    • Special Teams: Blue and Red Teams
    • External Researchers
  • Conclusion
• 21. Building a Culture of Security and Reliability
  • Defining a Healthy Security and Reliability Culture
    • Culture of Security and Reliability by Default
    • Culture of Review
    • Culture of Awareness
    • Culture of Yes
    • Culture of Inevitably
    • Culture of Sustainability
  • Changing Culture Through Good Practice
    • Align Project Goals and Participant Incentives
    • Reduce Fear with Risk-Reduction Mechanisms
    • Make Safety Nets the Norm
    • Increase Productivity and Usability
    • Overcommunicate and Be Transparent
    • Build Empathy
  • Convincing Leadership
    • Understand the Decision-Making Process
    • Build a Case for Change
    • Pick Your Battles
    • Escalations and Problem Resolution
  • Conclusion
• Conclusion
• A. A Disaster Risk Assessment Matrix
• Index

pokaż cały spis treści

ukryj recenzje