-
Get a monthly update on best practices for delivering successful software.
Security is often an after thought, slated towards the end of a project, or after some big issue has been discovered, but the nature of security functionality, rules, roles, auditing, etc make it hard to layer in to an existing codebase effectively.
Oh, and if the code base isn't sufficiently tested, you're in for a world of hurt.
If you are a developer that was just asked to 'do a quick security check and plug any holes', you are now in the difficult position of managing the expectation that a two-week security review means "we're covered". Be realistic about what you can accomplish, setting out some short-term and long-term goals.
Instead of pushing for more time to be able to 'cover it all' (even though you have no idea what 'it all' is yet), it might be better to start with a shorter analysis phase, where you detail your findings, identify any trends, and include recommendations for process change. I've found that even the most demanding manager is appreciative and understanding when you ask for a small amount of time in order to produce a better estimate, than to just immediately demand more time without any evidence as to why.
With your analysis and recommendations in hand,
you'll be in a better place to give an estimate on what it will take to correct the problems, and any potential side-effects, (ie. "our legacy data partners might not be able to implement their side of this new security plan on time"). Plus, the team can decide which items are the highest priority, and more importantly, you'll have put some practices in place to prevent any new security issues from slipping in later.
Because we are never really 'finished' with security, now would be a good time to schedule the next security review, tapping another member of the team to head it up (with your guidance), so that everyone knows that security is something they should be thinking of. Instead of doing a single 'big-bang' security audit headed by one person under an unrealistic deadline, you'll rotate the responsibility through the entire team, taking smaller more managable bites, and educating everyone in the process. Eventually your 'security-review' will be a natural part of the iteration and your everyday work.
(Tomorrow I'll post a quick checklist of general areas to look into for web application security.)
This same 'analyze, prioritize, estimate, rotate' technique could be applied to any 'big-bang' approach, such as:
Your team will get into a rhythm and become more efficient as the knowledge is evenly distributed. But more importantly your customers will appreciate the stability of having smaller but more frequent changes instead of massive buggy 'overhauls'. They'll see bugs getting fixed faster, and notice that little things that have bothered them for awhile are also getting fixed. Who knows, they might even give you the feedback that leads to your next million dollar idea!
Related posts:
[...] Yesterday’s post I said I’d put together a quick list of things to think about around web application security. This [...]
Pingback by Agile Ajax » Web app security checklist (Braindump) » Pathfinder Development, Thursday, May 14, 2009 @ 3:21 pm
[...] best to plan for bugs, I was asked to do a last minute Security Analysis, and I wrote a post about How to avoid the last minute security review, and I think that the planning part can actually apply to how you manage a big list of bugs as [...]
Pingback by Agile Ajax » Scrum defined in under 10 minutes » Pathfinder Development, Monday, May 18, 2009 @ 10:22 am