글로벌 소프트웨어 공급망은 항상 사이버 범죄자의 위협 민감한 정보나 지적 재산을 훔치고 시스템 무결성을 손상시키겠다고 위협하는 사람. 이러한 문제는 민간 기업뿐만 아니라 대중에게 안전하고 안정적으로 서비스를 제공하는 정부의 능력에도 영향을 미칠 수 있습니다.
미국 관리예산처(OMB)는 2022년 XNUMX월에 우리가 다룬 이 문제에 대한 메모를 발행했습니다. 여기에서 지금 확인해 보세요. 상세히. 2022년 XNUMX월에는 소프트웨어 공급망의 보안과 무결성에 중점을 두고 SBOM의 중요한 역할을 강조하는 새로운 메모가 발표되었습니다. 정확한 요구 사항 목록을 제시하고 처음으로 변경 사항 구현을 위한 실제 구속력 있는 타임라인을 공유합니다.
메모에는 국가의 사이버 보안을 개선하는 행정 명령(EO) 14028과 관련된 두 가지 주요 사항이 포함되어 있습니다.
- EO는 NIST(National Institute of Standards and Technology)에 소프트웨어 공급망의 보안 강화를 목표로 하는 개발 관행에 대한 지침을 공유하도록 지시합니다. 이를 달성하기 위해 NIST는 보안 소프트웨어 개발 프레임워크(SSDF), SP 800-218및 소프트웨어 공급망 보안 지침. 이를 함께 NIST 지침이라고 하며 보안 소프트웨어를 만들기 위한 기반을 구성하는 일련의 관행을 간략하게 설명합니다.
- EO는 또한 관리예산처(Office of Management and Budget)에 기관이 NIST 지침 및 기타 업데이트를 따르도록 요구하기 시작하도록 지시합니다.
자기증명은 필수인데 그게 전부인가요?
소프트웨어 생산자는 이제 소프트웨어 사용을 시작하기 전에 기관에 자체 인증을 제공해야 합니다. 실제로 자체 증명이 필요한 세 가지 범주는 새 소프트웨어 구매, 주요 버전 업그레이드, 소프트웨어 갱신입니다. 목표는 기관에 다음과 같은 위협으로부터 기관을 보호하는 안전하고 탄력적인 소프트웨어 제품을 제공하는 것입니다. SolarWinds 여러 기관을 손상시킨 경험이 있습니다.
기본 사항부터 시작해 보겠습니다. 자기 증명이란 정확히 무엇입니까?
자체 증명은 소프트웨어 제작자가 NIST 지침의 관행을 준수함을 증명하는 적합성 선언문처럼 작동하는 문서입니다. 아이디어는 기관이 메모의 요구 사항에 해당하는 모든 타사 소프트웨어 제품 또는 서비스에 대해 자체 인증을 얻는 것입니다. 여기에는 소프트웨어 갱신 및 주요 버전 업데이트가 포함됩니다.
메모의 또 다른 중요한 점은 기관이 소프트웨어 회사가 제품을 포괄하도록 장려한다는 것입니다. 이를 통해 모든 구매 대행사에 동일한 증명을 제공할 수 있습니다.
소프트웨어 회사가 자체 인증 문서를 공개적으로 게시하고 제안서에 게시 링크를 제공하지 않는 한 기관은 자체 증명 문서를 보관할 수 있습니다.
참고: 현재까지 다른 모든 메모나 지침에서는 자체 증명이 시작하기에 충분하다고 주장하지만, 이 문서에서는 신뢰와 투명성을 주요 목표로 설정합니다. 특히 사이버 보안이나 SSDF(그 일부인 경우에도)뿐만 아니라 소프트웨어 공급망에 중점을 둡니다.
소프트웨어 회사가 표준 형식으로 자체 증명을 제공할 수 없으면 어떻게 되나요?
소프트웨어 생산자는 표준 자체 증명 양식에 식별된 NIST 지침의 하나 이상의 관행을 증명하지 못할 수도 있습니다. 이 경우 소프트웨어를 요청하는 기관은 회사에 다음을 요구합니다.
- 증명할 수 없는 관행을 식별합니다.
- 이러한 위험을 완화하기 위해 사용 중인 모든 관행을 문서화합니다.
- 행동 계획 및 마일스톤(POA&M) 개발
당연히 기관에서는 문서가 공개적으로(공급업체 또는 기관 자체에 의해) 게시되지 않도록 해야 합니다.
공급업체가 모든 문서를 제공하고 해당 문서가 기관에 만족스럽다고 가정해 보겠습니다. 이 경우 생산자가 완전한 자체 증명을 하지 않았음에도 불구하고 후자는 소프트웨어 제품이나 서비스를 사용할 수 있습니다.
허용 가능한 자체 증명에는 무엇이 포함되어야 합니까?
자체 증명 문서에는 다음과 같은 최소 요구 사항이 포함되어야 합니다.
- 소프트웨어 회사 이름
- 설명이 언급하는 소프트웨어 제품에 대한 설명(이상적으로는 이 지점은 대행사에 제공되는 분류되지 않은 모든 제품을 포함하여 소프트웨어 회사 또는 제품 라인 수준을 설명합니다)
- 공급업체가 안전한 개발 관행 및 작업에 따라 운영되고 있음을 확인하는 진술서(자체 인증 양식에 항목별로 표시)
이러한 유형의 자체 증명은 최소 요구 수준입니다. 그럼에도 불구하고 기관이 소프트웨어 없이 소프트웨어를 조달하려는 경우(예: 중요성으로 인해) 제3자 평가의 도움을 받아 위험 기반 결정을 수행할 수 있습니다(에 정의됨). M-21-30).
그럼에도 불구하고 이 지침은 기관이 표준 자체 증명 양식을 사용하도록 권장합니다. FAR(Federal Acquisition Regulatory) 위원회는 이러한 표준 및 통일된 자체 증명 양식 사용에 관한 규칙 제정을 제안할 것입니다.
오픈 소스 소프트웨어에 대한 자체 증명
해당 기관이 오픈 소스 소프트웨어 또는 오픈 소스 구성 요소를 포함하는 소프트웨어 제품을 구매하기를 원한다고 가정해 보겠습니다. 이 경우 인증된 FedRAMP 3PAO(제XNUMX자 평가자 조직)에서 제공하는 제XNUMX자 평가나 기관 자체에서 승인한 평가로 전환할 수 있습니다.
3PAO가 NIST 지침을 기준으로 사용하는 한 공급업체의 자체 증명 대신 이러한 평가가 허용됩니다.
SBOM은 업계 표준이 되고 있습니다. 준비가 되셨나요?
자체 인증은 필요한 최소 수준이지만, 기관에서 얻으려는 제품이나 서비스가 중요하고 표준 형식으로 자체 인증을 제공할 수 없는 경우 기관에서 필요하지 않을 수 있습니다.
중요한 것은 이 메모가 기관이 보안 소프트웨어 개발 관행에 대한 적합성을 입증하는 아티팩트를 공급업체로부터 획득하도록 권장한다는 것입니다. 그러한 관행 중 하나에는 SBOM이 포함됩니다.
SBOM이란 무엇이며 어떻게 작동하나요?
SBOM은 소프트웨어 제품 개발 및 제공의 일부인 모든 구성 요소 및 종속성의 목록인 소프트웨어 BOM을 나타냅니다.
대행사는 다음을 요구할 수 있습니다. SBOM 기관에 대한 소프트웨어의 중요성에 따라 요청 요구 사항의 일부로 사용됩니다.
메모에는 기관의 SBOM 조달 및 사용에 대한 다음 지침이 포함되어 있습니다.
- 소프트웨어 제작자가 SBOM을 게시하고 이에 대한 링크를 기관과 공유하지 않는 한 기관은 SBOM을 보유할 수 있습니다.
- SBOM은 다음에 정의된 데이터 형식 중 하나를 사용하여 생성되어야 합니다. NTIA 보고서 "소프트웨어 자재 명세서(SBOM)의 최소 요소" 또는 사이버 보안 및 인프라 보안 기관.
- SBOM을 고려할 때 기관은 SBOM과 다른 기관이 유지 관리하는 소프트웨어 제작자의 기타 아티팩트의 상호성을 고려해야 합니다. 이는 직접적인 아티팩트 적용 가능성 및 통화를 기반으로 합니다.
- 기관은 필요한 경우 SBOM 이외의 아티팩트를 요구할 수 있습니다. 예를 들어 소스 코드 무결성을 검증하거나 취약점 검사를 수행하기 위한 자동화된 도구 및 프로세스와 관련된 아티팩트가 있습니다.
- 기관은 또한 소프트웨어 회사에 그들이 참여하고 있다는 증거를 제시하도록 요구할 수도 있습니다. 취약점 공개 프로그램.
메모에는 또한 대행사가 인수 과정에서 가능한 한 빨리 이러한 요구 사항을 공급업체에 알릴 것을 제안했습니다. Order 및 NIST 지침을 준수하려면 기관은 적절하게 계획을 세우고 소프트웨어 평가 프로세스에 모든 요구 사항을 포함해야 합니다. 이는 메모에 지정된 일정과도 일치해야 합니다(이 내용은 다음 섹션에서 다룹니다).
대행사는 RFP(제안 요청서) 또는 기타 모집 문서에 요구 사항을 명시해야 합니다. 여기서의 아이디어는 대행사가 공급업체가 구현하고 사용하는지 확인하는 것입니다. 안전한 소프트웨어 개발 관행 전체 소프트웨어 개발 수명주기 동안 NIST 지침을 준수합니다.
SBOM은 확실히 광범위한 사용 경로, 특히 완화를 위한 업계 모범 사례입니다. 소프트웨어 공급망 위험.
기업이 소프트웨어 제품에 대한 신뢰를 구축할 수 있도록 돕기 위해 최근 우리는 SBOM을 생성하고 이를 조직 내외에서 공유하는 데 도움이 되는 사용하기 쉬운 플랫폼을 출시했습니다. 시도 해봐 SBOM을 생성, 관리 및 공유하는 것이 얼마나 쉬운지 무료로 확인해 보세요.
더 이상 단순한 권장사항이 아닙니다. 이제 따라야 할 의무적인 일정이 있습니다.
대행사는 다음 일정에 맞춰 메모 요구 사항을 준수해야 합니다.
- 대행사는 90 일 동안 "핵심 소프트웨어"에 대한 별도의 인벤토리를 포함하여 모든 타사 소프트웨어의 인벤토리를 작성합니다.
- 이내 120 일 동안, 그들은 "이 각서의 관련 요구 사항을 공급업체에 전달하고 소프트웨어 제공업체가 공개적으로 게시하지 않은 증명 편지가 하나의 중앙 기관 시스템에 수집되도록 하는 일관된 프로세스"를 만들어야 합니다.
- 그들은 또한 270 일 동안 "중요 소프트웨어"에 대해 공개적으로 게시되지 않은 증명서를 수집합니다. 1년 이내에 대행사는 모든 타사 소프트웨어에 대한 편지를 수집해야 합니다.
- 마지막으로, 내에서 180 일 동안 메모 날짜(14년 2022월 XNUMX일)부터 기관 CIO는 모든 교육 요구 사항을 평가하고 증명 문서 및 아티팩트를 검토하고 검증하기 위한 교육 계획을 개발해야 합니다.
대행사는 미해결 요구 사항을 충족하기 위한 계획과 함께 메모에 명시된 관련 마감일로부터 최소 30일 전에 연장을 요청할 수 있습니다. 면제를 요청하는 것도 가능하지만 예외적인 상황과 제한된 기간 동안만 가능합니다.
요약
OMB는 메모 날짜로부터 90일 이내에(2022년 XNUMX월 중순까지) 면제 또는 연장 요청 제출에 대한 구체적인 지침을 공유할 것입니다. 또한 CISA 및 총무처(General Services Administration)와 협의하여 기관 간 보호 및 공유를 위한 올바른 메커니즘을 갖춘 "소프트웨어 증명 및 아티팩트를 위한 중앙 집중식 저장소"에 대한 요구 사항을 결정할 것입니다.
이러한 중앙 위치는 언젠가는 자체 증명 양식 또는 SBOM을 넘어 다양한 보안 증거 및 증명을 위한 중앙 위치가 될 수 있습니다. 모든 증거를 공유 가능한 단일 장소에 배치하면 조직이 새로운 악용이나 CVE와 같은 공유 문제를 처리하는 데 도움이 됩니다.
이것이 바로 Scribe의 핵심입니다. 보세요 이 페이지 조직 내에서 그리고 조직 전체에서 SBOM을 생성, 관리 및 공유하기 위한 포괄적인 플랫폼에 대해 자세히 알아보세요.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
