본문 바로가기

Security Indicator/Insight

[히스토리-3] 개발과 보안의 간극 그 해소에 대해

개발 스케줄이 타이트하게 이어지고 있고, 오픈된 서비스의 운영은 정신없이 계속되고 있었다. 그 어디에도 보안이라는 부분은 들어갈 곳이 없었다.  보안사고가 발생되어도 그것은 개발과는 관련 없는 별개의 영역이라 인식하는 것이 대부분이었다.  그렇다고 소스 레벨의 보안적인 이슈를 지적하는 것도 쉬운 일은 아니었고..

 

2005년 무렵 서비스 회사에 들어온 이래 온라인을 통해 원인 제거 (보안패치), 현상 제거 ( 온라인 백신)를 실행하였지만 그렇다고 근본적인 문제가 해결된 것은 아니었다.  사용자들에게 감염되는 악성코드들은 더 이상 메일이나 수상한 파일을 통해서 감염되는 것도 아니였으며, 전체 인터넷을 대상으로 취약한 서비스에 접속하는 모든 사용자들은 즉시 감염에 노출되고  패치가 되어 있지 않다면 그 즉시 감염이 발생되고 있었다. 감염의 원인과 현상의 제거에는 도구를 통해 진행하고 있었지만 근원적인 문제인 서비스의 취약성은 별개의 문제였다.  또한 살인적인 스케줄에 매일 야근을 일삼는 개발 조직에 단순히 보안검토를 이유로 서비스 오픈 지연을 하는 것도 할 수 없는 일이었고..

 

개발과 보안의 간극은 명확했다.

서비스의 개발과 운영은 분리되어 있고, 보안은 그 연장선상에서 보조적인 운영 서비스였을 뿐이었다.  그 어디에도 보안 취약성에 대해서 논의하지 않았으며 무엇보다도 빠른 개발과 서비스의 개시만이 목적이었을 뿐이었다.  보안 부분은 문제의 현상을 본질적으로 직시하지 못하였고, 사고가 발생된 이후에 로그를 기준으로 사후 대응을 할 뿐이었다. 즉 개발단계에서부터 보안을 적용한다는 것은 사실상 무리였고, 절차적으로도 들어갈 요소는 없었다.  또한 개발을 경험해본 보안인력들도 전무한 상태에서 단지 침입탐지와 방화벽의 로그, 공격 흔적을 역추적하는 형태를 벗어나지 못하였고, 탐지되지 않는 위협에 대해서는 대응할 수 조차 없던 상황이었다.  지금도 별반 다르지는 않지만 아예 기반이 전무한 상태였음은 두말할 필요도 없었다.

 

개발과 보안은 완전히 다른 영역으로 구분되어 있었고, 보안은 운영에 가까운 모델로 존재하고 있었다. 

 

개발의 이해

빠른 개발이 미션,제한된 기간

보안 이슈는 운영상의 이슈

서비스를 만드는 것이 먼저임

보안은 별개 영역이고, 개발과 관련되지 않는다.

 

보안의 이해

개발은 개발자의 문제

보안은 사고 이후 대응 중심

개발은 너무 어려워

소스를 수정 가이드 하는 것은 역량을 벗어나는 부분

 

각자의 부분에서 혼합되지 않고 있었고, 지금도 여전한 부분들이 있을 것이다.

이 영역의 한계를 벗어나야만 서비스의 문제를 서비스 오픈 이전에 체크하고 수정할 수 있으며, 이후 사고 발생 가능성을 급격히 낮출 수 있는 것은 명확해 보였다.  그러나 문제는 서비스의 개발기간도 타이트한데 거기에 보안성 검토를 할 수 있는 시간은 너무 없다는 점이 문제였다.  또한 Penetration test 정도가 할 수 있는 보안성 검토이지만 모의해킹의 영역으로 넘어가면 그 점검의 수행 시간도 길어지고, 또 실시자의 역량에 따른 현격한 편차가 발생될 수밖에 없다.

 

모의해킹을 보안성검토로 하기엔 다음과 같은 현실적 문제가 존재했다. 지금도 별반 다르지 않다.

점검 시간, 점검 인력에 따른 편차 발생, 서비스 장애 가능성, 이행점검에 따른 추가시간 소요.

무엇보다 중요한 것은 개발기간도 부족한 상황에서 보안성 검토를 할 여지는 없었다고 봐야 된다. 서비스의 성공이 전제된다면 검토를 할 여지는 충분하겠지만 , 서비스의 빠른 출시와 추가 개발이 더 중요한 상황에서 서비스의 성공과 별반 관계없어 보이는 보안성 검토는 의미 없는 태클로 보일 수밖에 없는 상황이 현실이다. 

 

보안성 검토, 보안 검수, 모의해킹, Penetration Test , Secure programming

지금이야 보안검수라는 용어로 통일되어 있었지만 개발과 긴밀하게 연계된 상태에서 보안성을 확보하고 서비스를 출시한다는 것은 여전히 많은 오버헤드를 발생시킨다. 충분한 검토의 시간이 필요하고 서비스의 안정성에 영향을 주지 않는 상태에서 점검을 수행해야 한다.  여기서 충분한 검토의 시간이 주어지는 것에 대해 상당히 오랜 시간이 걸려 이제 상호 간에 이해가 어느 정도 공존하는 상태가 지금의 상태가 아닐까 싶다.   새롭게 만들어지는 서비스들에 대해서는 가능하지만 기존의 서비스들은 과연 어떻게 할 것인가? 하는 문제는 너무나도 현실적인 이슈이다.

< 보안성 검수라는 이름으로 개발조직을 설득하기 위해 만든 Flow>

 

위의 Flow는 서비스 개발 완료 단계에서 보안조직이 의뢰를 받아 검토하고 수정하며, 재점검을 통해 서비스가 릴리즈 되는 것을 보여주고 있다.  설득은 쉽지 않았고, 주어지는 시간은 매우 제한적일 수밖에 없었다.

 

다시 2000년대 중반으로 돌아가보자.

문제는 명확했다. 관리도 되지 않는 수많은 서비스들은 누가 운영하는지도 모른 채 방치되고 있었고, 계속해서 새로운 서비스들은 릴리즈 되고 있었다.  그중에 어떤 서비스가 공격을 받는지조차 파악도 안 되는 상황에서 서비스의 보안을 기획하고 보안성을 확보해야 하는 상황에서 문제를 풀 수 있는 실마리도 보이지 않을 때였다.  물론 지금도 체계가 갖추어진 보안 부서를 가진 기업들을 제외하고는 별반 다르지 않을 것이다. 시간이 오래 지났음에도 불구하고 말이다.

 

문제의 핵심

수많은 레거시 서비스들은 어떻게 점검하고 문제를 고칠 것인가?

서비스 개발 완료 시점에 보안적인 검토의 flow를 어떻게 넣을 것인가?

점검에 필요한 인력은 있는가?

개발 부분에 가이드할 역량 있는 전문가들을 확보했는가?

문제를 확인한 이후 해결 방안은 제한된 인원으로 두 가지 방향으로 병행해야 하는 상황임을 인지한다.

 

1. 하나는 보안성 검토라는 Flow를 개발 주기에 밀어 넣는 것이었고, 이 Flow를 SDLC라 칭했다. 서비스의 오픈 시점에는 반드시 서비스 가동을 점검하기 위해 QA process가 필요했으며, 단순한 기능의 점검에만 그치고 있었다. 이 단계 이전에 Security Check를 Flow 하여 운영을 하도록 하였다.  물론 무한정한 시간을 들일 수는 없었기에 특정 문제점에 대한 빠른 진단과 검토를 통해 시간적인 제약을 극복하도록 하였다.

 

2. 광대하게 분포된 레거시 서비스들에 대한 보안은 다음과 같이 진행하였다. 우선 전체 서비스의 현황을 파악하고, 최신의 공격 기법들을 역으로 분석하여 해당 취약점이 존재하는지를 체크할 수 있도록 도구를 제작하였다.  그 이후 자동화된 도구를 이용하여 정말 빠르게 대규모 레거시 서비스들에 대해 반복적이고 지속적인 점검을 수행하였으며, 점검 결과는 서비스 카테고리별로 분류화하여 해당 개발 조직 전체로 전달하였다. 그리고 매주 , 매월의 정기적인 리포트는 문제 발견 수치와 개선된 부분들을 그룹핑하여 보고를 하였다.   자동화된 도구의 취약점은 급한 것부터 시작하여 점진적으로 확대하여 진행하였으며 전체적으로 보았을 때  80%가량의 서비스가 치명적인 취약성을 가지고 있었으며, 6개월간의 반복적인 검사와 결과를 공개함으로써 이 수치는 20%가량대로 떨어질 수 있었다.  이제야 특정 서비스를 대상으로 한 정밀한 검사가 가능한 상태가 되었다고 판단했다.

 

1의 단계를 통해 서비스 오픈 이전에 보안 검수라는 절차를 도입하여 체계화하였으며, 2의 단계를 통해 레거시 서비스들에 대한 시급한 보안성을 확보하고  개선되지 않는 서비스에 대해서는 클로즈를 유도하며, 전체적인 현황을 관리할 수 있도록 하였다. 

 

이렇게 글로써는 간략히 언급하지만 모든 과정이 쉽지는 않았고, 지금의 시대에서도 개발 Flow와 레거시 서비스들에 대한 대응은 어려울 수밖에 없다. 길고 지난한 과정을 거쳐 완성된 현황은 다음과 같다.

 

내부로 침입하거나 서비스를 공격하는 형태를 막기 위해 기존에 없었던 부분들을 단계적으로 도입하는 것이 아니라 일시에 도입하여 운영을 하였다. 지금처럼 솔루션이나 서비스가 있는 것이 아니기에 자체 제작 및 서비스 설정을 가이드하여 완료할 수 있었다.  이미지에 있는 서비스 형태의 운영을 위해서는 1년이 넘는 시간이 소요되었으며 그제야 관리와 운영에 집중할 수 있게 되었다. 어쩌면 파격적이고 한 번의 어긋남이 있었다면 바로 낭떠러지로 떨어지는 길이였지만 문제의 현상을 보았을 때 이 방법 외에는 할 수 있는 것은 거의 없었다고 지금도 생각한다.

 

남겨진 문제와 고민들

반복되는 개발 습관의 해결

Secure coding을 강요하는 것이 아닌 개발자가 셀프 체크할 수 있는 서비스의 필요성

서비스 개발을 발목 잡는 보안 정책과 개발 가이드의 갱신과 현실적인 가이드

개발을 알고 이해하는 보안전문가의 양성

필요한 것은 자체적으로 구현할 수 있는 역량의 필요성

( 이 고민들을 해결하기 위해 이후 오랜 기간 서비스를 만들고 직접 운영하기도 했었다. 물론 야생에서..)

 

보안 검수라는 무조건적인 절차를 준수하라고 하기 위해서 필요한 보안조직들은 다음의 요소들이 필수적일 것이다.  

. 평균적인 역량의 확보 (진단 수준의 일정함)

. 개발과 보조를 맞추는 진단기간 ( 개발이 메인인 것은 명확하다. 보안은 그 완성도를 높여 주는 방향으로 접근해야 한다. 규제와 규정을 빌미로 제한을 하게 되면 더욱더 스텝이 엉킬 수밖에 없다. )

 

지금에 와서야 보안 검수는 일상적인 flow라고 할 수 있지만 여전히 문제 해결보다는 형식적으로 거쳐야 하고 비용을 많이 들일 수밖에 없는 구색이라는 평가도 여전하다 할 수 있다.  자체적으로 개선이 되지 않으니 규정이 생기고 규제가 생기지만 이로 인해 보안은 서비스에 내재화되지 못하고 구색을 맞추는 요건에 해당하는 이슈들도 많이 보이고 있다.  야생의 시대에서 보안 서비스를 정착하기 위해 노력하였지만 지금의 모습은 어색할 따름이다. 여전히 개발과 분리되어 있는 듯하다. DevSecOps가 있다고 한다. 개발과 보안과 운영에 대한 Flow인데  최소한 DevSecOps를 이야기하려면 중심점을 Dev에 두고 고민하는 것이 필요하다.  개발, 보안, 운영이 각각 별개로 존재하는 것이 아니라 유기적으로 연결하기 위해서 보안이 중간의 교차점 역할을 하는 것이 훨씬 중요하다 볼 수 있다.  유기적으로 연결을 하는데 규정을 무조건 따르라고 한다면 교차점의 역할이 아니지 않을까?  또한 보안 분야에서는 개발 역량을 가지고 실제 개발 부분에서 도움이 되고 즉시 활용할 수 있는 서비스들에 대해서 고민하고 제안해야 되지 않을까?   2022년 현재 그런 고민은 많이 보이지 않는다.

 

오래된 경험을 회고하는 것이지만 지금에도 필요한 부분은 있을 것이다. 보안 검수라는 용어가 없을 때부터 어렵게 정착시킨 Flow이지만  개발과 발전을 같이 하지 않고 내재화되지 않는 보안은 언제든 겉돌 수밖에 없을 것이다.  

 

* 다음은 또 다른 주제로 이어 보겠습니다. 그럼