How did the old system work?

Missed frst 3-4 minutes of the webinar

Bad
Security team was Single Point of failure.
Change needed
Need to get involved earlier
Before the sprint started before planning meeting
Need to get team committed to security
Distribute workload
What does security in Agile SDLC look like?
Scrum roles parallels
Security Architect corresponds to Product Owner (strategic
Security Engineer corresponds to Team member (tactical involvement will do
security work)
Security Grooming
SA grooms the backlog with PO
Go thru stories that have already been groomed but from a security perspective
See which items need security tasks
Put requirements into the acceptance criteria of a development story
Security grooming meetings is a form of light weight threat modeling
There may be follow-up secure design reviews
Planning session
Dev stories have formal security sub tasks
Can be distributed to security engineers or team members
Goal if to fnd and fx potential issues within the sprint
For this new system
Good
Much more involved in story discussions
Better visibility around tracking
More scalable with distributed workload
Bad
More people involved
Increased complexity
More process have to defne something that works across all teams tricky to get
right!
Change Needed
Better training wise (devs learn)
Security into other aspects such as QA, release etc
Exceptions or special cases (e.g Sustaining Engineering that works on tech debt)
Using kanban instead of scrum
Have to fnd new ways to work with them
Relying on tech lead to get latest information
Doing static analysis at each sprint
Ton of automations around launching code analysis with build kick-of
Scale Factor
System is good but adding devs faster than security engineers not scalable
Transition the security responsibilities to the team
Security Champions/Ambassadors
Identify volunteers per scrum team
Teach them security skills so they can do routine tasks such as checking for XSS etc.
Teach QA pen testing
Precise coding guidelines tailored for each product
We still have a responsibility to keep their skills fresh
Know when to escalate to security team for non-routine
Challenges Faced
Rogue dev work
Happening outside of scrum/sprint/team
Unplanned work
Newer scrum teams
Specially people new to the company don't get the value proposition
Tough to get them to take the process seriously
There is pushback
We should socialize well and let them know why it is important
Grooming is very important. But if teams don't do that, fnd points where
you can inject yourself
Scrum rigor and practicality
Ideally this should scale well (hire more engineers) but we don't have
unlimited piles of money
Security Champion program is good but doesn't replace a security
engineer with years of experience
Everyone will have to make compromises and there will be tension
From the management side, continuously socialize and reafrm executive
support
Be aware of dev pain points, and respect them. Work with their process
and they will respect yours
Find ways to reduce fction otherwise your process will be viewed as a
roadblock
General Advice
Constantly think about how you can tweak the process. After all, that is the
core fundamental of agile/scrum
Generic approaches don't work well. Take the concepts and customize
them to your way to building products.