What is needed to ensure a secure software development framework?

Most developers will understand at least one development model, from the Software Delivery Life Cycle to the Waterfall model and many more aside, it is only recently that these models have been reviewed to ensure security requirements are taken into account at the earliest possible stage. This is an important update as new software development, and updates to existing applications can introduce new and evermore nasty vulnerabilities into our network. So how do we reduce our risk in this area? By taking a comprehensive view of security at all stages and taking all aspects of new software development into account!

Security category – 14.2. Security in development and support processes

14.2.1. Secure development policy.

A policy should outline the security requirements required during information systems development. It should include controls to protect the development environment, guidelines on how to create secure code and testing the code to verify it is secure. There are many programming methodologies that can be incorporated into this control such as the Secure Software Development Lifecycle.

14.2.2. System change control procedures.

This control ties into having a change management process and requires a similar process for deploying code during the development stage of new applications. It should include a risk analyse of impact, a roll back plan, testing and approval requirements. Documentation should be updated to accommodate changes and a version control record and audit log maintained. This is SOFTWARE FOCUSED.

14.2.3. Technical review of applications after operating platform changes.

Change always makes information systems more vulnerable. Therefore, we have a test environment but even with that whenever we make changes to applications, we should run through application use cases and conduct tests to ensure the change hasn’t negatively impacted usability or functionality.

14.2.4. Restrictions to changes to software packages

Where possible we should avoid making changes to software packages. Changes can introduce new vulnerabilities, break functionality and may prove a resource intensive exercise. In some circumstances it is justifiable to take this risk for a business need. In these cases, we should make sure we have the vendors written consent to changes, document if the vendor will still support the software and make sure we run comprehensive vulnerability tests to help us assess the risk. It is also best practise to maintain a version repository of any changes made, including keeping a copy of the original.

14.2.5. Secure system engineering principles.

Principles, such as those described in NIST SP 800-160 should be formally implemented into the organizations methodology and process, documented and maintained to allow for secure software engineering throughout the software development lifecycle. These principles should also be reviewed annually to ensure they still represent current best practises.

14.2.6. Secure development environment.

The people, technology and development process should all be protected with consideration given to the classification of data to be processed, the business criticality, legal requirements, access control and backup requirements.

14.2.7. Outsourced development.

With globalization resulting in more and more companies entering into partnership with outsourcing firms for their software development it becomes ever more important that the organizations security requirements are adhered to by their outsourcing partner. To ensure this is the case the company should actively work with and monitor the outsourced team to ensure compliance. Agreements should be in place to ensure the acceptance testing requirements are in place to include security concerns and that periodic auditing of the partners environment allowed.

14.2.8. System security testing.

As security should be a concern at every stage of the project security testing should be conducted throughout development with the extent of testing dependent on the business criticality of the application.

14.2.9. System acceptance testing.

As previously stated “If it doesn’t work securely, it doesn’t work”. There should be clearly documented acceptance criteria for new applications, upgrades and patches that must be met before these changes are accepted and rolled out. These criteria should include security concerns and after testing any issues should be remediated.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s