PSIRT 해설: 제품 보안 사고 대응팀이 하는 일

PSIRT란 무엇입니까?

PSIRT(Product Security Incident Response Team, 제품 보안 사고 대응팀)는 기업이 만들어 판매하는 제품의 보안 취약점을 처리하는 조직입니다. FIRST는 PSIRT를 제품, 서비스 상품, 솔루션, 구성 요소, 서비스를 포함해 "제품 내 보안 취약점과 관련된 위험의 식별, 평가, 처리"에 집중하는 조직으로 정의합니다.

실제로 PSIRT는 다음 일을 합니다.

연구자, 고객, 파트너가 취약점을 보고하는 채널을 운영합니다.
제품에 포함된 서드파티 및 오픈 소스 구성 요소의 취약점을 감시합니다.
각 보고를 분류합니다. 실제 취약점인지, 어떤 제품과 버전이 영향을 받는지, 심각도는 어느 정도인지 판단합니다.
담당 엔지니어링 팀이 위험에 맞는 일정으로 취약점을 수정하도록 합니다.
권고를 게시하고, 발견자 및 다운스트림 벤더와 공개를 조정합니다.
경영진에 지표를 보고하고, 제품을 만드는 사람들을 교육합니다.

업무의 대부분은 출시 이후에 이루어집니다. FIRST는 제품 취약점 대부분이 제품이 시장에 나온 뒤 품질 결함으로 보고된다고 설명하지만, PSIRT는 설계 검토와 위협 모델링처럼 더 이른 단계에서도 가치를 더합니다.

조직 내 PSIRT의 위치

다른 보안팀과의 차이는 제품에 집중한다는 점입니다. 기업 CSIRT는 회사 자체의 시스템과 네트워크를 보호하고, PSIRT는 회사 제품을 사용하는 고객을 보호합니다. 두 팀은 역량을 공유하고 보고 체계도 같은 경우가 많으며, 침해된 빌드 시스템처럼 회사 자체 인프라의 사고가 제품에까지 미칠 때 함께 일합니다. 자세한 비교는 PSIRT vs CSIRT를 참조하세요.

FIRST는 3가지 운영 모델을 제시합니다.

분산형: 소규모 핵심 PSIRT가 정책을 정하고 조정하며, 각 제품팀의 보안 담당자가 분류와 수정을 수행합니다. 크고 다양한 포트폴리오에도 확장할 수 있지만, 실제 업무를 하는 사람들이 PSIRT에 보고하지 않습니다.
중앙집중형: 자체 프로그램 관리, 분류, 조치 인력을 갖춘 더 큰 PSIRT가 제품 보안 담당 고위 임원에게 보고합니다. 소규모 기업이나 균일한 포트폴리오에 적합하며, 포트폴리오가 커질수록 비용이 늘어납니다.
하이브리드형: 기업 규모, 포트폴리오, 개발 전략에 따라 두 모델을 혼합합니다.

어떤 모델이든 FIRST는 독립성을 강조합니다. PSIRT는 그 권한을 확인해 주는 임원에게 보고해야 하며, 그래야 회사 자체 제품의 취약점에 대해 객관적인 입장을 취할 수 있습니다.

FIRST PSIRT Services Framework

FIRST가 무료로 공개하고 현재 버전 1.1인 PSIRT Services Framework는 대부분의 PSIRT가 서비스 카탈로그를 만들 때 기준으로 삼는 문서입니다. 운영 기반(권한, 이해관계자, 예산, 정책)을 정한 뒤 6가지 서비스 영역을 제시합니다.

서비스 영역	다루는 내용
1. 이해관계자 생태계 관리	내부 이해관계자, 발견자 커뮤니티, 다운스트림 벤더와 고객, 사고 커뮤니케이션, 발견자 공로 인정, 이해관계자 지표
2. 취약점 발견	취약점 보고 접수, 보고되지 않은 취약점 찾기, 제품 구성 요소의 취약점 모니터링, 새로운 취약점 식별, 발견 지표
3. 취약점 분류 및 분석	보고 검증, 기존 발견자와의 협력, 취약점 재현
4. 조치	수정 릴리스 관리 계획, 조치, 사고 처리, 릴리스 지표
5. 취약점 공개	통지, 조정, 권고를 통한 공개, 공개 지표
6. 교육 및 훈련	PSIRT, 개발 및 검증 팀, 기타 이해관계자 교육, 피드백 체계

업무에서 큰 비중을 차지하게 된 서비스 하나는 따로 짚어 볼 만합니다. 바로 제품 구성 요소의 취약점 모니터링입니다. 그 첫 번째 기능은 제품 구성 요소 인벤토리, 즉 각 제품에 포함된 벤더, 제품, 버전의 목록이며, FIRST는 이를 "상속된 취약점의 영향을 받는 제품을 빠르게 식별하는 데 필수적"이라고 설명합니다. 오늘날의 소프트웨어에서 이 인벤토리는 소프트웨어 자재 명세서(SBOM)입니다.

PSIRT 프로세스 한눈에 보기

두 가지 ISO/IEC 표준이 이 프로세스를 설명합니다. ISO/IEC 30111:2019는 벤더가 내부적으로 취약점을 처리하는 방법을, ISO/IEC 29147:2018은 외부에서 보고를 받고 조치 정보를 게시하는 방법을 다룹니다. 30111은 29147과 함께 사용하도록 되어 있으며, 30111이 설명하는 단계는 유용한 개요가 됩니다.

준비. 정책, 역할, 공개된 취약점 보고 방법, 점수 산정 방법, 출시하는 제품의 인벤토리를 갖춥니다.
접수. 연구자, 고객, 파트너, 자체 테스트로부터 보고를 받고, 사용하는 구성 요소에 대한 권고도 받습니다. 발견자에게 접수를 확인해 줍니다.
검증. 취약점을 확인하고 재현하며, 점수를 매기고, 영향을 받는 모든 제품과 버전을 파악합니다. 영향을 받지 않는 제품과 그 이유도 기록합니다.
조치 개발. 담당 팀이 수정 사항이나 완화 조치를 만들고 테스트합니다. PSIRT는 합의된 일정에 맞춰 진행 상황을 추적합니다.
릴리스. 발견자 및 귀사 제품을 내장하는 다운스트림 벤더와 조정해 수정 사항을 출시하고 권고를 게시합니다.
릴리스 이후. 수정 사항의 문제를 살피고, 고객 문의에 답하며, 근본 원인을 개발 과정에 반영합니다.

각 단계에서 무엇을 기록하고 누가 담당하는지는 취약점 관리 수명 주기에서 다룹니다. 어떤 발견 사항을 먼저 처리할지는 취약점 우선순위 지정을 참조하시고, 악용 신호는 EPSS와 CISA KEV 카탈로그에서 얻을 수 있습니다. 수정 사항이 나오기 전에 악용되는 취약점은 제로데이이며, PSIRT는 이를 사고로 처리합니다. 권고에서 수정된 빌드의 출시까지 이르는 과정은 CVE 조치에서 다룹니다.

공개와 권고

공개는 PSIRT 업무 중 고객의 눈에 보이는 부분입니다. 일반적인 관행은 조정된 취약점 공개입니다. 발견자가 비공개로 보고하고, 벤더가 수정하며, 양측이 합의한 날짜에 발견자의 공로를 밝히며 게시합니다. 그 출발점은 보고 방법, 발견자가 기대할 수 있는 사항, 제품 지원 기간을 밝힌 공개적인 취약점 공개 정책입니다. 조정된 취약점 공개를 참조하세요.

좋은 권고는 전화 문의 없이도 고객에게 다음을 알려 줍니다.

영향을 받는 제품과 버전, 그리고 영향을 받지 않는 제품과 버전
CVE ID와 심각도 점수
수정된 버전, 또는 아직 수정 사항이 없다면 완화 조치
발견자

대형 고객은 자체 자산 인벤토리와 자동으로 대조할 수 있는 기계 판독 가능한 형태의 권고를 점점 더 원합니다. CSAF는 권고를 위한 OASIS 표준 형식이며, VEX는 제품이 구성 요소 중 하나의 취약점에 영향을 받지 않는다고 밝히는 방법으로, 양측 모두 티켓 하나를 줄일 수 있습니다.

PSIRT 지표와 성숙도

프레임워크는 모든 서비스 영역에 지표를 둡니다. 일반적인 지표는 다음과 같습니다.

심각도별 보고 확인, 분류, 수정 릴리스까지 걸린 시간
제품, 심각도, 경과 기간별 미해결 취약점
공개한 조치 목표 기간 내에 제공된 수정 사항의 비율
내부에서 발견한 취약점과 외부에서 보고된 취약점의 비교
게시한 권고 수와 권고 정정 건수

FIRST의 보조 문서인 PSIRT Maturity Document는 서비스를 3단계로 구분합니다.

1단계, 기본: 경영진의 지원, 이해관계자, 예산과 정책, 보고 접수 방법, 분류 워크플로, 문서화된 수정 사항, CVE와 CVSS를 사용하고 발견자의 공로를 밝히는 권고.
2단계, 중급: 헌장과 조직 모델, 기준 지표, 종속성 매핑을 갖춘 제품 레지스트리, 공식적인 수정 계획, 이해관계자 통지 체계, 팀 교육.
3단계, 고급: 발견자 커뮤니티와의 직접 교류, 제품 구성 요소의 취약점 모니터링, 발견 및 릴리스 지표, 고급 사고 처리, 업계 조정을 위한 플레이북.

단계가 올라갈수록 사후 대응에서 사전 예방으로 나아갑니다.

PSIRT 구축 방법: 작게 시작하기

임원으로부터 서면 권한을 받으세요. 제품팀에 수정을 요청할 수 있는 권한이 포함되어야 합니다.
취약점 보고 방법을 공개하세요. 보안 연락처 주소, 웹 양식 또는 security.txt 파일과 간단한 공개 정책을 마련합니다.
분류와 점수 산정 방식을 정하세요. 누가 보고의 유효성을 판단하는지, 심각도를 어떻게 매기는지, 심각도별 조치 목표 기간은 얼마인지 정합니다.
출시하는 제품의 구성을 파악하세요. 제품 버전마다 그 안의 구성 요소와 버전을 알아야 합니다. 이것이 없으면 인기 라이브러리에 새 CVE가 나올 때마다 엔지니어링 팀에 며칠씩 문의해야 합니다.
제품별 담당자를 지정하세요. 담당자는 발견 사항을 받고 수정 일정을 잡습니다.
권고 템플릿을 작성하고 작은 문제라도 첫 권고를 게시하세요.
처음부터 측정하세요. 몇 가지 소요 시간을 측정해 두면 개선을 보여 줄 수 있습니다.

PSIRT 팀 페이지는 이 역할을 제품 보안 책임자의 관점에서 살펴봅니다. 산업용 제품 벤더는 이 단계를 IEC 62443-4-1에 대응시킬 수 있으며, 이 표준의 보안 개발 수명 주기 요구 사항에는 결함 관리와 패치 관리가 포함됩니다.

PSIRT를 요구하는 규정

예전에는 PSIRT가 성숙한 벤더의 표시였습니다. 이제는 여러 프레임워크가 PSIRT의 산출물을 요구합니다. NIS2 제21조 제2항 (e)호는 필수 및 중요 기관이 취해야 할 조치로 "취약점 처리 및 공개"를 명시합니다. 미국에서는 524B조가 의료기기 제조사에 SBOM과 함께, 조정된 취약점 공개를 포함해 시판 후 취약점을 모니터링, 식별, 처리하는 계획을 제출하도록 요구합니다. 그리고 EU Cyber Resilience Act는 제조사에 실제 악용 중인 취약점과 심각한 사고를 24시간 이내의 조기 경보부터 시작해 당국에 보고하도록 요구합니다. CRA란 무엇인가를 참조하세요. 통지는 ENISA의 Single Reporting Platform을 통해 제출합니다.

PSIRT에 필요한 도구

필요 사항	이유
보고 접수 및 사례 추적	모든 보고에 담당자, 상태, 일정이 부여됨
출시하는 제품의 인벤토리	전이적 종속성을 포함한 제품 버전별 정확한 SBOM
지속적 모니터링	다음 버전만이 아니라 출시된 모든 버전의 구성 요소와 새 CVE를 대조
분류 및 전달	발견 사항이 조치에 필요한 맥락과 함께 수정 담당 팀에 전달됨
영향 여부 진술	VEX로 취약점이 어떤 제품에 영향을 미치는지, 나머지는 왜 영향이 없는지 기록
권고 게시	사람이 읽을 수 있는 권고와 대형 고객을 위한 기계 판독 가능한 CSAF

모든 항목을 다루는 제품은 드뭅니다. 어떤 도구가 무엇을 하는지는 PSIRT 도구 비교를 참조하세요. 대부분의 PSIRT가 어려움을 겪는 부분은 인벤토리입니다. 사후에 잠금 파일을 읽는 스캐너는 출시되지 않는 개발 종속성을 나열하고, 빌드가 패키지 관리자 밖에서 내려받은 패키지를 놓치므로, "우리가 영향을 받는가?"라는 질문에 대한 답은 의심에서 시작됩니다.

CRACI는 그 인벤토리를 빌드 자체에서 가져옵니다. GitHub Actions 빌드를 CRACI 자체 러너에서 실행하고, 전이적 종속성, CI 캐시에서 복원된 패키지, 어떤 잠금 파일에도 없는 종속성을 포함해 각 작업이 실제로 가져온 패키지를 기록합니다. 각 SBOM에는 완전성 상태가 표시되며 CycloneDX 또는 SPDX로 내보낼 수 있습니다. 모니터링 중인 SBOM은 새로운 취약점이 공개될 때마다 지속적으로 재평가되고, 빌드 이력은 과거 어떤 빌드에 취약한 종속성이 포함되었는지 보여 주며, 인벤토리 뷰는 어떤 소프트웨어 버전이 어떤 제품에 배포되었는지 보여 줍니다. 보안팀은 발견 사항을 분류해 수정을 담당하는 팀에 보내며, CRACI는 VEX를 지원합니다. 취약점 추적과 PSIRT 팀을 위한 CRACI를 참조하세요.

PSIRT: 자주 묻는 질문

PSIRT는 무엇의 약자입니까?

PSIRT는 Product Security Incident Response Team(제품 보안 사고 대응팀)의 약자입니다. FIRST는 이를 조직이 생산하거나 판매하는 제품, 서비스 상품, 솔루션, 구성 요소, 서비스의 보안 취약점과 관련된 위험의 식별, 평가, 처리에 집중하는 조직 내 주체로 정의합니다.

PSIRT와 CSIRT의 차이는 무엇입니까?

PSIRT는 기업이 고객에게 출시하는 제품의 취약점을 처리합니다. 기업 CSIRT는 회사 자체의 시스템과 네트워크에서 발생하는 보안 사고를 처리합니다. 예를 들어 빌드 인프라 침해가 제품에 영향을 미칠 때처럼 두 팀은 함께 일합니다. PSIRT vs CSIRT를 참조하세요.

FIRST PSIRT Services Framework란 무엇입니까?

FIRST(Forum of Incident Response and Security Teams)가 무료로 제공하는 가이드로, PSIRT가 제공할 수 있는 서비스를 나열합니다. 버전 1.1은 이를 이해관계자 생태계 관리, 취약점 발견, 취약점 분류 및 분석, 조치, 취약점 공개, 교육 및 훈련의 6가지 서비스 영역으로 묶습니다. 보조 성숙도 문서는 서비스를 3단계로 구분합니다.

PSIRT 프로세스를 설명하는 표준은 무엇입니까?

ISO/IEC 30111:2019는 벤더가 내부적으로 취약점 보고를 처리하는 방법을 준비와 접수부터 검증, 조치 개발, 릴리스, 릴리스 이후까지 다룹니다. ISO/IEC 29147:2018은 외부와의 접점, 즉 보고 접수와 조치 정보 게시를 다룹니다. 30111은 29147과 함께 사용하도록 되어 있습니다. IEC 62443-4-1은 산업 자동화 제품에 대해 결함 관리와 패치 관리를 포함한 보안 개발 수명 주기 요구 사항을 정합니다.

소규모 기업에도 PSIRT가 필요합니까?

부서가 반드시 필요한 것은 아니지만, 그 기능은 필요합니다. FIRST의 성숙도 문서는 경영진의 지원, 지정된 이해관계자, 예산, 몇 가지 정책, 공개된 취약점 보고 방법, 분류 워크플로, 문서화된 수정 사항, 발견자의 공로를 밝히는 권고에서 시작합니다. 서면 권한을 가진 한두 명이 이를 운영할 수 있습니다.

PSIRT에는 어떤 도구가 필요합니까?

최소한 다음이 필요합니다. 보고 접수 방법, 사례 추적 도구, 취약점 점수 산정 방법, 어떤 제품 버전에 어떤 구성 요소가 포함되어 출시되는지에 대한 인벤토리, 해당 구성 요소의 새로운 취약점 모니터링, 각 제품의 영향 여부를 기록하는 방법(흔히 VEX), 그리고 권고를 게시하는 방법(점점 더 CSAF로)입니다.

PSIRT: 제품 보안 사고 대응팀이 하는 일