Table of contents exchange of letters with the minister executive summary

Download 5.91 Mb.

View original pdf

Page	234/329
Date	27.11.2023
Size	5.91 Mb.
	#62728

1 ... 230 231 232 233 234 235 236 237 ... 329

Report of the COI into the Cyber Attack on SingHealth 10 Jan 2019

COI Report – Part VIIPage 286 of 425

COI Report – Part VII
Page 285 of 425

826. Where, however, it is simply not feasible to inspect the source code or have it reviewed (e.g. due to availability issues with off-the-shelf proprietary software, or where the code size is simply too large, Dan and Vivek recommended performing a penetration test on the application as part of the safety review to make sure there were no vulnerabilities in the application.
827. Flowing from the foregoing, we recommend that a) Prior to the purchase of critical applications/systems, in particular those used for storing, processing or accessing sensitive information, an organisation should i) ask to conduct a source code/safety review to ensure security of the application/system, if possible and feasible ii) alternatively, ask the vendor to conduct a review based on the organisation’s security requirements and standards iii) further and/or alternatively, have a third party conduct an independent evaluation and certification for security iv) in any event, build into the contract the security requirements and standards which the organisation expects the application/system to meet and v) in any event, periodically conduct penetration testing on critical applications/systems (which will be elaborated on in section 39.3 (pg 288) below. b) In respect of legacy critical applications/systems which have already been purchased prior to any of the above steps being taken, it is all the more important that penetration testing be conducted on such applications/systems. Dan emphasised that there was urgency to conduct reviews and penetration testing of older, legacy systems,

COI Report – Part VII
Page 286 of 425

for which the organisation did not have sight of the source codes and performance criteria. c) As suggested by Dan, there should be consistent safety reviews of applications and systems throughout their life cycle and use, with penetration testing builtin as part of the safety review. This would enable necessary mitigation measures to betaken once vulnerabilities are found.
39.2.2
Evaluation and certification
828. In addition, we recommend that when it comes to the acquisition of anew software or products for CII systems and b) critical applications and systems used for storing, processing or accessing sensitive information such as patient data,
829. CII owners must require the vendor/developer to obtain security certification for the products/systems in accordance with international, national or industry-recognised standards such as ISO/IEC 15408 67
, FIPS 140-2 68
, IEC
62443 69
etc. This could be done byway of, for example, IHiS including in their tender specifications that the health informatics applications/systems which protect patient data are certified in accordance with ISO/IEC 15408.
67
ISO/IEC 15408-1:2009 establishes the general concepts and principles of IT security evaluation.
68
FIPS (Federal Information Processing Standard) PUB 140-2 is the benchmark for validating the effectiveness of cryptographic hardware. If a product has a FIPS PUB 140-2 certificate, it has been tested and formally validated by the US. and Canadian Governments.
69
ISO/IEC 62443 specifies the process requirements for the secure development of products used in industrial automation and control systems.

Download 5.91 Mb.

Share with your friends:

1 ... 230 231 232 233 234 235 236 237 ... 329