$30 off During Our Annual Pro Sale. View Details »

Zero-Trust SASE DevSecOps

Zero-Trust SASE DevSecOps

Building Cloud-Native App Series - Part 15 of 15
Microservices Architecture Series
Zero Trust / SASE
Network / Security
Cisco SD-WAN / SD-Access
Cisco Secure Cloud Insights / Jupiter One
GRC / DevSecOps

Araf Karsh Hamid

June 01, 2022
Tweet

More Decks by Araf Karsh Hamid

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. @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
    8
    o Understand the Origin of
    Zero Trust
    o Issues with Perimeter
    Security
    o Zero Trust Concept based
    on NIST Standards
    o Implementing Zero Trust
    using Software Defined
    Perimeter
    o Understanding SASE
    Objectives

    View Slide

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

    View Slide

  10. @arafkarsh arafkarsh
    What Zero Trust is
    10
    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”

    View Slide

  11. @arafkarsh arafkarsh
    How ZERO TRUST should Help Organization
    11
    • Business Focused (Enables Business)
    • A (Architectural) State of Mind
    • Same Security Principles for Internet & Intranet
    • A Combination of Process and Technologies
    • Reduced Complexity
    • Better User Experience for SecOps and Partners
    Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds

    View Slide

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

    View Slide

  13. @arafkarsh arafkarsh
    Zero Trust: Access Management
    13
    • Least Privilege
    • Every Access is limited to a
    specific user, device, and
    app or resource only
    • Centralized
    • Policies are centralized
    across common IT Systems
    • Policies are defined by
    Business Team (Support
    from IT)
    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)

    View Slide

  14. @arafkarsh arafkarsh
    Zero Trust: Data
    14
    • Adopt the Principle of Least Privilege
    • Access to the Data MUST be limited to a Specific user, device
    and App or Resource Only
    • Identify the User Persona and limit the access based on that
    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

    View Slide

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

    View Slide

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

    View Slide

  17. @arafkarsh arafkarsh 17

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  23. @arafkarsh arafkarsh
    Google Beyond Corp: with NIST 800-207
    23
    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

    View Slide

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

    View Slide

  25. @arafkarsh arafkarsh
    NIST 800-207: Deployment Models
    25
    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

    View Slide

  26. @arafkarsh arafkarsh
    NIST 800-207: Resource Based
    26
    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.

    View Slide

  27. @arafkarsh arafkarsh
    NIST 800-207: Enclave Based
    27
    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.

    View Slide

  28. @arafkarsh arafkarsh
    NIST 800-207: Cloud Routed
    28
    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

    View Slide

  29. @arafkarsh arafkarsh
    NIST 800-207: Micro Segmentation
    29
    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

    View Slide

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

    View Slide

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

    View Slide

  32. @arafkarsh arafkarsh
    NIST 800-162: Attribute Based Access Control
    32
    A subject is a human user or NPE, such as a device that issues
    access requests to perform operations on objects. Subjects are
    assigned one or more attributes.
    An object is a system resource for which access is managed by
    the ABAC system, such as devices, files, records, tables,
    processes, programs, networks, or domains containing or
    receiving information. It can be the resource or requested
    entity, as well as anything upon which an operation may be
    performed by a subject including data, applications, services,
    devices, and networks.
    Source: Page 17 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final

    View Slide

  33. @arafkarsh arafkarsh
    NIST 800-162: Attribute Based Access Control
    33
    • An operation is the execution of a function at the request of a subject
    upon an object. Operations include read, write, edit, delete, copy,
    execute, and modify.
    • Policy is the representation of rules or relationships that makes it
    possible to determine if a requested access should be allowed, given the
    values of the attributes of the subject, object, and possibly environment
    conditions.
    • Environment conditions: operational or situational context in which
    access requests occur. Environment conditions are detectable
    environmental characteristics. Environment characteristics are
    independent of subject or object, and may include the current time, day
    of the week, location of a user, or the current threat level.
    Source: Page 17 NIST 800-162: https://csrc.nist.gov/publications/detail/sp/800-162/final

    View Slide

  34. @arafkarsh arafkarsh
    NIST 800-162: ABAC in Action
    34
    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.

    View Slide

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

    View Slide

  36. @arafkarsh arafkarsh
    ACL Trust Chain
    36

    View Slide

  37. @arafkarsh arafkarsh
    NIST 800-162: ABAC Trust Chain
    37

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. @arafkarsh arafkarsh
    Software Defined Perimeter: Architecture
    43
    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.

    View Slide

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

    View Slide

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

    View Slide

  46. @arafkarsh arafkarsh
    Forrester
    Wave:
    Zero Trust
    46

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  55. @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
    55

    View Slide

  56. @arafkarsh arafkarsh
    OSI Layers
    56

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  60. @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
    60
    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)

    View Slide

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

    View Slide

  62. @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
    62
    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

    View Slide

  63. @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
    63
    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

    View Slide

  64. @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: 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

    View Slide

  65. @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
    VNI: 100
    VNI: 200
    VSWITCH: Virtual Switch. | VTEP : Virtual Tunnel End Point | VNI : Virtual Network Identifier

    View Slide

  66. @arafkarsh arafkarsh
    GRE: Generic Routing Encapsulation
    66
    Created By Cisco RFC 2784 & updated by RFC 2890
    GRE is used to create a tunnel between 2 network over public network. It can carry any OSI L3 protocol over an
    IP Protocol. GRE creates a Point-2-Point connection like VPN by encapsulating the (original) payload.
    GRE Tunnels are not secured as the data is un-encrypted. For Secure tunnel use IPSec.
    202.1.2.1 204.1.2.1
    Public IP Public IP
    Branch 1 Branch 2
    Internet
    192.168.1.1/24 192.168.1.2/24
    $ Interface tunnel0
    ip address 192.168.1.1
    255.255.255.0
    ip mtu 1476
    ip tcp adjust-mss 1436
    tunnel source 202.1.2.1
    tunnel destination 204.1.2.1
    $ Interface tunnel0
    ip address 192.168.1.2
    255.255.255.0
    ip mtu 1476
    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

    View Slide

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

    View Slide

  68. @arafkarsh arafkarsh
    DM VPN: Dynamic Multipoint VPN
    68
    o GRE is a Point-2-Point VPN Tunnel.
    o DM VPN helps to create VPN to multiple sites.
    o It’s a Hub & Spoke Design and yet spoke will
    be able to talk to each other.
    o Encryption is supported using IPSec.
    o Its a great alternative to MPLS VPN.
    4 Critical Elements for DM VPN
    1. Multipoint GRE
    2. NHRP (Next Hop Resolution Protocol)
    3. Routing (RIP, EIGRP, OSPF, BGP etc.)
    4. IPSec (optional)
    Branch 1
    B2
    B3 B4
    Head
    Quarter GRE Tunnel
    GRE Tunnel
    GRE Tunnel
    GRE Tunnel
    GRE
    GRE Tunnel
    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
    GRE Tunnel
    Source: Cisco DM VPN

    View Slide

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

    View Slide

  70. @arafkarsh arafkarsh
    Multipoint GRE
    70
    GRE Tunnel
    GRE Tunnel
    GRE Tunnel
    GRE Tunnel GRE Tunnel
    B1 B2
    B3 B4
    HQ
    GRE Tunnel
    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
    .3
    .4
    .1
    .2
    NHC NHC
    NHC NHC
    NHS
    Hub & Spoke
    Topology
    B1 B2
    B3 B4
    Head
    Quarter
    .3
    .4
    .1
    .2
    NHC NHC
    NHC NHC
    NHS
    GRE Tunnel
    GRE Tunnel
    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
    .0
    .0

    View Slide

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

    View Slide

  72. @arafkarsh arafkarsh
    DM VPN: Multipoint GRE
    72
    B1
    B2
    B3 B4
    Head
    Quarter
    .3
    .4
    .1
    .2
    NHC
    NHC
    NHC NHC
    NHS
    mGRE Tunnel m
    GRE Tunnel
    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
    NHRP Request
    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

    View Slide

  73. @arafkarsh arafkarsh
    DM VPN: Multipoint GRE
    73
    B1
    B2
    B3 B4
    Head
    Quarter
    .3
    .4
    .1
    .2
    NHC
    NHC
    NHC NHC
    NHS
    mGRE Tunnel m
    GRE Tunnel
    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
    NHRP Request
    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

    View Slide

  74. @arafkarsh arafkarsh
    DM VPN: Multipoint GRE – Summary
    74
    B1
    B2
    B3 B4
    Head
    Quarter
    .3
    .4
    .1
    .2
    NHC
    NHC
    NHC NHC
    NHS
    mGRE Tunnel m
    GRE Tunnel
    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
    NHRP Request
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  87. @arafkarsh arafkarsh
    Software Defined – WAN: Zero Touch Provisioning
    87
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  93. @arafkarsh arafkarsh
    Security
    Cloud Security Architecture
    93

    View Slide

  94. @arafkarsh arafkarsh
    Hype cycle
    of Security
    Operations
    for 2021
    94

    View Slide

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

    View Slide

  96. @arafkarsh arafkarsh
    Built-In Security At Every Layer
    96
    Built-In
    Security
    at every Layer
    • Cloud Architecture is composed of Multiple
    Layers. From a Cloud Native App perspective
    Each Microservice is specific layer in the
    Application Stack.
    • Each Layer must be self defending.
    • Each Layer Must have a Security Layer to be part
    of Defense in Depth.
    • Depends on the Security Guidelines / Policies
    some of the security measures will be internal
    some external.
    Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute

    View Slide

  97. @arafkarsh arafkarsh
    Built-In Security At Every Layer
    97
    Stack Layer Controls
    1 Data
    Backup, Data Leak Prevention, Encryption in Transit
    and Rest.
    2
    Application Logic +
    Presentation
    Web App Firewall, Secure Web Gateway, Identity &
    Access Management, Scans / Pen Tests, Service Mesh
    Policies
    3 Network
    Access Controls, Firewalls, Service Mesh, Routing,
    DDoS Defense
    4 Operating Systems
    Backups, Configuration, Vulnerability Scanning, User /
    Privilege Management
    5 Hypervisor
    Configuration, Access Controls, User / Privilege
    Management
    Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute
    Built-In
    Security
    at every Layer

    View Slide

  98. @arafkarsh arafkarsh
    Built-In Security At Every Layer
    98
    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.

    View Slide

  99. @arafkarsh arafkarsh
    Think ”Components”
    99
    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

    View Slide

  100. @arafkarsh arafkarsh
    Design for Failure
    100
    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

    View Slide

  101. @arafkarsh arafkarsh
    Design for Elasticity
    101
    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

    View Slide

  102. @arafkarsh arafkarsh
    Make use of Different Storage Options
    102
    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

    View Slide

  103. @arafkarsh arafkarsh
    Always think of Feedback Loops
    103
    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

    View Slide

  104. @arafkarsh arafkarsh
    Focus on Centralization, Standards, Automation
    104
    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

    View Slide

  105. @arafkarsh arafkarsh
    Blast Radius
    105
    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.

    View Slide

  106. @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
    106

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  115. @arafkarsh arafkarsh
    Traditional VPN Vs. Zero Trust
    115
    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

    View Slide

  116. @arafkarsh arafkarsh
    Zero Trust – Security: Resource Based
    116
    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

    View Slide

  117. @arafkarsh arafkarsh
    Zero Trust – Security: Enclave Based
    117
    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

    View Slide

  118. @arafkarsh arafkarsh
    Zero Trust – Security: Cloud Routed
    118
    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

    View Slide

  119. @arafkarsh arafkarsh
    Zero Trust – Security: Micro Segmentation
    119
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  126. @arafkarsh arafkarsh 126
    Cisco
    Umbrella

    View Slide

  127. @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
    127
    Cisco SD-WAN Solution
    represents an evolution of
    networking from an older,
    hardware-based model to a
    secure, software-based, virtual
    IP fabric. Cisco SD-WAN fabric,
    also called an overlay network,
    forms a software overlay that
    runs over standard network
    transport services, including
    the public Internet, MPLS, and
    broadband.
    Source: Cisco SD-WAN Getting started Guide. Page 5

    View Slide

  128. @arafkarsh arafkarsh 128
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  134. @arafkarsh arafkarsh
    Cisco SD-WAN Zero Touch Provisioning
    134
    Send New Router
    (vEdge) Details
    DTLS
    DTLS
    vBond
    vSmart
    vEdge
    vManage
    Send IP
    Addresses
    of vManage
    & vSmart
    to vEdge
    Authentication
    DTLS /
    TLS
    Authentication
    vEdge
    vManage
    Send Full
    Configuration
    file for vEdge
    1 2
    DTLS / TLS
    Authentication
    vSmart
    OMP Session Established
    between vEdge & vSmart
    to exchange routes
    3
    vEdge
    IPSec
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  141. @arafkarsh arafkarsh
    Cisco DNA Center
    o Concept
    o Architecture
    141

    View Slide

  142. @arafkarsh arafkarsh
    Cisco DNA Platform
    142
    Source: Cisco DNA Assurance – Page 23

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  147. @arafkarsh arafkarsh
    Cisco ISE – Identity Services Engine
    147

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  152. @arafkarsh arafkarsh
    Cisco SD-Access
    152
    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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  165. @arafkarsh arafkarsh
    Cisco SD-Access: Benefits
    165

    View Slide

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

    View Slide

  167. @arafkarsh arafkarsh
    Gartner
    Magic
    Quadrant
    2021
    SD-WAN
    167

    View Slide

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

    View Slide

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

    View Slide

  170. @arafkarsh arafkarsh
    Cisco SecureX & Secure Cloud Insights
    170
    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.

    View Slide

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

    View Slide

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

    View Slide

  173. @arafkarsh arafkarsh
    Secure Cloud Insights: Policies
    173
    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.

    View Slide

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

    View Slide

  175. @arafkarsh arafkarsh
    Secure Cloud Insights: Compliance
    175
    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)

    View Slide

  176. @arafkarsh arafkarsh
    Secure Cloud Insights: Graph Viewer
    176
    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.

    View Slide

  177. @arafkarsh arafkarsh
    Secure Cloud Insights: Insights
    177
    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.

    View Slide

  178. @arafkarsh arafkarsh
    Secure Cloud Insights: Query Library
    178
    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

    View Slide

  179. @arafkarsh arafkarsh
    Getting Started with Search
    179
    1. Ask questions by typing in any keywords
    to search across all packaged/saved
    questions
    2. Full text search across all entities based
    on their property values
    3. JupiterOne Query Language (J1QL) for
    precise querying of entities and
    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 ...?

    View Slide

  180. @arafkarsh arafkarsh
    JupiterOne Query Language
    o Query Language Concepts
    o Query Language Structure
    o Examples
    180

    View Slide

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

    View Slide

  182. @arafkarsh arafkarsh
    Jupiter 1 Query Language
    182
    FIND {class or type of an Entity}
    Start with an Entity
    WITH {property}={value} AND|OR
    {property}={value}
    Optionally add some property filters
    THAT {relationship_verb}|RELATES
    TO {class/type of another Entity}
    Get its relationships
    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

    View Slide

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

    View Slide

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

    View Slide

  185. @arafkarsh arafkarsh
    J1QL: THAT
    185
    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)

    View Slide

  186. @arafkarsh arafkarsh
    J1QL: WHERE
    186
    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)

    View Slide

  187. @arafkarsh arafkarsh
    J1QL: RETURN
    187
    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.

    View Slide

  188. @arafkarsh arafkarsh
    J1QL: ORDER BY, SKIP, LIMIT
    188
    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.

    View Slide

  189. @arafkarsh arafkarsh
    J1QL: Aggregate Functions: Count, Min, Max, Avg & Sum
    189
    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.

    View Slide

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

    View Slide

  191. @arafkarsh arafkarsh
    J1QL: Part 1 Simple Root Query
    191
    The JupiterOne Query Language (J1QL) is a query language for finding the entities and relationships
    within your digital environment. J1QL blends together the capabilities of asking questions,
    performing full text search, or querying the complex entity-relationship graph.
    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.)

    View Slide

  192. @arafkarsh arafkarsh
    J1QL: Part 1 Simple Root Query
    192
    The JupiterOne Query Language (J1QL) is a query language for finding the entities and relationships
    within your digital environment. J1QL blends together the capabilities of asking questions,
    performing full text search, or querying the complex entity-relationship graph.
    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.)

    View Slide

  193. @arafkarsh arafkarsh
    J1QL: Part 2 Infrastructure Analysis
    193
    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

    View Slide

  194. @arafkarsh arafkarsh
    J1QL: Part 2 Infrastructure Analysis
    194
    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:

    View Slide

  195. @arafkarsh arafkarsh
    J1QL: Part 2 Infrastructure Analysis
    195
    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

    View Slide

  196. @arafkarsh arafkarsh
    J1QL: Part 2 Infrastructure Analysis
    196
    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

    View Slide

  197. @arafkarsh arafkarsh
    J1QL: Part 2 Infrastructure Analysis
    197
    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

    View Slide

  198. @arafkarsh arafkarsh
    J1QL: Part 2 Infrastructure Analysis
    198
    2.6 Tagging Resources
    Tagging of resources (at source) can be quite useful and it will help to have a well-
    defined queries.
    Previous set of queries rely on following Default Tags
    o Classification
    o Owner
    o PII or PHI or PCI (Boolean type)
    o AccountName
    o Production
    All custom tags are prefixed with tag.. 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  202. @arafkarsh arafkarsh
    J1QL: Part 4 Cross Account Analysis
    202
    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?

    View Slide

  203. @arafkarsh arafkarsh
    J1QL: Part 5 Endpoint Compliance
    203
    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?

    View Slide

  204. @arafkarsh arafkarsh
    JupiterOne Data Models
    o Entities
    o Relationships
    204

    View Slide

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

    View Slide

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

    View Slide

  207. @arafkarsh arafkarsh
    J1: Relationships:
    207
    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

    View Slide

  208. @arafkarsh arafkarsh
    J1: Relationships:
    208
    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

    View Slide

  209. @arafkarsh arafkarsh
    JupiterOne
    o Architecture
    o Maturity Models
    o Data Models and Question Lists
    209

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  217. @arafkarsh arafkarsh
    People &
    Access
    Data
    Model
    217
    Source: JupiterOne Docs

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  239. @arafkarsh arafkarsh
    DevSecOps Playbook
    US DoD Enterprise DevSecOps 2.0 Playbook
    239

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  243. @arafkarsh arafkarsh
    Adopt Containerized Microservices
    243
    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

    View Slide

  244. @arafkarsh arafkarsh
    Adopt a Capability Model, not a Maturity Model
    244
    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

    View Slide

  245. @arafkarsh arafkarsh
    Drive Continuous Improvement through Key Capabilities
    245
    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

    View Slide

  246. @arafkarsh arafkarsh
    Drive Continuous Improvement through Key Capabilities
    246
    5
    Continuous Delivery
    1. Use a Source Code Repo for all production Artifacts
    2. Use Trunk based development methods
    3. Shift Left on Security
    4. Implement Test Automation
    5. Implement Continuous Integration
    6. Support Test Data Management
    7. Implement Continuous Delivery
    8. Automate the Deployment Process
    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

    View Slide

  247. @arafkarsh arafkarsh
    Establish a Software Factory
    247
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  254. @arafkarsh arafkarsh 254
    http://www.slideshare.net/arafkarsh

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  259. @arafkarsh arafkarsh
    References
    259
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide