위협 모델링이란 무엇인가요?

위협 모델링이란 무엇인가요?

위협 모델링은 애플리케이션과 해당 환경에서 보안 허점을 찾기 위한 연습입니다. 여기에는 모든 구성 요소가 포함된 애플리케이션의 표현을 만든 다음 취약점을 식별하는 작업이 포함됩니다. 이상적으로는 개발자와 보안 엔지니어가 소프트웨어 개발 프로세스 전반에 걸쳐 애플리케이션을 실행하기 전뿐만 아니라 실행 후에도 위협 모델링을 사용하는 것이 좋습니다. 위협 모델링은 애플리케이션을 그렇지 않았을 때보다 훨씬 더 안전하게 만드는 데 도움이 될 수 있지만, 애플리케이션을 난공불락으로 만들 것으로 기대해서는 안 됩니다.

강도 영화에서 주인공은 종종 강도를 계획하는 시설의 청사진을 검토하여 건물에 들어갈 수 있는 위치, 보안 카메라가 볼 수 없는 각도 등 약점을 파악합니다. 마찬가지로 위협 모델링은 주어진 애플리케이션의 "청사진을 검토하는 것과 같습니다." 차이점은 위협 모델링은 잠재적 강도가 아닌 애플리케이션을 안전하게 유지하려는 사람이 수행한다는 것입니다.

위협 모델링을 하려면 팀에서 애플리케이션에 대한 전체 보기를 만들어야 합니다. 그런 다음 애플리케이션을 손상시키려는 사람처럼 생각해야 합니다. 공격자는 어떻게 할까요? 취약한 API 보안을 이용할 수 있을까요? 통합 시스템 라이브러리를 감염시키기 위해 공급망 공격( )을 사용하나요? 모든 공격을 예측할 수 있는 것은 아니지만 위협 모델링은 일부 공격을 발생하기 전에 차단하는 데 도움이 됩니다.

위협 모델링의 단계는 무엇인가요?

위협 모델링에는 다양한 접근 방식이 있으며, 한 가지 방법을 모든 상황에 적용할 수는 없습니다. 하지만 일반적으로 다음 네 가지 주요 단계가 포함됩니다:

1. 애플리케이션 평가 및 다이어그램 작성하기

위협 모델러는 위협을 식별하고 묘사하려고 시도합니다:

• 데이터베이스 서버, 웹 서버, 게이트웨이, 라이브러리 및 사용자 인터페이스를 포함한 애플리케이션의 구성 요소
• 데이터 교환에 사용되는 프로토콜 및 전송 중인 데이터를 보호하는 암호화 등 이러한 구성 요소가 연결되는 방식입니다.

Terry가 풍선 사진을 표시하는 간단한 애플리케이션을 작성한다면 애플리케이션 다이어그램은 다음과 같을 수 있습니다:

이는 매우 단순화된 예시이며 실제 위협 모델링 애플리케이션 다이어그램은 훨씬 더 복잡할 수 있습니다.

2. 애플리케이션 구성의 보안 결함 식별

이러한 방식으로 애플리케이션이 배치된 것을 보면 결함을 더 쉽게 식별할 수 있습니다. 예를 들어, 테리는 풍선 사진 데이터베이스와 웹 서버 간의 통신이 전송 계층 보안(TLS)을 사용하지 않는다는 것을 알 수 있습니다. 즉, 두 서버 모두 디지털 서명을 통해 상대방의 신원을 확인하지 않으므로 공격자가 데이터베이스 서버를 사칭하여 악성 콘텐츠를 웹 서버로 전송할 수 있습니다.

3. 결함을 수정하는 변경 사항 만들기

위협 모델링은 개발 프로세스 전반에 걸쳐 이루어지므로 결함을 완화하려면 애플리케이션 아키텍처에 대한 계획을 변경하거나 진행 중인 애플리케이션 빌드에 수정 사항을 배포해야 할 수 있습니다.

그가 식별한 위협을 완화하기 위해 Terry는 데이터베이스 서버와 웹 서버가 연결에 TLS를 사용하도록 재구성하거나, 더 나은 방법으로는 상호 TLS(mTLS) 를 사용하여 서로를 확인하도록 할 수 있습니다.

4. 변경 사항이 적용되어 위협을 올바르게 완화했는지 확인합니다.

이 시점에서 테리는 테스트 환경에서 애플리케이션을 실행하여 1) 서버가 구성된 대로 TLS를 사용하는지, 2) 웹 서버가 데이터베이스 서버 대신 확인되지 않은 서버의 HTTP 트래픽을 허용하는지 확인할 수 있습니다. 그는 자신이 적용한 다른 완화 조치에 대해서도 유사한 점검을 수행합니다.

다양한 위협 모델링 방법론에는 어떤 것이 있나요?

위협 모델링 방법론은 위협을 식별하기 위한 접근 방식입니다. 방법론은 복잡한 시스템에서 압도적일 수 있는 위협 모델링 프로세스에 구조를 제공합니다. 조직은 다양한 위협 모델링 방법론 중에서 선택하거나 자체적으로 개발할 수도 있습니다. 가장 일반적인 방법론은 다음과 같습니다:

• STRIDE: Microsoft에서 개발한 이 방법론은 보안 위협을 식별하기 위한 니모닉 장치입니다. "STRIDE" 의 글자는 "스푸핑, 변조, 거부, 정보 공개, 서비스 거부, 권한 상승," 을 의미합니다. ("거부" 여기서 거부란 데이터의 출처와 무결성을 확인할 수 없음을 의미합니다.) 이 아이디어는 애플리케이션 아키텍처 전반에서 이러한 6가지 특정 유형의 위협을 찾는 것입니다.
• PASTA: " 공격 시뮬레이션 및 위협 분석 프로세스의 약자입니다." PASTA는 위협을 식별하고, 열거하고, 점수를 매기는 7단계 프로세스입니다.
• VAST: 시각적, 민첩하고 간단한 위협(VAST) 방법론은 자동화된 위협 모델링 소프트웨어 제품인 위협모델러와 연관되어 있습니다.
• SQUARE: 보안 품질 요구 사항 엔지니어링(SQUARE) 방법론은 개발 프로세스 초기에 보안 문제를 미리 파악하는 데 도움이 됩니다.

다른 위협 모델링 방법론도 몇 가지 있습니다. "트라이크" 및 다양한 하이브리드 방법론과 같은 일부는 약어조차 없습니다.

위협 모델링은 언제 수행되나요?

위협 모델링은 애플리케이션의 수명 주기 전반에 걸쳐 소프트웨어 개발 전과 개발 중에 수행하도록 되어 있습니다. 위협 모델링이나 완화 조치 없이 애플리케이션을 출시하면 보안 팀에서 발견하기 전에 사용자 또는 공격자가 보안 결함을 발견할 수 있습니다. 이로 인해 데이터 유출 이 발생할 수 있으며 제로 데이 위협의 위험이 커질 수 있습니다.

그러나 위협 모델링이 시스템 내의 모든 위험을 발견하는 것은 아니므로 개발자와 조직은 릴리스 후에도 이 프로세스를 계속 진행해야 합니다. 위협 모델링 외에도 다음과 같은 방법을 사용할 수 있습니다:

• 위협 헌팅: 여기에는 시스템에 대한 위협을 사전에 검색하는 작업이 포함됩니다. 위협 헌팅( )은 보안 분석가가 수행하는 수동 조사 프로세스, 보안 도구가 수행하는 자동화된 프로세스 또는 이 두 가지를 결합한 프로세스일 수 있습니다.
• 모의 침투 테스트: 모의 침투 테스트또는 펜 테스트는 윤리적 해커가 컴퓨터 시스템의 취약점을 찾아내어 악용하는 보안 연습입니다. 효과적인 모의 침투 테스트를 수행하려면 시스템에 대한 사전 지식이 없는 사람이 수행해야 하므로 위협 모델링 프로세스와 완전히 분리하여 수행해야 합니다. 보안 시설의 설계자가 강도 영화에서 강도가 침입할 수 있는 결함을 예상하지 못하는 것처럼, 애플리케이션을 구축한 사람들은 애플리케이션에 너무 가까이 있어 모든 결함을 파악하지 못하는 경우가 많습니다.
• 기타 애플리케이션 보안 조치: 애플리케이션 보안 은 복잡한 분야입니다. 어떤 시스템이나 애플리케이션도 완전히 안전하다고 간주해서는 안 됩니다. 웹 애플리케이션 방화벽(WAF)( )은 웹 애플리케이션 보안에 큰 도움이 될 수 있습니다.

Cloudflare는 또한 최신 위협으로부터 고객을 보호하기 위해 위협 인텔리전스( )와 운영 서비스인 Cloudforce One을 제공합니다. 클라우드포스 원은 글로벌 규모의 공격자를 차단한 경험이 풍부한 세계적 수준의 위협 연구팀이 이끌고 있습니다. 여기에서 클라우드포스 원에 대해 자세히 알아보기.