보안점검을 위한 체크리스트에 대하여(1)

정신없는 10월을 보내고 일이 좀 여유로워지는 느낌이 드니, 주말에 글을 끄적일 여유도 생겼다.

여유로움은 개뿔.. ㅠㅠ 현재(11.24)까지 바빠서, 매일 야근에 주말출근해서 계속 일했다 ㅠㅠㅠ...

..

 

 

이 글에서는 보안점검을 위한 체크리스트에 대해 얘기하고자 한다. 

 

글에서 최종적으로 말하고자 하는 바를 요약하자면,

"대학원에서 배우고 연구한 '체크리스트'와 실제 기관, 기업 등에서 연구하고 사용하는 '체크리스트'는 어떤 차이가 있을까?"

 

얘기하고 싶은게 많다보니 시리즈별로 내용을 구분하고자 한다.

'보안점검을 위한 체크리스트에 대하여(1)' 에서는 대학원에서 연구한 AI 스피커의 체크리스트에 관한 내용을 다루겠다.

'보안점검을 위한 체크리스트에 대하여(2)' 에서는 기업의 체크리스트와 대학원에서 연구한 체크리스트는 어떻게 다른지 차이점을 얘기하고 싶다.

 

..

 

난 대학원에서 보안 위협모델링(Cybersecurity Threat modeling)을 공부하고, 이를 점검 대상(Target, AI 스피커)에 적용하여 체크리스트를 도출하였다. 체크리스트를 이용해 ai스피커를 점검하던 중 취약점도 몇개 나왔었고..

그리고 현재 회사에서도 동일한 분야(위협모델링, 체크리스트, 보안요구사항 도출 등)를 연구하고 있다. 점검 대상이 대학원때와 다를뿐.

회사에서 연구하다보니 이런 생각이 들었다. '대학원에서 연구할 때는 ~~하게 생각했는데, 회사에서 연구한 체크리스트를 이용해 여러 대상에 적용해보려니 느낌이 다르네?'

대학원에서 공부하던 때보다 시야가 조금 더 넓어진 느낌이었다.

 

 

앞서 말했듯, 나는 대학원에서 배운 지식, 경험을 기반으로 보안점검 대상인 AI 스피커를 선정하고, 보안점검을 위한 체크리스트를 도출하였다. 다음과 같은 방법으로 체크리스트를 연구하였다.

 

연구 방법은 크게 여섯가지로 구분할 수 있다.

 

1. 점검 대상 선정: 내가 연구하던 해에는 AI 스피커가 보안이슈로 많이 떠올랐다. 이에 AI 스피커에 당연 관심이 갔고, 점검 대상(Target)으로 선정하였다. (사실 그냥 교수님이 정해주심 ㅎㅎ.....)

대상을 AI 스피커로만 볼 것인지, AI 스피커를 사용하기 위한 애플리케이션도 포함해야할 지, 껍데기뿐인 AI스피커에게 실질적인 기능을 제공해주는 스피커서버까지 포함해야할 지 잘 고려해야한다. 그냥 단순하게 '난 AI 스피커에 대해 위협모델링 해야지~' 하고 대상을 딸랑 AI 스피커로만 정할 수 없는 문제다. Target을 어느 범위까지 고려해야하는지에 따라 그 뒷 단계의 취약점식별, 분석 내용이 천차만별이다.

 

2. 점검 대상 체계화: 보안위협을 분석하기 위한 첫번째 과정이다. 점검 대상을 최대한 상세하게 체계화해야 한다. 이 과정에서는 DFD(Data Flow Diagram)을 이용할 수 있고, 다른 방법을 이용할 수도 있다. 나는 AI 스피커라는 대상, 환경을 구조화할 때 DFD가 적합하다고 판단하여 이를 이용하였다. 점검대상을 체계화해야 하는 이유는 명확하다. 점검 대상의 구성요소, 구성요소 간 데이터흐름을 빠짐없이 파악하기 위함이다. 이 과정이 상세할수록 점검 대상의 이해도가 더욱 높아지고 위협모델링을 이용한 보안위협 도출 시, 혹여나 실수로 놓치는 포인트(보안위협)를 줄일 수 있다.

관련 주소: en.wikipedia.org/wiki/Data-flow_diagram

Data-flow diagram - Wikipedia

이해도가 왜 높아지느냐? DFD를 작성하기 위해 삽질이란 삽질은 다 하기 때문이다. 구성요소를 빠짐없이 파악하기 위해 제품의 모든 기능을 이용해보고, 매뉴얼도 보고, 기술문서도 보고, 작성자가 어떤 의도로 제품을 개발했을지 관련 글도 찾아보게 된다. 그뿐만이 아니다. 구성요소간 송수신 데이터가 어떤 원리로 어떻게 흐르는지 파악하기 위해 패킷 스니핑도 해보고, 점검 대상의 코드 분석(공개되어있다면.), 심지어 점검 대상을 역분석(리버싱)하기도 한다.

  *이래서 점검 대상이 개발되기 전, 점검 대상의 구조를 정확하게 알고 있는 개발자, 설계자와 의논하면서 보안위협을 식별하는게 가장 좋다.

 

점검 대상의 체계화란 단순히 매뉴얼, 기술 문서를 읽어보는 것과, 점검 대상의 기능 사용만으로는 작성할 수 없다. 패킷 스니핑, 코드 분석, 필요에 따라 리버싱도 수행해야 하기 때문에 점검대상을 상세하게 체계화할 수록 시간이 오래걸리고, 오래걸릴수록 대상의 구조를 정확하게 파악할 수 있다. 파악한 구조를 한눈에 보기 쉽도록 도와주는 기법이 DFD인거고.

 

3. 알려진 모든 보안위협 식별: 점검 대상(Target)을 체계화하면 대상의 모든 구성요소, 구성요소 간 데이터흐름이 한 눈에 보인다. (그래야만 한다.) 여기서 보안위협(Threat)을 어떤 관점으로 식별할 지를 잘 고려해야 한다. 예를 들면

 1. 소프트웨어 취약점(Software Vulnerability) 관점으로 식별할 지

 2. 개인정보보호(Privacy) 관점으로 식별할 지

 3. 위험관리(Risk Management) 관점으로 식별할 지

 4. 물리적, 관리적, 기술적 등 보안정책을 포함하여 다방면으로 위협을 식별할 지.

등이 있겠다. 즉 관점에 따라 보안위협이 다양하게 식별될 수 있다. 나는 소프트웨어 취약점, 개인정보보호 관점으로 AI 스피커의 보안위협을 식별하였고, 이를 위해 STRIDE, LINDDUN 위협모델링을 활용하였다.

관련 주소: www.microsoft.com/security/blog/2007/09/11/stride-chart/

STRIDE chart - Microsoft Security

www.linddun.org/

보안위협을 식별하는 과정에는 여러가지 방법을 이용할 수 있다. 관련 보안 전문가들끼리 모여 Brainstorming을 할 수도 있고, 구글신(Google)에게 점검 대상의 보안위협이 어떤 것들이 있는지 물어보는 방법도 있을 것이다. 본인이 아는 취약점을 적어도 된다.

이런 방법에는 대표적으로 논문, 기술문서, 발표자료, 취약점 데이터베이스, 기술 전문가의 자문 등이 있다.

 

단, 식별한 모든 보안위협에는 근거가 필요하다. 아무런 근거없이 보안위협을 도출해서는 안된다는 뜻이다. '여기에는 이런 취약점이 있고 저기에는 저런 취약점이 있어요. 왜냐고요? 제가 이런거 잘 알거든요' 처럼 뇌피셜로 보안위협을 도출했다간, 식별한 모든 보안위협에 신뢰도가 떨어진다. 만약 근거없이 머리에 떠오르는 대로 A라는 구성요소에는 3가지의 취약점이 있다고 얘기했는데, 다른 보안전문가가 (여러 근거에 기반하여) 식별한 취약점 개수와 다르다면 과연 어느 쪽의 식별 결과가 더 신뢰도가 높을까? 

 

4. 보안위협에서 실제 발생 가능한 공격 도출:  3. 과정에서 보안위협을 식별했다면 그에 관한 공격을 도출할 수 있다. 예를 들면 특정 임베디드 장치에 아이디, 패스워드 노출위협이 존재한다고 할 경우, 그에 해당하는 공격으로 SQL 인젝션이 존재할 수도 있고 중간자 공격(MITM, Man in the Middle Attack)을 통한 방법도 있을 것이며 하드웨어 저장소(Storage)에서 정보를 탈취하는 방법도 있겠다. 나의 주 점검 대상인 AI 스피커는 아이디, 패스워드 정보를 Storage에 저장하지 않으니 저런 공격은 없겠지만.. 

관련 주소 : www.schneier.com/academic/archives/1999/12/attack_trees.html

Academic: Attack Trees - Schneier on Security

도출한 공격 목록은 문서(Document) 형태로 표현할 수도 있고 트리(Tree) 형태로도 표현할 수 있는데, 일반적으로는 트리형태로 한 눈에 보기 쉽게 작성한다. 공격을 목록화하여 작성하였을 때, 3.의 식별된 보안위협 결과와 매핑하여 표현해주면 더욱 좋다. 각각의 공격을 도출한 근거가 되기 때문이다.

 

여기서 의문점이 생길 수 있다. 3.에서 보안위협을 식별했는데 굳이 공격트리는 왜만들죠?? 어차피 위협이나 공격이나 똑같은거 아닌가?? 위협이 존재하기에 공격이 존재하는건데.

물론 나도 이 의문점에는 일부 동의한다. 그러나 결국 '보안위협'은 '공격'이라는 방법을 통해 발생할 수 있는 결과이다. '공격'을 당하지 않으면 '보안위협'도 발생하지 않는다. 아 물론, 자잘한 버그로 인해 발생하는 취약점을 제외한다면 말이다.

결국은 모든 공격을 식별하고, 이에 대한 대응 방안을 마련한다면 보안위협이 발생할 확률이 꽤 줄어든다는 얘기다.

 

5. 보안요구사항 도출: 발생 가능한 공격을 도출하였다면 그에 관한 보안요구사항을 작성할 수 있다. 공격이 구체적일수록 보안요구사항 또한 마찬가지로 구체적으로 작성될 수 있다. 보안요구사항을 작성하는 이유는 발생 가능한 '보안위협'을 최소화하기 위함이다. 1.부터 6.까지 모든 보안위협 식별, 분석 과정을 체계적으로 수행하고 대응한다 한들, 보안위협이 완전히 사라지진 않는다. 잠재적인 보안위협이 반드시 존재할 것이기 때문이다. 이 부분은 보안위협모델링을 적용한 체크리스트, 시큐어코딩으로는 해결할 수 없는 문제이다. 우리(보안 전문가들)는 보안위협을 최소화하기 위해 최대한 노력할 뿐이다. 

 

보안요구사항은 보안위협을 최소화하기 위해 필요한 요구사항을 작성한다. ~~한 공격을 막기 위해서는 취약한 함수(gets, strcpy 등)를 쓰지 말라든가. 특정 기능이 활성화되어야 한다던가. 시각 동기화(Time synchronization)가 적용되어야 있어야 한다던가. 각각의 공격에 대해 보안요구사항을 작성할 수 있겠다.

 

option. 공격의 난이도, 영향도에 따라 위협 우선순위 선정: 체크리스트 도출하는 과정에서 공격 대응 우선순위도 연구하면 참 좋겠지만, 우선순위 기준 잡기가 너무 어렵다. (Microsoft에서는 우선순위 선정을 위해 DREAD 평가 기법을 이용하였으나, 선정 기준이 너무 모호해서 2008년부터 DREAD 평가기법의 사용을 중단했다고 한다.)

관련 주소: web.archive.org/web/20160306170025/social.msdn.microsoft.com/Forums/en-US/c601e0ca-5f38-4a07-8a46-40e4adcbc293/do-you-use-dread-as-it-is?forum=sdlprocess

보통은 우선순위를 Scoring하여 선정한다. CWE(Common Weakness Enumeration)의 CWSS(Common Weakness Scoring System)을 이용할 수도 있고, 별도의 기준을 이용해 각 공격별로 Scoring할 수 있겠다.

우선순위를 왜 선정하느냐? (아마 제 생각엔) 일반적으로 자산의 위험관리(Risk Management)를 위해 위험을 수용(Acceptance)하거나 회피(Avoid)해야 할 경우가 생길텐데, 자산의 구성요소별 우선순위에 따라 위험을 수용하거나 회피하기 위해 각 공격별 우선순위를 선정한다. 예를 들어, A라는 공격이 자산에 끼치는 영향도가 낮은데, A를 막기 위해 지불해야하는 비용이 많다면 A라는 공격은 그냥 대응하지 않고 수용하는 게 기업 입장에서는 더 좋을 수도 있겠다.

 

6. 보안점검 체크리스트 작성: 마지막으로 이전 단계에서 도출한 보안요구사항을 만족할 수 있는 보안 체크리스트를 작성한다. 보안요구사항이 구체적으로 도출될수록 체크리스트 또한 구체적으로 작성할 수 있다. 체크리스트를 작성할 때는 여러가지를 고려하여야 한다.

 1. 체크리스트를 이용하는 모든 점검자가 동일한 결과를 도출할 수 있는가?

 2. 현실적으로 점검 가능한 체크리스트가 작성되었는가?

 3. 점검 대상(Target)과 관련한 모든 제품에 적용 가능한 체크리스트인지? 아니면 특정 대상에 한정한 체크리스트인지?

 4. 작성한 체크리스트를 이용해 점검할 시, 점검 대상의 알려진 모든 보안위협을 대응할 수 있는지?

 

위의 4가지 외에도 추가 고려사항이 있겠지만, 지금 떠오르는 건 딱 이정도이다.

 

최종적으로 도출된 보안 체크리스트를 이용하면 최소 알려진 모든 보안위협에 대해서 대응할 수 있다. 단, 기술적으로 대응하기 어려운 공격을 제외하고 말이다. 예를 들면 재밍 공격 등이 있겠다. 또한 잠재적인 취약점도 대응하기 어렵다. 체크리스트의 한계점이기도 하나, 사실 그 어떤 방법으로도 잠재적인 보안위협에 대해 완벽하게 대응할 수는 없을 것이다.

 

내가 생각하는 것 중에, 보안체크리스트를 만들어 관리하면 얻을 수 있는 큰? 장점이 있다. 바로 찔러보기식 해킹으로부터 안전해질 수 있다는 것이다. 특정 자산을 대상으로 정교하게 짜여진 해킹공격은 솔직히.. 기업 내 보안정책이 잘 세워지지 않았거나, 잘 세웠음에도 불구하고 잘 지켜지지 않는다면 막기 어렵다. 근데 정교하지도 않은 공격에 뚫리면.. 어떤 느낌일까? '이 기업 진짜 보안관리 하나도 안되어있네'. 이런 이미지부터 생각난다. 그리고 보통 해킹공격의 95%이상은 찔러보기식으로 이루어진다. 

 '알려진 보안위협으로는 대표적으로 이런 게 있고, 보통 이런 공격 이용하면 뚫리던데, 한번 공격해볼까???' 같은 해킹 초보자도 생각할 수 있는 해킹공격에 노출된 제품이 너무 많고, 실제로 이런 공격을 통해 해킹 피해가 발생하고 있다. 간단하게 예를 들어보면 CCTV 해킹이 있다. 아이디, 패스워드 설정이 안된 CCTV 제품의 디폴트 아이디, 패스워드를 인터넷 검색을 통해 획득한 후, 관리 페이지에서 해당 정보를 입력하면 CCTV에 접속되는 사례가 많은데, 이건 해킹을 모르는 일반인도 할 수 있다.

 

 

이것저것 쓰다보니까 글이 길어졌는데, 차근차근 작성한 내용보면서 다듬거나 수정해야겠다..