죄송합니다. 더 이상 지원되지 않는 웹 브라우저입니다.

장기적 IoT 성공을 위한 위험 평가

PDF 다운로드

글/Stephen Evanczuk, 마우저 일렉트로닉스(Mouser Electronics)

사물인터넷(IoT) 애플리케이션은 주변 센서, 게이트웨이, 클라우드 리소스를 결합하는 데 있어 잠재적 공격 표면의 수와 보안 취약성 때문에 전례 없는 타겟이 되고 있다. 기업들이 이러한 애플리케이션을 각자 인프라에 더욱 밀접하게 연결함에 따라, 이러한 위협이나 위협 가능성이 미칠 영향에 대해 명확하게 이해해야할 필요성이 더 시급해지고 있다. 개발팀에서는 위협과 위험 평가에 대한 체계적 접근방식을 사용하여 필요한 장소의 보안을 강화하거나, 허용 가능한 위험에 대한 확실한 정보에 입각하여 결정을 내릴 수 있다.
다수 뉴스보도에서는 커넥티드 시스템의 광범위한 보안 취약성이란 표현이 매우 자주 사용된다. 기사 헤드라인만 빠르게 훑어보아도 공공연한 대규모 분산 서비스 거부(DDoS) 공격에서부터, 중요한 데이터를 은밀하게 추출하거나 또는 더 극단적 공격의 준비가 필요한 지능적 지속 공격(APT)에 이르기까지 놀랄 만큼 넓은 공격 폭을 보여준다.
위와 같은 활용의 선정주의적 성질에도 불구하고, 이러한 공격 행위로부터 얻게 되는 가장 중요한 교훈 중 하나는 보안 메커니즘의 사용과 보안 시스템의 생성은 동일한게 아니라는 것이다. 해커들은 모든 유형의 보안 메커니즘으로 구축된 시스템에 성공적으로 침투한다. 심지어 보안에 가장 민감한 개발팀조차 무의식적으로 공격 표면을 설계에 남길 수도 있다.
사실, 오늘날은 설계의 복잡성으로 인해 IoT 애플리케이션과 같이 특히 다층적인 커넥티드 시스템에서 개방형 공격 가능성이 높아진다. 서로 다른 유형의 프로그래밍 가능한 많은 장치가 클라우드에 연결되면, 엔드-투-엔드 보안은 절대적 확실성보다는 통계적 확률에 가까워진다. 이와 같이 시스템 내 상호연결된 시스템의 각 구성 요소들은 그 특정 기능뿐만 아니라 보안 방정식에 대한 고유의 취약성도 제공한다.
각각의 취약성이 전체 애플리케이션에 어떻게 위협이 될 수 있는지를 완전히 이해하고 나서야 기업에서는 해당 취약성을 성공적으로 활용했을때 따르는 관련 위험 부담이 허용치를 넘어설 정도로 커져서 결국에는 완화가 필요한지에 대한 여부를 결정할 수 있다.
위와 같은 수준의 가시성을 위험의 본질 안으로 끌어들일 수 있는 능력은 충분한 전략적 가치를 제공한다. 동시에 보안의 취약성에 알맞는 위험 평가를 수행함으로써, 개발팀에서는 커넥티드 시스템의 거의 무한에 가까운 위협적인 흐름에 대한 실질적 대응책을 개발하기 위해 전술적 로드맵을 고안할 수 있다. 실제로, 위협과 위험 평가를 통해 얻은 보다 엄격한 수준의 이해가 없다면, 경험이 가장 풍부한 개발팀이라고 할지라도 그들의 시스템과 애플리케이션의 보안에 도박을 하고 있다고 봐야할 것이다. 그러나 이러한 지식의 습득은 시스템의 잠재적 위협을 체계적으로 문서화된 위협 모델에서 명확하게 이해하는데서부터 시작된다.
위협 모델은 시스템 설계와 관련된 특정 보안 취약점을 다룬다. 위협 모델을 만드는 것은 개념적으로는 간단해 보인다. 예를 들어, 개발자들은 설계를 분석하여 각각의 구성 요소들과 관련된 보안 취약점들을 찾아낸다. 그러나 실제로 위협 모델링에는 이러한 단순한 개념이 제시하는 것보다 훨씬 많은 작업과 연구, 전략이 포함될 수 있으며, 예상보다 훨씬 많은 기술 보안 문제가 발생할 수 있다. 보다 광범위하게 적용해보면, 위협 모델링은 관련 수명주기 프로세스나 IoT 애플리케이션과 관련된 중요한 보안 정책의 취약성도 식별할 수 있다. 궁극적으로, 수용 가능한 위협 모델의 구성 요소들은 사용하는 IoT 애플리케이션이나 소속 단체에 따라 광범위하게 달라질 수 있다. 그렇더라도 서로 다른 위협 모델은 특정 성질을 공유하며, 모든 위협 모델링 방법론은 몇 가지 공통적인 절차를 따를 것이다.

위협 모델링

위협 모델링은 유틸리티 수도 계량기의 작동과 같은 특정 사용 사례와 관련된 시스템, 이른바 평가대상(TOE)에 대한 정확한 설명에서 시작한다. 위협 모델이 시스템 취약성에 대한 그림을 그리는 작업이라고 본다면, TOE에 대한 설명은 캔버스에 비유할 수 있다. TOE의 범위를 확대하거나 강화함으로써 위협 모델링 팀은 위협 식별 프로세스에서 초점을 확대하거나 축소할 수 있다. 예를 들어, Arm이 최근 출시한 스마트 워터 미터 위협 모델은 TOE를 명확히 제한하면서 시스템의 핵심에만 초점을 맞춘다(그림 1).

[그림 1]  Arm의 워터 미터 위협 모델은 해당 시스템에 일반적으로 포함되는 하위 시스템 요소들을 모두 포함시키기 보다는 시스템 핵심을 위해 TOE를 제한하여 더욱 다루기 쉬운 분석 범위를 얻을 수 있다. (출처: Arm)

물론, 더 크고 복잡한 시스템이나 애플리케이션 하나의 하위 집합 내에 국한된 TOE는 위협 식별, 위험 평가 및 효과적인 경감 계획 수립 기능이 더욱 제한적이라는 것을 의미한다. IoT 애플리케이션의 시스템과 같은 복잡한 시스템의 경우, 경험이 풍부한 위협 모델러는 전체 시스템에 대한 상당히 개략적인 설명부터 조직에 있어서 특별히 중요하거나 관심 있는 하위 시스템에 대한 보다 상세한 설명으로 이어지는 일련의 위협 모델을 만들 것이다
어떤 접근 방식이든 TOE 설명이 요하는 세부 수준에 대한 절대적 요구 사항은 없다. 각 구성 요소의 세부사항을 하나하나 철저하게 제공하고자 하는 모델링 접근방식은 프로세스에 참여한 사람들을 지치게 할 수 있다. 반면 지나치게 추상적인 모델은 감지하기 힘든 취약성을 은폐할 수 있고, 종속 체인이나 서드파티 소프트웨어 라이브러리에 깊이 파묻혀 있는 취약성 감지를 방해할 가능성이 높다.
접근방식의 효과적인 절충안은 시스템의 개별적이면서도 고유한 영역사이의 ‘신뢰 경계’를 넘나드는 모든 상호작용을 포착하기 위해 필요한 수준까지 진화하는 수준을 상세하게 수집하는 것이다(그림 2).

[그림 2] 위협 모델은 각기 다른 시스템존에서 신뢰 구간을 넘나들 가능성이 있는 트렌잭션을 식별할 수 있게 충분한 내용을 제공해야 한다. (출처: 마이크로소프트)

예를 들어, IoT 애플리케이션은 클라우드 리소스, 게이트웨이, IoT 터미널 장치 및 사용자와 연결된 여러 영역으로 구성될 수 있다. 신뢰 경계를 넘어 작동하는 과정은 전송 데이터, 보안 자격 증명 또는 프로토콜에 대한 특수 공격에 유난히 취약하다.
겉보기에 무해해 보이는 신뢰 경계 간 통신 시도조차도 해커들로 하여금 보다 직접적인 공격에 대비하여 구축한 시스템의 기본 구성 요소를 결정하는 시스템 응답에 포함된 알려진 지표를 사용하는 ‘지문’ 공격 경로를 만들어줄 수 있다.
물론, 이러한 구성 요소들 중 일부가 서드파티에서 제공되는 경우 각 영역 내의 기본 구성 요소 간 상호 작용을 이해하는 것은 매우 중요하다. 예를 들어서 서드파티 센서 드라이버를 사용하는 loT 장치의 경우 드라이버의 경계 부분이 위협에 취약할 수 있다(그림 3).

[그림 3] 이 데이터 흐름도는 데스크탑 소프트웨어 드라이버의 경계를 넘나드는 처리 과정을 설명하기 위해 설계되었지만, IoT 장치를 포함한 모든 커넥티드 시스템에서 제 3자 하드웨어 또는 소프트웨어 구성 요소와 관련된 처리 과정에 있어서도 동일한 원칙이 적용된다. (출처: Microsoft)

위협 모델링에 있어서 어느 정도의 상세 설명은 필수적이지만, 그만큼 세부 정보와 연관된 특정 위협을 식별할 수 있다는 이점이 생긴다. Arm의 워터 미터 위협 모델의 경우 모델러는 펌웨어, 측정 데이터 및 TOE와 접촉이 가능한 외부 객체(사용자, 관리자, 공격자 등)와의 상호작용 등 각각의 자산과 관련된 위협을 쉬운 언어 표현으로 열거한다.
펌웨어의 경우, 해당 모델은 손상된 펌웨어의 설치, 펌웨어 업데이트 인증에 사용되는 보안 인증서의 수정, 복제 등을 포함한 특정 위협에 대해 설명한다. 개발팀은 자산 목록과 식별된 취약성에 기반하여 이에 부합하는 보안 목표 및 완화 방법을 개발할 수 있다. 예를 들면, Arm의 워터 미터 모델은 보안 부팅의 필요성, 펌웨어 인증, 인증 실패에 대한 대응 등 펌웨어에 대한 요구 사항을 포함한 보안 요구 사항 리스트를 통해 판단을 내린다.

사용 가능한 리소스

잠재적 위협을 식별할때 TOE 설명에 포함된 세부 자산 및 프로세스에 적용할 수 있는, 발생 가능한 모든 위협을 최신 상태로 유지할 수 있는 개발 조직은 거의 없다. 좋은 소식은 이 과정의 부분에 있어서 도움이 될만한 공개 소스를 다수 찾을 수 있다는 점이다. 개발자는 ‘공통 공격 형태 목록 및 등급(CAPEC)’ 목록과 같은 공공 자원을 사용하여 가장 일어날 확률이 높은 공격 유형을 탑다운 방식으로 검토할 수 있다. 그런 다음, 하드 코딩된 자격 증명 사용과 같이 시스템 설계 접근방식에 내재된 결함을 설명하는 ‘공통취약점목록(CWE)’ 목록에 열거된 공격 확률이 높은 대상을 바텀업 방식으로 확인할 수 있다. 설계자가 설계에 사용된 특정 하드웨어 또는 소프트웨어 구성 요소를 확인하고 나면, 사용 가능한 하드웨어 또는 소프트웨어 구성 요소의 특정 소프트웨어 결함이나 잠재적 악용 사례를 보여주는 ‘공통 보안 취약성 및 노출(CVE)’ 목록을 확인할 수 있다.
위험 평가의 경우, ‘공통 취약점 평가 체계(CVSS)’와 같은 리소스는 특정 취약성과 관련된 위험 평가를 위한 일관된 접근방식을 제공한다. 위험은 특정 취약성의 성질과 관련이 있지만, 공격을 수행할 때 사용되는 경로(벡터), 취약성을 이용하기 위해 필요한 공격의 복잡성 등 다른 요소도 포함한다. 예를 들어, 네트워크를 통해 수행할 수 있는 공격은 물리적 접근이 필요한 공격보다 훨씬 더 많은 위험을 초래한다. 마찬가지로, 수행 방법이 간단한 공격은 수행 방법이 본질적으로 매우 복잡한 공격보다 훨씬 더 많은 위험을 수반한다. CVSS 계산기를 사용하면 이러한 원인을 제공하는 다양한 요인을 신속하게 처리할 수 있으며, 특정 위협이나 위협 등급과 연관된 위험 수준 수치에 도달할 수 있다. Arm의 워터 미터기의 경우, CVSS 계산기에서는 펌웨어 공격과 관련된 요소들의 합이 ‘매우 위험함(critical)’을 의미하는 9.0점을 표시한 것으로 나타났다(그림 4).

[그림 4] CVSS 계산기를 사용할 때, 개발팀은 펌웨어와 같은 TOE 요소들의 여러가지 취약점 관련 항목들을 고위험군으로 분류했다 (출처: FIRST.org)

요구사항이나 기술이 광범위하기 때문에, ‘오픈 웹 애플리케이션 보안 프로젝트(OWASP)’의 Threat Dragon Project나 Mozilla의 SeaSponge, Microsoft의 Threat Modeling Tool과 같은 자동화 툴은 개발자들의 모델링 프로세스에 도움을 준다. 각 자동화 툴은 Threat Dragon Project와 SeaSponge의 시스템 다이어그램부터 Microsoft의 STRIDE(‘위장’, ‘변조’, ‘부인’, ‘정보 유출’, ‘서비스 중단’, ‘권한 상승’으로 번역됨) 접근법까지 다양한 위협 모델링 방법을 사용한다.
이러한 툴은 사용된지 수년이 되었고 통상적으로는 기업 소프트웨어 시스템을 위해 구축되었지만, 위협 모델링은 광범위하게 적용 가능하고 언제나 신선한 프로세스로, 특정 방법론들보다 공격 벡터, 약점 및 취약점의 현재 목록에 더 많이 의존한다. 그럼에도 불구하고, 이제는 시스템 설명과 위협 식별 사이를 더 긴밀하게 연결해주는 새로운 툴이 등장하고 있다. 다른 분야에서 딥러닝 기술이 급속도로 많이 등장하고 있지만, 이러한 기술을 자동화 위협 및 위험 평가에 적용하는데 있어 중요한 과제가 남아있다. 그렇더라도 스마트 모델링과 평가 툴은 곧 가용될 것으로 보인다.
한편, 개발자들은 보안의 약점, 취약성 및 공격 패턴을 나열하는 다양한 자료들을 찾을 수 있기 때문에 위협 모델링에 참여하기 시작한 사람들에게는 특히 이용 가능한 모든 세부 정보들이 대응하기에 힘들어 보일 수 있다. 실제로 위협 모델링을 피하기 위해 복잡하다고 변명하는 것은 매우 흔한 일이다.
엔지니어의 경우 세부사항의 전체에 뛰어드는 것보다는 가장 일반적인 위협에 초점을 맞춘 더욱 평범한 접근법으로 시작할 수 있다. 이 기사의 본문 작성 시점 기준으로 OWASP는 2018년도 상위 10대 IoT 보안 위협 선정 사항에 대해 여전히 검토 중이지만, 초기에 대두된 OWASP 상위 10개 IoT 목록은 오늘 날에도 유용한 출발점을 제공한다. 실제로 개발자들은 주요 취약성과 활용에 대한 준비된 카탈로그를 찾아보고자 한다면 선호하는 뉴스 사이트 내에서도 모두 찾을 수 있다.
그러나 기본 사항들을 빠른 속도로 짚고 넘어갈 수 있는 조직의 경우, 이와 같은 방법은 IoT 설계와 동일하게 중요한 측면을 다루는데 매우 유용할 수 있다. 예를 들면, 기계 제어 루프에 사용되는 시스템은 일반적으로 기능 안전과 관련된 임무 수행에 필수적인 요건과 직면한다. 이러한 시스템은 보안과 기능 안전이 매우 얽혀 있기 때문에 해당 시스템에 적합한 위협 모델에는 보안이나 안전의 약점이 물리적 위험을 초래할 수 있다는 시나리오를 포함시킬 필요가 있을 것이다. 같은 방식으로 보안과 프라이버시는 여러 측면에서 겹치지만, 어느 한 쪽의 약점이 개인식별가능정보 공개와 같은 결과를 초래할 수 있다는 차이점이 있다.

결론

복잡한 시스템에서의 위협 모델링과 위험 평가의 효과적인 적용은 사용 가능한 옵션과 기술을 단순히 여러개 적용하는 수준을 훨씬 넘어선다. 각각의 특정 시스템과 마찬가지로 개발 기업에서 각자의 고유한 제약 조건과 능력으로 이를 감당해야 한다.
어떤 시스템이나 기업에 대한 요구사항은 다른 회사의 기준과 완전히 다를 수 있다. 아마 유일한 공통 요건은 우선 위협 및 위험 평가를 수행해야 한다는 점일 것이다. 그렇지만 기업 차원에서 ‘완전한 위협 모델과 위험 평가’를 만들려고 시도하는게 맞는 것일까? 간단하게 대답하면 ‘No’다. 사실, 그렇게 하려고 시도하더라도 결국 이 완벽한 목표에는 미치지 못할 것이다.
결과를 완벽하게 예측하는 것은 불가능하다. 자연적으로 혼란스러운 과정과 시스템 완화와 해커의 공격 사이의 간극은 결국 완벽을 향한 어떤 시도도 쉽게 좌절시킨다.
그럼에도, 위협 모델과 위험 평가가 제공하는 일종의 보안 로드맵을 구축하지 않는다면 최소한 피할 수 없는 보안 침해로 이어지는 일부 함정과 우회로를 피하는 것도 역시 불가능하다.

leekh@seminet.co.kr
(끝)
<저작권자(c) 반도체네트워크, 무단 전재-재배포 금지>