이 게시물은 시몬 커지, 앤서니 네비코, 조나단 데이비스, 라파엘 파조스 로드리게스, 벤 핸슨에 의해 작성되었습니다
소개
위협 모델링은 애플리케이션 또는 시스템에 대한 가장 중요한 위험 완화를 식별하고 우선 순위를 지정하는 데 도움이 되는 중요한 보안 방법입니다. 이 문서에서는 위협 모델링을 보다 효과적이고 효율적으로 채택하고, 최신 DevOps 방법론 및 도구와 통합하고, 소프트웨어 개발 수명 주기와 관련된 모든 다양한 행위자에게 제공되는 가치에 초점을 맞추는 방법에 대한 몇 가지 리플렉션을 포함합니다.
이 논문이 당신을 위한 것입니까?
이 문서는 Microsoft의 소규모 보안 및 위협 모델링 전문가 팀의 작업 결과이며 Microsoft 외부에서 가장 저명한 전문가의 의견과 아이디어를 통합합니다. 간단하지만 긴급한 질문을 해결하려고 합니다. 가장 낮은 비용으로 필요한 값을 제공할 수 있도록 사용하는 위협 모델링 프로세스가 Agile 방법론 및 DevOps에 의해 부과된 최신 요구 사항으로 업데이트되도록 하려면 어떻게 해야 하나요?
제품 소유자, 보안 팀의 구성원 또는 개발 수명 주기의 일부로 위협 모델링을 채택하려는 개발자인 경우 이 문서를 참조하세요.
마찬가지로, 위협 모델링을 이미 채택한 경우에도 프로세스를 개선하기 위한 실질적인 아이디어를 찾을 수 있습니다.
그럼에도 불구하고 이 문서는 현재 프로세스를 개선하거나 DevOps 프로세스의 일부로 위협 모델링을 성공적으로 채택하기 위한 아이디어를 도입하도록 설계되었습니다. 특정 도구나 제품을 도입하지는 않지만, 미래에 이러한 아이디어가 어떤 도구나 제품에 의해 구현되기를 바랍니다. 따라서 새 도구의 공지 사항 또는 예정된 기능의 미리 보기는 여기에서 찾을 수 없습니다.
위협 모델링이 중요한 이유는 무엇인가요?
위협 모델링은 소프트웨어 솔루션을 안전하게 디자인하는 주요 방법 중 하나입니다. 위협 모델링을 통해 시스템을 분석하여 공격 벡터를 식별하고 해당 공격으로 인한 위험을 완화하기 위한 작업을 개발합니다. 적절하게 수행되는 위협 모델링은 모든 위험 관리 프로세스의 훌륭한 구성 요소입니다. 디자인 문제를 조기에 식별하고 수정하여 비용을 절감할 수도 있습니다. NIST의 오래된 연구에 따르면 프로덕션 코드에서 디자인 문제를 해결하는 데 드는 비용은 디자인 단계에서 복구하는 것보다 약 40배 더 높을 것으로 예상했습니다. 또한 최종 설계 문제에 대한 보안 인시던트로 인한 비용 발생을 줄일 수 있습니다. IBM 보안 및 Ponemon Institute의 2022 데이터 위반 비용 보고서는 데이터 위반의 평균 비용을 $4.35M로 추정합니다. 5천만 개 이상의 레코드를 손상시키는 소위 메가 위반의 경우 평균 비용은 $ 387M에 도달합니다!
위협 모델링은 솔루션 디자인에서 작동하기 때문에 솔루션을 보호하기 위해 수행할 수 있는 첫 번째 작업입니다. 이 특성을 사용하면 SDLC에 적용할 수 있는 가장 효과적인 보안 사례가 됩니다.
Microsoft는 위협 모델링을 통해 오랜 역사를 가지고 있습니다. 1999년, 두 명의 (당시) Microsoft 직원인 로렌 콘펠더와 Praerit Garg는 우리 제품에 대한 위협이라는 문서를 작성했습니다. 이 문서에서는 Microsoft 위협 모델링 프로세스의 동의어인 STRIDE 접근 방식을 소개했습니다.
위협 모델링은 진화적 프로세스입니다.
위협 모델링은 정적 프로세스가 아닙니다. 요구 사항과 기술이 변화함에 따라 진화합니다.
SolarWinds를 대상으로 하는 최근 공격과 같은 공급망 공격은 개발 및 배포를 포함하여 솔루션 자체보다 더 많은 시나리오를 위협 모델링으로 처리해야 한다는 것을 보여줍니다.
Log4j에 대한 최근 취약성과 같은 오픈 소스 취약성은 노출을 제한하기 위해 솔루션을 방어적으로 설계하여 취약한 구성 요소를 검색하는 소프트웨어 컴퍼지션 분석 도구의 채택에 따라 현재의 접근 방식을 보완해야 한다는 것을 입증했습니다.
Machine Learning 같은 새로운 기술을 적용하면 이해하고 제어해야 하는 새로운 공격 벡터가 도입되었습니다. 예를 들어, 인간의 귀에서 들리지 않는 악의적으로 만들어진 소리를 재생하여 AI 서비스에서 명령을 실행할 수 있는 가능성을 고려합니다.
Microsoft에서는 다양한 제품 그룹이 특정 보안 요구 사항에 따라 다양한 변형의 위협 모델링을 수행합니다. 각 변형은 적용되는 시나리오에 대해 적절한 수준의 보안 보증을 보장하는 것을 목표로 하지만, "적절한"은 특정 컨텍스트에 따라 변경 내용을 의미합니다.
예를 들어 Windows 보안은 Azure Cognitive Services의 보안과는 다릅니다. 이러한 시스템은 크기와 특징이 매우 다르기 때문입니다. 위협 모델링의 주요 측면은 애플리케이션에 대한 위험 허용 범위와 비용의 균형을 맞추는 것입니다. 이로 인해 일부 시나리오에서 위협 모델링을 완전히 방지할 수 있지만 제대로 수행되면 매우 효과적이므로 소프트웨어 개발 및 인프라 배포 프로젝트를 비롯한 모든 IT 이니셔티브에만 채택하는 것이 좋습니다.
ROI에 초점을 맞추는 것의 중요성
지난 몇 년 동안 주요 소프트웨어 개발 프로세스로 위협 모델링에 대한 관심이 꾸준히 증가했습니다. 이러한 관심은 인프라 및 솔루션에 대한 공격이 기하급수적으로 증가하기 때문입니다. NIST 권장 최소 표준 공급업체 또는 개발자 코드 검증 및 위협 모델링 선언문과 같은 이니셔티브는 현재 접근 방식이 몇 가지 제한을 보여 주는 시점까지 수요를 더욱 증가시켰다. 예를 들어 위협 모델링의 결과는 채택된 프로세스와 위협 모델을 수행하는 사람에 따라 크게 달라집니다. 따라서 경험에서 지속적으로 더 높은 품질을 얻는 것에 대한 우려가 있습니다.
하지만 품질은 위협 모델링에 어떤 의미가 있을까요? 품질 위협 모델에는 다음과 같은 특성이 있어야 합니다.
이는 실행 가능한 완화, 공격으로 인한 잠재적 손실을 줄이기 위해 수행할 수 있는 활동을 식별해야 합니다. 실행 가능은 이러한 완화를 잘 정의해야 하므로 구현하고 구현을 테스트하기에 충분한 정보를 얻을 수 있음을 의미합니다. 즉, 개발 팀에서 쉽게 사용할 수 있도록 제공해야 합니다. DevOps 및 Agile을 사용하면 완화를 백로그로 쉽게 가져올 수 있습니다.
각 완화에 대해 해당 상태를 식별해야 합니다. 일부 완화는 새로운 반면 다른 완화는 이미 존재합니다. 위협 모델은 이미 있는 것을 인식하고 현재 위험에 집중하여 상황을 개선하는 방법을 식별해야 합니다.
각 완화를 해당 위협에 연결하여 필요한 이유를 명확하게 식별해야 합니다.
또한 완화에는 각 위협에 대한 상대적 강도가 있습니다. 예를 들어 TLS 암호화는 전송 중인 데이터가 공개될 위험에 대한 강력한 완화가 될 수 있으며, 동시에 서버가 스푸핑될 위험이 거의 완전히 완화될 수 있습니다.
위협은 신뢰할 수 있고, 잘 정의되며, 솔루션에 한정되어야 합니다.
위협에는 관련 심각도가 있어야 하며, 이 심각도는 확률과 영향을 모두 고려해야 합니다. 심각도는 합리적이고 이상적으로 편견이 없어야 합니다.
위험 및 해결 방법에 대한 포괄적인 보기를 얻을 수 있어야 합니다. 이 보기는 보안 팀 및 비즈니스 의사 결정자와의 의미 있는 대화를 유도하는 데 중요한 역할을 하며 불필요한 복잡성을 숨길 수 있습니다.
이 목록에는 이미 중요한 개념이 나와 있습니다. 위협 모델링은 소프트웨어 수명 주기 동안 관련된 많은 역할에 가치를 제공할 수 있지만 각 역할에는 요구 사항과 요구 사항이 다릅니다. 예를 들어 개발자는 구현해야 하는 항목과 구현된 항목이 예상대로 작동하는지 확인하는 방법에 대한 명확한 정보를 받아야 합니다. 반면에 보안 팀은 일반적으로 조직이 소유한 인프라 및 애플리케이션 에코시스템의 전반적인 보안과 관련이 있습니다. 따라서 범위 내의 시스템이 충분히 안전하고 규정 준수 요구 사항을 충족하는지 여부를 결정할 수 있는 정보를 받아야 합니다. 마지막으로, 제품 소유자 및 비즈니스 의사 결정자는 조직에 위험을 허용하기 위해 필요한 사항을 이해해야 합니다.
이러한 다양한 요구 사항은 위협 모델에 대해 서로 다른 보기를 제공해야 하며, 각 뷰는 특정 사용 시나리오에 초점을 맞췄습니다.
위협 모델링의 일반적인 문제는 성공이 많을수록 사용 가능한 몇 명의 전문가가 수요를 처리하는 동시에 이 환경에서 예상되는 높은 품질을 제공하기가 더 어렵다는 것입니다. 그 결과, 경우에 따라 품질이 부정적인 영향을 받을 수 있습니다. 위협 모델링이 투자에 비해 상당한 가치를 제공하는 것을 중지할 때까지 모든 것이 좋습니다. 이 문제의 영향을 받는 조직이 여러 개 있습니다. 비즈니스 의사 결정권자가 비용에 상당한 가치를 제공하지 못하기 때문에 위협 모델링에 의문을 제기하기 시작한 몇 가지 보고서가 이미 있습니다.
값으로, 우리는 범위에서 시스템이 나타내는 위험을 이해하고 구현할 적절한 완화를 선택하기 위한 의미 있는 의사 결정 프로세스를 추진하는 데 필요한 정보를 제공하는 기능인 비즈니스 값을 참조합니다. 또한 값은 개발자 및 테스터에게 올바른 정보를 제공하는 방법과도 관련이 있습니다. 마지막으로, 값은 모든 관련 당사자와 잔여 위험을 전달하는 데 관련됩니다. 예를 들어 위협 모델링 프로세스의 영향을 측정하여 값을 측정할 수 있습니다. 각 위협에 식별된 심각도에 숫자를 할당하여 솔루션의 전반적인 위험을 측정한다고 가정합니다. 이 경우 위협 모델의 효과에 따라 시간이 지남에 따라 전반적인 위험이 감소할 것으로 예상합니다. 전반적인 위험이 일정하게 유지되거나 증가하는 경우 문제가 발생할 수 있습니다. 감소가 가파르면 위협 모델의 영향이 높아질 수 있습니다. 물론 위협 모델은 구현된 완화를 제어하지 않습니다. 구현해야 할 사항을 결정하는 것은 제품 소유자의 책임입니다. 그러나 위협 모델의 효과를 완화의 실제 구현과 연결하면 솔루션의 실제 보안에 미치는 영향이 증가하여 위협 모델이 이론적인 연습으로 남아 있는 위험을 줄일 수 있다는 장점이 있습니다.
대신, 비용은 위협 모델 자체를 수행하는 데 필요한 활동과 관련이 있으며, 이는 모든 관련 당사자가 위협 모델을 생성하고 논의하는 데 필요한 시간입니다.
비즈니스 가치를 극대화하고 비용을 최소화하는 데 초점을 맞춘 위협 모델링 프로세스를 정의할 수 있을까요?
DevOps의 중요성
위협 모델링이 DevOps 프로세스와 통합된 귀중한 관행인지 확인하는 것이 얼마나 중요한지 이미 강조했습니다. 즉, 일반적으로 프로세스를 단순화하고 자동화하여 모든 팀 구성원이 프로세스를 사용할 수 있어야 합니다. 가장 중요한 것은 DevOps에 대한 위협 모델링에 중점을 두는 것은 환경이 기존 DevOps 프로세스와 긴밀하게 통합되도록 해야 한다는 것을 의미합니다.
위협 모델링은 또 다른 부담이 되어서는 안 되며, 대신보안 요구 사항 유도 및 수집, 보안 솔루션 디자인, 선택한 작업 및 버그 추적 도구에 활동 포함 및 솔루션의 현재 및 미래 상태를 고려하여 잔여 위험 평가를 용이하게 하는 자산이어야 합니다.
DevOps와의 맞춤
다양한 기술을 사용하여 위협 모델링을 현재 DevOps 사례에 맞출 수 있습니다.
위협 및 완화
먼저 위협 모델링 프로세스에서 수행해야 하는 작업을 집중해야 합니다. 공격 패턴 및 발생할 수 있는 방법인 위협은 팀이 보안 제어를 구현해야 하는 이유를 설명해야 합니다. 또한 완화를 구현해야 하는 시기를 결정하는 요인이기도 합니다. 그러나 실제 목표는 완화를 위해 수행해야 하는 작업을 결정하는 것입니다. 따라서 이 접근 방식은 필요한 완화를 신속하게 식별해야 하며, 수행할 작업과 시기를 보다 쉽게 결정할 수 있도록 의사 결정 프로세스를 알려야 합니다. 이 의사 결정 프로세스의 주요 결과물은 백로그에서 선택한 완화를 표준 프로세스의 일부로 만드는 것입니다. 위협 모델링 도구와 작업 및 버그 추적 도구를 동기화하여 위협 모델의 완화 상태에 대한 업데이트를 반영하는 것이 이상적입니다. 이렇게 하면 잔여 위험을 동적으로 자동으로 수정할 수 있으며, 이는 스프린트 계획 회의와 같이 채택된 Agile 방법론의 일반적인 안무의 일환으로 정보에 입각한 결정을 지원하는 데 중요합니다.
오늘 무엇을 할 수 있습니까?
위협 모델링 전문가는 작업을 명확하게 식별하고 선택한 작업 및 버그 추적에 포함할 수 있는 위협 모델링 프로세스를 구현해야 합니다. 한 가지 방법은 이 프로세스를 자동화할 수 있는 많은 위협 모델링 도구 중 하나를 채택하는 것입니다.
개발자는 필요에 따라 식별되는 보안 컨트롤에 집중해야 합니다. 이 프로세스는 다른 활동을 받을 것으로 예상되는 것과 동일한 방식으로 사용자에게 제공하도록 설계되어야 합니다.
기능, 사용자 스토리 및 작업
완화는 DevOps 통합과 관련된 위협 모델에서 생성되는 가장 중요한 아티팩트임을 이미 설명했습니다. 따라서 선택한 작업 및 버그 추적 도구에서 이러한 완화에서 만든 개체의 형식을 명확하게 정의하는 것이 중요합니다. 일부 완화는 스프린트보다 더 지속될 수 있습니다. 따라서 기능으로 만드는 것이 가장 좋습니다. 하지만 많은 것들이 더 쉬워서 단일 스프린트 내에 구현할 수 있습니다. 따라서 사용자 스토리나 작업으로 나타낼 수 있습니다. 다양한 작업 항목 유형을 생성할 수 있지만 이로 인해 실수와 혼란이 발생할 수 있는 복잡한 프로세스가 발생할 수 있습니다. 이러한 이유로 단일 작업 항목 유형을 고수하는 것이 더 실용적으로 보입니다. 완화가 사용자 스토리의 자식으로 간주될 수 있다는 점을 감안할 때 이를 작업으로 나타내는 것이 좋습니다. 즉, 단일 스프린트에서 해당 작업 항목 유형을 실행해야 하는 요구 사항을 완화할 수 있습니다.
오늘 무엇을 할 수 있습니까?
위협 모델로 식별된 완화 방법이 백로그에 표시되는지 확인합니다. 명확하게 나타내는 방법을 식별합니다.
사용자 사례
완화는 작업 및 버그 추적 도구에 있는 항목과 일치시킬 수 있고 일치해야 하는 위협 모델의 유일한 아티팩트 부분이 아닙니다. 예를 들어 위협을 나타낼 수도 있습니다. 이 목표는 "누구로서 [나 자신], 무엇을 하고 싶은지 [내가 원하는 것], 그 다음에 무엇을 할 수 있게 되는지 [결과]"의 일반적인 형식에 WITHOUT 절을 추가하여 사용자 스토리를 확장함으로써 달성할 수 있습니다. 예를 들어: "사용자로서 신용 카드 정보를 도난당하지 않고도 일부 상품을 구매할 수 있도록 신용 카드로 결제하고 싶습니다." WITHOUT 절은 하나 이상의 위협에 매핑될 수 있으며 경우에 따라 보안 요구 사항을 표현할 수 있습니다. 위협과 WITHOUT 절 간의 이러한 맞춤이 위협 모델 내에서 명시적으로 이루어지도록 함으로써 가능한 위험이 사용자 스토리의 일부로 포함되기 때문에 팀에서 반영하고 처리하도록 할 수 있습니다. 이 관계를 사용하여 사용자 스토리의 일부로 식별된 모든 보안 요구 사항을 적어도 위협에 매핑할 수도 있습니다.
알아 두면 좋습니다.
WITHOUT 절은 이 페이지를 작성한 팀의 원래 개념이 아닙니다. 누가 처음 소개했는지는 확실하지 않지만, 이 아이디어를 제안한 사람에게 감사드립니다.
사용자 스토리 및 WITHOUT 절을 사용하여 위협을 매핑하는 다이어그램입니다.
그림 1: 요구 사항 정렬
예를 들어 이전 그림은 다음과 같은 상황을 보여 줍니다.
위협 A는 WITHOUT 1이라는 조항을 통해 사용자 스토리 1에 연결됩니다.
위협 B는 WITHOUT 2 절을 통해 User Story 2에 연결됩니다.
위협 B는 사용자 스토리 3에도 연결됩니다. 하지만 사용자 스토리 3은 어떠한 WITHOUT 절에도 할당되지 않습니다. 이유는 무엇입니까? 조사해야 하는 잠재적인 변칙을 나타냅니다.
위협 B는 사용자 스토리 1에도 연결됩니다. 둘 이상의 위협에 연결된 사용자 스토리를 허용해야 하는지는 아직 명확하지 않습니다.
위협 C는 WITHOUT 3 및 4와 연결된 사용자 스토리 4에 연결됩니다. 두 개 이상의 WITHOUT 절을 허용해야 하는지는 아직 명확하지 않습니다.
위협 D는 사용자 스토리에 연결되지 않습니다. 사용자 스토리 또는 WITHOUT 절이 누락되었나요?
사용자 스토리 5는 WITHOUT 절에 연결되어 있지만 관련된 위협 요소는 없습니다. 위협 또는 단순히 사용자 스토리와 위협 간의 링크가 누락되었나요?
위협 모델의 일부로 보안 요구 사항을 거의 식별하지 않습니다. 따라서 WITHOUT 절은 위협 모델을 보안 요구 사항으로 확장하고 관련 사용자 스토리와 연결하여 환경을 더욱 통합할 수 있는 기회를 제공합니다. 이 접근 방식은 시간이 지남에 따라 반복되는 평가에서 DevOps의 보안 디자인 도구가 되는 위협 모델링 환경을 발전시키는 데 중요한 역할을 합니다.
오늘 무엇을 할 수 있습니까?
사용자 스토리 내에서 WITHOUT 절 사용을 시작합니다.
사용자가 식별한 위협을 WITHOUT 절을 사용하여 사용자 스토리에 매핑하고 그 반대의 경우도 마찬가지입니다.
통합 환경
다른 시나리오에 동일한 아이디어를 적용할 수 있습니다. 예를 들어 위협 모델은 보안 요구 사항을 위협 모델 자체의 아티팩트(예: 위협 및 완화) 및 추적 및 버그 추적 도구의 아티팩트와 연결할 수 있습니다. 예를 들어 진행 중인 공격을 식별하기 위한 모니터링을 구현하기 위한 요구 사항은 모니터링과 관련된 모든 완화 및 작업 및 버그 추적 도구의 해당 아티팩트로 매핑되어야 합니다. 따라서 보안 요구 사항이 실현되지 않는 상황을 쉽게 식별할 수 있습니다. 실제로는 아무것도 연결되지 않습니다.
작업 및 버그 추적 도구의 아티팩트와 위협 모델에서 식별된 위협 및 완화 간에 동일한 링크를 사용하여 보안 활동의 우선 순위를 지정할 수 있습니다. 보안은 일반적으로 마지막으로 구현되며, 때로는 일부 도구 또는 침투 테스트로 식별되는 사후 취약성을 해결하기 위해 구현됩니다. 반대로 관련 사용자 스토리 또는 기능과 함께 완화를 구현하는 것이 가장 효과적입니다. 관련 결제 기능과 함께 구현해야 하는 경우 신용 카드 세부 정보를 보호하기 위해 컨트롤을 구현하기를 기다리는 이유는 무엇인가요? 위협 모델은 이러한 관계를 강조 표시하고 스프린트 중에 일부 기능을 구현할 때 관련 보안 기능을 구현해야 하는 경우를 결정하는 간단한 방법을 제공해야 합니다. 예를 들어 스프린트 계획 모임 중에 이 정보를 사용하여 의미 있는 토론을 하고 정보에 입각한 우선 순위를 정할 수 있습니다. 메커니즘은 간단합니다. 작업 중인 프로젝트의 제품 소유자가 다음 스프린트에 대한 사용자 스토리를 계획하기로 결정한다고 가정해 보겠습니다. 이 사용자 스토리에는 위협과 연결된 WITHOUT 절이 포함되어 있습니다. 위협 모델은 동일한 위협에 대한 몇 가지 완화를 식별합니다. 따라서 식별된 완화 방법 중 하나 이상의 우선 순위를 지정해야 한다고 즉시 추론할 수 있습니다.
보안 우선 순위를 지정하는 데 위협과 완화 사이의 링크를 사용하는 방법을 보여 주는 다이어그램
그림 2: 보안 우선 순위 지정
예를 들어 위의 그림에서 사용자 스토리 1이 위협 1에 연결되어 있는 것을 볼 수 있습니다. 그러면 완화 A 및 B와 연결됩니다. 따라서 이러한 완화 방법 중 하나 또는 둘 다를 구현하는 것도 고려해야 합니다.
오늘 무엇을 할 수 있습니까?
사용자 스토리를 WITHOUT 절과 함께 위협 모델을 참조로 사용하여 선택한 완화에 해당하는 작업 항목에 연결합니다. 다음 스프린트를 계획할 때 WITHOUT 절을 사용하여 해당 사용자 스토리 중 하나를 구현할 때 연결된 보안 활동의 우선 순위를 지정해야 합니다.
잘못된 정렬을 강조 표시하는 통합
위협 모델을 구성하는 아티팩트가 작업 및 버그 추적 도구의 아티팩트와 연결될 수 있는 방법에 대해 생각하기 시작하면 둘 다의 품질을 향상시킬 수 있는 기회를 쉽게 식별할 수 있습니다. 핵심은 관계를 활용하여 불일치를 강조하고 한 쪽에 있는 정보를 활용하여 다른 쪽에 있는 내용을 보완, 통합 및 해석하는 것입니다. 위에서 설명한 것처럼 팀이 이미 작동하는 방식에 큰 영향을 주지 않고도 이 작업을 수행할 수 있습니다. 이 방법은 기존 정보를 사용하고 다양한 세계의 다양한 개체 간에 관계를 만들기 때문입니다. 따라서 위협 모델은 솔루션의 보안을 위한 진실의 원천이 됩니다. 동시에 백로그는 솔루션의 상태에 지속적으로 맞춰집니다.
오늘 무엇을 할 수 있습니까?
매핑되지 않은 위협이나 사용자 스토리가 특정 조건 없이 존재하지 않는지 정기적으로 확인합니다.
위협 모델링 및 작업
이러한 모든 아이디어는 주로 DevOps의 개발 측면에 초점을 맞추고 있습니다. 작업을 개선하기 위해 어떤 작업을 수행할 수 있나요? 우리는 그렇게 생각합니다. 예를 들어 보안 관점에서 시스템을 포괄적으로 볼 수 있으므로 일부 공격의 의미를 더 잘 이해할 수 있으므로 근본 원인 분석을 용이하게 하는 도구로 위협 모델링을 사용할 수 있습니다. 이를 위해 선택한 모니터링 도구의 기존 피드와 위협 모델을 통합해야 합니다. 이 방법은 선택한 SIEM에 대한 보완을 나타낼 수 있습니다.
위협 모델링을 Operations와 통합하는 또 다른 아이디어는 첫 번째 방법을 사용하여 후자가 발생할 수 있는 방법을 설계하는 것입니다. 그 예는 솔루션에 대한 이벤트의 디자인입니다. 위협 모델링은 가능한 공격을 식별하며, 해당 지식을 사용하여 해당 공격이 실패할 때 범위 내 솔루션이 발생할 수 있는 이벤트를 식별할 수 있습니다. 엄격한 입력 유효성 검사를 수행하는 경우 악의적인 공격자는 성공하기 전에 몇 번의 시도가 필요합니다. 처음에는 시도가 실패하고 그 중 하나가 결국 성공합니다. 각 실패에 대한 이벤트를 발생시키고 일부 임계값에 도달하면 경고를 트리거하면 공격을 감지하고 조치를 취하여 수정할 수 있습니다. 인프라 모니터링을 제한하는 경우 이러한 상황은 거의 감지되지 않습니다. 따라서 SOC가 이를 활용하기 전에 팀이 디자인하고 구현해야 하는 사용자 지정 이벤트를 포함해야 합니다.
또한 후자는 솔루션에 대해 많이 알지 못할 수 있습니다. 따라서 SOC는 입력 유효성 검사에 실패할 때 대응하는 방법을 결정하지 못할 수 있습니다. 아쉽게도 데이터 위반이 발생하면 직접적인 손상과 최종 벌금의 확률 및 엔터티를 줄이기 위해 신속하게 대응해야 합니다.
따라서 모니터링해야 하는 사항, 문제가 있을 수 있는 조건 및 이러한 상황이 발생할 때 수행할 작업을 미리 계획해야 합니다. 이러한 이벤트를 식별하는 가장 좋은 방법은 위협 모델을 사용하는 것입니다. 따라서 모니터링 및 감사를 구동하고 인시던트 대응을 용이하게 하는 데 필요한 구성의 구현을 안내하고 가속화하기 위해 표준화된 아티팩트 생성에 활용하면 도움이 됩니다.
오늘 무엇을 할 수 있습니까?
위협 모델을 적극적으로 사용하여 각 위협에 대해 발생할 수 있는 이벤트를 식별합니다. 이러한 이벤트는 인프라 또는 애플리케이션에서 발생해야 하는 항목을 통해 제공될 수 있습니다. 해당 이벤트가 구현되도록 백로그에 작업 항목을 포함합니다.
SOC 팀을 비롯한 운영 및 보안 팀과 적극적으로 협력하여 이벤트를 활용하여 경고를 발생시키고 보안 인시던트 식별을 보장합니다.
ROI에 미치는 영향
이러한 기술이 위협 모델링의 ROI에 긍정적인 영향을 미칠 수 있는 이유가 궁금할 수 있습니다. 우리의 관점에서 볼 때 DevOps 팀의 위협 모델링 가치를 높이는 데 매우 중요합니다. 우리가 반복적으로 보았던 문제는 해당 팀이 보안을 제한된 가치를 제공하고 예기치 않은 작업이 많이 필요한 비용으로 인식한다는 것입니다. 때로는 보안을 고정하는 데 왜 그렇게 많은 시간을 투자해야 하는지 불분명합니다. 결과적으로 보안은 기회가 아닌 문제가 됩니다. 위협 모델링은 보안을 구현하는 이유를 제공하기 때문에 이러한 문제를 극복할 가능성이 있습니다. 또한 개발 프로세스 초기에 시작할 수 있으며, 조기에 발견되지 않으면 큰 비용이 발생할 수 있는 디자인 실수를 방지할 수 있습니다. 위의 기술은 DevOps와 위협 모델링을 더 잘 통합하는 것을 목표로 합니다. 이를 통해 비즈니스 의사 결정자와 개발자는 위협 모델링을 개발 및 운영 프로세스에 대한 자연스러운 보완으로 인식할 수 있습니다. 따라서 위협 모델링을 채택하여 받은 값이 증가하고 이미 사용 중인 다양한 도구와의 통합으로 인해 비용이 절감됩니다.
위협 모델러에 대한 작업 간소화
위협 모델링의 ROI를 개선하는 데 필요한 또 다른 중요한 측면은 비용을 절감하고 보다 동질적인 품질 수준을 유지하면서 배달할 수 있는 사람들의 수를 늘리는 것입니다.
유능한 사람들의 부족을 해결하기 위해 많은 시도가 있습니다. 그 중 일부는 위협 모델링 연습에서 전체 DevOps 팀의 적극적인 참여를 기반으로 합니다. 이 아이디어는 이니셔티브의 리더를 식별하는 것입니다, 즉 프로세스에 대한 중간 지식을 가진 사람이지만 반드시 전문가는 아니며, 다른 팀 구성원들 사이에서 토론을 이끌도록하는 것입니다. 이 방법은 위협 모델링 선언문의 서명자가 적극적으로 승인합니다.
우리는이 접근 방식이 좋은 가치를 얻을 수 있으며 현재 상황에 대한 개선을 나타낸다는 데 동의합니다. 또한 좋은 인사이트를 제공하고 팀이 보안 문화를 확장할 수 있도록 합니다. 그럼에도 불구하고, 그것은 단지 몇 가지 문제만 다루기 때문에 단점이 있다, 많은 문제를 빠뜨리고 있다. 이렇게 하면 토끼 구멍을 뚫고 중요한 문제를 누락하여 보조 문제에 귀중한 시간을 낭비하기가 너무 쉽기 때문에 일관성 문제가 발생합니다. 리더의 경험은 이러한 상황이 발생하지 않도록 방지하는 데 중요한 역할을 할 것입니다. 또한 이 방법을 사용하려면 모든 팀 구성원이 각 문제를 논의하는 데 많은 시간이 필요합니다.
이러한 이유로, 이 연습을 위해 스프린트당 몇 시간을 보내는 것조차도 상당한 투자를 나타낼 수 있습니다. 대부분의 팀은 모든 사람이 참여하는 대규모 모임에서 시간을 낭비하는 경향이 있다는 것을 모두가 알고 있으며, 이러한 위협 모델링 세션은 예외를 만들지 않을 것입니다. 그럼에도 불구하고 이 접근 방식은 팀이 소수의 고위 위원으로 구성된 소규모 제품에 적합합니다.
다른 접근 방식
이전 방법의 제한 사항을 고려할 때 모임 수, 모임 길이 및 참가자 수를 제한하는 것이 좋습니다. 따라서 위협 모델러의 책임은 인터뷰를 이끌 뿐만 아니라 위협 모델 자체를 만들고 유지하는 데 더 중요합니다. 이 접근 방식에는 더 중요한 역량과 전문 지식이 필요합니다. 위협 모델러는 Security Champions 또는 내부 보안 팀의 구성원이 나타낼 수 있습니다. 대부분의 조직은 보안 팀이 일반적으로 일정이 꽉 차 있기 때문에 첫 번째를 선택합니다.
보안 챔피언은 보안에 특히 관심이 있는 DevOps 팀의 구성원입니다. 그들은 어떤 수단으로든 전문가가 아니지만 기본적인 지식과 팀의 보안 태세를 개선하려는 의지를 가지고 있습니다. 보안 챔피언들이 그들의 팀이 옳은 일을 하도록 지원할 수 있게 강화하고, 보안 팀의 업무 부담을 경감하기 위해 보안 챔피언과 내부 보안 팀 간에 특권이 있는 연결을 만드는 것입니다. 위협 모델링을 사용하면 Security Champions가 위협 모델러 역할을 하게 되며, 내부 보안 팀은 이를 안내하고 작업을 검토할 책임이 있습니다.
오늘 무엇을 할 수 있습니까?
Security Champions 프로그램을 채택하고 이를 활용하여 보안 소프트웨어 개발 수명 주기를 더욱 강화할 수 있는 가능성을 조사합니다.
지식 기반의 역할
위협 모델링의 중요한 문제는 위협 모델을 수행하는 사용자에 관계없이 DevOps 팀의 환경 품질과 가치를 높이도록 하는 것입니다. 보안 챔피언을 사용하면 이 문제가 더욱 시급해집니다. 이 문제를 해결하는 방법은 위협 모델 생성을 구동하는 기술 자료 제공하는 것입니다. 위협 모델링에 대한 기술 자료는 특정 컨텍스트에 대한 정보 패키지입니다. 여기에는 해당 컨텍스트와 관련된 엔터티 정의, 해당 엔터티에 대한 가능한 공격 패턴 및 적용할 수 있는 표준 완화가 포함됩니다. 기술 자료를 통해 조직은 위협 모델러를 규범적인 방식으로 안내하는 참조 자료를 나타내므로 더 나은 결과를 얻을 수 있습니다. 기술 자료에는 시스템에 위협 및 완화를 자동으로 적용할 수 있는 규칙이 있어야 합니다. 이 자동화를 사용하면 일부 위협 모델러가 위협을 적용해야 하는지 또는 일부 완화가 효과적인지 확인하는 데 필요한 환경이 없을 수 있다는 사실을 극복할 수 있습니다.
기술 자료는 새로운 개념이 아닙니다. 많은 현재 위협 모델링 도구는 이미 어떤 형태로든 지원합니다. 그러나 많은 현재 구현에는 상당한 단점이 있습니다. 예를 들어 기술 자료 쉽게 유지할 수 있어야 합니다. 유지 관리 효율성은 아직 해결되지 않은 문제입니다. 예를 들어 빌드에 사용할 가장 적합한 정보 원본을 식별하는 것은 쉽지 않습니다. 또한 유지 관리는 일반적으로 수동입니다. 기술 자료 생성 및 유지 관리는 조직의 내부 보안 팀의 책임이어야 합니다. 우리는 기업이 미래에 고객의 부담의 일부를 해제하기 위해 가장 일반적인 위협 모델링 도구에 대한 기술 자료 제공하기 시작하기를 바랍니다. 이러한 기술 자료 가장 성숙한 조직에서도 채택을 지원하고 용이하게 할 수 있어야 하며, 이러한 기술 자료 관행, 정책 및 규정에 맞게 조정해야 합니다.
오늘 무엇을 할 수 있습니까?
다양한 개발 팀에서 위협 모델링을 가속화하는 데 사용할 수 있는 기술 자료 개발하기 위해 중앙 집중식 보안 팀의 노력의 일부를 고려할 수 있습니다.
지식 베이스 활용
지식 베이스의 또 다른 문제는 때때로 이해하기에 너무 복잡하다는 것입니다. 그들 중 많은 사람들이 필수적이고 덜 중요한 문제를 포함하여 포괄적이려고 노력합니다. 아쉽게도 모든 시스템에서 필요한 것은 아닙니다. 분석하는 시스템이 작고 중요한 데이터를 처리하지 않는 경우 더 간단한 방법을 채택하려고 합니다. 반대로 시스템이 복잡하고 PII 및 높은 비즈니스 가치 데이터를 처리하는 경우 좀 더 심층적인 작업을 수행해야 합니다. 따라서 컨텍스트에 따라 다양한 버전의 지식을 적용하거나 일부 공격 패턴 및 관련 완화를 "TOP"으로 표시할 수 있습니다. 결과적으로 위협 모델러는 포괄적인 환경을 원하는지 또는 쉽게 작업하고 필요한 작업을 최소화할지 결정할 수 있습니다.
효율성에 대해 말하자면 필요한 작업량을 줄이기 위해 활동을 최대한 간소화하고 자동화해야 합니다. 평균 크기 솔루션의 위협 모델을 수행하는 가장 좋은 지점은 위협 모델러에 대한 1일의 작업이어야 한다고 생각합니다. 이러한 결과는 선택한 도구가 필요한 시간을 줄일 수 있도록 가속기를 제공하는 경우에만 가능합니다. 예를 들어 도구가 100개의 다른 위치에 20가지 유형의 완화를 적용하고 각 항목에 대해 해당 상태를 지정하도록 요청하는 경우 후자 대신 첫 번째 완화에 집중하여 5배 더 효율적입니다. 필요한 경우 더 철저한 작업을 수행할 수 있는 가능성을 부여하면서 선택한 도구는 이 기능을 제공해야 합니다.
오늘 무엇을 할 수 있습니까?
현재 사용하는 기술 자료 "TOP" 위협 및 완화 개념을 지원하지 않는 경우 거의 필요하지 않거나 유용한 항목을 제거하여 실제로 중요한 것에만 집중할 수 있도록 하는 것이 좋습니다.
경우에 따라 채택된 기술 자료 일반적이고 여러 시나리오를 다루려고 하는 것이 문제입니다. 특수화하여 상황을 개선할 수 있습니다.
올바른 질문하기
분석 중에는 분석의 첫 번째 단계를 진행하기 위해 질문 프레임워크를 지원하기 위해 도구를 사용할 수 있는 가능성을 고려했습니다. 대부분의 경험이 부족한 위협 모델러는 분석에 필요한 정보를 얻기 위해 올바른 질문을 할 수 없습니다. 일부 전문가는 범위의 시스템 다이어그램을 기반으로 몇 가지 중요한 질문을 결정할 수 있음을 입증했습니다. 이러한 질문은 일부 세대 규칙과 함께 자동으로 적용할 수도 있습니다. 문제는 이 방법이 약속하는 것처럼 보이는 가치를 제공하지 못할 수 있다는 것입니다. 이는 각 질문의 근거를 이해해야 하기 때문입니다. 그렇지 않으면 답변을 평가하고 만족스러운지 확인할 수 없습니다. 그러나 자동화된 질문 생성은 덜 전문적인 위협 모델러에게 상당한 가치를 제공하여 범위 내 시스템에 대한 이해를 향상시킬 수 있습니다.
오늘 무엇을 할 수 있습니까?
질문을 하는 구조화된 접근 방식을 채택합니다. 예를 들어 Microsoft STRIDE를 참조로 채택하여 좋은 결과를 했습니다. 다음과 같은 솔루션 질문의 각 구성 요소를 요청하여 이 작업을 수행할 수 있습니다.
스푸핑: 구성 요소는 사용하는 서비스 및 리소스에 대해 어떻게 인증하나요?
변조: 구성 요소가 수신하는 메시지의 유효성을 검사하나요? 유효성 검사가 느슨하거나 엄격한가요?
부인 방지: 구성 요소가 감사 로그에 상호 작용을 로깅하고 있나요?
정보 공개: 트래픽이 구성 요소를 암호화하여 들어오고 나가는가요? 허용되는 프로토콜 및 알고리즘은 무엇인가요?
서비스 거부: 구성 요소가 고가용성으로 구성되었나요? DDoS 공격으로부터 보호되고 있나요?
권한 상승: 사용자에게 필요한 최소 권한이 할당되어 있나요? 솔루션이 일반 사용자를 대상으로 한 코드와 높은 권한 사용자를 위한 코드를 혼합합니까?
이와 같은 기술은 가르칠 수 있으며 경험을 통해 개선될 수 있습니다. 따라서 학습을 수집하고 조직 내에 분산하도록 설계된 연속 학습 접근 방식을 구현하는 것이 중요합니다.
ROI에 미치는 영향
결론적으로, 위협 모델링 환경의 효율성과 품질을 개선하고 궁극적으로 ROI를 높이기 위해 많은 아이디어를 식별할 수 있습니다. 그러나 이러한 노력은 지속적인 프로세스로 간주되어야 하며, 이는 연습의 지속적인 개선으로 전달되어야 합니다.
결론
위협 모델링은 조직의 보안을 개선하기 위한 훌륭한 방법입니다. 올바르게 수행하면 매우 합리적인 비용에 대한 값을 제공할 수 있습니다. 다음을 포함하여 최신 솔루션을 보호하기 위한 위협 모델링의 가치를 개선하는 데 필수적인 다양한 기술을 이미 확인했습니다.
다음을 수행하여 DevOps 사례에 따라 위협 모델을 정렬합니다.
완화에 집중
사용자 스토리와 대책 연결
위협 모델과 백로그 간의 불일치 강조 표시
위협 모델을 사용하여 보안을 위한 보다 포괄적인 모니터링 및 감사 추진
위협 모델 만들기를 간소화하고 결과의 일관성을 높입니다.
보안 챔피언에 의존
위협 및 완화의 식별을 자동화하는 기술 자료 채택
더 나은 기술 자료 만들기
자동화에서 지원하는 질문 프레임워크 제공
바라건대, 그들 중 일부는 이미 선호하는 위협 모델링 도구에서 찾을 수 있을 것입니다. 다른 사람들은 미래에 포함 될 것입니다. 위협 모델링을 위해 ROI를 극대화하는 것은 아직 없는 답변이 필요한 장기적인 노력이라는 것을 알고 있습니다. 우리는 또한 몇 가지 질문은 아직 알 수없는 것을 알고있다. 이 논문은 사고에 영감을 줄 수 있을 것이며, 여러분이 위협 모델링을 개선하는 데 도움이 되기를 바랍니다. 우리는 그것이 당신과 우리를위한 등대가 될 수 있기를 바랍니다, 그것은 앞으로 몇 년 동안 우리의 노력을 지시하는 것이 유용 할 것입니다.