Security Policies in the Application Development Process

By John Steer
CISSP, Senior Security Consultant, Microsoft ACE Services

See other Viewpoint articles.

Since 2001, I have participated in many application code reviews, covering both managed and unmanaged code. As part of the Application Consulting & Engineering (ACE) Services team for Microsoft, my reviews include internal Microsoft IT applications, along with consulting for external Microsoft customers (such as ISVs, enterprise customers, and the public sector). During these reviews, one thing I look at to determine the security of an application is the initial security effort that was put into the development process.

There have been many books written about how to write secure code, so I won't cover that in this article. What I will cover is the role of the security policy as a driver in the application development lifecycle. Imagine if you were to build your dream home without security in mind. You might not wire the home for a security alarm, or might even not fortify your entry and exit ways, leaving your home vulnerable to intrusion. Likewise, developing business software without a good security plan can and will leave you with an unsecured application.

The role of a security policy is to define what needs to be protected and how it will be protected. In the application development lifecycle, the security policy instructs designers and developers on what the security features need to be and how they must be implemented.

Would you prefer to accept a well-intentioned best guess from the development team as to how to secure your application, or rather have your team implement a solid, well-designed security plan from the start?

What does a security policy protect?

ISO 17799 defines a security policy as a document providing management direction and support for information security in accordance with business requirements and relevant laws and regulations. During the software development process it is important to use these policies as a guide for all security features that will be developed.

This point is subtle but critical to understand. The application security policy should not be defined by the development process it should only implement the organizations stated security requirements. Keep in mind that the application you develop needs to fit into the user's security model whether this is your company or your customers.

Too much software is developed without security as a feature.

It is interesting how many companies rely on the sale of software intellectual property as a source of revenue yet do little to protect that property. Working in application security, I often notice how many companies have elaborate security policies for protecting physical and information infrastructure, but who never extend that effort to the application development process.

Many companies overlook the use of security policies when protecting their software application layer and related intellectual property. When an application is developed without regard to security, that application can become a threat to the environment in which it is deployed. Obviously, this process puts both the development organization and the end user organization in a security deficit.

To make security part of the application architecture, designers need to understand the requirements of the security policy so that they can properly build these things in as feature requirements.

Why is security overlooked?

In many software development efforts, security is often implemented as an afterthought. In fact, security often doesn't even make it into the development process at all. One reason this happens is the low importance that organizations place on developing secure software. The frightening part is that companies often do not even realize that they are doing this. However it occurs, there is a perpetual lack of available security policies during the application design phase. This often results in the omission of security features at the application layer. In another common scenario, application architects attempt to implement security without using a corporate policy. When security is added this way, its effectiveness is diminished and there is no guarantee that actual threats are being addressed.

I have asked many development organizations why they do not design and implement security as a feature. One reason they cite is a lack of polices available to the development staff. In some organizations, computer security is often viewed as the responsibility of the operating system vendor. Security is often viewed in general as being costly to implement, and often is dropped due to time and cost constraints.

I disagree with these actions and believe that security is really everyone’s responsibility. Corporate and third-party software developers need to ensure that their applications do not introduce additional risks into the operating environment. As operating systems continue to become more secure, software attackers are looking for the next easiest targets. Unfortunately, the next easiest target is usually the application layer.

Why are security policies so important?

It is crucial for companies to recognize the need for application security policies because, without such policies, there is no reliable way to define, implement, and enforce a security plan within an organization. Does the physical security plan for your company include policies and procedures related to entrances and exits, or to the possession of firearms, or to access to secured areas, and so on? If you can think of your application as part of this same physical environment, it will be easier to see how this piece of software, which for example perhaps handles your payroll and accounting information, requires the same thought process for security as does the physical access to your hard corporate assets.

When a security policy is available to the development team, they can easily integrate the policy into the application as a feature. If your company is on the purchasing end of an application, the security policy that was involved in the application's development provides security features that should make the software package acceptable to your corporation.

There are far-reaching benefits to using a security policy in the application development process. The availability of the security requirements in the policy make it possible for the development team to create the software with a least-privilege mindset so that it can be deployed with a minimal attack surface into a restricted operating environment. Additionally, customers can enable features in a manner that is tailored to the configuration that is required by their own security policies.

Conclusion

Corporate security policies are a critical part of securing your corporate assets. Information security is an integral part of your corporate security program. It is important to imbed security processes and policies into your software development process.

Resources

Microsoft Application Threat Modeling Blog
https://blogs.msdn.com/threatmodeling/archive/2007/08/27/threat-modeling-sdl-it.aspx

Michael Howard, “How Do They Do It? A Look Inside the Security Development Lifecycle at Microsoft”
https://msdn.microsoft.com/msdnmag/issues/05/11/SDL/

Security Awareness Program Development Guidance
https://www.microsoft.com/technet/security/understanding/awareness.mspx

Noopur Davis, “Secure Software Development Life Cycle Processes,”
U.S. Department of Homeland Security
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/sdlc/326.html