사이버 보안 엔지니어로 일하던 시절, 매튜 로젠퀴스트는 여러 차례 좌절감을 겪었다. 회사의 주력 제품에 존재하는 취약점을 보고한 후, 자신의 팀을 해고한 CEO가 있었다. 보안 경험이 부족하면서도 이를 습득하려는 의지가 전혀 없었던 소프트웨어 엔지니어들이 있었습니다.
로젠퀴스트는 “그들은 스스로를 뛰어난 프로그래머라고 생각했고, 그걸로 충분하다고 여겼다”고 말한다. “그들은 ‘그건 내 문제가 아니야.’라고 말했다. “그냥 작동하게만 코딩해 놓고, 나머지는 보안 담당자가 알아서 할 문제야.”
그런 적대적인 태도는 이해할 만하다. 소프트웨어 개발자들은 반복적인 설계, 신속한 출시, 그리고 ‘최소 기능 제품(MVP)’이 지배하는 세상에서 일하고 있습니다. 시간을 절약하고 코드에 집중하기 위해, 그들은 보안을 비롯한 다른 사항들에는 별로 신경을 쓰지 않습니다. 그들은 이를 종종 일정이나 심지어 제품 자체에 걸림돌로 여깁니다.
[플랫폼 엔지니어링이 데브옵스(DevOps)와 어떻게 다른지, 보안 책임이 어디에서 분산되는지, 그리고 AI 도구가 도입되면 어떤 변화가 일어나는지 확인해 보세요]
“개발자나 엔지니어라면, 이것이 바로 여러분의 자식과도 같은 존재입니다.”라고 인텔에서 23 년을 근무했으며 현재 소프트웨어 암호화 기업인 Eclipz.io의 CISO를 맡고 있는 사이버 보안 전략가이자 이사회 고문인 로젠퀴스트()는 말합니다. “마감일이 있으시잖아요. 여러분이 정해진 기한 내에 코드를 제대로 작동시키는 능력을 기준으로 평가받고 있습니다. 여기에 여러분의 제품을 전혀 모르는 사이버 보안 담당자가 한 명 더 끼어들게 된다면 어떨까요? “내가 X, Y, Z를 하길 바라는 건가요?” “그러면 내 일정이 엉망이 되겠네.” 이러한 마찰은 점점 쌓여갑니다. “그보다 더 나쁜 건 보안 조치를 아예 취하지 않는 것뿐입니다.”
갈등을 해소하다
로젠퀴스트가 묘사한 이러한 마찰은 새로운 현상이 아니다. 이는 기업 내에서 오랫동안 지속되어 온 데브옵스 팀과 보안 팀 간의 갈등에서 비롯되었으며, 전 세계적인 보건 위기로 인한 어려움으로 인해 더욱 악화되었습니다. 수백만 명의 재택근무자들이 노트북, PC, 태블릿 등 수천만 대의 단말기를 통해 민감한 데이터 시스템에 접속함에 따라, 취약점과 보안 침해 사고가 급증하고 있다. According to a survey that Tanium released in 2020, North American businesses lose $700 billion a year as a result of IT downtime. 팀들 간의 갈등이 상황을 더 어렵게 만들고 있다.
하지만 그들은 함께 일해야만 한다. 예를 들어, ‘DevSecOps’라고 불리는 새로운 관행은 보안 팀 구성원과 프로세스를 소프트웨어 개발 수명 주기에 통합하여 취약점을 조기에 발견함으로써, 서로 대립하는 부서 간에 가교 역할을 하는 것을 목표로 합니다. 그럼에도 불구하고, 뿌리 깊은 문화적 문제와 보안 및 조직 구조 분야의 전 세계적인 인력 부족 은 여전히 팀 간 화합을 저해하고 있다. IT 리더들이 이러한 난관을 극복할 방안을 모색함에 따라, 경영진의 명확한 지지 확보와 협력적인 분위기 조성 등을 시작으로 몇 가지 모범 사례가 등장했습니다. 시작하는 방법은 다음과 같습니다:
최고 경영진부터 분위기를 조성하라
2001년에 마이크로소프트를 강타한 두 차례의 치명적인 웜 사태 이후, 빌 게이츠는 이듬해 전 사원을 대상으로 ‘ ’ 메모( )를 보내, 보안이 모든 제품의 코딩 과정에 필수적인 요소로 통합될 것임을 발표했습니다. 게이츠는 “기능 추가와 보안 문제 해결 중 하나를 선택해야 할 때, 우리는 보안을 선택해야 한다”고 적었습니다. … 현재 모든 개발자를 대상으로 최신 보안 코딩 기법에 대한 교육을 진행 중입니다. ... “저희 소프트웨어는 고객들이 보안에 대해 전혀 걱정할 필요가 없을 정도로 근본적으로 안전해야 합니다.”
그 결과, 이 회사는 획기적이며 수많은 기업에서 모방한 “보안 개발 라이프사이클()”을 탄생시켰는데, 이는 제품이 개발되고 성숙해가는 과정에서 보안 기능을 내재화하는 일련의 실천 방법론입니다. 그 이후로 기술 분야의 다양한 기업들이 이러한 보안 관행을 도입하고 상황에 맞게 조정해 왔습니다.
[관련 기사: 보안팀과 IT 운영팀 간의 긴장된 관계로 인해 기업이 위험에 처하다]
교훈: 제품 개발 라이프사이클에 보안을 위한 단계를 추가하면 일정에 상당한 영향을 미칠 수 있다. 게다가 상급자들이 이를 우선순위로 삼지 않는다면, 조직 하부에서는 이를 설득하기가 훨씬 더 어려워질 것입니다. 로젠퀴스트는 “최고 경영진부터 기업 목표와 부합하는 비즈니스 이해도를 갖춰야 한다”고 말한다.
““가장 상위 단계에서부터 기업 목표와 부합하는 비즈니스 이해력을 갖춰야 합니다.”Eclipz.io Inc의 최고정보보안책임자(CISO) 매튜 로젠퀴스트
데이비드 한( )은 이를 직접 목격했다. 실리콘밸리 은행, 미디어 대기업 허스트, 인튜이트 등 여러 기업에서 사이버보안 업무를 담당해 온 CISO로서, 그는 사이버보안 분야가 의사결정 과정에 반드시 참여해야 한다는 점에 대해 IT 리더들과 공감대를 형성하고, 궁극적으로 서로 협력해야 하는 다양한 역량 세트의 중요성을 각 팀에 전달함으로써 IT 리더들과 성공적으로 협력해 왔습니다. “나중에 와서 악역 역할을 맡을 수는 없는 법이야,”라고 그가 말한다.
책임 소재의 변화
이러한 격차를 해소하는 한 가지 방법은 보안을 개발 과정의 더 핵심적인 부분으로 만드는 것이다. EY의 연구에 따르면, 오늘날 기업의 약 3분의 2가 IT 프로젝트 초기 단계에서 보안팀을 참여시키지 않는 것으로 나타났다.
전문가들은 이러한 격차를 줄이는 한 가지 방법으로 “shift left” 방식의 소프트웨어 테스트를 도입하는 것을 꼽는데, 이는 개발 주기의 훨씬 초기 단계에서 테스트를 우선시하는 것이지, 사후에 억지로 덧붙이는 방식이 아니라는 것이다. 또한 보안 팀과 개발자 간의 협력을 의무화하진 않더라도 장려합니다.
그런 관행들은 기존의 부서 간 장벽을 허물어 주는 데 도움이 됩니다. “새로운 팀을 구성하는 것이 핵심입니다,”라고 한은 말한다. “누구나 개발, 보안, 운영 분야의 역량을 갖춰야 하지만, 어떤 사람들은 다른 사람들보다 특정 분야에 더 많은 경험을 가지고 있을 것입니다.”
그들을 그곳으로 이끄는 한 가지 방법은 교육을 통해 하는 것입니다. 한 씨는 소프트웨어 개발자들에게 보안 기술을 습득할 기회를 제공하는 것이 “성장 기회”라고 말합니다. 마찬가지로, 많은 보안 분석가들도 기본적인 코딩을 배우면 도움이 될 것입니다. 영국에 본사를 둔 소프트웨어 개발사 소나타입(Sonatype)의 보안 연구원이자 엔지니어인 액스 샤르마(Ax Sharma)는 “Go나 파이썬(Python) 같은 프로그래밍 언어를 통해 절차적 프로그래밍과 소프트웨어 개발의 복잡한 측면을 이해하는 것부터 시작할 수 있다”고 말했다. “이를 통해 보안 부서가 팀의 성과물 달성에 기여할 수 있다는 점에 대한 회의감을 줄이는 데 도움이 될 것입니다.”
DevSecOps: 보안과 개발에 대한 새로운 사고방식 모색
앞으로 몇 년 동안 보안 팀과 소프트웨어 개발 팀이 새로운 화합의 정취를 느낄 수 있게 된다면, 그 이유는 부분적으로 그들이 소프트웨어 개발자와 IT 운영 팀 사이의 오래된 갈등을 해소하는 데 엄청난 성공을 거둔 업무 방식을 받아들였기 때문일 것입니다. 지난 10여 년 동안 개발자들은 IT 운영팀과 훨씬 더 긴밀하게 협력하여 두 부서의 업무를 통합하고, 그 어느 때보다 신속하고 효율적으로 새로운 소프트웨어를 출시해 왔습니다.
GitLab에 따르면, ‘데브옵스(DevOps)’라고 불리는 이 방법론은 현재 기업 조직의 약 62% 가 어떤 형태로든 도입해 실천하고 있는 것으로 추정됩니다. DevSecOps는 이러한 개념을 바탕으로, 보안 테스트를 개발 과정이 끝난 후가 아니라 개발 과정 중에 수행하도록 합니다.
DevSecOps는 단순히 보안 팀을 프로세스 초기에 참여시키는 데 그치지 않고, 전체 구성원이 위험 허용 범위를 함께 모색할 수 있도록 합니다. 사이버 보안 담당자들이 개발 속도를 늦출까 우려하는 소프트웨어 엔지니어들에게, 한은 모든 구성원이 같은 인식을 공유하고 코드 개발을 원활하게 진행할 수 있는 방법이 있다고 말한다. 바로 취약점을 조기에 발견하지 못할 경우 어떤 일이 벌어지는지 그들에게 명확히 설명해 주는 것이다. “위협 모델을 도입해야 합니다,”라고 그가 말한다. “구상을 시작하면, 그것이 실체 있는 것이 됩니다.” “이는 공학적 논의가 되는 반면, ‘데이비드의 의견은 별로였고, 난 그게 마음에 들지 않아’라는 식의 반응과는 달라집니다.”
위협 모델은 양측 모두에게 타협점을 모색할 수 있는 방법을 제공합니다. 예를 들어, 소프트웨어 엔지니어들은 자사 고유의 기록이 모두 포함된 데이터베이스를 갖춘 신제품의 MVP나 베타 버전을 개발하는 데 열의를 보이고 있다. 보안팀은 취약점에 대한 전면적인 테스트가 완료될 때까지 해당 데이터베이스가 제품과 어떤 형태로든 연관되지 않기를 원합니다. 위협 모델은 미완성 제품에 민감한 데이터를 포함시킬 때 내재된 위험 요소를 지적할 수 있다.
그리고 나서 보안팀이 나서서 목소리를 내야 합니다. “그들은 ‘우리는 그런 위험을 감수할 필요가 없다’고 말해야 합니다. “가짜 데이터를 넣을 수도 있겠죠,”라고 한 씨가 말했다. EY 보고서 역시 보안 팀이 이러한 위험에 대해 더 효과적으로 소통할 수 있다고 지적하고 있다.
양측을 하나로 모으는 과정에서 샤르마는 모든 제품의 보안 절차 현황과 위협 수준을 점검하는 등 소규모 노력부터 시작할 것을 제안합니다. 이를 통해 취약점이 어디서 발생하는지에 대한 인식을 높일 수 있을 것입니다. 그런 다음 두 팀은 의 보안 자동화 도구(예: 악성코드 탐지 소프트웨어)를 활용하여 남아 있는 취약점을 찾아낼 수 있습니다. 샤르마는 “노력을 시작한 첫 달을 ‘관찰 단계’로 삼아, 팀원들이 그 효과를 확인하고 협력하며 낭비를 제거하기 위해 지속적으로 개선해 나가도록 하라”고 말합니다.
일이 엉망이 될 때
가끔은 일이 잘 풀리기도 합니다. 반면, 그렇지 않을 때도 있습니다. 한 씨는 양측이 협력하지 못할 때 두 가지 원인을 찾아봐야 한다고 말합니다. 바로 프로젝트의 일정과 진행 과정을 어긋나게 만드는 ‘범위 확장’과 ‘자아’입니다. “즉, 사람들이 스스로 합의한 원칙을 지키지 않는 것과 같은 경우죠,”라고 그는 말한다.
그 시점이 되면, 출시 일정을 미루게 되더라도 개발을 잠시 중단해야 할 때입니다. 한 씨는 “프로젝트 일정을 두 달이나 늦추게 만드는 보안 취약점을 발견하는 편이, 공개 출시 후 잠재적인 재앙에 직면하는 것보다 낫다”고 말한다.
Eclipz.io의 CISO인 로젠퀴스트는 “항상 대가가 따르기 마련이다”라고 말했다. “하지만 손실을 최소화하거나 규제 준수를 보장하고 있는 것이죠.” 그는 보안팀과 IT팀을 하나로 통합하는 것이 직원들에게만 유익한 것은 아니라고 덧붙입니다. “이는 경쟁 우위가 될 수 있습니다.”
