Abortion Pills In Pretoria ](+27832195400*)[ 🏥 Women's Abortion Clinic In Pre...
Security within Scaled Agile
1. Scaled Agile Framework
Overview for Security and Privacy Specialists / Ops from DevOps Teams
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
1
2. 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
3. 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) ♫
7. 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
8. 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
9. 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
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
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 well integrated in SAFe
R&D
Professional associations,
SDO’s, consortia
16 Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
18. 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
19. Security First? ♫
Not even 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” 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)
23. Enablers
. . . To the rescue
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
23
24. 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
25. Security as Quality ♫
So far, an insight external to SAFe
Mark Underwood @knowlengr | Views my own | ShareAlike | v1.1
25
26. 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
27. Test Engineering
Security as test 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
30. 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
31. 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
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
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
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 Security and 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 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
40. 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
41. 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