대형 유출사고로 드러난 것은 근본부터 잘못된 보안 구조
현대에서는 지속성이 경쟁력, 그 흐름 보안도 끊어서는 안 돼
[보안뉴스 문가용] 일단 몇 가지 짚고 넘어가자. 보통의 중소기업 규모를 가진 금융 조직은 천 개 이상의 애플리케이션을 시스템에 설치해 사용한다. 큰 기업들은 만 개가 넘어간다. 그리고 이 애플리케이션은 각각 수만 줄의 코드로 이루어져있고, 큰 애플리케이션은 천만 줄에 이르기도 한다. 또한 각 애플리케이션은 십 수개에서 수백 개에 이르는 소프트웨어 라이브러리, 프레임워크, 요소들로 구성되어 있으며, 이는 코드보다 용량 면에서 10배를 훌쩍 뛰어 넘는다. 이런 애플리케이션 중 20%가 매년 코드 업데이트를 거친다.
미국 세금 관련 서비스 사이트를 보면, 코드만 4백 4십만 개의 줄로 구성되어 있다. 이는 단순 양만 보면 보통 애플리케이션 다섯 개에 해당하는 양이다. 그리고 나는 보안 전문가로서 그 중 수천 가지에 이르는 취약점을 발견했다. CEO로서는 법적인 취약점과 구멍을 또한 수천 개 발견했다. 재미있는 건 코드를 분석하건 법적인 내용을 분석하건 차이가 별로 없었다는 것이다. 두 분야 모두 각 분야에서 사용되는 언어의 자세한 이해가 뒷받침 되어야 하기 때문이다.
그리고 크다 하는 금융 기관은 이 세금 서비스 코드의 2000배에 해당하는 코드를 가지고 있다. 이는 수십 억 줄에 해당하고, 20년치의 코딩 기간을 필요로 하는 양이다. 이게 현재의 ‘팩트’이며 사실이다. 이걸 바탕으로 금융 업계의 상황을 살펴보자.
현재의 보안 상황
JP모건 유출사고에 대한 추가 정보가 계속해서 드러나는 가운데 JP모건에서 근무했던 익명의 한 인물은 뉴욕 타임즈를 통해 “설계도를 훔쳐낸 듯한 정확한 공격이었다. JP모건으로서는 이런 사건이 일어났음에도 단 시간 내에 모든 문과 창문을 교체할 수 없을 것이다. 전체 서례와 연관이 있는 부분이기 때문이다”라고 말했다.
나는 이것도 완화시켜 말한 것이라고 본다. JP모건이 이런 종류의 사건에 완벽하게 대비된 시스템을 갖추려면, 위에 말했듯, 20년은 걸릴 것이라고 보기 때문이다. 그리고 여기에는 지름길이 있을 수 없다. 물리적으로 불가능하다. 도시 전체가 석면으로 지어졌고, 그 석면이 사실은 건강에 무척 해로운 것이 뒤늦게 알려져, 도시를 아예 싹 갈아엎는 것이 어쩌면 더 나을지도 모르는 상황이라면 비슷한 비유일까. 그것도 거주민을 옮기거나 할 수도 없는 상황에서 말이다.
애스펙트 시큐리티(Aspect Security)의 전문가들에 의하면 기업의 웹 애플리케이션에는 평균 22.4개의 심각한 취약점이 존재한다. 발견 자체도 쉽지 않지만, 종류도 다양하며 따라서 심각성이나 악용의 가능성도 단 몇 줄로 정리할 수 없을 만큼 다채롭다고 한다. 거기다가 취약점을 공격하는 위협의 방식도 고차원적으로 발전하고 있다. 이 둘이 합쳐지니 대규모 사고가 펑펑 터질 수밖에 없는 것이다. 올해만 해도 얼마나 많은 사고에 사고가 터졌는가?
우리가 아는 애플리케이션 보안의 한계
예전만해도 수동으로 취약점을 찾고, 침투 실험을 하고 코드를 점검했다. 이것만으로도 충분했다. 많은 취약점을 실제로 찾아냈고 개발자들은 수정할 시간을 여유롭게 가질 수 있었다. 그러나 소프트웨어 개발이 고도로 발전하면서, 특히 라이브러리와 컴포넌트의 사용이 늘어나면서, 개발 속도가 빨라지고 프레임워크가 복잡해졌고, 수동으로 코드를 점검한다는 건 추수 때 들판에 앉아 쌀을 한톨 한톨 세서 수확량을 계산하는 것처럼 비효율적인 것이 되어버렸다.
그래서 어떤 점이 좋아졌나? 생산량이 늘었다. 그러나 대신 퀄리티, 즉 질이 현저하게 떨어지는 결과를 낳았다. 많은 산업이 공통으로 겪는 현상이었다. 자동차 산업에 한 때 불어 닥친 리콜 사태를 생각해보면 이해가 빠를 것이다. 하지만 결국엔 질이 양을 따라잡았다. 개발 분야도 마찬가지라, 우리의 코딩 실력도 갈수록 빨라졌다. 그러나 보안이 아직 이를 미처 따라잡지 못하고 있다. 아니, 빠르게 하기 위해 보안을 희생하는 게 추세가 되었다고 표현하는 편이 더 옳을 것이다. 그래서 오늘날과 같은 무수한 사고를 겪는 것이다. 이제 개발 속도를 맞추며 보안성을 높이는 새로운 기술이 필요한 때다.
속도와의 전쟁, 양과의 전쟁, 그리고 앱 보안
일단 언급한 것처럼 질과 양을 맞추는 데 성공한 다른 산업의 예가 우리 주위엔 있다. 그러니 거기서부터 배워야 하는 것이 당연하다. 그래서 설계, 개발, 실험, 생산에 이르는 전 과정을 다시 고민해야 한다. 무엇을? 전 과정에서 그때그때마다 실시간으로 보안성을 점검해줄 수 있는 방법을 말이다. 생산의 모든 단계에서, 개발을 멈추거나 느리게 하지 않은 채 보안 점검을 하고 침투 실험을 하고 사건 대응법을 만들어나가야 한다는 것이다.
엣시(Etsy), 넷픽스(Netfix), 트위터(Twitter), 옐프(Yelp) 같은 조직들은 진즉부터 이 문제를 깨닫고 새로운 방식의 보안 툴을 도입해왔다. 이 보안 툴들은 개발의 맨 마지막 단계에서 완성된 상품이나 서비스의 보안성을 점검하는 기존의 보안 툴들과는 개념부터가 다르다. 소프트웨어 개발 과정 내내 보안 관련 정보를 실시간으로 수집하고 실험하고 접목한다. 그러면서도 소프트웨어 개발을 전혀 방해하지 않는다. 보안 툴의 가장 큰 미덕은 철옹성 같은 방어율이 아니라 개발자들이 전혀 느낄 수 없는 0%의 존재감이다. 개발 과정의 지연은 뭉텅이 돈을 허공에 버리는 것과 마찬가지기 때문이다.
이제는 ‘지속성’이란 개념이 우리 안에 올바로 박혀 있어야 한다. 지속적인 보안은 24시간 불침번처럼 인터넷을 살핀다는 의미도 있지만 지속적인 생산이 필수인 현대의 경쟁 체제에서의 보안 업무를 의미하기도 한다. 그런 지속성을 보안이라는 이유로 끊어서는 안 된다. 그렇다면 보안담당자들은 취약점을 찾아내서 고치는 의사나 탐정이 아니라 땀 흘리고 있는 선수 옆에서 꼭 필요한 조치를 취하고 조언을 해주는 코치여야 한다.
글 : 제프 윌리엄스(Jeff Williams)
@DARKReading
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(http://www.boannews.com/) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-17] 
.jpg)
.jpg)
