First published in Great Britain in 2020
by Rethink Press (www.rethinkpress.com )
Copyright Glenn Wilson
All rights reserved. No part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written permission of the publisher.
The right of Glenn Wilson to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988.
This book is sold subject to the condition that it shall not, by way of trade or otherwise, be lent, resold, hired out, or otherwise circulated without the publishers prior consent in any form of binding or cover other than that in which it is published and without a similar condition including this condition being imposed on the subsequent purchaser.
Cover image Adobe Stock | Oleksandr
Contents
This book is dedicated to Caz, Abs and Emily
Foreword
I have observed the dramatic changes in the software development field through a security lens during the 2010s. The pace at which the business demands rapid releases of new features to capture and accelerate business growth has become the norm.
This explosion is obvious when you look at the extraordinary rise of the likes of Etsy, Amazon, Facebook, Netflix, Taobao and WeChat. Each platform caters for the growth and spike in traffic, and the constant releases of new capabilities and updates to their web and mobile interfaces.
This fast pace of multiple releases (per day in most cases) has led the industry to accept that a security breach is going to happen to any business and so organisations must be prepared to handle such scenarios. As a counter to this inevitable event, organisations are now driving their delivery teams even harder to not just deliver on time but to provide a quality that exceeds the standard of their competitors and this includes security. Reputation damage and staying out of the press due to a security breach is now a top agenda item for the executives. Security has finally become a first-class citizen.
Being in the right place at the right time (through my commercial engagements) has allowed me to experience the evolution first-hand. Watching how the software development practices rapidly adapt to the business needs through the creation of new vocabulary and technology, turning software engineering into a sexy field with more and more people aspiring to join, has been an exciting time in my career. During the same period the security industry has achieved different successes; for example, the role of a security representative Chief Information Security Officer (CISO) on the board of companies, the acceptance of different shades of penetration testing (red, blue, purple and bug bounties) as an important assurance stage, and the formation of different teams covering the various security domains and disciplines required to serve the business.
In this book Glenn highlights the core principles in modern software development and security. He draws upon both his experience as a security practitioner and the wisdom of other leading figures in the area to merge the two practices, explaining the need and demand for what we now call DevSecOps.
Glenn proposes a three-layer approach for tackling DevSecOps.
Staying up to date with the current practices and emerging technology, and learning from other peoples success and mistakes, is a never-ending journey. Each individuals experience and skillset are different and so, in the first DevSecOps layer, educational programmes must be devised and adaptable to allow each resource to understand the core principles of DevSecOps. This is to ensure the security fundamentals are well understood by, and ingrained into, the delivery team. Glenn discusses different learning methods to offer teams, ranging from gamifying online training to running tournaments and establishing security champion roles to allow people to put theory into practice reinforcing the lessons taught. He notes that teaching materials are also available outside of the company. The teaching programme adopted for each individual should reflect how they learn and their willingness to expand their security knowledge.
The second layer focuses on the design aspect of the solution. Glenn covers good and secure coding practices, such as threat modelling and peer programming. In addition, he shares respected industry references from the OWASP and SANS establishments. The details from these will complement the lessons learned, prescribed from the training programme, and hopefully start to bake security into the core practices of the delivery team. The adopted software architecture for the solution must also be supportive of the modern development practices, and so the world of containers and microservices technology are also discussed. The reliability of the delivery pipeline and its security becomes more important in the world of DevSecOps. This layer concludes by highlighting good practices for securing the delivery pipeline.
Completing the trio, the third layer discusses the different security testing techniques which can be deployed as part of your DevSecOps practice. Automating the deployment and testing is key, but, in reality, not all testing can be automated due to certain industry regulations. Most teams will challenge the need for traditional penetration testing, but the use and purpose of this activity is not dismissed from Glenns three-layer framework.
To bring everything together, Glenn wraps up the book by structuring a programme of activities for teams to explore and adopt to start their journey into the world of DevSecOps.
This book will no doubt become a mandatory reference in the DevSecOps culture I hope you will enjoy it as much as I have.
Michael Man
DevSecOps London Gathering
September 2020
Introduction
Designing applications, whether they are simple APIs (application programming interfaces), microservices or large monoliths, is a complex activity involving resources from many disciplines. In traditional software delivery practices involving a slow linear lifecycle (such as waterfall), a product starts as an idea to meet a perceived requirement of the end user. This idea is handed over to a team of architects who design the application according to a set of criteria that meet the business objectives. The architecture determines the key features of the software and infrastructure, as well as non-functional requirements such as performance. When the architecture is complete, software engineers write the code that makes these pre-designed features, while operations engineers build the underlying infrastructure and services needed to host the applications. Finally, teams of testers validate the application against the functional and non-functional requirements and provide the quality assurances that meet user expectations.
These traditional methodologies have given ground to newer ways of working that merge the roles of product owners, architects, developers, testers and representatives of end-users into integrated product teams providing faster delivery and greater agility and responsiveness to changes in requirements. Furthermore, cloud hosted applications have led to the inclusion of operations resources within multi-disciplined teams to write infrastructure as code, which enables products to be developed, tested and deployed as complete packages. These teams and their methodologies have come to be known as DevOps (from the combination of dev elopment and op erations). The necessity of delivering new products and features to customers as quickly as possible has driven the journey from traditional waterfall to DevOps. Organisations that struggle to adapt to new ways of working have learned that the lengthy waterfall processes are unable to compete against the more agile and responsive organisations.
