<사진 출처 : www.freepik.com>

​

제3장 소프트웨어 공급망 보안의 강화 (행정명령 4절)

​

행정명령 4절은 총 24항으로 구성되어 있으며, 각 항은 어떤 기관이 언제까지 무엇을 해야 하는지를 지시한다. NIST 등 각 부처와 기관은 행정명령의 내용에 따라 보안 강화를 위한 지침 발행, 주요 소프트 웨어의 정의 공표 및 보안 지침 발행, 소프트웨어 라벨링 등 필요한 조치를 수행해야 한다. 각 항의 세 부 내용과 기한은 Appendix A를 통해 확인할 수 있다. [그림 1]은 행정명령 4절 중 소프트웨어 제품을 개발하는 기업에서 대응해야 할 항목들을 시간 순으 로 정리한 것이다. 크게 주요 소프트웨어 관련, SBOM 관련, 소프트웨어 테스트 관련, 가이드라인 및 지 침 관련으로 나눌 수 있다.

​

가) '주요 소프트웨어(critical software)'

관련 '주요 소프트웨어'는 연방 정부에서 사용하는 주요 소프트웨어 제품에 대한 보안 기준을 개발하기 위 해 행정명령에서 도입한 개념으로, 일반적인 의미의 주요 소프트웨어와 구분하기 위해 EO-주요 (EO-Critical) 소프트웨어라 한다. EO-주요 소프트웨어로 지정된 소프트웨어는 연방 정부가 소프트웨어 를 구매 및 관리하는 방법을 포함하여 추가적인 활동을 필요로 한다. 따라서 서비스하고 있는 소프트웨 어 제품이 EO-주요 소프트웨어에 해당되는지 알아보고, EO-주요 소프트웨어를 위한 보안 조치를 적용해 야 한다. NIST에서 공표한 EO-주요 소프트웨어의 정의에 따르면, EO-주요 소프트웨어란 다음 속성들 중 하나 이상을 포함하는 소프트웨어 혹은 그러한 소프트웨어를 직접적으로 포함하는(direct dependencies) 소프트웨어를 의미한다. Ÿ 상승된 권한으로 작동되거나 권한을 관리하는 소프트웨어 Ÿ 네트워크 및 컴퓨팅 자원에 직접적으로, 혹은 권한을 부여받아 접근할 수 있는 소프트웨어 Ÿ 운용 기술이나 데이터로의 접근을 제어하기 위해 설계된 소프트웨어 Ÿ 신뢰와 직결되는 기능을 수행하는 소프트웨어 Ÿ 권한 있는 접근(Priviliged Access)으로 신뢰 경계 밖에서 운용되는 소프트웨어 NIST는 소프트웨어 시장의 규모, 범위 및 복잡성과 정부 내에서 필요한 인프라를 감안하여 EO-주요 소프트웨어의 공급망 보안 강화를 단계적으로 접근하기로 하였다. 행정명령을 처음 적용하는 단계에서는 스탠드얼론 및 온프레미스 소프트웨어를 중심으로 하고, 그 이후에 클라우드 기반 소프트웨어나 펌웨어, OT 분야의 소프트웨어 등을 포함시키는 것을 권장하였다. 첫 적용 범위에 해당되는 소프트웨어의 예비 리스트를 보면 운영체제, 웹 브라우저, 방화벽, 원격 취약점 검사 소프트웨어 등 광범위한 소프트웨어가 EO-주요 소프트웨어에 해당된다.

​

배포되는 방식과 무관하게 EO-주요 소프트웨어에 정의에 해당되는 제품은 모두 EO-주요 소프트웨어 이다. 오픈소스 소프트웨어 또한 예외가 아니다. EO-주요 소프트웨어의 정의에 해당되는 오픈소스 소프 트웨어를 컴포넌트로 사용하는 경우 이를 개발 프로세스에 포함시켜 요구사항을 준수해야 한다. 임베디 드 소프트웨어나 펌웨어 또한 EO-주요 소프트웨어에 해당될 수 있다. EO-주요 소프트웨어에 해당되는 소프트웨어 제품을 개발하는 기업은 EO-주요 소프트웨어에 대한 보 안 조치를 제품에 적용해야 한다. 보안 조치에 대한 지침은 기존에 발행된 여러 보안 관련 문서를 기반 으로 하는데, 그 중 NIST의 Cybersecurity Framework와 SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations를 우선적으로 참조하여 만들어졌다. 지침은 다섯 가지 목표와 그에 맞는 조치로 구성되어 있으며, 간략한 내용은 다음과 같다. 1. EO-주요 소프트웨어를 인증되지 않은 접근 및 사용으로부터 보호 (1) 다중 요소 인증 사용 (2) EO-주요 소프트웨어 및 플랫폼에 접근하는 각 서비스를 고유하게 식별 및 인증 (3) 네트워크 기반 관리를 위한 권한 있는 접근(privileged access) 관리 원칙 준수 (4) 적절한 경계(boundary) 보호 기법 사용 2. EO-주요 소프트웨어에서 사용되는 데이터의 CIA 보호

​

나) SBOM 관련

SBOM은 Software Bill of Materials의 준말로 소프트웨어를 빌드하기 위해 사용된 여러 컴포넌트에 대한 내용과 공급망 관계를 형식에 맞춰 기록하는 것을 의미한다. 식품의 성분표와 비슷한 역할을 한다 고 볼 수 있다. SBOM은 소프트웨어 제품을 생산, 소비, 운용하는 자가 공급망에 대해 더 깊이 이해하 고, 알려진 혹은 새로운 취약점과 위협을 추적할 수 있게 한다. 특히 알려진 취약점의 확산을 저지하는 데 효과적이다. SBOM은 소프트웨어가 어떤 패키지를 포함하는지, 어떤 코드와 파일로 구성이 되는지, 어떤 인증을 받았는지 등 소프트웨어에 대한 자세한 정보를 포함해야 한다. [그림 1]은 소프트웨어가 개발되는 주기 의 각 단계가 SBOM에 어떻게 반영되는지를 나타낸 그림이다. SBOM은 소프트웨어를 설계하는 단계부 터 배포되기까지 고려되어야 하며, 배포 이후 유지보수 단계에서도 소프트웨어의 변경사항과 취약점 등 위험 관련 정보가 지속적으로 반영, 배포되어야 한다. 행정명령에 의해 NTIA에서 SBOM의 최소 요소를 공표하였다. SBOM의 최소 요소란 취약점 관리, 라 이선스 등 기본적인 SBOM의 활용에 필요한 최소 요소를 의미한다. 공표된 최소 요소는 크게 세 부분으 로 필수적인 항목, 자동화, 관행과 절차로 구성되어 있다. 필수적인 항목은 SBOM이 어떤 정보를 담아 야 하는지를, 자동화는 SBOM 생성이 자동화되어야 한다는 것을, 관행과 절차는 SBOM을 어떻게 관리 하고 운영해야 하는지를 담고 있다. 필수적인 항목의 경우 각 컴포넌트에 대해 추적하고 관리해야 하는 기본 정보를 지정한다. 기본 정보 는 컴포넌트 공급자명, 컴포넌트명, 컴포넌트 버전, 컴포넌트 식별을 위한 기타 고유 식별자, 의존 관계, SBOM 데이터 작성자, 타임스탬프로 총 7가지 항목으로 구성되었다. 자동화의 경우 SBOM을 생성하고 처리하기 위한 데이터 형식을 SPDX, CycloneDX, SWID의 세 가지 로 제한하고 있다. 리눅스 재단의 SPDX는 Software Package Data Exchange의 준말로, 오픈소스 라 이선스 관리를 중심으로 컴포넌트 관련 정보를 교환할 수 있는 SBOM 표준이다. OWASP의 CycloneDX는 오픈소스 컴포넌트에 대한 취약점 식별, 라이선스 관리 등을 위해 개발된 보안 취약점 중 심의 SBOM 표준이다. NIST의 SWID는 Software Identification의 준말로, 소프트웨어 수명 주기 전반 에 걸쳐 소프트웨어 인벤토리 자동화 및 관리를 하기 위해 개발된 SBOM 표준이다.

​

예시로 SPDX는 SBOM Generator를 제공하여 SBOM을 자동 생성할 수 있게 한다. [그림 2]는 패키 지 P1, P2, P3를 포함하고 있는 소프트웨어에 SBOM Generator를 사용했을 때 SBOM 파일이 생성되 는 과정을 나타낸 것이다. SBOM Generator는 Composer, Maven, NPM, PIP 등의 패키지 매니저를 지원하며 입력된 소프트웨어가 어떤 하위 패키지를 포함하고 있는지 정보를 추출하여 이를 SBOM으로 만든다.

​

다) 소프트웨어 테스트 관련

소프트웨어의 제품이 안전하다는 것을 검증하기 위해서는 소프트웨어 테스트가 불가결하다. 현재 사용 되는 테스트 방법은 위협 모델링, 자동화 검사, 정적 및 동적 분석 등으로 다양하기 때문에 어느 정도의 테스트를 거쳐야 소프트웨어가 충분히 안전한지 판단하기가 어렵다. 이번 행정명령에서는 소프트웨어 검 증에 권장되는 최소 기준을 마련하여 소프트웨어 생산자가 자체적인 검증 프로세스를 만들 수 있도록 돕고자 한다. 행정명령으로부터 60일 이내, NIST에서 소스 코드 테스트의 최저 기준에 대한 가이드라인을 공표하게 된다. 자발적인 가이드라인이기 때문에 의무적으로 준수할 필요는 없지만 추후 의무 사항이 될 가능성이 있으므로 미리 대비해두는 것이 좋을 것이다. 공표된 테스트 종류에는 위협 모델링, 자동화 검사, 코드 정적 분석, 동적 분석, 구성요소 검사, 버그 수정이 있다.

​

라) 가이드라인 및 지침 관련

행정명령 4절의 가장 핵심적인 산출물은 공급망 보안 강화를 위한 가이드라인과 실행 지침이다. 가이 드라인은 4절의 요구사항들을 만족시킬 수 있게끔 만들어지고, 지침은 가이드라인을 기반으로 만들어진 다. 지침에는 안전한 소프트웨어 개발 환경, 코드의 완전성을 확보하기 위한 자동화 도구 도입, SBOM 제공, 안전한 소프트웨어 개발 방법에 대한 적합성 증명 등 공급망 보안을 강화하기 위한 내용이 포함된 다. 예비 가이드라인과 관련된 내용의 경우 NIST에서 개발 중인 SP 800-161 Rev. 1 (2 nd Draft)의 Appendix F에 수록되었다. SP 800-161은 시스템과 조직을 위한 사이버보안 공급망 위험 관리 실행 지침에 대한 문서이다. SP 800-161 문서의 Appendix F의 내용을 보면 행정명령을 통해 나온 '주요 소 프트웨어의 정의' 등 산출물들의 내용에 대한 정리와 그 내용이 SP 800-161과 어떻게 연결이 되어있는 지 확인할 수 있다. 실행 지침의 경우 기존에 NIST에서 개발한 SSDF (Secure Software Development Framework)를 행정명령의 요구사항에 맞게 업데이트하는 것으로 대신한다. SSDF는 SDLC에 통합할 수 있는 고수준의 안전한 소프트웨어 개발 지침 모음으로 총 43개의 보안 조치로 구성되어 있다. 보안 조치는 조직에서 준비해야 하는 조치, 소프트웨어 보호를 위한 조치, 안전한 소프트웨어 생산을 위한 조치, 취약점 대응을 위한 조치의 네 종류로 구성되어 있다. 행정명령 내용을 반영한 SSDF 1.1 버전이 배포되었으며, 행정명 령의 요구사항과의 연결은 SSDF 문서의 Appendix A에 수록되어있다.

​