시스템 보안 아키텍처, 그게 뭐고 왜 필요하나요?

"APT 공격 또는 랜섬웨어가 내부에서 발견되었다". 그럼 어떻게 대응해야 할까? 보통 실무자들은 해당 보안 공격이 뭔지를 공부한다. 그런 다음 해당 공격을 방어할 수 있는 솔루션을 검색해서 구매한다. 심플!  이것이 보통의 기업에서 하는 절차이다. 

현재 달봉이가 근무하는 곳에서도 보안이 이슈다. 이곳에서도 이것과 유사한 절차로 외부 보안 공격, 위협에 대응하고 있다. 보안 담당자들이 여러명 있다. 근데 모두는 솔루션별로 지정되어 있다. 바이러스 공격 솔루션 담당자, 네트워크 접근 제어 솔루션 담당자, 노트북 제어 솔루션 담당자 등. 보안을 전체적으로 통제하고 관리할 수 있는 소위 큰 그림을 만들어야 하는 역할이 없다. 대증 치료적인 관점에서의 대응만이 이뤄지고 있다.

좀만 더 생각해보면 이런 방법의 헛점이 보인다. 보안에는 여러 차원의 조치들이 있다. 보안을 조금이라도 공부해보면 "CIA"라는 약어에 접하게 된다. "Confidentiality, Integrity, Availability"를 말한다. 보안은 기본적으로 이 3개의 차원에서 검토해서 차원별로 조치를 취해야 한다는 것이다. 그러나 현실에서는 이것보다 더 상세한 차원의 검토가 필요하다. 아래서 알아볼 ITU-T에서는 다음과 같은 8가지 차원에서 검토할 것을 권고하고 있다: "Access Control, Authentication, Non-repudiation, Data confidentiality, Communication security, Data integrity, availability, Privacy". 

말하고 싶은 것은 모든 솔루션은 이 모든 차원의 목표를 모두 지원해주는 것은 아니다. 각 보안 솔루션들은 이 중에서 몇 개의 차원에서 달성하고자 하는 목표만을 구현한다. 전사적인 관점에서의 뷰를 갖지 않고 솔루션들을 도입하게 되면, 전사적으로 봤을때 너무 과하게 방어를 하는 차원도 있을 거고, 어떤 차원의 목표는 달성되지 못할 수도 있다. 즉 "중복되거나 빠지는 부분이 생기게 되는 것이다"

공격이나 위협별로 대응할 수 있는 솔루션들을 곧바로 구매하는 절차를 수정할 필요가 있다. 그럼 어떻게? 

우선 기업의 원칙과 정책을 제공해줄 수 있는 "일반적인 보안 아키텍처와 보안 목표"가 정의되어야 한다. 그런 다음 그것을 참조해서 "기업의 환경에 맞는 보안 목표"가 정의되어야 하고, 그 목표에 맞는 솔루션들이 선택되어저야 한다는 것이다. 즉 전사 차원에서 Top-down 방식의 시스템 보안에 대한 큰 그림이 제일 우선적으로 있어야 "중복되지 않고, 빠지지 않는" 대책이 적용될 수 있다는 것이다. 

■ Security architecture for end-to-end security

본인이 ITU-T의 권고사항 시리즈중에서 X.805 문서를 봤을때 "이거다!! 예에~~"를 외쳤다. 보안 대응 조치에 대해서 완벽한, 정말 그동안 고민해왔던 것을 완벽히 커버해주는 모든 관점의 뷰를 보여주고 있었다. 문서에서 보여주는 보안 아키텍처의 최종적인 그림을 먼저 보면 다음과 같다. 

제일 좌측에는 시스템이 가지고 있을 수 있는 취약점을 나타내는 화살표가 있고, 이런 취약점에 대해서 외부의 공격과 위협에 대한 유형을 제일 오른쪽에 보여주고 있다. 

• 그림에서 보여주는 보안 아키텍처에서는 외부 공격에 대응해서 취할 수 있는 보안 조치를 8가지 차원으로 표시하고 있다. 즉 외부 공격에 대해서 Access Control부터 Privacy까지의 대응 조치가 필요하다는 것이다. 
• 8가지 차원의 보안 조치는 3개의 보안 레이어별로 즉 Application레이어, Services 레이어, Infrastructure레이어별로 검토, 적용되어야 한다는 것을 보여주고 있다. 
• 이런 3개의 보안 레이어는 다시 3개의 보안 측면 즉 End-user, Control, Management 별로 구분해서 검토, 적용될 수 있다는 것이다. 

요약하면 외부의 보안 공격에 대해서 8 security dimensions, 3 security layers, 3 security planes의 조합으로 "중복되지 않고, 빠지지 않을 수 있는" 보안 뷰를 가질 수 있다는 것이다. 

■ security architecture in a tabular form

앞의 보안 요소들을 조합하면 외부의 공격에 대해서 가능한 보안 조치들에 대한 전체적인 뷰를 모두 그려볼 수 있다. 다음은 앞에서의 end-to-end 관점의 아키텍처를 테이블 형태의 아키텍처로 보여주는 그림이다.

예를 들어, Module one의 상세 내용은 Management plane의 Infrastructure layer에서 8가지 security dimensions별로 어떻게 조치를 취해야 하는지를 표현하면 된다. 위 아키텍처대로 라면 72개의 셀이 만들어진다(8 security dimensions X 3 security layers X 3 security planes ). 

링크의 X.805 권고 문서에는 각 Module의 각 셀에서 어떤 내용을 검토해야 하는지를 정리해 주고 있다. 예를 들어 "Table 2/X.805-Applying security dimensions to the infrastructure layer, management plane" 테이블에서는 Management plane의 Infrastructure layer에서 8가지 security dimensions별로 어떤 조치를 취해야 하는지에 대한 보안 목표를 설명해주고 있다. 

ITU-T의 권장 문서에는 이런 보안 목표들이 모든 Module에 대해서 설명되어 있다. 

■ 기업 적용

각 기업에서는 이런 매트릭스를 가지고 각자의 Module별 security dimension의 목표를 달성하기 위해서 실제적인 조치를 취해나가야 한다. 물론 모든 Module의 모든 셀을 한꺼번에 적용할 수 있는 없을 것이다. 돈 문제도 있고, 인력 문제도 있고. 우선 순위에 맞게 시급한 부분부터 차례로 적용하면 될 것이다. 

이제 처음 얘기로 돌아가서...솔루션을 도입하더라도 어떤 Module의 어떤 dimension을 담당시킬 목적으로 구입하는 건지를 미리 정하고 도입하자는 것이다. 그래야 투자가 중복되거나 또는 빠질  가능성이 적어진다는 것이다. 솔루션 벤더들은 보안 매트릭스의 일부의 dimension만을 타겟으로 해서 제품을 제작한다는 것을 알자. 여러 기능이 있는 것도 좋을 수 있지만, 특정 차원의 보안을 전문으로 하는 솔루션들을 구입하는 것이 적당할 수도 있다. 솔루션을 도입하는 기업에서는 이런 면들을 검토해야 하는 것이다. 

----------------

ITU-T 권장 시리즈 : http://www.itu.int/itu-t/recommendations/index.aspx?ser=X

X.805 권장 문서 :  

X.805 Security architecture for systems providing end-to-end communications.pdf