Table of contents exchange of letters with the minister executive summary

Download 5.91 Mb.

View original pdf

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

1 ... 295 296 297 298 299 300 301 302 ... 329

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

COI Report – Part VIIPage 378 of 425

COI Report – Part VII
Page 377 of 425

(a) Patches addressing security concerns should take priority over patches dealing more with functionality;
(b) Patching of software which provides a broader attack surface (e.g.
with a connection to the internet) should take priority over patching of software with a more limited attack surface (e.g. software used internally to a network c) The type of security vulnerability should also play apart in determining the priority with which patches are applied. For example, patches addressing vulnerabilities related to remote code execution on internet systems, like email applications, should be higher priority and d) Similarly, the type of application should also be a criterion for priority. For example, email applications should be given a higher priority for patching, as email is the most common attack vector.
46.1.5
Patch testing
1097. IHiS, in practice, carries out patch testing before the patches are deployed. The practice notwithstanding, the patch management policy should be explicit in addressing this issue.
1098. Patch testing is vital to ascertain whether or not anew patch will affect the normal operation of any existing software. Patch testing
106
should consist of the following
106
Vinod
Mohan.
(1 Aug
2013).
<
https://thwack.solarwinds.com/community/solarwinds- community/geek-speak/blog/2013/08/01/why-should-you-test-patches-before-deployment>

COI Report – Part VII
Page 378 of 425

(a) Simulate test cases and check if the patches are getting deployed successfully on the target platforms b) Compare application performance before and after the patch deployment and check if there are any issues c) Test if other applications running on the target environment are impacted by the patch updated) Ensure that if the patch is successfully removed, no application or system issues will occur and e) Incorporate patch testing as part of IT security risk assessment plan.
1099. There should be clear and stringent patch testing timelines, and a means to ensure that these timelines are adhered to.
1100. In addition to identifying any unintended problems, patches themselves should ensure that they have fully addressed the vulnerability in question or corrected the performance issue as intended.
1101. If it is not feasible to install the patch because, for example, testing results show that the patch will crash or seriously disrupt the production system,
alternate security controls should be implemented and monitored for signs of the unpatched system being exploited.
1102. The Committee notes that MOH is committed to ensure that patches are effected in a timely way which minimises cybersecurity and operational risks.

Download 5.91 Mb.

Share with your friends:

1 ... 295 296 297 298 299 300 301 302 ... 329