Zero-Trust SASE DevSecOps

Slide 1

Slide 1 text

@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Zero Trust / SASE Network / Security Cisco SD-WAN / SD-Access Cisco Secure Cloud Insights Jupiter One GRC / DevSecOps Part 15 of 15 Microservices Architecture Series To Build Cloud Native Apps Composable Enterprise Architecture

Slide 2

Slide 2 text

@arafkarsh arafkarsh 2 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb Cloud-Native Architecture

Slide 3

Slide 3 text

@arafkarsh arafkarsh 3 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

Slide 4

Slide 4 text

@arafkarsh arafkarsh 4 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

Slide 5

Slide 5 text

@arafkarsh arafkarsh 0 Setting up the Context o Developer Journey o US DoD: Maturation of SDLC Best Practices o SANS: Cloud Security Architecture 5 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)

Slide 6

Slide 6 text

@arafkarsh arafkarsh 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 6 Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Design Patterns Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh

Slide 7

Slide 7 text

@arafkarsh arafkarsh Maturation of SDLC Best Practices 7 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals

Slide 8

Slide 8 text

@arafkarsh arafkarsh SecOps / DevOps 8 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.

Slide 9

Slide 9 text

@arafkarsh arafkarsh SANS Cloud Security Architecture Principles 9 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

Slide 10

Slide 10 text

@arafkarsh arafkarsh 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 10 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

Slide 11

Slide 11 text

@arafkarsh arafkarsh History: Evolution of Security & Threat 11 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

Slide 12

Slide 12 text

@arafkarsh arafkarsh What Zero Trust is 12 Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds • 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”

Slide 13

Slide 13 text

@arafkarsh arafkarsh How ZERO TRUST should Help Organization 13 • 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 Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds

Slide 14

Slide 14 text

@arafkarsh arafkarsh Perimeter Security Vs. Zero Trust 14 Zero Trust Security Model 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

Slide 15

Slide 15 text

@arafkarsh arafkarsh Zero Trust: Access Management 15 • 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) Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds • 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)

Slide 16

Slide 16 text

@arafkarsh arafkarsh Zero Trust: Data 16 • 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 Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds • 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

Slide 17

Slide 17 text

@arafkarsh arafkarsh Zero Trust: Network 17 • 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 Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds

Slide 18

Slide 18 text

@arafkarsh arafkarsh Jericho: Zero Trust Fundamentals 18 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

Slide 19

Slide 19 text

@arafkarsh arafkarsh 19

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

@arafkarsh arafkarsh Google Beyond Corp: Design to Deploy 21 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

Slide 22

Slide 22 text

@arafkarsh arafkarsh Google Beyond Corp: Design to Deploy 22 Source: 2016: Google BeyondCorp 2: Design to Deployment at Google https://research.google/pubs/pub44860/ 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.

Slide 23

Slide 23 text

@arafkarsh arafkarsh NIST 800-207: Zero Trust Architecture 23 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

Slide 24

Slide 24 text

@arafkarsh arafkarsh NIST 800-207: Zero Trust Architecture 24 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.

Slide 25

Slide 25 text

@arafkarsh arafkarsh Google Beyond Corp: with NIST 800-207 25 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 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 Policy Decision Point Access Control Engine Gateways Resources 3

Slide 26

Slide 26 text

@arafkarsh arafkarsh 3 Types of PEP: Policy Enforcement Points 26 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

Slide 27

Slide 27 text

@arafkarsh arafkarsh NIST 800-207: Deployment Models 27 Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final 1. Resource Based Deployment Model 2. Enclave Based Deployment Model 3. Cloud Routed Deployment Model 4. Micro Segmented Deployment Model

Slide 28

Slide 28 text

@arafkarsh arafkarsh NIST 800-207: Resource Based 28 Device Agent PEP Policy Engine Policy Administrator Policy Decision Point Control Plane Data Plane User App Policy Enforcement Point Gateway Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final 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.

Slide 29

Slide 29 text

@arafkarsh arafkarsh NIST 800-207: Enclave Based 29 Device Agent PEP Policy Engine Policy Administrator Policy Decision Point Control Plane Data Plane User App Policy Enforcement Point Gateway Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final Enclave Based Deployment Model Zero Trust Deployment Models 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 Resource = Data, Documents, Apps, Services, Files etc.

Slide 30

Slide 30 text

@arafkarsh arafkarsh NIST 800-207: Cloud Routed 30 Device Agent PEP PEP Policy Decision Point Control Plane Data Plane User App Policy Enforcement Point Gateway Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final Cloud Routed Deployment Model Zero Trust Deployment Models 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 Resource = Data, Documents, Apps, Services, Files etc. PEP Subject

Slide 31

Slide 31 text

@arafkarsh arafkarsh NIST 800-207: Micro Segmentation 31 Policy Decision Point Control Plane Data Plane Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final Micro Segmentation Deployment Model Zero Trust Deployment Models 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 Resource = Data, Documents, Apps, Services, Files etc. PEP Subject Resource Device Agent PEP User App PEP Subject Resource PEP Subject Resource

Slide 32

Slide 32 text

@arafkarsh arafkarsh NIST 800-162: Attribute Based Access Control 32 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.

Slide 33

Slide 33 text

@arafkarsh arafkarsh NIST 800-162: Attribute Based Access Control 33 Source: Page 18 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final 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

Slide 34

Slide 34 text

@arafkarsh arafkarsh NIST 800-162: Attribute Based Access Control 34 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. Source: Page 17 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final

Slide 35

Slide 35 text

@arafkarsh arafkarsh NIST 800-162: Attribute Based Access Control 35 • 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. Source: Page 17 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final

Slide 36

Slide 36 text

@arafkarsh arafkarsh NIST 800-162: ABAC in Action 36 Source: Page 19 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final • 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.

Slide 37

Slide 37 text

@arafkarsh arafkarsh NIST 800-162: ABAC in Enterprise 37 Source: Page 22 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final

Slide 38

Slide 38 text

@arafkarsh arafkarsh ACL Trust Chain 38

Slide 39

Slide 39 text

@arafkarsh arafkarsh NIST 800-162: ABAC Trust Chain 39

Slide 40

Slide 40 text

@arafkarsh arafkarsh Forrester: Zero Trust eXtended (ZTX) 40 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?”

Slide 41

Slide 41 text

@arafkarsh arafkarsh Gartner: CARTA: 7 Core Areas 41 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

Slide 42

Slide 42 text

@arafkarsh arafkarsh Software Defined Perimeter – Context 42 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

Slide 43

Slide 43 text

@arafkarsh arafkarsh Software Defined Perimeter 43 • 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 Cloud Security Alliance: May 27, 2020: SDP and Zero Trust

Slide 44

Slide 44 text

@arafkarsh arafkarsh Software Defined Perimeter – Principles 44 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.

Slide 45

Slide 45 text

@arafkarsh arafkarsh Software Defined Perimeter: Architecture 45 Cloud Security Alliance: May 27, 2020: SDP and Zero Trust Policy Enforcement Point SDP Gateway SDP Controller Policy Decision Point 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.

Slide 46

Slide 46 text

@arafkarsh arafkarsh SDP – Secure Communications 46 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

Slide 47

Slide 47 text

@arafkarsh arafkarsh Deployment modes of Software Defined Perimeter 47 • 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

Slide 48

Slide 48 text

@arafkarsh arafkarsh Forrester Wave: Zero Trust 48

Slide 49

Slide 49 text

@arafkarsh arafkarsh SASE: Secure Access Service Edge 49 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

Slide 50

Slide 50 text

@arafkarsh arafkarsh SASE: Overview 50 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

Slide 51

Slide 51 text

@arafkarsh arafkarsh SASE: Detailed View 51 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

Slide 52

Slide 52 text

@arafkarsh arafkarsh SASE Convergence 52 Source: Gartner 2021 Strategic Roadmap for SASE Convergence, March 25, 2021 By Neil MacDonald, Nat Smith, Lawrence Orans, Joe Skorupa

Slide 53

Slide 53 text

@arafkarsh arafkarsh Timeline for SASE Convergence 53 Source: Gartner 2021 Strategic Roadmap for SASE Convergence, March 25, 2021 By Neil MacDonald, Nat Smith, Lawrence Orans, Joe Skorupa

Slide 54

Slide 54 text

@arafkarsh arafkarsh SASE: Reference Architecture 54 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.

Slide 55

Slide 55 text

@arafkarsh arafkarsh SASE Framework: Summary 55 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

Slide 56

Slide 56 text

@arafkarsh arafkarsh 2 Network / Security o VXLAN / GRE / DMVPN / MPLS / LISP o SDN / SD-WAN o Zero Trust / VPN o Service Mesh 56 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

Slide 57

Slide 57 text

@arafkarsh arafkarsh 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 57

Slide 58

Slide 58 text

@arafkarsh arafkarsh OSI Layers 58

Slide 59

Slide 59 text

@arafkarsh arafkarsh Networking Glossary 59 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.

Slide 60

Slide 60 text

@arafkarsh arafkarsh Networking Glossary 60 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.

Slide 61

Slide 61 text

@arafkarsh arafkarsh 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 61 10.130.1.0/24 10.130.2.0/24 Underlay Network VSWITCH: Virtual Switch Switch Switch Router

Slide 62

Slide 62 text

@arafkarsh arafkarsh 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 62 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)

Slide 63

Slide 63 text

@arafkarsh arafkarsh 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 63 Overlay Network ARP Broadcast ARP Broadcast ARP Broadcast Multicast VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point ARP Unicast

Slide 64

Slide 64 text

@arafkarsh arafkarsh 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 64 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

Slide 65

Slide 65 text

@arafkarsh arafkarsh 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 65 Overlay Network Src: 10.130.2.187 Dst: 10.130.1.102 Src UDP Port: Dynamic Dst UDP Port: 4789 VNI: 100 VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point | VNI : Virtual Network Identifier 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

Slide 66

Slide 66 text

@arafkarsh arafkarsh 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 66 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 Src UDP Port: Dynamic 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 VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point | VNI : Virtual Network Identifier

Slide 67

Slide 67 text

Slide 68

Slide 68 text

@arafkarsh arafkarsh GRE: Generic Routing Encapsulation 68 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 GRE Tunnel (Overlay) 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 ip tcp adjust-mss 1436 tunnel source 204.1.2.1 tunnel destination 202.1.2.1 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

Slide 69

Slide 69 text

@arafkarsh arafkarsh GRE: Packet Headers & Data Transfer 69 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 GRE Tunnel (Overlay) 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

Slide 70

Slide 70 text

@arafkarsh arafkarsh DM VPN: Dynamic Multipoint VPN 70 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 3. Branch B2 & B4 linked Source: Cisco DM VPN

Slide 71

Slide 71 text

@arafkarsh arafkarsh NHRP: Next Hop Resolution Protocol 71 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

Slide 72

Slide 72 text

@arafkarsh arafkarsh Multipoint GRE 72 B1 B2 B3 B4 HQ Requirements 1. All branches linked to HQ 2. Branch B1 & B3 linked 3. Branch B2 & B4 linked 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

Slide 73

Slide 73 text

@arafkarsh arafkarsh DM VPN: Phases 73 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 predefined. 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

Slide 74

Slide 74 text

@arafkarsh arafkarsh DM VPN: Multipoint GRE 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 1. All branches are connected to HQ 2. Branch B1 & B3 are connected 3. Branch B2 & B4 are connected Specs $ interface Tunnel0 ip address 192.168.1.99 255.255.255.0 ip mtu 1476 ip tcp adjust-mss 1436 tunnel source 9.9.9.9 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 ip tcp adjust-mss 1436 tunnel source 1.1.1.1 tunnel destination 9.9.9.9 ip nhrp authentication NHRPKEY ip nhrp network-id 1 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 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

Slide 75

Slide 75 text

@arafkarsh arafkarsh DM VPN: Multipoint GRE 75 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 3. Branch B2 & B4 are connected 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 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 ip tcp adjust-mss 1436 tunnel source 1.1.1.1 tunnel mode gre multipoint ip nhrp authentication NHRPKEY ip nhrp network-id 1 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 Hub Configuration P-2-M Use Hub Config from Phase 1 No Static destination, so manually map the multicast to NHS

Slide 76

Slide 76 text

@arafkarsh arafkarsh DM VPN: Multipoint GRE – Summary 76 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 3. Branch B2 & B4 are connected Specs $ interface Tunnel0 ip address 192.168.1.99 255.255.255.0 ip mtu 1476 ip tcp adjust-mss 1436 tunnel source 9.9.9.9 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 ip tcp adjust-mss 1436 tunnel source 1.1.1.1 tunnel destination 9.9.9.9 ip nhrp authentication NHRPKEY ip nhrp network-id 1 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 ip tcp adjust-mss 1436 tunnel source 1.1.1.1 tunnel mode gre multipoint ip nhrp authentication NHRPKEY ip nhrp network-id 1 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 Hub Configuration P-2-M 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

Slide 77

Slide 77 text

@arafkarsh arafkarsh IPSec 77 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

Slide 78

Slide 78 text

@arafkarsh arafkarsh VRF: Virtual Routing & Forwarding 78 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.

Slide 79

Slide 79 text

@arafkarsh arafkarsh MPLS: Multi Protocol Label Switching 79 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.

Slide 80

Slide 80 text

@arafkarsh arafkarsh LISP: Location Identifier Separation Protocol 80 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

Slide 81

Slide 81 text

@arafkarsh arafkarsh LISP: Control / Data Plane 81 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

Slide 82

Slide 82 text

@arafkarsh arafkarsh LISP: Location Identifier Separation Protocol 82 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

Slide 83

Slide 83 text

@arafkarsh arafkarsh Software Defined Network 83 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

Slide 84

Slide 84 text

@arafkarsh arafkarsh SDN Architecture Software Defined Network 84 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

Slide 85

Slide 85 text

@arafkarsh arafkarsh Benefits of the SDN Controller 85 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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

@arafkarsh arafkarsh Software Defined – WAN 87 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

Slide 88

Slide 88 text

@arafkarsh arafkarsh Software Defined – WAN: Architecture 88 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

Slide 89

Slide 89 text

@arafkarsh arafkarsh Software Defined – WAN: Zero Touch Provisioning 89 New York SD-WAN Edge Appliance Internet MPLS SD-WAN Fabric 1 Gb DIA SD-WAN Controller Cloud Hosted / On-Premise 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

Slide 90

Slide 90 text

@arafkarsh arafkarsh Software Defined – WAN: Security 90 New York SD-WAN Edge Appliance SD-WAN Fabric SD-WAN Controller Cloud Hosted / On-Premise 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

Slide 91

Slide 91 text

@arafkarsh arafkarsh Public WAN Private WAN Software Defined – WAN: Private / Public 91 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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

@arafkarsh arafkarsh Software Defined – WAN: Benefits 93 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.

Slide 94

Slide 94 text

@arafkarsh arafkarsh Software Defined – WAN: Summary 94 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

Slide 95

Slide 95 text

@arafkarsh arafkarsh Security Cloud Security Architecture 95

Slide 96

Slide 96 text

@arafkarsh arafkarsh Hype cycle of Security Operations for 2021 96

Slide 97

Slide 97 text

@arafkarsh arafkarsh SANS Cloud Security Architecture Principles 97 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

Slide 98

Slide 98 text

@arafkarsh arafkarsh Built-In Security At Every Layer 98 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. Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute

Slide 99

Slide 99 text

@arafkarsh arafkarsh Built-In Security At Every Layer 99 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 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute Built-In Security at every Layer

Slide 100

Slide 100 text

@arafkarsh arafkarsh Built-In Security At Every Layer 100 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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.

Slide 101

Slide 101 text

@arafkarsh arafkarsh Think ”Components” 101 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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

Slide 102

Slide 102 text

@arafkarsh arafkarsh Design for Failure 102 Design for Failure Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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

Slide 103

Slide 103 text

@arafkarsh arafkarsh Design for Elasticity 103 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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

Slide 104

Slide 104 text

@arafkarsh arafkarsh Make use of Different Storage Options 104 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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

Slide 105

Slide 105 text

@arafkarsh arafkarsh Always think of Feedback Loops 105 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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

Slide 106

Slide 106 text

@arafkarsh arafkarsh Focus on Centralization, Standards, Automation 106 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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 Standards & Automation

Slide 107

Slide 107 text

@arafkarsh arafkarsh Blast Radius 107 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute 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.

Slide 108

Slide 108 text

@arafkarsh arafkarsh 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 108

Slide 109

Slide 109 text

@arafkarsh arafkarsh IEEE 802.1x Wired / Wireless 109 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

Slide 110

Slide 110 text

@arafkarsh arafkarsh 802.1x EAP Security 110 • 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

Slide 111

Slide 111 text

@arafkarsh arafkarsh Port Knocking 111 • 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

Slide 112

Slide 112 text

@arafkarsh arafkarsh 32 Bit 64 Bit 32 Bit Single Packet Authorization 112 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.

Slide 113

Slide 113 text

@arafkarsh arafkarsh Single Packet Authorization: Benefits 113 ✓ 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/

Slide 114

Slide 114 text

@arafkarsh arafkarsh Zero Trust: Micro Segmentation 114 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

Slide 115

Slide 115 text

@arafkarsh arafkarsh Zero Trust: Micro Segmentation: Benefits 115 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.

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

@arafkarsh arafkarsh Traditional VPN Vs. Zero Trust 117 Enterprise VPN User System VPN Client User App VPN Server IAM WAN WAN Split Tunnel Optional Resource = Data, Documents, Apps, Services, Files etc. 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

Slide 118

Slide 118 text

@arafkarsh arafkarsh Zero Trust – Security: Resource Based 118 Device Agent PEP Policy Decision Point 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 Zero Trust Deployment Models Encrypted Tunnel Data Implicit Trust Zone Zero Trust will bring changes to network segmentation and network traffic encryption patterns. Resource Resource = Data, Documents, Apps, Services, Files etc. Host IDS/IPS Host IDS/IPS ZT Aware IDS/IPS

Slide 119

Slide 119 text

@arafkarsh arafkarsh Zero Trust – Security: Enclave Based 119 Device Agent PEP Policy Decision Point 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 Enclave Based Deployment Model Zero Trust Deployment Models Encrypted Tunnel Data Implicit Trust Zone Zero Trust will bring changes to network segmentation and network traffic encryption patterns. Resource Enclave Resource = Data, Documents, Apps, Services, Files etc. Host IDS/IPS ZT Aware IDS/IPS Host IDS/IPS Host IDS/IPS NIDPS

Slide 120

Slide 120 text

@arafkarsh arafkarsh Zero Trust – Security: Cloud Routed 120 Device PEP Policy Decision Point Control Plane Data Plane User App Cloud Routed Deployment Model Zero Trust Deployment Models Resource = Data, Documents, Apps, Services, Files etc. PEP Subject Source: Page 183: Zero Trust Security: An Enterprise Guide by Jason Garbis, Jerry W Chapman 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

Slide 121

Slide 121 text

@arafkarsh arafkarsh Zero Trust – Security: Micro Segmentation 121 Micro Segmentation Deployment Model Zero Trust Deployment Models Resource = Data, Documents, Apps, Services, Files etc. Source: Page 183: Zero Trust Security: An Enterprise Guide by Jason Garbis, Jerry W Chapman PEP Subject Resource Host IDS/IPS PEP Subject Resource Host IDS/IPS ZT Aware Network IDS/IPS

Slide 122

Slide 122 text

@arafkarsh arafkarsh Secure Web Gateway 122 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.

Slide 123

Slide 123 text

@arafkarsh arafkarsh Cloud Access Security Broker (CASB) 123 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

Slide 124

Slide 124 text

@arafkarsh arafkarsh Service Mesh: Istio Security 124 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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

@arafkarsh arafkarsh Service Mesh: Micro Segmentation 126 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.

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

@arafkarsh arafkarsh 128 Cisco Umbrella

Slide 129

Slide 129 text

@arafkarsh arafkarsh 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 129 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

Slide 130

Slide 130 text

@arafkarsh arafkarsh 130 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

Slide 131

Slide 131 text

@arafkarsh arafkarsh Cisco SD-WAN: Features 131 Source: Cisco SD-WAN Getting Started Page 14

Slide 132

Slide 132 text

@arafkarsh arafkarsh OMP – Overlay Management Protocol 132 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

Slide 133

Slide 133 text

@arafkarsh arafkarsh Cisco SD-WAN Controllers 133 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.

Slide 134

Slide 134 text

@arafkarsh arafkarsh Cisco SD-WAN Components 134 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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

@arafkarsh arafkarsh Cisco SD-WAN Zero Touch Provisioning 136 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

Slide 137

Slide 137 text

@arafkarsh arafkarsh SD-WAN Transport Tunnels & Topologies 137 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

Slide 138

Slide 138 text

@arafkarsh arafkarsh Edge Router: Traffic Routing 138 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

Slide 139

Slide 139 text

@arafkarsh arafkarsh SD-WAN: Key Attributes 139 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

Slide 140

Slide 140 text

@arafkarsh arafkarsh Cisco SD-WAN: Boot Sequence 140 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 5 Sends Config 6 5.1 5.2 Start Start Start Start 7 Authenticate 8 Sends Config 7.1 7.2 7.3

Slide 141

Slide 141 text

@arafkarsh arafkarsh Cisco SD-WAN Summary 141 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.

Slide 142

Slide 142 text

@arafkarsh arafkarsh Cisco SD-Access / Zero Trust o Cisco DNA o Cisco ISE o Cisco SD – Access 142

Slide 143

Slide 143 text

@arafkarsh arafkarsh Cisco DNA Center o Concept o Architecture 143

Slide 144

Slide 144 text

@arafkarsh arafkarsh Cisco DNA Platform 144 Source: Cisco DNA Assurance – Page 23

Slide 145

Slide 145 text

@arafkarsh arafkarsh Cisco DNA Center Platform 145 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.

Slide 146

Slide 146 text

@arafkarsh arafkarsh Cisco DNA Center Overview 146 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

Slide 147

Slide 147 text

@arafkarsh arafkarsh Cisco DNA: Intent Based Networking 147 Source: Cisco DNA Assurance – Page 24

Slide 148

Slide 148 text

@arafkarsh arafkarsh Cisco DNA Architecture 148 Source: Cisco DNA Center 2.2.3.0 Data Sheet Nov 17 2021

Slide 149

Slide 149 text

@arafkarsh arafkarsh Cisco ISE – Identity Services Engine 149

Slide 150

Slide 150 text

@arafkarsh arafkarsh Cisco ISE: How ISE enforces Zero Trust 150 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

Slide 151

Slide 151 text

@arafkarsh arafkarsh Cisco SD-Access o Concept o Automation Benefits o SD-Access Layers o Architecture 151

Slide 152

Slide 152 text

@arafkarsh arafkarsh Cisco: SD-Access: Zero Trust 152 Source: Cisco Software-Defined Access for Zero-Trust Workplace At-a-Glance

Slide 153

Slide 153 text

@arafkarsh arafkarsh Cisco: Software Defined Access 153 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

Slide 154

Slide 154 text

@arafkarsh arafkarsh Cisco SD-Access 154 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 20 o Software- Defined Access 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.

Slide 155

Slide 155 text

@arafkarsh arafkarsh Cisco SD-Access: Automation 155 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 43

Slide 156

Slide 156 text

@arafkarsh arafkarsh Cisco SD-Access Layers 156 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. Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 32

Slide 157

Slide 157 text

@arafkarsh arafkarsh Cisco SD-Access Fabric 157 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. Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 36

Slide 158

Slide 158 text

@arafkarsh arafkarsh Cisco SD-Access Architecture Overview 158 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

Slide 159

Slide 159 text

@arafkarsh arafkarsh Cisco SD-Access : Wireless Deployment 159 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 60

Slide 160

Slide 160 text

@arafkarsh arafkarsh Cisco SD-Access: Multi Site Fabric 160 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 71

Slide 161

Slide 161 text

@arafkarsh arafkarsh Cisco SD-Access: Transit 161 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 78

Slide 162

Slide 162 text

@arafkarsh arafkarsh Cisco SD-Access: SD-WAN Transit 162 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 79

Slide 163

Slide 163 text

@arafkarsh arafkarsh Cisco SD-Access: MPLS VPN 163 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 80

Slide 164

Slide 164 text

@arafkarsh arafkarsh Cisco SD-Access: VRF-Lite over DM VPN 164 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 81

Slide 165

Slide 165 text

@arafkarsh arafkarsh Cisco SD-Access: Policy Enforcement 165 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 124

Slide 166

Slide 166 text

@arafkarsh arafkarsh Cisco SDA: User Access based on Group Policy 166 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 125

Slide 167

Slide 167 text

@arafkarsh arafkarsh Cisco SD-Access: Benefits 167

Slide 168

Slide 168 text

@arafkarsh arafkarsh Comparison o Cisco Viptela SD-WAN o VMWare VeloCloud o Silver Peak 168

Slide 169

Slide 169 text

@arafkarsh arafkarsh Gartner Magic Quadrant 2021 SD-WAN 169

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

@arafkarsh arafkarsh Cisco Secure Cloud Insights – Eye in the Sky 171 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.

Slide 172

Slide 172 text

@arafkarsh arafkarsh Cisco SecureX & Secure Cloud Insights 172 Source: SCI – Your Eyes in the Sky By AI Huger, Nov 15, 2021 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.

Slide 173

Slide 173 text

@arafkarsh arafkarsh Cisco Secure Cloud Insights 173 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

Slide 174

Slide 174 text

@arafkarsh arafkarsh Secure Cloud Insights: Apps 174 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

Slide 175

Slide 175 text

@arafkarsh arafkarsh Secure Cloud Insights: Policies 175 Source: Cisco Secure Cloud Insights Getting Started Guide Page 6 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.

Slide 176

Slide 176 text

@arafkarsh arafkarsh Secure Cloud Insights: Alerts 176 Source: Cisco Secure Cloud Insights Getting Started Guide Page 6 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

Slide 177

Slide 177 text

@arafkarsh arafkarsh Secure Cloud Insights: Compliance 177 Source: Cisco Secure Cloud Insights Getting Started Guide Page 6 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)

Slide 178

Slide 178 text

@arafkarsh arafkarsh Secure Cloud Insights: Graph Viewer 178 Source: Cisco Secure Cloud Insights Getting Started Guide Page 6 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.

Slide 179

Slide 179 text

@arafkarsh arafkarsh Secure Cloud Insights: Insights 179 Source: Cisco Secure Cloud Insights Getting Started Guide Page 7 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.

Slide 180

Slide 180 text

@arafkarsh arafkarsh Secure Cloud Insights: Query Library 180 Source: Cisco Secure Cloud Insights Getting Started Guide Page 7 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

Slide 181

Slide 181 text

@arafkarsh arafkarsh Getting Started with Search 181 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 Source: Cisco Secure Cloud Insights Getting Started Guide Page 10 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 ...?

Slide 182

Slide 182 text

@arafkarsh arafkarsh JupiterOne Query Language o Query Language Concepts o Query Language Structure o Examples 182

Slide 183

Slide 183 text

@arafkarsh arafkarsh Jupiter 1 Query Language 183 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

Slide 184

Slide 184 text

@arafkarsh arafkarsh Jupiter 1 Query Language 184 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 Source: Cisco Secure Cloud Insights Getting Started Guide Page 11 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} Optionally add some property filters

Slide 185

Slide 185 text

@arafkarsh arafkarsh J1QL: FIND 185 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

Slide 186

Slide 186 text

@arafkarsh arafkarsh J1QL: WITH 186 WITH is followed by property name and values to filter entities. Source: Jupiter One Documentation – Page 102 WITH {property}={value} AND|OR {property}={value} Optionally add some property filters 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')

Slide 187

Slide 187 text

@arafkarsh arafkarsh J1QL: THAT 187 Source: Jupiter One Documentation – Page 102 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)

Slide 188

Slide 188 text

@arafkarsh arafkarsh J1QL: WHERE 188 Source: Jupiter One Documentation – Page 103 WHERE {alias1.property}={value} AND|OR {alias2.property}={value} Optionally add some property filters 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)

Slide 189

Slide 189 text

@arafkarsh arafkarsh J1QL: RETURN 189 Source: Jupiter One Documentation – Page 103 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.

Slide 190

Slide 190 text

@arafkarsh arafkarsh J1QL: ORDER BY, SKIP, LIMIT 190 Source: Jupiter One Documentation – Page 104 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.

Slide 191

Slide 191 text

@arafkarsh arafkarsh J1QL: Aggregate Functions: Count, Min, Max, Avg & Sum 191 Source: Jupiter One Documentation – Page 104 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.

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

@arafkarsh arafkarsh J1QL: Part 1 Simple Root Query 193 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. Source: Cisco Secure Cloud Insights Getting Started Guide Page 16 Find Account THAT RELATES TO Root RETURN tree 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.)

Slide 194

Slide 194 text

@arafkarsh arafkarsh J1QL: Part 1 Simple Root Query 194 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. Source: Cisco Secure Cloud Insights Getting Started Guide Page 16 Find Account THAT RELATES TO Root RETURN tree 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.)

Slide 195

Slide 195 text

@arafkarsh arafkarsh J1QL: Part 2 Infrastructure Analysis 195 2.1 SSH Keys Source: Cisco Secure Cloud Insights Getting Started Guide Page 19 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

Slide 196

Slide 196 text

@arafkarsh arafkarsh J1QL: Part 2 Infrastructure Analysis 196 2.2 EBS Volumes Source: Cisco Secure Cloud Insights Getting Started Guide Page 19 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:

Slide 197

Slide 197 text

@arafkarsh arafkarsh J1QL: Part 2 Infrastructure Analysis 197 2.3 Unencrypted Data Source: Cisco Secure Cloud Insights Getting Started Guide Page 21 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

Slide 198

Slide 198 text

@arafkarsh arafkarsh J1QL: Part 2 Infrastructure Analysis 198 2.4 Network Resources and Configurations Source: Cisco Secure Cloud Insights Getting Started Guide Page 22 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

Slide 199

Slide 199 text

@arafkarsh arafkarsh J1QL: Part 2 Infrastructure Analysis 199 2.5 Serverless Functions Source: Cisco Secure Cloud Insights Getting Started Guide Page 24 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

Slide 200

Slide 200 text

@arafkarsh arafkarsh J1QL: Part 2 Infrastructure Analysis 200 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.. Classification and owner tags are automatically captured as properties so that they can be directly used as “classification” or ”owner”. Source: Cisco Secure Cloud Insights Getting Started Guide Page 21

Slide 201

Slide 201 text

@arafkarsh arafkarsh J1QL: Part 3 User & Access Analysis 201 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.

Slide 202

Slide 202 text

@arafkarsh arafkarsh J1QL: Part 3 User & Access Analysis 202 3.2 Cloud Users and Access Source: Jupiter One Documentation – Page 15 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 Examples in this section require an identity provider integration Who has been assigned full Administrator access in AWS? Which IAM roles are assigned which IAM policies? By Type By Relation

Slide 203

Slide 203 text

@arafkarsh arafkarsh J1QL: Part 3 User & Access Analysis 203 3.3 Combined users and access across all environments Source: Jupiter One Documentation – Page 16 Find (User|Person) as u THAT (ASSIGNED|TRUSTS|HAS|OWNS) (Application|AccessPolicy|AccessRole|Account|Device|Host) as a RETURN u.displayName, u._type, u.username, u.email, a._type, a.displayName, a.tag.AccountName ORDER BY u.displayName By Type By Relation Examples in this section require an identity provider integration Who has access to what systems/resources?

Slide 204

Slide 204 text

@arafkarsh arafkarsh J1QL: Part 4 Cross Account Analysis 204 Source: Jupiter One Documentation – Page 16 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?

Slide 205

Slide 205 text

@arafkarsh arafkarsh J1QL: Part 5 Endpoint Compliance 205 Source: Jupiter One Documentation – Page 17 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?

Slide 206

Slide 206 text

@arafkarsh arafkarsh JupiterOne Data Models o Entities o Relationships 206

Slide 207

Slide 207 text

@arafkarsh arafkarsh Relationship Types 207 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. Source: Jupiter One Documentation – Page 72

Slide 208

Slide 208 text

@arafkarsh arafkarsh J1: Entities / Relationships 208 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 Entity Relationship Entity AccessRole TRUSTS AccessRole AccessRole TRUSTS Service AccessRole TRUSTS Account Entity Relationship Entity Application CONNECTS Account Gateway CONNECTS Network Gateway TRIGGERS Function HOST EXTENDS Resource Relationships: TRUSTS / CONNECTS / TRIGGERS EXTENDS / DEPLOYED_TO

Slide 209

Slide 209 text

@arafkarsh arafkarsh J1: Relationships: 209 Entity Relationship Entity 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 Entity Relationship Entity Procedure IMPLEMENTS Policy Control IMPLEMENTS Policy Control MITIGATES Risk Entity Relationship Entity User IS Person Vulnerability IS Vulnerability (e.g. a Snyk Vuln IS a CVE) Person OWNS Device Entity Relationship Entity Host USES Resource (e.g. aws_instance USES aws_ebs_volume) HAS / CONTAINS / PERFORMED / COMPLETED / IDENTIFIED IMPLEMENTS / MITIGATES / IS / OWNS / USES Entity Relationship Entity Person PERFORMED Assessment Person COMPLETED Training Assessment IDENTIFIED Risk Assessment IDENTIFIED Vulnerability

Slide 210

Slide 210 text

@arafkarsh arafkarsh J1: Relationships: 210 Source: Jupiter One Documentation – Page 75 Entity Relationship Entity Vulnerability EXPLOITS Weakness Vulnerability IMPACTS CodeRepo | Application Entity Relationship Entity Person MANAGES Person Person MANAGES Organization Person MANAGES Team User MANAGES Account User MANAGES UserGroup ControlPolicy MANAGES Control AccessPolicy MANAGES AccessRole Entity Relationship Entity ControlPolicy EVALUATES HostAgent MONITORS Host HostAgent PROTECTS Host Entity Relationship Entity User ASSIGNED Application User ASSIGNED AccessRole UserGroup ASSIGNED AccessRole Entity Relationship Entity Vendor PROVIDES Service User CONTRIBUTES_TO CodeRepo User OPENED CodeReview (i.e. PR) MANAGES / PROVIDES / CONTRIBUTES_TO / OPENED / ASSIGNED EXPLOITS / IMPACTS / EVALUATES / MONITORS / PROJECTS

Slide 211

Slide 211 text

@arafkarsh arafkarsh JupiterOne o Architecture o Maturity Models o Data Models and Question Lists 211

Slide 212

Slide 212 text

@arafkarsh arafkarsh JupiterOne Architecture 212 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

Slide 213

Slide 213 text

@arafkarsh arafkarsh Advanced Maturity Balanced & Automated 3 Intermediate Maturity Getting Better 2 Basic Maturity Chaotic & Manual 1 JupiterOne Maturity Model 213 • 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 Source: JupiterOne Docs

Slide 214

Slide 214 text

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

Slide 215

Slide 215 text

@arafkarsh arafkarsh Assets Data Model 215 Assets are more than Devices and IP Addresses. Software Defined Entities and relationships. Source: JupiterOne Docs

Slide 216

Slide 216 text

@arafkarsh arafkarsh Assets / Infra: Questions / Queries 216 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

Slide 217

Slide 217 text

@arafkarsh arafkarsh Assets / Infra: AWS – Questions / Queries 217 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

Slide 218

Slide 218 text

@arafkarsh arafkarsh Asset / Infra: Google - Questions / Queries 218 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

Slide 219

Slide 219 text

@arafkarsh arafkarsh People & Access Data Model 219 Source: JupiterOne Docs

Slide 220

Slide 220 text

@arafkarsh arafkarsh People Access & Trust Data Model 220 Source: JupiterOne Docs

Slide 221

Slide 221 text

@arafkarsh arafkarsh People: Access: Questions / Queries 221 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

Slide 222

Slide 222 text

@arafkarsh arafkarsh People: Endpoints: Questions / Queries 222 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

Slide 223

Slide 223 text

@arafkarsh arafkarsh Vulnerability Management Data Model 223 Capture High Risk, High Impact items & Automate workflow of prioritization. Source: JupiterOne Docs

Slide 224

Slide 224 text

@arafkarsh arafkarsh Vulnerability Management: Questions / Queries 224 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

Slide 225

Slide 225 text

@arafkarsh arafkarsh Software Development Data Model 225 Source: JupiterOne Docs Include Secure Coding Practices, Security Testing in the Dev Pipeline.

Slide 226

Slide 226 text

@arafkarsh arafkarsh Software Development: Questions / Queries 226 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

Slide 227

Slide 227 text

@arafkarsh arafkarsh Operations & Response: Questions / Queries 227 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

Slide 228

Slide 228 text

@arafkarsh arafkarsh Data & Applications: Questions / Queries 228 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

Slide 229

Slide 229 text

@arafkarsh arafkarsh GRC Data Model 229 Source: JupiterOne Docs Good Governance is built on right data and metrics. It should be continuous and involves all stake holders.

Slide 230

Slide 230 text

@arafkarsh arafkarsh GRC Data Model 230 Source: JupiterOne Docs Good Governance is built on right data and metrics. It should be continuous and involves all stake holders.

Slide 231

Slide 231 text

@arafkarsh arafkarsh GRC: Questions / Queries 231 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

Slide 232

Slide 232 text

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

Slide 233

Slide 233 text

@arafkarsh arafkarsh DevOps (IEEE P2675) 233 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

Slide 234

Slide 234 text

@arafkarsh arafkarsh DevSecOps 234 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

Slide 235

Slide 235 text

@arafkarsh arafkarsh DevSecOps Manifesto 235 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

Slide 236

Slide 236 text

@arafkarsh arafkarsh DevSecOps 236 Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools

Slide 237

Slide 237 text

@arafkarsh arafkarsh DevSecOps 237 Recommended by US DoD DevSecOps Best Practices Source: Page 17 US DoD Enterprise DevSecOps Fundamentals

Slide 238

Slide 238 text

@arafkarsh arafkarsh DevSecOps Pipeline 238 Source: US DoD DevSecOps Fundamentals Guidebook. Page 6

Slide 239

Slide 239 text

@arafkarsh arafkarsh SAST vs DAST 239 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.

Slide 240

Slide 240 text

@arafkarsh arafkarsh Risk Management Framework 240 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

Slide 241

Slide 241 text

@arafkarsh arafkarsh DevSecOps Playbook US DoD Enterprise DevSecOps 2.0 Playbook 241

Slide 242

Slide 242 text

@arafkarsh arafkarsh 6 DevSecOps Playbook 242 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

Slide 243

Slide 243 text

@arafkarsh arafkarsh Adopt a DevSecOps Culture 243 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

Slide 244

Slide 244 text

@arafkarsh arafkarsh Adopt Infrastructure as Code 244 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. Source: US DoD DevSecOps Fundamentals Playbook. Page 5

Slide 245

Slide 245 text

@arafkarsh arafkarsh Adopt Containerized Microservices 245 3 Source: US DoD DevSecOps Fundamentals Playbook. Page 6 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

Slide 246

Slide 246 text

@arafkarsh arafkarsh Adopt a Capability Model, not a Maturity Model 246 4 Source: US DoD DevSecOps Fundamentals Playbook. Page 7 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

Slide 247

Slide 247 text

@arafkarsh arafkarsh Drive Continuous Improvement through Key Capabilities 247 5 Source: US DoD DevSecOps Fundamentals Playbook. Page 8 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

Slide 248

Slide 248 text

@arafkarsh arafkarsh Drive Continuous Improvement through Key Capabilities 248 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 Source: US DoD DevSecOps Fundamentals Playbook. Page 8 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

Slide 249

Slide 249 text

@arafkarsh arafkarsh Establish a Software Factory 249 6 Source: US DoD DevSecOps Fundamentals Playbook. Page 9 • 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

Slide 250

Slide 250 text

@arafkarsh arafkarsh Define a meaningful DevSecOps pipeline 250 7 Source: US DoD DevSecOps Fundamentals Playbook. Page 10

Slide 251

Slide 251 text

@arafkarsh arafkarsh Adapt an Agile Acquisition Policy for Software 251 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. Source: US DoD DevSecOps Fundamentals Playbook. Page 11

Slide 252

Slide 252 text

@arafkarsh arafkarsh Tirelessly Pursue Cyber Resilience 252 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. Source: US DoD DevSecOps Fundamentals Playbook. Page 12

Slide 253

Slide 253 text

@arafkarsh arafkarsh Shift Left: Operational Test & Eval 253 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). Source: US DoD DevSecOps Fundamentals Playbook. Page 13

Slide 254

Slide 254 text

@arafkarsh arafkarsh 254 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India: +91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

Slide 255

Slide 255 text

@arafkarsh arafkarsh 255 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh

Slide 256

Slide 256 text

@arafkarsh arafkarsh 256 Slides: https://speakerdeck.com/arafkarsh

Slide 257

Slide 257 text

@arafkarsh arafkarsh DevSecOps 257 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

Slide 258

Slide 258 text

@arafkarsh arafkarsh Security 258 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

Slide 259

Slide 259 text

@arafkarsh arafkarsh Security 259 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/

Slide 260

Slide 260 text

@arafkarsh arafkarsh References 260 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

Slide 261

Slide 261 text

@arafkarsh arafkarsh References 261 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

Slide 262

Slide 262 text

@arafkarsh arafkarsh References 262 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 1. IBM: IaaS Explained 2. IBM: PaaS Explained 3. IBM: SaaS Explained 4. IBM: FaaS Explained 5. IBM: What is Hypervisor? Cloud Architecture

Slide 263

Slide 263 text

@arafkarsh arafkarsh References 263 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

Slide 264

Slide 264 text

@arafkarsh arafkarsh References – Microservices – Videos 264 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.

Slide 265

Slide 265 text

@arafkarsh arafkarsh References 265 Domain Driven Design 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

Slide 266

Slide 266 text

@arafkarsh arafkarsh References 266 Event Sourcing and CQRS 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

Slide 267

Slide 267 text

@arafkarsh arafkarsh References 267 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

Slide 268

Slide 268 text

@arafkarsh arafkarsh References 268 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?

Slide 269

Slide 269 text

@arafkarsh arafkarsh References 269 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

Slide 270

Slide 270 text

@arafkarsh arafkarsh References 270 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

Slide 271

Slide 271 text

@arafkarsh arafkarsh 271 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

Slide 272

Slide 272 text

@arafkarsh arafkarsh References 272 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

Slide 273

Slide 273 text

@arafkarsh arafkarsh References 273 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

Slide 274

Slide 274 text

@arafkarsh arafkarsh References 274 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

Slide 275

Slide 275 text

@arafkarsh arafkarsh References 275 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