소프트웨어 보안 실패, 진짜 원인은...

10년 전 컨설팅/교육 벤처 기업을 시작한 이래로 필자는 전세계 수천 명의 개발자들과 만나봤다. 그리고 소프트웨어 보안 실패 사례 역시 수없이 목격해왔다. 그래서인지 사람들은 종종 필자에게 소프트웨어 운영 과정에서 주의해야 할 가장 큰, 가장 위험한 실수가 무엇인지 묻곤 한다.

물론 필자가 특정 사례들을 언급하며 대답을 하는 경우는 없다. 그것은 OWASP가 3년마다 하고 있는 일이다. OWASP 톱 10 리스트(OWASP Top-10)를 비롯한 보고서들은 정기적으로 보안 위협 목록을 발표하고 있지만 OWASP가 다루는 내용 가운데 일부는 문제의 규모에 기반해 선정된 것으로써 소수의 기관들에만 해당되는 내용인 경우가 많다.

기능 위주의 개발 현실과 개발자에 대한 과도한 의지
대신 필자는 조금 더 근본적인 두 개의 문제를 거론하곤 한다. 지나치게 기능성에만 초점을 두는 태도와 과도한 신뢰, 두 가지가 바로 그 문제다. 사실 이는 동전의 양면 같은 개념이라 할 수 있다. OWASP가 선정하는 위협들 역시 그 뿌리는 두 가지 문제에서 비롯된다고 생각한다.

이들 문제가 왜 이토록 오랜 시간 동안 우리를 괴롭히는지를 이해하는 것은 어렵지 않다. 필자가 만나 본, 그리고 함께 작업해 본 많은 소프트웨어 개발자들은 모두 매우 똑똑하고 열정적인 인물들이었다.

하지만 그들은 귀를 닫은 채 말도 안 되는 마감 기한을 제시하는 관리 팀을 상대하며 매우 고된 환경에서 업무를 처리하고 있다. 이런 압박을 받으며 근무하는 개발자들에게 기능성 이외의 다른 측면들, 즉 보안까지 신경쓰도록 요구하는 것은 너무 잔인한 처사라고 생각될 정도다.

'문제가 생길 수 있는 부분은 어디인지', 그리고 '외부 공격이 소프트웨어에 어떤 문제를 일으킬 수 있을지'에 대한 물음은 '고객들이 어떤 기능을 필요로 하는가?'라는 질문에 묻혀버리고 마는 것이다.

이런 상황의 반대편에는 위협을 과소평가하는 태도가 자리잡고 있다. 이 역시 개발자들이 다른 영역에 투자해야 할 역량을 기능성에만 집중하도록 하는 원인 가운데 하나로 생각해볼 수 있다.

좀 더 구체적으로 보자면 개발한 소프트웨어를 이용할 사용자들을, 그리고 코드에 이용되는 API를 과도하게 신뢰하는 개발자들의 태도가 문제의 싹을 키우는 것이라 할 수 있다.

기능 개발에 지나치게 집중함으로써 불필요한 기능의 차단에 주의를 기울이지 않는다면 잠재적 위협의 예측에는 상당한 어려움이 있을 것이다. 우리는 이런 태도가 결국 OWASP 톱 10 리스트에 소개되는 위협들로 이어짐을 기억해야 할 필요가 있다.

기능 개발의 중요성을 부정할 생각은 없다. 하지만 이에 못지 않게 코드가 임의적으로 어떤 작업을 시행하는 것을 차단하는 등의 안전을 위한 노력 역시 소홀히 해서는 안될 것이다. 쉽지 않은 작업임은 이해하지만, 예방을 소홀히 하면 문제는 더욱 커져 자신을 한층 더 힘겹게 할 것이다.

이런 이유로 필자는 개발자들에게 개발에 이용하는 모든 입력물들에 증명 과정을 거칠 것을 조언하곤 한다.

'완벽한' 소프트웨어를 목표로 한다면 특히나 위험 요인을 차단하는 블랙 리스팅이 아닌 투입되는 모든 재료의 안전성을 증명하는 화이트 리스팅(white listing)의 중요성이 강조된다.

블랙 리스팅 방식은 이미 많은 사례에서 허점을 드러내왔다는 사실을 언제나 마음에 새기고 작업에 임하자.

다음으로 데이터 출력 과정에 있어서도 이로 인한 문제 발생을 예방하려는 노력이 요구된다. 예를 들어 출력 환경이 XML 형식이라면, <“or”> 등의 명령어를 통해 사용자 데이터가 환경에 영향을 주는 일이 절대 발생하지 않도록 주의해야 할 것이다.

이런 대비에 실패한다면 그 소프트웨어는 매 순간 주입 공격의 위협을 안고 운영될 수밖에 없다. 하지만 예방이란 것이 말처럼 쉬운 작업은 아니다. 이는 데이터가 어디로 전달되고 어떻게 사용될 것인지, 그리고 그 형식은 안전한 지를 심도깊게 이해해야 하는 복잡한 과정이다.

불량 사용자들과 API, 그리고 입/출력 역시 대비해야 하는 요소들이다. 이와 관련해 필자는 종종 다음과 같은 예를 들곤 한다.

자신은 보모다. 오늘은 돌보고 있는 아이와 함께 시내에 볼 일이 있어 외출해야 한다. 지금 시각은 직장인들이 쏟아져 나오는 낮 12시. 일단 아이에게 합리적인 판단력이 있을 것이란 기대는 하지 않는 것이 좋다.

아예 처음부터 최악의 상황만을 가정한 뒤 여정을 떠나는 것이 맘 편하다. 아이의 눈에 햇살이 비치는 도시의 모든 것은 신기하기만 하다. 조금만 주의를 소홀히 하면 어느새 아이는 손을 놓고 저만치 뛰어가버린다. 자, 자신은 어떻게 볼 일을 끝마칠 것인가?

소프트웨어 역시 잠시라도 한 눈 팔면 금세 말썽을 일으키고 마는 어린아이와 같다. 부모 역할을 하는 보안 전문가가 존재하긴 하지만, 오늘처럼 외출한 상황에서까지 전문가의 도움을 받기는 어렵다.

당장 이 길거리에서 아이를 지켜내야 하는 몫은 보모인 자신, 다시 말해 소프트웨어 전문가에게 맡겨지게 되는 것이다.

더군다나 이 웃는 얼굴 속에 무시무시한 장난기를 지닌 이 꼬마를 부모의 사랑으로 감싸줄 수도 없으니, 괴로움은 부모가 느끼는 그것보다 더 클 것이다. 그래도 어찌하겠는가, 훌륭한 엄마와 좋은 보모 모두 아이에겐 없어선 안될 존재인 것을, 소프트웨어 역시 보안 전문가와 소프트웨어 전문가 둘의 손길이 모두 전해져야 오래도록 안전하게 커 나갈 수 있을 것이다.

최근 필자는 한 소프트웨어 개발팀에 자문 지원을 해줬다. 그들은 앞서 소개한 조언들을 잘 이해하고 받아들인 듯 보였다. 컨설팅 과정이 마무리 된 다음날 클라이언트 측에서 연락이 왔다. 개발팀과 보안팀 양측 모두에서 두 집단이 좀 더 잘 협력할 수 있는 방안을 조언해 줄 것을 요청해왔다는 내용이었다.

정말 기뻤다. 이들은 성공적인 소프트웨어 개발을 위한 변화의 첫 걸음이 무엇인지를 정확히 이해한 것이다. 변화는 분명 쉽지 않은 작업이다. 그러나 그 열쇠를 쥔 두 집단이 함께 힘을 모아 노력하면, 그들의 앞날은 분명 장미빛 청사진이 펼쳐질 것이다.

*케네스 반 빅(Kenneth van Wyk)은 KRvW 어소시에이츠(KRvW Associates LLC)의 회장 겸 상임 컨설턴트로 활동 중이다. editor@itworld.co.kr