보안 제품정보


해킹 사고를 예방할 수 있는 디자인 및 개발 10계명 2014.08.29

유명 회사 및 대학 개발진들 모여 작성한 보고서지만...

당장의 도움보다 장기적인 인식 변화를 위한 움직임


[보안뉴스 문가용] 보안에 구멍은 어떻게 생기는가? 버그나 취약점 때문인 경우가 많다. 그러나 전부는 아니다. 소프트웨어를 개발하는 단계에서 보안 설계 자체를 잘못 하는 것도 굉장히 큰 요인이다.

 

 ▲ 사실 별 내용 없지만, 일단 시도해봤다는 거에 의의를...

시지털(Cigital), 구글, 트위터, HP, 맥아피, EMC, RSA, 하버드대학, 조지워싱턴대학, 아테네경제대학, 샌도스키재단, 워싱턴대학은 최근 ‘안전한 디자인’에 대한 보고서를 최근 발표했다. 여기에는 소프트웨어 개발을 할 때 가장 흔히 저지르는 보안 관련 실수 10가지가 나와 있어 흥미롭다.


“소프트웨어 디자인 단계에서 문제를 발견하고 해결한다면 그 후에 발생할 수 있는 문제 대다수를 해결하는 것과 다름이 없습니다.” 트위터의 보안 엔지니어링 팀에 근무하고 있는 네일 다스와니(Neil Daswani)의 설명이다. “그러므로 가격 효율이 무척 높은 방법입니다.” 이는 이들이 함께 머리를 맞대고 10가지 실수를 작성한 이유이기도 하다.


“여태까지 취약점 및 버그 적발 백서와 같은 종류의 발간물은 온라인이고 오프라인이고 많았습니다. 하지만 보안전문가들이 버그에 혈안이 되어 있는 것만큼 소프트웨어 디자이너나 개발자들이 보안에 대해 조금 생각해보는 것도 대단히 중요합니다.” 시지털의 CTO인 게리 맥그로우(Gary McGraw)의 의견이다.


트위터는 이 보고서를 참고해 벌써 자사의 소프트웨어 디자인에 적용하고 있는 중이다. 다스위니에 의하면 이미 소프트웨어 개발 시 꼭 지켜야할 항목들이 내부적으로 돌고 있다고 한다. “예를 들면 템플릿 프레임워크는 정해진 수만큼만 사용할 것을 권장합니다. 개발자들을 ‘하나’로 정했고요. 템플릿 프레임워크를 하나로 정하면 XSS 취약점은 자연히 없어지는 것이죠.”


그렇게 디자인으로 방지할 수 있는 해킹 사고가 있다면, 디자인 단계에서 한번 쯤 고민해볼 가치가 있다. 이번 보고서에서 정리한 10가지 권장사항은 다음과 같다. 다소 뻔한 감이 있으니 기대감을 낮추고 볼 것을 권한다.


1. 믿음은 노력해서 얻는 것 혹은 주는 것이지 절대 그냥 생겨서는 안 된다.

2. 우회나 변경이 불가능한 인증 원리를 활용하라.

3. 일단 본인인증 및 식별 절차를 거친 후에 권한을 부여하라.

4. 데이터와 제어 명령을 철저하게 분리하라. 그리고 신뢰할 수 없는 곳에서부터 온 제어 명령은 절대 처리하지 않는다.

5. 작업 과정 중 발생하는 모든 데이터를 명쾌하게 인증할 수 있는 접근법을 규정하라.

6. 암호화를 올바르고 일관적으로 적용한다.

7. 민감한 데이터는 어떤 기준으로 분류하고 어떻게 다룰지 정한다.

8. 항상 사용자를 고려한다.

9. 소프트웨어에 통합되는 외부 요소가 어떤 식으로 공격면에 변화를 줄 수 있는지 이해한다.

10. 오브젝트와 액터가 장차 바뀔 수 있다는 걸 고려해 최대한 융통성을 발휘한다.


“중요한 건 요즘 빈번하게 터지는 보안 사고가 대부분 ‘버그’나 ‘취약점’에 맞춰져 있다보니 사용자들이 버그 때문에 해킹 사고가 발생한다고 생각합니다. 하지만 디자인 자체의 오류 때문에 발생하는 사고가 버그 때문에 발생하는 사고만큼 많다는 건 모르죠. 그런 부분을 환기시켰다고 볼 수 있습니다.” OWASP 재단의 부회장인 톰 브레난(Tom Brennan)의 설명이다.


“또한 소프트웨어 제작 단계에서부터 보안을 생각할 필요가 있다는 걸 짚어줌으로써 해킹 행위에 보다 적극적으로 대처할 수 있게 되었습니다. 증상에 연연하는 게 아니라 한 발 더 나아가 아예 원인 자체를 차단하는 방식으로 변해가자는 것이 이번 보고서의 주된 메시지겠죠.” 버그를 찾아내는 것도 좋지만 아예 그 버그의 태생부터 제거하는 게 더 효과적이라는 뜻이다. “문제 하나를 찾아내서 고치는 게 아니라 그 문제의 뿌리가 될 수 있는 걸 아예 제거함으로써 그 문제뿐 아니라 유사한 다른 문제까지도 다 예방할 수 있거든요.”


다스와니는 “결국 중요한 건 개발자와 디자이너, 보안담당자가 아예 처음 백지상태부터 소프트웨어 제작을 함께 해야 한다는 겁니다”라고 이번 보고서의 의의를 정리한다. 화이트옵스(WhiteOps)의 수석연구원인 댄 카민스키(Dan Kaminsky)는 이번 보고서가 재미있는 건 “결국 지난 수년 간 겪어왔던 해킹을 통해 뭔가 새로운 걸 배웠다는 뜻”이기 때문이라고 한다. “보안 문제는 보안담당자만의 문제가 아니라는 것을 시사 하기도 하고요.”


모인 사람들에 비해 이번 보고서 자체가 큰 도움이 될지 안 될지는 불투명하지만 보안을 다른 단계에서 해결하고자 하는 움직임이 일어나고 있다는 것에 의의를 둘 수 있다. 보안의 영역이 넓어지고 있다.

ⓒDARKReading

[국제부 문가용 기자(globoan@boannews.com)]


<저작권자: 보안뉴스(http://www.boannews.com/) 무단전재-재배포금지>