_m.jpg)
보안은 잘 하고 있어도 못 하고 있어도 눈에 잘 띄지 않는다. 그렇기 때문에 보안 담당자들의 사업 계획이나 목표라는 게 모호해질 수 있다. 모호함은 보안의 가장 큰 적 중 하나다. 그런 상황에서 MTTR의 유용성이 빛을 발할 수 있다.
[보안뉴스 = 하실 파리크 CEO, Tromzo.com] 리스크를 줄이는 건 보안 담당 팀들의 오랜 목표이자 사업 계획이었다. 그런데도 리스크를 줄인다는 이 원대한 계획은 성취되지 않고 있다. 보안 예산을 늘리고 인원을 증가시켜도 마찬가지다. 아니, 오히려 리스크는 그 어느 때보다 커지고 있는 상황이다.
그 이유 중 하나는 리스크를 줄이고 관리한다는 것이 그 어느 때보다 복잡한 일이 되어가고 있다는 것이다. 코드와 클라우드 자산들은 빠르게 증가하고 있고, 비슷하게 늘어나는 소프트웨어들에서 취약점들도 기하급수적으로 많이 발견되고 있기 때문이다. 이런 상황에서도 취약점에 대한 조치가 취해지기까지 걸리는 시간은 평균 270일이니, 리스크를 무슨 수로 낮출 수 있겠는가.
그렇기 때문에 보안 팀이 업무를 성공적으로 수행하고 있느냐 아니냐를 가장 잘 나타내는 척도 중 하나는 MTTR이 될 수밖에 없다. ‘취약점으로 인한 위험이 사라지는 데 걸리는 평균 시간(mean time to remediate)’이라는 뜻인 이 MTTR의 수치가 줄어들면 줄어들수록 기업은 리스크를 실제로 줄이는 데에 한 발 가까워진다.
위험 완화의 딜레마
오늘 날의 조직들은 그 어떤 시대보다 빠르게 움직인다. 더 빠르게 사업 아이템을 발굴하고, 더 빠르게 개발하며, 더 빠르게 시험하고, 더 빠르게 출시해 더 빠르게 단종시킨다. 그러므로 혁신도 빨라져야 하고, 혁신의 상용화라는 것도 속도감 있게 진행되어야만 한다. 고객과 시장이 이를 기대하고 있기 때문에 기업들로서도 사실상 어쩔 수 없다. 속도가 곧 생존이다.
이런 분위기에서 ‘위험 요인의 안정적인 제거’라는 것은 방해 요소가 되기 일쑤다. 속도를 내는 데 방해가 된다는 건 그 자체로 ‘손해’로 이어진다는 뜻이다. 그래서 기업들은 위험 요소를 제거하는 게 중요하다는 걸 알면서도 손해를 보지 않는 쪽을 택한다. 안전성을 다 확인하기 전에 코드와 클라우드 인프라를 구축한다. 이런 일들이 빠르게 진행되고 누적된다. 어느 새 돌아보면 회사 내에 위험 요소들이 산적해 있어 어디서부터도 손을 댈 수 없는 지경에 이르렀음을 알게 된다.
그렇게 리스크는 관리할 수 없는 것이 되고, ‘리스크 관리’는 아무도 지키지 않는 새해 결심이나 정치적 선언과 같은 것으로 전락한다. 물론 기업들이 무조건 ‘이윤 우선’의 철학으로 움직이는 건 아니다. 그들 보기에는 취약점 하나하나가 전부 실질적인 위험이 되는 건 아니라는 점도 감안해야 한다. 즉 취약점 하나 발견될 때마다 해킹 공격에 당할 가능성이 100%로 치솟는 건 아니기 때문에 하나하나 이상적인 대응을 할 수 없다는 게 기업들의 논리다.
수긍이 가는 말이다. 하지만 그런 식으로 놓친 취약점 하나가 커다란 손해가 되어 돌아오는 것도 사실이다. 그렇기에 기업들은 모든 리스크들을 빠르게 점검하고 평가하여 필요한 대처들을 할 수 있어야 하는데, 이것이 보안 업무를 한없이 복잡하게 만든다. 대처가 필요한 취약점들이 어떤 것인지 그 누구도 정답을 알려줄 수 없다. 어떤 기업에는 A라는 취약점이 대단한 리스크가 되기도 하지만, 다른 기업에는 노이즈일 수도 있다. 어떤 게 진짜 리스크이고 어떤 게 노이즈인가를 걸러내는 작업은, 그렇게 보안 담당자들 최대의 난제가 되었다. 심지어 점검해야 할 취약점의 양이 많기도 하다.
그러니 리스크 관리라는 건 개개인의 열심으로 잘 해볼 수 있는 일이 아닌 것이 되었다. 리스크 관리라는 ‘거대한 체계’가 필요하게 됐다. 체계적인 접근법과 기술, 도구들이 있어야만 하는 건데, 이것만으로는 부족하다는 사실이 요즘 다시 부각되는 중이다. 체계적인 평가 방법도 추가되어야 한다. 리스크를 얼마나 잘 관리하고 있는지 평가하지 못한 채라면 그 어떤 접근법이나 기술, 도구들을 사용한다 하더라도 맹목적일 수밖에 없기 때문이다. 측량할 수 없는 걸 관리한다는 건 어불성설이다.
그래서 이야기는 결국 MTTR로
리스크 관리를 얼마나 잘 하고 있느냐를 평가하는 방법으로서 MTTR이 떠오르는 건 당연한 일이다. 취약점 때문에 생기는 위험을 얼마나 빠르게 완화시킬 수 있느냐를 알려주는 것이기 때문이다. 물론 MTTR이 곧 리스크 관리 그 자체라는 뜻은 아니다. 리스크 관리를 평가하는 수많은 방법 중 하나다. 다만 그 수많은 방법 중 가장 리스크 관리의 현 주소를 대변해주는 것에 가깝기에 중요하게 여겨지는 것이다.
취약점이 존재하는데도 아무런 조치를 취하지 않고 시간이 흐르도록 그대로 둔다는 건 무슨 뜻일까? 조직이 공격에 노출된 채 방치한다는 것이고, 공격의 가능성이 매초 높아지는데도 손을 쓰지 않는다는 뜻이다. 그러므로 MTTR을 줄인다는 것, 즉 취약점 조치 평균 시간을 줄인다는 것은 공격에 당할 가능성을 줄인다는 뜻이 된다. 리스크 관리를 위해 하고 있는 일들, 즉 위험 요인을 탐지 및 파악하고, 긴급 조치를 취하고, 장기적 대응을 하는 것 모두가 좋은 효과를 보고 있다는 뜻도 된다.
하지만 모든 취약점이 똑같은 리스크 요인인 것은 아니다. 취약점 익스플로잇에 성공한다 하더라도 공격자가 별 다른 이득을 취하지 못하면 별 다른 손해도 끼치지 못할 수 있다. 그렇다면 이런 취약점에 대한 대응력을 MTTR 계산에 굳이 포함시키지 않아도 된다. 반면 공격을 한 번 허용했을 대 지대한 피해를 끼치는 취약점이라면 큰 의미를 갖는다. 그런 취약점에 대한 조치를 취했다면, MTTR을 계산할 때 긍정적으로 반영해도 된다.
MTTR, 왜 갑자기?
보안 상태를 숫자로 평가하고 점검하는 팀들에게 있어 MTTR은 그리 새롭거나 혁신적인 개념이 아니다. 심지어 이미 MTTR을 충실하게 계산하고 평가해왔을 가능성이 높다. 다만 필자가 여기서 말하고 싶은 건, MTTR을 대수롭지 않게 여겨 왔던 아예 MTTR이라는 것을 몰랐던 지금은 MTTR이 그 어느 때보다 중요하다는 것이다. 취약점을 발굴하고 익스플로잇 하는 기술은 계속해서 발전하고 있고, 취약점 자체도 그 어느 때보다 많이 생겨나고 있기 때문이다. 취약점에 대한 평균 대처 기간을 주기적으로 파악하고 줄여나간다는 것의 가치는 두말 할 필요가 없다.
MTTR을 주요 평가 항목으로 삼고, 이것을 기준으로 보안을 강화시킨다는 것은 실질적은 효과라는 측면에서도 긍정적이다. ‘보안 강화’라든가 ‘리스크 관리’라는 건 자칫 모호한 개념이 될 수 있다. ‘아무 일도 안 일어났으면 잘 한 것’이라는 걸 은연 중 목표로 삼는 보안 담당자들이 현장에 적잖이 있는 걸로 알고 있다. 그런 모호한 목적 아래 일을 했을 때 정말로 아무런 일이 일어나지 않는다면 그건 일종의 행운일 가능성이 높지, 정말 보안 담당자가 일을 잘해서 그랬을 확률은 얼마 되지 않는다. MTTR은 보다 가시적이고 분명한 목적을 제시한다.
MTTR을 줄이려면
그렇다면 MTTR을 실제로 감소시키려면 어떤 일을 해야 할까? 필자는 다음 몇 가지를 제안한다.
1) 취약점들을 찾아내 목록을 만든다 : 이를 위해서는 디지털 자산을 빠짐없이 알아내야 한다. 코드 리포지터리에 담겨 있는 코드들부터, 소프트웨어 디펜던시들, 컨테이너, 마이크로서비스 등 낱낱이 파악하는 것부터 시작해야 한다. 그런 후에 그 자산들에 각종 컨텍스트들(소유자가 누구이며, 어떤 상황에서 사용되는가 등)을 추가하는 것까지 진행한다.
2) 사업적 측면에서의 리스크를 평가한다 : 자산들의 컨텍스트까지 더했다면, 리스크들이 윤곽을 드러낼 텐데, 거기서부터는 각 리스크를 평가하는 작업을 진행해야 한다. 회사가 진행하고 있는 사업이라는 측면에서 리스크의 심각성을 평가하는 것을 추천한다. 순수한 기술적 침투 가능성만 가지고 평가하면 기업의 상황에 맞지 않는 결과가 나오게 되고, 리스크 관리의 효율성이 떨어지게 된다.
3) 평가에 따라 취약점들을 분류한다 : 평가 결과가 나왔다면 그것을 기준으로 당장 고쳐야 할 것들과 조금 후에 손봐도 될 것, 장기적으로 두고 봐도 괜찮을 것들을 구별하는 작업을 실시해야 한다. 이 때 순위를 매기는 것에 더해 ‘어떤 방법으로 조치를 취해야 하는가’ 역시 각 항목에 더해두는 것이 좋다. 담당자까지 미리 배정해 둔다면 더 확실한 취약점 관리 목록이 될 수 있다.
4) MTTR의 측정 방법을 수립하고 적용한다 : 취약점을 다루는 데 투자되는 평균 시간을 어떻게, 어떤 것을 기준 삼아 측정할 것인지도 결정해야 한다. 그 기준이 정립된다면 차후 발견되고 다뤄질 취약점들에도 똑같이 적용해 평가해야 한다. 그래서 MTTR이 시간이 흐르면서 향상되고 있는지 아닌지 객관적으로 확인할 수 있어야 한다. 평가 방법에 대한 신뢰를 구축해야 평가 결과의 활용도가 높아진다.
글 : 하실 파리크(Harshil Parikh), CEO & Co-Founder, Tromzo.com
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 = 하실 파리크 CEO, Tromzo.com] 리스크를 줄이는 건 보안 담당 팀들의 오랜 목표이자 사업 계획이었다. 그런데도 리스크를 줄인다는 이 원대한 계획은 성취되지 않고 있다. 보안 예산을 늘리고 인원을 증가시켜도 마찬가지다. 아니, 오히려 리스크는 그 어느 때보다 커지고 있는 상황이다.
[이미지 = gettyimagesbank]
그 이유 중 하나는 리스크를 줄이고 관리한다는 것이 그 어느 때보다 복잡한 일이 되어가고 있다는 것이다. 코드와 클라우드 자산들은 빠르게 증가하고 있고, 비슷하게 늘어나는 소프트웨어들에서 취약점들도 기하급수적으로 많이 발견되고 있기 때문이다. 이런 상황에서도 취약점에 대한 조치가 취해지기까지 걸리는 시간은 평균 270일이니, 리스크를 무슨 수로 낮출 수 있겠는가.
그렇기 때문에 보안 팀이 업무를 성공적으로 수행하고 있느냐 아니냐를 가장 잘 나타내는 척도 중 하나는 MTTR이 될 수밖에 없다. ‘취약점으로 인한 위험이 사라지는 데 걸리는 평균 시간(mean time to remediate)’이라는 뜻인 이 MTTR의 수치가 줄어들면 줄어들수록 기업은 리스크를 실제로 줄이는 데에 한 발 가까워진다.
위험 완화의 딜레마
오늘 날의 조직들은 그 어떤 시대보다 빠르게 움직인다. 더 빠르게 사업 아이템을 발굴하고, 더 빠르게 개발하며, 더 빠르게 시험하고, 더 빠르게 출시해 더 빠르게 단종시킨다. 그러므로 혁신도 빨라져야 하고, 혁신의 상용화라는 것도 속도감 있게 진행되어야만 한다. 고객과 시장이 이를 기대하고 있기 때문에 기업들로서도 사실상 어쩔 수 없다. 속도가 곧 생존이다.
이런 분위기에서 ‘위험 요인의 안정적인 제거’라는 것은 방해 요소가 되기 일쑤다. 속도를 내는 데 방해가 된다는 건 그 자체로 ‘손해’로 이어진다는 뜻이다. 그래서 기업들은 위험 요소를 제거하는 게 중요하다는 걸 알면서도 손해를 보지 않는 쪽을 택한다. 안전성을 다 확인하기 전에 코드와 클라우드 인프라를 구축한다. 이런 일들이 빠르게 진행되고 누적된다. 어느 새 돌아보면 회사 내에 위험 요소들이 산적해 있어 어디서부터도 손을 댈 수 없는 지경에 이르렀음을 알게 된다.
그렇게 리스크는 관리할 수 없는 것이 되고, ‘리스크 관리’는 아무도 지키지 않는 새해 결심이나 정치적 선언과 같은 것으로 전락한다. 물론 기업들이 무조건 ‘이윤 우선’의 철학으로 움직이는 건 아니다. 그들 보기에는 취약점 하나하나가 전부 실질적인 위험이 되는 건 아니라는 점도 감안해야 한다. 즉 취약점 하나 발견될 때마다 해킹 공격에 당할 가능성이 100%로 치솟는 건 아니기 때문에 하나하나 이상적인 대응을 할 수 없다는 게 기업들의 논리다.
수긍이 가는 말이다. 하지만 그런 식으로 놓친 취약점 하나가 커다란 손해가 되어 돌아오는 것도 사실이다. 그렇기에 기업들은 모든 리스크들을 빠르게 점검하고 평가하여 필요한 대처들을 할 수 있어야 하는데, 이것이 보안 업무를 한없이 복잡하게 만든다. 대처가 필요한 취약점들이 어떤 것인지 그 누구도 정답을 알려줄 수 없다. 어떤 기업에는 A라는 취약점이 대단한 리스크가 되기도 하지만, 다른 기업에는 노이즈일 수도 있다. 어떤 게 진짜 리스크이고 어떤 게 노이즈인가를 걸러내는 작업은, 그렇게 보안 담당자들 최대의 난제가 되었다. 심지어 점검해야 할 취약점의 양이 많기도 하다.
그러니 리스크 관리라는 건 개개인의 열심으로 잘 해볼 수 있는 일이 아닌 것이 되었다. 리스크 관리라는 ‘거대한 체계’가 필요하게 됐다. 체계적인 접근법과 기술, 도구들이 있어야만 하는 건데, 이것만으로는 부족하다는 사실이 요즘 다시 부각되는 중이다. 체계적인 평가 방법도 추가되어야 한다. 리스크를 얼마나 잘 관리하고 있는지 평가하지 못한 채라면 그 어떤 접근법이나 기술, 도구들을 사용한다 하더라도 맹목적일 수밖에 없기 때문이다. 측량할 수 없는 걸 관리한다는 건 어불성설이다.
그래서 이야기는 결국 MTTR로
리스크 관리를 얼마나 잘 하고 있느냐를 평가하는 방법으로서 MTTR이 떠오르는 건 당연한 일이다. 취약점 때문에 생기는 위험을 얼마나 빠르게 완화시킬 수 있느냐를 알려주는 것이기 때문이다. 물론 MTTR이 곧 리스크 관리 그 자체라는 뜻은 아니다. 리스크 관리를 평가하는 수많은 방법 중 하나다. 다만 그 수많은 방법 중 가장 리스크 관리의 현 주소를 대변해주는 것에 가깝기에 중요하게 여겨지는 것이다.
취약점이 존재하는데도 아무런 조치를 취하지 않고 시간이 흐르도록 그대로 둔다는 건 무슨 뜻일까? 조직이 공격에 노출된 채 방치한다는 것이고, 공격의 가능성이 매초 높아지는데도 손을 쓰지 않는다는 뜻이다. 그러므로 MTTR을 줄인다는 것, 즉 취약점 조치 평균 시간을 줄인다는 것은 공격에 당할 가능성을 줄인다는 뜻이 된다. 리스크 관리를 위해 하고 있는 일들, 즉 위험 요인을 탐지 및 파악하고, 긴급 조치를 취하고, 장기적 대응을 하는 것 모두가 좋은 효과를 보고 있다는 뜻도 된다.
하지만 모든 취약점이 똑같은 리스크 요인인 것은 아니다. 취약점 익스플로잇에 성공한다 하더라도 공격자가 별 다른 이득을 취하지 못하면 별 다른 손해도 끼치지 못할 수 있다. 그렇다면 이런 취약점에 대한 대응력을 MTTR 계산에 굳이 포함시키지 않아도 된다. 반면 공격을 한 번 허용했을 대 지대한 피해를 끼치는 취약점이라면 큰 의미를 갖는다. 그런 취약점에 대한 조치를 취했다면, MTTR을 계산할 때 긍정적으로 반영해도 된다.
MTTR, 왜 갑자기?
보안 상태를 숫자로 평가하고 점검하는 팀들에게 있어 MTTR은 그리 새롭거나 혁신적인 개념이 아니다. 심지어 이미 MTTR을 충실하게 계산하고 평가해왔을 가능성이 높다. 다만 필자가 여기서 말하고 싶은 건, MTTR을 대수롭지 않게 여겨 왔던 아예 MTTR이라는 것을 몰랐던 지금은 MTTR이 그 어느 때보다 중요하다는 것이다. 취약점을 발굴하고 익스플로잇 하는 기술은 계속해서 발전하고 있고, 취약점 자체도 그 어느 때보다 많이 생겨나고 있기 때문이다. 취약점에 대한 평균 대처 기간을 주기적으로 파악하고 줄여나간다는 것의 가치는 두말 할 필요가 없다.
MTTR을 주요 평가 항목으로 삼고, 이것을 기준으로 보안을 강화시킨다는 것은 실질적은 효과라는 측면에서도 긍정적이다. ‘보안 강화’라든가 ‘리스크 관리’라는 건 자칫 모호한 개념이 될 수 있다. ‘아무 일도 안 일어났으면 잘 한 것’이라는 걸 은연 중 목표로 삼는 보안 담당자들이 현장에 적잖이 있는 걸로 알고 있다. 그런 모호한 목적 아래 일을 했을 때 정말로 아무런 일이 일어나지 않는다면 그건 일종의 행운일 가능성이 높지, 정말 보안 담당자가 일을 잘해서 그랬을 확률은 얼마 되지 않는다. MTTR은 보다 가시적이고 분명한 목적을 제시한다.
MTTR을 줄이려면
그렇다면 MTTR을 실제로 감소시키려면 어떤 일을 해야 할까? 필자는 다음 몇 가지를 제안한다.
1) 취약점들을 찾아내 목록을 만든다 : 이를 위해서는 디지털 자산을 빠짐없이 알아내야 한다. 코드 리포지터리에 담겨 있는 코드들부터, 소프트웨어 디펜던시들, 컨테이너, 마이크로서비스 등 낱낱이 파악하는 것부터 시작해야 한다. 그런 후에 그 자산들에 각종 컨텍스트들(소유자가 누구이며, 어떤 상황에서 사용되는가 등)을 추가하는 것까지 진행한다.
2) 사업적 측면에서의 리스크를 평가한다 : 자산들의 컨텍스트까지 더했다면, 리스크들이 윤곽을 드러낼 텐데, 거기서부터는 각 리스크를 평가하는 작업을 진행해야 한다. 회사가 진행하고 있는 사업이라는 측면에서 리스크의 심각성을 평가하는 것을 추천한다. 순수한 기술적 침투 가능성만 가지고 평가하면 기업의 상황에 맞지 않는 결과가 나오게 되고, 리스크 관리의 효율성이 떨어지게 된다.
3) 평가에 따라 취약점들을 분류한다 : 평가 결과가 나왔다면 그것을 기준으로 당장 고쳐야 할 것들과 조금 후에 손봐도 될 것, 장기적으로 두고 봐도 괜찮을 것들을 구별하는 작업을 실시해야 한다. 이 때 순위를 매기는 것에 더해 ‘어떤 방법으로 조치를 취해야 하는가’ 역시 각 항목에 더해두는 것이 좋다. 담당자까지 미리 배정해 둔다면 더 확실한 취약점 관리 목록이 될 수 있다.
4) MTTR의 측정 방법을 수립하고 적용한다 : 취약점을 다루는 데 투자되는 평균 시간을 어떻게, 어떤 것을 기준 삼아 측정할 것인지도 결정해야 한다. 그 기준이 정립된다면 차후 발견되고 다뤄질 취약점들에도 똑같이 적용해 평가해야 한다. 그래서 MTTR이 시간이 흐르면서 향상되고 있는지 아닌지 객관적으로 확인할 수 있어야 한다. 평가 방법에 대한 신뢰를 구축해야 평가 결과의 활용도가 높아진다.
글 : 하실 파리크(Harshil Parikh), CEO & Co-Founder, Tromzo.com
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-24] 
.jpg)
.jpg)
