정보보호 위험관리 체계의 적용현실 및 대안
 
신수정/넷시큐어테크놀로지 컨설팅본부장(sjs1234@netsecuretech.com)
공학박사, CISSP, CISA, PMP
1. 서론
'위험관리'는 기업의 정보자산을 보호하기 위한 보안관리체계 수립의 핵심적인 요소로 이해되고 있다. 기업의 정보자산이란 그 자체가 가치가 있는 것이 아니라 그 정보자산이 기업의 미션과 사업을 수행하는데 있어 주요한 역할을 담당하기 때문에 가치가 있는 것이다.
그러므로 정보자산에 대한 '보안'은 단지 '정보자산'의 영역에 머물 수 없고 '사업' 의 영역과 연계되어 평가되고 대책이 설계되며 관리되어야 한다. 이러한 의미에서 '위험관리'가 정보보호체계의 핵심 프로세스이자 때로는 정보보호 체계의 전체적인 틀이라 해도 과장된 말은 아니다. 이로인해 '정보보호 프로젝트'는 때로 '위험관리 프로젝트'라고도 불리우기도 한다.

보안 체계 구축에 있어서 위험관리가 이렇게 중요한 위치를 차지하고 있고, 이에 따라 위험평가나 위험관리의 개념, 방법론 및 도구에 대한 많은 소개가 이루어져 왔다. 실제 '위협'이니 '취약성'이니 '위험'이니 하는 용어들은 이제는 보안 컨설턴트들 사이에서 뿐 아니라 기업의 보안 관리자들 사이에서도 아주 일반적으로 통용되는 용어가 되었다.

특히 정보보호관련 업체들은 컨설턴트들을 통해 기업들에게 위험평가나 위험관리에 대한 중요성을 강조하며, 컨설팅 방법론의 핵심요소로 위험평가나 관리를 위치시키고 다양한 방법론과 도구를 활용하여 기업들에게 개념과 실행을 전파하고 있다. 이에 부응하여 대형 기업들을 중심으로 많은 기업들이 컨설팅을 받으면서 이러한 평가, 관리 기법들을 어느 정도 수용하고 있다. 또한 학자들이나 연구자들은 위험분석이나 평가 분야에서 더욱 복잡하고 정교한 기법들을 지속적으로 제시하고 있다. 사실 이정도의 분위기라면 IT 보안위험평가나 관리는 아무런 문제가 없어 보인다.

그러나 진정한 현실은 어떠한가? 이러한 'IT 보안위험관리'가 국내의 대부분의 기업가운데 뿌리박혀 자연스럽게 실행되고 관리되고 있는가? 컨설팅 회사들의 위험평가나 관리의 방법론들이 대상기업에 적절히 이전되어 실행되고 있는가? 기업들이 위험관리 프레임웍을 보유하고 이를 적절히 운영하고 있는가? 이러한 질문에 대한 필자의 답변은 부정적이다. 물론 예외는 당연히 있으며 잘 수행하고 있는 기업들의 사례들이 충분히 있을 것이지만 필자의 개인적인 현장 경험에 의거할 때 그리 긍정적인 답을 할 수 없다는 것이 안타까운 현실이다.

그렇다면 그 이유는 무엇이며 이에 대한 극복방안은 무엇인가?
이에 대한 심층적인 답변은 위험평가나 관리 업무에 관련된 많은 당사자들이나 전문가들의 몫일 것이다. 단지 이 글에서는 간략한 핵심요소와 문제점 들을 짚어보고 이에 대한 개념적인 대응 방안을 고찰해 보려 한다. 이를 위해 먼저 위험관리의 기본적인 개념, 목적, 전형적인 단계 들에 대해 간략히 언급하고, 실행상의 문제점을 제시하며 마지막으로 간략한 제언을 하려한다.
세부적인 위험분석이나 관리 기법, 기업들의 세부적인 사례들은 이 글의 범위에서 다루지 않았다.
2. 위험관리 기본 개념과 목적
위험관리란 대략 위험을 정의하고, 분석하며, 대응하는 시스템적인 프로세스라고 정의할 수 있다. 위험관리를 채택하고자 하는 기본사상은 사실 단순 명확하다. '모든' 자산을 모두 열심으로 보호하려 하는 것은 비용효과적인 면에서 어리석은 일이고 끝이 없는 일일 수 밖에 없다. 결국 '중요한 자산'을 더 보호하고 신경쓰자는 것이다. 단지 '중요한'이라는 것을 어떻게 판단할까 하는 것이 아주 단순할 수도 있으나 의외로 아주 복잡할 수도 있을 뿐이다.

그렇다면 위험관리를 수행하는 목적은 무엇인가? NIST에서는 위험관리의 목적을 '단지 IT자산을 보호하는 것이 아니라 조직과 IT자산의 미션을 수행하는 조직의 능력을 보호하는것임' 이라고 설명하고 있다. 결국 위험관리란 정보자산자체의 영역이 아닌 조직과 사업의 영역이라는 것이고 이에 따라 위험관리는 IT자산을 관리하는 인력에 의해 이루어지는 기술적 기능이 아닌 기업 전체적인 관리기능으로 바라보아져야 한다는 것이다.

대부분의 투자에 대한 의사결정이란 투자했을 경우의 효과 대비 투자를 하지 않았을 경우의 위험에 대한 판단이며, 위험에 대한 대책비용 대비 위험에 대비하지 않았을 경우의 손실비용에 대한 판단이다. 결국 이러한 판단이 이루어지기 위해서는 위험에 기초한 관리는 필수적이라 할 수 밖에 없다. 특히 보안분야에서는 i) 완벽한 대책이라는 것이 존재할 수 없다는 이유와 ii) 완벽에 가까운 대책을 세우기 위해서 필요한 투자는 끝이 보이지 않는다는 비용 효과적인 이유와 iii)취약성 수준이라는 것을 어느 정도 판단할 수 있고 대책의 이행으로 인한 위험수준의 변화를 예측할 수 있다는 이유 등으로 인해 위험평가나 관리가 더더욱 필수적으로 요구되고 있는 상황이다.
그럼에도 불구하고 국내의 위험평가나 관리수준은 획기적으로 발전된 국내의 IT인프라의 수준을 따라가기에는 너무도 부족한 것이 현실이다.
 

3. '정보보호실행기준' 들의 비교
위험관리 프로세스에 대해서는 방법론마다 조금씩 차이는 있지만 일반적으로 5단계로 나눌경우
그림1과 같이 위험관리 계획수립-> 위험평가 -> 대책선정 및 대응계획수립 -> 이행 -> 모니터링 및 유지보수 의 단계를 취하고
그림1. 5단계 위험관리 프로세스->
   

　

3단계로 나눌경우 그림2와 같이 위험평가-> 대책선정 및 대응계획수립-> 이행, 모니터링 및 유지보수로 나눈다.
그림2 3단계 위험관리 프로세스->
 

사실 여기서 '위험평가'라는 단어는 상당히 유연성 있게 사용되는데 일반적으로 보안과 관련하여 자산정의-자산가치분석-위협평가-취약성평가-위험산정을 포함하며, 좁은 의미에서는 위험에 대한 정의와 위험분석을 포함한 개념으로, 조금 더 넓게는 계획수립까지 포함한 개념으로, 또 더 넓은 의미에서는 계획수립, 대책선정 및 대응계획수립까지 포함한 개념으로도 사용된다.
용어야 어찌되었든 결국 위험관리란 위험을 정의하고 평가해서, 산출된 위험의 레벨이나 금액에 근거해서 필요한 대안들을 분석하고 선택하여 최적의 이행 계획을 수립하고, 그 계획을 이행하고 모니터하며, 그 적절한 이행여부와 효과성, 변경 등을 관리하자는 것이다.

이들 위험관리 프로세스들 중 가장 기반이 되는 것은 당연히 '위험평가'일 수 밖에 없다. 적절한 위험평가가 이루어지지 않은 상태에서 이에 따른 후속 과정이 제대로 이루어질 수 없기 때문이다.
'위험평가'의 과정에서는 어떻게 객관적이고 효과적으로 자산 또는 업무의 보안위험을 분석하고 도출하느냐가 관건이므로 이에 대해 많은 기법들이 제시되고 있다.
일반적인 'IT 위험평가'와 마찬가지로 보안위험평가과정에서도 자산이나 업무에 대한 정확한 가치의 평가가 성공의 핵심요소이다. 단지 보안 분야의 경우 일반 IT위험평가와 차이가 있다면 '취약성 평가'의 과정이 상당히 강조되고 중요시되므로 이에 대한 부분의 적절한 평가도 상당히 큰 위치를 차지한다는 것이다. 그러나 취약성 평가는 상대적으로 평가를 수행하는 보안전문가들의 입장에서는 자산의 가치평가보다 쉬운 작업임에는 틀림없다.

위험을 평가한 이후에는 당연히 위험을 대응하는 전략을 수립하여야 하고 이에 따른 대책을 마련해야 한다. 위험대응전략은 위험의 회피, 위험의 전가, 위험의 완화, 위험의 수용 등이 존재한다. 대응전략에 대한 방안도 여러 각도에서 고찰할수 있는데, 이 중 NIST에서 제시하는 위험의 대응전략의 적용방안에 대한 예시는 그림 3과 같다.


<그림3 위험대응 행동도표>
그러나 위험평가와 위험대응전략 및 대책선택이 위험관리의 모든 것이 아니다. 대책선정이후 대책에 따른 이행계획, 이행계획의 이행, 관리, 재평가 등의 일련의 과정은 초기 위험평가 및 대책수립 과정 보다 훨씬 더 길고 지루하며 실제 지속적으로 관리하기 어려운 과정이다.
4. 위험관리 실행의 현실과 문제점
국내의 기업들의 IT나 IT보안환경을 분석하고 위험관리 프로젝트를 수행하면서 발견되는 현실적 상황과 문제점들은 다음과 같다.

첫째 가장 기본적으로 기업의 IT 위험관리 프레임웍이 존재하지 않고 이를 수립하는 것에 대한 최고 책임자의 인식이 부족하다는 것이다. 당연히 효과적이고 지속적인 위험관리 프로세스가 수행되기 위해서는 기업마다 위험관리를 위한 전반적인 정책, 절차, 기법, 책임, 조직이 존재해야 한다.
사실 IT 분야만 국한한다고 해도 위험관리는 꼭 보안에만 적용되지 않는다. 위험관리의 프레임웍은 대형 IT프로젝트를 관리하기 위해서도 필수적이고, 사업지속성 계획을 수립할 경우에도 필수적이다. 그러므로 기업은 꼭 보안뿐 아니라 다양한 IT의 위험관리를 위한 기본적인 프레임웍을 보유할 필요가 있음에도 불구하고 대부분은 전무하다고 할 수 있다. 또한 이러한 인식이 있는 책임자도 많지 않고, 이를 작업해내고 책임자들을 설득할 실무인력도 명확하지 않다. 이런 상황에서 지속적인 위험평가나 관리가 제대로 되기 어렵다.
이러한 프레임웍 설정이 내부적인 힘으로 어렵다면 외부 컨설턴트의 역할이 매우 중요할 수 있다. 그러나 문제는 대부분 기업이 위험관리의 프레임웍과 방법론 수립을 위해 별도의 컨설팅을 받기 보다는 보안컨설팅이나 BCP컨설팅 등을 받으면서 이에 따른 위험평가 프레임웍을 입수하는 경우가 많다. 이 경우 프로젝트 관리 컨설턴트, 보안 컨설턴트, BCP컨설턴트 들은 각기 자신들의 영역의 관점에서 위험을 분석하고 위험을 관리하는 기법이나 방법론을 제시하므로 기업들은 일부 영역에서 그러한 기법을 전수받기도 하나 여전히 IT전반적인 위험평가/관리의 체계는 보유하거나 활용하지 못하게 된다

둘째, IT 보안 위험관리를 'IT보안담당자'의 역할로 국한한다. 조금 더 나아간다면 'IT부서'의 역할로 정의한다. 그러나 전술했듯이 '위험관리'란 그것이 보안이던 IT자체이던 그 꼭대기는 사업과 미션이다. 그러므로 위험관리는 한 두 사람의 IT 전문가의 손에서 이루어지는 것이 아니고 이루어져서도 안된다. 그러나 대부분 여기에서 벗어나지 못하고 결국은 한 두 사람이 고생하다가 1회성으로 마치게 되거나 IT자산의 미시적인 평가에 그치게 되는 경우가 대부분이다.

세째 위험관리의 프로세스중 위험평가가 제대로 되지 않는다면 뒤에 따라오는 대응방안 수립 및 지속적인 관리등이 효과적으로 이루어질 수 없다. 그러나 현실적 문제는 이 위험분석평가 기법이 대부분 복잡하고 이를 통해 좋은 결과를 산출하지 못한다는 것이다.
이러한 원인은 다양하게 있을 수 있지만 몇 가지를 정리해보면

(1) 위험평가의 핵심적인 요소가 자산이나 업무의 가치를 제대로 측정하고, 객관적이고 틀리지 않는 데이터들을 도출하는 것이다. 그러나 지금은 많이 좋아졌지만 아직도 우리나라에서는 대부분의 인력들이 위험을 객관적으로 측정하는 훈련이 되어있지 않다.
그러므로 아무리 객관화 노력을 반영한 기법이나 방법론을 가지고 가도, 부서별로 또는 응답자별로 그 수준과 관점, 훈련도에 따라 그 결과는 천차만별이 되는 경우가 대부분이다. 심지어는 측정하는 컨설턴트의 경험과 지식에 따라서도 변화가 심해지는 경우가 많다.
이 경우 도리어 복잡하고 정교한 기법들을 가지고 갈수록 실패할 가능성은 더욱 커진다. 필자는 언젠가 어떤 컨설팅업체에서 어느 기업의 보안 위험평가를 위해 수십가지가 넘는 위협의 유형에 대해 그 강도와 빈도를 세부적으로 조사하고 수 많은 자산가치 측정요소를 가지고 모든 자산의 가치측정을 하려는 설문지를 본적이 있다.
예를들면 해킹이라는 위협이 발생하면 우리회사의 시스템에는, OS에는 몇 %의 손상을 가져오고, DB에는 또 얼마나, Application은 또 얼마나 손상을 가져올까요? 또 공기의 먼지라는 위협으로 문제가 생길경우 시스템에는 OS에는 DB에는 얼마나 손상을 가져올까요? 또 이러한 가능성은 몇 %정도 되나요? 라는 형식이다. 이러한 질문이 수백가지가 있다고 상상을 해보라. 과연 기업내에 누가 제대로 답을 할 수 있고, 또 이러한 설문지 결과를 통계한 결과치는 무슨 의미를 보여줄 것인가?

(2) 보안의 위험평가 프로젝트의 경우 IT부서의 인력, 또는 보안 전담인력들에게 그 수행의 책임과 역할이 주어질 경우가 많다. 이 경우 위험을 도출하고 위험을 측정하는 부분이 업무에까지 확장되지 못하고 IT 자산만의 Level에 그치는 경우가 많다.
예를들면 A라는 시스템의 진정한 가치를 도출하기 위해서는 A라는 시스템이 제공하는 서비스가 무엇이고 그 서비스의 문제발생시 업무적인 손실, 법적인 손실, 명성의 손실 등이 무엇인지 파악되어야 되는데 IT부서의 인력은 이러한 계산에 합당한 데이터를 줄 수 없다.
결국 업무 부서의 인력들로부터 정보들을 추출해야 하는데 프로젝트가 IT부서원만이 초점이 된 경우 이 부분에 대한 제대로된 피드백을 받는 것이 상당히 어렵다.

(3) 위험을 평가하는데 어려운 점은 연관성 부분이다. 최근의 IT환경은 독립된 환경이 단순하게 네트웍으로 연결된 것이 아니라 분산환경이다. 사실 모든 문제의 해결의 가장 쉬운 방법은 그 문제자체를 고립시키는 것이다. 그러나 그 문제가 고립되지 않고 수 많은 것들과 연결되는 경우 그 문제를 해결하기가 상당히 어렵다. 위험도 동일하다. 대상 자산이 고립되는 경우 그 자산에 대한 위험을 평가하는 것이 어렵지 않지만 여러 환경이 상호 협력하여 어떤 서비스를 이루어내는 경우 그 위험을 어떻게 분산시켜 분석할 지 어려운 부분이다.
그러나 또 문제는 이를 너무 정교하게 분산시키려 하면 도리어 더 좋지 않은 결과를 가져온다.

(4) 위험평가가 제대로 이루어지지 못하고 정착되지 못한데에는 컨설턴트의 잘못 또한 크다.
노련하지 않은 컨설턴트들이나 개발자들이 범하는 큰 실수중 하나는 정교하고 복잡할수록 무언가 더 정확하고 객관적일 것이라는 환상이다.
또 이러한 복잡성을 SW들이 잘 해결해 줄것이라는 환상 또한 가지고 있다. 그러나 복잡한 기법들을 수 많은 시간을 소요하면서 적용했지만 사실 업무를 아는 직원이라면 누구나 대략 알고 있는 감과도 동떨어진 형편없는 결과들을 산출할 경우가 많다.
또한 보안컨설턴트들이 '보안'의 전문가이지 '업무분석'의 전문가가 아닌 경우가 많으므로 대상 기업의 업무에 대한 이해없이 기계적인 작업으로 인해 제대로된 분석을 그르치는 경우가 많다. 이러한 과정과 결과를 보면서 기업의 담당자들은 당연히 위험분석이라는 것은 무진장 복잡한 작업이며 그럼에도 불구하고 답이 제대로 안나오는 작업이구나라고 생각하여 더 이상 체계적인 위험분석기법을 채택하게 되지 않게 되는 경우가 존재한다.
사실 많은 경우 위험평가결과가 수많은 문서들은 산출하나 실제 보안이행계획 수립시 거의 참고가 되지 않는 컨설팅과정중의 하나의 형식요소가 되어버렸다. 이러한 부분의 책임은 분명 보안 컨설팅 업체들이 느끼고 해결방안을 수립해야 할 부분이라는 생각이다.

(5) 위험의 평가방법에 대한 오해와 기업의 환경에 맞지 않는 잘못된 선택도 위험평가가 제대로 이루어지지 않는 결과를 가져오는데 일조를 한다.
예를 들면 흔히 정량적인 방법이 정성적인 방법보다 복잡하다고 하지만 반드시 그러한 것은 아니다. 또한 정량적인 방법이 정성적인 방법보다 더 정확하다고 하지만 반드시 그러한 것이 아니다.
기법에 따라 많은 차이가 있다. 예를들면 어떤 정성적인 기법은 너무 다양한 경우의 수를 고려하여 일반적인 정량적인 방법보다도 훨씬 더 복잡하면서도 결과적으로는 무의미한 Garbage들이 나타나게 되는 경우도 존재한다.

넷째, 결국 어렵게 위험분석을 수행하고, 이에 따른 대책을 세워 이행하고 관리하는 경우 앞의 분석과의 일관성이 존재하지 않는 경우가 대부분이다. 특히 이행은 잘하지만 그 이행이 원래 발견되었던 위험들을 어떻게 해소했는지에 대한 tracking이 제대로 되지 않고 있다.
결국 분석평가 따로 이행 따로 관리 따로인 경우가 많다. 또한 국내에서는 위험관리라 하면 위험분석이나 평가를 모든 것으로 생각하는 경우가 많다. 사실 위험분석이란 적절한 기법을 적용하고 경험이 풍부하고 숙달된 인력들이 작업을 한다면 도리어 짧은 기간내에 좋은 결과를 가져올 수도 있다. 그러나 그 뒤의 이행, 특히 모니터링과 통제는 지속적인 꾸준함과 끈기가 필요하다.
그러나 대부분 한 두번의 자체의 힘 또는 외부 컨설턴트들의 힘으로 분석작업이 완료된후 이행이 완료되면 더 이상 추적관리, 유지관리, 변경관리 등이 되지 않고 있는 경우가 많다. 결국 이 경우 실제 어떤 위험이 어떻게 포착되고 관리되고 소멸하는지 또한 이를 통해 결국 기업이 얼마만큼의 위험을 감소하고 어떠한 유익을 얻게되는지를 파악하지 못하게 되는것이다.
5. 위험관리 프로세스의 CSF와 최적화단계
위와 같은 현실과 문제점 속에서 위험관리를 제대로 수행하려면 어떻게 해야하는가? 이를 정리해 보기전에 먼저 위험평가 프로세스의 성공요소가 무엇인지 또 위험관리를 잘 한다는 것이 무엇인지 확인해보는 것은 의미있는 작업이다.
이러한 부분에 있어서 COBIT은 좋은 가이드라인을 제공해주고 있다. 위험평가를 IT의 중요한 Process로 정의한 COBIT에서 말하는 위험평가의 CSF를 검토해보면 다음의 표와 같다.

표1. 위험평가 프로세스의 핵심성공요소
핵심성공요소
· 위험관리의 소유권과 관리 책임소재에 대한 명확하게 정의된 역할과 책임이 있다
· 위험 한계와 위험 허용범위를 정의하기 위한 정책이 확립되어 있다
· 위험 평가는 취약성, 위협, 그리고 데이터의 가치를 연관시킴에 의해 수행된다
· 사고보고에 의해 제공되는 구조화된 위험 정보가 유지된다
· 위험관리 개선의 정의, 합의, 자금조달에 대한 책임과 절차가 존재한다
· 평가의 중점을 주로 실제 위험에 두며 이론적인 위험에는 적게 둔다.
· 위험의 식별과 완화를 도출하는 브레인스토밍 회의와 근본 원인 분석을 정기적으로 수행한다
· 전략의 현실성 검사는 객관성을 증가시키기 위해 제삼자가 수행하며 적절한 시기에 반복된다

또한 COBIT에서 제시하는 위험평가 프로세스의 성숙도 모델의 최적단계는 다음과 같다.

표2. 위험평가 프로세스의 최적화 단계
Level 5 최적화(Optimised)단계
· 위험 평가는 구조화되고, 조직 전반에 걸친 프로세스로서 시행되고, 주기적으로 유지보수되고, 잘 관리되는 단계까지 발전하였다.
전문가가 참여하는 위험 브레인스토밍과 근본 원인 분석이 조직 전체에 걸쳐서 적용된다.
위험 관리 데이터의 포착, 분석 및 보고는 고도로 자동화 되어 있다.
지침이 현장의 리더로부터 얻어지며, IT 조직은 동료 그룹에 참여하여 경험을 교환한다.
위험 관리는 모든 사업과 IT 운영에 진정으로 통합되고, 잘 수용되며 광범위하게 IT 서비스의
사용자를 참여시킨다.

물론 위의 프로세스가 보안에 국한된 것은 아니지만 위험관리가 제대로 된다는 것이 '조직 전반', '실제 위험', '책임과 역할', '참여', '주기적 유지보수' 등과 관계있음을 쉽게 깨달을 수 있다.
 
6. 더 나은 방향을 위해

사실 위에 구구절절 제시된 문제점 속에서 벌써 답이 숨어있음은 독자들이 쉽게 예상할 수 있다.
구지 요약하자면 다음과 같다.

첫째 기업에서는 전사적으로 통용될 수 있는 IT위험관리 프레임웍을 채택하여야 한다. 그리고 이 프레임웍은 반드시 교육하고 전파하여야 한다. 외부 컨설턴트들은 기업이 이러한 체계를 갖추도록, 현실적이고 적용가능한 정책과 프로세스와 기법들을 기업들에 제시를 해야하고, 주요 책임자와 경영층에게 그 중요성을 부각시켜 그 체계를 수립하고 지속적으로 적용해 나갈 수 있도록 설득해야 한다.

둘째 위험평가를 위한 업무부서와 IT부서가 결합된 효과적인 조직이 구성될 필요가 있다. 이 조직이 구지 별도의 조직일 필요는 없다. 그러나 대형 기업일수록 더더욱 필수적이다. 그러나 보안위험평가 및 관리만을 위한 조직구성은 현실적으로 불가능 할것이고 전사적인 IT위험관리의 프레임웍을 유지하고 적용하는 관점에서 구성되는 것이 현실적일 것이다.

세째 내부적으로 위험에 대한 측정이 훈련되지 않았다면 위험평가를 위해서 가능한 단순한 방법을 채택하는 것이 필요하다. 처음에는 가장 단순해보이는 정성적 방법을 채택해야 한다. 이 경우 위험을 평가하기 위해 필요한 양식을 서너 가지로 최소화하는 것이 필요하다.
이를 통해 위험을 측정해보고 객관화해보고 정량해 보는 훈련을 조금씩 수행하여 어느정도 적응이 된다면 조금 더 복잡한 측정방법을 채택하는 것이 바람직하다. 처음부터 복잡하고 정교한 방법을 선택하거나 무조건 툴을 구입하는 것은 파산의 지름길이다. 위험평가는 처음에는 거시적에서 미시적으로 접근하고 시간이 지날수록 미시적에서 거시적을 혼합하는 것이 효과적이다.

네째 위험평가의 프로세스의 효과성에 대해서 측정이 필요하다. 위험평가를 통해 얼마나 위험들이 감소되었는지 측정이 필요하다. 이를 통해 위험평가의 유효성을 더욱 제시할 수 있다. 이는 위험평가의 결과와 위험의 사후관리와의 연계를 통해 위험요소의 생명주기를 tracking함으로써 수행할 수 있다. 또한 대책 이행의 우선순위도 적절히 선택하며, 이로 인해 기업의 전반적인 보안위험이 어떻게 감소하는지 시뮬레이션 하고 실행의 결과와 비교해볼 필요가 있다.
사실 위험평가 도구는 많이 나와있지만 위험요소의 생명주기 tracking 도구는 제대로 만들어지지 않은 실정이다. 그러나 tracking은 대상 범위를 어느정도 축소한다면 Excel작업이나 약간의 프로그래밍으로 할 수 있을 만큼 의외로 복잡하지 않다. 여기에서는 지면관계상 세부내용은 생략한다.

다섯째 위험에 대한 평가의 지식을 축적하고 특히 동종기업들은 이를 공유함으로써 효율을 높여야 한다. 실제 위협분석의 경우 동종기업들의 경우 거의 차이가 없는 경우가 많다. 이 경우 동일한 수고를 각 기업들에서 별도로 할 이유가 없다.
결국 복잡하게 연계되어 있는 거대기업의 IT위험을 제대로 평가하고 관리한다는 작업이 쉬운 일이 아니지만 단계별로 차근히 풀어나간다면 의외로 상당한 효과를 거둘 수 있다. 그러므로 조급하게 서두르지말고 관련된 당사자들이 상호협력과 강한의지를 가지고, 위험관리 과정을 지속적으로 추진한다면 위험관리체계가 각각의 기업내에 자연스럽게 정착될 수 있을 것이다.

[참고문헌]
BSI, Information security management Part 2, 1999
DISC, PD3002 Guide to Risk Assessment and Risk Management, 1998
GAO, Information security risk assessment practices of leading organization, 1999
ISACA, COBIT 3rd Edition Management Guidelines, 2000
NSW, Information security guideline for NSW Government Agencies, 2001
NIST, Risk Management guide for Information Technology Systems, 2001

 

　

Copyright © 2001