Today I led SCARB, our internal Security Coding and Architecture Review Board, in a software security related meeting. As always seems to be the case, I found the agenda changing repeatedly up to and including half an hour before the start. Now that I think of it, in fact that agenda actually kept changing after the start of the meeting, too...
But that wasn't a bad thing! Thanks in part to the vagaries of the way these meetings are set up and run, we ended up with a larger than usual committee, and with representatives from across several different projects: Windows Forms, Web, and both; CQRS and relational; old and new. My presentation, detailing a good half dozen specific security related issues - and their mitigation - in one project, drew comments about the desirability of software and system security reviews in practice, and specifically mentioning the obvious advantages of starting such processes at the same time as the projects themselves.
People seem to particularly like concrete examples. Now, to obtain examples from your own code base, you have to have done a partial security review already. Which was in fact the case for us, at least with two of the projects concerned. Both had previously been taken into the stages of developing a data flow diagram of the system, and of identifying processes, data stores, data flows and the trust boundaries where the vulnerability categories must be investigated.
Now I know what I need to get buy-in, and push the review process further. More examples! SQL injection attacks that work and are demonstrable. XSS attacks, likewise. These can be taken from many resources available around the Internet, but I guess the closer to your own app in terms of applicability, the better. They'll also provide an excellent way of opening the mind to the plethora of attack vectors available to the attacker, encouraging the inclusive, brainstorming, "yes - and..." approach vital to the success of the review process.
And next time, we will have a game of cards.
No comments:
Post a Comment