정보시스템 보안위험관리 현실과

더 나은 방향을 위한 제언

 

신수정(CISA, CISSP, 공학박사)

넷시큐어테크놀로지 이사

 

서 서론

 

정보시스템의 위험평가나 위험관리라는 용어는 현재 IT업계나 기업의 IT부서에서 상당히 대중적으로 사용되고 있다. 보안분야에도 예외가 아니어서 위협이니 취약성이니 위험이니 하는 용어들은 컨설턴트들 사이에서 뿐 아니라 기업의 보안 관리자들 사이에서도 아주 일반적으로 통용되는 용어가 되었다. IT관련 또는 정보보호관련 글들 사이에서 위험평가위험관리니 하는 주제들은 아주 쉽게 찾을 수 있다.

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

그러나 진정한 현실은 어떠한가? 과연 다른 분야는 별개로 하고 보안분야만을 보았을 때 이러한 IT 보안위험관리가 국내의 대부분의 기업가운데 뿌리박혀 자연스럽게 실행되고 관리되고 있는가? 컨설팅 회사들의 위험평가나 관리의 방법론들이 대상기업에 적절히 이전되어 실행되고 있는가? 기업들이 위험관리 프레임웍을 보유하고 이를 적절히 운영하고 있는가? 이러한 질문에 대한 필자의 답변은 No라는 것이다. 물론 필자가 국내의 모든 기업들을 Survey해본것도 아니고, 특히 앞서나가는 기업들을 모두 검토해본 것도 아니라 이런 단언을 하는 것이 합당하지 않다고도 할 수 있지만, 최소 40 여개이상의 대형 기업을 분석해본 경험에 의거하여 볼 때 다른 기업도 예외는 분명있지만 크게 다르지 않을 것이라는 것이 기본적인 생각이다.

그렇다면 그 이유는 무엇이며 이에 대한 극복방안은 무엇인가? 이에 대한 심층적인 답변은 위험평가나 관리 업무에 관련된 많은 당사자들이나 전문가들의 몫일 것이다. 단지 이 글에서는 실제 여러 기업의 분석과 컨설팅 경험을 토대로 간략한 핵심요소와 문제점 들을 잡아보고 이에 대한 개념적인 대응 방안을 제시해 보려 한다. 이를 위해 먼저 위험관리의 기본적인 개념, 전형적인 단계 들에 대해 간략히 언급하고, 실행상의 문제점을 제시하며 마지막으로 간략한 제언을 하려한다. 세부적인 위험분석이나 관리 기법, 기업들의 세부적인 사례들은 이 글의 범위에서 다루지 않았다.

 

위험관리 기본 사상

위험관리란 대략 위험을 정의하고, 분석하며, 대응하는 시스템적인 프로세스라고 정의할 수 있다. 위험관리를 채택하고자 하는 기본사상은 사실 단순 명확하다. 이는 최근 유행하고 있는 CRM(Customer Relationship Management)과 비슷한 맥락이라 볼 수 있다. 즉 과거 기업들은 모든 고객들에게 거의 동일한 서비스를 제공해왔다. 그러나 세부적인 분석을 해보니 기업에게 많은 이익을 가져다 주는 고객군은 상당히 한정되어 있음을 알게되었다. 10원의 이익을 주는 고객과 1억의 이익을 주는 고객이 분명히 존재하는데 불행하게도 과거에는 두 부류의 고객에 대해서 동일하게 promotion하고 동일하게 관리했다는 것이다. 그러나 실제 1억의 이익을 주는 고객이 이탈하는 경우의 충격과 10원의 이익을 주는 고객이 이탈하는 경우의 충격은 결코 동일할 수 없으므로, 이제부터는 전자의 고객에게 더 집중하고 더 관심있게 관리하므로써 이탈을 방지하고 충성고객으로서 유지 발전시켜 지속적인 이윤창출을 도모하자는 것이다.

결국 IT 위험관리라는 것도 마찬가지 이다. 예를들면 비슷한 가격의 비슷한 환경을 가진 두 개의 IT 시스템이 존재한다. 대부분 이런 경우 전산실에 있는 사람은 이 두 자산에 대해 거의 비슷한 노력과 비슷한 투자로 관리한다. 그러나 이중 한  IT자산은 문제발생시 기업에 치명적인 손실을 가져오지만 다른 IT자산은 그렇지 않을 수 있다. 이 경우 어떻게 관리를 하는 것이 효과적인가는 자명한 문제이다. 결국 위험이 더 큰 자산에 더 힘을 집중하자는 것이 위험관리의 기본 사상이다. 사상은 단순하고 누구나 쉽게 이 사상을 적용할 수 있을 것 같으나 여러 다양한 이유로 인해 실제의 적용은 예상외로 쉽지 않다.

사실 국내에서 위험관리, 특히 IT분야에서의 위험관리라는 부분이 기업현장에서 본격적으로 논의되기 시작한 계기는 Y2K 프로젝트들 때문이라 할 수 있다. 그 당시 국내의 대부분들의 기업들은 Y2K 과제를 코드레벨에서의 미시적인 변환과제로 접근한 반면, 외국사들을 중심으로 한 컨설팅업체들은 Y2K프로젝트를 거시적인 위험관리 과제로 보았다. 즉 그들의 주장은 Y2K의 변환 프로젝트에 앞서 Y2K문제로 인한 사업 위험들을 분석해보고 이러한 위험에 따라 대응전략과 계획을 달리해야 한다는 것이었다. 즉 위험이 큰 영역에서는 우선순위를 높이고 변환의 노력과 투자를 기울이지만 위험이 크지 않은 영역에 대해서는 그럴 이유가 없다는 것이다.

그러나 여전히 국내의 대부분의 기업들은 위험에 기초한 접근방식을 택하기 보다는 All or nothing식, 또는 조금 더 전문적인 용어를 쓰자면  baseline접근식의 접근을 수행했다. 즉 모든 것을 무조건 정해진 시간내에 수행을 하자는 개념이었다. 그럼에도 불구하고 IT 위험관리라는 접근법이 특히 대형기업을 중심으로 많이 파급 되었고 또 약간의 기업들은 이러한 접근법들을 수용하여 적용하기도 했다.

Y2K와 맞물려 IT 인프라에 대한 투자가 더 가속화되었고, 이제 IT가 기업에 광범위한 위치를 점유하게 되었을 뿐 아니라 기업의 생존과 발전에 필수적인 수단이 되었다. 반면에 IT 투자비용과 이행의 난이도도 더욱 가속 상승하여 IT 투자에 대한 적절한 의사결정 자체가 어렵게 되었다. 이러한 상황에서 이제는 무조건적인 All or nothing식의 접근법은 통하기 어려워졌다. 대부분의 Business의 의사결정이란 투자했을 경우의 효과 대비 투자를 하지 않았을 경우의 위험에 대한 판단이며, 위험에 대한 대책비용 대비 위험에 대비하지 않았을 경우의 손실비용에 대한 판단이다. 결국 이러한 판단이 이루어지기 위해서는 위험에 기초한 관리는 이제 필수적이라 할 수 밖에 없다. 특히 보안분야에서는 완벽한 대책이라는 것이 존재할 수 없고, 완벽에 가까운 대책을 세우기 위해서 필요한 투자는 끝이 보이지 않는다는 비용효과적인 이유와 취약성 수준이라는 것을 어느 정도 명확하게 판단할 수 있고 대책의 이행으로 인한 위험수준의 변화를 예측할 수 있다는 이유 등으로 인해 위험평가나 관리가 더더욱 필수적으로 요구되고 있는 상황이다.

 

위험관리 단계

위험관리 프로세스에 대해서는 방법론마다 조금씩 차이는 있지만 일반적으로 5단계로 나눌경우

(1) 위험관리 계획수립-> 위험평가 -> 대책선정 및 대응계획수립 -> 이행 -> 모니터링 및 유지보수

의 단계를 취하고

 

3단계로 나눌경우

(2) 위험평가-> 대책선정 및 대응계획수립-> 이행, 모니터링 및 유지보수 또는

(3) 위험평가-> 이행-> 모니터링 및 유지보수

로 나눈다.

 

사실 여기서 위험평가라는 단어는 상당히 유연성 있게 사용되는데 일반적으로 보안과 관련하여 자산정의-자산가치분석-위협평가-취약성평가-위험산정을 포함하며, 좁은 의미에서는 위험에 대한 정의와 위험분석을 포함한 개념으로, 조금 더 넓게는 (2)와 같이 계획수립까지 포함한 개념으로, 또 더 넓은 의미에서는 (3)과 같이 계획수립, 대책선정 및  대응계획수립까지 포함한 개념으로도 사용된다.

용어야 어찌되었든 결국 위험관리란 위험을 정의하고 평가해서, 산출된 위험의 레벨이나 금액에 근거해서 필요한 대안들을 분석하고 선택하여 최적의 이행 계획을 수립하고, 그 계획을 이행하고 모니터하며, 그 적절한 이행여부와 효과성, 변경 등을 관리하자는 것이다.

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

그러나 위험평가가 중요하다지만 당연히 위험평가가 위험관리의 모든 것이 아니다. 평가이후 위험의 레벨 또는 위험의 경중에 따른 적절한 대책의 선택, 대책에 따른 이행계획, 이행계획의 이행, 관리 등의 일련의 과정은 위험평가과정 보다 훨씬 더 길고 지루하며 관리하기 어려운 과정이다.

 

위험관리 실행의 현실과 문제점

국내의 기업들의 IT나 IT보안환경을 분석하고 위험관리 프로젝트를 수행하면서 발견되는 현실적 상황과 문제점들은 다음과 같다.

첫째 가장 기본적으로 기업의 IT 위험관리 프레임웍이 존재하지 않고 이를 수립하는 것에 대한 최고 책임자의 인식이 부족하다는 것이다. 당연히 효과적이고 지속적인 위험관리 프로세스가 수행되기 위해서는 기업마다 위험관리를 위한 전반적인 정책, 절차, 기법, 책임이 존재해야 한다. 사실 IT 분야만 국한한다고 해도 위험관리는 꼭 보안에만 적용되지 않는다. 위험관리의 프레임웍은 대형 IT프로젝트를 관리하기 위해서도 필수적이고, 사업지속성 계획을 수립할 경우에도 필수적이다. 그러므로 기업은 꼭 보안뿐 아니라 다양한 IT의 위험관리를 위한 기본적인 프레임웍을 보유할 필요가 있음에도 불구하고 대부분은 전무하다고 할 수 있다. 또한 이러한 인식이 있는 책임자도 많지 않고, 이를 작업해내고 책임자들을 설득할 실무인력도 명확하지 않다. 이런 상황에서 지속적인 위험평가나 관리가 제대로 되기 어렵다.

이러한 프레임웍 설정이 내부적인 힘으로 어렵다면 외부 컨설턴트의 역할이 매우 중요할 수 있다. 그러나 문제는 대부분 기업이 위험관리의 프레임웍과 방법론 수립을 위해 별도의 컨설팅을 받기 보다는 보안컨설팅이나 BCP컨설팅 등을 받으면서 이에 따른 위험평가 프레임웍을 입수하는 경우가 많다. 이 경우  프로젝트 관리 컨설턴트, 보안 컨설턴트, BCP컨설턴트 들은 각기 자신들의 영역의 관점에서 위험을 분석하고 위험을 관리하는 기법이나 방법론을 제시하므로 기업들은 일부 영역에서 그러한 기법을 전수받기도 하나 여전히 IT전반적인 위험평가/관리의 체계는 보유하거나 활용하지 못하게 된다

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

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

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

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

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

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

 

셋째, 결국 어렵게 위험분석을 수행하고, 이에 따른 대책을 세워 이행하고 관리하는 경우 앞의 분석과의 일관성이 존재하지 않는 경우가 대부분이다. 특히 이행은 잘하지만 그 이행이 원래 발견되었던 위험들을 어떻게 해소했는지에 대한 tracking이 제대로 되지 않고 있다. 결국 분석평가 따로 이행 따로 관리 따로인 경우가 많다. 또한 국내에서는 위험관리라 하면 위험분석이나 평가를 모든 것으로 생각하는 경우가 많다. 사실 위험분석이란 적절한 기법을 적용하고 경험이 풍부하고 숙달된 인력들이 작업을 한다면 도리어 짧은 기간내에 좋은 결과를 가져올 수도 있다. 그러나 그 뒤의 이행, 특히 모니터링과 통제는 지속적인 꾸준함과 끈기가 필요하다. 그러나 대부분 한 두번의 자체의 힘 또는 외부 컨설턴트들의 힘으로 분석작업이 완료된후 이행이 완료되면 더 이상 추적관리, 유지관리, 변경관리 등이 되지 않고 있는 경우가 많다. 결국 이 경우 실제 어떤 위험이 어떻게 포착되고 관리되고 소멸하는지 또한 이를 통해 결국 기업이 얼마만큼의 위험을 감소하고 어떠한 유익을 얻게되는지를 파악하지 못하게 되는것이다.

 

더 나은 방향을 위해

그러면 이러한 현실과 문제점을 어떻게 타개해 나갈 것인가? 사실 위에 구구절절 제시된 문제점 속에서 벌써 답이 숨어있음은 독자들이 쉽게 예상할 수 있다.

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

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

셋째 위험평가의 결과와 위험의 사후관리와의 연계를 통해 위험요소의 생명주기를  tracking해야 한다. 또한 대책 이행의 우선순위도 적절히 선택하며, 이로 인해 기업의 전반적인 보안위험이 어떻게 감소하는지 시뮬레이션 하고 실행의 결과와 비교해볼 필요가 있다. 이러한 시뮬레이션과 tracking은 대상 범위를 어느정도 축소한다면 Excel작업이나 약간의 프로그래밍으로 할 수 있을 만큼 의외로 복잡하지 않으나 현실에서는 잘 이행되지 않고 있다.

예를 하나 들어보자. 다음의 표와 같이 업무1이 수행되기 위해 필요한 자산은 A, 업무 2수행을 위해서는 A,B, 업무3수행을 위해서는 B,C라고 하자. 이때 업무 1이 문제발생시 기업에 손실을 가져오는 비율이 50, 업무 2는 30, 업무 3은 20%이라고 하자.

 

 

Risk

Supporting 자산

업무 1

50%

자산 A,

업무 2

30%

자산 A, 자산 B

업무 3

20%

자산 B, 자산 C

 

위험

 

 

 

 

 

 이 경우 이러한 위험을 감소시키기 위한 대책을 선택하고 이행계획을 수립할 때 그 우선순위를 자산 A->B->C의 순으로 하느냐, 자산 C->B-A의 순으로 하느냐는 큰 차이가 있다. A->B->C의 경우 위험은  50-> 80-> 100% 감소하는 반면 C->B->A의 경우 위험은 0-> 20->100%의 순으로 감소한다. 결국 C->B->A의 경우 시간이 지나도 위험이 별반 감소하지 않음으로 이에 근거한 계획을 세우는 것은 비 효과적임이 분명하다. 이러한 부분을 고려하여 비용이나 시간투자의 우선순위를 설정하며 또 계획과 실행을 비교하면서 위험 감소의 추이를 추적해본다면 가시적으로도 상당히 흥미롭게 위험관리 작업들을 수행할 수 있을 것이다. 이를 위해서 자체적으로 위험관리를 위한 프로그램을 개발할 수도 있을 것이다. 상용 프로그램이 좋은 부분이 상당히 많지만 모든 기업에 반드시 효과적일 수 없다. 특히 국내와 같이 위험측정의 실행이 익숙하지 않는 경우는 도리어 기업에 맞는 위험분석과 관리 도구를 개발하는 것이 좋을 수 있다.  이러한 도구는 수작업보다  효과적이며 위험분석과 관리의 노력을 절감시켜줄 것이다.

넷째 위험에 대한 평가의 지식을 축적하고 특히 동종기업들은 이를 공유함으로써 효율을 높여야 한다. 실제 위협분석의 경우 동종기업들의 경우 거의 차이가 없는 경우가 많다. 이 경우 동일한 수고를 각 기업들에서 별도로 할 이유가 없다.

 결국 복잡하게 연계되어 있는 거대기업의 IT위험을 제대로 평가하고 관리한다는 작업이 쉬운 일이 아니지만 단계별로 차근히 풀어나간다면 의외로 상당한 효과를 거둘 수 있다. 그러므로 조급하게 서두르지말고 관련된 당사자들이 상호협력과 강한의지를 가지고, 위험관리 과정을 지속적으로 추진한다면 위험관리체계가 각각의 기업내에 자연스럽게 정착될 수 있을 것이다.

 

 


Copyright © 2001