Software Development Guidelines 03c

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.


There are several layers of security used in the Company’s computing environment, none of which is likely to change for any single applications, so it is important to have at least a basic understanding of some of the general constraints. This section provides an overview of IT security concerns across multiple IT groups, check the intranet or ask an IT analyst for more detailed information on any of the following sections.

General Security

Any application that is storing or transmitting sensitive corporate or personnel information should utilize a standard security mechanism to ensure that the data is safeguarded. Standard security mechanisms include SSL, SSH, or IPSec.

Proprietary encryption algorithms or data security protocols that are not officially sanctioned by the Company Germany may not be used.

Compiled software should never have usernames and/or passwords compiled into them, interpreted software should never have usernames and passwords coded into them, and configuration files should never contain usernames and passwords stored in clear text.

Applications that download confidential data from another application must always maintain the same level of security as the originating system.

Application Security

Application level security is designed by the software developer and must be able to protect the applications data from accidental or deliberate misuse. Documentation of the different levels of security available in an application must be provided. This documentation should provide detailed descriptions that clearly define the functional roles.

Authentication required for auditing, tracking, or determining security authorizations should be done though Active Directory or some other enterprise wide mechanism.

Client Security

The standard Company user is locked out of many portions of the corporate computers. Normal users are restricted to editing only certain portions of the registry and certain portions of the file system. So, when storing any information on the client machine it is essential to write to appropriate user accessible areas.

Data Security

Applications must provide data security appropriate for the type of data with which they deal. If an application is retrieving data from another system then it must maintain the same level of security as the original system. If an application is dealing with sensitive corporate or personnel data then appropriate data security policies must be adhered to.

Network Security

The networking group is responsible for the security of the network. For the most part data can flow freely between Company, but is restricted from external sources such as the internet. The networking group should be consulted if a special network protocol or network port range is required.

Server Security

The server group maintains the corporate servers and are responsible for their availability and security.

No development should be done on production servers and developers should not have direct access to production servers (thorough the use of MSTSC, VNC, SSH, terminal access, etc.).

Developers may have access to the server software, such as the Microsoft SQL Server services or the Microsoft IIS Web server services. But, this access should be strictly limited. In a SQL server environment developers should only have access at the database level (db_owner max), not at the SQL server level.

Published: 2008-05-13