86,99 €
Principles, applications, and methodologies to help organizations transition from traditional security models to a Zero Trust approach
Zero Trust Security is a hands-on guide that bridges the gap between Zero Trust theory and real-world practice through a unique and practical approach. Following the journey of a fictional manufacturing company, readers learn how to go from a flat network into a robust Zero Trust architecture. Through step-by-step implementations, the book demonstrates the essential elements of modern security architecture.
Each chapter provides both theoretical understanding and practical implementation guidance. The included Docker environments and configuration files enable readers to practice implementations in a safe environment, making complex security concepts tangible and actionable. For readers just beginning their Zero Trust journey or enhancing existing security controls, this guide offers actionable insights to build a more resilient security architecture.
Additional topics explored in Zero Trust Security include:
Zero Trust Security is an essential resource on the subject for IT managers, security architects, DevOps engineers, compliance officers, and cyber security practitioners. The book is also highly valuable for students in related programs of study seeking to understand the latest developments in the field.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 306
Veröffentlichungsjahr: 2025
Adam Tilmar Jakobsen
Copyright © 2026 by John Wiley & Sons Inc. All rights reserved, including rights for text and data mining and training of artificial intelligence technologies or similar technologies.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
The manufacturer’s authorized representative according to the EU General Product Safety Regulation is Wiley-VCH GmbH, Boschstr. 12, 69469 Weinheim, Germany, e-mail: [email protected].
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and the authors have used their best efforts in preparing this work, including a review of the content of the work, neither the publisher nor the authors make any representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data has been applied for:
Hardback: 9781394361090
ePDF: 9781394361113
epub: 9781394361106
oBook: 9781394361120
Cover Design: Wiley
Cover Image: © Soham Pansuriya/Shutterstock
Cover
Title Page
Copyright
Table of Contents
Preface
Acknowledgements
About the Author
Introduction
Notes
Chapter 1: Use Case: Juice Factory
1.1 Company Profile
1.2 Getting to Know the Business and Finding the Crown Jewels
Chapter 2: Zero Trust
2.1 Why Perimeter Security Is Insufficient
2.2 Zero Trust: Principles
2.3 NIST SP 800-207: Zero Trust Security Architecture
2.4 Implementing Zero Trust
2.5 Why Zero Trust Projects Fail
2.6 Applying Zero Trust to Juice Factory
2.7 Processes and Procedures
2.8 Summary
Note
Chapter 3: Docker
3.1 Installing Docker on Windows
3.2 Handling Containers with Docker
3.3 Docker Compose
3.4 Summary
Notes
Chapter 4: Initial Design of the Juice Factory Network
4.1 Services and Docker Images
4.2 Summary
Chapter 5: Network Segmentation and Network Security
5.1 Segmenting the Network
5.2 Key Technologies for Network Segmentation
5.3 Implementing Network Segmentation
5.4 Segmenting the Juice Factory Network
5.5 IPv6
5.6 Web Proxy
5.7 Summary
Notes
Chapter 6: Network Monitoring
6.1 What Traffic to Monitor?
6.2 Techniques for Monitoring
6.3 Implementing Network Monitoring with Suricata
6.4 Blackhole and Darknet
6.5 Summary
Notes
Chapter 7: Identity Access Management and Jump Box
7.1 Identity Access Management
7.2 Multi-factor Authentication
7.3 Credential Rotation
7.4 Single Sign-on
7.5 Applying Zero Trust to IAM
7.6 Importance of Separation of Duties
7.7 Jump Box
7.8 Summary
Notes
Chapter 8: Endpoint Detection and Response
8.1 Core EDR Components
8.2 Comparison to Traditional AV
8.3 Adding EDR to Our ZTA
8.4 Velociraptor: An Open-source EDR
8.5 Deployment of Velociraptor in Our Environment
8.6 Working with Velociraptor
8.7 Application Allow Listing
8.8 Summary
Notes
Chapter 9: Security Information and Event Management
9.1 SIEM Architecture
9.2 Log Collection
9.3 Data Processing Engine
9.4 Log Enrichment
9.5 Storage and Retention
9.6 Analysis and Visualisation Interface
9.7 What to Log?
9.8 Zero Trust SIEM
9.9 Implementing SIEM with ELK
9.10 Analyse Logs with Kibana
9.11 Incident Response
9.12 Detection Tuning
9.13 Sigma
9.14 Security Orchestration, Automation, and Response
9.15 Managed Security Service Provider
9.16 Summary
Notes
Chapter 10: Vulnerability Management
10.1 Vulnerability Scanner
10.2 Zero Trust Vulnerability Management
10.3 Deployment of Nessus Within Our Docker Environment
10.4 Summary
Note
Chapter 11: DevSecOps and Web Protection
11.1 The CALMS Framework
11.2 OWASP Top 10
11.3 Applying Zero Trust to the Development Process: Static and Dynamic Code Analysis
11.4 Web Application Firewall
11.5 Software Bill of Material
11.6 Applying DevSecOps to Security
11.7 Summary
Notes
Chapter 12: What About People?
12.1 Culture
12.2 Tabletop Exercise
12.3 Summary
Notes
Chapter 13: Journey from Flat Network to Zero Trust
13.1 Cloud
13.2 All That We Have Achieved So Far
Notes
Glossary
Index
End User License Agreement
Chapter 2
Figure 2.1 NIST SP 800-207 Zero Trust reference architecture.
Figure 2.2 John Kindervag – Zero Trust learning curve.
Chapter 3
Figure 3.1 Microsoft store.
Figure 3.2 Windows terminal.
Figure 3.3 Docker hello-world.
Chapter 4
Figure 4.1 Juice Shop.
Figure 4.2 Juice Factory – production system.
Figure 4.3 Juice Factory – HMI controls.
Figure 4.4 Network diagram.
Chapter 5
Figure 5.1 VLAN ports.
Figure 5.2 Network diagram.
Chapter 6
Figure 6.1 Network SPAN.
Figure 6.2 Network TAP.
Figure 6.3 Wireshark.
Figure 6.4 Network diagram.
Figure 6.5 Darknet architecture.
Chapter 7
Figure 7.1 OAuth flow.
Figure 7.2 Security markup language flow.
Figure 7.3 Star topology.
Figure 7.4 Network diagram.
Chapter 8
Figure 8.1 Velociraptor login.
Figure 8.2 Velociraptor client graph.
Figure 8.3 Velociraptor install client.
Figure 8.4 Velociraptor search bar.
Figure 8.5 Velociraptor clients.
Figure 8.6 Client shell.
Figure 8.7 Velociraptor menu.
Figure 8.8 Add new hunt.
Figure 8.9 Configuration of the hunt.
Figure 8.10 Hunt artefact.
Figure 8.11 Hunt review.
Figure 8.12 Hunt queue.
Figure 8.13 Starting the hunt.
Figure 8.14 Hunt finish.
Figure 8.15 Local security.
Figure 8.16 AppLocker rules.
Figure 8.17 Create default rule for AppLocker.
Figure 8.18 Enforce AppLocker.
Figure 8.19 Search bar service.
Figure 8.20 Windows services.
Figure 8.21 AppLocker message.
Chapter 9
Figure 9.1 Mitre navigator.
Figure 9.2 Network diagram for SIEM.
Figure 9.3 Server event.
Figure 9.4 Create server event.
Figure 9.5 Server event monitoring.
Figure 9.6 Server event configuration.
Figure 9.7 Server event review.
Figure 9.8 Velociraptor client command.
Figure 9.9 Kibana menu.
Figure 9.10 Create data view.
Figure 9.11 Data view creation window.
Figure 9.12 Data view.
Figure 9.13 Kibana search results.
Figure 9.14 NIST SP 800-61 incident response lifecycle.
Figure 9.15 Sigma flow.
Chapter 10
Figure 10.1 Network diagram.
Figure 10.2 Initiation.
Figure 10.3 Nessus registration.
Figure 10.4 Nessus product.
Figure 10.5 Nessus get activation code.
Figure 10.6 Nessus activation code.
Figure 10.7 Nessus download plugins.
Figure 10.8 Nessus scan menu.
Figure 10.9 Nessus new scan button.
Figure 10.10 Basic scan.
Figure 10.11 Create new scan.
Figure 10.12 Nessus scan overview.
Figure 10.13 Scan results.
Chapter 11
Figure 11.1 Network diagram.
Figure 11.2 Juice Shop frontpage.
Figure 11.3 Juice Shop login page injection.
Figure 11.4 Juice Shop admin login.
Figure 11.5 Juice Shop admin profile.
Figure 11.6 WAF protection.
Chapter 12
Figure 12.1 Dirty USB attack card from Backdoors & Breaches.
Chapter 13
Figure 13.1 Network diagram.
Chapter 2
Table 2.1 Protect surfaces of Juice Factory.
Table 2.2 Initiate transaction map of Juice Factory.
Chapter 5
Table 5.1 Juice Factory transaction map.
Table 5.2 Comparison of IPv6-related commands across different operating systems.
Chapter 6
Table 6.1 Transaction map.
Chapter 7
Table 7.1 Transaction map.
Chapter 8
Table 8.1 Transaction map.
Chapter 9
Table 9.1 Transaction map.
Table 9.2 Elasticsearch pipelines for sigma.
Chapter 10
Table 10.1 Transaction map.
Chapter 12
Table 12.1 Table scenario.
Chapter 13
Table 13.1 Transaction map.
Cover
Table of Contents
Title Page
Copyright
Preface
Acknowledgements
About the Author
Introduction
Begin Reading
Glossary
Index
End User License Agreement
iii
iv
ix
xi
xiii
xv
xvi
xvii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
Zero Trust is not a project, but a new way of thinking about information security. – John Kindervag, author of the founding Zero Trust paper, ‘No More Chewy Centers’
The essential paper that started the Zero Trust idea was John Kindervag’s ‘No More Chewy Centers: Introducing The Zero Trust Model of Information Security’. It was an unfortunate name because how can you run a network if you do not trust anything or anybody? That was not what Kindervag meant by the word Zero Trust. The concept is based on how the military thinks about protecting secrets. Everything requires a ‘need to know’ basis. If you don’t require the information to do your job, you shouldn’t have access to it. That’s all there is to Zero Trust. This idea of only granting access to what is required should apply to users, servers, network equipment and applications. We grant users access only to what they explicitly need for their work. That whole idea of Zero Trust. This way, we can reduce the attack surface of our environment by limiting access to services and data.
This book offers a practical guide to implementing Zero Trust principles in a simulated environment. The goal is to provide hands-on experience with the technologies and concepts that underpin Zero Trust, allowing readers to understand how to apply these principles in real-world scenarios. The book is structured to take you through the process of setting up a simulated environment using Docker, implementing network segmentation, monitoring and logging network activities, managing identity access, deploying endpoint detection and response solutions, integrating security information and event management systems, identifying and mitigating vulnerabilities, and protecting web applications using web application firewalls.
I would like to thank everyone in the cybersecurity community for all the awesome work they share on the internet. Without them, this book would not have been possible.
My journey with computers began, as it did for many others, with playing video games. Initially, my goal was to become a game developer, which led me to get a master’s degree in computer science. Although that dream didn’t materialise, I instead joined the Danish Army as a cyber specialist for the army intelligence within the electronic warfare division. Because of the classified nature of my work, I cannot delve into specifics; however, my job generally involved expanding the utility of cyber capabilities within operations, focusing on SIGINT, OSINT and all-source intelligence while also supporting other departments such as HUMINT, PSYOPS and IMGINT. After three years with the army intelligence, I joined Bluewater Shipping, a major Danish shipping company. Initially serving as a solution architect for all internally developed software, my role shifted to information security following a significant cyberattack on the company. As the sole security engineer, I oversaw the entire operation pipeline, including defining and implementing detection rules, incident response and much more. Another three years passed, and the government offered me the opportunity to join as a security specialist. The knowledge I’ve gained throughout my journey is an amalgamation of research, reading white papers, taking courses, taking certifications and taking part in Capture the Flag challenges.
I have written this book because I felt there was a lack of material about the more practical side of implementing Zero Trust, with hands-on exercises to help you learn. For this reason, I have included as many practical elements throughout the book. This resulted in the book becoming somewhat of a coursebook. The goal is to help people who are new to the field of cybersecurity. To where they can implement Zero Trust.
This book draws inspiration from The Phoenix Project,1 as well as Project Zero Trust.2 What both these books have in common is that they are about a fictional company that goes through a transformation of its information technology (IT) practices during a crisis. However, I found these books lacked a practical component that went into detail on some of the specific technologies that are used to achieve their goal. My goal with this book was to fill that gap by providing hands-on experience with these technologies. Giving the reader a demonstration of how different security controls work in action. Helping you understand how they work and what makes them important. The primary goal of this book is to bridge the gap between theoretical knowledge and practical skills. What this book will not do is make you an expert in Zero Trust, nor would it be possible for any book to do that. This is just the starting point of your journey towards becoming an expert in Zero Trust.
What is it that makes Zero Trust so interesting and confusing at the same time? Zero Trust is a change in how we view security. Traditional models of security rely on a strong perimeter to keep threats outside the network. The problem with this approach is that once an attacker breaches the perimeter, they can freely move within the network with relative ease. This is where Zero Trust comes into the picture. Its goal is to mitigate this by enforcing strict access controls that are continuously verified. And constantly monitoring the network for any threats. Zero Trust emphasises the idea of minimising trust. This involves identifying instances where user and system access is beyond what is necessary for their job.
The way we explore Zero Trust in this book is through a fictional organisation called Juice Factory. This fictional organisation’s IT infrastructure will be simulated using Docker containers. I chose Docker as it offers a lightweight and efficient way to create, deploy and manage multiple applications. This makes it an ideal tool for this project. Because it is a simulated environment, it has limitations, including control over the network, lack of network equipment for us to work with, and the absence of identity access management (IAM), and of real users. Containerisation also doesn’t fully replicate enterprise network infrastructure components such as physical switches, routers and hardware firewalls.
Despite these limitations, Docker provides a practical and accessible platform to illustrate the key concepts behind Zero Trust. You can find the Docker environment for this book at the GitHub repository.3 Here you can download the Docker environment we will use throughout this book.
Each chapter will guide you through Zero Trust principles and the implementation of security controls in our Docker environment, giving you step-by-step instructions on how to do so. As we progress through the book, you will learn:
Set up a simulated environment using Docker
Implement network segmentation
Monitor and log network activities continuously
Challenges of IAM and Using Jump Box to secure access to segmented networks
Deploy and configure Endpoint Detection and Response (EDR) solutions
Integrate Security Information and Event Management (SIEM) systems
Identify and mitigate vulnerabilities using vulnerability scanners
DevSecOps and Protect web applications using web application firewall (WAF)
Each chapter of the book will build upon the previous one. Upon completion, we will have a completely new environment, incorporating various security controls to defend against threat actors. While this book provides a detailed and practical guide for implementing Zero Trust, it is important to remember that no single resource can cover every scenario or challenge that you will face in the real world. The goal is to provide you with a foundational understanding of things, including some hands-on experience. This means that additional learning and adaptation are necessary to address the specific needs and complexities of your organisational environment. I encourage you to experiment, ask questions, and seek further knowledge as you embark on your journey towards cybersecurity expertise. By the end of this book, you should have a foundational knowledge of what Zero Trust thinking is and the controls we use in Zero Trust and cybersecurity.
1
The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford, IT Revolution Press, 2013.
2
Project Zero Trust, George Finney and John Kindervag, Wiley, 2022.
3
https://github.com/Paradoxxs/zero-trust-enviroment
What do you mean, zero trust? To be a successful organisation, we need trust. Yes, but not beyond what is required for them to do their job.
Throughout this book, we will explore the ideas of Zero Trust Architecture (ZTA) using a fictional company that allows us to look at the different concepts of zero trust in a practical and fun way. The corporation we will use is called Juice Factory, which represents a business that comprises both information technology (IT) used for communication and collaboration between employees and customers. And then there is also the operational technology (OT) that controls the production system making the Juice. At the last seminar for board members, they heard about a concept called Zero Trust, which can be used to make any organisation secure. Combined with the increasing risk of a cyber incident. The board of directors has hired you as their first Chief Information Security Officer (CISO). As the CISO, it’s your job to successfully adopt the strategies of ZTA to the organisation’s IT and OT environment. Making them more resilient against cyber threats and reducing the probability of a significant cyber affecting the business.
The first thing any CISO or security professional should do is to understand the organisation. It’s impossible to defend something you do not understand, like why the business makes the decision that they do. With that said, let’s get started getting to know the business we will work with. Here are some more details about the Juice Factory, to help clarify what they are all about.
Name: Juice Factory
Industry: Manufactory
Headquarters: Europe
Employees: 500
Revenue: $100 million annually
Sales Distribution:
10% from Business to Consumer (B2C) online sales
90% from Business to Business (B2B) sales
The headquarters of Juice Factory is located in a major European city. With approximately 450 employees located here. It comprises two buildings: one dedicated to the administrative offices of the organisation and the other to the engineering and manufacturing of juice products. All of the data centres for Juice Factory are located on-premises within the headquarters building. This ensures streamlined of IT and OT operations.
Juice Factory also operates several smaller satellite offices focused primarily on B2B sales in different countries. Sales personnel mostly staff these offices. With a typical size of around 4–6 employees per office. These people manage local customer relationships and sales activities in their respective countries.
Juice Factory’s OT systems are integral to its manufacturing processes. It automates the flow of production, using machinery control that is connected to a programmable logic controller (PLC) that is integrated with a human–machine interface (HMI), which allows the engineer to control the flow of the production facility with just a press of a button. The engineering team is responsible for monitoring and controlling the OT system. Because the production facility is critical for the business, it is not possible to reboot the system outside the planned maintenance cycles.
For the IT environment, the Juice Factory has its own IT infrastructure. The data centres are all at headquarters. The satellite offices only consist of the minimum network equipment to function and endpoints. Every satellite office is required to have a constant connection to the headquarters network to access the corporate resources. We achieve this using site-to-site VPNs.
For the design of the security architecture for an organisation, it is important to consider the business processes. When implementing new security controls at Juice Factory, consider the following business factors.
The continuous production of juice.
Remote and Mobile Workers: Employees often work remotely or are on the move, requiring secure access to company resources from various locations and devices.
Many Business Partners: The company collaborates with numerous partners, necessitating secure communication and data exchange channels.
Intellectual Property: The Juice Factory holds valuable production and manufacturing trade secrets that require protection from unauthorised access and cyber threats.
Diverse Endpoint Devices: The company’s IT environment includes a mix of endpoint devices running on Windows, Mac and Linux, requiring a versatile security solution.
Geographic Diversity: With operations across different geographic locations, the Juice Factory must comply with local regulations and meet diverse compliance requirements.
Whatever organisation you are working with, the same processes should be done. Talk with the different department leaders, understand how they work and what unique challenges they are facing. This helps you identify what problems you can mitigate and, most importantly, not introduce new problems for the departments.
Security can no longer afford to hide in our cubicle. The goal of security is to allow business processes to be performed in a secure manner. Not only that, we also have to be sure that the security control we put in place does not limit the business. Otherwise you will quickly be faced with shadow IT, and you will no longer have control over where the business data exists. For example, when our sales team needed a file-sharing solution for large technical documents, security initially prohibited cloud storage use. This led to sales representatives creating personal Dropbox accounts for sharing product specifications, inadvertently exposing proprietary data. A good way to mitigate shadow IT is by implementing approved alternatives before restricting tools.
What is required by us is to get to know the business. For that to happen, we have to create a relationship with the rest of the business leadership team. The best way to do this is through communication and collaboration between departments. How do we go about achieving this? The goal should be to identify how security can add value to the organisation. Speak to the different key departments for the organisation. These are often sales and legal. Legal allows you to understand what regulation the organisation must adhere to. And for sales, identify if there are any security concerns from the customers or if the organisation has lost any deals with potential customers because of lacking security. Another example is if sales or legal answers compliance-related questions about information security. You should step up and take this off their shoulder. Not only are you best suited to answer the question, it also creates a positive relationship with the department. The goal is to demonstrate to the other leaders that security is not just a cost centre, and instead is a business enabler. This requires you to speak the language of business, which they know and leave behind all the IT jargon behind, for our fellow security engineers.
The end goal is to understand which business processes makes the business profitable. Including the supporting systems that enables these processes. With that, we should have identified the crown jewels of the organisation. This allows us to prioritise what to focus on first and which system needs greater protection. Let’s look at the Juice Factory and try to understand both the crown jewels and the challenges the organisation is facing. Since this is a fictional business. It is not possible for us to go out and ask the different department leaders for input about the different functions of the business and the problems they are facing. We just have to pretend that we have already done so, and these are their responses.
Legal: Our Payment Card Industry Data Security Standard (PCI DSS) compliance efforts currently consume approximately 200 working hours yearly. We’re seeing increasing scrutiny from auditors, particularly around our card data environment segmentation. We’ve identified gaps in our GDPR compliance, specifically around data subject access requests and cross-border data transfers. Failure to address these issues may result in potential fines of up to 20 million euro or 4% of annual revenue.
Production: Our OT environment runs on legacy systems that control specialised juice processing equipment. We cannot reboot the production environment because of the loss of production time to the business. The only time we can perform maintenance and security update are part of scheduled maintenance, with only a single day each year is all that’s allowed for maintenance. We’ve identified three critical vulnerabilities in our SCADA systems, but patching requires a full system shutdown. We store our proprietary recipes digitally, accessible to 15 engineers; however, we lack an access log to audit who accesses the documents. A competitor recently attempted to hire one of our senior engineers, raising concerns about IP protection.
This covers the security concerns of the organisation. For this book, we will not go into how to handle compliance. That could be a book on its own. Instead, let’s focus on the IT and OT environment. What we know so far is that we cannot reboot the OT environment, as the production loss is too high. That limits us to only activities that do not directly touch the production systems itself. This limits us to only modify the network configuration. We should mark the production system as a crown jewels because of its criticality to the organisation. And it should be one of the first systems we will try to improve the protection for. For the IT environment, we need to ensure continuous operation, as any downtime stops sales for contacting potential leads and managing customer relationships.
Now that we have learned a little about the Juice Factory, which we will try to protect throughout this book. In Chapter 2, we will be heading straight into Zero Trust, to get a better understanding of how the strategies of Zero Trust can identify and design the controls that we need to implement.
Zero Trust is not a project, but a new way of thinking about information security. – John Kindervag, author of the founding Zero Trust paper, “No More Chewy Centers”
The essential paper that started the Zero Trust idea was John Kindervag’s ‘No More Chewy Centers: Introducing The Zero Trust Model of Information Security’. It was an unfortunate name, because how can you run a network if you do not trust anything or anybody? That was not what Kindervag met with the word Zero Trust. The concept is based on how the military thinks about protecting secrets. Everything requires a ‘need to know’ basis. If you don’t require the information to do your job, you shouldn’t have access to it. That’s all there is to Zero Trust ‘if you do not need it to do your job, you shouldn’t have access to it’. This idea of only granting access to what is required should apply to users, servers, network equipment and applications. We grant users access only to what they explicitly need for their work. That’s whole idea of Zero Trust. This way, we can reduce the attack surface of our environment by limiting access to services and data.
When it comes to implementing Zero Trust, there is no product that can make you ‘Zero Trust’, no matter how much marketing tells you otherwise. Zero Trust is a philosophy, a strategy and a new way of thinking about security. The goal is to evaluate your environment’s security state continually. There will never be a presentation saying, ‘We have achieved Zero Trust’. There is no need to go out and buy a suite of new tools; most organisations probably already have technology within their environment that can get you a long way down the road of Zero Trust. The only difference from before is that you just have to configure them with the mindset of Zero Trust. Before we can dive into examples, we have to get an understanding of the basic design principles. In this chapter, we dive into the four core design principles of Zero Trust, giving you a method for prioritising and evaluating what controls need to be implemented first and how.
To understand Zero Trust, we have to understand the security architecture that came before, which would be perimeter security. Perimeter security treats outside network connections as untrusted and all inside connections as trusted. The aim is to build a strong fortification, resembling a wall around a castle. The problem is, once you are on the inside, they trust similarly to the Trojan horse. Others like to compare the perimeter design to a hard candy shell on the outside but a scrumptious chocolate centre in the middle. The problem with perimeter design is by default we trust all internal systems. With this model, once an adversary is on the inside of the network, they become automatically trusted. Security controls don’t address internal-to-internal attacks. A question I like to ask is ‘Do you have the same level of protection for outbound connection to the internet, as you have for inbound connection?’ This is a good question to help understand if the organisation is thinking in terms of Zero Trust. Another question you should ask is ‘does your organisation have devices on the network whose configuration or software you cannot guarantee?’
I frequently hear of organisations that let internal vulnerabilities persist because they believe these vulnerabilities are safe from exploitation within their internal network. What about getting access to the different systems? Do employees and contractors truly have the least privilege access? Did we restrict contractor access to the contract period? What about your employees? When was the last time you verified that people with privileged access still have a need for this kind of access?
The idea of the perimeter had died a long time ago. We have in our pocket a small computer that is constantly jumping between different networks that we do not have control over. Laptops are also being removed from the office and connected to different networks like the airport Wi-Fi. Then there was the cloud, and the perimeter completely broke down. We now have a critical system for the organisation running on someone else’s hardware, transmitting data over a network we have no control over. The one thing everyone knows is that the environment will, at some point, get compromised. The problem is our architectures do not reflect this. Every part of the environment requires the same level of rigorous protection. We can no longer rely on perimeter architecture for protection. We have to find new design principles, which we have used to help us design an environment that we can protect.
With an understanding of what came before, we can now head into understanding Zero Trust. Good for us is that Kindervag also includes four design principles in his Zero Trust paper. This will help to get a better understanding of what Zero Trust is and how it can apply to our environment.
Understanding Business Outcomes: The goal is to understand how the business functions before making any organisational changes. It is critical to have a foundation of understanding of the organisation’s business objectives. By asking, ‘What is the business trying to achieve?’ This ensures that the security measures align with the business objectives. The goal should be to help better protect the organisation, without limiting its ability to make a profit. Even better if your security program can be a business enabler and drive additional revenue. One requirement of understanding the business is that you have identified the crown jewels of the organisation. What are the business processes that are driving the profits of the organisation? These systems and processes need to be protected better than anything else in the organisation, or the business will not survive.
