|
|
| Line 30: |
Line 30: |
| | |} | | |} |
| | </div>{{TOCright}} | | </div>{{TOCright}} |
| − | | + | {{Delete|reason=Expired Content}} |
| − | ==Overview and Background==
| |
| − | Security problems in software are a major component of the larger overall IT security issue. Software security issues may result from design flaws or coding errors. In the current threat environment, malicious threat actors are constantly testing software to find defects, and developing increasingly sophisticated methods to exploit such vulnerabilities in order to gain access into systems for criminal, espionage or ideological purposes. Internet-enabled programs and applications are of particular concern in that regard. The increasing complexity of software, and the Government of Canada’s (GC) dependence upon it in support of government operations, and for the provision of programs and services to Canadians, makes this an issue that cannot be ignored.
| |
| − | | |
| − | Consequently, it is incumbent on GC organizations to make their best efforts to ensure that the software programs and applications they procure and implement on government networks are trustworthy. The best way to accomplish this is to make informed risk decisions regarding the security of software that is procured, and to continuously monitor the security status of the software throughout its life cycle.
| |
| − | | |
| − | ==Assessing the Security of Software==
| |
| − | | |
| − | ===Assessment Methodology===
| |
| − | In order to gain a level of confidence in the software being procured GC organizations require a method for assessing whether such software has been developed securely. To that end, the methodology articulated in the [https://safecode.org/publication/SAFECode_Principles_for_Software_Assurance_Assessment.pdf SAFECode Principles for Software Assurance Assessment] is proposed as a model. This model as depicted below uses a process-based approach to assess a supplier’s software assurance practice to determine whether procuring and implementing such software fits a department or agency’s risk tolerance level.
| |
| − | | |
| − | [[File:Software-Assurance-SAFEcode-Principles.png|centre|334x334px]]
| |
| − | | |
| − | ===Risk Tolerance===
| |
| − | Risk tolerance is a key component to determining the level of software assurance required. If a GC organization determines that its risk tolerance level requires a high degree of confidence in the assurance of a software program or application then, in accordance with the SAFECode framework, they should seek a supplier with a proven mature secure software development lifecycle. If a GC organization does not require a high degree of confidence in software assurance then using suppliers without documented secure development processes may be acceptable. Consequently, it is important to ensure that departmental risk decisions such as these are made in accordance with government’s risk management framework, as articulated in the Communication Security Establishment’s (CSE) ITSG-33.
| |
| − | | |
| − | ===Maturity of Software Assurance Process===
| |
| − | when organizational risk tolerance level requires a high degree of confidence in the assurance of a software program or application, and the supplier has a mature secure software development process (and can provide evidence of such) then, in accordance with the SAFECode framework, a truly process-based assessment approach is suitable.
| |
| − | | |
| − | Suppliers can demonstrate the maturity of their software assurance processes by providing evidence that they follow international standards, such as ISO/IEC 27034 or IEC/ISA-62443. If a supplier does not follow these standards, they can instead demonstrate the maturity of their process by providing evidence that they adhere to secure development and integration practices, have implemented a strong governance structure to provide oversight of their software assurance process, and have a robust vulnerability response process in order to deal with software design flaws that are discovered
| |
| − | | |
| − | In some cases software suppliers will be unable or unwilling to provide evidence that they follow a mature software assurance process. In these instances GC organizations must make a risk-based decision on whether the program or application under consideration is best suited to their business need. If the software under consideration is deemed to be the best fit then GC organizations will need to work with the supplier to determine whether proof of acceptable trustworthiness can be provided through product testing
| |
| − | | |
| − | ===Considerations for Assessing Open Source Software===
| |
| − | The use of open source software (OSS) is an issue that is increasingly relevant to the Government. OSS use is seen as an important component to breaking down barriers between people, information, tools, programs and services.
| |
| − | | |
| − | Notwithstanding the Government’s commitment to ensure OSS is used, where appropriate, within the GC, organizations must ensure that any software being considered for implementation on government networks is trustworthy. In this regard, the process based on the SAFECode Principles for Software Assurance Assessment framework is still applicable and should be utilized to evaluate a product’s software assurance. However, given the more collaborative nature of OSS development it is also recommended that the following issues also be examined when considering implementation of OSS on GC networks:
| |
| − | *The development team - Look to ensure the software’s development team has a record of delivering quality products and issues patches quickly when vulnerabilities in its software are detected.
| |
| − | *The user community - Determine whether the product has a mature user community, a clear policy regarding the evaluation of user contributions, and a robust error handling process.
| |
| − | *The documentation - Examine the product’s documentation to determine ease of finding relevant information, and whether third-party specialists are available to provide support beyond what the company may offer.
| |
| − | *Update trustworthiness - Ensure that updates to the software are obtained via a trusted download source or link, preferably one provided by the supplier themselves.
| |
| − | | |
| − | ===Considerations for Assessing Freeware and Shareware Software===
| |
| − | Freeware, software that is free to use, and shareware, software that may be used for a period before buying, are also options for procuring software; but which have additional considerations for GC organizations. Unlike traditional closed-source software, and OSS from the larger vendors, it may be quite difficult to ensure that freeware and shareware have an acceptable level of software assurance. When considering implementation of freeware or shareware on government networks, GC organizations are urged to pay particular attention to:
| |
| − | *Restrictions - Ensure that the software being considered can be used at the enterprise, not personal level.
| |
| − | *Support - Give strong consideration to the level of support the software developer offers for the product.
| |
| − | *Legitimacy - Ensure that the software is obtained via a legitimate download link. Links for freeware and shareware are often advertisements for malware, rather than for legitimate software.
| |
| − | *Added programs - Freeware programs sometimes introduce optional, but pre-checked, software and toolbars that may not be required.
| |
| − | | |
| − | ===IT risk management===
| |
| − | Procurement and implementation of software programs and applications must be done as an informed risk management decision. GC organizations are encouraged to review CSE’s IT security risk management framework, in order to understand the GC approach to IT security risk management, and departmental responsibilities in that context.
| |
| − | | |
| − | Irrespective of whether GC organizations elect to procure and implement closed or open-source software (or even freeware or shareware) to fulfill their requirements, it is important to note that the associated risk management process does not end once a product has been selected. In accordance with CSE’s ITSG-33, risk management decisions must continue to be made throughout the software’s lifecycle to ensure that its continued use remains in agreement with the organization’s level of risk tolerance. In particular, should vulnerabilities in the product be discovered that cannot or will not be fixed by the vendor in a timely fashion, GC organizations will be required to give strong consideration to whether use of the product should continue, or whether additional safeguards/mitigation measures must be implemented.
| |
| − | | |
| − | ===Ongoing Maintenance and Monitoring===
| |
| − | Ongoing monitoring and maintenance of software is an important aspect of ensuring the security of government networks. Specifically, once departments and agencies implement software on their
| |
| − | networks it is important that the status of that software be continuously monitored to ensure it is up-to-date. Vendor sources should be monitored regularly for notices of vulnerabilities, and applicable patches should be actioned as soon as practicable.
| |
| − | | |
| − | ==Tips for Assessing Software Security==
| |
| − | In order to ensure that software implemented on GC networks is sufficiently secure, organizations should consider the following tips:
| |
| − | {| class="wikitable" | |
| − | !Tip
| |
| − | !Result
| |
| − | |-
| |
| − | |Understand your organization’s risk tolerance level
| |
| − | |•This will help you determine whether you should only procure software from suppliers with a demonstrated mature software assurance process
| |
| − | |-
| |
| − | |Ask for evidence when you verify a software supplier’s level of maturity for secure software development
| |
| − | |•Evidence that they follow international standards, such as ISO/IEC 27034 or IEC/ISA62443 is a good indication that they have a mature process.
| |
| − | | |
| − | •Asking questions, such as those in Annex B, about a supplier’s development and integration practices, oversight processes, and vulnerability response capabilities can also provide evidence of process maturity.
| |
| − | |-
| |
| − | |If proving supplier software development process maturity is problematic seek other assurances
| |
| − | |•Assurance that the supplier conducts such things as: binary code analyses, threat modeling, and manual code reviews and testing.
| |
| − | | |
| − | •Consult CSE to determine whether additional safeguards for your network should be considered.
| |
| − | |-
| |
| − | |When considering the use of Open Source Software, investigate its development environment
| |
| − | |•Determine whether the development team has a good track record, the user community is mature, and whether there is a trustworthy process for providing updates to the software
| |
| − | |-
| |
| − | |When considering the use of Freeware or Shareware, Investigate the conditions of use
| |
| − | |•Determine whether the software can be used at the enterprise-level, whether it comes with add-on (but unwanted) programs and tool bars, the level of support offered, and the legitimacy of the download link
| |
| − | |-
| |
| − | |Don’t forget about ongoing maintenance and monitoring
| |
| − | |•Once software has been implemented on your network, remember to monitor its status, and to frequently check for and implement patches
| |
| − | |}
| |
| − | | |
| − | ==Questions to Determine Supplier Software Assurance Process Maturity==
| |
| − | In accordance with the assessment framework articulated in the SAFECode Principles for Software Assurance Assessment, the following questions should be asked of suppliers to determine the maturity
| |
| − | of their software assurance process.
| |
| − | | |
| − | ===Secure Development and Integration Practices===
| |
| − | *Does the supplier define product-specific security requirements as part of its development lifecycle?
| |
| − | *Does the supplier conduct architectural risk analysis or threat modelling as part of its product lifecycle, and define appropriate mitigations?
| |
| − | *Does the supplier perform automatic static code reviews to identify security defects introduced during coding?
| |
| − | *Does the supplier perform automated dynamic security testing to identify common security vulnerabilities?
| |
| − | *Does the supplier triage security defects identified from the above activities and remediate them as part of its lifecycle?
| |
| − | *Does the supplier have a supply chain risk management process to manage the security and integrity of sourced components?
| |
| − | | |
| − | ===Product Security Governance===
| |
| − | *Does the supplier require security training for its product development team and a method to ensure that the requirements of its SDL are broadly understood?
| |
| − | *Do the appropriate levels of management in the organization review and sign off on the security posture of the product?
| |
| − | *Does the supplier conduct proper roadmap planning to identify future steps for remediating any unmitigated findings?
| |
| − | | |
| − | ===Vulnerability Response Process===
| |
| − | *Does the supplier have a way for researchers or customers to report a security vulnerability to it?
| |
| − | *Does the supplier issue security advisories or alerts as a way to notify customers of remediation of security vulnerabilities?
| |
| − | *Does the supplier use a CVE ID to list the vulnerability in the National Vulnerability Database?
| |
| − | | |
| − | ==References==
| |
| − | *[https://www.gcpedia.gc.ca/gcwiki/images/7/71/Guidance_for_Software_Assurance.pdf GC Guide for Software Assurance - DRAFT]
| |
| − | *[https://safecode.org/publication/SAFECode_Principles_for_Software_Assurance_Assessment.pdf SAFECode Principles for Software Assurance Assessment]
| |
