사이버보안 전문가는 소프트웨어 제품을 구할 때 그 제품이 안전한지, 공격자를 차단하기 위해 현재 사용 중인 절차와 툴을 지원 또는 포용하면서 주어진 기능을 수행하는지를 알아야 한다.

공격이 계속해서 증가하고 소프트웨어 공급망이 어느 때보다 취약한 상태에서 소프트웨어 개발 프로세스의 두 가지 주요 개념인 설계상의 보안(secure by design)과 기본 보안(secure by default) 도입이 활발히 논의되고 있다.

이 둘의 차이점은 정확히 무엇이고, 둘 중 무엇이 더 중요하거나 성공할 가능성이 높을까? 아니면 모두 필요할까? 설계상의 보안과 기본 보안 사이에는 기술적인 측면과 시장 및 공급망 측면 모두에서 살펴볼 만한 몇 가지 중요한 차이점이 있다.

설계상 보안 : 최종 사용자에게 많은 혜택 제공

설계상 보안 소프트웨어는 새로운 개념이 아니다. 그 기원은 50여년 전의 웨어 보고서(The Ware Report)까지 거슬러 올라가지만, 최근 미국 CISA(Cybersecurity and Infrastructure Security Agency)의 주도로 이 개념을 지원하는 움직임이 다시 활발해지고 있다. CISA는 이에 관한 여러 가이드와 주의 사항, 그리고 기업들이 서명한 자발적인 서약을 발표했다.

기본 보안 소프트웨어는 사후에 보안을 “추가”하는 오랜 관행에서 벗어나 개발 프로세스 전반적으로 안전 장치와 보안 태세를 염두에 두고 만들어진다.

CISA가 이 개념을 지원하고 나선 배경은 솔루션 업체가 출시 속도, 수익, 기능, 이익과 같은 경쟁상의 이익을 보안보다 우선시하면서 지금까지 기술이 본질적으로 안전하지 않게 설계됐으며, 이 시스템적 위험이 고객, 소비자, 시민, 사회까지 이어진다는 판단이다.

이로 인해 많은 경우 고객이 제품의 본질적인 약점과 취약성을 패치, 강화, 구성, 해결해야 하고, 그렇지 않으면 보안 사고의 피해자가 될 위험을 떠안게 된다.

CISA에 따르면 “설계상의 보안은 기술 제품이 디바이스, 데이터, 연결된 인프라에 액세스하려는 악의적인 사이버 행위자로부터 적절히 보호되도록 만들어진다는 것”을 의미한다.

설계상 보안 원칙을 따르는 업체는 NIST의 보안 소프트웨어 개발 프레임워크(Secure Software Development Framework, SSDF)와 같은 보안 개발 관행을 시스템/소프트웨어 개발 수명 주기에 통합했으며, 배포를 포함한 과정의 전반에 위협 모델링과 같은 활동도 통합하고 있다.

개발자가 설계상 보안을 따르는 방법

CISA는 설계상 보안 개발을 구현할 수 있는 다음과 같은 구체적인 몇 가지 사례를 제공한다.

• 메모리 안전 프로그래밍 언어
• 안전한 하드웨어 기반과 라이브러리, 모듈과 같은 보안 소프트웨어 구성요소 사용
• 소프트웨어 자재명세서(Software bills of materials, SBOM)
• 정적/동적 애플리케이션 보안 테스트(Static/dynamic application security testing, SAST/DAST). 기본적으로 개발에 자동화된 보안 테스트를 통합하는 것으로, 많은 경우 지속적 통합 및 지속적 개발 파이프라인을 통해 촉진된다.

이런 활동은 일련의 취약점을 제거하고, 제품 제작 시 안전한 기반과 구성요소를 사용함으로써 제품의 내재적 위험을 완화하고, 제품의 약점과 취약점을 고객에게 전가하지 않고 개발 수명 주기의 조기에 식별하는 것을 목표로 한다.

또한 설계상의 보안은 고객의 통제 범위 밖에 있는 특정 유형의 공격과 약점을 줄이는 기회도 된다. 이와 달리 아래에 설명할 기본 보안의 경우 구성이 개입되고 고객이 조작할 수 있으며 잠재적으로 위험이 발생할 수 있다.

물론 더 안전하게 설계된 제품이라 해도 사용하는 방법에 따라 위험이 발생할 수 있다.

설계상 보안의 주된 문제점 : 개발자 동참 필요

그러나 CISA가 자료에서 강조한 바와 같이 이를 위해서는 경영진과 리더십의 적극적인 투자와 동참이 필요하다. 그래야 설계상의 보안 원칙을 다른 활동 및 인센티브와 동등한 우선 순위로 다루고 말잔치가 아닌 문화적 혁신으로 추진할 수 있기 때문이다.

여기서 과제는 보안 관점에서는 설계상의 보안이 현명한 방식이라는 데 동의하겠지만 개발자와 업체 관점에서는 경쟁 열위에 놓일 수밖에 없다는 점이다. 설계상 보안을 우선시하지 않으면 기능과 제품을 그만큼 더 빠르게 시장에 내놓고 결과적으로 시장 점유율과 매출, 고객 유치/보존 등에서 우위에 설 수 있다.

또한 많은 업체가 벤처 캐피탈의 자금을 받는데, 이런 자금에는 투자금 회수에 대한 기대, 그리고 사이버 공간은 비즈니스가 직면하는 많은 위험 중 하나에 불과하다는 현실이 따른다. 이들은 시장 점유율을 유지하고 매출 목표를 달성하고 고객 만족도를 높이고 브랜드 인지도/노출을 확대하고 가장 수익성 좋은 비즈니스 성과를 달성해야 한다.

즉, 사이버보안 하나에만 초점을 유지하기가 어렵다. 기업에서 사용할 수 있는 시간과 관심, 리소스는 한정적이며, 특히 초기 단계에서는 조직 전체의 성장과 회복탄력성을 보장하기 위해 이러한 리소스를 전략적으로 할당해야 한다.

또한 사이버보안 사고가 브랜드 평판 훼손, 고객 신뢰 저하, 매출 손실에 대한 많은 두려움과 불확실성, 의심을 일으키고 있지만 여러 조사에서 사이버보안 사고는 기업의 생존성과 수익성에 큰 영향을 미치지 않는 것으로 나타났다. SEC 8-K의 중대 보안 사고 보고에도 불구하고 기업의 주가에 대한 단기적 영향과 장기적인 영향 모두 거의 발생하지 않는다.

즉, 우리는 자본주의 사회에서 개발자가 자신에게 불이익이 될 것임을 알면서도 보안을 우선시하기 위해 스스로를 경쟁에서 불리한 위치에 서도록 요구하고 있는 것이다.

기본 보안 : 보안을 완전히 갖춘 상태

‘기본 보안’ 개발은 처음부터 최대한의 보안을 제공하는 것을 목표로 소프트웨어 구성요소가 모든 보안 기능이 완전히 구현된 상태로 최종 사용자에게 전달되도록 하는 데 초점을 둔다.

대부분의 사이버보안 전문가는 새로운 제품 또는 소프트웨어를 강화해서 공격 표면을 줄이기 위해 CIS 벤치마크, DISA STIG, 벤더 가이드 등을 적용한다. 기본 보안은 이 패러다임을 뒤집는다. 즉, 제품은 강화된 상태로 제공되며, 고객이 각자의 필요에 맞게 강화된 보안을 롤백하거나 느슨하게 조정해야 한다.

예를 들어 클라우드에서 기본 보안의 가장 대표적인 사례 중 하나는 AWS 심플 스토리지 서비스(S3)다. 지금까지 공개적으로 노출된 AWS S3 버킷으로 인해 광범위한 영향을 미치는 여러 보안 사고가 발생하면서 민감한 데이터를 노출된 경우가 여러 번 있었다.

역설적인 점은 S3는 2006년 3월에 출시됐고 이후 이와 관련하여 많은 보안 사고가 발생했지만 AWS는 거의 17년이 지난 2023년이 되어서야 S3 버킷의 기본 상태를 비공개로 설정했다는 것이다. 이 기본 보안으로의 전환에 따라 고객은 구성 시 공개된 S3를 비공개로 설정하는 것이 아니라 필요에 따라 비공개를 공개로 설정해야 한다.

이와 같은 사례는 벤더가 제품과 서비스에 기본 보안 구성을 적용해서 고객이 해서는 안 되는 일을 하지 못하도록 하는 안전장치를 구축하고 제품/서비스를 처음 사용할 때부터 공격 표면과 사고 위험을 최소화할 수 있음을 잘 보여준다.

기본 보안의 단점 : 설정 벗어나면 부가적인 위험 발생

CISA에 따르면 “기본 보안 제품은 고객이 안전한 기본값에서 벗어날 경우 이를 보상하기 위한 부가적인 통제 수단을 구현하지 않는 한 침해 가능성이 높아진다는 것을 고객이 민감하게 인지할 수 있도록 설계된다.”

CISA는 기본 보안 논의에서 구성의 역할을 강조하면서 다음과 같은 사례를 들었다.

• 다중 요소 인증
• 기본 비밀번호 제거
• 싱글사인온
• 보안 로깅

그러나 기본 보안의 경우 솔루션 업체가 안전한 구성으로 제품을 제공하더라도 고객이 필요에 맞게 이런 구성을 변경하면서 그로 인해 위험이 발생할 가능성이 있다.

솔루션 업체는 제품이 CISA가 정의한 MFA, SSO, 로깅 등의 보안 기본값을 갖도록 보장할 수 있지만 몇 가지 장애물이 있다. 그 중 하나는 현대 환경이 매우 복잡하고, 단일 제품의 구성도 수많은 변형을 가질 수 있어 벤더에서 모든 구성 변형을 나열해 대처하는 것은 현실적이지 않다는 점이다.

이는 사용자 경험 측면에서 마찰을 일으킬 수 있다. 즉, 사용자는 비즈니스에 필요한 작업 또는 자신이 원하는 작업을 수행하기 위해 보안 측면에서 최선이 아니더라도 제품을 맞춤 구성해야 할 필요를 느낄 수 있다.

CISA는 기본 보안 제품에 대해 이른바 “느슨한 보안 가이드”라는 새로운 개념도 도입했다(전통적으로 제품에 제공되는 “강력한 보안 가이드”와는 반대 개념). CISA는 악의적인 활동 또는 악용이나 사고 위험을 방지하기 위해 적용된 기본 구성을 변경해서 제품의 보안을 느슨하게 하는 방법을 설명하기 위해 이 같은 개념이 필요하다고 한다.

사용 편의성 측면의 대가도 필요

더 중요한 점은 제품이 클라우드, 인프라, SaaS, API, 마이크로서비스, 워크로드, 네트워킹 등으로 구성된 기업 생태계에 통합된다는 사실이다. 이런 모든 요소를 전체적, 일관적으로 구현하지 않을 경우 공격자가 악용할 수 있는 틈새가 발생하게 된다.

여기서 주목할 부분은 보안과 사용 편의성 간의 끝없는 싸움이다. “시스템이 안전하기를 바란다면 금고에 넣고 잠근 다음 호수에 던져 넣으라”라는 말을 들어봤을 것이다. 즉, 완전무결한 시스템은 없으며, 많은 경우 보안이 강화될수록 기능과 사용 편의성은 저하된다.

보안이 엄격해지면 기업과 사용자 경험에서 더 많은 마찰이 발생할 수 있다. 이 경우 보안이 너무 거추장스럽고 불편해서 사용자들이 보안을 우회하면서 우발적으로 약점, 위험, 취약점을 유발하는 음지 사용(IT, 클라우드, SaaS, 이제는 AI까지)과 같은 의도치 않은 결과가 발생하기도 한다.

긍정적인 소식으로, 최근 연구 결과를 보면 좋은 UX 디자인은 사이버보안을 개선하고 사용자를 배려한 보안과 시스템 및 소프트웨어의 통합을 지원한다고 한다. 물론 그렇다 해도 설계상 보안 개념, 그리고 SDLC의 일부로 보안과 함께 적절한 제품 관리를 수행하고 CX/UX과 같은 다른 전문 분야와 협력해야 할 필요성은 여전하다.

두 가지 모두 개선된 보안 제공

기본 보안과 설계상 보안, 두 가지 개념 모두 보안 태세를 강화하고 기업과 최종 사용자의 위험을 줄일 기회를 제공한다는 점은 분명하다. 둘 모두 각자의 과제는 있지만 소프트웨어와 기술 생태계에 긍정적인 영향을 미칠 기회가 풍부하다.

설계상 보안에서는 위협 모델링, 취약점 제거와 같은 활동을 포함해서 시스템, 소프트웨어 또는 제품의 기본 구조에 보안 기초를 구축해 넣는다. 이를 위해서는 벤더가 SDLC 전반에서 보안에 투자하고 보안을 출시 속도, 기능 속도, 매출, 수익 등 다른 인센티브 및 고려 사항과 대등하게 고려해야 한다.

기본 보안은 제품을 제공하기 전에 강화해서 고객 취약점과 악용을 줄이는 데 초점을 두며, 더 많은 소유권을 갖고 처음 제공할 때부터 안전하게 구성된 제품을 제공한다. 이 방법이 훨씬 더 실용적으로 보이며 출시 속도, 매출, 기능 속도 등의 다른 우선 요소와 꼭 경쟁할 필요는 없음을 감안하면 탄력을 얻을 가능성이 높다.

두 개념 모두 중요하고 광범위한 위함 감소를 추진하기 위해 필요하다. 그러나 이를 위해서는 시장 인센티브, 규제 기관, 비즈니스 리더십, 참여와 같은 다양한 요소 간의 융합과 디지털 제품을 설계, 개발하고 사회에 배포하기 위한 현대화된 접근 방식이 필요하다.

어려운 과제지만, 소프트웨어가 현대 사회의 거의 모든 측면을 움직이고 있고 그 추세가 수그러질 기미도 없는 만큼 잠재적인 혜택도 막대할 것이다.
dl-itworldkorea@foundryco.com