보안을 전략적 이점으로 재해석

Clarke(00:05):
나와 주셔서 감사합니다.

Merritt(00:08):
불러 주셔서 감사합니다.

Clarke(00:09):
경력에 대해 조금 얘기해주시겠어요? AWS에는 어떻게 들어오게 되었고 현재 역할에서 어떤 일을 하고 계신가요?

Merritt(00:15):
예. AWS에 입사한 지 거의 4년이 되었습니다. 그 전에는 미국 정부에서 미국 시민을 위한 보안 업무를 맡았고 3개 지사 모두에서 일했습니다. 보안 관련 직종을 택한 이유는 해결해야 할 중요한 과제들이 있는데, 그러한 과제를 처리할 강력한 방법이 없다고 느꼈기 때문입니다. 그래서 법학을 전공했는데, 부분적인 이유로는 법학이 오늘 다룰 현안 중 하나와 관련된다는 것을 알았기 때문입니다. 또한 보안 문제가 일회성으로 위협을 식별하거나 한 범죄자의 위협 하나를 식별하는 것보다 더 중요해질 것이라고 생각했습니다. 그 결과로 제 생각에 진부하다고 여겨지는 보안 영역에서 일하게 되었어요. 인프라 계층에 있지만 뒤에서 더 중요한 역할을 해야 한다는 생각으로 여기까지 오게 된 것 같습니다.

Clarke(01:08):
멋진 이야기네요. 그럼 CISO 사무국에 대해 좀 더 이야기해 주시겠습니까? AWS의 관점에서 사무국이 지향하는 목표는 무엇인가요?

Merritt(01:17):
예. 저는 CISO 사무국의 국장입니다. AWS의 최고 정보 보안 책임자(CISO) 사무국은 여느 기업과 비슷합니다. 제 상관인 Steve Schmidt 씨는 AWS의 자체 보호 방식을 의미하는 내부 보안은 물론, 회사 전체로서 우리가 제공하는 모든 제품과 서비스의 보안 방식을 총괄합니다. 그 과정에서 상당히 흥미로운 결과물이 나오는데, 가드레일을 구축할 방법과 직원 마찰을 최소화할 방법을 개발 팀의 입장에서 생각해 봐야 하기 때문입니다. 또한 개발 팀에서 가장 안전하고 쉬운 방법으로 최대한의 보호를 제공할 수 있도록 지원해야 하죠. 제 역할은 공감과 신뢰성을 바탕으로 고객과 대화하는 것인데, 제 일의 절반은 AWS의 보안을 개선하는 것이고 나머지 절반은 고객과 대화하는 것이기 때문입니다. 이 대화는 공개적인 대화일 때도 있지만 대부분은 CISO와 CISO 간의 대화이며 보안 그룹과 함께 기업의 성숙도를 지원할 방법을 논의하는 과정이라고 할 수 있습니다. 대부분의 경우 보안은 더 광범위하고 더 빠르고 더 성숙한 방식으로 나아가는 데 필요한 핵심 요소 중 하나입니다. 동전의 다른 면을 생각해 보면 보안은 종종 장애물로 인식됩니다. 이러한 인식은 좋지 않습니다. 보안 팀의 성장과 발전을 방해할 뿐 아니라 요즘, 특히 클라우드에서는, 아시다시피 개발을 시작하는 순간부터 ID와 권한을 연결시키고 나머지 아키텍처와 나머지 인터넷과 관련하여 이를 구성할 방법을 모색하기 때문입니다. 구축하는 모든 것에 보안 속성이 내재되어 있어요. 이 말은 보안을 대화 안에 끼워 넣어야 한다는 것을 의미하며 고객에게 그 방법을 설명해야 함을 의미합니다.

Clarke(03:23):
그렇군요. 고객 측 CISO와 대화를 하다 보면 다른 책임으로 이어질 것 같은데요. 가령 CISO가 “X 또는 Y 제품이 마음에 드는데 이 기능을 제공했더라면 좋았을 텐데...”라는 말을 한다면 이 문제 또한 Merritt 씨가 담당하는 보안 스택에 해당하지 않습니까? 고객이 대화 중에 하는 이러한 말은 보안 서비스 제품 팀에 어떻게 전달되고 실제 기능을 구현하는 데 어떻게 반영됩니까?

Merritt(03:51):
아시다시피 서비스 팀에서는 항상 새로운 기능을 구현하고 배포합니다. 따라서 실제 과제는 제품과 서비스에서 이들이 결정했거나 투자할 수 있는 것을 따라가는 것이 아니라 문제를 해결하는 방법에 관한 것입니다. 만약 문제가 올바른 방식으로 해결되고 있지 않다면 그때는 개입해야 하겠죠. 대부분 제 일은 첫째, 고객의 실제 요구 사항을 파악하고 성숙도를 개선하거나 결과를 개선하는 데 필요한 도움을 주는 것입니다. 둘째는 그 방법을 결정하는 것이죠. 고객들은 저와 대화할 때 “귀사에서는 이 일을 어떻게 조정합니까?”라는 질문에 대한 답을 얻고자 합니다. 저는 제로섬 게임을 믿지 않으며 진정한 공감대를 형성하는 데 가치가 있다고 봅니다. 

Clarke(04:51):
좋은 말입니다. 고객들은 "AWS에서는 X를 할 때 어떻게 합니까?"라거나 좀 더 일반적으로 "AWS는 어떻게 합니까..."라면서 보안 관점에서 이러한 유형의 질문을 하지 않습니까?

Merritt(05:07):
지금까지 가장 중요한 질문은 혁신과 관련된 것입니다. “개발 팀에서는 어떻게 혁신하고 보안 팀에서는 개발 팀과 어떻게 원만한 관계를 유지합니까?” 이 질문은 우리가 하는 일에서 가장 두드러진 부분과 관련됩니다. 이처럼 빠른 속도의 혁신을 추구한다는 것은 릴리스 속도가 아주 빠르거나 새로운 것을 알아내기 위해 팀원들이 아주 열심히 일하고 있음을 의미합니다. 이러한 메커니즘의 공동 목표는 보안입니다. 투 피자 팀(피자 두 판을 한 끼로 나누어 먹기에 충분한 소규모 팀)은 의도적으로 사일로화된 팀을 함축적으로 의미하는데, 궁극적으로 우리가 하는 일은 이 투 피자 팀을 비즈니스 결정으로 빠르게 움직이고 이 투 피자 팀 아래에서 보안에 관한 비즈니스 의사 결정을 내리는 것입니다. 따라서 구성 요소의 작동 원리를 알게 되는 사람은 소수에 불과합니다. 여기에는 AWS의 운영 방식에 대한 보안 요소가 있습니다. 사실, 고객과 하는 대화는 AWS의 제품 안에 보안을 적용한 방식에 관한 것이지, 이를 개혁할 보안 팀으로서 이들과의 관계에 대한 이야기는 하지 않아요. 고객들은 “귀사에서는 어떻게 보안을 제품의 살아있는 일부로 만들었습니까?”라고 묻습니다.

Clarke(06:38):
완벽하게 이해가 되는군요. 고객은 이런 질문을 자주 하죠. 아마 같은 질문을 들으셨을 것 같은데요. "DevSecOps의 가치를 이해합니다. 엔지니어링과 운영 보안, 그리고 보안의 다른 모든 요소에 리소스를 투입하는 것의 가치를 이해합니다. 그런데 AWS와 같은 세계적인 수준의 보안 조직을 만들려면 어떻게 해야 합니까?”

Merritt(07:05):
예. 이 질문은 많은 형태로 나오는 것 같습니다. “인시던트 대응 계획을 시행한 적이 있는지 모르겠다”거나 “인시던트 대응 계획이 있는지 모르겠다”라는 형태를 띨 수 있습니다. 결국 이 질문은 자산의 수명 주기를 따르는 제어에 관한 것입니다. 인프라는 이 제어 프로세스를 통해 구축하는 것이고 Clarke 씨의 관점에서 보자면 탐지 제어와 교정 제어가 더 적절하겠네요. 이 제어 요소는 항상 자동화로 연결됩니다. 예를 들어 AWS 보안 팀은 가능한 경우 교정 내용을 스크립트로 만들기 전까지 문제 티켓을 종결하지 않습니다. 자동화는 관측 가능한 방식으로 구현하기 전까지의 립 서비스처럼 들리는데, 우리가 결국 기대하는 것은 운영을 확장하는 방식입니다. 이러한 보호, 탐지 및 교정 제어로 인해, 모든 자동화를 관리하는 담당자가 24시간 지원을 위해 대기하고 있습니다. 차세대 보안 운영 센터를 수용하면 아주 자유로워집니다. 언덕 위의 도시 같은 것일 수 있지만 어디서든 시작하세요. 이득이 있거든요. AWS에는 큰 문제와 작은 문제를 해결하는 보안 팀이 있습니다. 그러니 어디서든 시작하세요. 자동화에 능숙한 직원을 채용하세요. 다양한 생각을 가지고 있고 다양한 코드, 다양한 자동화로 문제를 해결하는 팀을 채용하세요. 그 과정에서 경영진의 동의도 얻어야 하겠죠. 이 프로세스에서는 기업 또는 기업과 동일한 방식으로 운영되는 공공 부문 엔터티가 보안 프로세스에 하는 투자에 대해 이야기해야 하므로 이 동의가 매우 중요합니다. 이 동의는 특정 방식과 행동으로 이행되어야 합니다. “세계적인 수준의 보안 팀을 만들려면 어떻게 해야 합니까?”라거나 “혁신 문화는 어떻게 구축합니까?”라는 질문을 하는데, 우리가 반복적으로 하는 일이 그것입니다. 그래서 관계가 있는 일들이 있고 몇몇 일에서는 연결 고리를 제공할 수 있습니다. 예를 들어 DevSecOps에서는 팀에 보안 엔지니어를 비례해서 배정하는데, 지금은 8명 중에 1명을 배정하지만 더 많아지거나 적어지기도 하죠. 우리는 이 수가 적정한지 여부를 평가하는 일을 합니다. 일이 잘못되거나 계획대로 되지 않을 때마다 오류의 원인을 찾는 일을 하는데, 오류의 원인에 대한 이 회의에는 VP가 참여합니다. 중간급 엔지니어를 보내 이 일을 처리하게 하지 않습니다. 책임감의 생태계를 만드는 것이죠. 이 일을 맡은 개인을 위해서가 아니라 조직을 위해서요. 학습 곡선을 지속적으로 늘리는 것이 우리의 목표입니다. 이 일은 우연히 일어나지 않습니다. 메커니즘을 만들어야 하죠.

Clarke(10:22):
목표로 하는 행동을 강화하는 메커니즘을 개발하는 것이군요.

Merritt(10:28):
맞습니다. 예를 들어 Amazon에서 하는 것처럼 직원에게 아주 개방된 권한을 주기로 선택한다고 합시다. 이 역시 신중한 비즈니스 의사 결정인데요. 그러면 아주 세부적으로 활동을 로깅하고 모니터링하는 수단을 갖추어야 합니다. 그런 다음 이를 임계화하고 일정에 따라 그 누구도 비난하지 않는 에스컬레이션하는 절차가 있어야 해요. 여기에도 경영진이 개입되어야 하는데, 보안에 대한 질문에 답을 해야 하는 사람은 경영진이기 때문입니다. 모든 경영진이 자신들은 보안에 신경을 쓴다고 말하지만 실제로 경영진이 하는 일은 보안을 지원하고 회의에 참여하는 것이죠. 그리고 보안 팀은 비즈니스 자체에서 여러 역할을 맡게 됩니다.

Clarke(11:26):
그렇군요. 이전 질문의 대답에서 투자에 대해 언급하셨는데, 고객의 CISO와 경영진은 "기능에 투자하려고 한다"는 말을 하죠. 보안 관점에서 AWS는 수년 간 최소 보안 기준에 대한 5개의 핵심 개념을 분명히 하고 있습니다. ID, 탐지 제어, 인프라 보안, 데이터 보호, 인시던트 대응이 그것인데요. 고객 측 CISO가 "예산과 인력이 부족하지만 이 5가지를 모두 해야 하는데, 무엇에 먼저 투자해야 합니까?”라고 묻는다면 이 5개 중에서 가장 중요한 것은 무엇일까요?

Merritt(12:09):
“워크로드 하나에서 시작합니까? 100개에서 시작합니까?”라고 묻는 CISO가 꽤 있습니다. 그렇죠? 저는 어디서든 시작하고 이를 의미 있게 만들어야 한다고 생각합니다. 많은 수의 워크로드에서 시작해도 되지만 몰래 해서는 안 됩니다. 보안이라는 현미경 아래에서 해야 해요. 이렇게 하면 플랫폼 관점에서 기업 또는 엔터티의 비즈니스 차별화 요소로 작용하는 보안이라는 유산을 가지게 됩니다. 단순히 백업을 한다는 말은 이제 우습게 들릴 것입니다. 클라우드가 무엇인지 생각해 보세요. 20년 전에는 책상 아래 불법 서버를 확인하는 것만으로 이 5개 단계를 수행했습니다. 이제는 더 이상 하지 않죠. 적어도 클라우드를 사용한다면 할 필요가 없습니다. 보안 유산이 있다는 것은 AWS가 이 스택의 최하위 계층을 책임을 진다는 것을 의미합니다. 클라우드를 활용하여 클라우드 규모의 보안을 수행하는 것이 시급합니다. 하지만 현실은 그렇지 않은 고객이 많아요. 예산이 제한적이라면 이 규모를 활용할 수 있는 클라우드 상태로 들어갈 이유가 더 많아집니다. 하나를 골라야 한다면 ID가 가장 어렵다고 말할 수 있어요. 그럼에도 “지금 사용 중인 ID 제공업체에 만족하고 잘 하고 있다고 생각한다”고 말하는 고객이 많습니다.

Clarke(13:40):
자금이 부족하다면 ID에 투자해야 한다는 말인가요?

Merritt(13:45):
자금이 부족하면 비즈니스 목표가 무엇인지 파악한 다음 보안이 비즈니스 차별화 요소인 이유를 설명해야 합니다. 제가 말하는 보안은 생산하는 제품에 대한 것이 아니라 제품의 일부인 보안입니다. 소매업체거나 정유 회사거나... 자동차, 제약, 미디어 엔터테인먼트, 인수 합병 기업 등 어떤 회사든 현 시대에 사람들이 중요하게 생각하고 또 그렇게 해야 하는 것은 비즈니스의 보안입니다. 보안 제품을 제공하는 사람도 아니고 HR 역할에서 내부 데이터를 관리하는 방식도 아닙니다. 제품의 내재된 부분으로 보안을 어떻게 제공하고 있는지가 중요하죠. 이것은 임시방편으로 해낼 수 있는 일이 아닙니다. 실제 기업을 세우고 목표를 수립하는 방식에서 시작되어야 해요. 그리고 예산에서 이를 고려해야 하죠. 이제는 더 이상 보안을 비용 센터로 간주해서는 안 됩니다. 사실 보안은 비즈니스 조력자이자 비즈니스 동인입니다. 안전하지 않은 일을 하고 싶어하는 사람은 없어요. 안전하지 않은 것을 사려는 사람도 없고요. 안전하지 않은 회사 또는 정부와는 누구도 함께 하고 싶어하지 않습니다. 솔직히 말해서 안전하지 않으면 시작도 말아야 합니다. 물론 목표는 변경될 수 있습니다. 이것은 하나의 과정이고 지속적인 작업이지만 노력이 필요해요.

Clarke(15:24):
보안을 비즈니스 조력자로 인지하려면 CISO 조직을 비용 센터로 보는 CISO 또는 조직이 조직의 이사회 또는 다른 의사 결정권자에게 이 메시지를 어떻게 전달해야 할까요?

Merritt(15:42):
몇 가지 요소가 있습니다. 하나는 성장하고자 하는 기업 안에서 일어나는 일반적인 변화입니다. 전반적으로 기업은 이전 비용에 너무 집착하는 경향이 있습니다. 그러면서 현 상태에 머무르는 것의 비용은 알아보지 않죠. 이 시점에서는 현상 유지로 인해 발생하는 비용과 지금 이전하지 않고 할 수 있는 것을 하지 않음으로써 지불해야 하는 비용을 살펴봐야 합니다. 솔직히 말해서 거기에 도달하려면 대담함이나 긍정적인 에너지가 필요하겠지만 거의 즉시 결과를 얻게 됩니다. 또한 이것은 조직이 기업으로 성장할 수 있는 방법 중 하나가 될 것입니다. 이를 미루는 것은 시간 낭비일 뿐입니다. 게다가 보안을 비용 센터로 인지하는 것은 과거의 잔재입니다. 

Clarke(16:53):
예. 무언가를 하지 않는 것은 회사가 보는 다른 위험과 똑같이 위험하다는 설명에서 요점을 잘 집어주신 것 같습니다.

Merritt(17:01):
똑같다기보다 더 비싸다는 표현이 맞겠죠. 이사회에 말할 때는 이 점을 고려해야 해요. 보안 지표를 말할 때 사람들은 이를 게임화하는 경우가 많은데, 예를 들어 “지난 주에 100번의 노크 소리를 들었는데 이번 주에는 70번만 들렸다”라고 할 수 있어요. 이것은 여기에도 없고 거기에도 없는 노크 소리와 같아요. 이러한 숫자는 인공적인 것이죠. 제가 방금 만들어낸 것이에요. 요점은 보안 지표는 개선 여부를 보여주는 진짜 곡선을 제공해야 한다는 것입니다. 그렇지 않으면 잘못된 지표입니다. 실제로 게임화하는 사람이 누구죠? 지치는 것은 당사자예요.

Clarke(17:50):
랜섬웨어는 오늘날의 중요한 주제입니다. 고객이 크게 우려하는 문제죠. 이 영역에서 전문 지식을 가지고 계신 것으로 알고 있는데요. 랜섬웨어 이벤트에 대비하기 위해 고객의 보안 조직에서 해야 할 일에 대해 몇 가지 조언을 해주실 수 있습니까?

Merritt(18:07):
예. 최근 뉴스에 자주 등장하죠. 하지만 랜섬웨어는 새로운 것이 아닙니다. 최소 1989년부터 시작되었어요. 한 의료 컨퍼런스에서 나쁜 사람 몇 명이 “AIDS”라는 레이블이 붙은 디스크 드라이브를 나눠 준 일이 있었습니다. 의료 컨퍼런스였으니까요. “AIDS 랜섬웨어”로 알려진 이 디스크를 드라이브에 삽입하면 파일이 암호화되었고 파나마의 사서함으로 89 USD를 보내야 했죠. 랜섬웨어 자체는 이론상 새로운 것이 아니지만 암호화폐의 부상에 편승해서 네트워크에 침투할 수 있다는 사실을 이용해 이익을 취하려는 이들에 의해 악용되고 있습니다.

Clarke(18:58):
랜섬웨어는 서비스죠?

Merritt(19:01):
예. 그리고 돈이 된다는 사실 때문에 확실히 문제가 되고 있습니다. 또한 데이터 개인 정보 보호 제도로 인해 회사에서는 침해를 당한 사실을 쉽게 공개할 수 없게 되었습니다. 비용이 너무 많이 들거든요. 데이터를 잠그는 형태의 랜섬웨어가 있었고 X로 채우는 형태의 랜섬웨어가 있었습니다. 백업이 있다고 해도 이 범죄자들은 접근이 가능했다는 사실을 공개할 것이라고 협박합니다. 특히 규제 데이터를 다루는 경우 침해로 분류되는데 우리 모두가 그렇죠. 따라서 여기에서는 침해가 일어나는 환경이 관련이 있는데, 질문에 답하자면, 랜섬웨어를 해결할 묘책은 없어요. 랜섬웨어를 방지하려면 집안 정리를 잘 해야 합니다. 애초에 접근 가능성을 최소화하는 것부터 ID와 패치 적용, 최소 권한, 세분화 등을 적용하고 변경 불가능한 백업을 생성해야 하죠. AWS Backup 또는 Cloud and Door 같은 것을 사용하면 최신 백업을 특정 시점에 생성하고 백업 기능을 복원할 수 있어요. 

Clarke(20:23):
고객이 많은 관심을 보이는 또 다른 주제는 제로 트러스트 개념입니다. 제로 트러스트는 어떤 의미가 있고 고객에게 이를 어떻게 설명하며 AWS는 고객이 제로 트러스트를 달성하는 데 어떤 도움을 줄 수 있습니까? 제로 트러스트를 필요로 하는 경우라면요?

Merritt(20:42):
예. 제로 트러스트는 보안 제어를 고려할 때 유용할 수 있는 개념적 렌즈라고 생각합니다. 그렇죠? 제 생각에 제로 트러스트는 사람에 따라 다른 정의가 나올 수 있을 것 같은데요. 저는 제로 트러스트의 의미가 함축적이라고 생각합니다. 이 ‘커피 머그는 인터넷에 연결되어 있지 않다’라는 아이디어가 아니라 네트워크에서 위치를 기반으로 행위자에게 제공하는 신뢰 수준을 가능하면 0에 가깝게 줄여야 한다는 아이디어를 함축합니다. 기본적으로 소프트웨어든 사람이든 기존 경계의 개념에 대한 의존도를 줄여야 한다는 것입니다. 물론 경계가 사라져도 경계를 지울 수는 없죠. AWS는 VPN이나 VPC 같은 기존의 경계 중심 제어와 보안 그룹, Naples 및 기타 범위 안에서 작동하는 세분화된 ID 중심 제어 사이의 이분법적 선택을 하지 않습니다. 대신, 이 둘을 연동하여 사용하고 보완하며 서로 인식할 수 있게 만듭니다. VPC 엔드포인트 정책이 한 가지 예인데, 여기에는 경계도 있고 세분화된 권한도 있습니다. 이 둘은 상호 보완적이며 코드형 인프라에서 클라우드에 내재된 도구를 통해 적절히 사용할 수 있습니다. 보안을 코드로 사용할 수 있어요. 네트워크를 통해 패킷을 전송할 필요 없이 액세스 분석기나 검사기와 같은 것을 통해 네트워크에 접근할 수 있습니다. 진부한 소리처럼 들릴 수 있지만 이러한 종류의 심층 방어를 결합해서 사용하라는 것입니다. “문과 창에 자물쇠를 다세요"라는 말처럼 들릴 수 있죠. 하지만 이러한 수단은 역할이 서로 다르며 실제로 보안에 대한 근거를 찾을 때도 이와 동일한 논리가 적용됩니다.

Clarke(22:57):
오늘 시간을 내주셔서 감사합니다. 마지막으로 하실 말씀이 있으신가요?

Merritt(22:59):
사람들은 심오하고 기술적인 CISO 질문을 하겠다는 생각을 하지만 정작 “조직의 변화를 위한 추진력과 자금을 확보하려면 어떻게 해야 합니까?”라고 묻습니다. 결국 이 질문은 문자 그대로의 의미와 은유적 의미 모두에서 보안을 일등 시민으로 만들기 위해 한 기업이 하는 투자로 귀결됩니다. 보안이 0순위 작업이라는 말을 하는데 이 말은 보안이 좌우명이라는 의미가 아닙니다. 일상적인 문화 안에 보안을 포함한다는 의미입니다. 저희는 이를 위해 Steve Schmidt 씨가 CEO에게 직접 보고하고 다른 비즈니스 관심사로 인해 보안이 제외되는 일이 없도록 합니다. AWS와 같은 방식으로 우선 순위를 지정하고 싶다면 직접 해보실 것을 권장합니다. 목표를 달성하려면 먼저 시작해야 합니다. 그리고 시작하려면 목표를 중심으로 비즈니스를 정렬해야 해요. 목표를 달성하거나 조직의 목표 달성을 지원하는 방법 중 하나는 세계적인 등급의 팀을 만드는 것입니다. 지금은 인재를 찾기가 어렵지만 서로 다른 생각을 가지고 있고 다른 시야로 보며 다른 방식으로 코딩하는 사람을 채용하고 싶습니다. 업계를 위해 옳은 일이고 전체 생태계를 위해 옳은 일이니까요. 보안은 취약한 커뮤니티에서, 기술을 사용하는 과정에서, 문제를 해결하고 비즈니스와 엔터티를 강하게 만드는 과정에서 많은 접점을 가지고 있습니다. 거기에 없다면 어디에도 없습니다. 제가 하고 싶은 말은 모두가 해야 할 일이라는 것입니다. 포용력 있는 직장 문화를 만들고 엔터티를 강하게 만들어야 합니다.

Clarke(25:02):
Merritt 씨, 오늘 이 자리에서 귀한 통찰력을 공유해 주셔서 감사합니다.