We are in the process of revising the patterns in the library to ensure they are consistent, and simplify where possible. One idea is that we should create a few additional modules to reduce the number of controls that are specified on each pattern.

The set of modules could be:

• DMZ- new module to show standard DMZ environment for hosting applications or connections to untrusted networks or systems
• High Security Network Zone- new module to show high security environment for hosting sensitive applications such as Finance and HR systems, Payment processing, Source code repository etc
• Information Security Management System- new module for the baseline controls required for IS management of environment
• Client- existing module that shows baseline set of controls for clients
• Server- existing module that shows baseline set of controls for servers

Hoping to make some progress on these in the next month or so. Drop us a line if you want to contribute.

Finally got around to adding the padlock item to the icon library. Not very exciting, but I thought I'd mention it :-)

For 10 years agile development has been finding more and more followers and practitioners. It seems like a sure bet that SCRUM will be the leading process skeleton for lean and agile project management. As for most new technologies also processes and frameworks go through a hype-cycle. At this moment we know a lot about the advantages of SCRUM and maybe we know too little about the pitfalls.

In the area of security SCRUM does have some dangerous assumptions which I personally believe will prove to be major challenges in getting security right in development projects. Let me just mention two here:

• SCRUM assumes that in the team everyone should be able to deal with all aspects of the solution, which would lead us to assume that all developers need to be knowledgeable in security controls and secure programming. However in all the successful projects that I have seen there was a security expert that joined the team almost on a daily basis. I believe the same is true by the way for other non-functional aspects like usability. Not sure what Ken Schwaber thinks about this but I firmly believe that the team works best if team members bring their strengths together. One is interested in security, another is interested in usability (and great design), a third is interested in database scalability and off you go with a great team :). It is good to have a backup in case someone leaves the project but that comes at a cost.
• SCRUM is a project management skeleton but not a software engineering process. Scrum does not tell you how to come up with requirements, it does not tell when and how to integrate and test, and it does not tell how to build a lasting architecture, nor does it have anything to do with secure coding practices. This is not to blame SCRUM for this. SCRUM is great because it is simple and it focuses on very few aspects like prioritizing resources and interacting with stakeholders.

All I intend to say here is; please don't try to invent a secure SCRUM because security is better placed in a solution development life cycle than a process skeleton. And a great lean process skeleton should not be overloaded. If anything SCRUM should be more specific about project and solution risk management. Two years ago an interesting column was posted on infoq (http://www.infoq.com/news/2008/07/managing-risk-with-scrum). 

What are your experiences?

An OSA reference has been included into the recent O'Reilly book "Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance" by Tim Mather et al. The Cloud Computing pattern from the patterns library is reproduced in the Appendix. We are pleased to be of assistance in a small way, for a solid reference work on the topic.

If you are interested in reading further on the topic you can find it here on Amazon