Open Reference Architecture for Security and Privacy

Warning

This document is a living document! Collaboration is fun, so help us by contributing (See section contributing)! Join the ROI movement!

Note

A stable version of this publication (2019 edition!) is also available as hard-copy, see here. Support this work and buy a hardcopy! The latest version of this Open Referene Architecture is always available online at https://security-and-privacy-reference-architecture.readthedocs.io

This reference architecture contains open reusable information to empower you to solve or mitigate security or privacy risks. This reference architecture is created to ease the process to create security and privacy solutions. It is time to stop reinventing the wheel when it comes down to creating security and privacy solutions. Build your specific solution on proven solutions. Making use of existing solutions is a far better investment in time and quality.

The reference architecture is not just another security book. Since libraries and book stores are filled with decent books on security and privacy this book is all about using and reusing existing security and privacy solutions to simplify the process to solve your urgent use case.

(c) 2015-2020 Maikel Mardjan and Asim Jahan.

Published by the Business Management Support Foundation, The Netherlands.

All trademarks, trade names, product names and logos appearing in this report are the property of their respective owners.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Use of these materials is permitted only in accordance with license rights granted. Materials provided “AS IS”; no representations or warranties provided. User assumes all responsibility for use, and all liability related thereto, and must independently review all materials for accuracy and efficacy.

Content

• Foreword
• Introduction
  • Why another reference architecture
  • Why security and privacy
  • Advantage of using this reference architecture
  • Who should use this reference architecture
  • Scope of this reference architecture
  • What about security patterns?
  • How this reference architecture is structured
• Creating a Solution
  • The steps
• Generic Security & Privacy Architectures
  • Security Reference Architecture
  • Privacy Reference Architecture
• Security and Privacy models
  • Introduction
  • Common attack vectors
  • HTTPS Interception
  • Hosting, hardware, firmware and other invisible threats
  • Security Personas
  • Threat Models
  • Security Models
  • Privacy Models
• Security and Privacy Principles
  • What are principles?
  • Principles or requirements?
  • What are requirements?
  • Reuse requirements
• Security Principles
  • Address Privacy & Security
  • Always consider the users
  • Asset protection and resilience
  • Assume that external systems are insecure
  • Audit information provision to consumers
  • Authenticate users and processes
  • Authorize after you authenticate
  • Avoid security by obscurity
  • Check the return value of functions
  • Clearly delineate the physical and logical security boundaries
  • Compartmentalise
  • Compile with all warnings enabled
  • Complete mediation
  • Computer security is constrained by societal factors
  • Computer Security Requires a Comprehensive and Integrated Approach
  • Computer Security Responsibilities and Accountability Should Be Made Explicit
  • Computer Security Should Be Cost-Effective
  • Computer Security should be periodically reassessed
  • Computer Security Supports the Mission of the Organization
  • Data in transit protection
  • Data is always protected
  • Declare data objects at the smallest possible level of scope
  • Defense in depth
  • Design and implement audit mechanisms
  • Design and operate an IT system to limit damage and to be resilient in response.
  • Design for secure updates
  • Design for security properties changing over time
  • Design reviews
  • Design security to allow for regular adoption of new technology
  • Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability
  • Do not implement unnecessary security mechanisms.
  • Don’t trust infrastructure
  • Don’t trust services (from others)
  • Earn or give, but never assume or trust
  • Economy of mechanism
  • Ensure proper security in the shutdown or disposal of a system
  • Ensure that developers are trained in how to develop secure software.
  • Establish a sound security policy as the“foundation” for design.
  • Establish secure defaults
  • External interface protection
  • Fail Safe Defaults
  • Fail-safe default settings for security and access
  • Formulate security measures to address multiple overlapping information domains
  • Governance framework
  • HTTP header use
  • Identify and prevent common errors and vulnerabilities
  • Identify potential trade-offs
  • Identity and authentication
  • Implement layered security (Ensure no single point of vulnerability).
  • Implement least privilege
  • Implement tailored system security measures to meet organizational security goals.
  • Isolate public access systems from mission critical resources
  • Least common mechanism
  • Least privilege
  • Limit the use of pointers
  • Limit the use of the preprocessor to file inclusion and simple macros
  • Logging secrets
  • Minimize secrets
  • Minimize the system elements to be trusted.
  • Open design
  • Operational security
  • Personnel security
  • Protect information while being processed, in transit, and in storage.
  • Provide assurance that the system is, and continues to be, resilient in the face of expected threats.
  • Psychological acceptability
  • Reduce risk to an acceptable level.
  • Risk Based Approach to Security
  • Secure use of the service by the consumer
  • Security by Design
  • Sensitive Data
  • Sensitive data must be identified
  • Separation between consumers
  • Separation of privilege
  • Session lifetime
  • Strive for operational ease of use.
  • Strive for simplicity
  • Supply chain security
  • Systems Owners Have Security Responsibilities Outside Their Own Organizations
  • Treat security as an integral part of the overall system design.
  • Use an authentication mechanism that cannot be bypassed
  • Use only Secure Protocols
  • Use standard solutions
  • Use unique identities to ensure accountability
  • Where possible, base security on open standards for portability and interoperability.
  • Zero trust architecture design principles
• Privacy Principles
  • EU GDPR privacy principles
  • Other privacy principles
  • Access to Personal data
  • Data anomyzation
  • Collection Limitation Principle
  • Collection of personal data
  • Defensive data collection
  • Design reviews
  • Disclosure to third parties
  • Don’t trust infrastructure
  • Don’t trust services (from others)
  • Individual Participation Principle
  • Management Responsibility
  • Monitoring and enforcement
  • Purpose Specification Principle
  • Security for privacy
  • Security Safeguards
  • Use Limitation Principle
• Security and Privacy designs
  • Handling privacy regulations
  • How do I apply privacy by design
  • How do I manage API security
  • How do I validate a password?
  • What are good privacy design patterns?
  • How to handle privacy when designing new protocol specifications?
  • How to build the Internet yourself?
  • When to use Blockchain?
• Using Open Source for security and privacy protection
  • Introduction
  • What is open Source Software (OSS)?
  • The power of open for security and privacy
  • Determining quality of OSS for security and privacy applications