Software Security Code of Practice - Implementation Guidance
Page 6 of 7
Theme 4: Communication with customers
By being open and transparent with your customers you will be able to demonstrate that you take security seriously throughout the life cycle of the software. This will assist them to be able to make a risk-based decision (and encourage stronger levels of security to be considered) when selecting software. In addition, should a vulnerability or incident occur, it will be easier to recover with effective communication between supplier and customer.
Principle 4.1 Provide information to the customer specifying the level of support and maintenance provided for the software being sold
Software reaches the end of its life cycle due to changes in market demand, technological innovation or new product development. When this happens, it is expected that the software will no longer receive vulnerability patches even if new exploits are known to be available. Older software may also lack the latest security measures, increasing the impact of vulnerabilities, making exploitation more likely to succeed, and detection of any exploitation more difficult.
Advising your customers on how they can securely use your software is crucial for their safety and the integrity of the software. Providing clear information and instructions on how to go about this will reduce the risk of exploitation. To ensure that the customer is aware of the expected lifespan of the software, they should be given enough notice to adapt when the software reaches end of support, and understand how to secure the product.
You should ensure that:
- You provide information to the customer, in an accessible way, specifying the level of support and maintenance provided for the software being sold. You clarify what level of support will be provided, including frequency of patching against known vulnerabilities, how these are to be distributed and how the customer will be notified of these patches being available.
- You provide customers with documentation on how to securely use your software. This should emphasise the importance of applying the latest software updates, using strong authentication / MFA, how to regularly back up important data, controlling access to only those that require it and what ports may be exposed to the outside world along with firewall rules.
Further reading
Principle 4.2 Provides at least one year’s notice to customers of when the software will no longer be supported or maintained by the vendor
Organisations can use a varied and potentially complex mix of software. As such it might not always be clear which components are moving towards end of life and will no longer be supported. Also, even if it is known that a piece of software needs replacement, it might not always be straightforward to do this so plenty of notice may be required to ensure a planned and controlled changeover.
You should ensure that:
- An end-of-support policy for the product is declared. This should include the length of time the software is supported for, and/or the notice period that will be given of the product containing the software reaching its end of life. This notification period should not be less than one year to allow the customer to take appropriate risk mitigation measures and should advise on the risks of not taking such measures.
Further reading
Principle 4.3 Make information available to customers about notable incidents that may cause significant impact to customer organisations
Due to the complex nature of most software, vulnerabilities can be exploited which either causes an incident to occur, or introduces a weakness that may be exploited in the future. By proactively supporting affected customers the impact to them and yourselves is reduced.
If such a situation occurs, it is important that the customer of the software is made aware of the issue, how it might impact them and what actions can be taken to remediate and reduce the likelihood of it affecting them, or to recover from any incidents that have occurred.
You should ensure:
- A policy or plan is created in advance and shared with the customers of your software detailing how you will go about supporting them in the event of an incident occurring. This may contain roles and responsibilities, incident response procedures (including key points of contact), containment strategies, communication plans, eradication measures, recovery plans and post-incident reviews.
- When an incident occurs, you should prompt notification to users as soon as possible in a clear and concise way, communicating what happened, the expected impact and what is being done to resolve it. This will help minimise impact and maintain trust. Regular updates should be provided until the incident is resolved, and followed up with a post incident report, identifying the root cause and specifying measures being taken to prevent a future similar event.