지금 당장 저지를 가능성이 높은 7가지 위협 모델링 실수

OWASP(Open Web Application Security Project)는 위협 모델링이 애플리케이션과 관련된 보안 위험을 식별, 정량화, 해결하기 위한 구조화된 접근방식이다. 이는 기본적으로 애플리케이션 라이프사이클 가운데 위협 방지 또는 완화를 위한 적절한 통제를 조기에 이행해 시스템 구축 또는 배치 시 위협에 대해 전략적으로 생각하는 것이 수반된다.

위협 모델링(threat modeling)은 일종의 개념으로 전혀 새로운 것은 아니지만 이를 유의미한 방식으로 이행한 조직이 거의 없다. TMS(ThreatModeler Software)의 설립자이자 CEO인 아치 아가월은 "위협 모델에 대한 우수사례가 여전히 등장하고 있다"고 말했다. 아가월은 "가장 큰 문제점은 위협 모델링의 핵심이 무엇인지에 대해 이해하지 못한다는 것"이라며, "위협 모델링 방법은 다양하며 기업들은 이를 하나의 프로세스로 보고 확장하는 방법을 찾아내는 문제에 직면할 수 있는 경우가 많다. 여전히 전반적인 것이 명확하지 않다"고 설명했다.

이번 기사에서는 아가월과 다른 전문가들이 말하는 위협 모델링 시 저지를 수 있는 7가지 실수에 대해 살펴보자.

1. 너무 애플리케이션 중심적이다
조직이 위협 모델을 구축할 때 저지르는 가장 보편적인 실수는 애플리케이션 자체에만 집중하는 것이다. 아가월은 "위협 모델링을 통해 하나의 애플리케이션뿐만이 아니라 전반적인 상황을 이해해야 한다"고 말했다.

인프라, 데이터베이스, 공유 구성 요소, 제 3자 상호작용, 배치 환경 등을 고려한다. 위협은 애플리케이션이 온프라미스인지, 아니면 클라우드에서 구동하는지 또는 모바일 장치와 기타 컴퓨팅 엔드포인트에서 접속할 수 있는지 여부에 따라 달라질 수 있다.

클라우드로 이행 중인 경우, 클라우드를 위한 위협 모델이 필요하다. 아가월은 "애플리케이션과 데이터가 전용 인프라에서 운용될까, 아니면 공유 서버와 데이터베이스에서 운용될까, 위협 모델링 시 애플리케이션뿐만이 아니라 이와 관련된 모든 것을 살펴봐야 한다는 것을 기억해야 한다"고 말했다. 개발자는 애플리케이션 개발 시의 일부 수정사항과 애플리케이션 배치 시 처리해야 하는 작업에 대해 생각해야 한다.

2. 위협이 아닌 취약점에만 초점을 맞춘다
IDC 분석가 피트 린드스트롬은 "위협이 아니라 취약점에만 과도하게 집중하는 것이 조직이 범할 수 있는 실수"라고 말했다. 분명 데이터 흐름과 제어 흐름을 파악하고 앱에 어떤 취약점이 존재할 수 있는지 아는 것은 중요하다.

또한 위협을 좀 더 명시적으로 살펴보고 위험할 수 있는 입력과 출력을 확인해야 한다. 공격자가 사용자의 제어를 차단해 데이터의 기밀성, 무결성, 가용성, 생산성, 전매 특허 특성에 영향을 끼칠 수 있는 모든 가능성에 대해 생각해봐야 한다.

린드스트롬은 "현재 우리는 멜트다운과 스펙터(Meltdown and Spectre)가 기밀성에 대한 공격이라고 이야기한다"면서도, "하지만 무결성이나 가용성은 어떨까, 공격자가 이런 메모리 테이블을 조작하거나 데이터를 삽입할 수 있는 방법이 있을까"라고 반문했다. 특정 익스플로잇(Exploit) 공격에 대한 통제력이 있다고 해서 공격자가 결함을 이용할 수 있는 새로운 방법을 발견할 수 없는 것이 아니다.

3. 현재의 위협에 과도하게 집중한다
SANS 인스티튜트(Institute)의 신규 보안 트렌드 이사 존 페스카토는 "위협 모델 구축 시 최신 위협만 추구하거나 특정 위협 활동자 또는 활동자 유형에 과도하게 집중하지 말라"고 충고했다. 랜섬웨어(Ransomware)와 크립토마이닝(Cryptomining) 소프트웨어가 보안에 가장 큰 최신 위협을 가할 수도 있다. 이런 위협에 특화된 모델링보다는 시스템의 기밀성, 무결성, 가용성에 대한 모든 위협을 완화시키는 통제력에 집중해야 한다.

페스카토는 "마찬가지로 중국, 러시아, 세르비아 등의 활동자가 위협을 가하는지 여부는 중요하지 않다"고 말했다. 발생하는 위협에 대응할 수 있는 방법을 알기 때문에 귀속성 및 국가 지원 해커와 범죄자에 대해 초점을 맞추는 것은 덜 중요하다. 페스카토는 "중국 활동자들이 추적하고 있다는 정보를 듣는 것보다 어떤 조치를 취할지 아는 것이 더 중요하다"고 말했다.

무엇인가 바뀔 때마다 준비할 수 있도록 반복 가능한 프로세스를 구축하는 것에 집중해야 한다. 위협의 생소함에 상관없이 매번 같은 방식으로 수행되는 표준 프로세스 또는 방법론을 확보하는 것이 핵심이다. 페스카토는 "자신이 보호하려는 대상을 파악하고 거기에서부터 시작하는 것이 중요하다"고 충고했다.

4. 위협 모델링을 위한 위협 지도 작성의 오류를 범하고 있다
아가월은 "위협 모델 구축이 위협 목록을 작성하고 자신의 앱이 해당 사항이 있는지 확인하는 것이라고 생각한다면 위협 지도를 작성하고 있는 것"이라고 말했다. 아가월은 "온라인 뱅킹 애플리케이션이 있고 '플래시(Flash)를 사용하는가' 또는 '자바(Java)를 사용하는가' 또는 '인증을 수행하는가' 등 일련의 질문을 묻는다고 가정해 보자"고 말했다. 위협에 대한 맥락이 없기 때문에 위협 모델링을 수행하는 것이 아니다. 플래시를 어떻게 사용하는지 또는 어디에서 사용하고 있는지 모르고 있다.

마찬가지로 데이터베이스가 있다고 해서 반드시 SQL 주입을 하나의 공격 벡터(Vector)로써 걱정할 필요가 없다. SQL 주입은 외부 소스의 입력을 수용하는 웹 앱이 있을 경우에만 잠재적인 우려 사항이 된다. 아가월은 "위협 평가에 대해 확인목록 접근방식을 취할 때 이런 미묘한 차이를 놓치기 쉽다"고 설명했다.

적절한 위협 모델을 구축하려면 아키텍처 다이어그램이 필수적이다. 앱을 구동하고 액세스하는 데이터베이스, 웹 서버, 운영체제 계층, 인프라를 확인할 수 있다. 모든 데이터와 의사소통이 어디로 흘러가며 진입점이 어디이고 이런 입력점에서 어떤 종류의 투입값이 유입되는지 확인할 수 있다. 아키텍처 다이어그램은 큰 그림뿐만이 아니라 엣지 케이스(Edge Case)도 보여준다.

5. 사용자를 위협 모델에 참여시키지 않는다
적이 코드를 공격하는 방법에 너무 집중한 나머지 애플리케이션과 데이터에 접근할 수 있는 다른 방법은 간과하는 경우가 있다. 페스카토는 "악당이 코드를 공격하는 방법으로 모델을 위협하는 것이 좋다"면서, ""하지만 피싱(Phishing) 공격에 대한 방어책을 애플리케이션에 내장할 수는 없다"고 말했다.

사용자를 위협 모델에 참여시키고 사용자의 행동이 보안에 영향을 끼칠 수 있는 다양한 방식을 고려해야 한다. 권한 관리와 역할 기반 액세스 같은 것들을 살펴봐야 한다. 사용자가 클라우드에서 또는 더 큰 전자상거래 스키마의 일부일 수 있는 모바일 앱을 통해 애플리케이션에 액세스할 때의 잠재적인 위협을 고려해야 한다.

6. 위협 모델링에 대한 일회성 접근방식을 취한다
위협 모델은 정적일 수 없다. 아가월은 "필수적인 애플리케이션을 갖다가 위협 모델을 한 번만 수행하고 끝났다고 생각해서는 안 된다"고 경고했다. 조직이 인지하고 있다고 지속적인 개발 활동이 이뤄진다. 애플리케이션이 바뀌면 위협 프로필도 바뀐다. 즉, 현재의 위협 모델이 3개월 후에는 무용지물이 될 것이다. 아가월은 "위협 모델은 살아 있는 문서여야 한다. 단순히 위협 모델을 구축하고 손을 떼서는 안 된다. 애플리케이션은 살아 있다."고 설명했다.

7. 자신의 시스템이 다른 시스템에 어떤 영향을 끼치는지 고려하지 않는다
위협 모델을 구축할 때 자신이 디지털 세계에서 어느 정도 신뢰할 수 있는지에 대해 생각해 보는 것도 좋은 방법이다. 직면한 모든 위협을 고려하고 이를 위한 통제책 또는 완화책을 파악했다면 조직의 시스템이 통신하는 다른 시스템에 잠재적으로 어떤 영향을 끼칠지 살펴보자.

린스트롬은 자신의 결과물이 타인의 보안에 어떤 영향을 끼칠 수 있는 지에 주의해야 한다"고 말했다. 린스트롬은 "예를 들어, 자신이 암시장 사이트를 위한 공간을 제공하고 있거나 누군가 자신의 도메인에 자리를 잡고 있거나 자신의 IoT 시스템에서 DDoS 패킷에 대한 반응을 살펴볼 수 있다"고 설명했다.

광고 차단 앱은 수용하지 않더라도 자신의 사이트에 있는 악성 광고가 고객의 시스템을 감염시킨다면 어떻게 될까? 온라인에 무엇인가를 배치하면 이를 깔끔하게 유지해 자신의 시스템을 사용할 때 다운스트림 사용이 영향을 받지 않도록 할 책임이 있는 것이다. 린드스트롬은 "디지털 신뢰성과 책임 관점에서 이런 부지런함이 위협 모델링에 포함돼야 한다"고 말했다.

위협 모델링 활동의 일환으로써 오픈소스 소프트웨어 및 제 3자 구성 요소와 관련된 자신의 조직뿐 아니라 자신의 서비스의 다운스트림 사용자에 대한 위험을 파악해야 한다. 예를 들어, 매시업(Mashup)을 제공하고 있다면 자신의 데이터 또는 서비스가 다른 누군가의 결과에 어떤 영향을 끼칠 수 있는지에 관해 생각해 봐야 한다. 다른 누군가가 자신이 제공하는 GPS 데이터에 의존하고 있다면 그 데이터의 무결성과 신뢰성에 대해 생각해 봐야 한다. editor@itworld.co.kr