This chapter is from the book
This chapter is from the book
This chapter is from the book
On Confluence
In larger organizations one would expect to find more specialization, which is also true for security folks. Today, in our experience, one often finds IT security practitioners in large shops who elected that specialty early in their careers, and have little or no background in application design and coding. They are likely to be well versed in the latest attacks, and can be experts in setting parameters for firewalls and similar devices, and interpreting the log files. But several fine network security engineers of our acquaintance have no programming skills at all, whereas many others feel they are doing well to cobble together a functional PERL script to manipulate log files. This is the state of the practice today, and one of the drivers behind the need for confluence.
As we’ve said previously, one of the many key elements of success in addressing security issues properly from the beginning is confluence among the development and security teams. To be sure, many other stakeholders need to be included in the process as well, but none so clearly and comprehensively as these two. The overall process of teams and stakeholders’ selection and considerations for doing it are explained in Chapter 2, “Project Inception.” The thinking and consideration that should go into designing a business application are clear examples and opportunities of this confluence.
Microsoft’s SDL process stresses this concept in a different way. Their cornerstones include both a Software Security Group (SSG) and people in a security advisor (SA) role, who act as the primary point of contact for all things security in product development. Note that, organizationally, SAs can belong either to the SSG or to the development organization, but work very closely with the security professionals. As such, they are advocates for the developers, not part of review or audit process that might at times be viewed as an adversarial role. We wholeheartedly support this concept and further believe it to be a vital success factor for developing a secure application system. Existence of such a formal security structure also helps with obtaining a senior management’s mandate for following SDL practices and enforcing it consistently at all stages of product life cycle, because grass-roots efforts often do not work well with security.
We make it a point to describe key collaborative opportunities throughout this book, but perhaps the most important aspect of this exists here during the design process. No matter how rigorously your team engages in design activities, you’re more than likely to be successful if you’re able to reach out to all the stakeholders and include them as active participants in the design process. Having said that, care should be taken to clearly set roles and responsibilities, in order to prevent a “too many cooks in the kitchen” sort of situation. It is one thing to reach out to a stakeholder and solicit input; that is completely different than handing the helm over to the stakeholder.
In our experience, we’ve often found design review processes in which various stakeholders are included, but more often than not, the gating functions have been primarily business related and not security related. For example, can the application be developed within budget? Will it be delivered on time? Is the expense justifiable? Although this is all good and essential to do, we feel that security concerns need to also be included as early as possible, and that means including the security stakeholders in the process.