Zero-Trust SASE DevSecOps

@arafkarsh arafkarsh
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh
8 Years
Network &
Security
6+ Years
Cloud
Native Apps
8 Years
Cloud
Computing
8 Years
Distributed
Computing
Architecting
& Building Apps
Microservice
Architecture Series
Building Cloud Native Apps
Zero Trust / SASE
Network / Security
Cisco SD-WAN / SD-Access
Cisco Secure Cloud Insights / Jupiter One
GRC / DevSecOps
Part 12 of 12

@arafkarsh arafkarsh 2
Slides are color coded based on the topic colors.
VXLAN / GRE /
DMVPN / LISP / MPLS
SDN / SD-WAN
Service Mesh
2
Network / Security
SD-WAN / SWG
DNA / ISE / SD-Access
Secure Cloud Insights
JupiterOne
3
Cisco Solutions
Perimeter Security
Zero Trust / NIST 800-207
Beyond Corp / SDP
ZTX / CARTA / SASE
1
Zero Trust
DevOps
DevSecOps
Playbook
4
Operations

0
Setting up the Context
o Developer Journey
o US DoD: Maturation of SDLC Best Practices
o SANS: Cloud Security Architecture
3
DoD = Department of Defense
This is the final Part (12) of the
Cloud Native App Architecture
Series focused on Software
Developers.
The objective of this Chapter is to
give a good overview of the
Networking and Security Landscape
to the developers and how they can
contribute (Code / Service Mesh)
towards the Security Measures
handled by the Security Team.
This Section sets up the context to
Networking / Security and
Operations (DevSecOps)

Agile
Scrum (4-6 Weeks)
Developer Journey
Monolithic
Domain Driven Design
Event Sourcing and CQRS
Waterfall
Optional
Design
Patterns
Continuous Integration (CI)
6/12 Months
Enterprise Service Bus
Relational Database [SQL] / NoSQL
Development QA / QC Ops
4
Microservices
Scrum / Kanban (1-5 Days)
Mandatory
Design
Patterns
Infrastructure Design Patterns
CI
DevOps
Event Streaming / Replicated Logs
SQL NoSQL
CD
Container Orchestrator Service Mesh

Maturation of SDLC Best Practices
5
Source:
Page 16
US DoD Enterprise
DevSecOps 2.0
Fundamentals

SecOps / DevOps
6
Source: SCI – Your Eyes in the Sky By AI Huger, Nov 15, 2021
While SecOps starts on the left with security posture and attack surface
management as its entry point, DevOps start at the far right with
continuous integration and continuous delivery (CI/CD) pipeline and
application/API security as their main care about.
As SecOps moves right and begins to influence the other
stakeholders within a mature organization, DevOps shifts
left to include pre-deploy checks by using runtime security
inputs.

SANS Cloud Security Architecture Principles
7
Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute
Think
Components
Design for
Failure
Always
Think of
Feedback Loops
Use Different
Storages
Options
Built-In
Security
at every Layer
CENTRALIZATION
Focus on
Centralization
Standards & Automation
Design for
Elasticity

1
Zero Trust
o Perimeter Security Vs. Zero Trust
o Google Beyond Corp
o NIST 800-207
o Forrester Zero Trust Extended
o Software Defined Perimeter
o Secure Access Service Edge
8
o Understand the Origin of
Zero Trust
o Issues with Perimeter
Security
o Zero Trust Concept based
on NIST Standards
o Implementing Zero Trust
using Software Defined
Perimeter
o Understanding SASE
Objectives

History: Evolution of Security & Threat
9
Time Technology / Threats
1 Early 1990s Anti Viruses / Viruses
2 Mid 1990s Wardialing
Testing an organization's list of phone numbers for the presence of modems.
After the Telecommunications Consumer Protection Act of 2003 made it
illegal to "dial for tone" war dialling died off.
3 Late 1990s Firewalls Deep Packet Inspection
4 Early 2000s PKI
A public key infrastructure (PKI) is a set of roles, policies, hardware, software and
procedures needed to create, manage, distribute, use, store and revoke digital
certificates and manage public-key encryption
5 Mid 2000s Deperimeterization Jericho Forum
6 Late 2000s Next Gen Firewalls
7 Early 2010s Defense in Depth & APTs
An advanced persistent threat (APT) is a stealthy threat actor, typically a nation state or state-
sponsored group, which gains unauthorized access to a computer network and remains
undetected for an extended period
8 Mid 2010s AI & Big Data
9 Late 2010s Zero Trust
Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds

What Zero Trust is
10
• NOT A Next Generation Firewall / Security Device
• NOT A Next Generation Perimeter
• NOT A Next Gen VPN Solution
• NOT a Security Product
• NOT an IT Project
• NOT Eliminating your Intranet
• AND NOT About “Trusting No One”

How ZERO TRUST should Help Organization
11
• Business Focused (Enables Business)
• A (Architectural) State of Mind
• Same Security Principles for Internet & Intranet
• A Combination of Process and Technologies
• Reduced Complexity
• Better User Experience for SecOps and Partners

Perimeter Security Vs. Zero Trust
12
Classic Security Model
Perimeter Security
• Location Based (External /
Internal)
• Anyone inside the network is
always trusted.
• Based on Layered Security
Never Trust,
Always Verify 1
Implement
Least Privilege 2
(Always)
Assume Breach 3
Forrester's John Kindervag 2010: No More Chewy Centers: Introducing
The Zero Trust Model Of Information Security
Inspired from Jericho Forum Commandments v1.2 May 2007
Source: Microsoft: Jericho & Modern Security
Restrict everything to a secure Network
Zero Trust
Protect Assets
anywhere with
Central Policy

Zero Trust: Access Management
13
• Least Privilege
• Every Access is limited to a
specific user, device, and
app or resource only
• Centralized
• Policies are centralized
across common IT Systems
• Policies are defined by
Business Team (Support
from IT)
• Dynamic
• Access Decisions are made
in real-time
• Context of the Access
influence the Decision
• Adaptive
• Open to Support new Auth
Protocols
• Constantly Evolving System
(Machine Learning, AI)

Zero Trust: Data
14
• Adopt the Principle of Least Privilege
• Access to the Data MUST be limited to a Specific user, device
and App or Resource Only
• Identify the User Persona and limit the access based on that
• Contextual Access Control
• Data Access Policies must be defined by the Business with the support of IT
• Access decisions must be made in real-time – as and when its required.
• Operate Outside your Control
• Business needs to interact with the outside world

Zero Trust: Network
15
• It’s Application and User Centric and not Infra or Technology Centric
• No DMZ or VPN anymore: No Security Perimeter
• All Network Sessions MUST have Authentication and Authorization
• Only Secure (Encrypted) Protocols allowed on Network
• More than One way to Implement Zero Trust Network
• Network Micro Segmentation (Lots of Tiny Firewalls)
• Software Defined Perimeter (Lots of Tiny VPN)
• Identity Aware Proxy (Next Gen Web Access Management)
• All of the Above

Jericho: Zero Trust Fundamentals
16
JFC
#4
Devices and applications must communicate using open, secure
protocols.
JFC
#5
All devices must be capable of maintaining their security policy
on an un-trusted network. Designed for Internet
JFC
#6
All people, processes, and technology must have declared and
transparent levels of trust for any transaction to take place.
Multiple trust attributes (user, device, location, app etc)
JFC
#11
By default, Data must be appropriately secured when stored, in
transit, and in use.
Source: Jericho Forum Commandments v1.2 May 2007: https://collaboration.opengroup.org/jericho/commandments_v1.2.pdf

Google Beyond Corp: A New Approach to Enterprise Security
18
Source: 2014: Google BeyondCorp: A New Approach to Enterprise Security https://research.google/pubs/pub43231/

Google Beyond Corp: Design to Deploy
19
Source: 2016: Google BeyondCorp 2: Design to Deployment at Google https://research.google/pubs/pub44860/
Management
Agents
Certificate
Authorities
Asset
Inventories
Exceptions
Others
Trust Inferer
Device Inventory
Service
Access Control
Engine
Access Policy
Interactive Login
Network Switch
Web Proxy
Gateways
Code Repository
Network VLAN
Bug Tracker
Resources
Data Sources Access Intelligence Gateways Resources
1
2
3
4

Google Beyond Corp: Design to Deploy
20
Access requirements are organized into Trust Tiers representing levels of increasing sensitivity.
• Resources are an enumeration of all the applications, services, and infrastructure that are subject to access
control. Resources might include anything from online knowledge bases, to financial databases, to link-layer
connectivity, to lab networks. Each resource is associated with a minimum trust tier required for access.
• The Trust Inferer is a system that continuously analyses and annotates device state. The system sets the
maximum trust tier accessible by the device and assigns the VLAN to be used by the device on the corporate
network. These data are recorded in the Device Inventory Service. Re-evaluations are triggered either by state
changes or by a failure to receive updates from a device.
• The Access Policy is a programmatic representation of the Resources, Trust Tiers, and other predicates that
must be satisfied for successful authorization.
• The Access Control Engine is a centralized policy enforcement service referenced by each gateway that
provides a binary authorization decision based on the access policy, output of the Trust Inferer, the resources
requested, and real-time credentials.
At the heart of this system, the Device Inventory Service continuously collects, processes, and publishes changes
about the state of known devices.
Resources are accessed via Gateways, such as SSH servers, Web proxies, or 802.1x-enabled networks. Gateways
perform authorization actions, such as enforcing a minimum trust tier or assigning a VLAN.

NIST 800-207: Zero Trust Architecture
21
Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final
A User, An Application, or a Device – Operating on (or with) a Computer System which has access to an
Enterprise Resource
Subject
Is an Application, Document, Data, Database, Workload that’s under the Enterprise Control protected
by the Zero Trust System
Resource
Policy Enforcement Point
Policy Engine Policy Administrator
Policy Decision Point
Control
Plane
Data Plane Resource
Subject
User
App Device
UnTrusted Trusted
CDM
System
GRC
System
Threat
Intelligence
Activity
Logs
Data
Access
Policy
PKI
IAM
SIEM
1 2
3

NIST 800-207: Zero Trust Architecture
22
PE – Policy
Engine
PA – Policy
Administrator
PEP – Policy
Enforcement
Point
Policy Decision Point PE is responsible to grant access to a resource for a given subject. The PE uses
enterprise policy as well as input from external sources (e.g., CDM systems,
threat intelligence, etc) as input to a trust algorithm to grant, deny, or revoke
access to the resource.
Source: NIST 800-207 https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
PA is responsible for establishing and/or shutting down the communication. It
would generate any session-specific auth and auth token, or credential used by
a client to access an enterprise resource. PA configures the PEP to allow the
session to start. If the session is denied the PA signals to the PEP to shut down
the connection.
PEP is responsible for enabling, monitoring, and eventually terminating
connections between a subject and an enterprise resource. The PEP
communicates with the PA to forward requests and/or receive policy updates
from the PA.

Google Beyond Corp: with NIST 800-207
23
Management
Agents
Certificate
Authorities
Asset
Inventories
Exceptions
Others
Trust Inferer
Device Inventory
Service
Access Policy
Interactive Login
Network Switch
Web Proxy
Gateways
Code Repository
Network VLAN
Bug Tracker
Resources
Data Sources Access Intelligence
Network PEP
(Access Proxy) Application PEP
1
2
4
Access Control
Engine
Gateways Resources
3

3 Types of PEP: Policy Enforcement Points
24
User Agent PEP runs on the user device (laptops, smart devices, desktops etc.) and provides
secure connections to the resource, introspect the device to provide input into Policies like
device configuration, security posture, geo location etc. PEP can also interact with User if it
requires additional authentication.
User Agent
PEP
NIST 800-207 Zero Trust Architecture
There are 2 types of Application PEPs – External and Internal. Internal one will be running
along with the workload based on sidecar pattern. Internal PEP focuses on Application access
based on User/Service Authentication and Authorization. External PEPs will be linked to
systems like PAM or DLP.
Application
PEP
Network PEP are the simplest among the three category of Policy Enforcement Points.
Network PEP are already in place in any classic setup to some extend, For Ex Devices like
enterprise firewalls (Next Gen Firewalls). These PEPs operate at the network layer enforcing
traffic policies. It can also inspect the data or meta to enforce the policy.
Network
PEP

NIST 800-207: Deployment Models
25
1. Resource Based Deployment Model
2. Enclave Based Deployment Model
3. Cloud Routed Deployment Model
4. Micro Segmented Deployment Model

NIST 800-207: Resource Based
26
Device
Agent
PEP
Policy Engine
Policy Administrator
Control Plane
Data Plane
User
App
Policy
Enforcement
Point
Gateway
Resource Based
Deployment
Model
Zero Trust Deployment Models
Control Messages
Data
Implicit Trust Zone
Pros
• End to End Control of App
and Network Traffic
• Trust Zone behind Gateway
Cons
• PEP need to be deployed for
Device and Resource
• Push back from App
Resource Owners
• Requires 1:1 Relationship
with Subject and Resource
• Need to deployable for
Legacy Apps Resource
Resource = Data, Documents, Apps, Services, Files etc.

NIST 800-207: Enclave Based
27
Device
Agent
PEP
Policy Engine
Policy Administrator
Control Plane
Data Plane
User
App
Policy
Enforcement
Point
Gateway
Enclave Based
Deployment
Model
Control Messages
Data
Implicit Trust Zone
Pros
• Easy to Deploy for Resources
• Fewer PEPs deployed
• PEPs can run at the Edge of
the network
Cons
• Large and Opaque Resource
Zones
• PEPs represent a new type
of Ingress point into the
enterprise Network
Resource Enclave

NIST 800-207: Cloud Routed
28
Device
Agent
PEP
PEP
Policy Decision Point Control
Plane
Data
Plane
User
App
Policy
Enforcement
Point
Gateway
Cloud Routed
Deployment
Model
Control Messages
Data
Implicit Trust Zone
Pros
• Easy to setup for Enterprises
• Reduces the Operational
overhead
• Secure Web Gateway
enables Multi-Cloud or
Hybrid Cloud Environments
Cons
• Adds Latency to user Traffic
• Limited Network Protocols
support
• Large and Opaque Trust
Zones.
Resource Enclave
PEP
Subject

NIST 800-207: Micro Segmentation
29
Control Plane
Data Plane
Micro Segmentation
Deployment Model
Control Messages
Data
Implicit Trust Zone
Pros
• Small Implicit Trust Zone
• Bi-Directional, Good for
Microservices Implementation
Cons
• Large PEP deployment
• Potential Conflicts
• Direct access to PEPs by
Subjects
• Potential for push back from
App Owners
PEP
Subject Resource
Device
Agent
PEP
User
App
PEP
Subject Resource
PEP
Subject Resource

NIST 800-162: Attribute Based Access Control
30
Source: Page 17 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final
An access control method were
• subject requests to perform operations on objects
are granted or denied
• based on assigned attributes of the subject,
• assigned attributes of the object,
• environment conditions,
• and a set of policies that are specified in terms of
those attributes and conditions.

31
1. Subject requests access to object
2. Access Control Mechanism
evaluates
a) Rules,
b) Subject Attributes,
c) Object Attributes,
d) Environment Conditions to
compute a decision
3. Subject is given access to object if
authorized

32
A subject is a human user or NPE, such as a device that issues
access requests to perform operations on objects. Subjects are
assigned one or more attributes.
An object is a system resource for which access is managed by
the ABAC system, such as devices, files, records, tables,
processes, programs, networks, or domains containing or
receiving information. It can be the resource or requested
entity, as well as anything upon which an operation may be
performed by a subject including data, applications, services,
devices, and networks.

33
• An operation is the execution of a function at the request of a subject
upon an object. Operations include read, write, edit, delete, copy,
execute, and modify.
• Policy is the representation of rules or relationships that makes it
possible to determine if a requested access should be allowed, given the
values of the attributes of the subject, object, and possibly environment
conditions.
• Environment conditions: operational or situational context in which
access requests occur. Environment conditions are detectable
environmental characteristics. Environment characteristics are
independent of subject or object, and may include the current time, day
of the week, location of a user, or the current threat level.

NIST 800-162: ABAC in Action
34
• Each object within the system must be assigned specific
object attributes that characterize the object.
• Some attributes pertain to the entire instance of an
object, such as the owner.
• Other attributes may only apply
to parts of the object. For
example,
• a document object could be
owned by organization A,
• have a section with
intellectual property from
organization B,
• and be part of a program run
by organization C.

NIST 800-162: ABAC in Enterprise
35

ACL Trust Chain
36

NIST 800-162: ABAC Trust Chain
37

Forrester: Zero Trust eXtended (ZTX)
38
Forrester Zero Trust extended Ecosystem: Aug 11, 2020
Zero Trust
Strategy
Zero Trust
Capability
Zero Trust
Technology
Zero Trust
Feature
Goal is to evolve towards a
Zero Trust Architecture or
Encrypt all Sensitive Data
For Ex. Data Security
Security teams need the ability
to inventory, classify, obfuscate,
archive, or delete data
according to policy
Ask
“What capabilities does this
technology support and where
does it specifically plug into my
team’s Zero Trust strategy?”

Gartner: CARTA: 7 Core Areas
39
Continuous Adaptive Risk and Trust Assessment approach
Source: Gartner 2018
Replace one-time security gates with Context Aware, Adaptive & Programmable
Security Platforms
1
Continuously Discover, Monitor, Assess and Prioritize Risk – Proactively and Reactively
2
Perform Risk and Trust Assessment Early in Digital Business Initiatives
3
Instrument Infrastructure for Comprehensive, full stack Risk Visibility, Including
Sensitive Data Handling
4
Use Analytics, AI, Automation and Orchestration to speed the time to detect and
respond to scale
5
Architect Security as an Integrated, Adaptable Programmable System, and not Silos
6
Put Continuous Data Driven Risk Decision making and Risk Ownership into BU’s and
product owners
7

Software Defined Perimeter – Context
40
o Classic Network Design creates fixed Perimeter to divide the External
Network with Internal Network
o Using Routers, Firewalls, and other access control devices.
o The concept of Classic Network is based on visibility and accessibility.
1. Today’s network is fluid with Hybrid clouds, IaaS, PaaS, SaaS, IoT, etc.,
all with multiple entry points.
2. This is further complicated by Contractors, Remote/Mobile Users,
BYOD etc.
 These conditions gives rise to Software Defined Perimeter instead of a
traditional Fixed Perimeter
Cloud Security Alliance: May 27, 2020: SDP and Zero Trust

Software Defined Perimeter
41
• SDP abstracts and hides internet connected infrastructure (Routers,
Servers etc.) irrespective of infra is On-Premise or Cloud.
• SDP Secures the user, application and the connectivity.
• Instead of traditional hardware-based perimeter setup, SDP is
completely software driven.
• VPN Connects the users to the Network using a simple
authentication
• While SDP allows the users to connect to the required resource using
real-time contextual risk assessment to determine user access.
According to Gartner more than 60% of Enterprises moved away from VPN by 2021

Software Defined Perimeter – Principles
42
1. Separation of Control Plane and Data Plane. User, Devices etc
access is controlled using Control Plane. SDP Controller handles the
control plane.
2. Separation of logical and physical Components. The Connection
between hosts are virtualized using overlay tunnels.
3. Authenticating the Hosts. Only authorized systems/services allowed
to communicate.
4. Validating the Hosts against a set of policies. Checking for absence
of Malwares, allowed applications, business policies such as time of
the day, checking external Threat Intelligence Database.
Source: IEEE Software-Defined Perimeters: An Architectural View of SDP
SDP is not a replacement for existing solutions, it augments the existing solutions such as SDN.

Software Defined Perimeter: Architecture
43
Policy
Enforcement Point
SDP Gateway
SDP Controller
Control Plane
Data Plane
Resource
Subject
User
App
Device
SDP
Client
Source: https://cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/
IH: Initiating Host
Control Messages
Data
SDP requires
2 Security
modules
1. mTLS
2. SPA
AH
AH: Accepting Host
The model depicted below is Similar to Enclave Resource model from NIST 800-207 Architecture. NIST team
defined that based on Cloud Security Alliance SDP Architecture.

SDP – Secure Communications
44
mTLS – Mutual
Transport Layer Security
SPA – Single Packet
Authorization
• Both Client and Server need to
validate the certificate
• Expect Mutual Root
Certificates for Client & Server
• Avoids Man in the Middle
Attack
HOTP: An HMAC-Based One-Time Password Algorithm
Authenticate before Connect
• Default Policy in SDP Gateway is
Drop All Packets
• Based on RFC 4226: HOTP
• SPA happens before TLS Connection
• For Valid Connections Firewall rule
is created for mTLS connection

Deployment modes of Software Defined Perimeter
45
• Client-Gateway – SDP uses a proxy that arbitrates
connections between clients and a set of protected servers.
A client connects to a gateway which in turn provides access
to hosts that provide services.
• Client-Server – there is no gateway proxy sitting between the
client and server. The clients directly connect to the hosts.
• Server to Server – used for servers offering services (via REST
APIs) to applications.
• Client to Server to Client – peer to peer connections between
clients. Source: IEEE Software-Defined Perimeters: An Architectural View of SDP
As defined by Cloud Security Alliance

Forrester
Wave:
Zero Trust
46

SASE: Secure Access Service Edge
47
Created by Gartner: Six Core Technologies of SASE
Network
Security
SASE
SD-WAN
ZTNA
Zero Trust Network Access
SWG
Secure Web Gateway
CASB
Cloud Access Security Broker
FWaaS
Firewall as a Service
DNS
Security

SASE: Overview
48
o Users
o Devices
o Locations
o Public Cloud
o Data Center
o Edge
Identity Context
Consistent Network & Security Policy
SASE Cloud Infrastructure
WAN Edge
Infrastructure
/ Services
Security
Services
Edge
Threat
Awareness
Sensitive Data
Awareness
Entities Anywhere Resources Everywhere
Zero Trust Access
Consistent User Experience
Source: Gartner 2021 Strategic
Roadmap for SASE Convergence,
March 25, 2021By Neil
MacDonald, Nat Smith, Lawrence
Orans, Joe Skorupa

SASE: Detailed View
49
o Employees
o Contractors
o Partners
o Devices
o Distributed Apps
o Remote
o Mobile
o Offices
o Edge
o Applications
o APIs
o Data
o Devices
o SaaS
o IaaS
o Data Center
o Branch
o Edge
User / Device Identity Context
Consistent Network & Security Policy
SASE Cloud Infrastructure
WAN Edge Services
• SD-WAN
• WAN Optimization
• QoS
• Routing
• SaaS Acceleration
• Content Delivery /
Caching
• …
Security Services Edge
• Secure Web GW
• CASB
• ZTNA / VPN
• FWaaS
• Remote Browser
Isolation
• Encryption /
Decryption
• …
Threat
Awareness
Sensitive Data
Awareness
Entities Anywhere Resources Everywhere
Zero Trust Access
Consistent User Experience
Source: Gartner 2021 Strategic
Roadmap for SASE Convergence,
March 25, 2021By Neil
MacDonald, Nat Smith, Lawrence
Orans, Joe Skorupa

SASE
Convergence
50
Strategic Roadmap for
SASE Convergence,
March 25, 2021
By Neil MacDonald, Nat
Smith, Lawrence Orans,
Joe Skorupa

Timeline for
SASE
Convergence
51
Strategic Roadmap for SASE
Convergence,
March 25, 2021
By Neil MacDonald, Nat
Smith, Lawrence Orans,
Joe Skorupa

SASE: Reference Architecture
52
SASE Reference Architecture
based on Network as a
Service Model
Source: Cisco: SASE with Savvy The Keys to an Effective Secure Access Service Edge Solution
As the workloads are
becoming Cloud Native in a
Hybrid, Multi Cloud
Environment, Cisco Umbrella
and Cisco SD-WAN is an
implementation SASE
Framework.

SASE Framework: Summary
53
Source: July 21, 2021: Steve Murphy SASE and Secure Web Gateway
Secure Access Framework to Manage
• Cloud Environment (Hybrid, Multi Cloud)
• Distributed Workforce (Remote, WFH)
Focuses on Delivery Adaptive Access & Security to Users
• Direct Access to Cloud (SD-WAN)
• Eliminate backhaul to Security Stack
Users can access Apps/Data from Any Device from Any Location
• Security is Applied based on Context

2
Network / Security
o VXLAN / GRE / DMVPN / MPLS / LISP
o SDN / SD-WAN
o Zero Trust / VPN
o Service Mesh
54
o Understanding of Overlay
Networking
o Understanding of GRE /
DM VPN / LISP / MPLS
o Understanding of Software
Defined Networking
o Understanding of SD-WAN
o Understanding of Service
Mesh
Objectives

Networking
o Overlay Network VXLAN
o GRE / mGRE / DM VPN / IPSec /
o LISP : Location ID Separation Protocol
o MPLS : Multi Protocol Label Switching
o SDN : Software Defined Networking
o SD-WAN : Software Defined – WAN
o SD-WAN : Zero Touch Provisioning
o SD-WAN : Public / Private WAN
55

OSI Layers
56

Networking Glossary Netfilter – Packet Filtering in Linux
Software that does packet filtering, NAT and other
Packet mangling
IP Tables
It allows Admin to configure the netfilter for managing
IP traffic.
ConnTrack
Conntrack is built on top of netfilter to handle
connection tracking..
IPVS – IP Virtual Server
Implements a transport layer load balancing as part of
the Linux Kernel. It’s similar to IP Tables and based on
netfilter hook function and uses hash table for the
lookup.
Border Gateway Protocol
BGP is a standardized exterior gateway protocol
designed to exchange routing and reachability
information among autonomous systems (AS) on the
Internet. The protocol is often classified as a path vector
protocol but is sometimes also classed as a distance-
vector routing protocol. Some of the well known &
mandatory attributes are AS Path, Next Hop Origin.
L2 Bridge (Software Switch)
Network devices, called switches (or bridges) are
responsible for connecting several network links to each
other, creating a LAN. Major components of a network
switch are a set of network ports, a control plane, a
forwarding plane, and a MAC learning database. The set
of ports are used to forward traffic between other
switches and end-hosts in the network. The control
plane of a switch is typically used to run the Spanning
Tree Protocol, that calculates a minimum spanning tree
for the LAN, preventing physical loops from crashing the
network. The forwarding plane is responsible for
processing input frames from the network ports and
making a forwarding decision on which network port or
ports the input frame is forwarded to.
57

Networking Glossary
Layer 2 Networking
Layer 2 is the Data Link Layer (OSI Mode) providing Node to
Node Data Transfer. Layer 2 deals with delivery of frames
between 2 adjacent nodes on a network. Ethernet is an Ex.
Of Layer 2 networking with MAC represented as a Sub Layer.
Flannel uses L3 with VXLAN (L2) networking.
Layer 4 Networking
Transport layer controls the reliability of a given link through
flow control.
Layer 7 Networking
Application layer networking (HTTP, FTP etc.,) This is the
closet layer to the end user. Kubernetes Ingress Controller is
a L7 Load Balancer.
Layer 3 Networking
Layer 3’s primary concern involves routing packets between
hosts on top of the layer 2 connections. IPv4, IPv6, and ICMP
are examples of Layer 3 networking protocols. Calico uses L3
networking.
VXLAN Networking
Virtual Extensible LAN used to help large cloud deployments
by encapsulating L2 Frames within UDP Datagrams. VXLAN is
similar to VLAN (which has a limitation of 4K network IDs).
VXLAN is an encapsulation and overlay protocol that runs on
top of existing Underlay networks. VXLAN can have 16
million Network IDs.
Overlay Networking
An overlay network is a virtual, logical network built on top
of an existing network. Overlay networks are often used to
provide useful abstractions on top of existing networks and
to separate and secure different logical networks.
Source Network Address Translation
SNAT refers to a NAT procedure that modifies the source
address of an IP Packet.
Destination Network Address Translation
DNAT refers to a NAT procedure that modifies the
Destination address of an IP Packet.
58

eth0 10.130.1.102
Node / Server 1
172.17.4.1
VSWITCH
172.17.4.1
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
VSWITCH
172.17.5.1
Customer 1
Customer 2
VXLAN Encapsulation
10.130.1.0/24 10.130.2.0/24
Underlay Network
VSWITCH: Virtual Switch
Switch Switch
Router
59

eth0 10.130.1.102
Node / Server 1
172.17.4.1
VSWITCH
VTEP
172.17.4.1
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
VSWITCH
VTEP
172.17.5.1
Customer 1
Customer 2
VXLAN Encapsulation
Overlay Network
VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point
VXLAN encapsulate L2 into UDP
packets tunneling using L3. This
means no specialized hardware
required. So, the Overlay networks
could be created purely in
Software.
VLAN = 4094 (2 reserved) Networks
VNI = 16 Million Networks (24-bit ID)
60

eth0 10.130.1.102
Node / Server 1
172.17.4.1
VSWITCH
VTEP
172.17.4.1
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
VSWITCH
VTEP
172.17.5.1
Customer 1
Customer 2
VXLAN Encapsulation
Overlay Network
ARP Broadcast ARP Broadcast
ARP Broadcast
Multicast
VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point
ARP Unicast
61

eth0 10.130.1.102
Node / Server 1
172.17.4.1
B1 – MAC
VSWITCH
VTEP
172.17.4.1
Y1 – MAC
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
B2 – MAC
VSWITCH
VTEP
172.17.5.1
Y2 – MAC
Customer 1
Customer 2
VXLAN Encapsulation
Overlay Network
Src: 172.17.4.1
Src: B1 – MAC
Dst: 172.17.5.1
Dst: B2 - MAC
Src: 10.130.1.102
Dst: 10.130.2.187
Src UDP Port: Dynamic
Dst UDP Port: 4789
VNI: 100
Src: 172.17.4.1
Src: B1 – MAC
Dst: 172.17.5.1
Dst: B2 - MAC
Src: 172.17.4.1
Src: B1 – MAC
Dst: 172.17.5.1
Dst: B2 - MAC
VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point | VNI : Virtual Network Identifier
62

eth0 10.130.1.102
Node / Server 1
172.17.4.1
B1 – MAC
VSWITCH
VTEP
172.17.4.1
Y1 – MAC
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
B2 – MAC
VSWITCH
VTEP
172.17.5.1
Y2 – MAC
Customer 1
Customer 2
VXLAN Encapsulation
Overlay Network
Src: 10.130.2.187
Dst: 10.130.1.102
Dst UDP Port: 4789
VNI: 100
Src: 172.17.5.1
Src: B2 - MAC
Dst: 172.17.4.1
Dst: B1 – MAC
Src: 172.17.5.1
Src: B2 - MAC
Dst: 172.17.4.1
Dst: B1 – MAC
Src: 172.17.5.1
Src: B2 - MAC
Dst: 172.17.4.1
Dst: B1 – MAC
63

eth0 10.130.1.102
Node / Server 1
172.17.4.1
B1 – MAC
VSWITCH
VTEP
172.17.4.1
Y1 – MAC
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
B2 – MAC
VSWITCH
VTEP
172.17.5.1
Y2 – MAC
Customer 1
Customer 2
VXLAN Encapsulation
Overlay Network
Src: 172.17.4.1
Src: Y1 – MAC
Dst: 172.17.5.1
Dst: Y2 - MAC
Src: 10.130.1.102
Dst: 10.130.2.187
Dst UDP Port: 4789
VNI: 200
Src: 172.17.4.1
Src: Y1 – MAC
Dst: 172.17.5.1
Dst: Y2 - MAC
Src: 172.17.4.1
Src: Y1 – MAC
Dst: 172.17.5.1
Dst: Y2 - MAC
64

eth0 10.130.1.102
Node / Server 1
172.17.4.1
B1 – MAC
VSWITCH
VTEP
172.17.4.1
Y1 – MAC
Customer 1
Customer 2
eth0 10.130.2.187
Node / Server 2
172.17.5.1
B2 – MAC
VSWITCH
VTEP
172.17.5.1
Y2 – MAC
Customer 1
Customer 2
VXLAN Encapsulation
Overlay Network
VNI: 100
VNI: 200
65

GRE: Generic Routing Encapsulation
66
Created By Cisco RFC 2784 & updated by RFC 2890
GRE is used to create a tunnel between 2 network over public network. It can carry any OSI L3 protocol over an
IP Protocol. GRE creates a Point-2-Point connection like VPN by encapsulating the (original) payload.
GRE Tunnels are not secured as the data is un-encrypted. For Secure tunnel use IPSec.
202.1.2.1 204.1.2.1
Public IP Public IP
Branch 1 Branch 2
Internet
192.168.1.1/24 192.168.1.2/24
$ Interface tunnel0
ip address 192.168.1.1
255.255.255.0
ip mtu 1476
ip tcp adjust-mss 1436
tunnel source 202.1.2.1
tunnel destination 204.1.2.1
$ Interface tunnel0
ip address 192.168.1.2
255.255.255.0
ip mtu 1476
VTI VTI
Underlay
New IP Header GRE Header
Original IP
Header
Data
4 – 16 Bytes
20 Bytes
24 – 36 Bytes Overhead
Data (Payload)
Source: RedHat Introduction to Linux IP Tunnels

GRE: Packet Headers & Data Transfer
67
Created By Cisco RFC 2784 & updated by RFC 2890
202.1.2.1 204.1.2.1
Public IP Public IP
Branch 1
Router
Branch 2
Router
172.17.4.1
172.17.4.2
172.17.5.1
172.17.5.2
Internet
192.168.1.1/24 192.168.1.2/24
VTI VTI
Underlay
New IP Header GRE Header
Original IP
Header
Data
Src = 172.17.4.1
Dst = 172.17.5.2
Src = 202.1.2.1
Dst = 204.1.2.1
1. Packet reaches Branch 1 Router
2. New IP Header and GRE Header added
3. Packets Reaches Branch 2 Router
4. New IP Header and GRE Header Removed
LAN LAN
Routes
All traffic to 172.17.5.1/24
will be forwarded
to Tunnel 0 or
192.168.1.1
Route
All traffic to 172.17.4.1/24
will be forwarded to
Tunnel 0 or 192.168.1.2

DM VPN: Dynamic Multipoint VPN
68
o GRE is a Point-2-Point VPN Tunnel.
o DM VPN helps to create VPN to multiple sites.
o It’s a Hub & Spoke Design and yet spoke will
be able to talk to each other.
o Encryption is supported using IPSec.
o Its a great alternative to MPLS VPN.
4 Critical Elements for DM VPN
1. Multipoint GRE
2. NHRP (Next Hop Resolution Protocol)
3. Routing (RIP, EIGRP, OSPF, BGP etc.)
4. IPSec (optional)
Branch 1
B2
B3 B4
Head
Quarter
Branch 1
B2
B3 B4
HQ
Ex. Organization with
1 HQ and 4 branches
Point 2 Point GRE Tunnels
are complex and doesn’t
scale well.
Internet
Requirements
1. All branches linked to HQ
2. Branch B1 & B3 linked
Source: Cisco DM VPN

NHRP: Next Hop Resolution Protocol
69
o It’s a protocol to discover the best path (Next Hop) in a multiple wide area
network with lot of subnets.
o WAN typically blocks broadcast requests and it’s called Non-Broadcast
Multiple Access (NBMA) network.
o NHRP is similar to ARP (Address Resolution Protocol).
o NHRP provides Next Hop Servers (NHSes) to register and provide routing
information to Next Hop Clients (NHCs). NHS is the hub and NHC the spoke.
o Each NHC registers its physical IP and its logical local IP to the NHS.
o When an NHC wants to discover the Route to another NHC it sends the
request to NHS and NHS returns the target NHC details.
NHRP was developed by Internet Engineering Task Force: RFC 2332

Multipoint GRE
70
B1 B2
B3 B4
HQ
Requirements
1. All branches linked to HQ
This is not an ideal Solution as we need to
setup multiple tunnel interfaces at each
router, its messy and not scalable.
In Multipoint GRE, there will be ONLY 1 tunnel interface on
each router & Hub interface don’t have tunnel destination.
B1 B2
B3 B4
Head
Quarter
NHC NHC
NHC NHC
NHS
Hub & Spoke
Topology
B1 B2
B3 B4
Head
Quarter
NHC NHC
NHC NHC
NHS
192.168.1.0/24
NHC registers
with NHS
B1 & B2 sends NHRP
request to NHS to get
the route details
Based on the Route
details dynamic
tunnels are built.
Dynamic
On Demand
Tunnels

DM VPN: Phases
71
Phase 1
All the spokes are registered with the Hub. All traffic goes thru Hub. Each Spoke
uses regular Point-2-Point GRE Tunnel.
Phase 2
Allows Spoke-2-Spoke communication using Multipoint GRE tunnels. Spoke-2-
Spoke tunnels are on-demand based on traffic. Data need not go to the Hub for
communication.
Phase 3
Improves the Phase 2 with NHRP request to create the Spoke-2-Spoke Tunnels on-
Demand. This improves the scalability from Phase 2 where the routes are pre-
defined.
Source: Tech Target: DM VPN:
Phase 1 Phase 2 Phase 3
Key
Feature
Spokes Dynamically
register with Hub
Spoke Communicates
directly with other Spokes
Allows route
summarization
Tunnel
Type
Hub: mGRE
Spoke: GRE
All use mGRE All use mGRE

B1
B2
B3 B4
Head
Quarter
NHC
NHC
NHC NHC
NHS
Dynamic
On Demand
Tunnels
.99
192.168.1.0/24
9.9.9.9
2.2.2.2
1.1.1.1
3.3.3.3 4.4.4.4
LAN
172.99.1.1
LAN
172.4.1.1
LAN
172.3.1.1
LAN
172.2.1.1
LAN
172.1.1.1
1. All branches are connected to HQ
2. Branch B1 & B3 are connected
Specs
$ interface Tunnel0
ip address 192.168.1.99 255.255.255.0
ip mtu 1476
ip nhrp authentication NHRPKEY
ip nhrp network-id 1
tunnel mode gre multipoint
tunnel key 11
Hub Configuration P-2-M
$ interface Tunnel0
ip address 192.168.1.1 255.255.255.0
ip mtu 1476
tunnel key 11
ip nhrp nhs 192.168.1.99
ip nhrp map 192.168.1.99
1.1.1.1
B1 Spoke Configuration P-2-P
DM VPN Phase 1
172.99.1.1 172.4.1.1 Data
Src Dst
172.99.1.1 172.2.1.1 Data
172.3.1.1 172.99.1.1 Data
1
172.1.1.1 172.3.1.1 Data
172.2.1.1 172.4.1.1 Data
2
3
DM VPN: Multipoint GRE
Adjusted for 40-byte GRE Header
Tunnel Source Public (NBMA) IP Address
NHRP Network ID (Domain) – Hub will be NH Server
No Destination is assigned for mGRE
Optional – Used for authentication. If set, is in the
GRE header. It must match for the tunnel to form.
In Phase 1 – Spoke work in GRE mode. So, destination
IP (NBMA) is given of the Hub Router
Next Hop Server is the Hub Router. This needs to
be statically configured
Map the Tunnel to the NBMA IP address (Hub)
$ ip nhrp nhs 192.168.1.99 nbma 1.1.1.1 multicast
Repeat the B1 Spoke Config for other Branches also

B1
B2
B3 B4
Head
Quarter
NHC
NHC
NHC NHC
NHS
Dynamic
On Demand
Tunnels
.99
192.168.1.0/24
9.9.9.9
2.2.2.2
1.1.1.1
3.3.3.3 4.4.4.4
LAN
172.99.1.1
LAN
172.4.1.1
LAN
172.3.1.1
LAN
172.2.1.1
LAN
172.1.1.1
Specs
172.99.1.1 172.4.1.1 Data
Src Dst
172.99.1.1 172.2.1.1 Data
172.3.1.1 172.99.1.1 Data
1
172.1.1.1 172.3.1.1 Data
172.2.1.1 172.4.1.1 Data
2
3
DM VPN: Multipoint GRE
Adjusted for 40-byte GRE Header
Tunnel Source Public (NBMA) IP Address
NHRP Network ID (Domain) – Hub will be NH Server
Statically configured destination for Spoke is gone
mGRE is introduced for Spoke also
Optional – Used for authentication. If set, is in the
GRE header. It must match for the tunnel to form.
Hub informs Spoke about a better route for the spoke
This allows the Spoke to accept the redirect
message and create a short cut route.
DM VPN Phase 2
$ interface Tunnel0
ip address 192.168.1.1 255.255.255.0
ip mtu 1476
tunnel key 11
ip nhrp map multicast
1.1.1.1
B1 Spoke Configuration P-2-M
DM VPN Phase 3
$ interface Tunnel0
ip nhrp shortcut
B1 Spoke Configuration – Routes
$ interface Tunnel0
ip nhrp redirect
Use Hub Config from Phase 1
No Static destination, so manually map the
multicast to NHS

DM VPN: Multipoint GRE – Summary
74
B1
B2
B3 B4
Head
Quarter
NHC
NHC
NHC NHC
NHS
Dynamic
On Demand
Tunnels
.99
192.168.1.0/24
9.9.9.9
2.2.2.2
1.1.1.1
3.3.3.3 4.4.4.4
LAN
172.99.1.1
LAN
172.4.1.1
LAN
172.3.1.1
LAN
172.2.1.1
LAN
172.1.1.1
Specs
$ interface Tunnel0
ip address 192.168.1.99 255.255.255.0
ip mtu 1476
tunnel key 11
$ interface Tunnel0
ip address 192.168.1.1 255.255.255.0
ip mtu 1476
tunnel key 11
ip nhrp nhs 192.168.1.99
ip nhrp map 192.168.1.99 1.1.1.1
B1 Spoke Configuration P-2-P
DM VPN Phase 1 DM VPN Phase 2
$ interface Tunnel0
ip address 192.168.1.1 255.255.255.0
ip mtu 1476
tunnel key 11
ip nhrp map multicast 1.1.1.1
B1 Spoke Configuration P-2-M
DM VPN Phase 3
$ interface Tunnel0
ip nhrp shortcut
B1 Spoke Configuration – Routes
$ interface Tunnel0
ip nhrp redirect
172.99.1.1 172.4.1.1 Data
Src Dst
172.99.1.1 172.2.1.1 Data
172.3.1.1 172.99.1.1 Data
1
172.1.1.1 172.3.1.1 Data
172.2.1.1 172.4.1.1 Data
2
3

IPSec
75
RFC 6071
o Creates an encrypted tunnel over an IP Network
o Authentication and Encryption prevents eavesdropping
and data modification
o GRE can be combined with IPSec to support Multiple
protocols over IP Network
New IP
Header
IPSec
Header
Original IP
Header
Data
50 – 57 Bytes Overhead
IPSec
Trailer
IPSec
Auth Trailer

VRF: Virtual Routing & Forwarding
76
172.17.4.1 172.17.5.1
Internet
Customer A Customer B
Before VRF
ISP
Router
172.17.4.1 172.17.5.1
Internet
Customer A Customer B
After VRF
ISP
Router
VRF-A VRF-B
o It Allows to have multiple instances
of routing table in a Virtual Router.
o VRF increases the security as traffic
is separated.
o Network Path is segmented without
using multiple hardware’s.
o A VRF Instance uses a Single Routing table.
o VRF requires a forwarding table for the
next Hop of the packet.
o Traditional VRF is done on ISP MPLS-VPN
and VRF Lite is without MPLS-VPN.
o VRF uses the same methods of Virtualization as VLANs. They are equivalent to the L3 version of a
TCP/IP Layer of VLAN. VLAN makes a single switch appear as multiple switches while VRF makes a
single Router appear as multiple routers.

MPLS: Multi Protocol Label Switching
77
Jointly developed by Cisco, Ipsilon & IBM in 1996. First working group formed in 1997 and first deployment in 1999.
• MPLS supports transport over IP, Ethernet, asynchronous transfer mode (ATM) and frame relay.
• MPLS allows most data packets to be forwarded at Layer 2 - switching (Data Link) layer of OSI instead of
Layer 3 the routing (Network) Layer.
• MPLS is an alternative to traditional routing based on destination IP address of the packet which requires
each router to inspect packets destination IP address in every hop before consulting its own routing table.
This is a time-consuming process especially for Voice and Video calls.
• First router in the MPLS network will determine the entire route upfront the identity of which is quickly
conveyed to subsequent routers using a label in the packet header.
MPLS labels consist of 4
parts:
1. Label value: 20 bits
2. Experimental: 3 bits
3. Bottom of stack: 1 bit
4. Time to live: 8 bits
Source: Tech Target – Multi Protocol Label Switching
Label Edge
Router
1. Each packet get labelled on
entry by ISPs LER.
2. This router (LER) decides Label
Switch Path (LSP) the path it
will take until it reaches the
destination.
3. All subsequent LSR will forward
the packet based on the Label.

LISP: Location Identifier Separation Protocol
78
LISP creates 2 addresses for each network node:
1. One for its Identity (Endpoint Identifiers – EID).
Assigned to hosts like Computers, Laptops, Printers, etc
2. Second for its Routing Location (RLOC) in the
network. Assigned to routers, use RLOC to reach EIDs.
LISP is a tunnelling Protocol that uses DNS like system to
figure out which router the they should send packets.
Created by Cisco and transferred to IETF – RFC 6830 : https://datatracker.ietf.org/doc/html/rfc6830
Source: Cisco LISP – IP Routing Guide
Internet Routing Tables has grown exponentially high resulting in close to 900K prefixes putting
huge burden on the BGP routers.
• Multihoming: Customers Connect 2 different ISPs and advertise their PI (Provider Independent)
IP Address to both ISPs.
• Traffic Engineering: By advertising Specific Route increases size of the Internet Routing Table.
WHY
3 Environments in a LISP Network
1. LISP Site: EID Namespace
2. Non-LISP Site: RLOC
Namespace where you find
RLOC
3. LISP Mapping Service: EID-to-
RLOC Mapping Service

LISP: Control / Data Plane
79
172.17.4.2 DNS Server
DNS Request
DNS Response
google.com ?
142.250.77.110
LISP
R1
EID: 172.17.5.2 ?
EID: 172.17.5.0/24
RLOC: 204.1.2.1
Map Request
Map Response
• DNS resolves a Hostname
to IP Address
• LISP resolves an EID to
RLOC
LISP Data Plane
LISP Control Plane
Source: https://networklessons.com/cisco/ccnp-encor-350-401/cisco-locator-id-separation-protocol-lisp

LISP: Location Identifier Separation Protocol
80
LISP is a Map and
Encapsulation Protocol
LISP
R1
202.1.2.1
204.1.2.1
172.17.5.0/24 EID
RLOC
202.3.2.1
172.17.4.2
Map Cache
202.1.2.1
172.17.4.0/24 EID
RLOC
Map Cache
172.17.4.2
172.17.5.2
Data
Src
Dst
IP Data
172.17.4.2
172.17.5.2
Data
Src
Dst
IP Data
Where is
EID: 172.17.5.2 ?
EID: 172.17.5.0/24
RLOC: 204.1.2.1
R2
204.1.2.1
New IP Header LISP Header Original IP Header Data
Src: 202.1.2.1
Dst: 204.1.2.1
Src: 172.17.4.2
Dst: 172.17.5.2
204.1.2.1
172.17.5.0/24 EID
RLOC
Map Database
1
2
3
4 5
6
RLOC
Space
LISP Site 1
172.17.5.2
LISP Site 2
Host 1 Host 2
ITR ETR
Router R1 = Ingres Tunneling Router
Router R2 = Egress Tunneling Router
LISP Stores all the EID-RLOC Maps
1. Host 1 sends data to Host 2 thru
R1
2. R1 Router Sends Map Request to
LISP Server with EID
3. LISP Server Responds with RLOC
4. R1 encapsulates the Packet with
R1 Source and R2 Destination
5. R2 Router receives the LISP
encapsulated packet and de-
encapsulate
6. R2 Send the Original Packet to
Host 2

Software Defined Network
81
Challenges
1. Explosion of Devices
2. Cost of Human Error
3. Lack of Visibility
4. Security Challenges
1. Central Intelligence
2. Intent Based Networking
Control
Plane
Data
Plane
Tradition Router has both
Control and Data Planes
Data Plane:
Responsible for Packet Forwarding
Control Plane:
Responsible for Device Network
Communication and How to
forward packets
Control Plane
Central Intelligence
Control Plane moved out and
router contains only the Data Plane
Forwarding Rules Packet Forwarding
2 Fundamental Tenets of SDN
Control
Plane
Application
Plane
Data
Plane
Southbound APIs
Northbound APIs
Security
Network OS
QoS
MPLS…
Routing
SDN Architecture

SDN Architecture
Software Defined Network
82
Control
Plane
Management
Plane
Data
Plane
Southbound APIs
Northbound APIs
Security
Controller
QoS
MPLS…
Routing
• OpenFlow
• SNMP
• NetConf
RESTful or Java APIs
Business Applications
Network Elements
Controller
Application
Layer
Control
Layer
Infrastructure
Layer
East – West APIs
Multiple Controllers to avoid
Single Point of Failure
vRouter vSwitch vFirewall SDN Appliance – vEdge.
vController
vManage

Benefits of the SDN Controller
83
1. Virtualization
1. Virtualizes the Network
2. Separate the Network Function from
the hardware – (NFV) Network
Function Virtualization
3. VNF = Virtual Network Functions
vRouter vSwitch vFirewall
Cisco SD-WAN vEdge 1000 Router
2. Automation
1. ZTP = Zero Touch Provisioning
2. Use Template to automatically
deploy the hardware into your
network
3. Visibility
1. Single Controller to see the
entire network
2. Configure and Monitor from a
Single Glass of Pane

SDN – Use Cases
84
• SD-DC Software Defined Data
Center
• SD-WAN Software Defined WAN
• SD-LAN Software Defined LAN
• SDX Software Defined X

Software Defined – WAN
85
Uses a combination of technologies
to create the next generation WAN
• Encrypted Tunnels: IPSec /
GRE
• Routing Protocols: OSPF and
BGP, MPLS
• Supports various Network
Topologies
Features
1. Transport
Independent
2. Cloud Friendly
3. Simple and
Secure

Software Defined – WAN: Architecture
86
New York
SD-WAN Edge
Appliance
San Jose
SD-WAN Edge
Appliance
Internet
MPLS
SD-WAN
Fabric
1 Gb DIA
100 M MPLS
SD-WAN Controller
Cloud Hosted / On-Premise
100 M MPLS
1 Gb DIA
Circuits
Underlay
IP, MPLS, 4G/5G…
Overlay
Tunnels
Benefits of SD-WAN
1. Active-Active Design
Some vendors support up
to 8 active connections
1. Intelligent Traffic Routing
2. Better User Experience

Software Defined – WAN: Zero Touch Provisioning
87
New York
SD-WAN Edge
Appliance
Internet
MPLS
SD-WAN
Fabric
1 Gb DIA
SD-WAN Controller
100 M MPLS
Circuits
Underlay
IP, MPLS, 4G/5G…
1 Unbox & Connect
to the network
2
SD-WAN Appliance
Calls Home to talk
the controller
3
SD-WAN Controller
pushes the configuration
to the SD-WAN
Appliance
4
SD-WAN Appliance
joins the SD-WAN
Fabric

Software Defined – WAN: Security
88
New York
SD-WAN Edge
Appliance SD-WAN
Fabric
SD-WAN Controller
1
Localized Security Policy
to handle a specific
Branch Specs
2
Centralized Security Deployed
Through Service Chaining By
Redirecting Internet Traffic To
a Cloud Firewall or Secure
Web Gateway
3
Consistent Security Policy
regardless of Local or a
Central Security Policy

Public
WAN
Private
WAN Software Defined – WAN: Private / Public
89
New York
SD-WAN Edge
Appliance
San Jose
SD-WAN Edge
Appliance
Layer 1 – Dark Fiber Circuit
Layer 2 – Virtual Private LAN Service - Circuit
Layer 3 – Multi Protocol Label Switching- Circuit
MPLS
VPLS
Layer 3 – Dedicated Internet Access Circuit
Layer 3 – Broadband (DSL/Cable/4G/5G) Circuit Shared
Source: Juniper: Understand the VPLS
Source: Juniper: Understanding MPLS VPN Circuits

Modern WAN Architecture: SD-WAN
Software Defined – WAN: Cloud Friendly
90
Traditional / Legacy WAN Architecture
MPLS
Branches
Users Data Center
Users
DIA /
Broadband
MPLS
Branches
Data Center
SaaS
Multi
Cloud
Internet
Internet
Choke Point

Software Defined – WAN: Benefits
91
1. Create a Secure and Open Network than a closed
one.
2. Utilizes all your Bandwidth (across multiple
providers / protocols) instead of master / slave
3. Support smooth transition Cloud Native Apps
(cloud Workloads)
4. Simplified Management using Single Glass of Pane
5. Consolidate Edge Appliances, rather than dedicated
appliances from different vendor.

Software Defined – WAN: Summary
92
A Cloud
Delivered,
Centralized,
Single Solution
for Management
of Configurations
for WAN, Cloud &
Security with low
Cost.
Single Pane of Glass – SPoG: Cisco SD-WAN Dashboard

Security
Cloud Security Architecture
93

Hype cycle
of Security
Operations
for 2021
94

SANS Cloud Security Architecture Principles
95
Think
Components
Design for
Failure
Always
Think of
Feedback Loops
Use Different
Storages
Options
Built-In
Security
at every Layer
CENTRALIZATION
Focus on
Centralization
Design for
Elasticity

Built-In Security At Every Layer
96
Built-In
Security
at every Layer
• Cloud Architecture is composed of Multiple
Layers. From a Cloud Native App perspective
Each Microservice is specific layer in the
Application Stack.
• Each Layer must be self defending.
• Each Layer Must have a Security Layer to be part
of Defense in Depth.
• Depends on the Security Guidelines / Policies
some of the security measures will be internal
some external.

97
Stack Layer Controls
1 Data
Backup, Data Leak Prevention, Encryption in Transit
and Rest.
2
Application Logic +
Presentation
Web App Firewall, Secure Web Gateway, Identity &
Access Management, Scans / Pen Tests, Service Mesh
Policies
3 Network
Access Controls, Firewalls, Service Mesh, Routing,
DDoS Defense
4 Operating Systems
Backups, Configuration, Vulnerability Scanning, User /
Privilege Management
5 Hypervisor
Configuration, Access Controls, User / Privilege
Management
Built-In
Security
at every Layer

98
Built-In
Security
at every Layer
o Cloud introduced very frequent changes to the environment
(Infrastructure / Software)
o Security Measures must be embedded for these Rapid changes.
1. Defining Security in the Code (Functional Code, Security
Policies)
2. Include Security Configuration Params for the Container /
Virtual Machines
3. Automating Security Processes & Activities
4. Building Continuously Monitored Environments
o Many of these are realized through Sound DevSecOps Practices.

Think ”Components”
99
Think
Components
o From Systems to Component based thinking is a Major shift
for Security Professionals
o Cloud is more oriented towards component-based model
and linked together based on Business requirements
o Key aspects of Component is – Reusability
o Network Policies
o Security Policies
 The above can be applied across multiple clouds
 Ex. Terraform, Kubernetes, Service Mesh

Design for Failure
100
Design for
Failure
o In the Cloud Failure is common
o Elasticity Issues
o Configuration Issues
o Cloud Provider Issues
o Chaos Engineering plays a big Role in Preparing for this
o Product ion – Network Testing
o Production – Security Testing
o Production – Performance Testing
Minimize
Blast Radius
Chaos Engineering
Principle

Design for Elasticity
101
o Microservices, Containers and Kubernetes brought automated dynamic
scaling up and down of the systems (containers)
o This is a new environment from Security Perspective compared with old
Static environment (Changes are periodic and planned).
o Designing Elasticity from Security Perspective
o Vertical or Horizontal Scaling
o What thresholds are appropriate for scaling up & down
o How will inventory management adjust to system volume changes
o Images new systems are spawned from
o Where are new systems located in the network
o Host Based Security + Licensing
Design for
Elasticity

Make use of Different Storage Options
102
Use Different
Storages
Options
o There are many types of Storage options available in Cloud and
each has its own security features.
o Design the Data Security based on the storage options.
o Things to consider and evaluate
o Storage have appropriate SLA
o Storage options for Dev and Ops
o Storage have adequate Redundancy & Archival
o Storage have native encryption capabilities
o Storage have adequate logging and event generation

Always think of Feedback Loops
103
o One of the most critical Principle is Feedback Loops
o One of the critical aspect of Feedback loops is Logging
o Enable Logging everywhere you can
o Within the entire cloud environment (Cloud Trail –Azure,
Cloud Watch – AWS, Stack Driver – Google)
o OS Types, Network Platforms
o For All Identity & Access Management
o For all Interconnected services and their activity
o Feedback Loops = Logging
o Secure Log Access
Always
Think of
Feedback Loops

Focus on Centralization, Standards, Automation
104
o Centralization – Having a Single Glass of Pane to see all the things
happening in the cloud.
o Using the Same vendor Products across all the environments (Cloud,
On-Premise) – If Possible
o Standardization – Go with well known standards
o SAML and OpenID – Connect for IAM
o YAML for Configs / Infra as Code
o AES-256+ for Crypto
o Automation – Is the Key for DevOps and DevSecOps. Manual efforts
are doomed to fail due to rapid changes.
CENTRALIZATION
Focus on
Centralization

Blast Radius
105
o One of the Core Security Concepts in the world of DevOps & Cloud
Computing is the Blast Radius
o It’s the amount of damage that could be caused if something goes
wrong
o An Account or Server gets hacked
o A Component Fails
o Design the Security Model in such a way that the damage is limited
to that area or Service.
o In Microservices architecture link this concept with Circuit Breakers,
Bulkhead Design Patterns.

Security
o 802.1x EAP Security
o Port Knocking & SPA – Single Packet Authorization
o Micro Segmentation / Software Defined Firewall
o Zero Trust and VPNs
o Service Mesh
106

IEEE 802.1x Wired / Wireless
107
Source: What is 802.1X? How Does it Work? https://www.securew2.com/solutions/802-1x
https://standards.ieee.org/ieee/802.1X/7345/
• 802.1X is an authentication protocol to allow access to networks with the use of a RADIUS server.
• 802.1X and RADIUS based security is considered the gold standard to secure wireless and wired networks.
An 802.1X network is different from home networks in one major way;
1. it has an authentication server called a RADIUS Server.
2. It checks a user's credentials to see if they are an active member of the organization &
3. depending on the network policies, grants users varying levels of access to the network.
This allows unique credentials or certificates to be used per user, eliminating the reliance
on a single network password that can be easily stolen

802.1x EAP Security
108
• Standard Authentication protocol used on encrypted networks is Extensible Authentication Protocol (EAP).
• 802.1X is the standard that is used for passing EAP over wired and wireless Local Area Networks (LAN).
• It provides an encrypted EAP tunnel that prevents outside users from intercepting information.
The EAP protocol can be configured
1. Credential (EAP-TTLS/PAP and PEAP-MSCHAPv2) and
2. Digital Certificate (EAP-TLS) authentication and is a highly secure method for protecting the authentication
process.
Source: What is 802.1X? How Does it Work? https://www.securew2.com/solutions/802-1x
802.1X only includes 4
major components:
1. Client
2. Access-point/switch
3. RADIUS Server
4. Identity provider

Port Knocking
109
• Port knocking is a simple method to grant remote access without leaving a port
constantly open.
• In the following config of KnockD – the Port (8888) will be open for 10 seconds
based on the correct sequence of access on ports – 7000, 8000, 9000.
Source: Ubuntu Port Knocking Manual: https://help.ubuntu.com/community/PortKnocking
Security by Obscurity

32 Bit
64 Bit
32 Bit
Single Packet Authorization
110
UID OTP
Counter GMAC
128 Bit
SPA = UID, CTR OTP, GMAC
UID Universal ID of SDP Client
CTR Hashed with seed to Create OTP
OTP One Time Password: HTOP
GMAC Signature of UID, CTR, OTP
Seed Shared Secret for OTP
Encryption
Key
Shared Key for GMAC
(AES-256)
OTP HMAC [Seed + CTR]
GMAC E-Key [UID + OTP + CTR]
CTR
Is incremented to mitigate
playback attacks
= 256
SPA addresses all the limitations of Port Knocking
By Default, SPA Gateway Drops All the Packets
1. Client Sends a SPA Packet
2. Gateway Receives the Packet and Decrypts Packet
3. Validates the Credentials based on protocol / port
4. If Valid, then Adds a Firewall rule to open an mTLS
Connection
5. Once the Connection is established the Gateway
removes the firewall rule making the service go Dark
Again.
o The established mTLS session will not be affected by
removing the firewall rule.

Single Packet Authorization: Benefits
111
 SPA Blackens the Gateway and all the services Behind
the Gateway are invisible to the world.
 SPA also mitigates DDoS attacks on TLS. SDP Gateway
discards the TLS DoS attack before it gets into the
handshake.
 The First packet to the Gateway must be a SPA
Packet. Any other packet will be viewed as an Attack
this helps in attack detection.
Source: https://network-insight.net/2019/06/zero-trust-single-packet-authorization-passive-authorization/

Zero Trust: Micro Segmentation
112
Source: Cisco: What is Micro Segmentation?
How does it work?
• Secures App by allowing specific Application Traffic and Deny All other Traffic
• Micro Segmentation is the foundation of Zero Trust Security Model
Challenges in Implementing Micro Segmentation
• Implement Granular Firewall Policy using Host workload Firewall
• Policy Life Cycle Management
• Begin at Macro Level and refine using Policy Automation
Why can’t Classic Firewalls do the job?
• Granular East-West Policy Controls provides Workload Perimeter
• Implemented at Workload Level
• Scalable across workloads
• Enhances the visibility and control from workload perspective

Zero Trust: Micro Segmentation: Benefits
113
Source: Cisco: What is Micro Segmentation?
Reduce Attack Surface
Uses an allow-list model to significantly reduce this attack surface across different
workload types and environments.
Protect Critical Applications
Gain better threat visibility and enforcement for critical workloads and applications
across different platforms and environments, limiting lateral movement of a
security incident from one compromised VM, service, or container to another.
Achieve Regulatory Compliance
Granular visibility and control over sensitive workloads demonstrate proper
security and data separation to simplify audits and document compliance.

Software Defined Firewall: Network / Micro Segmentation
114
Network Segmentation using Software Defined Firewall Micro Segmentation using Software Defined Firewall
Source: https://www.vmware.com/topics/glossary/content/network-segmentation.html

Traditional VPN Vs. Zero Trust
115
Enterprise
VPN
User System
VPN
Client
User
App
VPN
Server IAM
WAN
WAN
Split
Tunnel
Optional
Relies on Shared secret
and/or Shared root of Trust
If Split tunneling is enabled
only traffic to Enterprise
will be tunneled.
Zero Trust
User System
Agent
PEP
User
App
PEP
Encrypted Tunnel
Normal Traffic
LAN
IAM
PDP
PEP PEP
• Dynamically adjust the Context
• Multiple Entry Points
• Support Remote and On Premise
Resource
Resource Resource
Resource

Zero Trust – Security: Resource Based
116
Device
Agent
PEP
ZT Aware
Network IDS/IPS
Control Plane
Data Plane
User
App
PEP
Gateway
Source: Page 183: Zero Trust Security: An Enterprise Guide by Jason Garbis, Jerry W Chapman
Resource Based
Deployment
Model
Encrypted Tunnel
Data
Implicit Trust Zone
Zero Trust will bring changes to
network segmentation and
network traffic encryption
patterns.
Resource
Host IDS/IPS
Host IDS/IPS
ZT Aware
IDS/IPS

Zero Trust – Security: Enclave Based
117
Device
Agent
PEP
ZT Aware
Network IDS/IPS
Control Plane
Data Plane
User
App
PEP
Gateway
Enclave Based
Deployment
Model
Encrypted Tunnel
Data
Implicit Trust Zone
Zero Trust will bring changes to
network segmentation and
network traffic encryption
patterns.
Resource Enclave
Host IDS/IPS
ZT Aware
IDS/IPS
Host IDS/IPS
Host IDS/IPS
NIDPS

Zero Trust – Security: Cloud Routed
118
Device
PEP
Control
Plane
Data
Plane
User
App
Cloud Routed
Deployment
Model
PEP
Subject
ZT Aware
Network IDS/IPS
Agent
PEP
Host IDS/IPS
PEP
Gateway
Resource Enclave
Host IDS/IPS
Host IDS/IPS
NIDPS
Encrypted Tunnel
Data
Implicit Trust Zone

Zero Trust – Security: Micro Segmentation
119
Micro Segmentation
Deployment
Model
PEP
Subject Resource
Host IDS/IPS
PEP
Subject Resource
Host IDS/IPS
ZT Aware
Network IDS/IPS

Secure Web Gateway
120
Content Filtering
Filter Content by specific URL or category to ensure internet access is based
on corporate policies.
Scan Docs Scan all the uploaded and downloaded files for malware and other threats.
File Types Block Files based on File Types Example .exe files.
App Controls
User access to Web Apps are controlled. For example, Uploading fille to Drop
Box, Google Drive etc. Attaching file to Gmail and Posting to Social Media
sites.
Metrics
Detailed Reporting on User, Device, URLs accessed, network Identity and
Allow or Block Actions.

Cloud Access Security Broker (CASB)
121
o CASB is the bridge between Cloud
Service Consumers and Cloud
Service Providers to combine and
interject enterprise security Policies
as the cloud-based resources are
consumed.
o They combine multiple types of
Security Policy Enforcement
Systems like Authentication, Single
Sign-On, Authorization, Credential
Mapping, Device Profiling,
Encryption, Tokenization, Malware
detection / prevention etc.
Visibility Compliance
Threat
Prevention
Data
Security
Source: Garnet CASB Definition

Service Mesh: Istio Security
Source: https://istio.io/docs/concepts/security/
It provide strong identity, powerful policy, transparent TLS encryption, and authentication,
authorization and audit (AAA) tools to protect your services and data. The goals of Istio
security are
• Security by default: no changes
needed for application code
and infrastructure
• Defense in Depth: integrate
with existing security systems to
provide multiple layers of
Defense
• Zero-trust network: build
security solutions on untrusted
networks
122

Service Mesh: Istio Security Architecture
Source: https://istio.io/latest/docs/concepts/security/
123

Service Mesh: Micro Segmentation
124
Source: Istio: Micro-Segmentation with Istio Authorization https://istio.io/latest/blog/2018/istio-authorization/
• Authorization at different levels of granularity, including
namespace level, service level, and method level.
• Service-to-service and end-user-to-service authorization.
• High performance, as it is enforced natively on Envoy.
• Role-based semantics, which makes it easy to use.
• High flexibility as it allows users to define conditions
using combinations of attributes.

3
Cisco
SASE / Zero Trust
o Cisco Software Defined – WAN
o Cisco Software Defined – Access
o Cisco Secure Cloud Insights
125
o Understand Cisco Umbrella
o Understand Cisco DNA
o Understand Cisco SD-WAN
o Understand Cisco SD-
Access
o Understand Jupiter One
Objectives

Cisco
Umbrella

Cisco Viptela
SD-WAN
o Architecture
o Controllers
o Overlay Management Protocol
o Zero Touch Provisioning
o Transport Tunnels & Topologies
o Traffic Routing
o Bootup Sequence
127
Cisco SD-WAN Solution
represents an evolution of
networking from an older,
hardware-based model to a
secure, software-based, virtual
IP fabric. Cisco SD-WAN fabric,
also called an overlay network,
forms a software overlay that
runs over standard network
transport services, including
the public Internet, MPLS, and
broadband.
Source: Cisco SD-WAN Getting started Guide. Page 5

Mana
SD-WAN
Edge
Appliances
Routers
MPLS
DIA
DSL
4G/5G
Branch Remote Data Center Branch Cloud Branch
• Zero Touch Provisioning
• On-Premise or Cloud
• Physical or Virtual
Data Plane
vSmart Controllers
• Routing and Security Policies
• Horizontal Scaling
Control Plane
vManage
• Single Pane of Glass
• RBAC and APIs
• Monitoring / Troubleshooting
Management Plane
Cisco
SD-WAN
(Viptela)
Architecture
vEdge
vEdge
vAnalytics
• Carrier Performance
• Bandwidth Forecasting
• Machine Learning
Analytics Plane
SD-WAN
Fabric
vEdge Cloud
Overlay
Network
Source: Cisco SD-WAN
Getting Started Guide
Cloud /
On-Premise
vBond

Cisco
SD-WAN:
Features
129
Source:
Cisco SD-WAN Getting
Started Page 14

OMP – Overlay Management Protocol
130
o OMP Provides Centralized Control
1. Orchestration of
1. Routing & Secure Connectivity between Sites
2. Service Chaining like Firewalls, Routers
3. VPN Topologies
2. Distribution of
1. Traffic Routing Rules
2. Security Policies
3. Security
1. Establishes Secure Connection between vSmart to
vSmart, vSmart to vEdge
2. Uses DTLS (UDP), AES 256 Key Encryption
o Three Types of OMP Routes
1. OMP Routes (vRoutes)
2. TLOC: Transport Location (ties to a Physical Location)
3. Service Routes (Firewalls, IDS, etc.) vEdge vEdge
vSmart vSmart
vSmart
Patent: Overlay Management Protocol for Secure Routing based on an Overlay Network
Source: SD-WAN OMP

Cisco SD-WAN Controllers
131
vSmart
vManage
vBond
vManage Cisco vManage is a centralized network management
system that lets you configure and manage the entire
overlay network from a simple graphical dashboard.
vSmart & vBond
talks to vManage
vSmart The Cisco vSmart Controller is the centralized brain of
the Cisco SD-WAN solution, controlling the flow of data
traffic throughout the network. The vSmart works with
the vBond Orchestrator to authenticate vEdge devices as
they join the network and to orchestrate connectivity
among the edge routers.
Read this article to setup Cisco
SD-WAN: Basic Configuration Lab
by Jedadiah Casey
Source: Cisco SD-WAN Getting Started Page 13
vBond The Cisco vBond Orchestrator automatically orchestrates
connectivity between edge routers and vSmart.
Controllers. If any edge router or Cisco vSmart Controller
is behind a NAT, the Cisco vBond Orchestrator also
serves as an initial NAT-traversal orchestrator.

Cisco SD-WAN Components
132
vSmart
vManage
vBond
vAnalytics Cisco vAnalytics platform is a SaaS service hosted by
Cisco SD-WAN as part of the solution. vAnalytics
platform provides graphical representations of the
performance of your entire overlay network over
time and lets you drill down to the characteristics of
a single carrier, tunnel, or application at a particular
time.
Read this article to setup Cisco SD-WAN: Basic Configuration Lab by Jedadiah Casey
Source: Cisco SD-WAN Getting Started Page 13, 18
The edge routers sit at the perimeter of a site (such
as remote offices, branches, campuses, data centres)
and provide connectivity among the sites. They are
either hardware devices or software (Cloud router),
that runs as a virtual machine. The edge routers
handle the transmission of data traffic.
vEdge
vAnalytics
vEdge Routers

Cisco SD-WAN Controllers Deployment Models
133
Source: Cisco SD-WAN Getting Started
vSmart
vManage
vBond
On - Premise
Private
Cloud
Cisco
Cloud
Preferred Deployment Model
Cloud Delivered

Cisco SD-WAN Zero Touch Provisioning
134
Send New Router
(vEdge) Details
DTLS
DTLS
vBond
vSmart
vEdge
vManage
Send IP
Addresses
of vManage
& vSmart
to vEdge
Authentication
DTLS /
TLS
Authentication
vEdge
vManage
Send Full
Configuration
file for vEdge
1 2
Authentication
vSmart
OMP Session Established
between vEdge & vSmart
to exchange routes
3
vEdge
Authentication
vEdge
BFD Session Established.
Helps to quickly switch
over when a path fails
4
vEdge
vBond Checks.
Digital Certificate
and Serial No.
Reject if it
Doesn’t
Match.
Bidirectional
Forwarding
Detection
Source:
Cisco
SD-WAN
Getting
Started
Page
28

SD-WAN Transport Tunnels & Topologies
135
Mana
Mana
Full Mesh
Mana
Partial Mesh
Mana
Hub & Spoke
Mana
Point 2 Point
MPLS
DIA
DSL
4G/5G
vSmart
vEdge vEdge
OMP Route
tables
Site 1 Site 2
o No Reliance on Underlay Transport
o Each VPN can have a separate topology
o vEdge Routers maintain per VPN routing info.
Overlay VPNs
Single Tunnel Per Transport
Source: Intro to Cisco SD-WAN | Viptela

Edge Router: Traffic Routing
136
MPLS
DIA
Source: Intro to Cisco SD-WAN | Viptela
Active / Active
Load Sharing Per Session
(Default)
vEdge
MPLS
DIA
Active / Active
Weighted Per Session
vEdge
MPLS
DIA
Active / Standby
Application Pinning
vEdge
Ex. Voice App
MPLS
DIA
Active / Standby
Application Aware Routing
(Policy Enforced)
vEdge
SLA SLA

SD-WAN: Key Attributes
137
Source: Cisco SD-WAN Getting Started Page 24 - 25
vSmart
vEdge - 1 vEdge - 2
Router 1
IPSec
Domain ID: 1
Site ID: 1
System IP: 10.0.0.1
Domain ID: 1
Site ID: 100
System IP: 1.0.0.100
Domain ID: 1
Site ID: 200
System IP: 2.0.0.200
Domain ID
• Logical grouping of Edge Routers and vSmart Controllers
• Each Domain is identified by a unique Integer
• Currently only 1 Domain is allowed in an Overlay network
• vBond Orchestrator is not part of a Domain
Site ID
• Physical Location of an Edge Router within an Overlay Network
• Each Site ID is a Unique Integer
• If a Site contain 2 Edge Routers (for Backup) the 2nd one will have
the same Site ID
System IP Address
• Each Edge Router and vSmart is assigned with an IP
Address which identifies the physical system
independent of interfaces.
• Similar to Router ID on a regular Router
• Permanent network Overlay Address
TLOC
• Identifies the physical interface where a edge router connects to
the WAN transport network or to a NAT gateway

Cisco SD-WAN: Boot Sequence
138
Source: Cisco SD-WAN Getting Started Page 95
vSmart
vManage vEdge
vBond
OFF ON
OFF ON
OFF ON
OFF ON
1
2
3
4
4.1 4.2
4.3
Authenticate
Sends Config
6
5.1
5.2
Start
Start
Start
Start
7 Authenticate
Sends Config
7.1
7.2
7.3

Cisco SD-WAN Summary
139
o Utilization of multiple underlay transport protocols at the
same time.
o Single Window into the Entire Network Fabric for
Management and Monitoring.
o Low-Cost solution with Bandwidth forecasting and Carrier
Performance
o Zero Touch Provisioning
o Separation of Data Plane and Control Plane and virtualizing
the routing instead of dedicated hardware.

Cisco SD-Access / Zero Trust
o Cisco DNA
o Cisco ISE
o Cisco SD – Access
140

Cisco DNA Center
o Concept
o Architecture
141

Cisco DNA Platform
142
Source: Cisco DNA Assurance – Page 23

Cisco DNA Center Platform
143
Automation:
o To transform the network Admin’s Business Intent into device
specific Network Configs.
o Consists of Network Info Database, Policy Engines & Network
Programmer
o Controller has the ability to discover the network
infrastructure and periodically scan the network to Create a
Single Source of Truth.
o Policy Engine Provisions various Policies across the enterprise
network
o It also provides topology Info that maps network devices to
physical topology and detailed devices data.
Analytics & Assurance
o Built-in Data Collector Framework. Network Infrastructure data
obtained via streaming telemetry mechanisms. It also collects
data from contextual systems like Cisco ISE, IPAM, ITSM etc.
o Data is processed in real-time using time-series analysis,
Complex Event Processing and Machine Learning Algorithms.
o Output is stored and visualized using DNA Center UI.
Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 112
Policy:
o Define and Deploy Network wide Policies
End-2-End.
o Policies like QoS, Security Policies, Policies
on Metrics etc.

Cisco DNA Center Overview
144
Digital Network Architecture
• Using Intuitive workflows
• Import Existing Designs
• User Access
Design
• User & Device Profiles
• Virtual Networks
• ISE, AAA, Radius
• Group Policies
Policy
• Zero Touch Provisioning
• Policy Based Automation
• Provisions Network Elements
to send NetFlow Data
Provision
• Network health
• Fabric Health
• 3600 View
• Path Trace, Sensor
Assurance
Source: Cisco DNA 2.2.3.0 Cisco DNA – Plan, Design & Implement Services

Cisco DNA: Intent Based Networking
145
Source: Cisco DNA Assurance – Page 24

Cisco DNA Architecture
146
Source: Cisco DNA Center 2.2.3.0 Data Sheet Nov 17 2021

Cisco ISE – Identity Services Engine
147

Cisco ISE: How ISE enforces Zero Trust
148
Connecting trusted users and endpoints with trusted resources
Endpoint Request Access
• Endpoint is identified and trust is
established
• Posture of endpoint verified to meet
compliance
1
Endpoint authorized access based
on least privilege
• Access Granted
• Network segmentation
achieved
3
Endpoint classified, and profiled into
groups
• Endpoints are tagged w/SGTs
• Policy applied to profiled groups
based on least privilege
2
Trust continually verified
• Continually monitors and verifies
endpoint trust level
• Vulnerability assessments to identify
indicators of compromise
• Automatically Updates access policy
4
Source: Cisco – Implement Zero Trust and regain Control with Cisco Identity Services Engine

Cisco SD-Access
o Concept
o Automation Benefits
o SD-Access Layers
o Architecture
149

Cisco: SD-Access: Zero Trust
150
Source: Cisco Software-Defined Access for Zero-Trust Workplace At-a-Glance

Cisco: Software Defined Access
151
Why Cisco SD-Access for Zero-Trust Workplace?
• Identify and verify all endpoints and users, including IoT
endpoints, that connect to your network
• Establish policy and segmentation to help ensure least
privilege access based on endpoint and user type
• Continually monitor endpoint behaviour, including
encrypted traffic, to help ensure compliance
• Stop threat propagation, including ransomware, by
quarantining any endpoint that exhibits malicious or out-of-
compliance behaviour
Source: Cisco Software-Defined Access for Zero-Trust Workplace At-a-Glance

Cisco SD-Access
152
o Software- Defined Ac cess is the industry’s first intent- based net working.
o An intent- based network treats the network as a single system that provides
the translation and validation of the business intent (or goals) into the network
and returns actionable insights.

Cisco SD-Access: Automation
153

Cisco SD-Access Layers
154
SDA Fabric Physical and logical network for warding infrastructure
DNA Center
Automation, Policy, Assurance and Integration
Infrastructure
Digital Network Architecture
o Cisco’s SD-Access solution is a programmable network architecture that
provides software-based policy and segmentation from the edge of the
network to the applications.
o SD-Access is implemented via Cisco Digital Network Architecture Center (Cisco
DNA Center) which provides design settings, policy definition and automated
provisioning of the network elements, as well as assurance analytics for an
intelligent wired and wire less net work.

Cisco SD-Access Fabric
155
An SD-Access network underlay is comprised of the physical network devices, such as routers,
switches, and wireless LAN controllers (WLCs) plus a traditional Layer 3 routing protocol.
SD-Access Fabric Overlay has 3 Components
Fabric Data Plane
Logical Overlay is created by using VXLAN.
Fabric Control Plane
Logical Mapping & resolving of users and devices (associated with
VXLAN) is performed by Locator/ID Separation Protocol (LISP)
Fabric Policy Plane
Where the Business Intent is translated into a network Policy using
Address-Agnostic Scalable Group Tags (SGT) and group-based policies.

Cisco SD-Access Architecture Overview
156
Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 36, 50
DNA – Digital Network Architecture
• Automation: Intent Based Automation for
wired and wireless Fabric Devices / users
• Assurance: Collectors Analyze Endpoint to
Application flows and monitor Fabric Device Status.
• Policy: Based on Cisco ISE for Dynamic
Endpoint to Group Mapping & Policy definition
• Control Plane: Central DB to track all
users & devices attached to Fabric.
• Border: Connects the traditional L2,
L3 Networks to the SD-Access Fabric
• Fabric Edge: Responsible to
connecting endpoints to the Fabric
& operates at the perimeter and 1st
point of attachment of users and
implementation of policy.
• WLC: Connects the APs and wireless
Endpoints to the SD-Access Fabric

Cisco SD-Access : Wireless Deployment
157

Cisco SD-Access: Multi Site Fabric
158

Cisco SD-Access: Transit
159

Cisco SD-Access: SD-WAN Transit
160

Cisco SD-Access: MPLS VPN
161

Cisco SD-Access: VRF-Lite over DM VPN
162

Cisco SD-Access: Policy Enforcement
163

Cisco SDA: User Access based on Group Policy
164

Cisco SD-Access: Benefits
165

Comparison
o Cisco Viptela SD-WAN
o VMWare VeloCloud
o Silver Peak
166

Gartner
Magic
Quadrant
2021
SD-WAN
167

Cisco: Secure Cloud Insights
o Apps / Policies / Alerts / Compliance
o Graph Viewer / Insights / Query Library
o JupiterOne Query Language
o JupiterOne Platform
168

Cisco Secure Cloud Insights – Eye in the Sky
169
While SecOps starts on the left with security posture and attack surface
management as its entry point, DevOps start at the far right with
continuous integration and continuous delivery (CI/CD) pipeline and
application/API security as their main care about.
As SecOps moves right and begins to influence the other
stakeholders within a mature organization, DevOps shifts
left to include pre-deploy checks by using runtime security
inputs.

Cisco SecureX & Secure Cloud Insights
170
o Integrated Secure Cloud
Insights with Cisco’s security
platform SecureX and intend
to have it play a bigger role
as a context wrapper for
numerous other Cisco
security services.
o While Secure Cloud Insights
connects the dots, Secure
Cloud Analytics baselines
behaviour by analysing
traffic flowing between
those dots.

Cisco Secure Cloud Insights
171
Source: Cisco Secure Cloud Insights
Benefits
o Gain complete visibility and
understanding of your cloud security
posture across multiple clouds
o Continuously monitor cloud
environments to detect policy violations
or misconfigurations
o Understand your entire attack surface by
mapping relationships between assets
o Quickly investigate and remediate
impacted assets by pinpointing your
blast radius

Secure Cloud Insights: Apps
172
Assets
o Gives the Complete Inventory of your
Assets.
o You can analyze and visualize your
assets.
o It also gives you the type and class of
the assets and its relationships.
Source: Cisco Secure Cloud Insights Getting Started Guide Page 5

Secure Cloud Insights: Policies
173
Policies
o Helps you to articulate your organization
Policies.
o And associate them to your compliance
requirements.
o Each Policy and Procedure is written down
in its own Markup file.
o And the policies can be linked together.
o Policy Templates are open source.
o 120+ Policy and Procedure Templates are
available.

Secure Cloud Insights: Alerts
174
Alerts
o Alerts can be created using any Query
for Continuous Auditing and Threat
Monitoring.
o You must have at least one Active Rule
to create an Alert.
o You can import rules from Rule Pack
o You can create Custom Rules

Secure Cloud Insights: Compliance
175
Manage any Compliance standards or
frameworks as a set of Controls or
requirements
o Import a compliance standard or security
questionnaire
o Map policy procedures to each control or
requirement
o Map data-driven compliance evidence by
query questions
o Perform automated gap analysis based on
query results
o Export compliance artifacts (summary or
full evidence package)

Secure Cloud Insights: Graph Viewer
176
Graph Viewer
It’s a data driven Graph Platform
o Jupiter One Query Language (J1QL)
is used to traverse the Graph Data –
Entities and Edges (Relationships).
o You can view and interact with the
Query Result.

Secure Cloud Insights: Insights
177
Insights
o Helps you build Reporting
Dashboards using J1QL Queries.
o You can create a Team Board shared
across accounts and individual
Dashboards.
o Layouts are saved for Each User.
o Admins can create default Layouts.
o You can create your own custom
Dashboards.

Secure Cloud Insights: Query Library
178
Query Library
o Has 100s of built-in and categorized Queries
for accessing the current state of your assets.
o You can clone existing queries
o You can create Custom Queries
Ask Anything Search Bar
o You can type any query in the search bar.
o Autocomplete is available

Getting Started with Search
179
1. Ask questions by typing in any keywords
to search across all packaged/saved
questions
2. Full text search across all entities based
on their property values
3. JupiterOne Query Language (J1QL) for
precise querying of entities and
Results can be toggled in four different display modes:
Table, Graph, Raw JSON, or Pretty JSON. Results are
limited to return 250 items.
Ask Questions
Just start typing any keyword (or combination
of keywords) such as these (without quotes):
o compliance
o access
o traffic
o ssh
o data encrypted
o production
Or ask a question like:
o Who are my vendors?
o What lambda functions do I have in AWS?
o What is connected to the Internet?
o Who has access to ...?

JupiterOne Query Language
o Query Language Concepts
o Query Language Structure
o Examples
180

Jupiter 1 Query Language
181
FIND {class or type of Entity1} AS {alias1}
WITH
{property}={value} AND|OR
{property}={value}
THAT
{relationship_verb}
{class or type of Entity2} AS {alias2}
WHERE
{alias1}.{property} = {alias2}.{property}
o Seamlessly blend full-text search and graph queries
o Language keywords are case-insensitive
o Inspired by SQL and Cypher and aspires to be as close
to natural language as possible
o Support for variable placeholders
o Return entities, relationships, and/or traversal tree
o Support for sorting via ORDER BY clause (currently
only applies to the starting entities of traversal)
o Support for pagination via SKIP and LIMIT clauses
(currently only applies to the starting entities of
traversal)
o Multi-step graph traversals through relationships via
THAT clause
o Aliasing of selectors via AS keyword
o Pre-traversal filtering using property
values via WITH clause
o Post-traversal filtering using property
values or union comparison via
WHERE clause
o Support aggregates including
COUNT, MIN, MAX, AVG and SUM.
Source: Jupiter One Documentation – Page 81

Jupiter 1 Query Language
182
FIND {class or type of an Entity}
Start with an Entity
WITH {property}={value} AND|OR
{property}={value}
Optionally add some property filters
THAT {relationship_verb}|RELATES
TO {class/type of another Entity}
Get its relationships
Examples
FIND * WITH tag.Production='true'
FIND User THAT IS Person
FIND User THAT RELATES TO Person
FIND Firewall AS fw
THAT ALLOWS AS rule (Network|Host) AS n
WHERE
rule.ingress=true AND rule.fromPort=22
RETURN
fw._type, fw.displayName, fw.tag.AccountName,
n._type, n.displayName, n.tag.AccountName
WHERE {alias1.property}={value}
AND|OR {alias2.property}={value}

J1QL: FIND
183
FIND {class or type of an Entity}
Start with an Entity
FIND User FIND * WITH _class= 'User'
=
FIND aws_iam_user FIND * WITH _type= ' aws_iam_user '
=
The noun that immediately follows the verb is case sensitive:
o A TitleCase word tells the query to search for entities of that class
(e.g., Account, Firewall, Gateway, Host, User, Root, Internet, etc.);
o A snake_case word tells the query to search for entities of that type
(e.g., aws_account, aws_security_group, aws_internet_gateway,
aws_instance, aws_iam_user, okta_user, user_endpoint, etc.)
Note that using the wildcard at
the beginning of the query
without any pre-traversal
filtering – that is,
FIND * THAT ... without WITH –
may result in long query
execution time.
Source: Jupiter One
Documentation – Page 102

J1QL: WITH
184
WITH is followed by
property name and values
to filter entities.
Source: Jupiter One
Documentation – Page 102
WITH {property}={value} AND|OR {property}={value}
Supported operators include:
o = or != for String value, Boolean, Number, or Date comparison.
o > or < for Number or Date comparison.
o The property names and values are case sensitive.
o String values must be wrapped in either single or double quotes - "value" or 'value'.
o Boolean, Number, and Date values must not be wrapped in quotes.
o The undefined keyword can be used to filter on the absence of a property.
For example: FIND DataStore with encrypted=undefined
FIND DataStore WITH encrypted = false AND tag.Production = true
FIND user_endpoint WITH platform = ('darwin' OR 'linux')
Find DataStore WITH classification != ('critical' and 'restricted')

J1QL: THAT
185
The verb is the class value of a Relationship – that is, the edge between two connected entity nodes in the
graph. This relationship verb/class value Is stored in ALLCAPS, however, it is case insensitive in the query, as the
query language will automatically convert it. The predefined keyword RELATES TO can be used to find any
relationship between two nodes.
FIND Service THAT RELATES TO Account
FIND (Host|Device)
WITH ipAddress='10.50.2.17'
FIND * WITH (_class='Host' OR _class='Device’)
AND ipAddress='10.50.2.17'
THAT {relationship_verb}|RELATES TO {class/type of another Entity}
Get its relationships
( | ) can be used to select entities or relationships of different class/type.
=
FIND * THAT (ALLOWS|PERMITS) (Internet|Everyone)

J1QL: WHERE
186
WHERE {alias1.property}={value} AND|OR {alias2.property}={value}
FIND Firewall AS fw
THAT ALLOWS AS rule (Network|Host) AS n
WHERE
rule.ingress=true AND rule.fromPort=22
RETURN
fw._type, fw.displayName, fw.tag.AccountName,
n._type, n.displayName, n.tag.AccountName
FIND (Network as n1 | Network as n2)
WHERE
n1.CIDR = n2.CIDR
This query joins the properties of two different
network entities, to identify if there are multiple
networks in the same environment using
conflicting IP spacing
WHERE is used for post-traversal filtering or union (requires selector)

J1QL: RETURN
187
FIND User as u
THAT IS Person as p
RETURN
u.username, p.firstName, p.lastName,
p.email
FIND User as u
THAT IS Person as p
RETURN is used to return specific entities, relationships, or properties
By default, the entities and their properties found from
the start of the traversal is returned. For example, Find
User that IS Person returns all matching User entities
and their properties, but not the related Person
entities.
To return properties from both the User and Person
entities, define a selector for each and use them in
the RETURN clause:
FIND User as u
THAT IS Person as p
RETURN
u.*, p.*
Wildcard can be used to return all properties. A side effect of
using wildcard to return all properties is that all metadata
properties associated with the selected entities are also
returned. This may be useful when users desire to perform
analysis that involves metadata.

J1QL: ORDER BY, SKIP, LIMIT
188
FIND Person as u
WITH encrypted = false
ORDER BY u.username
SKIP 10
LIMIT 5
o ORDER BY is followed by a selector.field to indicate what to sort.
o SKIP is followed by a number to indicate how many results to skip.
o LIMIT is followed by a number to indicate how many results to return.
In the example below, the query sorts users by their username, and returns the 15th-20th users
from the sorted list.

J1QL: Aggregate Functions: Count, Min, Max, Avg & Sum
189
FIND bitbucket_team as team
that relates to bitbucket_user as user
RETURN
team.name, count(user)
The following aggregating functions are
supported:
o count(selector)
o count(selector.field)
o min(selector.field)
o max(selector.field)
o avg(selector.field)
o sum(selector.field)
FIND bitbucket_team as team
that relates to bitbucket_user as user
RETURN
team.name, count(user), avg(user.age)
The ability to perform aggregations are exposed
as Aggregating Functions. These are functions
that can be applied to a given set of data that
was requested via the RETURN clause.

J1QL: Combining Full Text Search
190
Find "Administrator" WITH _class='AccessPolicy’ THAT ASSIGNED (User|AccessRole)
Find 'security officer’ WITH _type='employee'
Find 'roles responsibilities’ WITH _class=('Policy' or 'Procedure')

J1QL: Part 1 Simple Root Query
191
The JupiterOne Query Language (J1QL) is a query language for finding the entities and relationships
within your digital environment. J1QL blends together the capabilities of asking questions,
performing full text search, or querying the complex entity-relationship graph.
Find Account THAT RELATES TO Root RETURN tree
(e.g., aws_account, aws_security_group, aws_internet_gateway, aws_instance, aws_iam_user,
okta_user, user_endpoint, etc.)

J1QL: Part 1 Simple Root Query
192
The JupiterOne Query Language (J1QL) is a query language for finding the entities and relationships
within your digital environment. J1QL blends together the capabilities of asking questions,
performing full text search, or querying the complex entity-relationship graph.
Find Account
THAT RELATES TO Root
RETURN tree
(e.g., aws_account, aws_security_group, aws_internet_gateway, aws_instance, aws_iam_user,
okta_user, user_endpoint, etc.)

J1QL: Part 2 Infrastructure Analysis
193
2.1 SSH Keys
FIND AccessKey WITH usage='ssh'
FIND aws_key_pair
By Class
By Type
FIND Host as h
THAT uses AccessKey
WITH usage='ssh' as k
RETURN
h.tag.AccountName, h._type,
h.displayName, h.instanceId, h.region,
h.availabilityZone, h.publicIpAddress,
h.privateIpAddress, h.platform,
h.instanceType, h.state, k._type,
k.displayName
By Class
By Relation
By Filter
This query Finds the Host entities that USES each
AccessKey and returns a set of specific properties. You
can add or remove properties returned as desired.
FIND aws_instance THAT uses aws_key_pair
FIND Host THAT uses aws_key_pair

194
2.2 EBS Volumes
FIND Host THAT uses aws_ebs_volume WITH encrypted != true
FIND aws_ebs_volume WITH encrypted != true
By Class
By Type
FIND Network as n
THAT has Host as h
THAT uses aws_ebs_volume
WITH
active = true AND
encrypted != true AND
tag.Production = true as e
RETURN
n.displayName, h._type,
h.displayName, e.displayName,
e.encrypted
By Class
By Relation
By Filter
This query Finds aws_ebs_volume that
o What subnets are these instances in?
o Are these actively in use?
o And in production?
o Are they Encrypted?
Let's also just return a few key properties from
the type of entities related in this search:

195
2.3 Unencrypted Data
Find DataStore WITH encrypted != true
Find (aws_s3_bucket|aws_rds_cluster|aws_db_instance|aws_dynamodb_table|aws_redshift_
cluster) WITH encrypted!=true
By Class
By Type
FIND DataStore
WITH
encrypted != true AND
tag.Production = true AND
(classification = 'confidential’ OR
classification = 'restricted')
By Class
By Filter
This query Finds DataStore
o Is the Data Encrypted?
o Is the Data In Production?
o Is it classified as Confidential or restricted

196
2.4 Network Resources and Configurations
Find Network THAT contains Network RETURN tree
Find Network THAT has (Host|Cluster|Database) RETURN tree
By Class
By Class
Find (Gateway|Firewall)
THAT relates to *
WITH category='network’
RETURN tree
By Class
By Relation
By Filter

197
2.5 Serverless Functions
Find aws_lambda_function
By Type
Find aws_lambda_function as function
THAT TRIGGERS * as trigger
RETURN
trigger._type, trigger.displayName,
trigger.arn, trigger.webLink,
function.functionName, function.arn,
function.webLink
By Type
By Relation
Find Firewall as fw
THAT ALLOWS as rule (Host|Network)
WITH internal=false OR
internal=undefined as src
WHERE
rule.ingress=true AND
(rule.fromPort<=22 AND
rule.toPort>=22)
RETURN
fw._type, fw.displayName,
rule.fromPort, rule.toPort,
src.displayName, src.ipAddress,
src.CIDR
By Class
By Relation
By Filter

198
2.6 Tagging Resources
Tagging of resources (at source) can be quite useful and it will help to have a well-
defined queries.
Previous set of queries rely on following Default Tags
o Classification
o Owner
o PII or PHI or PCI (Boolean type)
o AccountName
o Production
All custom tags are prefixed with tag.<TagName>. Classification and owner tags are
automatically captured as properties so that they can be directly used as
“classification” or ”owner”.

J1QL: Part 3 User & Access Analysis
199
3.1 Identity Provider Users and Access
Source: Jupiter One Documentation – Page 14,15
Find User THAT !IS Person
Find User
WITH active = true AND mfaEnabled != true
THAT !(ASSIGNED|USES|HAS) mfa_device
By Class
Find User
WITH active = true AND mfaEnabled != true
THAT ASSIGNED Application
WITH displayName = 'Amazon Web Services'
By Class
By Filter
By Relation
By Filter
Examples in this section require an identity provider integration
Are there system accounts do not belong to an
individual employee/user?
Which active user accounts do not have
multi-factor authentication enabled?
Find User with active = true and mfaEnabled !=
true that ASSIGNED Application with
displayName = 'Amazon Web Services'
Find User
THAT IS Person
THAT !EMPLOYS Root
By Class
By Relation
By Class
By Filter
By Relation
Find all contractors and external users in the
environment.

200
3.2 Cloud Users and Access
Find (aws_iam_role|aws_iam_user|
aws_iam_group)
THAT ASSIGNED AccessPolicy
WITH policyName='AdministratorAccess'
Find aws_iam_role as role
THAT ASSIGNED AccessPolicy as policy
RETURN
role._type as RoleType,
role.roleName as RoleName,
policy._type as PolicyType,
policy.policyName as PolicyName
By Type
By Relation
By Filter
Who has been assigned full Administrator
access in AWS?
Which IAM roles are assigned which IAM
policies?
By Type
By Relation

J1QL: Part 4 Cross Account Analysis
202
Find User as U
THAT ASSIGNED Application as App
THAT CONNECTS aws_account as AWS
RETURN
U.displayName as User,
App.tag.AccountName as IdP,
App.displayName as ssoApplication,
App.signOnMode as signOnMode,
AWS.name as awsAccount
By Class
By Relation
Who has access to my AWS accounts via
single sign on (SSO)?
Find aws_account
THAT HAS aws_iam
THAT HAS aws_iam_role
THAT TRUSTS
(Account|AccessRole|User|UserGroup)
WITH _source='system-mapper’
RETURN tree
Are there assume role trusts from one AWS
account to other external entities?

J1QL: Part 5 Endpoint Compliance
203
Find HostAgent as agent
THAT MONITORS user_endpoint as device
REURN
device.displayName, device.platform,
device.osVersion, device.hardwareModel,
device.owner, agent.firewall,
agent.compliant, agent._type,
agent.displayName
By Class
By Relation
Do I have local firewall enabled on end-user
devices?
Find Person as person
THAT OWNS (Host|Device) as device
THAT MONITORS HostAgent
WITH compliant!=true as agent
RETURN
person.displayName, person.email,
device.displayName, device.platform,
device.osVersion, device.hardwareModel,
device.owner, agent.compliant,
agent._type, agent.displayName
Whose endpoints are non-compliant?

JupiterOne Data Models
o Entities
o Relationships
204

Relationship Types
205
HAS
CONTAINS
IS
OWNS
EXPLOITS
IMPACTS
USES
CONNECTS
TRIGGERS
EXTENDS
IMPLEMENTS
MITIGATES
MANAGES
EVALUATES
MONITORS
TRUSTS
PROJECTS
PERFORMED
COMPLETED
IDENTIFIED ASSIGNED
PROVIDES
CONTRIBUTES_TO
OPENED
DEPLOYED_TO
Relationships can also carry their own properties.
For example, CodeRepo -- DEPLOYED_TO -> Host may have version as a property on the DEPLOYED_TO
relationship. This represents the mapping between a code repo to multiple deployment targets, while
one deployment may be of a different version of the code than another. Storing the version as a
relationship property allows us to void duplicate instances of the code repo entity to be created to
represent different versions.

J1: Entities / Relationships
206
Source: Jupiter One Documentation
Entity Relationship Entity
CodeRepo DEPLOYED_TO Account
CodeRepo DEPLOYED_TO Host
CodeRepo DEPLOYED_TO Container
CodeRepo DEPLOYED_TO Function
1. AccessPolicy
2. AccessRole
3. Account
4. Application
5. Assessment
6. CodeRepo
7. CodeReview
8. Container
9. Control
10. ControlPolicy
11. Database
12. Device
13. Function
14. Gateway
15. Host
16. HostAgent
18. Network
19. Organization
20. Person
21. Policy
22. Procedure
23. Resource
24. Risk
25. Service
26. Site
27. Team
28. Training
29. User
30. UserGroup
31. Vendor
32. Vulnerability
33. Weakness
Entities
AccessRole TRUSTS AccessRole
AccessRole TRUSTS Service
AccessRole TRUSTS Account
Application CONNECTS Account
Gateway CONNECTS Network
Gateway TRIGGERS Function
HOST EXTENDS Resource
Relationships: TRUSTS / CONNECTS / TRIGGERS
EXTENDS / DEPLOYED_TO

J1: Relationships:
207
Account HAS User
Account HAS UserGroup
Account HAS AccessRole
Account HAS Resource
CodeRepo HAS Vulnerability
Host HAS Vulnerability
Organization HAS Site
Organization HAS Organization (e.g.. a business unit)
Application HAS Vulnerability
CodeRepo HAS Vulnerability
Host HAS Vulnerability
Service HAS Vulnerability
Site HAS Network
Site HAS Site
UserGroup HAS User
Network CONTAINS Host
Network CONTAINS Database
Network CONTAINS Network (e.g., a subnet) Source: Jupiter One Documentation – Page 72
Procedure IMPLEMENTS Policy
Control IMPLEMENTS Policy
Control MITIGATES Risk
User IS Person
Vulnerability IS Vulnerability (e.g. a Snyk Vuln IS a CVE)
Person OWNS Device
Host USES Resource (e.g. aws_instance USES
aws_ebs_volume)
HAS / CONTAINS / PERFORMED / COMPLETED / IDENTIFIED
IMPLEMENTS / MITIGATES / IS / OWNS / USES
Person PERFORMED Assessment
Person COMPLETED Training
Assessment IDENTIFIED Risk
Assessment IDENTIFIED Vulnerability

J1: Relationships:
208
Vulnerability EXPLOITS Weakness
Vulnerability IMPACTS CodeRepo | Application
Person MANAGES Person
Person MANAGES Organization
Person MANAGES Team
User MANAGES Account
User MANAGES UserGroup
ControlPolicy MANAGES Control
AccessPolicy MANAGES AccessRole
ControlPolicy EVALUATES <any entity>
HostAgent MONITORS Host
HostAgent PROTECTS Host
User ASSIGNED Application
User ASSIGNED AccessRole
UserGroup ASSIGNED AccessRole
Vendor PROVIDES Service
User CONTRIBUTES_TO CodeRepo
User OPENED CodeReview (i.e. PR)
MANAGES / PROVIDES / CONTRIBUTES_TO / OPENED / ASSIGNED
EXPLOITS / IMPACTS / EVALUATES / MONITORS / PROJECTS

JupiterOne
o Architecture
o Maturity Models
o Data Models and Question Lists
209

JupiterOne Architecture
210
Assets &
Infrastructure
Fabric
Vulnerability
Management
Software
Development
Data
& Applications
People &
Access
Operations &
Responses
Governance
Risk &
Compliance
 7 Core Functional Modules
 Connected to Central Fabric
 Silos are avoided
 Each Module contains set of
control elements
 Answers a list of Questions
 And Measured by a 3 tier
Maturity Model
The Fabric is
o A Knowledge base
o An Engineering Platform
o JupiterOne
Source: JupiterOne Docs

Advanced
Maturity
Balanced &
Automated
3
Intermediate
Maturity
Getting
Better
2
Basic
Maturity
Chaotic &
Manual
1
JupiterOne Maturity Model
211
• Siloed and piecemeal controls
implementation
• Little to no automation and lots of
unknowns
• Lack well defined data and visibility:
“garbage-in garbage-out”
• People are the “fabric”, doing the busy
work
• Getting results are labour intensive and
depends heavily on processes
• Ad hoc, reactive, manual
• Partially automated
• Has defined patterns, data, metrics
• Knows what “good” looks like with
proactive initiatives to get there
• A central platform is starting to take
place as the “fabric”
• People leverage the platform to define
and automate processes
• Mostly automated, clean data, near
complete visibility
• Continuously reporting & improving
on metrics
• The “fabric” is fully operationalized
• People make data-driven and risk-
balanced decisions
• Security becomes engineering
Control Characteristics Operational Characteristics

Data Models & Questions
1. Assets
2. People
3. Vulnerability Management
4. Software Development
5. GRC - Governance Risk & Compliance
212

Assets
Data
Model
213
Assets are more than Devices
and IP Addresses. Software
Defined Entities and
relationships.

Assets / Infra: Questions / Queries
214
What resources are directly connected to the Internet?
Find all the entities with an edge directly connected to the
Internet
What firewall rules allow ingress or egress Internet access in
production environments?
Return a list of all production ingress/egress firewall rules.
What network rules control ingress and egress access
from/to the internet?
Return ingress and egress network traffic rules from/to the
internet.
Source: https://ask.us.jupiterone.io/filter?categories=Infrastructure%2CGeneral&tagFilter=all
Find Firewall with tag.Production=true as fw
that allows as rule Internet
return
fw.tag.AccountName, fw._type, fw.name,
rule.ingress, rule.egress, rule.ipProtocol,
rule.fromPort, rule.toPort
Find (Internet|everyone)
that (allows|connects) *
return tree
Find Firewall as fw
that ALLOWS as rule Internet
return
fw.tag.AccountName, fw._type,
fw.name, rule.ingress, rule.egress,
rule.ipProtocol, rule.fromPort, rule.toPort

Assets / Infra: AWS – Questions / Queries
215
Is MFA enabled for the Account Root User for all my AWS
accounts?
Returns the accountMfaEnabled status for all AWS accounts.
'0' means MFA is not enabled.
Find aws_account
with
_source!='system-mapper' and
mfaEnabled=true as aws
return
aws.name, aws.accountId,
aws.accountMfaEnabled,
aws.mfaEnabled
Which IAM users do not have an access key?
Returns a list of users with access key enabled set to false.
Find aws_iam_user
with accessKeyEnabled!=true
Which IAM user has not logged in to the console in more
than 90 days?
Returns a list of users that have not used their password for
90 days. Consider removing the password for these users.
Find aws_iam_user
with
createdOn < date.now-90days and
passwordEnabled = true and
(passwordLastUsed < date.now-90days or
passwordLastUsed = undefined)
Source: https://ask.us.jupiterone.io/filter?integrations=aws%2Cazure%2Ccisco_meraki&tagFilter=all
Find

Asset / Infra: Google - Questions / Queries
216
Ensure that SSH access is restricted from the
internet
Firewall rules that allow traffic to SSH port (22)
should be restricted
Find Internet
THAT ALLOWS as rule google_compute_firewall as firewall
THAT PROTECTS google_compute_network as network
THAT CONTAINS google_compute_subnetwork as subnetwork
WHERE
firewall.ingress=true AND
rule.ipProtocol='tcp' AND
rule.fromPort <= 22 AND
rule.toPort >= 22
Return
rule.ipProtocol, rule.fromPort, rule.toPort,
firewall.sourceRanges, firewall.destinationRanges,
network.displayName, network.name,
network.description, subnetwork.CIDR,
subnetwork.displayName, subnetwork.name
Which Google Cloud service accounts are active?
Finds all Google Cloud service accounts that are
active
Find google_iam_service_account
With active = true
Source: https://ask.us.jupiterone.io/filter?integrations=google_cloud&tagFilter=all

People &
Access
Data
Model
217

People
Access &
Trust
Data
Model
218

People: Access: Questions / Queries
219
Find anything that allows public access to everyone.
Returns all entities that have an 'ALLOWS' permission
directly to the global 'everyone' entity.
Find Everyone
that ALLOWS *
return tree
Find Everyone
that ALLOWS * as resource
return
resource.tag.AccountName,
resource._type, resource.name,
resource.classification,
resource.description, resource.webLink
Is single sign-on (SSO) and role-based access
control (RBAC) utilized?
Returns the graph view of logical access across the
environment.
Find *
that ALLOWS AccessPolicy
that ASSIGNED AccessRole (
that TRUSTS Account)?
that (HAS|ASSIGNED)
(UserGroup|User) (that IS Person)?
return tree
Source: https://ask.us.jupiterone.io/filter?categories=Access%2CEndpoints%2CTraining&tagFilter=all

People: Endpoints: Questions / Queries
220
Whose endpoint is out of compliance?
Find employees whose endpoint device did not
meet configuration compliance.
Find Person
that (OWNS|HAS|ASSIGNED) Device
that (MONITORS|MANAGES|PROTECTS) HostAgent
with compliant=false
Is there malware protection for all endpoints?
Returns all endpoint Devices and their anti-
malware Host Agents / Configuration Policies.
Additionally, returns devices that do not have
anti-malware agent protection.
Find HostAgent
with function='anti-malware' as agent
that (PROTECTS|MANAGES|ASSIGNED|MONITORS)
(user_endpoint|workstation|laptop|desktop|
computer|smartphone|tablet) as device
return
agent.displayName,
device.displayName,
device.owner
What training courses were provided last year?
Returns a list of training created or started within
the past year.
Find Training
with
createdOn > date.now-1year or
startedOn > date.now-1year or
startDate > date.now-1year
Source: https://ask.us.jupiterone.io/filter?categories=Access%2CEndpoints%2CTraining&tagFilter=all

Vulnerability
Management
Data Model
221
Capture High Risk, High Impact
items & Automate workflow of
prioritization.

Vulnerability Management: Questions / Queries
222
What open vulnerabilities do I have?
Returns Vulnerability findings that are still open (i.e.
with a status that is open/pending).
Find (Vulnerability|Finding)
with open=true as vuln
return vuln._type, count(vuln)
Source: https://ask.us.jupiterone.io/filter?categories=Vulnerability%20Management&tagFilter=all
Which applications are vulnerable?
Returns Applications and their open Vulnerability
findings except low severity ones.
Find (Application|Project|CodeRepo) as app
that has (Vulnerability|Finding)
with severity>2 and open=true as vuln
return
app._type, app.name, vuln.name,
vuln.severity, vuln.priority
Which hosts are vulnerable?
Returns Hosts and their open Vulnerability findings
except low severity ones.
Find Host as host
that has (Vulnerability|Finding)
with severity>2 and open=true as vuln
return
host._type, host.name, vuln.name,
vuln.severity, vuln.priority

Software
Development
Data Model
223
Include Secure Coding Practices,
Security Testing in the Dev
Pipeline.

Software Development: Questions / Queries
224
Is a source code management system with version control in
place?
Finds code repositories and their related pull requests and
users (authors, reviewers, approvers).
Find CodeRepo
that HAS >> PR
that (APPROVED | OPENED) << User
return tree
Source: https://ask.us.jupiterone.io/filter?categories=Application%20Development%2CVulnerability%20Management&tagFilter=all
What are my code module, e.g., NPM package, dependencies?
Find all unique code module dependencies.
Find UNIQUE CodeModule as m
that USES as u CodeRepo as r
return count(m)
Are there code commits by an unknown developer in a PR?
Pull requests (PRs) are set to `validated` when all commits are
made by known valid developers. Returns a list of pull requests
with `validated=false`
Find PR
with validated=false
Which developer opened the most PRs in the past year? (Dev
PR Leaderboard)
Count the number of pull requests opened by developer in the
past year.
Find User as u
that opened PR
with _createdOn > date.now - 1year as pr
return u.displayName, count(pr) as totalPR
order by totalPR desc

Operations & Response: Questions / Queries
225
What are the documented incidents within the last year?
Returns a list of Incident Records within the past year.
Find 'Incident Record’
With
_createdOn > date.now-1yr or
_beginOn > date.now-1yr
Show me a graph of the inbound attacks.
Returns a graph of Attacker -TARGETS-> Any Resource
Find Attacker
that TARGETS *
return tree
Source: https://ask.us.jupiterone.io/filter?categories=General%2CIncident%20Response%2CThreat%20Analysis&tagFilter=all
Show me a graph of the outbound attacks.
Returns a graph of internal (non-mapped) Host -TARGETS->
external (mapped) Host or Network
Find Host
with _source != 'system-mapper' or internal=true
that TARGETS (Host|Network)
with
(_source = 'system-mapper' or public=true)
and internal!=true
return tree

Data & Applications: Questions / Queries
226
Are data stores encrypted at rest?
Finds if data stores are encrypted at rest.
Find DataStore
with encrypted=true
Who/what has access to critical or sensitive data?
Find all users and/or identities that have access to
critical or sensitive data.
Find unique *
with _class!='AccessPolicy' as c
that (USES|ASSIGNED) AccessRole
that (USES|ASSIGNED) AccessPolicy
that ALLOWS DataStore
with classification=('critical' or 'sensitive’)
return c._class, c._type
Source: https://ask.us.jupiterone.io/filter?categories=Data&tagFilter=all
Are data stores encrypted in transit?
Finds if data stores are encrypted in transit.
Find aws_cloudfront_distribution
with sslVersion!=undefined
Evidence of data-at-rest encryption for production
servers
Returns all data volumes (disks) attached to
production hosts and their encryption status.
Find Host
with (tag.Production=true or production=true or
tag.ePHI=true or tag.PHI=true or tag.PII=true) as h
that uses DataStore with encrypted=true as d
return
h.tag.AccountName as Account,
h.displayName as Hostname, d.displayName as
EncryptedDisks, d.encrypted as Encrypted

GRC
Data
Model
227
Good Governance is built
on right data and metrics.
It should be continuous
and involves all stake
holders.

GRC
Data
Model
228
Good Governance is built
on right data and metrics.
It should be continuous
and involves all stake
holders.

GRC: Questions / Queries
229
What are the corporate security policies and procedures?
Find all security policies and procedures.
Find security_policy
Find security_procedure as procedure
that IMPLEMENTS security_policy as policy
return
policy.displayName,
procedure.displayName
order by
policy.displayName
Source: https://ask.us.jupiterone.io/filter?categories=Governance&tagFilter=all
What are the policies and procedures for the information
security program and scope?
Find all security policies and procedures that address the
information security program and scope.
Find Procedure
that IMPLEMENTS Policy
with title='Security Program Overview

4
DevSecOps
o DevOps (IEEE P2675)
o DevSecOps Concepts
o DevSecOps Pipeline
o SAST vs DAST
230
o Risk Management Framework
o cATO
o DevSecOps Playbook

DevOps (IEEE P2675)
231
DevOps is a set of principles and practices emphasizing collaboration &
communication between Software Development Teams and IT Operations Staff along
with acquires, suppliers, and other stakeholders in the lifecycle of a Software System.
5
o Collaboration: between all Stakeholders
o Infrastructure as a Code: Assets are versioned,
scripted, & shared
o Automation: Deployment, Testing, Provisioning,
any manual or human-error-prone process
o Monitoring: Any metric in Development or
Operation that can inform priorities, direction
and policy.
Source: IEEE P2675-2021 IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment:
Standardising Change: IEEE P2675 DevOps Standard (Ruth G. Lennon) https://www.youtube.com/watch?v=a3E0u48lYyM
Five Principles of DevOps
1. Mission First
2. Customer Focus
3. Left Shift
4. Continuous Everything
5. System Thinking
 Focuses on establishing effective Compliance and IT Controls

DevSecOps
232
DevSecOps is a culture and philosophy that
must be practiced across the organization,
realized through the unification of a set of
Software development (Dev), Security (Sec)
and Operations (Ops) personnel into a
singular team.
Source: Page 17. US DoD Enterprise DevSecOps 2.0 Fundamentals

DevSecOps Manifesto
233
Source: https://www.devsecops.org/
1. Leaning in over Always Saying “No”
2. Data & Security Science over Fear, Uncertainty and Doubt
3. Open Contribution & Collaboration over Security-Only Requirements
4. Consumable Security Services with APIs over Mandated Security Controls & Paperwork
5. Business Driven Security Scores over Rubber Stamp Security
6. Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities
7. 24x7 Proactive Security Monitoring overreacting after being Informed of an Incident
8. Shared Threat Intelligence over Keeping Info to Ourselves
9. Compliance Operations over Clipboards & Checklists

DevSecOps
234
Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools

DevSecOps
235
Recommended by US DoD DevSecOps Best Practices
Source:
Page 17
US DoD
Enterprise
DevSecOps
Fundamentals

DevSecOps Pipeline
236
Source: US DoD DevSecOps Fundamentals Guidebook. Page 6

SAST vs DAST
237
Source: https://www.synopsys.com/blogs/software-security/sast-vs-dast-difference/
White box security testing
The tester has access to the underlying framework, design,
and implementation. The application is tested from the
inside out. This type of testing represents the developer
approach.
Black box security testing
The tester has no knowledge of the technologies
or frameworks that the application is built on.
The application is tested from the outside in. This
type of testing represents the hacker approach.
Requires source code
SAST doesn’t require a deployed application. It analyses the
sources code or binary without executing the application.
Requires a running application
DAST doesn’t require source code or binaries. It
analyses by executing the application.
Finds vulnerabilities earlier in the SDLC
The scan can be executed as soon as code is deemed
feature-complete.
Finds vulnerabilities toward the end of the SDLC
Vulnerabilities can be discovered after the
development cycle is complete
Can’t discover run-time and environment-related issues
Since the tool scans static code, it can’t discover run-time
vulnerabilities.
Can discover run-time and environment-related
issues
Since the tool uses dynamic analysis on an
application, it is able to find run-time
vulnerabilities.

Risk Management Framework
238
NIST SP 800-37 Rev.2
Source: NIST https://csrc.nist.gov/projects/risk-management/about-rmf : NIST 800-37
0. Prepare
Essential activities to prepare the
organization to manage security
and privacy risks
1. Categorize Information System
Categorize the system and information
processed, stored, and transmitted
based on an impact analysis.
2. Select Controls
Select the set of NIST SP 800-53
controls to protect the system
based on risk assessment(s)
3. Implement Controls
Implement the controls and
document how controls are deployed
4. Assess Controls
Assess to determine if the controls are
in place, operating as intended, and
producing the desired results
5. Authorize System
Senior official makes a risk-based decision
to authorize the system (to operate)
6. Monitor Controls
Continuously monitor control
implementation and risks to the
system

DevSecOps Playbook
US DoD Enterprise DevSecOps 2.0 Playbook
239

6
DevSecOps Playbook
240
1 Adopt a DevSecOps Culture
2 Adopt Infrastructure as Code
3
Adopt Containerized
Microservices
4
Adopt a Capability Model, not a
Maturity Model
5
Drive Continuous Improvement
through Key Capabilities
Establish a Software Factory
7
Define a meaningful
DevSecOps pipeline
8
Adapt an Agile Acquisition
Policy for Software
9
Tirelessly Pursue Cyber
Resilience
10
Shift Left: Operational Test &
Eval
Source: US DoD DevSecOps Fundamentals Playbook

Adopt a DevSecOps Culture
241
1
Key Cultural Practices
1. Stakeholder transparency and visibility.
2. Complete transparency across team members in real-
time.
3. All project resources easily accessible to the entire team;
not everyone needs commit privileges.
4. Adopt and embrace ChatOps as the communication
backbone for the DevSecOps team.
5. All technical staff should be concerned with, and have a
say in, baked-in security.
Source: US DoD DevSecOps Fundamentals Playbook. Page 4

Adopt Infrastructure as Code
242
2
Key Advantages
1. IT infrastructure supports and enables change, rather than being an obstacle
or a constraint.
2. Mitigates drift between environments by leveraging automation and push-
button deployment.
3. Enforces change management through GitOps with multiple approvers, as
needed.
4. Environmental changes are routine and fully automated, pivoting staff to focus
on other tasks.
5. Quicker recovery from failures, rather than assuming failure can be completely
prevented.
6. Empowers a continuous improvement ecosystem rather than “big bang” one
and done activities.

Adopt Containerized Microservices
243
3
Components
via
Services
Organized around
Business
Capabilities
Products
NOT
Projects
Smart
Endpoints
& Dumb Pipes
Decentralized
Governance &
Data Management
Infrastructure
Automation
via IaC
Design for
Failure
Evolutionary
Design

Adopt a Capability Model, not a Maturity Model
244
4
Metric High Performers Medium Performers Low Performers
Deployment frequency –
How often the organization deploys
code.
On demand (multiple
deploys per day)
Between once per
week and once per
month
Between once per
week and once per
month
Change lead time –
Time it takes to go from code commit to
code successfully running in production.
Less than one hour Between one week
and one month
Between one week
and one month
Mean time to recover (MTTR) –
Time it takes to restore service when a
service incident occurs (e.g., unplanned
outage, service impairment).
Less than one hour Less than one day Between one day and
one week
Change failure rate –
Percentage of changes that results in
either degraded service or requires
remediation (e.g., leads to service
impairment, service outage, requires a
hotfix, rollback, patch, etc.)
0-15% 0-15% 31-45%
Google’s DORA research program advocates that rather than use a maturity
model, research shows that a capability model is a better way to both
encourage and measure performance improvement

Drive Continuous Improvement through Key Capabilities
245
5
Architecture
1. Use Loosely Coupled Architecture
2. Architect for Empowered Teams
Culture
1. Adopt a Likert scale survey to
measure cultural change progress
2. Encourage and support continuous
learning initiatives
3. Support and Facilitate
Collaboration among and between
teams
4. Provide resources and tools that
make work meaningful
5. Support or Embody
transformational leadership
24
There are 24 Key that drive
improvements across both
DevSecOps and the
Organization
5
Classified into 5 Categories
1. Culture
2. Architecture
3. Product & Process
4. Continuous Delivery
5. Lean Management &
Monitoring

Drive Continuous Improvement through Key Capabilities
246
5
Continuous Delivery
1. Use a Source Code Repo for all production Artifacts
2. Use Trunk based development methods
3. Shift Left on Security
4. Implement Test Automation
5. Implement Continuous Integration
6. Support Test Data Management
7. Implement Continuous Delivery
8. Automate the Deployment Process
Product and Process
1. Gather and Implement Customer Feedback
2. Make the flow of work visible through the value
stream
3. Work in small batches
4. Foster and enable team experimentation
Lean Management & Monitoring
1. Have a lightweight change
approval process
2. Monitor across applications &
infrastructure too inform
business decisions
3. Check System Health periodically
4. Improve Processes and Manage
work with WIP
5. Visualize work to Monitor quality
and communicate throughout

Establish a Software Factory
247
6
• Define CI/CD Processes
and Tasks
• Select Tools
• Operate & Maintain the
Software Factory
• Monitor the Tools and
Processes
• Gather Feedback for
Improvement
• Build the Software
Factory
• Automate the
Workflows
• Verify the Tool
Integrations
• Test the Pipeline
Workflows

Define a meaningful DevSecOps pipeline
248
7

Adapt an Agile Acquisition Policy for Software
249
8
• Establishes the Software Acquisition Pathway as the
preferred path for acquisition and development of
software-intensive systems.
• Simplifies the acquisition model to enable continuous
integration and delivery of software capability on timelines
relevant to the warfighter / end user.
• Establishes business decision artifacts to manage risk and
enable successful software acquisition and development.

Tirelessly Pursue Cyber Resilience
250
9
• Cyber Resilience is “the ability to anticipate, withstand, recover from, and
adapt to adverse conditions, stresses, attacks, or compromises on the
systems that include cyber resources.”
• Cybersecurity touches each of the eight phases of the DevSecOps
lifecycle, and the various control gates serve as Go/No-Go decision
points.
• Al pipelines must use these control gates to ensure that cybersecurity is
both “baked in” and transparently identified
• Moving to DevSecOps includes moving towards a Continuous
Authorization to Operate (cATO) for an application developed using
DevSecOps processes, including a software factory with a CI/CD pipeline.

Shift Left: Operational Test & Eval
251
10
Common Testing Categories
1. Unit and Functional Testing.
2. Integration Testing.
3. Performance Testing.
4. Interoperability Testing.
5. Deployment Testing (normally conducted in a staging environment).
6. Operational Testing (normally conducted in a production environment).
7. Static Application Security Testing (SAST).
8. Dynamic Application Security Testing (DAST).
9. Interactive Application Security testing (IAST).
10. Runtime Application Self-Protection (RASP).

DREAM | AUTOMATE | EMPOWER
Araf Karsh Hamid :
India: +91.999.545.8627
http://www.slideshare.net/arafkarsh
https://www.linkedin.com/in/arafkarsh/
https://www.youtube.com/user/arafkarsh/playlists
http://www.arafkarsh.com/
@arafkarsh
arafkarsh

Source Code: https://github.com/MetaArivu Web Site: https://metarivu.com/ https://pyxida.cloud/

http://www.slideshare.net/arafkarsh

DevSecOps
255
1. IBM: 2019, Sept 13: What is DevSecOps? https://www.youtube.com/watch?v=J73MELGF6u0
2. 2019, Aug 14: Three Faces of DevSecOps: https://www.youtube.com/watch?v=eC_Y74sfFrI
3. 2021 Jan 15: Life of a DevSecOps Engineer: https://www.youtube.com/watch?v=1SL_sxsEB5o
4. 2021 Mar 25: How to Build and Maintain a DevSecOps Culture: https://www.youtube.com/watch?v=qNsklzbDAqU
5. BlackHat: DevSecOps: What, Why & How: https://www.youtube.com/watch?v=DzX9Vi_UQ8o
6. Cisco Secure Cloud Insights: https://www.cisco.com/c/en/us/products/security/secure-cloud-insights/index.html
7. JupiterOne: Cloud Native Cyber Asset Management Platform: https://jupiterone.com/platform/
8. DevSecOps: https://www.atlassian.com/devops/devops-tools/devsecops-tools
9. SAST vs. DAST : https://www.synopsys.com/blogs/software-security/sast-vs-dast-difference/
10. How to Build Strong DevSecOps Culture: https://enterprisersproject.com/article/2018/6/how-build-strong-devsecops-culture-5-tips
11. Carnegie Mellon University: SEI: 2021 Oct 14: The role of DevSecOps to cATO: https://insights.sei.cmu.edu/blog/the-role-of-devsecops-in-
continuous-authority-to-operate/
12. Carnegie Mellon University: SEI: Achieving Continuous Authority To Operate: https://www.youtube.com/watch?v=3dvsrWZbu0E
13. NIST SP 800-37 Rev.2 Risk Management Framework: https://www.nist.gov/privacy-framework/nist-sp-800-37
14. Continuous ATO - https://www.youtube.com/watch?v=k4lO3-9kIM0

Security
256
1. 2021 Sept 10, IBM Zero Trust Explained: https://www.youtube.com/watch?v=yn6CPQ9RioA
2. 2020 June 10: Palo Alto: Best Practices: Zero Trust: https://www.youtube.com/watch?v=-ld2lfz6ytU
3. 2020 June 2, Palo Alto Zero Trust: https://www.youtube.com/watch?v=zzZ4q9DSnbg
4. 2020 Mar 10, Cisco: How to Approach Zero Trust Model: https://www.youtube.com/watch?v=6q6c0Ld0qx0
5. 2019 July 24, SANS Blue Team Summit ZTN: https://www.youtube.com/watch?v=EF_0dr8WkX8
6. 2019 March 17, RSA: Fallacy of Zero Trust Network: https://www.youtube.com/watch?v=tFrbt9s4Fns
7. 2019 March 17, RSA: No More Firewalls Zero Trust: https://www.youtube.com/watch?v=pyyd_OXHucI
8. 2018 Nov 30, SANS Webcast – Zero Trust Architecture: https://www.youtube.com/watch?v=5sFOdpMLXQg
9. 2012 Jul 30: Zero Trust Network with John Kindervag: https://www.youtube.com/watch?v=SSUUg38lFg0
10. RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm https://datatracker.ietf.org/doc/html/rfc4226
11. Understanding IP Tables Concept: https://www.youtube.com/watch?v=vbhr4csDeI4
12. IP Tables Rules: https://www.youtube.com/watch?v=H1WPwAjMXRo

Security
257
1. 2014: Google BeyondCorp 1: A New Approach to Enterprise Security
https://research.google/pubs/pub43231/
2. 2016: Google BeyondCorp 2: Design to Deployment at Google https://research.google/pubs/pub44860/
3. 2016: Google BeyondCorp 3: The Access Proxy https://research.google/pubs/pub45728/
4. 2017: Google BeyondCorp. 4: Maintaining Productivity While Improving Security
https://research.google/pubs/pub46134/
5. 2017: Google BeyondCorp 5: The User Experience https://research.google/pubs/pub46366/
6. 2018: Google BeyondCorp 6: Building a Healthy Fleet https://research.google/pubs/pub47356/

References
258
Design Thinking
1. What’s Design Thinking: 2020, Feb 4, https://www.youtube.com/watch?v=gHGN6hs2gZY
2. Design Thinking Process: 2017 Oct 23, https://www.youtube.com/watch?v=_r0VX-aU_T8
3. Design Thinking Workshop with Justin Ferrell of Stanford: 2013, Dec 20,
https://www.youtube.com/watch?v=Z4gAugRGpeY
Lean Startup
1. Lean Startup: Eric Ries, Talks @ Google: https://www.youtube.com/watch?v=fEvKo90qBns
2. Lean, Agile, Design Thinking: https://www.youtube.com/watch?v=OCL6RkUOShI
3. Jeff Gothelf : Lean vs Agile vs Design Thinking: https://www.youtube.com/watch?v=_4VPfmtwRac
4. Lean Startup Summary: Eric Ries, https://www.youtube.com/watch?v=RSaIOCHbuYw

References
1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas
2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google
3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head
4. Feb 17, 2019 - Lean vs Agile vs Design Thinking
5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban
6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained.
Agile Methodologies
259

References
1. Vmware: What is Cloud Architecture?
2. Redhat: What is Cloud Architecture?
3. Cloud Computing Architecture
4. Cloud Adoption Essentials:
5. Google: Hybrid and Multi Cloud
6. IBM: Hybrid Cloud Architecture Intro
7. IBM: Hybrid Cloud Architecture: Part 1
8. IBM: Hybrid Cloud Architecture: Part 2
9. Cloud Computing Basics: IaaS, PaaS, SaaS
260
1. IBM: IaaS Explained
2. IBM: PaaS Explained
3. IBM: SaaS Explained
4. IBM: FaaS Explained
5. IBM: What is Hypervisor?
Cloud Architecture

References
Microservices
1. Microservices Definition by Martin Fowler
2. When to use Microservices By Martin Fowler
3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler
4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern
5. Thought Works: Microservices in a Nutshell
6. Microservices Prerequisites
7. What do you mean by Event Driven?
8. Understanding Event Driven Design Patterns for Microservices
261

References – Microservices – Videos
262
1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s
2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg
3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans
4. GOTO 2015 – Challenges Implementing Micro Services By Fred George
5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer
6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith
7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k
8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans
9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney
10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016
11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles
12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan
13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup.
14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant
15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula
16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford.
17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

References
263
1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans
2. Mar 19, 2013 Domain Driven Design By Eric Evans
3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World
4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard
5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke
6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson
7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune
8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans
9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans
10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

References
1. IBM: Event Driven Architecture – Mar 21, 2021
2. Martin Fowler: Event Driven Architecture – GOTO 2017
3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016
4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young
5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS
6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler
7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes
264

References
265
Kafka
1. Understanding Kafka
2. Understanding RabbitMQ
3. IBM: Apache Kafka – Sept 18, 2020
4. Confluent: Apache Kafka Fundamentals – April 25, 2020
5. Confluent: How Kafka Works – Aug 25, 2020
6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020
7. Kafka Streams – Sept 4, 2021
8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018
9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

References
Databases: Big Data / Cloud Databases
1. Google: How to Choose the right database?
2. AWS: Choosing the right Database
3. IBM: NoSQL Vs. SQL
4. A Guide to NoSQL Databases
5. How does NoSQL Databases Work?
6. What is Better? SQL or NoSQL?
7. What is DBaaS?
8. NoSQL Concepts
9. Key Value Databases
10. Document Databases
11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends
12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012
13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB
14. Oct 30, 2020 - Column vs Row Oriented Databases Explained
15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained!
1. Graph Databases
2. Column Databases
3. Row Vs. Column Oriented Databases
4. Database Indexing Explained
5. MongoDB Indexing
6. AWS: DynamoDB Global Indexing
7. AWS: DynamoDB Local Indexing
8. Google Cloud Spanner
9. AWS: DynamoDB Design Patterns
10. Cloud Provider Database Comparisons
11. CockroachDB: When to use a Cloud DB?
266

References
Docker / Kubernetes / Istio
1. IBM: Virtual Machines and Containers
2. IBM: What is a Hypervisor?
3. IBM: Docker Vs. Kubernetes
4. IBM: Containerization Explained
5. IBM: Kubernetes Explained
6. IBM: Kubernetes Ingress in 5 Minutes
7. Microsoft: How Service Mesh works in Kubernetes
8. IBM: Istio Service Mesh Explained
9. IBM: Kubernetes and OpenShift
10. IBM: Kubernetes Operators
11. 10 Consideration for Kubernetes Deployments
Istio – Metrics
1. Istio – Metrics
2. Monitoring Istio Mesh with Grafana
3. Visualize your Istio Service Mesh
4. Security and Monitoring with Istio
5. Observing Services using Prometheus, Grafana, Kiali
6. Istio Cookbook: Kiali Recipe
7. Kubernetes: Open Telemetry
8. Open Telemetry
9. How Prometheus works
10. IBM: Observability vs. Monitoring
267

References
268
1. Feb 6, 2020 – An introduction to TDD
2. Aug 14, 2019 – Component Software Testing
3. May 30, 2020 – What is Component Testing?
4. Apr 23, 2013 – Component Test By Martin Fowler
5. Jan 12, 2011 – Contract Testing By Martin Fowler
6. Jan 16, 2018 – Integration Testing By Martin Fowler
7. Testing Strategies in Microservices Architecture
8. Practical Test Pyramid By Ham Vocke
Testing – TDD / BDD

1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and
most of the important components are plug‐ gable.
2. Pumba : A chaos testing and network emulation tool for Docker.
3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH-
managed environment, as an aid to resilience testing of high-availability systems.
4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours.
5. Blockade : Docker-based utility for testing network failures and partitions in distributed
applications.
6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server.
7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an
OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift
components like Pods or Deployment Configs and randomly terminates them.
8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS
deployed to an Azure Resource Manager-based resource group.
9. Tugbot : Testing in Production (TiP) framework for Docker.
Testing tools

References
CI / CD
1. What is Continuous Integration?
2. What is Continuous Delivery?
3. CI / CD Pipeline
4. What is CI / CD Pipeline?
5. CI / CD Explained
6. CI / CD Pipeline using Java Example Part 1
7. CI / CD Pipeline using Ansible Part 2
8. Declarative Pipeline vs Scripted Pipeline
9. Complete Jenkins Pipeline Tutorial
10. Common Pipeline Mistakes
11. CI / CD for a Docker Application
270

References
271
DevOps
1. IBM: What is DevOps?
2. IBM: Cloud Native DevOps Explained
3. IBM: Application Transformation
4. IBM: Virtualization Explained
5. What is DevOps? Easy Way
6. DevOps?! How to become a DevOps Engineer???
7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg
8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM
9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk
10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE
11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU
12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

References
272
1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014.
2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015.
3. Newman, Sam. Building Microservices. O’Reilly Media, 2015.
4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015.
5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014.
6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014.
7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015.
8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012.
9. Zuul Edge Server, Ketan Gote, May 22, 2017
10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017
11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017
12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017
13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016
14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016
15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015

References
273
16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx
17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/
19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs
20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer
21. CQS : http://en.wikipedia.org/wiki/Command–query_separation
22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem
23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
24. CAP 12 years how the rules have changed
25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices
26. Pat Helland (Amazon) : Life beyond distributed transactions
27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw
28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem
29. Rx Observable : https://dzone.com/articles/using-rx-java-observable

Zero-Trust SASE DevSecOps

More Related Content

What's hot

Similar to Zero-Trust SASE DevSecOps

More from Araf Karsh Hamid

Recently uploaded

Zero-Trust SASE DevSecOps

Editor's Notes