개발 아키텍처 설계를 위한 보안 위협 모델링
하마터면 보안만 짚을 뻔했다.
정보 과잉 시대에 살고 있다 보니, 뭐든지 많이 알아놓는 게 쓸모 있으련만 인간의 생애는 한정되어 있다. 이 한정된 시간 속에 잉여가 아닌, 유의미한 정보를 생산하고 추출할 줄 알아야 하는 게 정보산업계에 종사하는 사람들의 사명이다. 하마터면 보안 아키텍트가 최종 지향점임에도 불구하고 개발 아키텍트의 역량 탐색에 매달릴 뻔했다. 도메인 주도 설계(DDD)라는 소프트웨어 아키텍트와 관련된 개념은 보안 아키텍트가 알아야 할 용어의 교차점이 존재하기는 하나, 보안 전문가의 기업에서의 역할은 고객에게 안전한 가치를 제공하기 위한 보안 위협과 공격자의 침해 시도 분석 및 대응 등의 일련의 활동(governance)을 수행하는 것이다.
소프트웨어나 보안 아키텍트와 달리 해당 프로젝트 분야(Domain)의 전문가를 일컫는 도메인 전문가는 비즈니스가 동작하는 방법에 대한 비전('개발 수익'에 중점을 둘 수 있는 사업적 수완)을 두어야 하며, 이 DDD(Domain-Driven Design)를 사용하는 까닭은 수행하는 프로젝트의 기술적인 측면의 복잡도보다 비즈니스 모델의 복잡도가 더 높기 때문이다. 그래서 각각의 역할에 대한 경계를 확실하게 해서 큰 그림(Scrum)을 쉽게 볼 수 있게 하기 위함이다. 개발자들이 보통 고객과 대화를 나누면 고객의 요구사항이나 조건에 대해서 기술 중심적으로 답변하면서 회피하기 마련이다(2016, Vernon). 이것을 '간결성 회피'라고 '도메인 주도 설계 핵심'이라는 책에 번역되어 있는데, 본인이 국내 ATM 제조 1위 업체에서 설계직으로 근무할 당시, 고객이 아닌 사장이라도 자잘한 것에 대한 설계변경을 요청하면 회피성이 아니라 마음속으로는 거부반응부터 먹게 된다. 왜냐하면, 실제로 설계를 애초에 처음부터 직접 하면 모르겠는데, 중간에 변경을 요청하면 이래 저래 BOM(Bill of Material) 구성부터 시작해서 구매품의까지 거쳐야 할 과정이 산적하기 때문이다.
그런데 이 도메인 주도 설계의 주도권을 쥐어야 할 IT 개발 프로젝트의 도메인 전문가는 어떤 것이든 개발자의 의견이 근거가 있는 것인지 따져서 '기술 중심의 주장'을 무조건 수용하지 않아야 한다고 한다. 개발팀이 점진적으로 개발하는 해당 팀의 안에 보편 언어(기술 중심('Bound Context')의 바깥에 있는 공통적으로 알아듣고 기술과 비즈니스 분야 모두 혼용 가능한 개념)를 또한 수용할 수 있게끔 유도하고 설득해야 한다. 그러니 이 도메인 전문가도 제품 책임자나 프로젝트 리더(PL)와 마찬가지로 개발 경력이 어느 정도 충족되어야 현업의 개발자들과 대화가 될 것이고 개발자들로부터 공감을 이끌어낼 수 있을 수밖에 없다. 어쨌든 비즈니스 모델의 복잡도가 높기 때문에 개발자는 이 도메인 전문가와 함께 비즈니스 모델을 파고들어야 한다는 '도메인 주도 설계의 핵심'의 2장까지의 내용을 보고 필자는 이번 섹션의 소제목처럼 산 하나 더 만들 뻔했다는 것을 깨달았다.
기업과 제품의 보안에 있어서 전문가가 되고자 함에 있어서는 비즈니스 측면에서의 복잡도보다는 신경 써야 할 부분은 따로 있다. 하지만 도메인 전문가의 역할에 대한 뼈만 발라내면(연역적 추론), 보안 아키텍트의 역할 또한 쉽게 결론 낼 수 있다. 앞서 섹션 #9에서 개발자의 우선순위는 한정된 프로젝트 기간 내에 임무(제품 출시)를 완수해야 하고 또한 대개의 경우 주어진 기간은 그리 길지 않다고 언급했다. 보안은 주어진 임무 중 상대적으로 중요도가 낮기 때문에 뒤로 밀려나고, 보안에 신경을 쓰고 싶어도 쓸 시간적 여유가 없는 상황이 대부분인 개발자들과 소통하기 위해서는 보안 전문가라면 역시 개발자의 경력이 있으면 상대의 입장에서 지금 무엇이 가장 필요한 지 알 수 있을 것이다. 또한 개발자의 업무 중 우선순위가 가장 높은 일은 '보안성 확보'가 아니라, 애플리케이션의 기능 구현과 로직 개발이기 때문에 그들에게 보안성 확보를 위한 설득이 요긴할 수도 있다.
어쨌든 본인은 향후 섹션에서 도메인 주도 설계에 따른 개발도 아닌, 애플리케이션 단의 취약점 분석도 아닌 아래와 같은 스크럼(프로젝트 관리를 위한 점진적 개발 방법)으로 개인 프로젝트를 계속 진행해서 침해 모델(Threat Model)을 산출하려고 한다.
프로젝트 목적 : 가상의 침해사고의 모델링을 통해 보안과 관련된 이벤트 사이의 상관관계를 정의하고 침해사고 예방을 위한 보안 아키텍처('Security Architecture') 설계
주요 내용 :
1) 가상의 공격 시나리오로 시스템 로그분석 기반의 데이터를 통해 공격 식별 핵심 요소(key- factor)를 도출한 일반적인 침해사고(Threat) 모델링.
2) 이 모델을 바탕으로 해서 공격 피해로 인한 법적 손해배상 비용(보험료)과 복구비용 대비 투자비를 산출해서 비교한 수치 데이터로 최대 이익(비용 편익)의 보안 비즈니스 모델 수립하기
사용한 기술력(언어 및 소프트웨어와 참조 서적)
1) 파이썬 : 로그 증적 자동화 툴(쉘 스크립트) 코딩
2) 파이토치(pytorch) 및 텐서플로(Tensorflow) : 추출한 로그 데이터의 분석 및 모델링
3) Cybersecurity Law by Jeff KosseffPublished by Wiley, 2017 : 로그분석 기반의 공격자 활동 추적 공격 시도 탐지 및 대응을 위한 IOC(Indicator Of Compromise, 디지털 포렌식(하드웨어나 디지털 기기의 복구를 위한 기술) 과정 간에 보안 침해와 관련된 지표) 기준 수립(보안 아키텍처)을 위한 참조 e-book
4) 보안 경제학(CEO를 위한 정보 보안 투자 가이드. 서승우 저)
스프린트(반복 주기) 기간 : 2주
최종 데드라인 : 2021. 04. 25.
후속 프로젝트 계획 : 악성코드(Malware) 및 기타 사고(Incident) 대응 관련 데이터 분석 및 포렌식 시도
아래는 위키피디아에서 발췌한 Visual representations based on data flow diagrams의 한 예이다. 어느 온라인 뱅킹 애플리케이션의 데이터 흐름을 보여주는 시각적 플로우이다.
Visual representations based on data flow diagrams본인이 계획한 프로젝트를 구체화하기 위해서는 일단 네트워크의 경계로 보이는 빨간 점선의 구간(Node) 사이에서 오고 가는 증적(향후 침해사고 발생 시 법적 대응 자료로 사용하기 위한 로그)을 수집해서 특이한 트래픽(Outlier)을 분석하여 공격으로 식별한 한 가상의 공격 시나리오를 모델링한다. 그리고 연역적 추론을 통해 보안 이벤트 사이의 상관관계를 정의하고 이러한 관계 중 정말 공격에 해당할 수 있는 인과 관계성의 침해사고 가능성을 통계적 수치로 도출해서 이 데이터셋을 기반으로 최적화한 보안 투자비용을 산정하는 게 이번 프로젝트의 목표다.
참조
Vernon, V(박현철, 전장호 역). (2016). 도메인 주도 설계 핵심(원제 : Domain-Driven Design Distilled). Pearson Technology Group Canada.
