2022년 XNUMX월, 미국 관리예산처(OMB)는 보고서를 발표했습니다. 랜드마크 메모 미국 연방 정부가 허용할 수 있는 수준으로 소프트웨어 공급망을 보호하는 데 필요한 단계에 대해 설명합니다. 소프트웨어를 생산하는 정부 및 연방 기관과 사업을 하려는 모든 회사는 다음에 명시된 요구 사항과 일정을 준수해야 합니다. M-22-18 메모.
M-22-18은 소프트웨어 공급망의 보안과 무결성에 중점을 두고 다음의 역할에 특히 주의를 기울였습니다. SBOM. 여기에는 규정 준수에 필요한 단계를 구현하기 위한 요구 사항 목록과 일정이 포함되어 있습니다.
이 메모는 NIST가 작성한 두 가지 주요 문서를 확립했습니다. 보안 소프트웨어 개발 프레임워크(SSDF), SP 800-218및 소프트웨어 공급망 보안 지침 보안 소프트웨어 개발에 대한 NIST의 지침입니다. 이 메모에는 또한 연방 기관이 제품을 자유롭게 사용하기 전에 NIST 지침 준수 여부를 자체적으로 증명해야 하는 소프트웨어 제작자의 책임이 명시되어 있습니다. 이 자체 증명은 서명된 자체 증명 "공통 형식"의 형식을 취합니다. 새 소프트웨어 구매, 주요 버전 업그레이드, 소프트웨어 갱신 등 세 가지 범주의 소프트웨어에는 이 자체 증명 양식이 필요합니다.
M-22-18은 CISA가 해당 각서 날짜(120년 14월 2022일)로부터 120일 이내에 이 표준 자체 증명 "일반 양식"을 확립하도록 요구했습니다. 그 2023일이 XNUMX년 XNUMX월이 되었는데도 그 형태는 그대로 남아있습니다. 초안 양식 이에 대한 의견 수렴 기간은 26년 2023월 XNUMX일에 마감되었습니다. OMB 메모가 원래 기관에 중요한 소프트웨어에 대한 증명 수집을 시작하도록 지시한 시점은 대략 이 시점입니다.
공통 증명 양식에 대해 접수된 일부 의견을 바탕으로 OMB는 22년 18월 9일에 M-2023-XNUMX에 대한 수정안을 발표하는 것이 적절하다고 판단했습니다. 이 수정안의 제목은 다음과 같습니다. M-23-16. 새로운 각서는 기관이 소프트웨어 제작자로부터 증명을 수집할 수 있도록 M-22-18에 게시된 일정을 연장합니다. 이제 대행사는 데이터를 수집해야 합니다. 자기 증명 "공통 형식" OMB가 CISA 공통 자체 인증 양식을 승인한 후 3개월 이내에 "핵심" 소프트웨어에 대한 소프트웨어 생산자로부터 다른 모든 소프트웨어 생산업체는 OMB가 자체 인증 양식을 승인한 후 6개월이 소요됩니다.
이것부터 표준 자체 증명 양식이 주목을 받고 있는 것으로 보입니다. 여기에 무엇이 포함되어 있는지 좀 더 자세히 살펴보겠습니다. 또한 서명할 사람이 정확히 누구인지, 서명이 무엇을 의미하는지 살펴보겠습니다.
보안 소프트웨어 자체 증명 공통 양식
EO 14028부터 NIST 지침서, OMB 메모까지 일련의 규제에 따라 정부는 연방 기관과 민간 기업 모두를 보호하려는 목표를 갖고 있음이 분명합니다. 소프트웨어 공급망 취약점 그리고 침입. 민간 부문이 이에 대해 충분한 조치를 취하지 않았기 때문에(정부의 관점에서) 정부는 모든 사람(연방 정부에 제품을 판매하는 사람)이 따라야 하는 새로운 규정을 만들기 시작했습니다.
물론, (아직) 연방 정부에 제품을 판매하지 않더라도 이러한 회사가 더 매력적인 비즈니스 파트너가 될 것이기 때문에 이러한 규칙을 따르고 자신이 '안전'하다는 것을 자체 증명하는 것이 최선의 이익입니다. 제품과 사용자를 보호하기 위해 최선을 다하고 있는지 확인할 수 없는 회사와 비즈니스를 하고 싶은 사람이 누가 있겠습니까?
우리는 NIST 지침이 새로운 규정과 모범 사례의 기초임을 이미 확립했으므로 예를 들어 다음과 같은 동일한 제안이 나타나는 것은 놀라운 일이 아닙니다. SSDF 자기증명 형태로도 나타난다.
다음은 초안 문서의 간단한 예입니다.
보안 소프트웨어 자체 증명 공통 양식 초안에서 가져옴
왼쪽에는 요구 사항, 관련 EO 섹션, SSDF 사례 및 작업이 표시됩니다. 이것은 독자가 사이버 보안 및/또는 DevOps 또는 DevSecOps 비즈니스에 종사하지 않는 경우 완전히 명확하지 않을 수 있는 매우 포괄적인 요구 사항 목록(1페이지 반)입니다.
이 문서에서는 회사의 서명인이 양식에 설명된 모든 요구 사항이 일관되게 유지되고 목록의 요소가 더 이상 유효하지 않은 경우 회사가 영향을 받는 기관에 알릴 것임을 개인적으로 증명하도록 요구합니다.
문서에는 회사 내 누가 문서에 서명해야 하는지 명시되어 있지 않지만 이 양식은 회사가 연방 정부 및 그 기관과 비즈니스를 수행하기 위한 요구 사항이므로 CEO가 책임을 져야 하는 사람이라는 것이 합리적입니다. 여기. CEO는 맹목적으로 서명하지 않을 것이며 CTO와 CISO에게 회사가 이러한 모든 지침과 요구 사항을 준수하는지 확인하도록 (아마도 서면으로) 요청할 것입니다.
이러한 모든 요구 사항을 수집하고 증명할 수 있는 확립된 제품이나 운영 모드가 없기 때문에 어떤 의미에서 서명하는 각 회사는 자체적으로 '바퀴를 다시 발명'하고 나쁜 일이 일어나지 않기를 바랄 필요가 있습니다.
나쁜 일이 발생하면 연방 정부는 서명인을 추적하여 모든 양식의 요구 사항을 뒷받침할 수 있음을 보여주고 증명할 것입니다.
서명하지 않으면 어떻게 되나요?
첫째, 이 전체 증명은 현재 귀하의 소프트웨어가 연방 기관에서 사용되는 경우, 귀하의 소프트웨어를 연방 정부에 판매하려는 경우 또는 소프트웨어를 사용 중인 공급업체에서 귀하의 소프트웨어를 사용하는 경우에만 관련됩니다. 또는 연방 정부에 판매될 예정입니다.
자체 증명이나 다른 검증 가능한 형태의 SSDF 준수가 소프트웨어 생산 분야에서 새로운 '모범 사례'가 될 것이라는 모든 징후가 있기 때문에 '현재'라고 말한 것에 주목하세요.
따라서 귀하의 회사가 위에 언급된 그룹에 속하고 귀하가 명확한 양심을 가지고 이 문서에 서명할 방법을 찾을 수 없다고 가정하면 모든 것이 아직 손실된 것은 아닙니다. 증명의 단점이 어디에 있는지 설명하고 만족스러운 답변을 제공할 수 있다면 행동 계획 및 이정표(POA&M) 문제의 연방 기관은 여전히 귀하의 제품을 구매/사용하고 OMB를 대신하여 귀하의 소프트웨어에 대한 확장을 추구할 수 있습니다.
나쁜 소식은 POA&M 계획이 있든 없든 결국 완전한 증명 양식을 제공해야 한다는 것입니다. 즉, 양식에서 요구하는 모든 단계를 회사가 따랐고 귀하의 회사가 이를 연방 법원에 확인할 수 있어야 함을 의미합니다. 소프트웨어 개발 프로세스는 최소한 양식의 요구 사항만큼 안전합니다.
현재 이러한 형태의 증명에서 면제되는 유일한 소프트웨어는 연방 기관에서 개발한 소프트웨어와 무료로 사용할 수 있는 소프트웨어인 AKA 오픈 소스 소프트웨어입니다. 물론 대부분의 소프트웨어 공급망 보안 허점은 어떤 방식으로든 코드의 일부 오픈 소스 패키지로 추적될 수 있지만, 무료로 일하는 오픈 소스 개발자와 유지 관리 담당자가 소프트웨어에 대해 법적 구속력이 있는 보증을 제공하도록 강제하는 데는 실질적인 문제가 있습니다. 일반적인 안전성과 특히 이것이 내장된 소프트웨어의 안전성을 검증하는 것은 오픈 소스 소프트웨어를 사용하는 모든 사람에게 달려 있습니다.
최악의 시나리오
이 전체 소프트웨어 공급망 보안 성실성은 유명한 SolarWinds 마구 자르기. 너무 많은 세부 사항을 다루지 않고도 해킹 당시 18,000개 연방 기관을 포함하여 9명 이상의 회사 고객이 영향을 받았습니다.
몇 년이 지난 지금에서야 우리는 이 사건으로 인해 일부 법적 결과가 나타나기 시작했습니다. 증권거래위원회, 미국 증권거래위원회, 회사를 뒤쫓고 있어 전체적으로는 물론 몇몇 C레벨 임원 이후에도. 이는 보안 개발 관행을 입증했지만 해킹의 희생양이 된 소프트웨어 생산자에게 그러한 사건이나 유사한 사건이 닥칠 경우 정부 의도의 예로 볼 수 있습니다.
SolarWinds의 경우 회사는 이러한 법적 조치의 대상이 되는 모든 직원을 전적으로 지원하고 있습니다. 미국 법률 시스템을 알면 그러한 사건은 수년이 걸리고 많은 비용이 소요될 가능성이 높습니다. 벌금은 무시할 수 없으며 추정치를 기준으로 수백만 달러에 이를 수 있습니다. 피해를 입다.
모든 회사, 특히 중소기업이 SolarWinds만큼 직원을 철저하게 보호하는 것은 아니라고 상상할 수 있습니다. 문제는 피고인이 회사의 CEO라면 회사와 제품에 대한 시장의 신뢰가 심각하게 훼손될 가능성이 있다는 점이다. 돈이 많은 대기업의 지원 없이 SEC에 맞서면 순진한 CEO와 회사가 망가질 수 있습니다. 물론 사람들이 자신의 책임을 진지하게 받아들여 개발을 보장하도록 하는 것이 목적이지만 두려움 때문에 사람들이 자기 보존 측면에서 오류를 범하게 될 수도 있습니다. 이는 사람들이 잠재적인 SEC 소송에서 이길 수 없다고 생각하거나 그러한 사건의 비용과 나쁜 평판이 너무 심각해서 법원 소송 결과에 관계없이 숨기는 것이 더 낫다고 생각한다면 사이버 보안 사고를 숨기는 것이 낫다는 것을 의미합니다.
어떻게 서명할 수 있나요?
NIST SSDF 지침은 제안과 모범 사례로 가득 차 있지만 실용성에 대해서는 조명합니다. 각 회사는 고유하기 때문에 모든 사람에게 적합한 제품이나 시스템을 출시하는 것은 매우 어렵습니다. 이 경우 민간 부문이 개입하여 공백을 메우고 요구 사항을 준수하는 데 도움이 되는 생태계를 조성합니다.
예를 들어, Scribe가 플랫폼을 구축했습니다. 증명을 생성하고, 서명하고, 검증할 수 있는 기능을 제공한다는 개념을 기반으로 합니다. 우리는 곧 맞춤형 문서를 공개할 예정입니다. CISA 자기 증명서 양식, Scribe 솔루션이 요구 사항의 각 섹션에서 어떻게 도움이 될 수 있는지 보여줍니다. 계속 지켜봐 주시기 바랍니다.
시도 Scribe의 플랫폼은 무료입니다. 한 번 시도해 보시고 플랫폼을 귀하의 요구 사항에 맞추는 동시에 명확한 양심을 가지고 CISA 자체 인증 양식에 서명할 수 있는 방법을 알아보시기 바랍니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
