소프트웨어 보안성 검사하는 툴들 자체에도 취약점 많아
결국엔 설계 단계부터 보안 도입해야... 개발 툴 개선 필요
[보안뉴스 문가용 기자] 소프트웨어를 구매한 사람들은 그 소프트웨어가 안전하다는 사실을 반드시 보장받아야 한다. 여기에는 이견이 있을 수 없다. 하지만 안전함을 보장하기 위해서 취하는 방법들 중 소프트웨어 분석과 칼로 무 자르듯 합격/불합격으로 나누는 평가 시스템에는 고개를 갸웃하게 된다. 현대의 복잡하고 치밀한 소프트웨어 세계를 지켜주는 정보보안의 기능이 더 이상은 제대로 발휘되지 않는다는 전제를 깔고 있는 개념이기 때문이다. 게다가 합격/불합격이란 평가를 내릴만한 정적 분석 기술을 우리는 보유하고 있기는 한가?
정적 분석이란 소프트웨어의 약점을 발견해내는 것으로 퍼즈(fuzz) 실험, 이미 알려진 취약점 대입 실험, 멀웨어 사냥, 정적 바이너리 분석 등과 같은 여러 소프트웨어 평가 항목 중 하나다. 물론 이 방법들을 동원해 취약점을 찾아내가면서 소프트웨어의 안정성을 점검하는 것 자체는 나쁠 게 없다. 그러나 모두가 외면하고 있거나 잘 모르는 문제점이 하나 있는데, 정적 분석이 끝난 후 그 자리에 리스크가 잔여물처럼 남는다는 것이다. 이를 상주 위험(residual risk)라고 한다.
상주 위험이란 무엇인가? 분석 툴이 이해를 하지 못할 정도로 엉망으로 작성된 코드는 분석되지 않는데, 이런 ‘엉망진창’인 부분이 어디인지 정적 분석을 통해 알 수가 없다. 이런 코드가 상주 위험이다. 또, 시스템과 프로세스들의 퍼포먼스 문제 때문에 분석 툴들이 분석 과정 중에 방해를 받아 버그나 취약점을 지나쳐가는 경우가 거의 확실히 생기는데, 이 때문에 분석 툴들이 발견해낸 오류나 약점들이 얼마나 정확한지 100% 신뢰할 수 없다. 이 역시 상주 위험이다.
즉 소프트웨어를 검사하는 툴들 역시 소프트웨어고, 이 세상에 100% 완벽한 소프트웨어는 없으니, 검사를 맡은 이 분석 툴이란 소프트웨어들도 오류를 일으켜 정확한 검사가 되지 않는다는 것이다. 앞이 안 보이는 사람이 앞이 안 보이는 사람을 이끄는 모양새다. 즉 우리는 소프트웨어를 평가하기 전에, 평가를 위한 소프트웨어를 검사할 수 있어야 한다는 것이다.
물론 그 동안에도 이런 노력들이 있어왔다. NSA, NIST 등도 연방정부의 투자금을 가지고 툴 자체를 연구 분석했다. 그러면서 현대화가 필요한 부분을 적발했다. 국토안보부도 여기에 나섰고, 조만간 각 분석 툴들에 대한 세부정보 및 참고사항 등이 발표될 예정이라고 한다. 하지만 보안 툴에 대한 정보를 공개하는 면에 있어서 법적으로 충돌이 일어나는 지점이 있어서 이 발표 계획이 정말로 현실화 될지는 불투명하다. 개인적으로는 정적 분석 툴들을 연구 분석한 결과가 보안 커뮤니티 안에서 공유되면 경쟁력 강화로 이어져 소프트웨어 분석이 더 정확해질 것이라고 보고 있다.
그러나 그 어떤 평가보다 소프트웨어를 처음부터 안전하게 설계하는 게 제일 좋다. 보안의 측면에서 엉성하게 기획되고 설계된 시스템은 유지 비용이 갈수록 높아질뿐더러, 다양한 보안 장치를 덧입히기를 반복해 오히려 더 위험해지는 게 보통이다. 카네기멜론 대학에서도 최근 연구를 통해 “보안 사고의 90%는 설계 및 개발 단계에서 막을 수 있는 것”이라는 결과를 발표한 바 있다.
하지만 보안을 강화한 개발 문화 역시 좀처럼 자리를 못 잡고 있다. 로체스터공과대학의 소프트웨어 엔지니어링 부교수인 메디 미라콜리(Mehdi Mirahkoli) 박사는 “아키텍처 분석 및 보안이 적용된 개발 방법론이 현재 환경에 잘 도입되지 않는 이유는 지금 가장 많이 쓰이고 인기가 높은 개발 툴들에 보안 기능이 충분하지 않기 때문”이라고 분석한다. “개발자들이 매일 더블클릭해서 사용하는 툴들 자체에 보안 기능이 없으니, 개발자들이 ‘보안 마인드’라는 걸 어떻게 가질 수 있겠습니까?”
결국 소프트웨어를 인증한다는 개념 자체에는 찬성한다. 서두에 말하긴 했지만 소비자들은 ‘내가 사는 물건이 안전하다’는 확인을 받아야 하는 권리를 가지고 있기 때문이다. 다만 인증 시 사용하는 소프트웨어 툴들이 아직은 불완전하다는 게 문제다. 오히려 검사 대상인 소프트웨어들이 훨씬 더 현대화 되어 있고 검사 및 인증 툴들이 구식이니 그 결과를 어떻게 믿겠는가? 이 부분의 전문가 중 하나인 헨니 십마(Henny Sipma) 박사는 “정적 분석 툴은 한 15년 뒤쳐진 상태”라고까지 말한다. 소프트웨어 인증이란 제도를 도입하기 전에 인증 툴들에 대한 고려가 반드시 있어야 한다.
게다가 ‘소프트웨어 인증’이 만능은 아니다. 어차피 우리가 도착해야 할 최종 목적지는 ‘빌트인 시큐리티’, 즉 설계 때부터 도입된 보안이다. 이를 위해선 개발 툴들 자체에 보안 관련 기능이 더 많이 들어가야 한다. 즉, 보안을 강화하기 전에 우리가 지금 아무렇지도 않게 사용하고 있는 여러 툴들 자체에 개선해야 할 부분이 있음을 있다는 걸 자각할 필요가 있다.
글 : 케빈 그린(Kevin Greene)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
결국엔 설계 단계부터 보안 도입해야... 개발 툴 개선 필요
[보안뉴스 문가용 기자] 소프트웨어를 구매한 사람들은 그 소프트웨어가 안전하다는 사실을 반드시 보장받아야 한다. 여기에는 이견이 있을 수 없다. 하지만 안전함을 보장하기 위해서 취하는 방법들 중 소프트웨어 분석과 칼로 무 자르듯 합격/불합격으로 나누는 평가 시스템에는 고개를 갸웃하게 된다. 현대의 복잡하고 치밀한 소프트웨어 세계를 지켜주는 정보보안의 기능이 더 이상은 제대로 발휘되지 않는다는 전제를 깔고 있는 개념이기 때문이다. 게다가 합격/불합격이란 평가를 내릴만한 정적 분석 기술을 우리는 보유하고 있기는 한가?
정적 분석이란 소프트웨어의 약점을 발견해내는 것으로 퍼즈(fuzz) 실험, 이미 알려진 취약점 대입 실험, 멀웨어 사냥, 정적 바이너리 분석 등과 같은 여러 소프트웨어 평가 항목 중 하나다. 물론 이 방법들을 동원해 취약점을 찾아내가면서 소프트웨어의 안정성을 점검하는 것 자체는 나쁠 게 없다. 그러나 모두가 외면하고 있거나 잘 모르는 문제점이 하나 있는데, 정적 분석이 끝난 후 그 자리에 리스크가 잔여물처럼 남는다는 것이다. 이를 상주 위험(residual risk)라고 한다.
상주 위험이란 무엇인가? 분석 툴이 이해를 하지 못할 정도로 엉망으로 작성된 코드는 분석되지 않는데, 이런 ‘엉망진창’인 부분이 어디인지 정적 분석을 통해 알 수가 없다. 이런 코드가 상주 위험이다. 또, 시스템과 프로세스들의 퍼포먼스 문제 때문에 분석 툴들이 분석 과정 중에 방해를 받아 버그나 취약점을 지나쳐가는 경우가 거의 확실히 생기는데, 이 때문에 분석 툴들이 발견해낸 오류나 약점들이 얼마나 정확한지 100% 신뢰할 수 없다. 이 역시 상주 위험이다.
즉 소프트웨어를 검사하는 툴들 역시 소프트웨어고, 이 세상에 100% 완벽한 소프트웨어는 없으니, 검사를 맡은 이 분석 툴이란 소프트웨어들도 오류를 일으켜 정확한 검사가 되지 않는다는 것이다. 앞이 안 보이는 사람이 앞이 안 보이는 사람을 이끄는 모양새다. 즉 우리는 소프트웨어를 평가하기 전에, 평가를 위한 소프트웨어를 검사할 수 있어야 한다는 것이다.
물론 그 동안에도 이런 노력들이 있어왔다. NSA, NIST 등도 연방정부의 투자금을 가지고 툴 자체를 연구 분석했다. 그러면서 현대화가 필요한 부분을 적발했다. 국토안보부도 여기에 나섰고, 조만간 각 분석 툴들에 대한 세부정보 및 참고사항 등이 발표될 예정이라고 한다. 하지만 보안 툴에 대한 정보를 공개하는 면에 있어서 법적으로 충돌이 일어나는 지점이 있어서 이 발표 계획이 정말로 현실화 될지는 불투명하다. 개인적으로는 정적 분석 툴들을 연구 분석한 결과가 보안 커뮤니티 안에서 공유되면 경쟁력 강화로 이어져 소프트웨어 분석이 더 정확해질 것이라고 보고 있다.
그러나 그 어떤 평가보다 소프트웨어를 처음부터 안전하게 설계하는 게 제일 좋다. 보안의 측면에서 엉성하게 기획되고 설계된 시스템은 유지 비용이 갈수록 높아질뿐더러, 다양한 보안 장치를 덧입히기를 반복해 오히려 더 위험해지는 게 보통이다. 카네기멜론 대학에서도 최근 연구를 통해 “보안 사고의 90%는 설계 및 개발 단계에서 막을 수 있는 것”이라는 결과를 발표한 바 있다.
하지만 보안을 강화한 개발 문화 역시 좀처럼 자리를 못 잡고 있다. 로체스터공과대학의 소프트웨어 엔지니어링 부교수인 메디 미라콜리(Mehdi Mirahkoli) 박사는 “아키텍처 분석 및 보안이 적용된 개발 방법론이 현재 환경에 잘 도입되지 않는 이유는 지금 가장 많이 쓰이고 인기가 높은 개발 툴들에 보안 기능이 충분하지 않기 때문”이라고 분석한다. “개발자들이 매일 더블클릭해서 사용하는 툴들 자체에 보안 기능이 없으니, 개발자들이 ‘보안 마인드’라는 걸 어떻게 가질 수 있겠습니까?”
결국 소프트웨어를 인증한다는 개념 자체에는 찬성한다. 서두에 말하긴 했지만 소비자들은 ‘내가 사는 물건이 안전하다’는 확인을 받아야 하는 권리를 가지고 있기 때문이다. 다만 인증 시 사용하는 소프트웨어 툴들이 아직은 불완전하다는 게 문제다. 오히려 검사 대상인 소프트웨어들이 훨씬 더 현대화 되어 있고 검사 및 인증 툴들이 구식이니 그 결과를 어떻게 믿겠는가? 이 부분의 전문가 중 하나인 헨니 십마(Henny Sipma) 박사는 “정적 분석 툴은 한 15년 뒤쳐진 상태”라고까지 말한다. 소프트웨어 인증이란 제도를 도입하기 전에 인증 툴들에 대한 고려가 반드시 있어야 한다.
게다가 ‘소프트웨어 인증’이 만능은 아니다. 어차피 우리가 도착해야 할 최종 목적지는 ‘빌트인 시큐리티’, 즉 설계 때부터 도입된 보안이다. 이를 위해선 개발 툴들 자체에 보안 관련 기능이 더 많이 들어가야 한다. 즉, 보안을 강화하기 전에 우리가 지금 아무렇지도 않게 사용하고 있는 여러 툴들 자체에 개선해야 할 부분이 있음을 있다는 걸 자각할 필요가 있다.
글 : 케빈 그린(Kevin Greene)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
.jpg)
.jpg)
