Security Features vs. Securing Features

Secure software is a hot topic these days and many people have ideas about what should be done to achieve it. For years, the focus of many software vendors was on security features. Add a firewall. Add SSL to secure data flows. Positive security features are great, but they don’t do much to address every potential security issue that result from insecure code.

At this year’s Cisco SecCon conference, Bryan Sullivan, Microsoft’s Security Program Manager, addressed the issue of writing secure code with a diagram like the following:

His point is that there is much more work to do in securing all the features of a product than simply writing the security features. Writing security features, although important, is only 10% of the workload of creating secure code. The other 90% of the coding work is meant to ensure that all non-security codebase is secure. This includes input validation, output encoding, and overflow defense.

These practices are part of software quality, and they don’t usually appear on a feature list and often fail to appear on customer requirements lists. Customers don’t often ask for things such as:

This product should be free of cross-site scripting vulnerabilities
This product shouldn’t have client-side security validation that can be bypassed by a determined attacker
This product shouldn’t store my passwords or key data in plain text files might be leaked

Why don’t customers make such requests? Because they expect vendors to have thought of these issues and coded their products securely. Just as a car buyer doesn’t specify “the accelerator shouldn’t jam on the floor mats” or “the wiring shouldn’t set the car on fire,” we as software vendors should be taking care of the internals of implementation in a manner that doesn’t place customer data or networks at risk.

Writing secure software is part of basic software quality. You can’t list it as a feature and you can’t charge more money for it. And when done correctly, secure software is part of creating a great quality product that customers will buy. The lack of security, especially if it is embarrassingly discovered, can be a way of losing trust and sales in the marketplace. And more customers are doing their own security robustness testing, either with in-house teams or with outside security firms. Ultimately, there is a bottom line at stake. Writing secure software is good business and worth the investment of resources to do it right.

Cisco and Microsoft get it. They have collaborated on securing the design lifecycle. Microsoft’s Secure Design Lifecycle and Cisco’s Secure Design Lifecycle (CSDL) have many similar elements, but each are tailored to the development processes in each company. Both are a set of actions, tools, and processes aligned to various stages in the design lifecycle. They have the goal of ensuring that secure software designs are created, turned into secure code, and tested to ensure a secure product.

As an attendee at SecCon 2012, I was pleased to see the majority of presentations focus on secure design and development. Examples included:

Is Your Software Rugged?
Hacking Secure Protocols
The Importance of Least Privilege

I think the days of thinking about security as purely a “bolt-on” set of features, or an opportunity for additional sales of security features and appliances are over. Security features and security-specific software are an important part of the picture, and a legitimate software and hardware market in and of themselves. But the larger picture is that the quality aspect of secure design and coding must be in mind everywhere. It must be in every design phase and in every software component, and we must validate all input that comes into a component to ensure that it is handled properly. So how do we do this?

Phase out insecure functions and libraries
Educate developers to avoid repeating security mistakes
Keep up-to-date with third-party software components
Use tools such as fuzzers and static analysis to find mistakes that slipped through the cracks
Combine these activities for a measurable and repeatable process

These are the types of practices that will help a vendor produce products that are not only full of functionality, but also resistant to attackers. That is what our customers expect and what they deserve.

For all things Security don’t forget to visit our Cisco Security Intelligence Operations (SIO) Portal—the primary outlet for Cisco’s security intelligence and the public home to all of our security-related content. And, we’re easy to remember! Just go to cisco.com/security!

For questions about this post or content on the SIO portal, feel free to reach out to me. Thanks and look forward to hearing from you!