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.

What should we look at when defining our security requirements?

We have talked a lot in this blog about various aspects of implementing your information security management system; But one of the most fundamental aspects to this is understanding your security requirements. By taking an objective view of your particular organization we can clearly define what our risk is, what mitigating controls can be put in place and have the best view into our threat landscape. ISO 27001 outlines 3 main considerations to take with this;

Security category – 14.1. Security requirements of information systems

14.1.1. Information security requirements analysis and specification.

Security should be an integral part of the development and acquisition of all new information systems. This means including any security needs as deliverables/requirements at the earliest possible point in development or acquisition. The tenet of “If it doesn’t work securely, it doesn’t work.”[1] should apply when planning, developing, testing and deploying applications. The level of security should be a reflection of the value of the information being processed by the new application and its business criticality.

14.1.2. Securing application services on public networks.

Whenever our information processing takes place across public networks, such as the internet, we need to take steps to ensure the data isn’t disclosed or modified and to ensure there is a level of non-repudiation. Using encryption such as transporting the data over a VPN, SSL/TLS or IPSec can provide us with protection against disclosures and making use of encrypted hashes (known as digital signatures) can provide us with a level of assurance that the information has not been modified. In a PKI setup, we can also achieve non-repudiation through the use of public-private key pairs.

14.1.3. Protecting application service transactions

Special consideration should be given to information involved in transactions where data is modified within the service. Clearly defined stored procedures, database locking and other methods should be used to mitigate against this threat.

[1] Kelly Henderhan

Secure information at all times, especially when transmitting it.

Information is rarely static, staying in one place throughout its lifecycle. More commonly information is processed, disseminated and dispersed, between applications and between people. Processes and procedures need to be created to govern this transfer in a secure and responsible way; likewise personnel (including third parties receiving information) must be trained to treat any information they have access to, apparently.

Security category – 13.2. Information transfer

13.2.1. Information transfer policies and procedures.

The process that employees need to follow should be explicitly stated including an acceptable use policy which employee’s need to sign to transmit information. These policies should include measures to prevent staff from forwarding malicious mail, engaging in harassment and should detail the retention period and disposal procedure for emails, when encryption should be used and steps to protect against information disclosure such as being overheard having confidential conversations in public places.

13.2.2. Agreements on information transfer.

Where feasible during communications with vendors, government and other parties it should be explicitly required in agreed contracts what level of security is required for correspondence. This should keep include non-repudiation, responsibilities in the event of disclosure, technical requirements and data classification.

13.2.3. Electronic messaging.

As more and more companies use Electronic Messaging, such as email, Lync and Slack, in their day to day communications repertoire, and sometimes as a complete replacement for letters and calls, it is important that we have policies in place detailing how this can be used and what controls are in place to protect us such as keeping a record of messages exchanged, ensuring encryption in transit and at reset and having mechanisms for non-repudiation in place.

13.2.4. Confidentiality or non-disclosure agreements.

Staff, contractors and other third parties working in your organization may all have access to confidential information. This needs to be protected and one of the best ways to do this is to require all parties with access to sign confidentiality or non-disclosure agreements(NDA). These agreements should specify what is to be kept confidential, for how long, what the penalties are for disclosure, what the protected information can be used for and how that information should be protected and disclosures reported.

A short post following a long break.

Apologies everyone for the long delay between posts but I hope you enjoyed the last two on network security, and especially Vulnerability Management(which was our most popular posting to date!). Now that the holidays are over and I have settled into my new role lets continue running through the second half on the ISO27001:2013 controls.

This post will be shorter than the previous ones as we are only dealing with one control;

Security category – 12.7. Information systems audit considerations

12.7.1. Information systems audit considerations.

Any audit of information systems should be carefully planned, and have coverage agreed on in advance with the goal of minimizing disruption to business operations. While audits are an amazing tool for finding gaps and weaknesses in our security standing. Auditors are observers. The audit should not change any of the information stored on assets being reviewed and the auditors access should be monitored and logged.

Ideally the auditor should have read only access and should only run their audit scripts outside of business hours to minimize disruption.

Networked security

Your internal network has to be a prominent consideration when planning your information security. Your network carries sensitive data and is the primary route an attacker uses to navigate between your assets. Due to this it should receive special considerations and security should be designed into it from the beginning. This blog post is aimed at covering the 27001 standard but network security has its own separate standard i would highly recommend reading details on how to build controls around your network security. Segmentation, access controls, encryption, detection and more are just some of the tools we use.

Security category – 13.1. Network security management

13.1.1. Network controls.

Your network is how your staff and users access your information systems. That same network, if not adequately protected can allow a malicious user to try and compromise your environment, or if an asset is already compromised to more easily move around. There are many ways to protect your network and the level of protection should depend on your environment. Access should be restricted and controlled to protect against misuse and abuse. ISO 27033 discusses network security in detailed and should be reviewed in relation to this control category.

13.1.2. Security of network services

In addition to segmenting you network you should include additional controls such as firewalls to control access, NAC’s and filtering to restrict access to approved users/devices and NIDS and NIPS to monitor for abuse. Other tools can be used and should any service contracts your company enters into should include requirements for protection levels.

13.1.3. Segregation in networks.

All organizations can benefit from network segmentation. This could be something as simple as

Your network should be divided into subsections based on the users, application type and classification of data held in that environment. There are many ways the segment the network such as using VLANs or firewalls and time should be spent to plan out this segregation to ensure optimal protection and separation.