본문바로가기
  • BUSINESS
  • PRODUCT
  • CUSTOMER
  • COMMUNITY

제 목 소프트웨어 보안 관점에서 본 미국 사이버보안 행정명령과 우리의 대응방안
등록일 2022-01-14
첨부파일


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



 

제1장 서론

2021년 5월 12일, 미국 바이든 행정부는 『국가의 사이버보안 향상에 관한 행정명령(EO 14028) (2021)』을 내렸다. 이는 최근 콜로니얼 파이프라인 공격이나 솔라윈즈 공급망 공격과 같은 대규모 사이 버 공격 사례가 등장하여 사이버보안의 필요성이 증가했기 때문이다. 이러한 악성 사이버 공격이 공공 부문, 민간 부문을 넘어 개개인의 보안과 프라이버시까지 위협한다고 미국 정부는 판단한 것이다.

우리나라 또한 소프트웨어 보안 문제에서 자유롭지 않다. 소프트웨어에 국경이 없는 만큼 해외소프트 웨어의 취약점이 국내에 영향을 끼칠 수 있으며 반대의 경우도 마찬가지이다. 소프트웨어 공급망을 통해 전세계가 연결되어 있기 때문에 미국의 행정명령을 통해 나온 규제에서 국내 기업도 자유로울 수 없는 것이다. 많은 국내 소프트웨어 기업들은 소프트웨어 제품의 구현을 중심으로 하는 프로세스를 가지고 있다. 근 래의 사이버보안 요구사항은 소프트웨어 개발부터 유통까지 공급망의 모든 과정을 대상으로 하기 때문에 이에 대비하기 위해서는 많은 비용과 시간을 들여 근본적인 체질 개선을 해야 한다. 이번 행정명령과 같 은 변화를 미리 파악하고 대비하지 않으면 이후에 더 큰 비용으로 돌아올 수 있다. 본 문서는 소프트웨어 제품을 개발하는 기업에서 행정명령의 요구사항에 맞추기 위해 무엇을 준비해 야 할지 살펴보기 위해 작성되었다. 행정명령 중 소프트웨어 보안에 대한 부분인 4절의 내용과 연관된 문서들, 그리고 국내의 소프트웨어 보안 관련 정책을 분석하여 앞으로 국내 기업에서 소프트웨어 제품 보안 요구사항에 어떻게 대비해야 할지 점검하고자 한다.

제2장 미국 사이버보안 행정명령

이번 행정명령은 앞으로의 사이버보안 위협에 맞서기 위해 시행되는 조치로 총 11절로 구성되어 있다. l 1절 방침(Policy) n 행정명령의 배경과 목적에 대해 설명 l 2절 위협 정보 공유 과정의 장애물 제거 l 3절 연방 정부 사이버보안의 현대화 l 4절 소프트웨어 공급망 보안의 강화 l 5절 사이버안전심의회(Cyber Safety Review Board)의 설치 l 6절 연방 정부의 사이버보안 취약점과 사고 대응 전략 표준화 l 7절 연방 정부 네트워크에서 사이버보안 취약점과 사고 검출 개선 l 8절 연방 정부의 조사 및 복구 능력 향상 l 9절 국가안보시스템 l 10절 용어 정의 l 11절 일반적인 규정(General Provisions)

행정명령의 1절에서는 연방 정부와 민간 부문의 협력을 강조하고 있다. 안전한 사이버 공간을 만들기 위해 연방 정부는 사이버 공격을 방어, 탐지 및 대응하기 위한 노력을, 민간 기업은 끊임없이 변화하는 위협 환경에 적응하며 자사 제품이 안전하게 구축 및 운용되고 있는지 확인해야 한다는 것이다. 최종적 으로 디지털 인프라에 대한 신뢰를 구축하여 국가 및 경제의 안전을 보장하는 것을 목표로 한다. 행정명령 4절 ‘소프트웨어 공급망 보안의 강화’는 소프트웨어 개발 및 유통 과정에서의 보안 강화에 대 3 해 다룬다. 내용을 보면 보안 강화를 위한 지침 발행, 가이드라인 공표 등 어떤 기관이 언제까지 무엇을 수행해야 하는지를 지시하는데, 그 안에서 소프트웨어 제품 개발 기업에 요구되는 사항들을 볼 수 있다.


<사진 출처 : 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에 수록되어있다.




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


 

제4장 우리나라의 대응방안

국내의 경우 2021년 2월 발표된 'K-사이버방역 추진전략'에서 공급망 보안을 강화하기 위한 정책을 제시한 바 있다. 해당 정책에 따르면 주요 SW업체에 단계별 보안진단 및 조치 지원, 중소 SW업체에 자가 보안 진단 도구 및 가이드 보급, 주요 SW서비스 기업에 개발환경 보안점검 지원 및 공급망 검증 체계 구축, 공급망 보안점검 기준 및 점검도구 개발이 이루어진다고 한다. 위 내용에 따라 올해 8월 과학기술정보통신부 주관으로 '소프트웨어 개발 보안 허브'가 개소된 바 있 다. 중소기업에 소프트웨어 개발보안을 적용하여 공급망 공격을 예방하겠다는 것이다. 소프트웨어 개발 보안 활성화를 위해 보안약점 진단, 개발자 대상 교육 등의 사업이 추진된다. 아쉬운 점은 보안약점 진 단이 정적분석에 한정되어 있고, 국내 개발보안이 시큐어코딩으로 한정된 경우가 많다는 것이다.

제5장 결론

이번 사이버보안 행정명령이 여러 방면으로 많은 내용을 담고 있지만, 자세히 살펴보면 기존에 이미 존재하던 관행, 기준, 표준을 활용하여 재구성한 부분이 많다. 다만 기존에 권장 사항 정도로 존재하던 개념들이 행정명령을 통해 필수적으로 요구되는 사항이 될 수 있다는 점에서 의의가 있다고 볼 수 있다. 국내의 경우 이번 행정명령의 요구사항을 100% 만족하고 있는 기업은 많지 않을 것으로 예상이 되 고 있는 상황이다. 미국에서 나온 행정명령이지만, 소프트웨어의 국경이 모호한 시대인 만큼 국내 기업 에도 영향을 끼칠 것임은 자명한 일이다. 다행히 행정명령이 발령된 지 오래 되지 않았고, 아직 진행 중 이기 때문에 지금부터 대비한다면 대비할 시간은 충분하다. 소프트웨어 제품의 구현에 집중하다 보면 보안에 소홀해지곤 한다. 당장 눈에 보이지 않는 위험에 대 12 한 지불을 꺼리는 것이다. 솔라윈즈 공급망 해킹 사건을 보면 알 수 있듯이 공급망 공격은 큰 파급력을 가지고 있다. 소프트웨어 제품에 있는 작은 취약점이 돌이킬 수 없는 피해를 낳을 수 있다는 것이다. 이 번 행정명령이 국내에서도 보안을 중요시하는 문화가 자리잡는 계기가 될 수 있을 것으로 생각된다.


<자료 출처 : 한국인터넷 진흥원 KISA Library 이태준/ 고려대학교 컴퓨터보안연구실 연구원>

이 전 다 음
목록