[넋두리 2] 8. 좋은 개발보안이란 무엇인가!

개발자가 보안을 신경 쓰지 않게 하는 것

  최근 한 정보보안 관련 조찬모임에 참석했다. 아침 7시 반에 시작되는 모임 시간에 맞추기 위해 새벽 5시 반에 기상하는 부지런함을 떨어 한 시간 이상을 이동해서 참가한 모임이다. 그날 들은 발표 중 개발보안을 주제로 한 발표가 있었다. 그리고 발표 내용 중 한 구절이 두 눈에 박히며 가슴을 때렸다.

"개발자는 보안을 신경 쓰고 싶지 않습니다"

  현재 정보보안을 직업으로 하고 있으나 사회진출을 개발자로 시작한 사람으로서 그 구절이 십분 공감되면서 진지한 화두를 던지게 만들었다. '좋은 개발보안이란 무엇인가'라는 화두를 말이다.

  대부분 해커의 공격은 취약점을 이용해 이루어진다. 취약점은 개발자가 IT 프로그램을 개발하면서 만들어진 보안에 취약한 부분이다. 기업 및 기관들이 사용하는 IT 프로그램들은 모두 취약점을 가지고 있고, 이를 이용해 해커들의 해킹 공격이 이루어진다. 이를 이유로 개발자들에게 요구하는 것이 개발보안이다. 제발 개발할 때 보안을 좀 신경 쓰면서 개발하라는 요구 말이다.

  당연한 말이지만 개발자들은 보안전문가가 아니다. 그렇다고 보안에 취약한 IT 프로그램을 개발해야지 하는 생각도 없다. 그냥 요구사항에 따라 개발했는데 취약점이 있을 뿐이다. 일부러 취약점을 만드는 것이 아니란 것이다. 

  그럼 보안전문가가 개발기술을 습득해 IT 프로그램을 개발하면 취약점이 없을까 하면 그렇지도 않다. 보안전문가가 개발해도 취약점은 나온다. 거의 반드시 나온다고 봐도 무방하다. 이 경우 오히려 전문 개발자보다 IT 프로그램 자체의 성능은 떨어지는 부작용이 있을 수도 있다.

  힘들게 개발한 프로그램이 해커의 공격에 의해 해킹당하면 그로 인한 피해의 결과는 대체로 두 개의 조직에게 집중된다. 보안조직과 개발조직. 보안조직에게는 왜 사전에 취약점이 있음을 파악하지 못했는가 하는 추궁이, 개발조직에게는 어떻게 개발했기에 해킹을 당했는가 하는 추궁이 이어진다. 지금까지는 보안조직과 개발조직 모두 이 문제에서 자유롭지 못한 상태가 반복되어 이어지고 있다. 

  짧은 개발기간 동안 개발을 완료해야 하는 개발조직은 힘들다. 가뜩이나 개발기간도 짧은데 취약점 점검을 한답시고 이리저리 헤집어 놓더니 취약점이 나왔으니 조치해야 한다고 추가 요구사항을 한 보따리 던지는 보안조직이 밉다. 이해하기 어려운 보안용어가 잔뜩 나열된 조치방안이 어려워서 더 밉다. 그 와중에 개발 완료를 독촉하는 관리자는 한술 더 뜨고 있으니 역시 밉다. 그렇다고 취약점이 있다고 하는데 신경 쓰지 않을 수도 없다. 이래저래 진퇴양난이다.

  보안조직도 힘들다. 개발보안 좀 잘 신경 써서 개발해서 취약점 없이 누이 좋고 매부 좋으면 어디 덧나는지 매번 취약점이 우르르 나온다. 조치는 꼭 되어야 하는데 개발자들은 항상 개발기간 완료 독촉에 따른 어려움을 하소연한다. 감정적 이해는 되지만 어쩔 수 없다. 해킹이라도 당하면 그 피해는 보안조직에게 치명적이다. 양보는 없다.

  이렇듯 항상 평행선을 달리게 된다. 주변 환경들이 개발조직과 보안조직의 원만한 합의를 어렵게 만든다. 그래서 개발자는 보안을 신경 쓰고 싶지 않게 되는 것이다. 

  '좋은 개발보안이란 무엇인가'라는 고민이 하나의 화두로 자리 잡았다. 적어도 개발자가 보안을 신경 쓰지 않게 할 수 있다면 좋은 개발보안이 될 수 있을 것이다. 이를 해결하기 위한 방안에 대한 고민이 깊어지고 있다.