세계 보안 엑스포  전자정부 솔루션 페어  개인정보보호 페어  국제 사이버 시큐리티 컨퍼런스  세계 태양에너지 엑스포  스마트팩토리  세계 다이어트 엑스포  INFO-CON
소프트웨어 산업의 공급망 변혁, 이미 시기가 지났다
  |  입력 : 2017-07-16 21:05
페이스북 보내기 트위터 보내기 네이버 밴드 보내기 카카오 스토리 보내기
현대 애플리케이션들은 대부분 오픈소스 요소들 조립해 만들어져
앱 사용하는 기업들 자체적인 취약점 탐지 및 조치 능력 없어


[보안뉴스 문가용 기자] 자동차 생산업체가 고장 나거나 불량인 부품을 발견하면 어떻게 해야 할까? 리콜을 하거나 고객들에게 알려 어떤 식으로든 보상을 해줘야 한다. 해당 부품을 탑재한 채로 자동차가 이미 거리를 달리고 있을 수 있기 때문에, 자동차 제조사나 부품 제조사의 책임은 어마어마하게 커진다.

[이미지 = iclickart]


웹 애플리케이션이나 API를 오픈소스 요소들을 사용해 만드는 것은 어떨까? 자동차 제조업체와 그 사정은 비슷하다. 오픈소스 ‘부품’들을 사용하는 사람들이라면 어디엔가 취약점이 있을 가능성이 높다는 걸 인지하고 있어야 한다. 자동차를 만들든 소프트웨어를 만들든 부품의 완전성을 늘 의심하지 않고서는 제대로 된 제품을 만들 수가 없다. 그러나 소프트웨어 산업에서는 이러한 자세가 아직도 부족한 것으로 보인다. 요즘 자동차도 사실은 소프트웨어에 바퀴만 얹어놓은 것인데 말이다.

오늘날의 애플리케이션들은 수백 개의 ‘오픈소스 요소’들의 조립품이다. 수백만~수천만 줄의 코드로 구성되어 있으며, 보안 업체인 콘트라스트 시큐리티(Contrast Security)에 의하면 이중 79%는 라이브러리 코드이고, 21%만이 개발자가 직접 손 댄 부분이라고 한다. 또한 현존하는 애플리케이션들의 약 76%가 적어도 한 개 이상의 취약점을 가지고 있으며, 34%는 4개 이상의 취약점을 내포하고 있다고도 한다. 소프트웨어의 생산 체계에 뭔가 문제가 있긴 있다.

올해 초 아파치(Apache)는 스트러츠2(Struts2) 프레임워크에 대한 패치를 발표했다. 스트러츠2에서 발견된 취약점 때문이었다. 이 취약점은 공격자들이 아주 쉽게 원격 코드 실행을 할 수 있도록 해주는 치명적인 것이었다. 그런데 오히려 해커들은 이 패치 공개 때문에 해당 취약점에 대해 알게 되었고, 익스플로잇 방법이 널리 퍼지기 시작했다. 패치가 퍼지는 것보다 공격이 더 빨리, 활발히 일어났다.

필자가 근무하고 있는 콘트라스트에서는 실제로 CVE-2017-5638 취약점에 대한 공격을 발견한 바 있다. 당시 해커는 HTTP Request Header인 “content-type:”을 통해 애플리케이션 안으로 침입을 시도하고 있었다. 코드는 다음과 같았다.

[이미지=제프 윌리엄즈]


이런 식의 해프닝은 매년 발생한다. 더 구체적으로 말하자면 1) 익스플로잇 하기 손쉬운 취약점이 매년 몇 번씩이나 나오고 2) 쉽기 때문에 많은 사이버 범죄자들이 악용하는 사례가 매년 몇 번씩 나오고, 3) 취약점 패치가 배포되는 것보다 공격자들의 실행이 더 빠른 사례도 매년 몇 번씩 나온다는 것이다. 소프트웨어를 처음부터 끝까지 혼자 만들 수 없는 대부분의 기업들에겐 의문이 생길 수밖에 없다. ‘도대체 이 일을 어찌해야 할까?’

가장 간단한 해결책은 패치를 빠르게 하는 것이다. 그러나 이게 말처럼 쉬운 문제는 아니다. 패치를 해야 하는 애플리케이션과 같이 활용되는 다양한 시스템 및 다른 애플리케이션들과의 호환성 문제가 발생할 수 있기 때문이다. 90년대 산업 단지 시설에서 OS를 새롭게 바꿔야만 했을 때도 이런 ‘패치해야 하는데 패치할 수 없는’ 문제가 대대적으로 발생했었다. 그래서 예전에는 패치만을 담당하는 팀이 대기업들에 따로 있을 정도였다. 하지만 이제는 OS 제조사들이 자동 패치가 적용되도록 인프라를 갖추고 있다.

문제는 애플리케이션이 OS처럼 자동으로 업데이트 되지 않는다는 것이다. 그렇기에 아무도 자신들이 사용하고 있는 애플리케이션들에 하자가 있는지 없는지 모른다. 안다고 해도 고칠 방법이 없다. 그러니 애플리케이션에서 발견된 취약점이 전반적으로 고쳐지기까지는 수개월에서 수년까지 걸린다. 그러니 패치가 적용되는 것보다, 패치가 나온 시점에 해당 취약점을 파악한 해커들의 공격이 빠른 것이다. 취약점을 알게 된 시점을 기준으로 해커는 수시간 만에 움직이기 시작한다. 그럴 수 있기 때문이다.

사실 공급망의 변혁을 겪지 않는 산업은 없다. 자동차 산업과 제약 산업을 보라. 성장을 하다 보면 어느 시점에는 분명히 커진 규모에 맞게 생산과 공급 방법에 변화가 일어난다. 그렇지 않으면 규모만 커지고 내실은 없어져 속으로 붕괴하고 만다. 소프트웨어 산업은 그 시점을 지나쳐도 이미 한참 전에 지나쳤다. 그렇기에 소프트웨어마다 구멍들이 있고, 해커들의 공격에 무방비로 당하는 것이다. 그렇다면 어떻게 해야 할까?

먼저 소프트웨어 사용 기업들의 현재 상황을 보도록 하자. 기업들은 여러 가지 사정으로 취약점 소식이 들려와도 꽤나 늦게 대응한다. 아무리 치명적인 위험요소를 가지고 있고, 아무리 익스플로잇이 쉬운 취약점이라고 해도 말이다. 그건 무엇보다 자체적으로 그런 취약점들을 발견해내는 기능을 가지고 있지 않아서다. 취약점을 탐지도 못하고, 그걸 악용하는 활동들 역시 발견하지 못한다.

다행히 이 문제는 곧 해결될 것으로 보인다. 런타임 애플리케이션 시큐리티 프로텍션(Runtime Application Security Protection, RASP)이라는 것이 등장했기 때문이다. 기업과 조직들은 RASP을 웹 애플리케이션과 API에 직접 삽입해 스스로의 애플리케이션들을 보호할 수 있다. 웹 애플리케이션 방화벽(WAF)과는 달리 애플리케이션의 내부에 설치되기 때문에 위험요소를 더 단단히 틀어막을 수 있다. 속도도 더 빠르다. 새롭게 출현한 이 시장이 좀더 성숙해지면 앱 보안 취약점의 탐지가 더 빨라질 것으로 기대된다.

좀 더 설명을 하자면 RASP 제품들은 1) 오픈소스 코드 어디에 취약점이 있는지 정확히 파악하고, 2) 어떤 서버에서 어떤 애플리케이션들이 실행되고 있는지를 지속적으로 보고하며, 3) 그 중에서도 정확히 어떤 오픈소스 요소가 사용되고 있는지도 알려준다. 이렇게 어떤 애플리케이션이 어디에 위치해 있으며 언제 사용되는지만 정확히 실시간으로 알게 돼도 소프트웨어 생태계는 훨씬 안전해진다. 취약점을 정확히 짚어준다는 특징이 더해주는 안정감은 말할 것도 없다.

중요한 건 RASP 제품들이 이미 변화를 시작했고, 단순히 현 상태를 드러내는 것뿐만 아니라 어느 정도의 보호 기능을 스스로 가지고 있다는 것이다. 이미 알려지고 공개된 취약점들에 대해서는 자체적인 보호 매커니즘을 발휘해 해커들이 적어도 알려진 취약점들을 통해 공격할 수 없도록 한다. 이를 CVE 방패(CVE Shield)라고 부르기도 한다. 한 마디로 공격자의 비용을 높인다는 것이다.

미래에는 애플리케이션들마다 ‘자동 탐지 및 자동 보고’ 기능을 갖출 것으로 보인다. 또한 RASP 제품들처럼 어느 정도의 CVE 방패 기능을 가지고 있어 공격자들이 쉽사리 공격할 수 없도록 만드는 것도 ‘표준’이 되지 않을까 한다. 그것이 소프트웨어 산업이 가야할 변혁의 방향이다. 소프트웨어 산업이 무르익다 못해 농익어 터지기 직전이다.

글 : 제프 윌리엄즈(Jeff Williams)
[국제부 문가용 기자(globoan@boannews.com)]

Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>



비츠코리아 파워비즈시작 2017년7월3일파워비즈 배너
북한의 사이버 공격이 갈수록 심해지고 있습니다. 해킹 공격이 미사일 공격보다 더 무섭다는 소리도 나올 정도입니다. 정부 차원에서 더 강화된 사이버 보안을 위한 전략을 새롭게 수립해야 한다고 생각하십니까?
아니다. 지금 있는 것만 제대로 해도 충분하다.
그렇다. 단, 미국의 행정명령처럼 장기적인 방향성을 가져야 한다.
그렇다. 단, 지금의 위기상황에 당장 적용할 수 있는 것이어야 한다.
아니다. 민간 차원에서 해결할 수 있어야 한다.
정부 차원의 전략이 얼마나 도움이 될지 잘 모르겠다.
크게 보면 외교 문제다. ‘보안’의 시각으로만 접근해서는 안 된다.
기타(댓글로)