.jpg)
미국의 보안 담당 기관인 CISA의 국장이 얼마 전 폭탄발언을 했다. 이 때문에 많은 의견들이 오가기도 했는데, 그러면서 CISA가 줄기차게 강조해오고 있던 ‘설계 단계에서부터 보안’이라는 개념이 다시 한 번 주목 받고 있다. 마침 CISA가 관련 가이드라인까지 발표했는데, 어쩌면 이 문건에 주목하게 하려는 게 CISA 국장의 진짜 의도가 아니었을까 싶기도 하다.
[보안뉴스 문정후 기자] 지난 보안 행사에서 미국 사이버 보안 전담 기관인 CISA의 이스털리 국장이 기조 연설을 진행했었다. 그 자리에서 그녀는 수많은 개발자들을 도발했다. “진짜 빌런은 해커가 아니라 소프트웨어 개발자”라는 표현이 그녀의 입에서 나왔기 때문이다. 이에 여러 IT 매체들에서 이를 조롱하고 비꼬는 기사나 사설들을 내기도 했다. 우리나라에서는 비교적 조용히 지나갔지만 적어도 미국 IT 시장에서는 꽤 파장이 컸던 발언이었다.
물론 여기에는 맥락이 있다. 소프트웨어 개발을 한다고 해서 다 나쁜 놈이라는 건 당연히 아니다. 아직 덜 준비된, 즉 취약점이 덕지덕지 붙어있는 소프트웨어를 시장에 급히 내는 소프트웨어 업계의 관행이 잘못됐다는 걸 꼬집는 말이었던 것이다. 빠르게 출시해야 한다는 강박이 어느 순간부터 소프트웨어 업체들을 사로잡았고, 그러면서 이들은 취약점이 있든 말든 일단 시장에 내놓고 보는 걸 당연하게 여기기 시작했다는 지적이다.
취약점은 후속 패치로 해결하면 된다는 사고방식이 최근 증가하는 사이버 위협의 주요한 이유라는 건데, 그렇기에 그녀가 이끄는 CISA는 ‘설계 단계에서부터 보안(security by design)’을 계속해서 강조하고 있다. 그 CISA가 Security by Design에 관한 안내서를 얼마 전 공개했기에 해당 내용을 집중적으로 소개하고자 한다.
먼저 CISA는 “모든 기술 제조 업체(하드웨어 제조와 소프트웨어 개발 모두를 아우르는 말)가 설계 단계에서부터 보안 개념을 적용할 것을 권고한다”고 서두에 쓰면서 보고서를 작성했다. 예외가 없다는 표현을 한 것인데, 이는 “사이버 위협에 대한 부담을 고객들에게 전가시켜서는 안 되기 때문”이라고 밝혔다. 일단 출시하고 나중에 위험한 부분이 발견되면 패치로 메운다는 판매 전략은, 고객의 위기를 담보로 일단 수익을 챙기겠다는 것이라는 게 CISA와 현 바이든 정부의 변함없는 스탠스다. 후속 패치야 절대적으로 필요한 것이긴 한데, 그것만 믿고 초기 출시되는 제품의 품질을 낮춰서는 안 된다는 것이다.
“모든 기술 제조 업체가 고객의 사이버 위협 부담을 줄이는 방향으로 제품을 개발하고 출시할 것을 강력하게 권고합니다. 고객이 지속적으로 시스템을 모니터링하고, 정기 업데이트를 수행하며, 손상 복구에 항상 신경 써야 할 필요가 없도록 하라는 겁니다. 그들은 일반인이지 보안 전문가들이 아니니까요. 그러므로 소프트웨어 개발사가 직접 설정과 모니터링, 정기 업데이트를 책임지고 진행하는 게 맞습니다. 보안 문제에 대하여 소프트웨어 개발사가 담당해야 할 책임의 비중이 지금보다 훨씬 높아야 합니다.”
참고로 이번 가이드라인은 CISA만이 아니라 미국의 정보 기관인 NSA와 FBI가 함께 작성했다고 한다. 뿐만 아니라 여러 국제 기관과 타국 정보 기관들과도 피드백을 주고 받는 등, 되도록 많은 지역과 문화권, 국가의 독특한 사정과 차이도 최대한 반영하려 했다고 CISA는 밝혔다. 그 국제 기관 중에 한국 KISA도 포함되어 있다.
약간의 배경
사실 이 문건은 여러 번 검토를 거친 버전이다. 최초 가이드라인은 2023년 4월에 발표됐고, 그 때부터 계속해서 각계 각층의 피드백을 받아 수정할 내용을 수정하는 과정을 거쳤다고 한다. 이번 가이드라인은 이전 버전보다 많은 내용을 다루고 있으며, 어떤 규모의 개발사가 어떤 책임의 원칙을 갖게 되는지를 특히 비중 있게 다뤘다고 CISA는 설명한다. 이는 전에는 그리 심도 있게 다루지 않았던 내용이다. 즉, “설계 단계에서부터 보안”이라는 개념은 앞으로도 계속해서 발전할 것이라는 걸 시사한다. 실제 이번 문건도 최종 버전은 아니며, CISA는 “더 많은 피드백을 부탁한다”고도 쓰고 있다.
또한 전통적 개념의 소프트웨어 개발사들에만 적용되는 게 아니라 인공지능 소프트웨어 시스템을 갖춘 개발사에도 해당될 수 있도록 내용을 구성했다고 CISA는 밝히고 있다. 시대의 흐름을 반영했다는 뜻이 되기도 하지만, 아직까지는 인공지능 소프트웨어나 일반 소프트웨어나 보안이라는 측면에서는 크게 다르지 않다는 걸 말하기도 한다. “일부 요소들은 인공지능 소프트웨어에만 특수하게 적용되어야 하기도 합니다만 대부분의 중요 원칙들은 모든 소프트웨어 개발 행위에 적용될 수 있습니다.”
다만 CISA는 “설계 단계에서부터 보안”이라는 개념을 기존 소프트웨어 생애주기에 적용하는 게 간단한 일이 아니라는 걸 충분히 이해하고 있음을 밝히기도 했다. “소프트웨어 개발 절차라는 게 이미 확립되어 있는데, 거기에 보안 원칙을 처음부터 끼어맞추는 건 간단한 작업이 아니며, 뜻밖에 많은 시간이 걸릴 수 있음을 인지하고 있습니다. 규모가 작은 개발사라면 이런 어려움이 더더욱 커질 수 있다는 것도 알고 있습니다. 그럼에도 소프트웨어 산업이라고 한다면 지금처럼 소프트웨어가 삶의 곳곳에 편만하게 퍼져 있는 시대에 제품을 더 안전하게 만든다는 윤리 의식과 프로 정신, 기술적 방법을 널리 보급해야 할 의무가 있다고 믿습니다.”
설계 단계에서부터 보안(Security by Design)
CISA는 ‘설계 단계에서부터 보안’이라는 개념에 대해 다음과 같이 설명한다. “설계 단계에서부터 보안이라는 것은 기술 기반 제품들을 악용해 각종 장비나 데이터, IT 인프라에 접근하려는 공격자의 여러 가지 악의적 시도들을 가장 합리적이며 효율적으로 방지하는 방법을 모든 개발 단계에 구축한다는 걸 의미합니다. 보안은 여러 겹으로 하는 게 가장 안전하다고 알려져 있는데(이를 다층 방어(defense-in-depth)라고도 한다), ‘설계 단계에서부터 보안’도 그러한 보호의 겹 중 중요한 하나로 볼 수 있습니다. 개발이 이뤄지는 플랫폼에서부터 완성품이 배포되는 절차까지 모든 것을 고려하여 소프트웨어를 개발하는 게 ‘설계 단계에서부터 보안’입니다.”
이는 경영진의 사고방식의 전환을 요구하는 것이라고 CISA는 강조한다. “보안을 나중에 완성품이 나온 후 덧붙이는 것으로 이해한다면 설계에서부터 보안을 접목시킬 수가 없습니다. 즉 보안을 일종의 IT 기술로 본다면 이뤄질 수 없는 게 바로 이 ‘설계 단계에서부터 보안’이라는 개념인 것이죠. 보안을 비즈니스 우선 사항 및 기본 사항으로 인식하고 있어야 합니다. 경영진이 이런 철학을 가지고 일을 해야 회사 전체에 보안 중심 문화가 퍼질 수 있습니다.”
경영진의 상당한 결단이 요구되는 일이 수밖에 없다. “고객에게 보이지 않는 투자를 하는 것과 마찬가지거든요. 취약점이 덜 나오는 프로그래밍 언어로 개발 환경을 바꾼다든가 하는 것들이죠. 이는 환경에 따라 매우 많은 돈이 들어갈 수도 있습니다. 게다가 제품의 매력 포인트에 투자할 돈을 나눠서 고객 보호 기능에 투자해야 하는데, 이 역시 잘 보이지 않는 부분이죠. 어떻게 해서든 출시를 앞당기는 방식의 경쟁에 익숙해 있다면 보안부터 고려하는 게 절대 쉽지 않을 겁니다. 설계부터 보안을 강화하는 제작 방식이 완전무결한 건 아닙니다만, 적잖은 취약점들을 사전에 처리할 수 있는 게 사실이기 때문에 비용 면에서 상당히 절감되기도 하는데, 이를 인지해야 합니다.”
그러면서 CISA는 한 발 더 나아간 개념을 강조한다. 바로 ‘기본으로 제공되는 보안(Security by Default)’이다. “‘기본으로 제공되는 보안’이란, 추가 비용을 소비자에게 요구하지 않고도 제품에 보안 기능을 탑재하는 걸 말합니다. 최첨단 보안 기능은 아니더라도 일반적인 해킹 기술에 대응할 만한 기술을 기본적으로 갖추고 있는 제품들을 개발하는 것을 지칭하는 말이죠. 물론 이런 경우 소비자들도 개발사가 의도한 범위 안에서만 제품을 사용해야 하겠지요. 그것을 벗어날 경우 위험하다는 것과, 사고 발생 시 책임이 소비자에게 있다는 것을 강조해야 합니다.”
이런 ‘기본으로 제공되는 보안’을 CISA는 자동차 안전벨트에 비유한다. “어느 나라에서나 자동차를 새로 구입할 때 안전벨트를 옵션으로 넣지 않죠. 안전벨트를 빼는 대신 차를 더 저렴하게 판다던가 반대로 안전벨트 값을 따로 더 받는다고 생각해보세요. 상식 밖의 일이 되겠죠. 그렇다고 안전벨트가 모든 종류의 사고로부터 운전자나 승객을 지켜주는 무적의 방어 장치라고 생각하는 사람도 없고요. 소프트웨어도 마찬가지입니다. 완전 무결한 보안 장치까지는 바라지 않습니다. 적어도 기본적인 방어가 되는 기능은 반드시 소프트웨어들에 포함되어 있어야 합니다.”
안전한 소프트웨어 제품 개발의 3원칙
CISA는 상기한 모든 말들을 구체화시키는 작업을 이어가면서 가이드라인의 뒷부분을 채우고 있다. 먼저 설계 단계에서부터 보안을 도입할 수 있도록 하는 기본 원칙 세 가지를 제시했는데 이는 다음과 같다. 하나하나 항목이 제법 길다.
1) 고객이 겪는 보안 사고에 대한 결과를 소프트웨어 개발사가 지라 : 모든 사용자의 실수나 잘못을 소프트웨어 개발사가 정말 책임지고 해결해야 한다는 뜻이라기보다, 그런 철학을 반영하여(책임을 진다는 생각으로) 제품을 기획하고 설계해야 한다는 의미다. 고객의 아주 작은 실수 하나로 인해 치명적 사고가 번번이 발생한다면, 그건 고객만의 문제는 아니다. CISA는 이 항목을 다음과 같이 풀어 쓴다.
“소프트웨어 개발사는 애플리케이션 하드닝을 하고, 디폴트 설정을 보다 안전하게 하여 출시하는 등 출시되는 제품의 보안을 강화하기 위해 투자해야 합니다. 이는 소프트웨어를 100% 안전하게 만들라는 것이 아니라, 공격자가 공격을 실행할 때 들어가는 비용을 높여야 한다는 뜻입니다.” 지금은 너무나 쉽고 무력하게 그들의 공격을 허용하는 편이고, CISA가 짚고자 하는 것은 바로 그 지점이라는 뜻이다.
“보안 취약점은 제품 품질과 관련된 문제라는 걸 소프트웨어 개발사들이 받아들여야 합니다. 그러므로 보안은 품질 관리 측면에서 반드시 내장되어야 하는 것이지, 사고가 발생하면 그제야 덧대는 게 아니라는 걸 기본 원칙으로 삼아야 합니다. 사용자가 입력하는 값을 철저히 검사하고 적용할 수 있도록 하고, 메모리 안전 프로그래밍 언어를 되도록 사용하고, 소프트웨어 개발 주기를 보안성에 맞춰서 조정하는 등의 노력이 필요하다는 소리입니다.”
보안이 제품 품질과 직결된 문제가 될 때 사용자들은 그러한 소프트웨어를 사용함으로써 저절로 보안을 강화시킬 수 있게 된다고 CISA는 보고 있다. “소비자 모두가 보안을 강화하기 위해 스스로의 워크플로우나 작업 환경을 애써 바꿔야 한다는 건 너무나 이상적인 이야기입니다. 보안을 더 잘 아는 전문가들이 나서서 사용자가 최대한 쉽게 보안이라는 기능을 누릴 수 있도록 해주어야 합니다. 보안이 복잡하고 어려울 때 사용자들이 보안을 포기한다는 걸 우리는 지난 수십 년 동안 목격해 왔습니다.”
그렇다면 이 원칙(고객의 보안 사고에 소프트웨어 개발사가 책임진다)을 어떻게 실제 구현할 수 있을까? CISA는 이를 위해 다음 몇 가지를 제안하고 있다.
ㄱ) 기본 비밀번호 제거
ㄴ) 실제 사용 환경에서의 테스트 실시
ㄷ) 고객에게 전달할 보안 가이드라인 최소화(개발사가 대부분을 부담)
ㄹ) 레거시 기능의 제공 중단
ㅁ) 경고 알림과 조치 방안을 최대한 눈에 잘 띄게 표시
ㅅ) 소프트웨어와 관련된 위험 점검표 제공
또한 안전한 제품을 개발하기 위한 프로세스를 도입하는 것도 중요하다고 CISA는 지적한다. 그러기 위해서 다음과 같은 것들을 제안하고 있다.
ㄱ) 보안을 위주로 한 개발 프로세스의 문서화 및 준수(관련 프레임워크 적극 도입 권장)
ㄴ) 보안 성과 목표 설정 및 문서화(역시 관련 프레임워크 적극 도입 권장)
ㄷ) 개발 기간 내내 취약점 관리(즉, 품질 관리)
ㄹ) 오픈소스 소프트웨어 관리 및 활용에 관한 기준 설정 및 준수
ㅁ) 개발자들이 최대한 편하게 일할 수 있도록 안전한 개발 도구와 재료 제공
ㅂ) 소프트웨어 개발자들이 보안을 이해할 수 있도록 교육
ㅅ) 모의 공격 훈련을 실시하여 실제 상황 발생 시 재빨리 대응할 수 있도록 준비
ㅇ) 제로트러스트 아키텍처 구현
위에서 언급했다시피 ‘설계 단계에서부터 보안’이라는 건 소프트웨어 개발 행위만의 문제가 아니다. 비즈니스 경영진의 의지가 선행되어야만 비로소 구현될 수 있는 것이다. CISA는 ‘보안 사고 책임을 개발사가 진다’는 원칙을 실천하기 위해 보안 중심 비즈니스 관행이 수립되어야 한다고 강조하며 다음과 같은 것들을 권장하기도 했다.
ㄱ) 추가 비용 없이 사용자들에게 로그 제공. 필요하다면 로그 활용 및 관리 방법 교육도 제공.
ㄴ) 숨은 비용 제거. 예를 들어 아이덴티티 및 접근 관리(IAM) 서비스들 중 대다수가 SSO 서비스에 대한 비용을 별도로 청구하는데, 이 때문에 많은 기업들이 비밀번호보다 안전한 로그인 방법인 SSO를 기피하게 된다.
ㄷ) 공개 표준 채택. 네트워크 및 아이덴티티 프로토콜을 구현할 때 되도록 공개된 표준을 이용하는 게 독점 프로토콜을 활용하는 것보다 안전하다.
ㄹ) 업그레이드 도구 제공. 최신 제품이 너무 비싸거나 검증되지 않아 이전 버전들을 선택하는 사용자들이 많은데, 이를 존중하고, 소비자들이 향후 부담 없이 업그레이드 할 수 있도록 기회를 제공해야 한다.
2) 철저하게 투명하라 : 소프트웨어 업체의 자부심이라는 것이 ‘획기적이고 새롭고 톡톡 튀는 제품을 만들었다’는 데에만 있는 것은 더 이상 옳지 않다고 CISA는 지적한다. “안전하고 사고 나지 않는 제품을 만들어 출시하는 데에 자부심을 느껴야 합니다. 그리고 이런 점을 홍보하고 돋보이게 해서 경쟁에서 우위를 점할 수 있어야 합니다. 차별화된 보안성으로 경쟁에서 우위를 점한다는 건, 고객들에게 제품을 배포할 때 얻는 정보들이나 고객들의 상황과 관련된 피드백을 투명하게 공유하는 것을 필요로 한다. 또한 취약점 정보, 해결 방식, CVE 기록을 정확히 남기는 것 역시 중요하다. 한 마디로 취약점이 제품에서 발견됐을 때 이를 감추려고 애쓰는 게 아니라 오히려 해결 과정까지 떳떳하게 공개하라는 의미가 된다.
“투명성은 업계가 좋은 기준을 설정하는 데에 큰 도움이 됩니다. 투명성은 고정된 개념이 아닙니다. 시간이 지남에 따라 고객의 요구, 위협 행위자의 전술 변화, 기술 발전에 대응하여 변화할 수 있습니다. 투명성은 자원이 적은 개발사가 더 성숙하고 능력 있는 자원을 가진 개발사로부터 배울 수 있게 도와주기도 합니다. 이를 바탕으로 제품 개발 초기 단계에서 보다 현명한 보안 관련 결정을 내릴 수 있게 해 주며, 지속적인 관리 역시 가능하게 합니다. 결국 투명성이란 것은 제품에 대한 개발사의 책임감을 내재시키는 도구가 됩니다.”
이 투명성의 원칙을 적용하기 위해 CISA가 제안하는 것은 다음과 같다.
ㄱ) 보안 관련 통계와 추이를 공개
ㄴ) 패치 관련 통계 자료를 공개
ㄷ) 사용되지 않는 권한 관련 데이터 공개
ㄹ) 내부 보안 통제 시스템 수립
ㅁ) 위협 모델 공개
ㅂ) 개발 프로세스에 대한 자체 보안 평가 보고서 공개
ㅅ) 취약점 관련 내용 공개
ㅇ) 소프트웨어 구성 요소(SBOM) 공개
개발과 보안에 있어 투명함을 유지한다는 건 결국 비즈니스를 영위함에 있어서도 변화를 야기하게 된다. CISA는 비즈니스 차원에서 다음을 고려할 것을 권고하고 있다.
ㄱ) 보안 마인드가 출중한 사람을 기획 및 설계 책임자로 임명
ㄴ) 그런 책임자가 제품 기획에 앞서 보안 로드맵을 작성하도록 하고, 그것을 조직 전체에 공개
ㄷ) 메모리 안전 언어로 전환하기 위한 로드맵을 작성하고 공개
ㄹ) 각종 보안 조치에 대한 결과를 공개
3) 새로운 방식에 맞는 조직과 리더십을 구성하라 : 설계 단계에서부터 보안을 추구한다거나 보안 기능을 기본적으로 제공한다는 새로운 소프트웨어 개발론이 정착하려면, 기존의 조직 구조를 탈피해야 한다. 또한 보안을 진심으로 염려하고 신경 쓰는 사람이 조직의 맨 위에서 프로젝트를 주관해야 한다. 당연하지만 보안 상황이라는 것은 고객이 연루될 때가 많으므로 기업들은 그 어느 때보다 적극적으로 고객과의 소통에도 정성을 쏟아야 한다. 이런 필요 조건들을 충족시킬 만한 조직과 리더들이 있어야 한다.
하지만 리더들만으로는 불충분하다. 그 리더들이 아무리 뛰어난 인재이더라도 기업의 업무 프로세스나 오랜 세월 쌓여온 관행들이 보이지 않게 그 리더들의 걸음을 막아서는 일이 비일비재 하다. 즉 사람만이 아니라 시스템까지도 뒤집어 바꿔야 할 필요가 있는 것이다.
CISA는 이를 구체적으로 실천하기 위해 다음과 같은 사안들을 권장한다.
ㄱ) 연차 재무 보고서에 보안 관련 내용을 추가
ㄴ) 이사회에 보안 관련 내용을 정기적으로 보고
ㄷ) 보안 설계를 총괄하는 책임자의 권한을 회사 차원에서 강화
ㄹ) 실질적으로 의미가 있고 ‘갖고 싶어지는’ 인센티브(승진, 보너스, 휴가 등)를 내부적으로 마련
ㅁ) 보안 설계만을 위한 위원회와 팀을 구성
ㅂ) 고객 관리를 위한 위원회 및 팀을 구성(보안 관련 고객 피드백을 수집하고 후속 제품에 반영)
이런 체제가 갖춰진 회사라면 보안을 설계 단계에서부터 도입할 수밖에 없다고 CISA는 강조했다.
여기에 더해 보안을 중심으로 한 설계와 기획의 전략을 갖추는 것도 중요한데, CISA는 모범이 될 만한 로드맵의 사례를 다음과 같이 요약하여 제시하고 있다.
ㄱ) C#, 러스트, 루비, 자바, 고, 스위프트 등 메모리 안전 프로그래밍 언어의 도입과 사용.
ㄴ) 하드웨어 보안 장치의 적극적인 활용
ㄷ) 필요한 보안 소프트웨어들에 대한 적극적인 투자
ㄹ) XSS 취약점이 발생하는 걸 최소화 해주는 웹 템플릿 프레임워크의 적용
ㅁ) 정적 및 동적 애플리케이션 보안 점검
ㅂ) 소프트웨어 물자표(SBOM) 작성 및 공유
ㅅ) 취약점 공유 방법 설정 및 구축
또한 소프트웨어 개발사라면 다음과 같은 기본적인 내용을 준수함으로써 제품을 보다 안전하게 만들 수 있어야 한다고 CISA는 강조했다.
ㄱ) 기본 비밀번호 제거
ㄴ) 다중 인증 필수화
ㄷ) SSO 기본 제공
ㄹ) 보안 로깅 무료 제공
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 지난 보안 행사에서 미국 사이버 보안 전담 기관인 CISA의 이스털리 국장이 기조 연설을 진행했었다. 그 자리에서 그녀는 수많은 개발자들을 도발했다. “진짜 빌런은 해커가 아니라 소프트웨어 개발자”라는 표현이 그녀의 입에서 나왔기 때문이다. 이에 여러 IT 매체들에서 이를 조롱하고 비꼬는 기사나 사설들을 내기도 했다. 우리나라에서는 비교적 조용히 지나갔지만 적어도 미국 IT 시장에서는 꽤 파장이 컸던 발언이었다.
[이미지 = gettyimagesbank]
물론 여기에는 맥락이 있다. 소프트웨어 개발을 한다고 해서 다 나쁜 놈이라는 건 당연히 아니다. 아직 덜 준비된, 즉 취약점이 덕지덕지 붙어있는 소프트웨어를 시장에 급히 내는 소프트웨어 업계의 관행이 잘못됐다는 걸 꼬집는 말이었던 것이다. 빠르게 출시해야 한다는 강박이 어느 순간부터 소프트웨어 업체들을 사로잡았고, 그러면서 이들은 취약점이 있든 말든 일단 시장에 내놓고 보는 걸 당연하게 여기기 시작했다는 지적이다.
취약점은 후속 패치로 해결하면 된다는 사고방식이 최근 증가하는 사이버 위협의 주요한 이유라는 건데, 그렇기에 그녀가 이끄는 CISA는 ‘설계 단계에서부터 보안(security by design)’을 계속해서 강조하고 있다. 그 CISA가 Security by Design에 관한 안내서를 얼마 전 공개했기에 해당 내용을 집중적으로 소개하고자 한다.
먼저 CISA는 “모든 기술 제조 업체(하드웨어 제조와 소프트웨어 개발 모두를 아우르는 말)가 설계 단계에서부터 보안 개념을 적용할 것을 권고한다”고 서두에 쓰면서 보고서를 작성했다. 예외가 없다는 표현을 한 것인데, 이는 “사이버 위협에 대한 부담을 고객들에게 전가시켜서는 안 되기 때문”이라고 밝혔다. 일단 출시하고 나중에 위험한 부분이 발견되면 패치로 메운다는 판매 전략은, 고객의 위기를 담보로 일단 수익을 챙기겠다는 것이라는 게 CISA와 현 바이든 정부의 변함없는 스탠스다. 후속 패치야 절대적으로 필요한 것이긴 한데, 그것만 믿고 초기 출시되는 제품의 품질을 낮춰서는 안 된다는 것이다.
“모든 기술 제조 업체가 고객의 사이버 위협 부담을 줄이는 방향으로 제품을 개발하고 출시할 것을 강력하게 권고합니다. 고객이 지속적으로 시스템을 모니터링하고, 정기 업데이트를 수행하며, 손상 복구에 항상 신경 써야 할 필요가 없도록 하라는 겁니다. 그들은 일반인이지 보안 전문가들이 아니니까요. 그러므로 소프트웨어 개발사가 직접 설정과 모니터링, 정기 업데이트를 책임지고 진행하는 게 맞습니다. 보안 문제에 대하여 소프트웨어 개발사가 담당해야 할 책임의 비중이 지금보다 훨씬 높아야 합니다.”
참고로 이번 가이드라인은 CISA만이 아니라 미국의 정보 기관인 NSA와 FBI가 함께 작성했다고 한다. 뿐만 아니라 여러 국제 기관과 타국 정보 기관들과도 피드백을 주고 받는 등, 되도록 많은 지역과 문화권, 국가의 독특한 사정과 차이도 최대한 반영하려 했다고 CISA는 밝혔다. 그 국제 기관 중에 한국 KISA도 포함되어 있다.
약간의 배경
사실 이 문건은 여러 번 검토를 거친 버전이다. 최초 가이드라인은 2023년 4월에 발표됐고, 그 때부터 계속해서 각계 각층의 피드백을 받아 수정할 내용을 수정하는 과정을 거쳤다고 한다. 이번 가이드라인은 이전 버전보다 많은 내용을 다루고 있으며, 어떤 규모의 개발사가 어떤 책임의 원칙을 갖게 되는지를 특히 비중 있게 다뤘다고 CISA는 설명한다. 이는 전에는 그리 심도 있게 다루지 않았던 내용이다. 즉, “설계 단계에서부터 보안”이라는 개념은 앞으로도 계속해서 발전할 것이라는 걸 시사한다. 실제 이번 문건도 최종 버전은 아니며, CISA는 “더 많은 피드백을 부탁한다”고도 쓰고 있다.
[이미지 = gettyimagesbank]
또한 전통적 개념의 소프트웨어 개발사들에만 적용되는 게 아니라 인공지능 소프트웨어 시스템을 갖춘 개발사에도 해당될 수 있도록 내용을 구성했다고 CISA는 밝히고 있다. 시대의 흐름을 반영했다는 뜻이 되기도 하지만, 아직까지는 인공지능 소프트웨어나 일반 소프트웨어나 보안이라는 측면에서는 크게 다르지 않다는 걸 말하기도 한다. “일부 요소들은 인공지능 소프트웨어에만 특수하게 적용되어야 하기도 합니다만 대부분의 중요 원칙들은 모든 소프트웨어 개발 행위에 적용될 수 있습니다.”
다만 CISA는 “설계 단계에서부터 보안”이라는 개념을 기존 소프트웨어 생애주기에 적용하는 게 간단한 일이 아니라는 걸 충분히 이해하고 있음을 밝히기도 했다. “소프트웨어 개발 절차라는 게 이미 확립되어 있는데, 거기에 보안 원칙을 처음부터 끼어맞추는 건 간단한 작업이 아니며, 뜻밖에 많은 시간이 걸릴 수 있음을 인지하고 있습니다. 규모가 작은 개발사라면 이런 어려움이 더더욱 커질 수 있다는 것도 알고 있습니다. 그럼에도 소프트웨어 산업이라고 한다면 지금처럼 소프트웨어가 삶의 곳곳에 편만하게 퍼져 있는 시대에 제품을 더 안전하게 만든다는 윤리 의식과 프로 정신, 기술적 방법을 널리 보급해야 할 의무가 있다고 믿습니다.”
설계 단계에서부터 보안(Security by Design)
CISA는 ‘설계 단계에서부터 보안’이라는 개념에 대해 다음과 같이 설명한다. “설계 단계에서부터 보안이라는 것은 기술 기반 제품들을 악용해 각종 장비나 데이터, IT 인프라에 접근하려는 공격자의 여러 가지 악의적 시도들을 가장 합리적이며 효율적으로 방지하는 방법을 모든 개발 단계에 구축한다는 걸 의미합니다. 보안은 여러 겹으로 하는 게 가장 안전하다고 알려져 있는데(이를 다층 방어(defense-in-depth)라고도 한다), ‘설계 단계에서부터 보안’도 그러한 보호의 겹 중 중요한 하나로 볼 수 있습니다. 개발이 이뤄지는 플랫폼에서부터 완성품이 배포되는 절차까지 모든 것을 고려하여 소프트웨어를 개발하는 게 ‘설계 단계에서부터 보안’입니다.”
[이미지 = gettyimagesbank]
이는 경영진의 사고방식의 전환을 요구하는 것이라고 CISA는 강조한다. “보안을 나중에 완성품이 나온 후 덧붙이는 것으로 이해한다면 설계에서부터 보안을 접목시킬 수가 없습니다. 즉 보안을 일종의 IT 기술로 본다면 이뤄질 수 없는 게 바로 이 ‘설계 단계에서부터 보안’이라는 개념인 것이죠. 보안을 비즈니스 우선 사항 및 기본 사항으로 인식하고 있어야 합니다. 경영진이 이런 철학을 가지고 일을 해야 회사 전체에 보안 중심 문화가 퍼질 수 있습니다.”
경영진의 상당한 결단이 요구되는 일이 수밖에 없다. “고객에게 보이지 않는 투자를 하는 것과 마찬가지거든요. 취약점이 덜 나오는 프로그래밍 언어로 개발 환경을 바꾼다든가 하는 것들이죠. 이는 환경에 따라 매우 많은 돈이 들어갈 수도 있습니다. 게다가 제품의 매력 포인트에 투자할 돈을 나눠서 고객 보호 기능에 투자해야 하는데, 이 역시 잘 보이지 않는 부분이죠. 어떻게 해서든 출시를 앞당기는 방식의 경쟁에 익숙해 있다면 보안부터 고려하는 게 절대 쉽지 않을 겁니다. 설계부터 보안을 강화하는 제작 방식이 완전무결한 건 아닙니다만, 적잖은 취약점들을 사전에 처리할 수 있는 게 사실이기 때문에 비용 면에서 상당히 절감되기도 하는데, 이를 인지해야 합니다.”
그러면서 CISA는 한 발 더 나아간 개념을 강조한다. 바로 ‘기본으로 제공되는 보안(Security by Default)’이다. “‘기본으로 제공되는 보안’이란, 추가 비용을 소비자에게 요구하지 않고도 제품에 보안 기능을 탑재하는 걸 말합니다. 최첨단 보안 기능은 아니더라도 일반적인 해킹 기술에 대응할 만한 기술을 기본적으로 갖추고 있는 제품들을 개발하는 것을 지칭하는 말이죠. 물론 이런 경우 소비자들도 개발사가 의도한 범위 안에서만 제품을 사용해야 하겠지요. 그것을 벗어날 경우 위험하다는 것과, 사고 발생 시 책임이 소비자에게 있다는 것을 강조해야 합니다.”
이런 ‘기본으로 제공되는 보안’을 CISA는 자동차 안전벨트에 비유한다. “어느 나라에서나 자동차를 새로 구입할 때 안전벨트를 옵션으로 넣지 않죠. 안전벨트를 빼는 대신 차를 더 저렴하게 판다던가 반대로 안전벨트 값을 따로 더 받는다고 생각해보세요. 상식 밖의 일이 되겠죠. 그렇다고 안전벨트가 모든 종류의 사고로부터 운전자나 승객을 지켜주는 무적의 방어 장치라고 생각하는 사람도 없고요. 소프트웨어도 마찬가지입니다. 완전 무결한 보안 장치까지는 바라지 않습니다. 적어도 기본적인 방어가 되는 기능은 반드시 소프트웨어들에 포함되어 있어야 합니다.”
안전한 소프트웨어 제품 개발의 3원칙
CISA는 상기한 모든 말들을 구체화시키는 작업을 이어가면서 가이드라인의 뒷부분을 채우고 있다. 먼저 설계 단계에서부터 보안을 도입할 수 있도록 하는 기본 원칙 세 가지를 제시했는데 이는 다음과 같다. 하나하나 항목이 제법 길다.
1) 고객이 겪는 보안 사고에 대한 결과를 소프트웨어 개발사가 지라 : 모든 사용자의 실수나 잘못을 소프트웨어 개발사가 정말 책임지고 해결해야 한다는 뜻이라기보다, 그런 철학을 반영하여(책임을 진다는 생각으로) 제품을 기획하고 설계해야 한다는 의미다. 고객의 아주 작은 실수 하나로 인해 치명적 사고가 번번이 발생한다면, 그건 고객만의 문제는 아니다. CISA는 이 항목을 다음과 같이 풀어 쓴다.
[이미지 = gettyimagesbank]
“소프트웨어 개발사는 애플리케이션 하드닝을 하고, 디폴트 설정을 보다 안전하게 하여 출시하는 등 출시되는 제품의 보안을 강화하기 위해 투자해야 합니다. 이는 소프트웨어를 100% 안전하게 만들라는 것이 아니라, 공격자가 공격을 실행할 때 들어가는 비용을 높여야 한다는 뜻입니다.” 지금은 너무나 쉽고 무력하게 그들의 공격을 허용하는 편이고, CISA가 짚고자 하는 것은 바로 그 지점이라는 뜻이다.
“보안 취약점은 제품 품질과 관련된 문제라는 걸 소프트웨어 개발사들이 받아들여야 합니다. 그러므로 보안은 품질 관리 측면에서 반드시 내장되어야 하는 것이지, 사고가 발생하면 그제야 덧대는 게 아니라는 걸 기본 원칙으로 삼아야 합니다. 사용자가 입력하는 값을 철저히 검사하고 적용할 수 있도록 하고, 메모리 안전 프로그래밍 언어를 되도록 사용하고, 소프트웨어 개발 주기를 보안성에 맞춰서 조정하는 등의 노력이 필요하다는 소리입니다.”
보안이 제품 품질과 직결된 문제가 될 때 사용자들은 그러한 소프트웨어를 사용함으로써 저절로 보안을 강화시킬 수 있게 된다고 CISA는 보고 있다. “소비자 모두가 보안을 강화하기 위해 스스로의 워크플로우나 작업 환경을 애써 바꿔야 한다는 건 너무나 이상적인 이야기입니다. 보안을 더 잘 아는 전문가들이 나서서 사용자가 최대한 쉽게 보안이라는 기능을 누릴 수 있도록 해주어야 합니다. 보안이 복잡하고 어려울 때 사용자들이 보안을 포기한다는 걸 우리는 지난 수십 년 동안 목격해 왔습니다.”
그렇다면 이 원칙(고객의 보안 사고에 소프트웨어 개발사가 책임진다)을 어떻게 실제 구현할 수 있을까? CISA는 이를 위해 다음 몇 가지를 제안하고 있다.
ㄱ) 기본 비밀번호 제거
ㄴ) 실제 사용 환경에서의 테스트 실시
ㄷ) 고객에게 전달할 보안 가이드라인 최소화(개발사가 대부분을 부담)
ㄹ) 레거시 기능의 제공 중단
ㅁ) 경고 알림과 조치 방안을 최대한 눈에 잘 띄게 표시
ㅅ) 소프트웨어와 관련된 위험 점검표 제공
또한 안전한 제품을 개발하기 위한 프로세스를 도입하는 것도 중요하다고 CISA는 지적한다. 그러기 위해서 다음과 같은 것들을 제안하고 있다.
ㄱ) 보안을 위주로 한 개발 프로세스의 문서화 및 준수(관련 프레임워크 적극 도입 권장)
ㄴ) 보안 성과 목표 설정 및 문서화(역시 관련 프레임워크 적극 도입 권장)
ㄷ) 개발 기간 내내 취약점 관리(즉, 품질 관리)
ㄹ) 오픈소스 소프트웨어 관리 및 활용에 관한 기준 설정 및 준수
ㅁ) 개발자들이 최대한 편하게 일할 수 있도록 안전한 개발 도구와 재료 제공
ㅂ) 소프트웨어 개발자들이 보안을 이해할 수 있도록 교육
ㅅ) 모의 공격 훈련을 실시하여 실제 상황 발생 시 재빨리 대응할 수 있도록 준비
ㅇ) 제로트러스트 아키텍처 구현
위에서 언급했다시피 ‘설계 단계에서부터 보안’이라는 건 소프트웨어 개발 행위만의 문제가 아니다. 비즈니스 경영진의 의지가 선행되어야만 비로소 구현될 수 있는 것이다. CISA는 ‘보안 사고 책임을 개발사가 진다’는 원칙을 실천하기 위해 보안 중심 비즈니스 관행이 수립되어야 한다고 강조하며 다음과 같은 것들을 권장하기도 했다.
ㄱ) 추가 비용 없이 사용자들에게 로그 제공. 필요하다면 로그 활용 및 관리 방법 교육도 제공.
ㄴ) 숨은 비용 제거. 예를 들어 아이덴티티 및 접근 관리(IAM) 서비스들 중 대다수가 SSO 서비스에 대한 비용을 별도로 청구하는데, 이 때문에 많은 기업들이 비밀번호보다 안전한 로그인 방법인 SSO를 기피하게 된다.
ㄷ) 공개 표준 채택. 네트워크 및 아이덴티티 프로토콜을 구현할 때 되도록 공개된 표준을 이용하는 게 독점 프로토콜을 활용하는 것보다 안전하다.
ㄹ) 업그레이드 도구 제공. 최신 제품이 너무 비싸거나 검증되지 않아 이전 버전들을 선택하는 사용자들이 많은데, 이를 존중하고, 소비자들이 향후 부담 없이 업그레이드 할 수 있도록 기회를 제공해야 한다.
2) 철저하게 투명하라 : 소프트웨어 업체의 자부심이라는 것이 ‘획기적이고 새롭고 톡톡 튀는 제품을 만들었다’는 데에만 있는 것은 더 이상 옳지 않다고 CISA는 지적한다. “안전하고 사고 나지 않는 제품을 만들어 출시하는 데에 자부심을 느껴야 합니다. 그리고 이런 점을 홍보하고 돋보이게 해서 경쟁에서 우위를 점할 수 있어야 합니다. 차별화된 보안성으로 경쟁에서 우위를 점한다는 건, 고객들에게 제품을 배포할 때 얻는 정보들이나 고객들의 상황과 관련된 피드백을 투명하게 공유하는 것을 필요로 한다. 또한 취약점 정보, 해결 방식, CVE 기록을 정확히 남기는 것 역시 중요하다. 한 마디로 취약점이 제품에서 발견됐을 때 이를 감추려고 애쓰는 게 아니라 오히려 해결 과정까지 떳떳하게 공개하라는 의미가 된다.
[이미지 = gettyimagesbank]
“투명성은 업계가 좋은 기준을 설정하는 데에 큰 도움이 됩니다. 투명성은 고정된 개념이 아닙니다. 시간이 지남에 따라 고객의 요구, 위협 행위자의 전술 변화, 기술 발전에 대응하여 변화할 수 있습니다. 투명성은 자원이 적은 개발사가 더 성숙하고 능력 있는 자원을 가진 개발사로부터 배울 수 있게 도와주기도 합니다. 이를 바탕으로 제품 개발 초기 단계에서 보다 현명한 보안 관련 결정을 내릴 수 있게 해 주며, 지속적인 관리 역시 가능하게 합니다. 결국 투명성이란 것은 제품에 대한 개발사의 책임감을 내재시키는 도구가 됩니다.”
이 투명성의 원칙을 적용하기 위해 CISA가 제안하는 것은 다음과 같다.
ㄱ) 보안 관련 통계와 추이를 공개
ㄴ) 패치 관련 통계 자료를 공개
ㄷ) 사용되지 않는 권한 관련 데이터 공개
ㄹ) 내부 보안 통제 시스템 수립
ㅁ) 위협 모델 공개
ㅂ) 개발 프로세스에 대한 자체 보안 평가 보고서 공개
ㅅ) 취약점 관련 내용 공개
ㅇ) 소프트웨어 구성 요소(SBOM) 공개
개발과 보안에 있어 투명함을 유지한다는 건 결국 비즈니스를 영위함에 있어서도 변화를 야기하게 된다. CISA는 비즈니스 차원에서 다음을 고려할 것을 권고하고 있다.
ㄱ) 보안 마인드가 출중한 사람을 기획 및 설계 책임자로 임명
ㄴ) 그런 책임자가 제품 기획에 앞서 보안 로드맵을 작성하도록 하고, 그것을 조직 전체에 공개
ㄷ) 메모리 안전 언어로 전환하기 위한 로드맵을 작성하고 공개
ㄹ) 각종 보안 조치에 대한 결과를 공개
3) 새로운 방식에 맞는 조직과 리더십을 구성하라 : 설계 단계에서부터 보안을 추구한다거나 보안 기능을 기본적으로 제공한다는 새로운 소프트웨어 개발론이 정착하려면, 기존의 조직 구조를 탈피해야 한다. 또한 보안을 진심으로 염려하고 신경 쓰는 사람이 조직의 맨 위에서 프로젝트를 주관해야 한다. 당연하지만 보안 상황이라는 것은 고객이 연루될 때가 많으므로 기업들은 그 어느 때보다 적극적으로 고객과의 소통에도 정성을 쏟아야 한다. 이런 필요 조건들을 충족시킬 만한 조직과 리더들이 있어야 한다.
[이미지 = gettyimagesbank]
하지만 리더들만으로는 불충분하다. 그 리더들이 아무리 뛰어난 인재이더라도 기업의 업무 프로세스나 오랜 세월 쌓여온 관행들이 보이지 않게 그 리더들의 걸음을 막아서는 일이 비일비재 하다. 즉 사람만이 아니라 시스템까지도 뒤집어 바꿔야 할 필요가 있는 것이다.
CISA는 이를 구체적으로 실천하기 위해 다음과 같은 사안들을 권장한다.
ㄱ) 연차 재무 보고서에 보안 관련 내용을 추가
ㄴ) 이사회에 보안 관련 내용을 정기적으로 보고
ㄷ) 보안 설계를 총괄하는 책임자의 권한을 회사 차원에서 강화
ㄹ) 실질적으로 의미가 있고 ‘갖고 싶어지는’ 인센티브(승진, 보너스, 휴가 등)를 내부적으로 마련
ㅁ) 보안 설계만을 위한 위원회와 팀을 구성
ㅂ) 고객 관리를 위한 위원회 및 팀을 구성(보안 관련 고객 피드백을 수집하고 후속 제품에 반영)
이런 체제가 갖춰진 회사라면 보안을 설계 단계에서부터 도입할 수밖에 없다고 CISA는 강조했다.
여기에 더해 보안을 중심으로 한 설계와 기획의 전략을 갖추는 것도 중요한데, CISA는 모범이 될 만한 로드맵의 사례를 다음과 같이 요약하여 제시하고 있다.
ㄱ) C#, 러스트, 루비, 자바, 고, 스위프트 등 메모리 안전 프로그래밍 언어의 도입과 사용.
ㄴ) 하드웨어 보안 장치의 적극적인 활용
ㄷ) 필요한 보안 소프트웨어들에 대한 적극적인 투자
ㄹ) XSS 취약점이 발생하는 걸 최소화 해주는 웹 템플릿 프레임워크의 적용
ㅁ) 정적 및 동적 애플리케이션 보안 점검
ㅂ) 소프트웨어 물자표(SBOM) 작성 및 공유
ㅅ) 취약점 공유 방법 설정 및 구축
또한 소프트웨어 개발사라면 다음과 같은 기본적인 내용을 준수함으로써 제품을 보다 안전하게 만들 수 있어야 한다고 CISA는 강조했다.
ㄱ) 기본 비밀번호 제거
ㄴ) 다중 인증 필수화
ㄷ) SSO 기본 제공
ㄹ) 보안 로깅 무료 제공
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-12-22] 
.jpg)
