Scaled Agile Framework
Overview for Security and Privacy Specialists / Ops from DevOps Teams
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
1
Disclaimers
Not an in-depth briefing
SAFe treats security as one among many quality attributes
Also consider hybrid models and/or Site [Service] Reliability Engineering
Credit: Some content adapted from Scaled Agile materials
♫ = Personal “Professional” Opinion
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
2
SAFe: Built from Borrowed Concepts
 Lean
 Agile
 DevOps
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
3
 Composable Services ♫
 MBSE ♫
 OOP ♫
 Quality (ISO 9001, PDCA) ♫
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
4
Lean-Agile Principles5
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
6
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Core Values
in SAFe
7
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
1. Alignment
2. Fully integrated quality
3. Transparency
4. Program Execution
Agile Manifesto
 Individuals and interactions
over processes and tools
 Working software over
comprehensive
documentation
 Customer collaboration over
contract negotiation
 Responding to change over
following a plan
8 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
More of the Agile Manifesto
 1. Satisfy customer through early and continuous delivery
 2. Welcome changing requirements, even late in development.
 3. Deliver working software frequently
 4. People and developers must work together daily throughout a project
 5. Build projects around motivated people; support them; trust them
 6. Face to face conversation
 7. Working software is the primary measure of progress
 8. Agile processes promote sustainable development
 9. Continuous attention to technical excellence and good design enhances agility
 10. Simplicity – maximizing the amount of work not done – is essential
 11. Best architectures, requirements, designs emerge from self-organizing teams
 12. Teams regularly reflect on how to become more effective, then tune & readjust
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
9
SAFe Lean-Agile Principles10
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
11
Deming Cycle
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
12
Program Increment Planning
 “No event is more powerful than PI
planning. It’s the magic in SAFe.”
 “Teams create and take responsibility for
plans.”
 “Stakeholders appear face to face.”
 “Requirements and design emerge.”
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
13
 Requirements engineering depends on
story fidelity
 Story fidelity is more art than design
pattern
 Security is a bit player
 Privacy, compliance? Sometimes a starring
role
Architectural Runway14
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Delay-centric Optimization15
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
“Visualize and limit
WIP, reduce batch
sizes and manage
queue lengths.”
Ops issues such as
latency, scalability,
robustness
“Continuous
Exploration”
 Less well integrated in SAFe
 R&D
 Professional associations,
SDO’s, consortia
16 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Cadence and Synchronization
for Security & Privacy
17
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Most Powerful Principle18
“Iterate toward the sustainably
shortest lead time with best
quality and value to people and
society.”
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Security First? ♫
Not even close.
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
19
Symptom, not
Diagnosis ♫
 “Security is an afterthought.”
 “Security is tacked on.”
 “Security needs to be designed
in at the beginning.”*
 *My choice for the most
pernicious
20 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Applications Rule! ♫
 Unless you’re building a security tool, security is not even a stakeholder
 Applications are (almost) never about security
 Discussing security is a distraction from good story-craft
 By “security” customers mean:
 Privacy
 Functional features (e.g., “controls”) in a domain
 Expression of distrust in a process / developer team / internal competitors
 Indirectly express lack of awareness about security/privacy standards
 Dependencies
 Operations work as Apps, but it’s not a 1:1 mapping
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
21
“Secure Code” Reality Check ♫22
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
15-20% defects remain after
static/dynamic scans
Bug-free software production is beyond
the current state of the art
Goal subtracts from more important
objectives (sustainability, manageability,
risk, usability, maintainability, customer
needs)
Enablers
. . . To the rescue
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
23
SAFe Support for Security/Privacy
 Frequent iteration
 Automated test
 Shorter sprints
 Left-shifted test development
 Immersion with quality dimensions in value streams
 Nurture domain-rich security through “knowledge worker” focus
 Depicts security teams/artifacts as enablers, not blockers
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
24
Security as Quality ♫
So far, an insight external to SAFe
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
25
Meanwhile, at the Retrospective . . . ♫
 Enablers have different life cycles in different enterprises / projects
 Retrospectives often hint at enabler gaps
 Cut and paste
 Role of R&D
 Domain specific languages
 Repository deployment, discovery, development
 Maturing the CI/CD for security/privacy
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
26
Test Engineering
Security as test and vice versa
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
27
Frequent System Demos
 For security, as with quality, manageability, monitoring:
 Test must be fully integrated
 Left-shifted
 Tagging and annotation are valuable stubs when used with an orchestrator
 Increase reliance on IDE support
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
28
Deconstructing
“Configuration
Error”
29
 Developer or Insfrastructure engineering problem?
 Common Operations Responsibility
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Security is a Specialization ♫
 Haphazard coverage in college level software engineering
 Reflecting indifference?
 Reflecting moving target, weak domain integration
 Consider how a rheumatologist engages a neurologist
 Some (few?) software engineers will become security specialists
 (nor should they have to)
 Each operation (e.g., Akamai or Palo Alto firewall specialist) role is specialized
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
30
Legacy
“Over-the-
wall” Test
Engineering
♫
31
 Some hardening may require aggressive red teaming
 New paradigm
 Not part of, but supported by SAFe
 Mix of legacy and software-defined data centers
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Teaching Toys ♫
 “Zero Trust”
 Do what the unicorns do
 Many organizations (must) manage code written before Google was founded
 Security and capacity / performance management are unrelated
 Terraform
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
32
Security as Code ♫
Yes, partly, but also knowledge engineering for domain-aware safety
frameworks.
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
33
Decision
Support ♫
34
 Derive from a full Integration with quality
 What telemetry to support decision-making?
 Security incidents, use cases may require human
intervention
 Need for models & simulation
 Earlier, often, incrementally available
 Risk may need HCI engagement
 Support for operations support tooling / dashboard-
style management
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Security Big
Data ♫
35
 Old: Applications telemetry as “signature,” “snapshot”
 Now: Application telemetry will exceed the scale of most
applications
 No telemetry, no analytics
 Security Analytics -> Complex Event Processing -> Data
science
 Dashboards for big data are still emerging from the data
science community
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
HCI in Security and Privacy♫
Human - Computer Interaction
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
36
Repo’s,
Discovery &
Design
Patterns ♫
37
 What are these patterns?
 SAFe offers some ideas, solutions, enablers
 CNCF community is part of this ecosystem, but how?
 What is an Ops Repo? Is it teachable?
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Stories and
Domain
Knowledge ♫
38
 Stories = Natural Language = Complex
 Security stories (e.g., OWASP -> an application domain)
 Domain expertise supersedes security expertise
 Are operations stories similar or different?
 Is Ops a stakeholder?
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Technical Debt and Backlog
 Sometimes security dumping grounds
 Ops technical debt is . . . What?
 Failure to measure
 Telemetry gap
 Failure to design manageability
 Exogenous events
 New/updated integration points
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
39
The Enterprise
Lens in SAFe
40
 Small teams (e.g., CNCF teams)
 API-First
 Legacy software (owner, developer,
infrastructure)
 Product/Release Centered (vs. SRE)
 What is a “Product Owner” ?
 Simplistic views of
 Knowledge Management (vs.
CKO)
 Data / Application Management
(CDO)
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
Systemic Security Risks:
Termites in the House of Security ♫
 RBAC instead of ABAC
 The Admin Syndrome
 Short-sighted understanding of test engineering
 Weak adoption of ModSim
 Weak automation
 Excessive dependence on static / dynamic testing
 Risk registers are oil to security water
 Supply chain (especially OSS)
 “Machine Learning (‘AI’) will fix it”
 Frameworks (e.g., 800-53, etc., are too manual)
 DevSecOps based on weak software engineering (bash, CLI, no OOP)
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
41
Contact
@knowlengr dark@computer.org
www. scaledagile.com
Presented to CNCF Sig Security 2020-04-01
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
42

Security within Scaled Agile

  • 1.
    Scaled Agile Framework Overviewfor Security and Privacy Specialists / Ops from DevOps Teams Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 1
  • 2.
    Disclaimers Not an in-depthbriefing SAFe treats security as one among many quality attributes Also consider hybrid models and/or Site [Service] Reliability Engineering Credit: Some content adapted from Scaled Agile materials ♫ = Personal “Professional” Opinion Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 2
  • 3.
    SAFe: Built fromBorrowed Concepts  Lean  Agile  DevOps Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 3  Composable Services ♫  MBSE ♫  OOP ♫  Quality (ISO 9001, PDCA) ♫
  • 4.
    Mark Underwood @knowlengr| Views my own | ShareAlike | v1.1 4
  • 5.
    Lean-Agile Principles5 Mark Underwood@knowlengr | Views my own | ShareAlike | v1.1
  • 6.
    6 Mark Underwood @knowlengr| Views my own | ShareAlike | v1.1
  • 7.
    Core Values in SAFe 7 MarkUnderwood @knowlengr | Views my own | ShareAlike | v1.1 1. Alignment 2. Fully integrated quality 3. Transparency 4. Program Execution
  • 8.
    Agile Manifesto  Individualsand interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan 8 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 9.
    More of theAgile Manifesto  1. Satisfy customer through early and continuous delivery  2. Welcome changing requirements, even late in development.  3. Deliver working software frequently  4. People and developers must work together daily throughout a project  5. Build projects around motivated people; support them; trust them  6. Face to face conversation  7. Working software is the primary measure of progress  8. Agile processes promote sustainable development  9. Continuous attention to technical excellence and good design enhances agility  10. Simplicity – maximizing the amount of work not done – is essential  11. Best architectures, requirements, designs emerge from self-organizing teams  12. Teams regularly reflect on how to become more effective, then tune & readjust Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 9
  • 10.
    SAFe Lean-Agile Principles10 MarkUnderwood @knowlengr | Views my own | ShareAlike | v1.1
  • 11.
    Mark Underwood @knowlengr| Views my own | ShareAlike | v1.1 11
  • 12.
    Deming Cycle Mark Underwood@knowlengr | Views my own | ShareAlike | v1.1 12
  • 13.
    Program Increment Planning “No event is more powerful than PI planning. It’s the magic in SAFe.”  “Teams create and take responsibility for plans.”  “Stakeholders appear face to face.”  “Requirements and design emerge.” Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 13  Requirements engineering depends on story fidelity  Story fidelity is more art than design pattern  Security is a bit player  Privacy, compliance? Sometimes a starring role
  • 14.
    Architectural Runway14 Mark Underwood@knowlengr | Views my own | ShareAlike | v1.1
  • 15.
    Delay-centric Optimization15 Mark Underwood@knowlengr | Views my own | ShareAlike | v1.1 “Visualize and limit WIP, reduce batch sizes and manage queue lengths.” Ops issues such as latency, scalability, robustness
  • 16.
    “Continuous Exploration”  Less wellintegrated in SAFe  R&D  Professional associations, SDO’s, consortia 16 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 17.
    Cadence and Synchronization forSecurity & Privacy 17 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 18.
    Most Powerful Principle18 “Iteratetoward the sustainably shortest lead time with best quality and value to people and society.” Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 19.
    Security First? ♫ Noteven close. Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 19
  • 20.
    Symptom, not Diagnosis ♫ “Security is an afterthought.”  “Security is tacked on.”  “Security needs to be designed in at the beginning.”*  *My choice for the most pernicious 20 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 21.
    Applications Rule! ♫ Unless you’re building a security tool, security is not even a stakeholder  Applications are (almost) never about security  Discussing security is a distraction from good story-craft  By “security” customers mean:  Privacy  Functional features (e.g., “controls”) in a domain  Expression of distrust in a process / developer team / internal competitors  Indirectly express lack of awareness about security/privacy standards  Dependencies  Operations work as Apps, but it’s not a 1:1 mapping Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 21
  • 22.
    “Secure Code” RealityCheck ♫22 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 15-20% defects remain after static/dynamic scans Bug-free software production is beyond the current state of the art Goal subtracts from more important objectives (sustainability, manageability, risk, usability, maintainability, customer needs)
  • 23.
    Enablers . . .To the rescue Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 23
  • 24.
    SAFe Support forSecurity/Privacy  Frequent iteration  Automated test  Shorter sprints  Left-shifted test development  Immersion with quality dimensions in value streams  Nurture domain-rich security through “knowledge worker” focus  Depicts security teams/artifacts as enablers, not blockers Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 24
  • 25.
    Security as Quality♫ So far, an insight external to SAFe Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 25
  • 26.
    Meanwhile, at theRetrospective . . . ♫  Enablers have different life cycles in different enterprises / projects  Retrospectives often hint at enabler gaps  Cut and paste  Role of R&D  Domain specific languages  Repository deployment, discovery, development  Maturing the CI/CD for security/privacy Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 26
  • 27.
    Test Engineering Security astest and vice versa Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 27
  • 28.
    Frequent System Demos For security, as with quality, manageability, monitoring:  Test must be fully integrated  Left-shifted  Tagging and annotation are valuable stubs when used with an orchestrator  Increase reliance on IDE support Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 28
  • 29.
    Deconstructing “Configuration Error” 29  Developer orInsfrastructure engineering problem?  Common Operations Responsibility Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 30.
    Security is aSpecialization ♫  Haphazard coverage in college level software engineering  Reflecting indifference?  Reflecting moving target, weak domain integration  Consider how a rheumatologist engages a neurologist  Some (few?) software engineers will become security specialists  (nor should they have to)  Each operation (e.g., Akamai or Palo Alto firewall specialist) role is specialized Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 30
  • 31.
    Legacy “Over-the- wall” Test Engineering ♫ 31  Somehardening may require aggressive red teaming  New paradigm  Not part of, but supported by SAFe  Mix of legacy and software-defined data centers Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 32.
    Teaching Toys ♫ “Zero Trust”  Do what the unicorns do  Many organizations (must) manage code written before Google was founded  Security and capacity / performance management are unrelated  Terraform Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 32
  • 33.
    Security as Code♫ Yes, partly, but also knowledge engineering for domain-aware safety frameworks. Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 33
  • 34.
    Decision Support ♫ 34  Derivefrom a full Integration with quality  What telemetry to support decision-making?  Security incidents, use cases may require human intervention  Need for models & simulation  Earlier, often, incrementally available  Risk may need HCI engagement  Support for operations support tooling / dashboard- style management Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 35.
    Security Big Data ♫ 35 Old: Applications telemetry as “signature,” “snapshot”  Now: Application telemetry will exceed the scale of most applications  No telemetry, no analytics  Security Analytics -> Complex Event Processing -> Data science  Dashboards for big data are still emerging from the data science community Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 36.
    HCI in Securityand Privacy♫ Human - Computer Interaction Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 36
  • 37.
    Repo’s, Discovery & Design Patterns ♫ 37 What are these patterns?  SAFe offers some ideas, solutions, enablers  CNCF community is part of this ecosystem, but how?  What is an Ops Repo? Is it teachable? Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 38.
    Stories and Domain Knowledge ♫ 38 Stories = Natural Language = Complex  Security stories (e.g., OWASP -> an application domain)  Domain expertise supersedes security expertise  Are operations stories similar or different?  Is Ops a stakeholder? Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 39.
    Technical Debt andBacklog  Sometimes security dumping grounds  Ops technical debt is . . . What?  Failure to measure  Telemetry gap  Failure to design manageability  Exogenous events  New/updated integration points Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 39
  • 40.
    The Enterprise Lens inSAFe 40  Small teams (e.g., CNCF teams)  API-First  Legacy software (owner, developer, infrastructure)  Product/Release Centered (vs. SRE)  What is a “Product Owner” ?  Simplistic views of  Knowledge Management (vs. CKO)  Data / Application Management (CDO) Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
  • 41.
    Systemic Security Risks: Termitesin the House of Security ♫  RBAC instead of ABAC  The Admin Syndrome  Short-sighted understanding of test engineering  Weak adoption of ModSim  Weak automation  Excessive dependence on static / dynamic testing  Risk registers are oil to security water  Supply chain (especially OSS)  “Machine Learning (‘AI’) will fix it”  Frameworks (e.g., 800-53, etc., are too manual)  DevSecOps based on weak software engineering (bash, CLI, no OOP) Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 41
  • 42.
    Contact @knowlengr dark@computer.org www. scaledagile.com Presentedto CNCF Sig Security 2020-04-01 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1 42