40,81 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Protect your organization's security at all levels by introducing the latest strategies for securing DevOps
Key Features
- Integrate security at each layer of the DevOps pipeline
- Discover security practices to protect your cloud services by detecting fraud and intrusion
- Explore solutions to infrastructure security using DevOps principles
Book Description
DevOps has provided speed and quality benefits with continuous development and deployment methods, but it does not guarantee the security of an entire organization. Hands-On Security in DevOps shows you how to adopt DevOps techniques to continuously improve your organization's security at every level, rather than just focusing on protecting your infrastructure.
This guide combines DevOps and security to help you to protect cloud services, and teaches you how to use techniques to integrate security directly in your product. You will learn how to implement security at every layer, such as for the web application, cloud infrastructure, communication, and the delivery pipeline layers. With the help of practical examples, you'll explore the core security aspects, such as blocking attacks, fraud detection, cloud forensics, and incident response. In the concluding chapters, you will cover topics on extending DevOps security, such as risk assessment, threat modeling, and continuous security.
By the end of this book, you will be well-versed in implementing security in all layers of your organization and be confident in monitoring and blocking attacks throughout your cloud services.
What you will learn
- Understand DevSecOps culture and organization
- Learn security requirements, management, and metrics
- Secure your architecture design by looking at threat modeling, coding tools and practices
- Handle most common security issues and explore black and white-box testing tools and practices
- Work with security monitoring toolkits and online fraud detection rules
- Explore GDPR and PII handling case studies to understand the DevSecOps lifecycle
Who this book is for
Hands-On Security in DevOps is for system administrators, security consultants, and DevOps engineers who want to secure their entire organization. Basic understanding of Cloud computing, automation frameworks, and programming is necessary.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 391
Veröffentlichungsjahr: 2018
Ähnliche
Hands-On Security in DevOps
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Vijin BorichaAcquisition Editor:Heramb BhavsarContent Development Editor:Ronn KurienTechnical Editor:Aditya KhadyeCopy Editor:Safis EditingProject Coordinator:Kinjal BariProofreader: Safis EditingIndexer:Pratik ShirodkarGraphics:Tom ScariaProduction Coordinator: Shantanu Zagade
First published: July 2018
Production reference: 1270718
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78899-550-4
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Tony Hsu is a senior security architect with over 20 years of experience in security services technology. He has rich experience with Secure Software Development LifeCycle (SSDLC), is deeply involved with security activities such as security requirements planning, threat modeling, secure architecture and design review, secure code review, automated security testing, and cloud services security monitoring. He is also in-house SDL trainer.
He is also a co contributor on OWASP projects such as OWASP testing guide, proactive control guide, and deserialization security cheatsheet.
About the reviewer
Roshan Nagekar is an independent technology consultant with 10 years of experience in the field of DevOps and Site Reliability Engineering. He holds a master's degree in computer applications from Modern College, Pune. He has worked with companies such as Mphasis, IBM, Vuclip, and Western Union.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Hands-On Security in DevOps
Packt Upsell
Why subscribe?
PacktPub.com
Contributors
About the author
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the color images
Conventions used
Get in touch
Reviews
DevSecOps Drivers and Challenges
Security compliance
ISO 27001
ISO 27017 and ISO 27018
Cloud Security Alliance (CSA)
Federal Information Processing Standards (FIPS)
Center for Internet Security (CIS) and OpenSCAP – securing your infrastructure
National Checklist Program (NCP) repository
OpenSCAP tools
Legal and security compliance
New technology (third-party, cloud, containers, and virtualization)
Virtualization
Dockers
Infrastructure as Code (IaC)
Cloud services hacks/abuse
Case study – products on sale
What do hackers do?
Rapid release
Summary
Questions
Further reading
Security Goals and Metrics
Organization goal
Strategy and metrics
Policy and compliance
Education and guidance
Development goal/metrics
Threat assessment
Threat assessment for GDPR
Deliverables and development team self-assessment
Security requirements
QA goal/metrics
Design review
Implementation review
Third-party components
IDE-plugin code review
Static code review
Target code review
Security testing
Operation goal/metrics
Issue management
Environment Hardening
Secure configuration baseline
Constant monitoring mechanism
Operational enablement
Code signing for application deployment
Application communication ports matrix
Application configurations
Summary
Questions
Further reading
Security Assurance Program and Organization
Security assurance program
SDL (Security Development Lifecycle)
OWASP SAMM
Security guidelines and processes
Security growth with business
Stage 1 – basic security control 
Stage 2 – building a security testing team
Stage 3 – SDL activities
Stage 4 – self-build security services
Stage 5 – big data security analysis and automation
Role of a security team in an organization
Security office under a CTO
Dedicated security team
Case study – a matrix, functional, or taskforce structure
Security resource pool
Security technical committee (taskforce)
Summary
Questions
Further reading
Security Requirements and Compliance
Security requirements for the release gate
Release gate examples
Common Vulnerability Scoring System (CVSS)
Security requirements for web applications
OWASP Application Security Verification Standard (ASVS)
Security knowledge portal
Security requirements for big data
Big data security requirements
Big data technical security frameworks
Privacy requirements for GDPR
Privacy Impact Assessment (PIA)
Privacy data attributes
Example of a data flow assessment
GDPR security requirements for data processor and controller
Summary
Questions
Further reading
Case Study - Security Assurance Program
Security assurance program case study
Microsoft SDL and SAMM
Security training and awareness
Security culture
Web security frameworks
Baking security into DevOps
Summary
Questions
Further reading
Security Architecture and Design Principles
Security architecture design principles
Cloud service security architecture reference
Security framework
Java web security framework
Non-Java web security frameworks
Web readiness for privacy protection
Login protection
Cryptographic modules
Input validation and sanitization
Data masking
Data governance – Apache Ranger and Atlas
Third-party open source management
Summary
Questions
Further reading
Threat Modeling Practices and Secure Design
Threat modeling practices
Threat modeling with STRIDE
Diagram designer tool
Card games
Threat library references
Case study – formal documents or not?
Secure design
Summary
Questions
Further reading
Secure Coding Best Practices
Secure coding industry best practices
Establishing secure coding baselines
Secure coding awareness training
Tool evaluation
Tool optimization
High-risk module review
Manual code review tools
Secure code scanning tools
Secure compiling
Common issues in practice
Summary
Questions
Further reading
Case Study - Security and Privacy by Design
Case study background
Secure architecture review
Authentication
Authorization
Session management
Data input/output
Privacy by design
Summary of security and privacy frameworks 
Third-party component management
Summary
Questions
Further reading
Security-Testing Plan and Practices
Security-testing knowledge kit
Security-testing plan templates
Security-testing objective
Security-testing baseline
Security-testing environment
Testing strategy
High-risk modules
Recommended security-testing tools
Web security testing
Privacy
Security-testing domains
Thinking like a hacker
Exploits and CVE
Hacker techniques
Malware Information
Security-Training environment
Summary
Questions
Further reading
Whitebox Testing Tips
Whitebox review preparation
Viewing the whole project
High-risk module
Whitebox review checklist
Top common issues
Secure coding patterns and keywords
Case study – Java struts security review
Struts security review approaches
Struts security checklist
Struts security strings search in struts.xml and API
Summary
Questions
Further reading
Security Testing Toolkits
General security testing toolkits
Automation testing criteria
Behavior-driven security testing framework
Android security testing
Securing infrastructure configuration
Docker security scanning
Integrated security tools
Summary
Questions
Further reading
Security Automation with the CI Pipeline
Security in continuous integration
Security practices in development
IDE plugins to automate the code review
Static code analysis
Secure compiler configuration
Dependency check
Web testing in proactive/proxy mode
Web automation testing tips
Security automation in Jenkins
 Summary
Questions
Further reading
Incident Response
Security incident response process
Preparation
Detection and analysis
Containment and recovery
Post-incident activity
Security incident response platforms (SIRP)
SOC team
Incident forensics techniques
Summary
Questions
Further reading
Security Monitoring
Logging policy
Security monitoring framework
Source of information 
Threat intelligence toolset
Security scanning toolset
Malware behavior matching – YARA
Summary
Questions
Further reading
Security Assessment for New Releases
Security review policies for releases
Security checklist and tools
BDD security framework
Consolidated testing results
Summary
Questions
Further reading
Threat Inspection and Intelligence
Unknown threat detection
Indicators of compromises
Security analysis using big data frameworks
TheHive 
MISP – an Open Source Threat Intelligence Platform
Apache Metron
Summary
Questions
Further reading
Business Fraud and Service Abuses
Business fraud and abuses
Business risk detection framework
PCI DSS compliance
Summary
Questions
Further reading
GDPR Compliance Case Study
GDPR security requirement
Case studies
Case 1 – personal data discovery
Case 2 – database anonymization
Case 3 – cookie consent
Case 4 – data-masking library for implementation
Case 5 – evaluating website privacy status
Summary
Questions
Further reading
DevSecOps - Challenges, Tips, and FAQs
DevSecOps for security management 
DevSecOps for the development team 
DevSecOps for the testing team
DevSecOps for the operations team
Summary
Further reading
Assessments
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 12
Chapter 13
Chapter 14
Chapter 15
Chapter 16
Chapter 17
Chapter 18
Chapter 19
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
DevOps has provided speed and quality benefits with continuous development and deployment methods, but it does not guarantee the security of an entire organization. Hands-On Security in DevOps shows you how to adopt DevOps techniques to continuously improve your organization's security at every level, rather than just focusing on protecting your infrastructure.
This guide combines DevOps and security to help you to protect cloud services, and teaches you how to use techniques to integrate security directly in your product. You will learn how to implement security at every layer, such as for the web application, cloud infrastructure, communication, and the delivery pipeline layers. With the help of practical examples, you'll explore the core security aspects, such as blocking attacks, fraud detection, cloud forensics, and incident response. In the concluding chapters, you will cover topics on extending DevOps security, such as risk assessment, threat modeling, and continuous security.
By the end of this book, you will be well-versed in implementing security in all layers of your organization and be confident in monitoring and blocking attacks throughout your cloud services.
Who this book is for
This book is for system administrators, security consultants, and DevOps engineers who want to secure their entire organization. Basic understanding of Cloud computing, automation frameworks, and programming is necessary.
What this book covers
Chapter 1, DevSecOps Drivers and Challenges, we will cover external factors that drive the need for security such as security compliance, regulations, and the market.
Chapter 2, Security Goals and Metrics, we will discuss security practices from different perspectives based on the OWASP SAMM framework. We will also cover security activities in different roles such as security management, development, QA, and operation teams.
Chapter 3, Security Assurance Program and Organization, will cover how different organization structures may relate to the execution of a security assurance program. The role, responsibility and relationship of the security team in the organization structure also impact the success execution of a security assurance program. We will discuss these factors by case study.
Chapter 4, Security Requirements and Compliance, will cover security requirements covering four aspects: the security requirements for each release quality gate, the security requirements for general web applications, the security requirements for big data, and the security requirements for compliance with General Data Protection Regulation (GDPR).
Chapter 5, Case Study - Security Assurance Program, we will cover two case studies looking at the security assurance program and security practices in the DevOps process. Microsoft SDL and SAMM were introduced to apply to the security assurance program. In addition to the process, the non-technical parts, security training, and culture are also critical to the success of the security program. We will also give an example of how security tools and web security framework can help during the whole DevOps process
Chapter 6, Security Architecture and Design Principles, will cover security architecture and design principles. For security architects and developers, building software on a mature security framework will greatly reduce not only security risks with industry best practices but also implementation efforts. Therefore, this chapter introduces the key security elements of a cloud service architecture and some mature security frameworks, which can be applied based on the scenario
Chapter 7, Threat Modeling Practices and Secure Design, we will cover the importance of the whole team's involvement with threat modeling practices and the STRIDE examples (spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege).
Chapter 8, Secure Coding Best Practices, we will cover secure coding industry best practices, such as CERT, CWE, Android secure coding, OWASP Code Review, and the Apple secure coding guide. Based on those secure coding rules, we will establish secure coding baselines as part of the security policy and release criteria.
Chapter 9, Case Study - Security and Privacy by Design, we will examine a case study to discuss the implementation of security by design and privacy by design. The case study will show us the common challenges a DevOps team may have to face when applying security practices, and how the security team may help to provide best practices, tools, a security framework, and a training kit.
Chapter 10, Security-Testing Plan and Practices, will give an overview of a security-testing plan, security-testing domains, and the minimum set of security-testing scope. We will discuss a security testing plan, testing approaches, risk analysis, security domains, and industry practices, to build your security-testing knowledge base. In addition, we will introduce some industry best practices, testing approaches, and security tools, for security testing.
Chapter 11, Whitebox Testing Tips, will focus on whitebox testing tips. Whitebox code review can be most effective to identify certain specific security issues, such as XXE, deserialization, and SQL injection. However, a whitebox review can be time-consuming if there are no proper tools or strategies. To have an effective whitebox test, we need to focus on specific coding patterns and high-risk modules. This chapter will give tips, tools, and key coding patterns to identify high-risk security issues.
Chapter 12, Security Testing Toolkits, we will cover common (but not a comprehensive) set of security testing tools. The major elements of a network that involve security testing include web and mobile connections, configuration, communication, third-party components, and sensitive information. We will look at the testing tips and tools for each element. Furthermore, we will also learn how these tools can be executed both automatically and as tools that are built into continuous integration.
Chapter 13, Security Automation with the CI Pipeline, will focus on security practices in the development phases, as well as how to integrate tools such as Jenkins into continuous integration. In the development phases, we explored the techniques of using IDE plugins to secure code scanning, and suggested some static code analysis tools. For the build and package delivery, secure compiler configurations and dependency vulnerability checks will also be introduced. Finally, web security automation testing approaches and tips will also be discussed in this chapter.
Chapter 14, Incident Response, will cover incident responses for a security operation team. We will mainly discuss the key activities in the key phases of the incident response process: preparation, containment, detection, and post-incident analysis. The field of incident response includes how to handle public CVE vulnerability, how to respond to white hat or security attacks, how we evaluate each security issue, the feedback loop to the development team, and the tools or practices we may apply in incident response.
Chapter 15, Security Monitoring, will cover some security monitoring techniques. The objective of this chapter is to prepare our security monitoring mechanism to protect and prevent our cloud services from being attacked. To be prepared for this, our security monitoring procedures should include logging, monitoring the framework, threat intelligence, and security scanning for malicious programs.
Chapter 16, Security Assessment for New Releases, we will cover security assessment for new releases in this chapter. Cloud services may have frequent releases and updates. It's a challenge for the development, operations, and security teams to release their work within a short time frame and to finish the minimum required security testing before releases. In this chapter, we will look at the security review policies and the suggested checklist and testing tools for every release. For testing integration, the BDD security framework and other integrated security testing framework will also be introduced in this chapter.
Chapter 17, Threat Inspection and Intelligence, will cover threat inspection and intelligence. This chapter focuses on how to identify and prevent known and unknown security threats, such as backdoors and injection attacks, using various kinds of log correlation. We will introduce the logs that are needed, how those logs are connected, and the potential symptoms of attacks. Some open source threat detection will be introduced. Finally, we will introduce how to build your own in-house threat intelligence system.
Chapter 18, Business Fraud and Service Abuses, will cover business fraud and service abuses. Cloud services introduce new types of security risks, such as transaction fraud, account abuses, and promotion code abuses. This online fraud and abuse may result in financial losses or gains, depending on which side of the fence you sit. It will also provide guidelines and rules on how to detect these kinds of behaviors. We will discuss typical technical frameworks and technical approaches needed to build a service abuse prevention or online fraud detection system.
Chapter 19, GDPR Compliance Case Study, will cover GDPR compliance as a case study to apply to software development. It discusses the GDPR software security requirements it should include in coming releases. We will also explore some practical case studies, such as personal data discovery, data anonymization, cookie consent, data-masking implementation, and web privacy status.
Chapter 20, DevSecOps - Challenges, Tips, and FAQs, will cover some hands-on tips, challenges, and FAQs based on a functional roles perspective.
To get the most out of this book
Refer to the OWASP security projects, NIST, CSA, GDPR for updated security best practices. Try to install and apply the open source tools mentioned in the books.
Apply one security tool or practice at a time into the DevOps process.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/HandsOnSecurityinDevOps_ColorImages.
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Being able to establish the application resource (TimeSheet.xls) in a security relationship is a unique authorization model in OACC."
Bold: Indicates a new term, an important word, or words that you see onscreen.
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
DevSecOps Drivers and Challenges
Due to the rapid release of cloud services, law enforcement, security incidents, and tenants' data protection, the security is indispensable to cloud/internet services. Moving security activities from right to left during the development lifecycle and having built-in security practices in the continuous integration pipeline are the goals of DevSecOps.
The business environment, culture, law compliance, and external market drive relate to how the DevSecOps security assurance program rolls out in an organization. The DevSecOps or security assurance program management involved with the whole organization across all business units and the key success to DevSecOps will require all stakeholders to agree with the goal and approaches.
We will cover the following topics in this chapter:
Security compliance (ISO 2700x, FIPS, CSA-CCM)
Legal/law compliance—
General Data Protection Regulation
(
GDPR
)
New technology (third-party, cloud, containers, and virtualization)
Cloud service hacks/abuse
Rapid release
As shown in the following diagram, this is how external drivers and challenges impact on a team when delivering secure cloud services:
Security compliance
For cloud services, it's very important to have security compliance-ready. Security compliance not only shows how the security controls of the cloud service meet security standards but also demonstrates security trustworthiness for customers and partners. Security compliance provides an overview of a security assurance program, but it won't specifically tell us which security technical approach it should apply. For frequent cloud service releases, constantly monitoring and auditing to meet security compliance can be a big challenge.
Although most cloud service providers are security compliance ready (ISO, PCI, FedRAMP, SOC, and so on), it's still the cloud service customer's responsibility to secure data and manage their own application compliance assessment. Both cloud service customers and providers need to maintain system or application audit logs, configuration lists, and change histories for compliance assessment. The compliance assessment should be considered a continuous activity—not a one-time audit check.
In this chapter, we will introduce key cloud services security compliance as a reference to building a security assurance program, and how these security compliance standards relate to DevSecOps.
ISO 27001
ISO 27001 is an information security management system (ISMS). It provides an overview of organization-level security assurance programs. ISO 27001 won't specify a technical security approach, but it provides a complete set of a security management programs. As the diagram shows, the segments in the upper parts may be more directly related to DevOps security practices, such as compliance, business continuity, operation security, access control, software development, cryptography, incident management, and communication. This will serve as a guideline to further developing our own DevOps security program:
We won't introduce ISO 27001 details, but the following table summarizes how ISO 27001 relates to each role and the DevOps team:
Role
Company/organization security policy
Operation or DevOps team
Development team
ISO 27001 chapters
5 Information security policies
6 Organization of information security
7 Human resource security
8 Assess management
15 Supplier relationships
11 Physical and environmental security
9 Access Control
10 Cryptography
12 Operation security
13 Communication security
17 Information security aspects of business continuity management
16 Information security incident management
18 Compliance; with internal requirements, such as policies, and external requirements, such as laws
19 Cloud services control
14 System development
10 Cryptography
9 Access control
ISO 27017 and ISO 27018
ISO 27018 is mainly for the protection of personally identifiable information (PII) in the cloud. It's an extended security compliance based on ISO 27001 and ISO 27002. On top of ISO 27001/27002, ISO 27018 additionally defines PII protection security requirements
ISO 27017 provides both service providers and cloud service consumers with the ability to implement security controls for cloud services. ISO 27017 is an extension to ISO 27002 to address cloud-specific security issues.
Cloud Security Alliance (CSA)
As there are many cloud security compliance methods out there, we may get frustrated trying to follow each of them. The CSA (Cloud Security Alliance) Cloud Controls Matrix (CCM) consolidated most security compliance methods into one matrix called CCM. Take application and interface application security as an example—CCM includes all security compliance controls such as ISO, FedRAMP, and NIST 800-53 related to this area, and defines the control ID. The key benefit of referring to CCM is that we can simply focus on CCM and know all other security compliance regulations will be met as well.
In addition, CSA provides a Consensus Assessments Initiative Questionnaire (CAIQ). It's a yes/no questionnaire for cloud consumers or cloud provides to do security self-assessment and to understand the requirements of security controls. Google Vendor Security Assessment Questionnaires (VSAQ) also provide a security assessment questionnaire in terms of Web Application Security, Security and Privacy Program, Infrastructure Security and Physical and Datacenter Security.
Furthermore, if you are looking for the top cloud threats and security control mitigations, Cloud Security Alliance (CSA) cloud top threats provide guidelines. At the time of writing, it defines the top 12 cloud threats, mappings to threat analysis, CCM/Control ID, and the domains of CSA Security Guidance reference. The following table shows related CSA security guides and how to apply security practices in your organization:
CSA security guides
What it is?
When to apply?
CSA Security Guidance reference
Cloud security white paper
If your organization needs a cloud service security guideline or white paper, this can be a good reference.
Cloud top threats
Top 12 cloud threats and mappings to threat analysis, CCM/Control ID, and domains of CSA Security Guidance reference
It can be the basis for cloud threat modeling.
CAIQ
Yes/no questionnaire
A list of yes/no questions for self-assessment to understand existing security control requirements.
CSA CCM
One consolidated worldwide security standard mapping
It's a great consolidated reference and includes most security compliance standards (ISO 27001, PCI, NIST, and so on). It's the only matrix you need to review security standards compliance.
Federal Information Processing Standards (FIPS)
The FIPS mainly defines minimum security requirements for the use of cryptographic modules. Every organization that is not going to get a FIPS certificate should also refer to it. It's highly recommended that you refer to Security Requirements for Cryptographic Modules to understand what cryptographic modules may be considered safe, legacy, or weak.
For developers who would like to learn how to implement cryptographic modules correctly, the following resources are recommended.
OWASP Cryptographic Storage Cheat Sheet.
OWASP Guide to Cryptography
OWASP Key Management Cheat Sheet
Here is a summary of the minimum security requirements for each cryptography algorithm and its usage:
Usage scenario
Unsafe cryptography algorithm
(key length)
Legacy Systems Only
Recommended cryptography algorithm
Symmetric encryption
Blowfish, DES, Skipjack, RC4
3 DES only when
(key 1 != key 2 != key 3)
AES > 128 bits
Asymmetric encryption
RSA (< 1024 bits)
RSA (1024 bits)
RSA (> 1024 bits)
Hash
MD5
SHA1 (1024 bits)
SHA256
Digital signature
RSA (< 1024 bits)
DSA (< 1024 bits)
ECDSA (<= 160 bits)
DSA (1024 bits)
RSA (1024 bits)
RSA (>=2048 bits)
DSA (>=2048 bits)
ECDSA (>=256 bits)
Hellman key exchange (DH)
DH ( < 1024 bits)
DH (1024-2047 bits)
DH (>=2048 bits)
ECDH(>-256 bits)
Center for Internet Security (CIS) and OpenSCAP – securing your infrastructure
The CIS defines security benchmarks and the National Checklist Program (NCP), defined by the NIST SP 800-70, provides guidance on the security configurations of the operating system, database, virtualization, framework, and applications.
The IT and operation team are primarily responsible for ensuring the security of the infrastructure. However, the development team may also share some responsibilities for securing the infrastructure. For example, the development team may decide to deliver the application package in the form of a container or to apply Infrastructure as Code frameworks, such as Puppet or Chef. These technologies allow development teams to define a secure configuration, even in the development stage, and the operation team just needs to apply the secure configuration definition during application deployment.
In addition, it's also the development team's job to provide a list of configuration changes for every release's deployment. This will allow the operation team to review if the configuration changes are secure and appropriate. Due to the complexity and the amount of configuration that needs to be reviewed, the adoption of scanning tools to check if all the configurations are secure and comply with industry best practices is necessary. Cloud service providers may provide such scanning services or tools. Here, we recommend open source tools such as CIS-CAT Lite provided by CIS and OpenSCAP.
The journey to secure the infrastructure and platform can be completed in three stages. The first stage is to define a secure configuration baseline by referring to industry practices such as CIS or NIST NCP. Then, we may apply tools such as Chef or Puppet to ensure every deployment includes a secure configuration as well. The final stage is to do constant monitoring of frequent configuration changes and security compliance assessment.
Typical infrastructure components are listed in the following table. CIS provides secure configuration suggestions to each system component and also tools to do the scanning against the security best practice baseline.
CIS provides the CIS Benchmark, which defines the secure configuration of operating systems, server software, cloud services, networking devices, and so on. It helps operation teams to understand how to secure and configure an infrastructure and platform.
Infrastructure layers
System
Web services
Apache, Nginx, IIS
Database
MS SQL, MySQL, Oracle, MongoDB
Virtualization/container
VMware, Docker, Kubernetes
Networking
Cisco devices
Operating systems
Windows, Linux, Ubuntu, CentOS, SUSE
In addition to CIS Benchmark documents, CIS also provides tools to infrastructure or operation teams for secure configuration scanning. The CIS Security website provides related security configuration scanning tools to download.
National Checklist Program (NCP) repository
The NCP repository provides secure configuration for specific software components. For example, if you are looking for Apache security configuration or the CIS of Apache, you may use the NCP to do the search. The screenshot is from the NIST NCP (National Checklist Program).
OpenSCAP tools
OpenSCAP is similar to CIS security benchmarks; it also provides a secure configuration baseline. In addition, OpenSCAP also provides different kinds of tool for operation or infrastructure teams to do secure configuration evaluation and scanning. Depending on the requirements, there are four kinds of tool provided, as shown in the following screenshot:
Legal and security compliance
The EU GDPR, which came into force in May 2018, protects all EU citizens from privacy and data breaches. According to the GDPR FAQ:
In other words, if a company is providing services to customers in the European Union, its data handling will need to comply entirely with GDPR. From a DevSecOps point of view, it's related to data collection, handling, storage, backup, modification, transport, and removal—in a secure manner. According to GDPR Article 5, there are six privacy principles:
Lawfulness, fairness, and transparency
Purpose limitations
Data minimization
Accuracy
Storage limitations
Integrity and confidentiality
GDPR, like other security compliance policies, doesn't define the technical approach to achieve it. GDPR can still be too high-level for an engineering team. It needs to translate into software security requirements, design, threat modeling, tools, and so on. The following table summarizes typical security practices for the engineering team:
Stage
Common security practices for privacy or sensitive info handing
Design
Privacy Impact Assessment (PIA)
Coding
Data masking library
Anonymous toolbox
RAPPOR—privacy-preserving reporting algorithms
Encryption storage (RSA, ASE)
Secure erasure
Secure communication protocol (such as
TLS v1.2,
SSH v2, SFTP, SNMP v3)
Cookie consent
Data Vault
Key management
Testing
OWASP testing for weak cryptography, testing for error handling, testing for configuration, and so on
Deployment
OWASP configuration and deployment management testing
CIS secure environment configuration
Sensitive information in Git
Monitoring
ELK for log analysis
Integrity monitoring (IDS/IPS) to monitor any unauthorized changes
CIS secure configuration monitoring
Sensitive information leakage in Git
New technology (third-party, cloud, containers, and virtualization)
New technologies such as virtualization, Docker, and microservices introduce new methods of software delivery and speeds up application deployment, but also brings new security threats and risks. We will briefly discuss how these new technologies change the practices of security and DevOps.
Virtualization
It's very common to install application services on top of a virtualized OS. Virtualization technology helps to make the most physical machine resources such as the CPU, memory, and disks. However, virtualization is a shared OS technology. It also introduces security risks such as VM escape, information leakage, and denial-of-service for applications running on top of virtualization.
Security practices in guest OS virtualization are normally involved with both OS and virtualization hardening. Here are some key security configurations related to virtualization. Refer to CIS Benchmarks for details:
Limit
informative messages
from the VM to the VMX file
Limit sharing console connections
Disconnect unauthorized devices (USB, DVD, serial devices, and so on)
Disable
BIOS Boot Specification
(
BBS
)
Disable guest-host interaction protocol handler
Disable host guest filesystem server
Disable VM console paste operations
Disable virtual disk shrinking
Do not send host information to guests
The following diagram shows the adoption of virtualization. Virtualization adds a hypervisor layer on top of the physical server so that the virtualized guest OS can run on top of it:
In addition to the secure configuration of virtualization, applying a security patch to virtualization is also a must for operation or IT teams.
In addition, the following resources may help you to search for Common Vulnerabilities and Exposures (CVE) in vulnerability databases:
Exploit Database
https://www.exploit-db.com/
SecLists
http://seclists.org/fulldisclosure/
Vulnerability Notes Database
https://www.kb.cert.org/vuls/
To search for the vulnerabilities of a specific product or vendor, refer to the URL search for VMware as following:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=VMware
https://www.cvedetails.com/vendor/
252/
Vmware.html
Dockers
The introduction of Docker provides software package delivery and installation with new choices and can be one of the best ways to isolate different applications without using a whole separate OS virtual machine. Software can be packaged into a container by Docker. A container, like a VM image, includes everything needed to run application services such as runtime, system libraries, and settings. The key difference between a virtual machine image and a container is that the container doesn't actually include the whole OS. The container only includes key necessary system libraries and every container shares the same OS kernel during runtime. Therefore, Docker containers can boot up within seconds and use much less memory or far fewer disks than virtualization images.
The use of Docker can also greatly help operation teams to do deployment and secure configuration since a Docker container includes every configuration and the settings you need to run. To understand Docker security practices, check out the CIS Docker Benchmark and Docker security in the Further reading section.
Key secure practices and configurations of Docker are listed here:
Separate partition for containers
Updated Linux kernel
Only allow trusted users to control the Docker daemon
Audit the Docker daemon, files, and directories
Restrict network traffic between containers
TLS authentication for the Docker daemon
Do not bind Docker to another IP/port or a Unix socket
Docker daemon configuration files permissions
Container runtime (Linux Kernel capabilities, SSH, ports, memory, CPU, IPC)
The following diagram shows the key difference between virtualization and Docker. Virtualization is a guest OS level while Docker is actually an application-level isolation and shares the same guest OS:
Here is a summary of the known security vulnerabilities identified in Docker.
CVE ID
Related CWE ID
Description
CVE-2014-5282
20
Docker before 1.3 does not properly validate image IDs, which allows remote attackers to redirect to another image through the loading of untrusted images via Docker load.
CVE-2017-14992
20
Lack of content verification in Docker-CE (also known as Moby), and earlier allows a remote attacker to launch a Denial of Service attack via a crafted image layer payload; a.k.a Gzip bombing.
CVE-2017-7297
264
Rancher Labs rancher server 1.2.0+ is vulnerable to authenticated users disabling access control via an API call. This is fixed in versions rancher/server:v1.2.4, rancher/server:v1.3.5, rancher/server:v1.4.3, and rancher/server:v1.5.3.
CVE-2016-9962
362
RunC allowed additional container processes via runc exec to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container.
CVE-2014-0047
n/a
Docker before 1.5 allows local users to have an unspecified impact via vectors involving unsafe /tmp usage.
Here is a tip to query a specific vulnerability. Take 'CVE-2014-0047' as an example; just replace the CVE ID number at the end of the following URL.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0047
https://nvd.nist.gov/vuln/detail/CVE-2014-0047
Infrastructure as Code (IaC)
Puppet, Chef, Ansible, and SaltStack are tools to apply IaC. The key advantage of using these tools is that any system configuration can be defined in a text file at the design stage and changes can be managed by versions. This will help both operation or development teams to build security configuration baselines such as file permissions, firewall rules, web configurations, or MySQL connections. Once the security configuration baseline is defined, the operation team can monitor any unauthorized changes or roll back the configuration to previous specific versions.
For example, we may have baseline security firewall rules for a web services environment to only allow ports 80 and 443. All an operation team needs to do is to define the firewall rules by using one of the tools (Puppet, Chef, Ansible, SaltStack), and the framework will apply the rules, audit, and even correct changes if other ports are opened by mistake or by other service deployments.
The DevSec Hardening Framework project available at https://github.com/dev-sec provides Ansible, Chef, and Puppet secure configuration baseline template scripts.
The following diagram shows how IaC (for example, Puppet) works:
Cloud services hacks/abuse
A CSA survey on the top cloud security concerns has identified the following 12 issues:
Data breaches
Weak identity, credentials, and access management
Insecure APIs
System and application vulnerabilities
Account hijacking
Malicious insiders
Advanced Persistent Threats
(
APTs
)
Data loss
Insufficient due diligence
Abuse and nefarious use of cloud services
Denial of service
Shared technology issues
In addition, service abuse has also become a headache for most e-commerce or shopping sites. Let's take one example to understand how hackers or misconduct users can benefit from it.
Case study – products on sale
Assume that one online shopping store is going to have a 50% discount on one new model phone for only the first 100 customers; it will be available at 12:00 on February 1.
What do hackers do?
For this kind of sale with 50 % profit is a great attraction for malicious users to do something. What underground users typically may do involves the massive registration of user accounts. There can be more than 10,000 users accounts registered in a short period of time just before the sales. At the moment of the sale, they will use automated scripts to trigger purchase behaviors and finish the orders within seconds. Once they have ordered or occupied all the phones, they may either sell them at higher prices or even not pay for the orders.
Is this illegal? These behaviors follow the business rules for registration and purchases. Although the behavior may not be against the law, it may be considered misconduct or service abuse. Therefore, this kind of on-sale activity may require additional business rules and regulations. After all, it's not purely hacking behavior. We will discuss this in later chapters. Here, we provide an overview of alleviating measures, which can be by means of business rules or technical approaches:
The sale is only limited to those customers with a certain period of purchase history
Apply CAPTCHA to distinguish humans from machines
Two-factor authentication and registration via phone SMS
Detection and correlation of IP, phone number, email, account ID, physical address, and GeoIP location
Unusual page browsing behavior such as skipping products and jumping to the purchase directly
Unusual massive logins or registration from the same IP or devices
Rapid release
Rapid, frequent, and iterative releases are very common for cloud services. This normally drives the need for DevOps practices. This can be both an opportunity and a challenge to security. The challenge is that a short period of frequent releases may not include enough time to do a full cycle of security testing. There are three maturity levels of DevOps practices:
Maturity level
Achieved
Technology adoption
Continuous integration
Source code repository and version control
CI workflow with a daily build and unit testing
Jenkins
Git
Unit testing
Continuous delivery
Automated deploy to the staging environment
Integration testing on the staging environment
Deployment to production is done manually
IaC(Puppet)
Docker
Continuous deployment
Automated deployment and acceptance testing on production
Production changes or configuration management
IaC (puppet)
Docker
Automated acceptance testing
Configuration monitoring
The adoption of DevOps practices means more collaboration between development, QA, IT, and operation teams, and more in-progress adoption of continuous integration or continuous delivery tools. This provides a good foundation to move to DevSecOps. Depending on the maturity level of the existing CI/CD, security practices or tools can be added on top of the existing CI/CD framework. It's the most effective and least learning curve to introduce security is don't change existing development, QA, IT, operation team the way they work. Building security tools around the existing CI/CD is still the best approach. We will explore this more in upcoming chapters.
The diagram below shows the security involved with development, QA, and operations through the whole CI/CD lifecycle.
Summary
In this chapter, we discussed external factors that drive the need for security such as security compliance, regulations, and the market. In addition, the adoption of new technologies also brings about new challenges such as Docker, virtualization, cloud services, and IaC.
