Casey will be speaking at LinuxCon Berlin on October 4.

Regardless of the level at which you’re doing your programming, security is going to get in the way. No amount of application abstraction or modern development process seems capable of shielding developers from the barriers raised by security. It’s pretty hard not to hate security when it doesn’t seem to add any intrinsic value, and often gets in the way of providing a delightful user experience. To top it off products can get hacked anyway, in spite of any and all work you do to make your products secure.

Executive Order 12472

To understand why security can be so obstructive to developers, we need to go back to the United States government’s Executive Order 12472 from April 1984. This order mandated security features and process criteria for all computers purchased by the US government. In particular, it mandated a security policy model based on the work of David Bell and Leonard LaPadula, who had been chartered to create a mathematical model of the US Department of Defense’s paper marking scheme. Descriptions of the UNIX systems of the day were written to explain how they conformed with the Bell & LaPadula terminology. Those descriptions have been carried over into the basic security model for today’s Linux systems.

That means that today we are using a security model that was originally designed to protect a user’s data on a shared supercomputer from being accessed by other users of that machine, and we are now using that same model to protect everything from self-driving cars to smart light bulbs and cloud-based data centers.

Development process assurance

Another aspect of security that Order 12472 included was development process assurance. Programs must not only demonstrate that they do what they are supposed to do, but they also have to demonstrate that they don’t do what they are not supposed to do. Order 12472 required that the steps used to make these assurances are described in detail. Mature processes were deemed to be good, whereas lightweight processes were considered dangerous. Within the framework of this 1984 model of security, modern development practices are viewed as a recipe for disaster. With all this to consider, it’s small wonder that most developers want to distance themselves from security.

Making security transparent

The theory behind many of today’s security mechanisms involves making security transparent. Sandboxing, containers, and other modern security mechanisms create an abstraction layer that shields everyone else from the details of security policy. While this achieves the stated goals of program isolation, it makes legitimate sharing of information much more complex. Controlling sharing at the appropriate level of granularity is the hardest part of security, and this is where our problems arise.

In spite of these efforts towards transparency, all too often developers find that security requirements have painted them into a corner with no easy way out. Fortunately, there are ways for developers to think about and approach security so that security doesn’t destroy their products, user experience, or schedule.

The biggest mistake a development team can make is treating security differently from how they treat their other requirements. Just as a product team that expects to tune out performance issues after all the code is done will inevitably create software full of performance issues, a product team that expects to turn on a security system just before release is going to have a smoldering pile of technology that no longer functions. To avoid this fate, development teams must consider security to be an integral part of the software’s specification, design, and implementation, and should include security as early as possible in the development process.

It is equally important to determine where the security issues for projects initially arise. Sometimes the biggest security problems are institutional, when development teams try to comply with interfaces or procedures dictated by their parent organization that might not make sense for the developers’ particular cases. Other times security problems come from poor technology choices, such as implementing sophisticated security protocols in JavaScript that are to be run on a web browser. Problems frequently come from choosing security mechanisms that have nothing to do with the environment that the code will run in.

Which approach to take?

In the end, developers have some basic options when dealing with security. You can take the traditional cathartic approach and continue to hate it and blame it for whatever impact it has on what you’re trying to accomplish. You can also take the ever-popular approach of just ignoring security, which is surprisingly cost effective. Or you could embrace security as your first priority, but this is rarely a winning strategy because of its high costs and impact on user experience and performance.

But the best way to get through the security process is to include security early in the product specification, design, and implementation along with other basic requirements. While this might seem inconvenient, and in some cases might require some retraining (especially of the security developers, who might not know what hit them), it is the best way to develop software that has effective security without creating unnecessary obstructions to the development process.