"Why they're called a 'buddy', I don't know. It's kind of like calling my IRS auditor my 'buddy'."
(Non securitur: "If you give me the right hardware, I can probably get Excel to bring me more iced tea.")
[The immediate problem I'm seeing with this (presumably canonical) SDL model is that waterfall doesn't work for security, because there are always new threats, so, e.g., the threat model is out of date before it's even been written. "Final security review" especially doesn't seem meaningful. I might be jumping ahead as far as this process really needing to be agile instead.]
"How many of you wait until the end to get performance right? Do you do a 'performance push'?"
Agile! Here we go!
How do we get the same gains with a less-heavy process and less up-front design?
Security is just as much a part of every developer's job as, e.g., reliability
Appoint a Security Owner, preferably one who cares whether the app is secure or not, whose responsibility it will be to ensure that the team meets security goals day-to-day
Need to train every developer to know what a security bug looks like
Agile Threat Modeling
Lightweight, rapid
Sketch DFD on whiteboard
Include threat mitigations in the feature backlog
Does management want to learn how insecure your app is from you... or from a hacker?
Use code-scanning tools daily or weekly
Peer code review; anything that increases quality, increases security
Check for banned APIs at code check-in time?
Crypto: don't try this at home. Hire a pro to review.
Unit-level, object-level security testing; write at same time as functional tests
"Throw some evil inputs at it" when running tests
Security Push is good to get everybody's head in the game, and/or for legacy cleanup, but all the rest of the time security needs to be every day, every sprint, whatever
We could make Agile the more secure development approach... it lends itself, we just don't capitalize (yet)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment