Dangers of Self-Managed Development Environments

Like most of my peers in this industry, I started out as a programmer.

Many remained as programmers for several years until morphing into managers. Others became system administrators of development or production systems.

Over my twenty-two plus year career, I've worked as a developer, system administrator, and architect, and in various leadership and managerial roles.

Today I've come full-circle and back to my roots as a principal engineer.

Over the years I have seen the discipline of software development grow in many directions to include new programming languages, associated processes, software deployment methodologies, and software development environments.

The trend that concerns me is the ease at which developers can set up their own development environment to perform unit level development.

Developers can easily stand up their own Linux desktop or virtualized environments and begin to develop software. Then they can submit finished components into a central repository to be integrated and fully tested in the subsequent phases of development.

Denying developers this capability would be counter-productive. I agree with the two arguments I hear most often:

(1) “Don't worry dude! The software is portable” and

(2) it takes too long for system administrators to configure our necessary development environments – more specifically, it takes too long for system administrators to adjust security settings and install tools we need to develop software.

Both are valid points, however, the non-standardization of development tools, runtime environments, and inconsistent security settings raise concerns.

Too often I have seen developers relax security controls during unit development only to be bewildered when full integration testing fails. Many database administrators have strict table access controls which developers must adhere to.

Why isn't this the same when it comes to base operating system resources?

Another scenario which concerns me is when an operations group has little-to-no influence on the configuration guidelines which a development group must follow.

When development is completed, operations is expected to install and configure the newly developed application.

In my opinion, if the required configuration deviates from established standards or a developer is required to install it, operations should not be expected to accept the product!

Why should operations be expected to maintain the current level of documented security or maintain the product in general if the product is not developed using the same processes?

This dilemma is exactly what one of our Security Blanket® customers described to me. My first response to them was that good leadership, sound configuration management, and supporting processes must be in place.

Secondly, my suggestion was to establish consistent configurations throughout the testing environments to mimic production as closely as possible.

And if possible, tighten the development environments down, too, or at least establish development guidelines like “stop running Tomcat as root”!

If you or your organization have encountered this situation in a professional services capacity, what was your solution? What other concerns should organizations have?

Jamie Adams is a Principal Secure Systems Engineer at Trusted Computer Solutions, Inc.

Note: the views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post. Infosec Island reserves the right to remove or edit the content of all material submitted by our members.

View the original article here