In this chapter, you’ve found out how to develop secure software. To make sure you have the most secure environment to develop secure software, combine all of these topics. Your development environment and tools need to be up to date just like the rest of your application software. Likewise, ensure the OSs on all of your software development computers have the latest security patches. Take the time to treat your development environment computers like production computers, and make sure they are hardened and current.

Once you have confidence that your development environment is secure, provide the same level of assurance to your customers. Just as you expect to receive timely OS and application software updates to address any newly discovered vulnerabilities, so do your clients. It doesn’t matter whether the recipients of the software you develop are internal customers or external customers. Your goal is to provide them with secure software, including periodic updates. Prioritize your software development to address any vulnerability discovered in your application software. Don’t take any shortcuts, but make every attempt to release security patches that address known vulnerabilities as quickly as possible.

Maintaining a software application often requires making difficult decisions. It would be nice to deliver every request in the order it was received. Realistically, you’ll run into times when you have to fast track software modifications. Your customers may need a critical new feature. Alternatively, you may have to address a newly discovered vulnerability or management may simply require you to implement a specific service or function as a priority. Or your organization may require you to suspend or postpone scheduled maintenance software development to address other critical projects. Although it is tempting to treat fast track projects differently than regular development, try not to bypass your development controls to speed up the process. Extreme cases calling for speedy fixes are inevitable. So when they crop up, make sure you document what you did and have a plan to reconcile the production change with testing as soon as possible. The secure development process you adopt isn’t there to slow you down—it’s there to protect you from making common mistakes. Don’t proceed without these protections simply to try to increase the speed with which you deploy maintenance patches.

Releasing patches every few days can make your customers’ system administrators scramble to validate and test each patch before they apply it. While not all organizations test new patches in isolated environments, some do. Those that do test patches before applying them to their production environments can get overwhelmed with frequent patches. Further, applying patches generally requires some type of a privileged user account. Frequent updates or patches mean more opportunities for problems during the installation process and more potential for attackers to compromise your environment during installation.

Also, check that all maintenance procedures protect your data’s security. For example, if a security patch or feature upgrade requires data conversion, one approach is to export the data to an external file and import the file into a new or modified database table. This strategy will expose the data while the program stores the data on disk. You could store the data in an encrypted folder to protect it from other users, but the disk still resides, at least temporarily, outside of the database and its internal access controls. Take care that you don’t expose any data during maintenance procedures. Keep the data secure at all times.