3. Cybersecurity Testing
제조사는 밸리데이션을 절차를 수립하고 유지해야 함. (21 CFR 820.30(f))
ENUnder 21 CFR 820.30(f), a manufacturer must establish and maintain procedures for verifying the device design.KR21 CFR 820.30(f)에 따라, 제조사는 장치 설계를 검증하기 위한 절차를 수립하고 유지해야 합니다.
ENSuch verification shall confirm that the design output meets the design input requirements. Under 21 CFR 820.30(g), a manufacturer must establish and maintain procedures for validating its device design. Such design validation shall include software validation and risk analysis, where appropriate.KR이러한 검증은 설계 산출물이 설계 입력 요구사항을 충족하는지를 확인해야 합니다. 21 CFR 820.30(g)에 따라, 제조사는 장치 설계를 밸리데이션하기 위한 절차를 수립하고 유지해야 하며, 해당 설계 밸리데이션에는 적절한 경우 소프트웨어 밸리데이션 및 위험 분석이 포함되어야 합니다.
ENFDA recommends verification and validation include sufficient testing performed by the manufacturer on the cybersecurity of the medical device system through which the manufacturer verifies and validates their inputs and outputs, as appropriate.KRFDA는 제조사가 의료기기 시스템의 사이버보안에 대해 충분한 테스트를 수행함으로써 설계 입력 및 산출물을 적절히 검증하고 밸리데이션할 것을 권장합니다.
시판 전 제출문서는 보안 테스트 문서 및 보고서를 포함함.
테스트 유형
- Security requirements;
- Manufacturers should provide evidence that each design input requirement was implemented successfully. -
- Manufacturers should provide evidence of their boundary analysis and rationale for their boundary assumptions.
- Threat mitigation;
- Manufacturers should provide details and evidence of testing that demonstrates effective risk control measures according to the threat models provided in the global system, multi-patient harm, updatability and patchability, and security use case views.
- Manufacturers should ensure the adequacy of each cybersecurity risk control (e.g., security effectiveness in enforcing the specified security policy, performance for maximum traffic conditions, stability, and reliability, as appropriate).
- Vulnerability Testing (such as section 9.4 of ANSI/ISA 62443-4-1); and
- Manufacturers should provide details and evidence46 of the following testing and analyses:
- Abuse or misuse cases, malformed and unexpected inputs;
- Robustness.
- Fuzz testing.
- Attack surface analysis;
- Vulnerability chaining;
- Closed box testing of known vulnerability scanning;
- Software composition analysis of binary executable files; and
- Static and dynamic code analysis, including testing for credentials that are “hardcoded,” default, easily guessed, and easily compromised.
- Manufacturers should provide details and evidence46 of the following testing and analyses:
- Penetration testing.
- The testing should identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product. Penetration test reports should be provided and include the following elements:
- Independence and technical expertise of testers;
- Scope of testing;
- Duration of testing;
- Testing methods employed; and
- Test results, findings, and observations.
- The testing should identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product. Penetration test reports should be provided and include the following elements:
테스트 보고서는 참여한 테스트 조직 및 엔지니어에 대해 기술해야 함
ENDevice manufacturers should indicate in the test reports by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices.KR장치 제조사는 테스트 보고서에 테스트 수행자가 누구인지(예: 독립적인 내부 테스트 담당자, 외부 테스트 담당자)와 테스트 담당자가 장치 설계를 담당하는 개발자들과 어느 정도 독립성을 갖는지를 명시해야 합니다.
ENIn some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups, such that vulnerabilities or other issues revealed during testing are appropriately addressed.KR경우에 따라, 테스트 중에 발견된 취약점이나 기타 문제들이 적절히 해결될 수 있도록 두 그룹 간의 적절한 독립성을 확보하기 위해 제3자를 활용해야 할 수도 있습니다.
ENFor any third-party test reports, manufacturers should provide the original third-party report.KR제3자 테스트 보고서가 있는 경우, 제조사는 해당 제3자의 원본 보고서를 제출해야 합니다.
ENFor all testing, manufacturers should provide their assessment of any findings including rationales for not implementing or deferring any findings to future releases.KR모든 테스트에 대해 제조사는 발견된 사항에 대한 평가와 함께, 해당 사항을 구현하지 않거나 향후 릴리스로 연기한 이유에 대한 근거를 제공해야 합니다.
테스트 중에 식별된 취약점과 anomaly(이상)은 보안 영향 측면에서 평가되어야 함.
ENVulnerabilities and anomalies identified during testing should be assessed for their security impacts as part of the security risk management process.KR테스트 중에 식별된 취약점과 이상(anomaly)은 보안 위험 관리 프로세스의 일환으로 보안 영향 측면에서 평가되어야 합니다.
ENIn non-security software testing, a benefit analysis of a discovered defect may lead to the conclusion that an anomaly does not need to be fixed, as its impact on medical device system functionality may be small or unlikely.KR비보안 소프트웨어 테스트에서는 발견된 결함에 대한 이점 분석을 통해 해당 이상이 장치 기능에 미치는 영향이 작거나 발생 가능성이 낮다고 판단되어 수정이 필요하지 않다고 결론지을 수 있습니다.
ENConversely, in security testing, the exploitability of an anomaly may necessitate that it is mitigated because of the greater, and different type of, harm that it could facilitate.KR반면, 보안 테스트에서는 해당 이상이 악용될 가능성이 있기 때문에 더 크고 다른 유형의 피해를 초래할 수 있어 이를 완화해야 할 필요가 있을 수 있습니다.
시판 전 제출문서는 취약점과 이상(anomaly)이 남아있는 경우, 이를 해결하기 위한 향후 릴리즈 계획을 포함함.
ENFor issues that will be addressed in future releases (i.e., remediation deferred for a future software release because current risk was assessed to be acceptable), the premarket submission should contain plans for those releases.KR향후 릴리스에서 해결될 예정인 문제(즉, 현재 위험 수준이 수용 가능하다고 평가되어 향후 소프트웨어 릴리스로 위험개선이 연기된 경우)에 대해서는 시판 전 제출 문서에 해당 릴리스 계획이 포함되어야 합니다.
ENSuch plans should include the vulnerabilities that future software releases will address, anticipated timelines for release, whether devices released in the interim will receive those updates, and how long it will take the update to reach the devices.KR이러한 계획에는 향후 소프트웨어 릴리스에서 해결할 취약점, 예상 릴리스 일정, 중간에 출시된 장치가 해당 업데이트를 받을지 여부, 그리고 업데이트가 장치에 도달하는 데 걸리는 시간이 포함되어야 합니다.
사이버보안 테스트는 SPDF 전반에 걸쳐 수행되어야 함.
ENFDA recommends that cybersecurity testing should occur throughout the SPDF.KRFDA는 사이버보안 테스트가 SPDF(Security Process and Data Framework) 전반에 걸쳐 수행되어야 한다고 권장합니다.
ENSecurity testing early in development can ensure that security issues are addressed prior to impacting release timelines and can prevent the need to redesign or re-engineer the device.KR개발 초기 단계에서의 보안 테스트는 보안 문제를 조기에 해결하여 릴리스 일정에 영향을 주지 않도록 하고, 장치의 재설계 또는 재엔지니어링 필요성을 방지할 수 있습니다.
ENAfter release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually) to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited.KR출시 이후에는 위험 수준에 따라 정기적으로(예: 연 1회) 사이버보안 테스트를 수행하여 잠재적인 취약점을 사전에 식별하고 악용되기 전에 대응할 수 있도록 해야 합니다.