새로운 정부 지침 및 지속적 위협으로 인한 보안 소프트웨어 시급성 가중

새로운 정부 지침 및 지속적 위협으로 인한 보안 소프트웨어 시급성 가중

신규 지침 효력 발휘 전 지침 준수 및 위험 감축을 위해 필수 소프트웨어 개발 모범 사례를 이해해야 합니다.

바이든 대통령이 국가 사이버 보안 개선을 위한 행정명령 14028에 서명한지 일년 이상이 지난 시점에서 표준 및 컴플라이언스에 대한 기대가 집중 조명 받고 있습니다.

미국 국립표준기술연구소(The National Institute of Standards and Technology, NIST)와 미국 관리예산실(the Office of Budget and Management, OMB), 기타 미 정부 기관에서는 소프트웨어 공급망 가시성과 보안을 가속화할 여러 모범 사례 가이드라인과 지침을 발표했습니다.​ 이 표준은 연방 부서와 연방 기관 계약 사업자들을 위한 것이지만 중요 인프라 부문에도 큰 영향을 미칠 것으로 예상됩니다.

또한 지속적인 위협 활동 및 이슈들로 인해 철저한 소프트웨어 보안의 중요성이 다시 한번 대두되고 있다.​

• 남미 기반 해커 그룹 Lapsus$는 기술 선두 기업 삼성(Samsung)과 엔비디아(NVIDIA)를 해킹하여 소스 코드, 제품 개요도와 함께 코드서명 인증서까지 유출했습니다. 이 정보는 위협 행위자의 향후 공격 계획에 활용될 수 있습니다.

• Apache Log4J 취약점이 다양하게 악용되면서 원격 코드 실행(Remote code execution, RCE)이 가능해졌습니다. 소프트웨어 라이브러리는 소비자 및 기업 서비스에 광범위하게 사용되며, 이 취약점은 적절한 소프트웨어 공급망의 시각화 없는 오픈소스 코드 사용이 얼마나 위험한지 일깨워 주었습니다.

• Peter Zaitko의 트위터 내부 고발 사건은 보안 사고는 아니었으나 불충분한 소프트웨어 개발 수명 주기(software development life cycle, SDLC) 보안과 접근 권한의 무분별한 증가로 인한 보안 위험을 분명하게 보여줍니다. 이 내부 고발에서는 트위터의 일관성 없는 시큐어 코딩 규칙의 적용, 관리자 권한의 관리 부재에 대한 내용이 기술되었습니다.

​

행정명령 14028: 연방 및 기타 판매 기업에 대한 소프트웨어 보안 기준 강화

행정명령은 정보 유출 알림, 제로 트러스트, 네트워크 가시성 강화 등 다양한 사이버 보안 기대 사항들을 중요하게 다루고 있지만, 그 중 소프트웨어 공급망 보안이 가장 중요한 사안입니다. 핵심 명령 내용으로는 새로운 소프트웨어 보안 표준 및 베스트 프랙티스 개발, SBOM 제출, 소프트웨어 코드 검증 요구 공식화, 사물인터넷(IoT) 사이버보안 표준 개발이 있습니다. 여러 기관에서 행정명령준수를 위한 가이드라인 및 지침을 발행했습니다.

• 미국 국립표준기술연구소(NIST)의 중요 소프트웨어 정의(Definition of Critical Software)에서는 중요하다고 간주되는 소프트웨어의 기준 및 특징, "행정명령의 중요 소프트웨어(EO-critical software)" 사용상의 보안 조치를 포함하고 있다.

• NIST의 소프트웨어 개발자 증명을 위한 최소 표준(Minimum Standards for Developer Verification of Software)에 대한 가이드라인은 핵심 테스트와 확인 방법을 포함하고 있다.

• 미 상무부의 SBOM 최소 요소(Minimum Elements for an SBOM)

최근 행정명령 14028 원칙 실행과 관련하여 미 관리예산실(OMB)에서는 NIST의 보안 소프트웨어 개발 프레임워크 (Secure Software Development Framework,SSDF) 적용을 이끌 두 가지를 발표했습니다. OMB는 3월 미국 정부 기관에 소프트웨어 제품을 공급하는 모든 판매 업체에 대해 NIST SSDF를 채택하도록 지시함으로써 SSDF를 모범 사례 및 행정 명령 준수에 대한 권위 있는 참조로 공식화했습니다. 지난 달 OMB는 안전한 소프트웨어 개발 관행을 통한 소프트웨어 공급망 보안 강화를 발표했습니다. 해당 내용에서 OMB는 미 정부 판매 업체가 안전한 소프트웨어 개발 사례 및 업무의 증명을 비롯해 행정 명령 가이드라인을 실행하는데 필요한 단계에 대해 설명하고 있습니다. 해당 설명에서는 아직 미정의 표준 형식을 활용한 자체 증명을 사용하지만, 자체 증명이 최소한으로 요구되는 수준임을 나타내고 있습니다. 소프트웨어의 중요도에 따라 기관에서는 제3자 평가(assessment)가 필요한 위험 기반의 결정을 내릴 수 있습니다. 이러한 모호성으로 인해 미 정부 공급 업체들은 자체 증명 및 제3자 지원 가능성을 위한 단계들을 고려해야 합니다.

​

보안 소프트웨어 개발 프레임워크(SSDF)의 네 가지 핵심 원칙

미 국립표준기술연구소(NIST) SSDF(SP 800-218)는 미국 정부 소프트웨어 보안 목표의 반영과 운영에 있어서 구심점 역할을 하고 있습니다. 2월 SP 800-218은 기존의 2020 NIST 사이버 보안 백서를 대체하면서 SSDF를 정부의 중요 소프트웨어 보안 조직 구성체로 공식화했습니다.​ 해당 문서는 안전한 소프트웨어 개발을 위한 기반 사례들을 상술하며 네 가지 핵심 원칙을 담고 있습니다.

• 조직의 준비: 안전한 소프트웨어 개발을 수행하고 유지하려면 사람, 프로세스, 기술이 적절히 준비되어 있어야 합니다.

• 소프트웨어 보호: 조직은 소프트웨어의 모든 구성 요소를 위변조 및 무단 변경으로부터 보호해야 합니다.

• 견고한 소프트웨어 생산: 조직은 취약점을 최소화한 견고한 소프트웨어를 생산해야 합니다.

• 취약점에 대응: 조직은 취약점을 탐지해내고 알맞게 대응해야 합니다.

각 원칙 내에는 해당하는 사례(practices), 과업(tasks) 및 구현 예시(implementation examples)가 포함되어 있습니다. 또한 SSDF는 참조 섹션에서 이전에 발표된 모범 사례 프레임워크(예: BSIMM, OWASR 등)에 맞춰 조정합니다. 따라서 해당 분야에서 이미 실현된 훌륭한 업적도 인정되어 왔습니다.

SSDF는 또한 NIST 사이버 보안 프레임워크(NIST Cybersecurity Framework)의 접근 방식과 유사하게 공통 언어와 높은 수준의 사례(high-level practices)를 제공합니다. 하지만 SSDF의 사용자 맞춤화에 따른 유연성으로 인해 해석상의 문제와 모호성이 발생할 수 있습니다.​ 예를 들어 SSDF에는 정의된 각 과업(task)을 만족시키는 일련의 “개념적 실행의 예(notional implementation examples)”가 설명되어 있지만, 이 목록은 빈틈이 없는 것은 아니며 다양한 해석의 여지도 존재합니다. 조직 프레임워크로서는 이러한 유연성이 훌륭한 특성이지만, 규정 준수 체제로서는 해석 및 증명 상의 문제를 유발할 수 있습니다.

실무자의 SSDF 준수를 위한 새로운 가이드라인

기업이 행정 명령 14028에 명시된 요구 사항을 준수할 수 있도록 미 국가 안보 시스템의 보안 및 안정성에 대한 위협 및 위험을 다루는 부문간 워킹 그룹, ESF (Enduring Security Framework)의 소프트웨어 공급망 워킹 패널(Software Supply Chain Working Panel)은 '소프트웨어 공급망 보호' 라는 이름의 지침을 발표했습니다. 이 지침은 연방 정부를 위해 소프트웨어를 공급, 개발 및 구입하는 기업에 필요한 내용을 담고 있으며, 중요 인프라 공급 업체 및 구매자에 대한 새로운 요구 사항들을 다루고 있습니다. 개발자가 의존성을 획득하고, 안전한 소프트웨어를 통합 및 구축하며, 온전성을 유지하고 주장하는 동시에 소프트웨어를 배포하는 것을 돕는 접근법에 대해 상술합니다.

ESF 지침은 개발자, 공급 업체, 고객에게 더 높은 수준의 NIST SSDF 원칙과 관련시킬 수 있는 실질적 방안을 제시합니다.​ 다음의 예시는 ESF 지침이 SSDF 조정을 보완하는 방법을 상술하고 소프트웨어 보안에 대한 기대 증가를 다룹니다.

보안 소프트웨어 구성요소 유지

바이너리 통합 시 개발자는 소스 코드 제공없이 바이너리의 소프트웨어 구성을 분석하여 취약점을 찾아낼 수 있는 도구를 사용해야 합니다. 오픈 소스 프로젝트 등으로 부터 소스 코드를 제공받아 사용가능한 경우 정적 애플리케이션 보안 테스트(SAST) 도구를 활용할 수도 있습니다.

빌드(build) 환경 보호

개발자는 신뢰할 수 있는 구성 요소를 빌드 환경으로 가져오기에 앞서 빌드 환경이 내, 외부 위협에서 보호되는지 확인해야 합니다. ESF 지침은 빌드 타임 위협(build time threats), 악의적인 내부자 위협부터 미숙한 엔지니어, 잘못 설정된 액세스 권한, 빌드 체인 악용(exploit)에 이르기까지 다양한 대응 방법에 대해 정보를 제공합니다. 일반적으로 기업은 빌드 환경을 외부 네트워크 활동으로부터 보호하고, 모든 액세스가 기록되도록 설정하며, 데이터 유출을 모니터링하고, 빌드 파이프라인과 관련된 모든 기밀을 보호해야 합니다. ESF 지침에서는 파이프라인 보안 외에도 개발된 소스 코드를 소프트웨어 패키지에 빌드 및 통합하면서 소프트웨어 취약점의 예방, 테스트, 완화, 해결에 필요한 모든 활동을 수행하여 소프트웨어 위험을 최소화할 것을 권장합니다.

​

소프트웨어 패키지의 악용 감지 및 예방

소프트웨어가 위험을 최소화하는 방식으로 구축되고 나면 악의적 변조를 탐지 및 예방하는 방식으로 배포되어야 합니다. 예를 들어, 손상된 빌드 파이프라인을 통해 소프트웨어 패키지로 컴파일될 수 있는 악의적 사용을 탐지하고 예방하거나 손상된 배포 채널이 멀웨어(malware)나 백도어를 소프트웨어에 삽입하도록 허용하는 것이 있습니다. 배포 경로 보호 시, 업로드되는 모든 소프트웨어는 바이너리 소프트웨어 구성 분석(SCA)을 거쳐 패키지에 취약한 구성 요소가 없도록 해야 합니다. 바이너리 분석 결과는 개발자가 생성한 SBOM과도 비교해야 하며 모든 불일치를 조사해야 합니다.

안전한 소프트웨어 개발과 공급망 보호

몇 달 내로 정부가 SSDF 요구 사항을 확정하지는 않겠지만, 위협 환경과 규정 준수 압력의 정도를 고려할 때 조직들은 SSDF 프로그램에 맞도록 기업 포지셔닝을 시작해야 합니다. 특히 "중요 소프트웨어" 범주에 속할 수 있는 기업의 경우, 초기 SSDF 평가가 보고 기한 전에 보안 계획의 우선 순위를 정하는 데 도움이 될 수 있습니다. 미 정부에 납품하지 않는 기업들도 조달 규정에 SSDF 지침을 포함할 가능성 있는 상업적 구매자에 대한 소프트웨어 보안 기대가 높아지므로 SSDF에 맞추는 포지셔닝을 고려해 보아야 합니다. 또한 ESF 지침이 SSDF와 상호 운용 가능한 실용적 구현 지침을 제공할 수 있으므로 실무자는 ESF 지침을 숙지해야 합니다.

​

​

원문 게시일: 2022.10.25

원문 기고자: Synopsys Editorial Team

출처: https://www.synopsys.com/blogs/software-security/new-government-directives-and-threats-reinforce-urgency-secure-software.html