효과적인 위협 모델링을 수행하기 위한 제언

본 게시글은 “How to approach threat modeling”의 내용을 기반으로 Security Specialist SA인 황재훈님이 한글로 재작성 하였습니다.

개요

본 블로그 포스트는 회사의 애플리케이션 개발 수명 주기에 위협 모델링을 도입하고 통합하는 방법에 대한 팁을 제공 하고자 작성되었습니다. 이미 위협 모델링을 체계적으로 수행하는 방법에 대한 훌륭하고 구체적인 가이드가 많이 있으므로, 여기서는 그러한 방법론에 대해서는 간단하게만 언급합니다. 대신, 위협 모델링을 계획하고 수행하는데 있어서, 인력, 프로세스 구성, 도구 선정, 접근 방식등에 대한 몇 가지 유용한 팁을 전달드리는데 중점을 둡니다. 물론 Amazon Web Services(AWS)를 사용하는 경우와 관련된 지침들도 포함됩니다.

그럼 우선 위협 모델링에 대한 기본적인 사항부터 살펴보겠습니다.

왜 위협 모델링을 수행 해야 하는가?

오늘날, IT 시스템은 이미 복잡하게 구성되어 있습니다. 심지어 시간이 지남에 따라 그 기능이 향상되고, 추가되며 다양한 서비스와 통합되면서 점점 더 복잡하게 발전하고 있습니다. 따라서 IT 시스템을 설계할 때, 단순히 원하는 기능이 동작하도록 하는것 이상으로 훨씬 더 많은 부분이 고려되어야 합니다. 특히 복잡함 속에서 놓칠 수도 있는 잠재적인 보안 위협요소를 구체적으로 파악하고 이에 대비하는 일이 매우 중요합니다. 이는 데이터에 대한 허가되지 않은 액세스, 서비스 가용성 부족, 리소스의 잘못된 사용, 데이터 소스의 오염 등을 통해서 회사 비즈니스에 영향 큰 영향을 미칠 수 있기 때문입니다.

이러한 복잡성과 다양한 시스템간 연동 사례로 인해, 구조화되지 않은 접근 방식을 통해서 위협 모델링을 수행하는 것은 효과적이지 못합니다. 따라서 워크로드에 대한 잠재적이고 핵심적인 위협을 식별하고, 이 위협들에 대한 대응 방안을 우선순위에 따라 체계적으로 정리하여, 회사의 제한된 자원을 활용해 워크로드 전반의 보안 태세를 최대한 향상시킬 수 있는 구조적인 접근 방식이 필요합니다. 위협 모델링은 이러한 체계적인 접근 방식을 제공하기 위해 설계되었으며, 시스템 설계 초기 단계에서 문제를 발견하고 해결하는 것을 목표로 합니다. 이는 수명 주기 후반에 문제를 해결하는 것보다 적은 자원을 투입하여 더 효과적인 완화 조치를 취할 수 있기 때문입니다.

AWS Well-Architected Framework는 보안 원칙 영역에서 위협 모델링을 특정 모범 사례로 강조하고 있습니다. 이는 “SEC 1: 워크로드를 안전하게 운영하려면 어떻게 해야 합니까?“라는 질문에 대한 답변의 일부로 제시됩니다.

“위협 모델을 사용하여 위협 식별 및 완화 조치의 우선순위 지정: 위협 모델링을 수행하여 워크로드에 대한 잠재적 위협 및 관련 완화 조치의 최신 등록을 식별하고 유지 관리합니다. 보안 위협 우선순위를 지정하고 보안 제어 완화 조치를 조정하여 방지, 감지 및 대응합니다. 워크로드와 진화하는 보안 환경에 맞춰 이를 보완하고 유지 관리합니다. “

위협 모델링의 핵심 단계

위협모델링을 수행하는 다양한 방법과 단계들이 있지만, 큰 틀에서 보면 다음과 같은 단계를 따릅니다:

1. 자산, 행위자, 진입 지점, 구성 요소, 사용 사례 및 신뢰 영역을 식별하고 이를 설계 다이어그램에 포함합니다.
2. 위협 목록을 식별합니다.
3. 각 위협에 대하여 필요한 조치들을 식별합니다.
4. 위협에 대한 조치가 충분히 적용되었는지 여부를 결정하기 위해서 위협 매트릭스(Risk matrix)를 작성하고 검토합니다.

이러한 단계들에 대하여 더 많은 내용을 살펴보려면 “SAFECode Tactical Threat Modeling 백서”와 “OWASP Threat Modeling Cheat Sheet”를 읽어보실 것을 권장합니다. 이러한 가이드는 특정 접근 방식을 채택할 때 고려할 만한 훌륭한 자료입니다. 또한, 위협 모델링 프로세스를 가속화하는 데 도움이 되는 여러 도구와 방법론을 참조하고 있습니다. 여기에는 OWASP Threat Dragon 프로젝트를 사용한 위협 모델 다이어그램 작성, OWASP Top 10, OWASP Application Security Verification Standard (ASVS), STRIDE를 사용한 잠재적 위협 결정 등이 포함됩니다. 이러한 도구와 방법론을 조합하여 사용하거나, 자체적으로 새로운 방식을 만들어 사용할 수도 있습니다

언제 위협 모델링을 수행 해야 하는가

위협 모델링은 설계 단계에서 수행되는 활동입니다. 설계 단계에서는 일반적으로 시스템의 목표를 달성하기 위해 필요한 자원을 파악하고, 시스템 아키텍처 다이어그램을 작성하며, 테스트 환경을 구축하고, 필요한 시스템 요소들을 구성합니다. 이렇게 설계된 개발 환경은 이후 실제 서비스 환경으로 이관되어 시스템이 정상적으로 동작하는 것을 보장하기 위해 다양한 요소들을 반영하게 됩니다.

위협 모델링은 바로 이 설계 단계에서 이루어집니다. 따라서 코드 리뷰, 코드 분석(정적 또는 동적), 침투 테스트와 같이 보안 수명 주기에서 나중에 이루어지는 활동에 우선합니다. 워크로드를 설계할 때는 초기 단계부터 잠재적 위협을 항상 고려해야 합니다. 그렇기 때문에 위협 모델링은 주로 초기 설계 미팅의 일부로서, 화이트보드(물리적 또는 가상) 앞에서 시작는 경우가 많습니다. 물론 초기 설계 단계 이후에도, 기능의 추가나 변경이 있을 때에도 추가적인 위협 모델링을 수행할 필요가 있습니다. 변경 사항으로 인해서 새로운 위협이 추가되거나 기존 위협이 변경 될 수 있으며, 거기에 적절하게 대응하기 위해서 기존의 위협 모델을 업데이트 해야 하기 때문입니다.

위협 모델링 시 고려 사항

위협 모델링은 브레인스토밍, 협업 및 커뮤니케이션을 요구하는 활동입니다. 그 목적은 애플리케이션이나 시스템의 개발, 운영, 비즈니스 및 보안 간의 격차를 줄이는 것입니다. 성공을 위한 지름길은 없지만, 위협 모델링의 채택과 성공에 의미 있는 영향을 미치는 요소들이 있습니다. 아래에서 이러한 요소들을 다루는 몇 가지 팁을 나열하였습니다.

1. 적절한 팀 구성

위협 모델링을 수행하려면, 다양한 팀 구성원의 지식과 기술이 요구됩니다. 특히 위협 모델링을 수행하는 동안 취합되는 의견 및 아이디어들은 모두 동등한 가치를 가진 것으로 간주하고 진행하기 때문에 다양한 관점이 더욱 요구됩니다. 이 섹션에 나열하는 여러 관점들은 모두 공통적으로 고객의 입장에서 부터 사고 하도록 권장됩니다. 아마존의 Working Backwords(거꾸로 일하기) 문화를 참조하시면 이해가 더욱 쉬울 것입니다. 바로 최종 고객의 기대에서 시작하여 역으로 최종 애플리케이션/시스템의 기능/서비스로 접근하는 것입니다. 고객 관점에서 이 워크로드나 워크로드 기능을 통해서 기대하는 결과와 거기에 필요한 보안 제어, 보안 제어에 따른 영향을 균형있게 고려할 필요가 있습니다. 다음에서 나열하는 여러 관점들이 위협 모델링을 수행하는 팀에 포함되도록 합니다. 물론, 한사람이 여러개의 관점을 가지고 참석 할 수도 있습니다.

비즈니스 관점 – 먼저, 워크로드 또는 기능의 비즈니스적인 결과를 주관하는 사람이 필요합니다. 이 사람은 워크로드의 기능적 및 비기능적 요구 사항을 깊이 이해하고 있어야 하며, 제안된 위협 완화 조치가 이러한 요구 사항에 과도한 영향을 미치지 않도록 보장해야 합니다. 즉, 제안된 보안 통제(완화 조치)가 애플리케이션을 정상적으로 사용할 수 없게 하거나 지나치게 성능이나 기능을 저하시키는 경우에는, 보안과 기능의 적절한 균형을 찾기 위해 추가 작업이 필요합니다.

개발자 관점 – 워크로드 기능에 대한 현재 제안된 설계를 가장 잘 이해하고 있으며, 지금까지 이루어진 설계 결정에 가장 깊이 관여한 사람입니다. 이들은 설계 브레인스토밍 또는 화이트보드 세션에 참여했으며, 설계에 대한 위협과 포함할 수 있는 완화 조치에 대해 생각해 왔을 것입니다. 자체 애플리케이션을 개발하지 않는 경우(COTS 애플리케이션 등) 내부 애플리케이션 소유자를 참여시킵니다.

공격자 관점 – 다음으로, 공격자 역할을 수행할 사람이 필요합니다. 이 역할의 목표는 공격자의 입장에서 워크로드 설계를 비판적으로 검토하고, 설계 결함을 이용해 특정 목표(예: 데이터의 탈취)를 달성할 방법을 찾는 것입니다. 이들이 수행하는 “공격”은 실제 키보드 조작이 아닌 가상의 공격입니다. 보안 조직에 레드 팀이 있다면 이 역할에 적합할 수 있으며, 그렇지 않다면 보안 운영 또는 엔지니어링 팀의 구성원이 이 역할을 수행할 수 있습니다. 또는 이 분야에 전문화된 제3자를 참여시킬 수도 있습니다.

방어자 관점 – 그 다음으로, 방어자의 역할을 수행할 사람이 필요합니다. 이 역할의 목표는 공격자가 나열한 가능한 “공격”을 잠재적 위협으로 보고, 이를 완화할 보안 통제를 고안하는 것입니다. 또한, 가능한 완화 조치가 지속적인 운영 지원, 모니터링 및 사건 대응 측면에서 합리적으로 관리 가능한지 평가합니다.

AppSec SME 관점 – 애플리케이션 보안(AppSec) 주제 전문가(SME) 역할은 위협 모델링 프로세스 및 토론 중재 방법에 가장 익숙해야 하며, IT 보안 지식과 경험이 풍부해야 합니다. 토론을 적절히 중재하는 것은, 전체 프로세스의 목표를 유지하고, 보안과 고객 결과 전달 간의 적절한 균형을 유지하기 위해 매우 중요합니다. 궁극적으로 이 역할이 위협 모델을 승인하고, 침투 테스트 범위와 같은 위협 모델링 연습 외의 작업 범위를 조언합니다.

2. 일관된 접근 방식 과 언어 사용

위협 모델링에 대한 일관된 접근 방식을 유지하면 더 신속하고 정확한 수행이 가능합니다. 예를 들어서 처음 위협 모델링에 참석하는 팀원이라고 할 지라도, 일관된 접근 방식을 사용한 다면, 이미 다른 팀 구성원이나 다른 팀이 개발한 위협 모델을 참조하여 역할을 빠르게 수행할 수 있습니다.

위협 모델을 새롭게 구성하고 수행하는 데 필요한 노력과 시간을 생각해 보면, 이미 수행한 이전의 위협 모델에서의 경험 및 사용된 시간을 그대로 활용하는 것이 더 빠르게 수행할 수 있을뿐 아니라, 위협 모델링의 일정도 현실적으로 정할 수 있습니다. 일관된 접근 방식과 형식을 사용하는 것 외에도 모델링하는 위협의 세분성과 관련성에 일관성을 유지하는 것이 중요합니다. 이 글의 뒷부분에서는 조직 전체에서 재사용할 수 있는 위협 카탈로그를 만드는 권장 사항에 대해 설명하겠습니다.

마지막으로 중요한 점은 이러한 접근 방식을 통해서 재사용성을 확보할 수 있다는 것입니다. 위협 모델링을 진행 할 때, 특정 워크로드의 기능을 검토해 보니 이미 동일한 기능에 대해서 다른 워크로드에서 위협 모델 수행이 완료된 적이 있다면, 그 구성 요소의 위협 모델이나 개별 보안 제어를 재사용할 수 있습니다. 이 방법을 통해 기존 구성 요소의 위협 모델을 효과적으로 활용하여 새로운 모델을 구축할 수 있으며, 결과적으로 불필요한 재작업을 피할 수 있습니다.

3. 소프트웨어 개발 및 배포 방법 참조

애플리케이션 개발 팀은 이미 개발 및 테스트를 위한 워크플로우와 배포 방법을 구현해 두고 있습니다. 흔히 사용하는 애자일(Agile) 방식의 개발 및 배포 방식을 사용한다고 예를 들면, 위협 모델링 접근 방식 역시 이 애자일 방법론과 도구에 잘 통합되도록 구현 하여야 합니다. 즉, 다른 모든 개발 산출물과 마찬가지로, 위협 모델링과 관련된 산출물 역시 워크로드 기능의 스프린트, 에픽 또는 백로그의 일부로 관리할 수 있습니다.

4. 기존 워크플로 도구 사용

마찬가지로, 애플리케이션 개발팀은 이미 개발/배포 방법론에 맞는 일련의 도구를 사용하고 있습니다. 여기에는 일반적으로 문서화를 위한 협업 도구(예: 팀 위키)와 소프트웨어 개발 수명 주기 동안 작업 결과물을 추적하는 이슈 추적 도구가 포함됩니다. 가능하다면, 이러한 도구를 보안 검토 및 위협 모델링 워크플로우에서 함께 사용하는 것이 권장됩니다.

기존 워크플로우는 개발 과정 및 운영과정에 있어서 통합된 도구와 방법론으로 표준화 됩니다. 즉 위협 모델링이 개발 워크플로우의 일부로 포함되면, 프로젝트를 완료하는 데 있어 보안팀과의 마찰을 예방할 수 있으며, 위협 모델링이 단위 테스트, QA 테스트 또는 기타 일반적인 워크플로우 단계처럼 일상화될 수 있습니다.

일반적인 워크플로우 도구를 사용하면 위협 모델을 작성하고 검토하는 팀 구성원이 비동기적으로 작업할 수 있습니다. 예를 들어, 위협 모델 검토자가 피드백을 추가하면 작성자가 알림을 받고, 전용 회의 시간을 따로 마련하지 않고도 시간이 있을 때 피드백을 처리할 수 있습니다. 또한, 이를 통해 AppSec SME가 참여하고 있는 여러 위협 모델 검토 작업을 보다 효과적으로 수행할 수 있습니다. 앞서 설명한 일관된 접근 방식과 언어는 이 비동기 프로세스를 실행 가능하게 만드는 중요한 전제 조건입니다.

5. 작게 나눠서 진행하기

워크로드를 기능 단위로 분해하고 기능 수준에서 위협 모델링을 수행하는 것이 좋습니다. 전체 워크로드에 대한 단일 위협 모델을 만드는 것보다 이 접근 방식이 여러 가지 주요 이점을 제공합니다:

• 더 작은 작업 단위로 나누면 진행 상황을 더 세밀하게 추적할 수 있어 애자일 방식을 따르는 개발 팀과 잘 맞으며, 지속적인 진행 업데이트가 가능합니다.
• 작게 나누어진 워크로드 별로 더 상세한 위협 모델이 생성되며, 더 많은 위협을 식별할 수 있습니다.
• 동일한 구성 요소를 사용하는 다른 워크로드들에 대한 위협 모델의 재사용성을 높힙니다.
• 각 구성 요소별로 나눠서 위협 완화를 고려함으로써, 전체 워크로드 수준에서 단일 위협에 대해 여러 가지 완화 조치를 가질 수 있습니다. 이는 해당 위협에 대한 복원력을 향상 시킵니다.
• 작게 나눠진 위협에 대한 대응이 아직 완료되지 않았더라도, 그 영향이 크지 않다고 판단되면 전체 애플리케이션이나 시스템의 릴리스를 중단하지 않고도 우선순위에 따라서 개별 대응할 수 있습니다.

AWS 서비스를 사용하는 경우의 컨텍스트 수집을 예로 들어 보겠습니다.

• 하나의 자산. 예를 들어 자격 증명, 고객 정보 등
• 하나의 진입점. 예를 들어, Amazon API Gateway REST API 배포.
• 두 개의 구성 요소. 예를 들어, 웹 브라우저와 API Gateway REST API, 또는 API Gateway와 AWS Lambda 함수.

이 예에서, AWS 관리형 서비스에 대한 위협 모델링을 고객이 직접 수행하는 것은 바람직하지 않습니다. 이는 고객이 AWS 서비스에서 사용되는 모든 컨텍스트를 완전히 수집 할 수 없기 때문입니다. 또한 AWS는 이미 각 서비스의 위협 모델링을 수행하고 제품을 출시하므로, 고객은 이러한 관리형 서비스에 대해서 위협 모델링을 다시 할 필요가 없습니다. 대신, 고객은 식별된 위협을 완화할 때 다양한 AWS 서비스 구성 옵션과 워크로드별 완화 조치를 고려해야 합니다.

AWS의 공동 책임 모델에 따르면, AWS는 인프라의 보안을 책임지고, 고객은 자신의 데이터와 애플리케이션 보안을 책임집니다. 따라서, 고객은 AWS가 제공하는 보안 제어와 함께 자신의 워크로드에 적합한 보안 조치를 통합해야 합니다. 아래의 “완화 조치 식별 및 평가” 섹션에서 기본 보안 통제 개념에 대해 좀더 알아 보겠습니다.

6. 위협 모델링의 소유권 (책임과 권한의 배분)

위협 모델 생성을 담당하는 중앙 담당자나 전담 부서를 두는 것은 장기적으로는 효과적이지 않습니다. 이러한 중앙 조직은 병목 현상이 발생하기 쉬우며, 이를 해결하기 위해서는 인원의 추가를 통한 확장을 수행 하여야 합니다. 또한, 중앙 집중화된 보안 전담조직에 위협 모델링의 소유권이 있는 경우, 실제로 워크로드 기능을 설계하고 구현하는 사람들에게 보안 권한과 책임을 부여하기가 쉽지 않습니다.

대신, 각 워크로드 기능을 설계하고 구현하는 팀에 위협 모델 생성에 대한 소유권을 분산하는 것이, 효과적인 위협 모델링과 보안 문화 확산에 더욱 효과적입니다. 이러한 분산된 소유권은 확장성을 높이고 행동 변화를 유도합니다. 애플리케이션 팀이 제어권을 갖고 주도적으로 보안 위협을 관리하게 되며, 이를 통해 위협 모델링 프로세스에서 얻은 보안 학습을 다음 기능 릴리스에 적용하여 워크로드 및 기능의 보안을 지속적으로 개선할 수 있습니다.이 접근 방식은 팀이 보안에 대한 책임감을 느끼고, 보안 위협을 능동적으로 식별하고 완화하는 데 기여하게 합니다. 결과적으로, 조직 전체의 보안 태세가 강화되고, 보안이 조직 문화의 핵심 요소로 자리 잡게 됩니다.

더불어서 AppSec SME 역할을 수행하는 담당자는, 회사의 다양한 애플리케이션 팀에 대한 중재자 및 보안 자문 역할을 효과적으로 수행할 수 있는 기회를 창출할 수 있습니다. AppSec SME는 위협 모델링의 일관성을 유지하고, 보안 완화 조치를 채택하고, 보안 관련 커뮤니케이션을 주도하면서 회사 전체의 보안 문화를 향상하는데 기여할 수 있게 됩니다.

7. 노출 지점, 공격 진입점 식별

고객의 애플리케이션/시스템이 AWS 서비스를 사용하면서, 위협 모델링의 대상으로 포함되기도 합니다. 이때, AWS 서비스의 유형과 고객의 워크로드의 기능 구현 방식에 따라서 노출지점 즉, 공격 진입점이 달라 질 수 있다는 사실을 이해하는 것이 중요 합니다.

예를 들어, Amazon Simple Storage Service(Amazon S3)의 경우, S3 버킷에 대한 유효한 진입점 유형은 Amazon S3 API를 통해 노출되는 것으로 제한되며, 고객이 ‘추가적인’ 진입점 유형을 생성할 수 있는 기능은 제공되지 않습니다. 하지만 고객은 S3 서비스 자체가 제공하는 기존 기능에 대한 진입 유형을 어떻게 노출할지는 결정할 수 있습니다. 예를 들어, 버킷을 비공개로 할지, 공개적으로 읽기를 허용할 지, 외부에서 업로드가 가능하도록 할 지 등의 여부를 결정할 수 있습니다.

반면, Amazon Elastic Compute Cloud(Amazon EC2)는 고객이 EC2 인스턴스에 대한 추가적인 진입점 유형(예: 애플리케이션 API)을 생성할 수 있도록 허용합니다. 이는 Amazon EC2 API와 EC2 인스턴스에서 실행되는 운영 체제에 기본적으로 제공되는 진입점 유형(예: SSH 또는 RDP) 외에도 가능합니다. 따라서 AWS 서비스의 기본 진입점 외에도, 워크로드 기능에 특화된 진입점을 위협 모델의 일부로 적용해야 합니다.

8. 위협 식별

위협 식별 단계에서의 목표는 “무엇이 잘못될 수 있는가?”라는 질문에 대한 답을 찾는 것입니다. 모든 가능한 위협을 나열하는 완벽한 위협 식별 목록은 존재하지 않습니다. 위협을 파악하고 결정하는 것은 평가 중인 워크로드의 기능, 산업적 특성, 지리적 특성, 정치적인 환경등과 같이 다양한 맥락에서 고려되어야 하며, 이는 고유한 위협 유형들이 다양하게 나타날 수 있음을 뜻합니다.

따라서 유효한 위협을 파악하려면 적극적인 브레인스토밍을 통해서 다양한 접근을 하는 것이 필요합니다. 브레인스토밍 과정에서 STRIDE (Spoofing-스푸핑, Tampering-변조, Repudiation-부인, Information Disclosure-정보 노출, Denial of Service-서비스 거부, and Elevation of Privilege-권한 상승)와 같은 니모닉을 사용하거나 OWASP Top 10 또는 HiTrust 위협 카탈로그와 같은 위협 목록을 살펴봄으로써 아이디어의 흐름을 촉진할 수 있습니다.

이 과정에서 조직에 적합한 위협 카탈로그를 개발하고 지속적으로 업데이트하는 것이 중요합니다. 위협 카탈로그는 조직이 직면할 수 있는 다양한 위협을 체계적으로 정리한 문서로, 이를 통해 위협 식별과 분석이 보다 효율적으로 이루어질 수 있습니다. 또한, 위협 카탈로그는 팀 간의 공통된 이해를 촉진하고, 표준화를 통해서 차후의 브레인스토밍 과정을 가속화할 수 있으며, 모델링하는 위협의 세분화에 일관성을 가져오는데도 도움이 됩니다.

9. 완화 조치 식별 및 평가

여기서 목표는 워크로드 설계 내에서 완화 조치(보안 통제)를 식별하고 위협이 적절하게 해결되었는지 평가하는 것입니다. 일반적으로 여러 계층의 통제와 여러 책임이 작용한다는 점을 염두에 두어야 합니다.

자체 애플리케이션과 코드의 경우, 설계에 포함된 완화 조치—예를 들어 입력 검증, 인증, 세션 처리, 경계 처리 등을 검토해야 합니다. 워크로드의 다른 모든 구성 요소(예: 서비스형 소프트웨어(SaaS), COTS 애플리케이션을 지원하는 인프라, 온프레미스 데이터 센터에 호스팅된 구성 요소)를 고려하고, 워크로드 설계의 일부인 보안 통제를 결정해야 합니다.

AWS 서비스를 사용할 때 보안 및 컴플라이언스는 AWS와 고객 간의 공동 책임 영역입니다. 이는 AWS 공동 책임 모델 페이지에 설명되어 있습니다. 이는 사용 중인 AWS 서비스의 일부가 AWS의 책임(클라우드의 보안)인 경우, 보안 통제는 AWS에서 관리하며, 위협 식별 및 완화도 거기에 포함된다는 의미입니다. AWS(클라우드의 보안)와 고객(클라우드 내 보안) 간의 책임 분배는 사용 중인 AWS 서비스에 따라 다릅니다. 아래에서 인프라, 컨테이너, 추상화된 AWS 서비스의 예를 통해 위협 식별 및 완화에 대한 고객의 책임이 어떻게 달라질 수 있는지 비교해 보았습니다:

• Amazon EC2: 인프라 서비스의 좋은 예시입니다. 고객은 클라우드에서 가상 서버를 생성하고, 운영 체제를 선택하고, 그 위에서 실행되는 서비스들에 대한 모든 부분을 제어할 수 있습니다. 따라서 식별된 위협을 완화하는 책임이 고객에게 있습니다.
• Amazon Relational Database Service (Amazon RDS): 컨테이너 서비스의 대표적인 예로, 운영 체제가 노출되지 않고 AWS가 선택한 데이터베이스 엔진(예: MySQL)을 제공합니다. 이 경우 운영 체제의 보안은 AWS의 책임이며, 고객은 여기에 대해서 완화 조치를 고려하고 구현할 필요가 없습니다. 그러나 데이터베이스 엔진과 그 위의 모든 영역은 고객의 통제하에 있으므로 이러한 영역에 대한 완화 조치를 고려해야 합니다. 여기서 AWS는 인프라 서비스에 비해 더 많은 책임을 집니다.
• Amazon S3, AWS Key Management Service (AWS KMS), Amazon DynamoDB: 추상화된 서비스의 예로, AWS가 서비스 API를 통해 전체 서비스에 대한 컨트롤 플레인과 데이터 플레인의 접근을 제공합니다. 여기서 운영 체제, 데이터베이스 엔진 또는 플랫폼은 노출되지 않으며, 이는 AWS의 책임입니다. 그러나 여전히 API 작업과 관련된 정책은 고객의 통제하에 있으며, API 수준 이상의 모든 영역에 대한 완화 조치는 고객이 고려해야 합니다. 이 유형의 서비스에서는 AWS가 컨테이너 및 인프라 서비스에 비해 더 많은 책임을 집니다.

이 예들은 워크로드에 포함될 수 있는 모든 유형의 AWS 서비스를 포괄하지는 않지만, 공동 책임 모델에 따른 보안 및 컴플라이언스 책임이 이 맥락에서 어떻게 달라질 수 있는지를 보여줍니다. 워크로드에 포함된 AWS 서비스 유형에 대한 AWS와 고객 간의 책임 균형을 이해하면, 위협 모델링의 범위를 고객이 제어할 수 있는 완화 조치로 한정할 수 있습니다. 이는 일반적으로 AWS 서비스 구성 옵션에 대한 조정 및 고객의 자체 워크로드에 특화 보안 완화 조치를 조합하는 방식으로 구현됩니다.

AWS의 책임 부분에 대해서 좀 더 언급하자면, AWS의 서비스들은 여러 국가의 다양한 컴플라이언스 프로그램을 충족하고 있습니다. 이는 AWS Artifact에서 AWS 고객이 각 컴플라이언스별 감사 보고서를 다운로드 받아 봄으로써 확인할 수 있습니다.

어떤 AWS 서비스를 사용하든 고객의 책임 요소는 항상 존재하며, 이는 워크로드 위협 모델에 포함되어야 합니다. 특히 AWS 서비스 자체에 대한 보안 통제 완화 조치의 경우, 다음과 같은 도메인 전반에 걸쳐 보안 통제를 고려해야 합니다:

• ID 및 접근 관리(인증/권한 부여)
• 데이터 보호(저장 중 보안, 전송 중 보안)
• 인프라 보안
• 로깅 및 모니터링
• 보안 이슈 대응

각 AWS 서비스는 공개된 문서에 해당되는 보안 섹션을 포함하고 있으며, 완화 조치로 적용하거나 고려하여야 할 보안 통제에 대한 지침을 제공하고 있습니다. 위협 모델링을 수행하면서, 워크로드별로 보안 제어 및 완화 조치를 기록 할때는 워크로드에 포함되는 실제 코드, 적용된 IAM 정책, AWS CloudFormation 템플릿 등에 대한 참조링크를 반드시 포함하는 것이 좋습니다. 이렇게 하면 위협 모델의 검토자나 승인자가 의도한 완화 조치를 명확하게 파악하는 데 도움이 됩니다.

위협 식별의 경우와 마찬가지로, 모든 가능한 보안 통제를 나열하는 만능 목록은 없습니다. 여기서 설명한 과정을 통해 조직의 통제 목표에 맞는 기본 보안 통제를 자체적으로 개발하고, 가능한 경우 이러한 기본 보안 통제를, 플랫폼 수준 통제로 발전시켜서 구현해 가는 것이 좋습니다. 여기에는 AWS 서비스 수준 구성(예: 데이터 저장간 암호화) 또는 가드레일(예: 서비스 제어 정책을 통한) 등이 포함됩니다. 이를 통해 일관성과 확장성을 확보할 수 있으며, 설계 및 배포하는 다른 워크로드 기능에 대해 이러한 구현된 기본 보안 통제가 자동으로 상속되고 적용됩니다.

기본 보안 통제를 설정할 때는 특정 워크로드 기능의 컨텍스트를 알 수 없다는 점에 유의해야 합니다. 따라서 기본 보안 통제는 조정이 가능한 베이스 라인으로 간주하는 것이 좋습니다. 만약 특정 워크로드에 대한 위협 모델링을 수행할 때 이러한 기본 통제에 포함 시킨 위협이 발견되지 않거나, 이미 다른 완화 조치나 보완 통제가 위협을 적절히 완화하는 경우 베이스라인에서 벗어날 수 있도록 할 조정할 수 있습니다. 기본 보안 통제를 전체 클라우드 보안 거버넌스의 일부로 고려하는 방법에 대해 더 알고 싶다면, “클라우드 보안 거버넌스에 대한 고려 사항들“이라는 블로그 게시물을 참조 할 수 있습니다.

10. 위협 모델링의 완성 시점

이 질문에는 완벽한 답이 없습니다. 위협 모델링을 수행하는 과정에서는 현실성 있는 위험에 기반하여 접근하는 것이 중요합니다. 이는 위험의 발생 가능성과 영향을 적절히 고려하여 균형 잡힌 접근 방식을 만드는 데 도움이 됩니다. “빨리 만들고 출시하자”는 접근 방식에 너무 치우치면 나중에 상당한 비용과 지연이 발생할 수 있습니다. 반대로 “모든 위협을 완화하자”는 접근 방식에 너무 치우치면 워크로드 기능의 출시가 늦어지거나 아예 출시되지 못할 수도 있으며, 고객이 떠날 수도 있습니다. 이전에 “적절한 팀 구성” 섹션에서 언급한 것처럼, 관점과 역할의 선택은 기능 출시와 위협 완화 간의 자연스러운 긴장을 유지하기 위해 신중하게 고려되고 정해졌습니다. 이러한 건강한 긴장을 유지하면서 위협모델링을 수행해 나가야 합니다.

11. 일단 시작해 보기

앞서 “작게 나눠서 진행하기” 섹션에서 위협 모델을 워크로드 기능으로 범위를 좁혀야 한다고 권장했습니다. “이미 <X개>의 기능을 출시했는데 어떻게 위협 모델링을 수행하여야 합니까? 다시 수행해야 하나요?” 라고 질문할 수 있습니다. 이 경우에는, 이미 출시된 기능을 다시 위협 모델링하기보다는 지금 작업 중인 새로운 기능을 위협 모델링하고 다음에 출시하는 코드와 그 이후에 출시하는 각 기능의 보안 속성을 개선하는 것을 목표로 삼는 것이 좋습니다. 이 과정에서 팀원들과 조직은 위협 모델링뿐만 아니라 서로 효과적으로 소통하는 방법도 배우게 됩니다. 조정하고, 반복하고, 개선하는 과정을 통해 고품질의 일관되고 재사용 가능한 위협 모델을 제공할 수 있게 되면, 기존 기능에 대한 위협 모델링을 백로그에 추가할 수 있습니다.

결론

위협 모델링은 애플리케이션 및 시스템의 초기 설계 단계에서 위협을 식별하고 완화하여, 이후 발생할 수 있는 비용을 줄이는 효과적인 투자로 고려되어야 합니다. 또한 지속적으로 위협 모델링을 수행하면 시간이 지남에 따라 조직 전체의 보안 태세가 함께 개선될 가능성도 높습니다. 본 블로그에서 공유하는 팁들은 위협 모델링을 조직에 통합하는 실용적인 방법에 관한 것입니다. 여기에는 커뮤니케이션, 협업, 그리고 고객이 예상하는 위협을 찾아 해결하기 위한 인적 전문성에 중점을 두고 있습니다. 이러한 팁을 바탕으로 현재 작업 중이거나 백로그에 있는 워크로드 기능을 검토하고, 어떤 기능을 우선적으로 위협 모델링할지 결정하는 것이 좋습니다.

본 블로그 게시물의 연장선으로, AWS Summit Online Australia and New Zealand 2021에서 녹화된 “How to approach threat modelling” 세션을 시청하는 것도 도움이 될 것입니다.

직접 실습해 보고 싶다면, AWS에서 제공하는 “Threat modeling the right way for builders” 워크숍 교육을 추천합니다. 이 초급 워크숍은 위협 모델링의 배경과 필요성, 시스템 모델링, 위협 식별, 완화 조치 선택을 위한 도구와 기법을 소개합니다. 워크숍은 시스템 모델과 해당 위협 모델을 생성하는 과정을 안내하며, 각 연습에는 단계별 지침이 제공되어 워크숍을 진행하면서 참가자 워크북을 사용할 수 있습니다. 워크숍 전반에 걸쳐 AWS가 위협 모델링을 어떻게 생각하는지, 보안 문화와 보안 인력을 확장하는 방법에 대한 통찰을 제공합니다.