In the Microsoft TechNet Viewpoint article “Security Policies in the Application Development Process,” John Steer discusses the importance of an organization having a well-defined security policy and applying this policy to the application development lifecycle. Examining this from the perspective of a software developer, it is difficult to disagree with his points. It does seem, however, that Steer brushes past a few key reasons why an organization may fail to create secure applications.
Initially the general reasons for why a security policy is in place are discussed. Steer uses ISO17799 to provide a definition for a security policy and rightly points out that a security policy is not created as part of the development process. Instead the security policy provides guidelines so security requirements are known and can be implemented into the software during the development process. He does, however, overlook that a security policy may fail during the development process in a couple of ways. First, if a security policy fails to address some important security consideration it may be worthwhile for those involved in the development process to bring this to the attention of the organization. Second, a security policy will in many cases not be able to address many of the security concerns faced by the development team in terms of actual security issues related to the coding process. It is important for a development team to make their own list of security concerns that are specific to software development.
Next Steer discusses that while many organizations have comprehensive security policies that address both physical and information infrastructure, in many cases this is not extended to software development. He states that in order for security to be a part of the application architecture that developers must understand the requirements stated in the security policy. While this is most certainly true, one of the difficulties may be putting the security policy in terms that make sense to the development process. It is easy to have the security policy say “passwords are required,” but when applied to the development of an application if a simple password is allowed that technically meets the requirement of the security policy but does not conform to the actual meaning behind the policy.
Steer then attempts to provide an answer to why security is overlooked. He says that organizations often place low importance on the development of secure software, and continues that this is often not even realized. By failing to provide security policies during the application design phase, security features are omitted at the application level. He gives another example where security is added later on but implemented without using a corporate policy, stating that when asked one reason he has been given is that policies are not made available to the development staff. He should question if it is really an issue of the development staff not having access to security policies, or if it has more to do with the policies themselves. If individuals with little understanding of software development create the policies, it is easy to imagine the security policies being convoluted and difficult for the development team to understand what is being asked and how this could apply to software development. It is important for someone familiar with software development to be involved in the process of actually creating the security policy. Steer does mention that security is often viewed as being costly and says he disagrees with this assessment. What he fails to address, however, is that often the budget and those outside of the development team set time constraints for software development. If when giving initial estimates and projections the development team fails to mention the importance of strong implementation of security this may be left out of the time table and budget, meaning once this is brought forward as a significant issue to consider it may suddenly be considered too costly or time consuming to implement. It is important for the software development team to not overlook security in the initial stages of a project, and in many cases it is not hard to imagine developers wanting to get right into the ‘meat’ of a project failing to consider steps to implement secure architecture.