PSIRT vs CSIRT: 제품 취약점과 자체 IT의 보안 사고

CSIRT란 무엇입니까?

CSIRT(Computer Security Incident Response Team, 컴퓨터 보안 사고 대응팀)는 관할 대상(constituency)이라고 부르는 정해진 사람이나 조직 집단을 위해 보안 사고를 처리하는 팀입니다. FIRST의 CSIRT Services Framework는 CSIRT를 가상일 수도 있는 조직 단위, 또는 그 관할 대상에 "컴퓨터 보안 사고의 예방, 탐지, 처리, 대응을 위한" 서비스를 제공하는 역량으로 정의합니다.

관할 대상에 따라 CSIRT의 유형이 정해집니다.

• 기업 CSIRT: 한 회사의 자체 네트워크, 시스템, 계정, 데이터.
• 부문 CSIRT: 금융이나 에너지처럼 한 산업에 속한 조직 집단.
• 국가 CSIRT: 국가 전체이며, 국경 간 조정 역할을 맡는 경우가 많습니다.
• 공급업체 팀: 회사의 고객으로, 자사 제품의 문제를 다룹니다. 이것이 PSIRT입니다.

CSIRT Services Framework(버전 2.1)는 CSIRT 서비스를 정보 보안 이벤트 관리, 정보 보안 사고 관리, 취약점 관리, 상황 인식, 지식 전달의 5개 영역으로 묶습니다.

PSIRT란 무엇입니까?

PSIRT(Product Security Incident Response Team, 제품 보안 사고 대응팀)는 FIRST의 표현에 따르면, 조직이 만들거나 판매하는 "제품 내 보안 취약점과 관련된 위험의 식별, 평가, 처리"에 집중하는 조직 내 주체입니다. 취약점 보고를 접수하고, 어떤 제품과 버전이 영향을 받는지 파악하고, 수정을 만들어 출시하게 하며, 권고문을 통해 고객에게 알립니다.

PSIRT의 프레임워크인 PSIRT Services Framework(버전 1.1)에는 이해관계자 생태계 관리, 취약점 발견, 취약점 분류 및 분석, 해결, 취약점 공개, 훈련 및 교육의 6개 서비스 영역이 있습니다.

핵심 차이

차이는 누구의 시스템이 위험에 처했느냐입니다. CSIRT는 조직을 보호합니다. 사고는 자사 환경에서 일어나며, 이를 직접 봉쇄합니다. PSIRT는 고객을 보호합니다. 취약점은 고객 환경에서 실행되는 자사 제품에 있으며, 고객 대신 패치할 수 없습니다. 수정을 출시하고 고객에게 설치하라고 알립니다.

FIRST는 이를 분명하게 말합니다. "제품에 대한 집중이 핵심 차별점"으로서 같은 조직 내의 PSIRT와 다른 사고 대응팀을 구분하며, 기업 CSIRT는 일반적으로 조직 자체 인프라를 구성하는 시스템과 네트워크에 집중합니다.

PSIRT vs CSIRT 비교

	기업 CSIRT	PSIRT
범위	조직 자체 네트워크, 시스템, 데이터의 사고	조직이 출시하는 제품의 취약점
관할 대상	직원과 내부 시스템	제품의 고객과 사용자
일반적인 입력	알림, 로그, 사용자 보고, 위협 인텔리전스	연구자 보고, 서드파티 구성 요소 권고문, 내부 테스트, 조정 기관
일반적인 산출물	봉쇄된 사고, 복구된 시스템, 사고 후 검토	수정된 릴리스, 보안 권고문, CVE 레코드, 고객 통지
시작 시점	사고가 탐지되었을 때	취약점이 보고되거나 공개되었을 때
일반적인 책임자	CISO 또는 IT 보안	제품 보안 또는 엔지니어링
FIRST 프레임워크	CSIRT Services Framework 2.1	PSIRT Services Framework 1.1
표준	ISO/IEC 27035(사고 관리)	ISO/IEC 29147(취약점 공개), ISO/IEC 30111(취약점 처리)

두 프레임워크 모두 팀이 고립되어 일하지 않는다는 점을 강조합니다. PSIRT 프레임워크는 국가 CSIRT를 포함한 CSIRT를 PSIRT가 관계를 구축해야 할 이해관계자로 설명합니다. 공급업체가 취약점을 일찍 알게 되는 경로가 바로 이들인 경우가 많기 때문입니다.

CERT vs CSIRT

이런 유형의 첫 팀은 CERT Coordination Center였습니다. SEI에 따르면 이 팀은 1988년 Morris 웜 대응 과정에서 DARPA의 자금 지원을 받아 카네기 멜런 대학교 소프트웨어 공학 연구소(Software Engineering Institute)에서 탄생했습니다. CERT는 카네기 멜런 대학교가 미국에 등록한 상표이며, SEI는 미국 팀이 이름에 이 상표를 사용하도록 승인합니다. 미국 밖에서는 더 이상 상표 사용을 허가하지 않습니다.

따라서 "CERT"와 "CSIRT"는 같은 종류의 팀을 가리킵니다. CSIRT는 FIRST와 EU 법에서 사용하는 중립적인 용어이며, 많은 팀, 특히 국가 팀은 여전히 이름에 CERT를 씁니다.

국가 CSIRT와 조정 기관

몇몇 조직은 발견자, 공급업체, 사용자 사이에 있기 때문에 제품 팀에게 중요합니다.

• CERT/CC는 1988년부터 소프트웨어 취약점 공개를 조정해 왔으며, 자체 프로세스를 구축하는 조직을 위해 조정된 취약점 공개 가이드를 발행합니다.
• CISA는 미국에서 보고자, 제조업체, 사용자 간의 공개를 조정하며, 응답하지 않는 공급업체에 처음 연락을 시도한 지 45일이 지나면 수정 여부와 관계없이 공개할 수 있습니다.
• EU 국가 CSIRT. NIS2는 모든 회원국이 하나 이상의 CSIRT를 지정하거나 설립하도록 요구하며, 이들은 CERT-EU와 함께 CSIRTs Network에서 협력합니다. EU 사이버 보안 기관인 ENISA가 사무국을 맡습니다.

국가 CSIRT는 취약점 보고에서도 공식적인 역할을 맡습니다. NIS2 제12조에 따라 각 회원국은 CSIRT 하나를 조정된 취약점 공개의 조정 기관으로 지정합니다. 이 기관은 취약점을 보고하는 사람과 제조업체 사이의 신뢰할 수 있는 중개자로서, 관련 공급업체를 식별하고, 보고자를 지원하고, 공개 일정을 협상할 수 있습니다. Cyber Resilience Act도 같은 역할을 기반으로 합니다. 제조업체는 자사 제품에서 실제로 악용되는 취약점을 조정 기관으로 지정된 CSIRT와 ENISA에 동시에 통지합니다.

PSIRT와 CSIRT의 협업 방식

자사 제품과 내부 시스템 양쪽에서 사용되는, 악용 중인 취약한 오픈 소스 구성 요소를 예로 들어 보겠습니다. 두 팀은 같은 권고문을 받지만 각자의 일이 있습니다.

1. CSIRT: 내부 서버와 노트북에서 구성 요소를 찾고, 로그에서 악용 흔적을 확인하고, 패치하거나 격리하며, 침해된 것이 있으면 사고 대응을 진행합니다.
2. PSIRT: 어떤 제품, 버전, 빌드에 구성 요소가 들어 있는지 파악하고, 제품이 영향을 받는지 평가하고, 수정된 릴리스를 출시하고 권고문을 게시하며, 영향받지 않는 버전에 대해서는 VEX 문서를 함께 제공합니다.
3. 두 팀 모두: 침해 지표와 타임라인을 공유합니다. CSIRT가 공격이 빌드 시스템까지 도달했다는 사실을 발견하면, PSIRT는 출시된 릴리스가 변조되었는지 확인해야 하며, 이로써 내부 사고가 제품 사고로 바뀝니다. 공급망 공격은 보통 이 경계를 넘나듭니다.

PSIRT를 늦추는 것은 두 번째 단계입니다. CSIRT는 자체 자산을 스캔할 수 있습니다. PSIRT는 이미 고객 손에 있는 소프트웨어에 대해 답해야 하므로, 출시한 모든 릴리스에 무엇이 들어갔는지 알아야 합니다. 취약점 관리 라이프사이클과 조정된 취약점 공개 페이지에서 PSIRT가 수정에 이르는 나머지 과정을 다룹니다.

CSIRT vs SOC

보안 운영 센터(SOC)는 감시합니다. 알림과 로그를 24시간 모니터링하고, 노이즈를 걸러 내며, 실제 위협으로 보이는 것을 에스컬레이션합니다. CSIRT는 대응합니다. 확인된 사고를 넘겨받아 봉쇄하고, 조사하고, 법무 및 커뮤니케이션 부서와 조정하며, 복구를 주도합니다. 규모가 작은 조직에서는 SOC와 CSIRT가 같은 사람들인 경우가 많으며, SEI는 팀을 CSIRT, SOC 또는 다른 무엇으로 부르는지보다 어떤 기능을 수행하는지가 더 중요하다고 지적합니다.

둘 다 PSIRT를 대체하지 않습니다. SOC는 자사 환경을 모니터링하며, 고객이 사용하는 기기의 취약점은 볼 수 없습니다.

둘 다 필요합니까?

소프트웨어나 기기를 만들면서 자체 IT도 운영한다면 두 기능이 모두 필요합니다. 두 부서가 필요한 것은 아닙니다. 소규모 공급업체는 회사의 사고 대응을 맡는 보안 책임자 한 명과 제품을 위한 문서화된 PSIRT 프로세스로 시작하고, 수정은 대기 중인 엔지니어링 팀이 맡는 경우가 많습니다. 분리되어야 하는 것은 프로세스입니다. 내부 사고와 제품 취약점은 책임자, 기한, 알려야 할 대상이 모두 다릅니다.

CRACI의 역할

CRACI는 PSIRT 측면, 즉 출시하는 소프트웨어에 무엇이 들어 있는지 아는 일을 지원합니다. GitHub Actions 빌드를 CRACI 자체 러너에서 실행하고, 전이적 종속성과 캐시에서 복원된 패키지를 포함해 각 작업이 실제로 가져온 패키지를 기록하며, SBOM을 CycloneDX 또는 SPDX로 내보냅니다.

모니터링 대상 SBOM은 지속적으로 재평가되며, 빌드 기록을 통해 과거 어떤 빌드에 취약한 종속성이 들어 있었는지 확인할 수 있습니다. 인벤토리 뷰는 어떤 버전이 어떤 제품에 배포되어 있는지 보여 주고, 보안 팀은 발견 사항을 분류해 수정을 담당하는 팀에 전달합니다. 취약점 추적과 PSIRT를 위한 CRACI를 참조하세요.

PSIRT vs CSIRT: 자주 묻는 질문

CSIRT란 무엇입니까?

컴퓨터 보안 사고 대응팀(Computer Security Incident Response Team)입니다. FIRST는 이를 가상일 수도 있는 조직 단위, 또는 정해진 관할 대상에 컴퓨터 보안 사고의 예방, 탐지, 처리, 대응을 위한 서비스와 지원을 제공하는 역량으로 정의합니다. 관할 대상은 한 회사, 한 부문, 또는 국가 전체가 될 수 있습니다.

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

PSIRT는 회사가 판매하는 제품의 취약점, 즉 고객이 노출되는 취약점을 처리합니다. 기업 CSIRT는 회사 자체 시스템과 네트워크의 보안 사고를 처리합니다. FIRST는 제품에 대한 집중을 둘의 핵심 차별점이라고 말합니다.

CERT와 CSIRT는 같은 것입니까?

기능적으로는 같습니다. CERT는 카네기 멜런 대학교가 미국에 등록한 상표이며, 이 대학의 CERT Coordination Center는 Morris 웜 이후 1988년에 설립된 이런 유형의 최초 팀입니다. CSIRT는 일반 용어입니다. 많은 국가 팀이 이름에 CERT를 사용하며, EU는 법률에서 CSIRT를 사용합니다.

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

SOC는 24시간 모니터링하고 탐지합니다. 알림과 로그를 감시하고 실제 위협으로 보이는 것을 에스컬레이션합니다. CSIRT는 확인된 사고에 대한 대응, 즉 봉쇄, 조사, 조정, 복구를 책임집니다. 많은 조직에서 둘은 겹치거나 인력을 공유하며, SEI는 팀의 이름보다 어떤 기능을 수행하는지가 중요하다고 지적합니다.

PSIRT와 CSIRT가 모두 필요합니까?

소프트웨어나 기기를 판매하면서 자체 IT도 운영한다면 두 기능이 모두 필요하지만, 반드시 두 부서가 필요한 것은 아닙니다. 소규모 회사에서는 같은 소수 인원이 둘 다 맡는 경우가 많으며, 프로세스는 분리합니다. 하나는 자사 환경의 사고를 위한 것이고, 하나는 출시하는 제품의 취약점을 위한 것입니다.

국가 CSIRT는 무엇을 합니까?

국가 단위 관할 대상의 사고를 처리하고, 경고를 공유하며, 국경을 넘어 조정합니다. NIS2에 따라 모든 EU 회원국은 최소 하나의 CSIRT를 지정하며, 그중 하나가 조정된 취약점 공개의 조정 기관 역할을 합니다. 즉 취약점을 보고하는 사람과 제조업체 사이의 신뢰할 수 있는 중개자입니다.