> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/ko/reference/cybersecurity-terminology.md). # 사이버 보안 용어 | 용어 | 설명 | | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CA | 인증 기관. 인증서를 발급하는 조직입니다. | | CEP | 컴포넌트 환경 프로필. 여기에는 컴포넌트의 최대 영향도, 컴포넌트가 공격 표면에 포함되는지 여부, 컴포넌트로의 데이터 흐름이 있는지 여부(및 어떤 데이터인지) 등의 특성이 포함됩니다. | | CeQ | 당사의 사이버 보안 지원 품질 시스템은 Medcrypt 서비스 제품입니다. | | CISA KEV | 사이버 보안 및 인프라 보안국(CISA)의 알려진 악용 취약점 | | COTS | 상용 기성 소프트웨어. 일반 대중이 구매, 라이선스 취득 또는 대여할 수 있도록 상용 제품으로 미리 제작된 소프트웨어 또는 하드웨어입니다. 이를 기성품 소프트웨어라고도 합니다. 자세한 내용은 이 표의 해당 정의를 참조하세요. | | CNA | Microsoft와 같은 CVE 번호 지정 기관입니다. | | CPE |

공통 플랫폼 열거(Common Platform Enumeration)입니다.


취약점은 CPE, PURL, SWID의 세 가지 필드를 사용해 식별할 수 있습니다. Helm은 CPE와 PURL을 지원합니다.

NIST는 CPE를 IT 시스템, 소프트웨어 및 패키지를 위한 구조화된 명명 체계로 정의합니다. CPE는 Uniform Resource Identifier(URI)의 일반 구문을 기반으로 하며, 공식적인 이름 형식, 시스템과 이름을 대조하는 방법, 텍스트와 테스트를 이름에 연결하는 설명 형식을 포함합니다. CPE 사양은 운영 체제, 애플리케이션 및 하드웨어 장치를 대상으로 설계되었습니다. CPE는 NVD에서 관리합니다.

클라이언트 또는 서버 애플리케이션, 펌웨어 또는 운영 체제를 식별할 때는 CPE를 사용하는 것이 좋습니다.


| | CQI | 지속적 품질 개선 | | CSAF | 공통 보안 권고 프레임워크(Common Security Advisory Framework)는 OASIS Open CSAF 기술 위원회가 개발한, 기계가 읽을 수 있는 보안 권고 표준입니다. | | CSR | 인증서 서명 요청 | | CycloneDX |

CycloneDX 사양 및 사용 사례 정보를 바탕으로 합니다.

CycloneDX는 애플리케이션, 컨테이너, 장치, 라이브러리, 파일, 펌웨어, 프레임워크, 운영 체제와 같은 컴포넌트 유형을 설명하는 기계 판독형 SBOM 형식입니다. 서비스도 설명합니다. Helm은 CycloneDX를 지원합니다.

| | CWE | 컴포넌트 약점 열거(Component Weakness Enumeration) | | EPSS | 실제 환경에서 취약점이 악용될 가능성을 예측하려는 모델입니다. | | HDO | 의료 서비스 제공 조직. 함께 진료하는 의사 그룹 등이 이에 해당합니다. | | HSM | 하드웨어 보안 모듈. HSM은 키 관리, 키 교환, 암호화 및 복호화 등 다양한 암호화 작업을 수행하는 특수한 '신뢰할 수 있는' 컴퓨터입니다. | | NTIA | 미국 국가통신정보청(National Telecommunications and Information Administration) | | OSS | 오픈 소스 소프트웨어. FDA는 어떤 컴포넌트가 COTS 또는 OSS인지 제조업체가 파악하고 있는지 확인하려 합니다. OSS와 SOUP는 흔히 잘못된 방식으로 서로 바꿔 쓰입니다. OSS 컴포넌트를 사용한다면 해당 컴포넌트가 적극적으로 유지 관리되고 있음을 보여 주는 문서를 FDA에 제출해야 합니다. 적극적으로 유지 관리되지 않거나 지원 종료(EOL)된 경우에는 해당 컴포넌트의 취약점을 어떻게 완화하는지에 대한 정보를 제출해야 합니다. | | OTS |

기성품 소프트웨어.

이 정보는 FDA의 「의료기기에서의 기성품 소프트웨어 사용」 지침을 바탕으로 합니다.

범용 컴퓨터 하드웨어의 사용이 보편화되면서 의료기기에서 OTS 소프트웨어가 더 자주 사용되고 있습니다. 그러나 특정 의료기기 용도에는 적합하지 않을 수 있습니다. 의료기기 제조업체(MDM)는 OTS를 사용하면 소프트웨어 수명 주기에 대한 통제권을 포기하게 되지만, 기기가 계속 안전하고 효과적으로 작동하도록 할 책임은 여전히 있습니다.

무엇을 문서화해야 하나요?

문서화 내용은 의료기기의 특성과 OTS 소프트웨어의 고장으로 인해 환자, 조작자 또는 주변인의 안전에 미치는 영향에 따라 달라집니다. OTA 소프트웨어로 인한 위해의 심각성이 커질수록 FDA에 제출해야 하는 문서의 상세 수준과 제조업체가 확보해야 하는 수명 주기 통제 수준을 결정하기 위해 위험 분석을 수행해야 합니다.


| | PKI |

공개 키 기반 구조는 장치, 서비스 및 사용자 간에 안전한 암호화 통신과 상호 인증을 제공합니다. 디지털 인증서를 사용하면 연결된 모든 '사물'을 공개 키를 통해 사람이나 조직과 같은 엔터티에 연결할 수 있습니다. 이러한 인증서를 사용하면 연결된 장치와 인증서를 발급한 인증 기관 사이에 신뢰 체인이 형성됩니다.

PKI가 작동하려면 제조하는 모든 장치마다 무작위로 생성한 암호화 키 쌍을 만들어야 합니다. 키 쌍은 마이크로컨트롤러의 신뢰 루트(RoT)에 프로비저닝해야 합니다. 개인 키는 하드웨어 RoT로 보호해야 하며, 공개 키 부분은 인증서에 포함해야 합니다. 둘 다 제조 과정에서 프로비저닝합니다. 인증 기관이 인증서에 서명하므로 이를 통해 신원을 인증할 수 있습니다.

따라서 신원은 고유 ID나 범용 고유 식별자(UUID)가 아니라, 무작위로 생성한 키 쌍을 사용해 장치 또는 다른 컴포넌트를 식별하는 방식입니다. 키 쌍의 공개 키 부분은 신뢰할 수 있는 인증 기관이 서명(인증)한 인증서 형태로 제공됩니다. 키 쌍의 개인 키 부분은 신원을 증명하는 데 사용됩니다.

| | PURL |

취약점은 CPE, PURL, SWID의 세 가지 필드를 사용해 식별할 수 있습니다. Helm은 CPE와 PURL을 지원합니다.


Package URL(PURL)은 소프트웨어 패키지 메타데이터를 표현하는 방식을 표준화하여, 패키지가 속한 공급업체, 프로젝트 또는 에코시스템에 관계없이 패키지를 범용적으로 찾을 수 있게 합니다. PURL은 소프트웨어 패키지를 안정적으로 식별하고 찾기 위해 기존 접근 방식을 표준화하려는 시도입니다. 프로그래밍 언어, 패키지 관리자, 패키징 규칙, 도구, API 및 데이터베이스 전반에서 소프트웨어 패키지를 대체로 범용적이고 일관된 방식으로 식별하고 찾는 데 사용하는 URL 문자열입니다.

| | QMS | 품질 관리 시스템입니다. 규제 및 고객 요구사항을 충족하는 고품질 제품과 서비스를 지속적으로 제공하기 위해 프로세스, 절차 및 책임을 문서화하는 체계적인 시스템입니다. 목표는 회사 전반의 커뮤니케이션, 협업 및 일관성을 개선하는 한편, 낭비를 줄이고 지속적인 개선 문화를 조성하는 프레임워크를 제공하는 것입니다. | | QSR | 품질 시스템 규정 | | RA | 등록 기관 | | RDP | 원격 데스크톱 프로토콜입니다. 사용자가 다른 컴퓨터나 장치에 원격으로 연결하고 이를 제어할 수 있도록 합니다. | | RoT | 신뢰 루트 | | SBOM | 소프트웨어 자재 명세서입니다. 여기에는 소프트웨어 공급망 전반에 존재하는 구성 요소, 라이선스, 저작권 및 보안 참조 정보가 모두 포함됩니다. | | SMB | 서버 메시지 블록은 Windows 컴퓨터에서 파일, 포트 및 프린터 공유와 기타 네트워크 서비스를 제공하는 프로토콜입니다. 이러한 프로토콜이 적절히 보호되지 않으면 공격자가 네트워크에 접근하여 심각한 피해를 일으킬 수 있습니다. | | SOUP |

출처 또는 이력이 알려지지 않았거나 불확실한 소프트웨어를 의미하며, 의료 소프트웨어와 같은 안전 필수 및 안전 관련 시스템의 맥락에서 자주 사용되는 용어입니다. SOUP는 알려진 소프트웨어 개발 프로세스나 방법론에 따라 개발되지 않았거나, 안전 관련 속성이 알려지지 않았거나 존재하지 않는 소프트웨어입니다.


| | SPDX |

소프트웨어 패키지 데이터 교환입니다. SPDX는 Linux에서 제공하는 국제 개방형 표준으로, 출처, 라이선스, 보안 및 기타 관련 정보를 포함한 SBOM 정보의 교환을 지원합니다. 기계 판독이 가능한 SBOM과 사람이 읽을 수 있는 SBOM을 제공하므로 소프트웨어 생태계에 관한 중요한 데이터를 공유하고 투명성을 높이며 사이버 보안 위험을 완화할 수 있습니다.

SPDX는 ISO/IEC 5962:2021에 따라 보안, 라이선스 준수 및 기타 소프트웨어 공급망 산출물을 위한 국제 개방형 표준으로 인정받고 있습니다.

Helm은 현재 SPDX를 지원하지 않지만, 지원 기능을 설계 중입니다.

| | SSVC |

이해관계자별 취약점 분류입니다. 이는 CISA의 이해관계자별 취약점 분류 문서를 기반으로 합니다..

이 취약점 분석 방법론은 단일 시스템에서 취약점의 악용 여부, 안전에 미치는 영향 및 영향을 받는 제품의 보급률을 고려합니다.

CISA는 자체 SSVC 의사결정 트리를 사용하여 관련 취약점의 우선순위를 다음 네 가지 의사결정 항목으로 분류합니다.

이러한 의사결정은 악용 여부, 기술적 영향, 자동화 가능성, 임무 관련 보급률 및 공공 복지에 미치는 영향 값을 기반으로 합니다.


| | SWID |

에 정의된 소프트웨어 ID(SWID) ISO/IEC 19770-2:2015 는 주로 설치된 소프트웨어를 식별하는 데 사용됩니다.


취약점은 CPE, PURL 및 SWID의 세 필드를 사용하여 식별할 수 있습니다. Helm은 CPE와 PURL을 지원하지만, 현재 SWID는 지원하지 않습니다.


SWID는 컨테이너(PURL도 적합하며, Helm에서 지원), 펌웨어(CPE도 적합하며, Helm에서 지원), 라이브러리 또는 프레임워크(패키지가 아닌 경우), 운영 체제(CPE도 적합) 및 운영 체제 패키지(PURL도 적합)에 사용하는 것이 좋습니다.

| | TQM | 종합 품질 관리입니다. 설계부터 고객 만족에 이르기까지 회사 전반의 품질에 중점을 둡니다. | | UUID | 오늘날 대부분의 마이크로컨트롤러에서 읽을 수 있는 범용 고유 ID입니다. 이는 신원이 아니라 식별자일 뿐입니다. 자세한 내용은 PKI 정의를 참조하세요. | | V\&V | [검증 및 유효성 확인](/ko/reference/cybersecurity-best-practices/cybersecurity-verification-and-validation-v-and-v.md) 방법은 제품, 서비스 또는 시스템이 요구사항과 사양을 충족하고 의도된 목적을 달성하는지 확인하는 데 사용됩니다. V\&V는 품질 관리 시스템(예: IO 9000)의 핵심 요소입니다. | | VEX |

취약점 악용 가능성 정보 교환입니다. 공급업체가 특정 취약점을 자사 소프트웨어와 관련하여 분석한 결과를 고객에게 전달하는 보안 권고입니다. 병원과 같은 공급업체 고객은 해당 취약점이 장치 사용에 영향을 미치는지 알아야 합니다. Helm은 VEX 상태 규칙을 사용하지 않지만, 해당 기능을 설계 중입니다.

VEX는 제품의 종속성에 있는 특정 취약점이 제품에 영향을 미치는지에 관한 추가 정보를 제공합니다. 영향을 미치는 경우, 해결 조치도 권장합니다. 예를 들어 취약한 코드가 컴퓨터에서 로드되지 않거나 소프트웨어의 다른 부분에 인라인 보호 기능이 존재하는 경우 등에는 상위 종속성의 취약점이 최종 제품에서 악용되지 않을 수 있습니다. 종속성 공급업체는 특정 제품에서 취약점의 상태를 명시하기 위해 VEX를 발행합니다. 상태는 다음과 같습니다.

VEX는 기계 판독이 가능하므로 사용자는 SBOM의 종속성 데이터와 VEX의 취약점 상태 정보를 통합해 취약점 상태를 최신 상태로 파악할 수 있습니다. 이를 통해 소프트웨어의 취약점을 더욱 정밀하게 찾아 해결할 수 있습니다.

하나의 VEX는 제품 하나 또는 여러 제품에 걸친 둘 이상의 취약점을 다룰 수 있습니다.

이는 CSAF에서 정의하며, 공급업체, 시스템 통합업체 및 운영자가 제공하는 해결 방법, 임시 해결책, 필요한 재시작/다운타임, 점수 및 위험 등의 정보를 제공할 수 있습니다.

| | VLCDB | 취약점 수명 주기 데이터베이스 | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.medcrypt.com/ko/reference/cybersecurity-terminology.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.