Announcing Edgio Attack Surface Management | 
Edgio의 Beyond the Edge Podcast 소개 에피소드 4: DevSecOps: Edgio의 글로벌 캠페인 매니저인 Lauren Bradley가 주관하는 제품 로드맵을 오른쪽으로 이동하지 않으려면 왼쪽으로 이동하십시오.
Lauren Bradley: 안녕하세요. Beyond the Edge에 오신 것을 환영합니다. 여기서 우리는 현대 디지털 비즈니스의 안팎을 파헤칩니다. 저는 이 에피소드의 공동 파일럿인 Lauren Bradley입니다. 오늘은 좌파로 이동하는 주제에 대해 알아보겠습니다. 특히 웹 애플리케이션과 API 보호가 DevOps 라이프사이클의 기본 요소로 자리잡음에 따라 문화와 기술이 어떻게 변화하는지 알아보겠습니다.
Ponemon Institute의 충격적인 통계로 시작해 봅시다. 오늘날 대부분의 기업들은 침해를 탐지하는 데까지 200일 이상이 걸립니다. 침해를 충분히 빨리 감지하지 못하면 비용이 많이 들 것입니다. IBM은 테스트 단계에서 발견된 버그 수정 비용이 설계 단계에서 발견된 버그 비용보다 15배 더 높을 수 있다는 사실을 발견했습니다.
간단히 말해서, 문제를 잡기 위해 더 오래 기다릴수록 더 많은 비용이 듭니다. 비용, 재작업, 시간 및 에너지가 궁극적으로 제품 로드맵을 되돌릴 수 있다는 것만 말하는 것이 아닙니다. 그렇다면 어떻게 하면 왼쪽으로 효과적으로 이동하고 귀중한 자원을 낭비하고 발전을 지연시키지 않을 수 있을까요?
오늘 Edgio의 플랫폼 엔지니어링 이사인 Michael Grimshaw와 Edgio Security Platform의 제품 관리 수석 이사인 Richard Yew가 함께 합니다. 안녕하세요, 마이클과 리처드. 입으셔서 반갑습니다.
마이클 그림쇼: 감사합니다, 로렌. 이곳에 오셔서 반갑습니다. 감사합니다.
로렌 브래들리: 여러분들은 여러분과 이 주제에 대한 여러분의 초기 생각에 대해 조금 말씀해 주실 수 있나요? 마이크, 시작할게
마이클 그림쇼: 물론입니다. 우선, 감사하고, 로렌, 관심을 가져 주셔서 감사합니다. 이 매우 중요한 주제에서, 그리고 여러분은 파고 들어가고 있습니다. 그리고 이 주제에 대해 우리가 나누고 있는 대화는, 이 1년을 포함하여, 우리가 업계에서 하고 있는 일에 매우 귀중하고 필수적인 것입니다.
Michael Grimshaw: 이러한 이해는 널리 공유되어야 하며, 관심을 진심으로 감사해야 합니다. 제 이름은 마이클 그림쇼입니다. 저는 Edgio의 플랫폼 엔지니어링 책임자입니다. 업계에서 플랫폼에 익숙하지 않거나 플랫폼에 익숙하지 않은 분들은 애플리케이션과 인프라를 일관된 단위로 통합하는 것을 생각하고 계실 것입니다.
그리고 보안 배경이 심한 플랫폼에 왔습니다. 이 분야는 제가 매우 열정을 가지고 있는 분야입니다. 왜냐하면 보안, 수익성, 그리고 우리 산업에 매우 중요한 많은 분야들이 있습니다.
그리고 DevSecOps를 계속 살펴볼 수 있지만, 리처드에게 소개해 드리겠습니다.
리처드 유: 정말 감사합니다, 마이클. 예. 예. 이것은 매우 중요한 주제입니다. 저는 개인적으로 전체 소프트웨어 개발 라이프사이클 프로세스를 거치면서 비즈니스에 번역을 해왔기 때문에 제 마음에 매우 가깝고 소중합니다.
지금, 내가 하는 일에 대해 말하면… Lauren이 언급했듯이 저는 Edgio에서 보안 제품 관리 조직을 운영하고 있습니다. 그래서 제 일상 생활은 R&D 팀과 엔지니어링 팀과 협력하여 고객에게 가치를 전달하고 있는지 확인하는 것입니다. 물론 개발 관행 최적화, 보안, CI CD 관행과 같은 모든 것이 포함될 것입니다. 우리는 실제로 안전한 제품을 제공 할 수 있습니다.
맞습니다. 이는 실제로 고객에게 가치를 제공하고, 적시에 예산에 맞춰 제공하며, 고객에게 훌륭한 경험을 제공할 수 있도록 보장합니다. 그래서, 제 렌즈는 전체 DevSecOps를 사람들의 관점에서 살펴보는 것입니다. 기술과 대조되는 프로세스와 업계에서 모범 사례를 실제로 구현하는 방법을 말이죠.
DevSecOps란 무엇입니까?
마이클 그림쇼: 리처드, 괜찮으시다면 제가 공을 훔쳐가게 해드릴게요.
이제 DevSecOps가 의미하는 바에 대해 표준화하고 왼쪽 시프트를 이동해 봅시다. 가트너가 있었는데, 이 DevSecOps를 듣는 몇몇 분들을 위한 것들이 있습니다. 그리고 이 용어는 왼쪽으로, 오른쪽으로 이동하는 등 비교적 새로운 것으로 들릴 수 있습니다. 이것은 새로운 것이 아닙니다. 아시다시피, 일년 전에 가장 인기있는 최신 물건이 아닙니다.
아니, 이것은 꽤 오랫동안 업계에서 구워왔다. 실제로 가트너는 2017년 DevSecOps 라이프사이클에 대한 보고서를 발표했다. 업계 DevOps 트렌드인 DevOps의 연장선상에 불과했습니다. Infosec의 보안을 피드백 루프 및 소프트웨어 개발 라이프사이클로 확장하는 것뿐입니다.
제가 말했듯이, 가트너는 2017년에 이것에 대해 글을 쓰고 있었습니다. 이미 업계에서 하나의 과정과 운동이 있었습니다. 그 전에 꽤 오랫동안. 이것들은 새로운 개념이 아닙니다. 이것은 우리가 수년간 작업해온 것의 연장선상에 불과합니다. DevSecOps는 개발 측면과 운영 측면이 있다는 점에서 DevOps의 유사한 모델을 사용합니다.
그리고 핵심은, 모든 보안 요구 사항을 가능한 빨리 구축하고 있다는 것입니다. 제 말은, 설계가 시작된 시점부터 전체 프로세스를 구축하고 있습니다. 개발자가 개발하는 시점까지 말이죠. 죄송합니다. 오른쪽으로 이동하면 작업 관찰 가능성 측면에 더 가깝습니다. 오늘은 왼쪽부터 교대 자세에 초점을 맞출 것입니다. 하지만 이것은 기본적으로 여러분의 스캔 테스트와 검증을 위한 것입니다. 빠르면 왼쪽부터 말이죠. SDLC의 개발 수명 주기 초기에 가능한 한 예를 들어, 이것이 이야기하는 것들 중 하나는, 다시 말하지만, 7년 전으로 거슬러 올라갑니다. 보안, 스캐닝, 스캐닝, 스캐닝, 오픈소스 써드파티 라이브러리, 저장소, 코드 베이스, 그리고 여러분이 작성한 코드, 디자인, 아키텍처, 전체 9야드, 그리고 아주 처음부터 그것을 굽는 것과 같은 것들입니다. 제가 드린 예시 중 하나는 개발자들이 사용하는 바로 그 IDE를 구축하고 보안을 검사하는 것입니다. 그것은 단지 하나의 예일 뿐이며, 그것들이 많이 있습니다.
그래서 그들이 코드를 작성할 때 즉각적인 피드백을 받을 수 있습니다. 아, 저는 그냥 문을 열어둔 채로, 인증정보 스터핑이나 속편 삽입을 했는데, 구문 오류처럼 보안 오류가 발생합니다. 코드를 작성하는 바로 그 자리에서 보안 오류가 발생합니다. 그래서, 그들은 즉시 해결할 수 있습니다. 그래서 고객이나 최종 사용자에 대해 불평하는 고객이 없도록 말이죠. 한 달 후, 아니, 바로 거기서 처리됩니다.
가장 저렴하고, 가장 빠르며, 처음부터 가장 쉽습니다. 리처드, 뭔가 말하려고 했잖아
비용에 관해서는 왼쪽으로 이동하는 것이 왜 그렇게 중요합니까?
리처드 유: 오, 네. 네. 제가 생각하기에 비용은 실제로 매우 중요하다고 생각하듯이, 아시다시피, 모든 사람들이 많은 운영 비용을 알고 있습니다. 아시다시피, 모든 조직은 개발과 같습니다. R&D 과정
그래서, 비용에 관해서, 이것이 왼쪽으로 이동하는 것이 더 중요한 이유입니다, 그렇죠? 왜냐하면 우리는 많은 노력을 기울이고 그 이유에 대해 이야기하고 있기 때문입니다. 나중에 “어떻게”에 대해 이야기 할 것이지만, 우리는 이것이 왜 중요한지에 대해 이야기하고 싶습니다. 왜냐하면, 우리는 데이터를 가지고 있기 때문입니다.
네. 우리의 연구에 따르면, 코드와 프로덕션을 출시한 후에 발견된 보안 취약점을 수정하는 경우 위협을 증가시킬 때 설계 단계에서 발견된 보안 취약점의 15배가 더 많이 드는 것으로 나타났습니다. 물론, 개발 노력의 초기 단계가 모든 보안 취약점을 완전히 포착한다는 것은 아닙니다.
그렇기 때문에 심층적인 방어 체계를 구축해야 합니다. 하지만 8단계를 살펴보면, 일반적으로 부채 주기, 계획, 코드, 빌드, 테스트, 모니터링 및 운영을 좋아합니다. 맞습니다. 더 오른쪽으로 보면서 보안 취약성을 발견할수록 더 많은 비용이 소요됩니다.
조직에서 실제로 문제를 해결합니다. 그래서, 우리는 스캔에서 취약점을 찾는 것의 차이에 대해 이야기하고 있습니다. 여러분이 이미 많은 코드를 제작에 공개한 후에 일어나는 취약성을 찾는 것과, 아시다시피, 스테이징 환경에서 동적 애플리케이션 보안 작업을 수행하여 코드를 프로덕션에 전달하기 전에 실제로 감지하는 것과 같은 경우가 있습니다.
Richard Yew: 이러한 문제를 해결하거나 코드 감소를 릴리스하기 전에 미리 일종의 가상 패치를 구현할 수 있습니다. 그러나, 다시 말하지만, IDE에 무언가를 입력하거나 위협 모델링을 고려하기 전에 코드를 작성하기 전에 프로세스의 첫 단계부터 보안을 구축해야 한다는 것을 이해하는 것이 매우 중요합니다. 설계의 어떤 부분이 잠재적으로 악용될 가능성이 있습니까?
DevOps 및 보안 팀에 대한 일상적인 영향
로렌 브래들리: 네, 그리고 그것들은 정말 좋은 점들입니다, 여러분. 사용자 관점에서 보면 비용 이외에 금전적으로 DevOps나 보안 팀이 처음부터 제대로 구현하지 않는다면 일상적으로 경험할 수 있는 것은 무엇일까요?
또한 DevOps 라이프사이클에 어떻게 효과적으로 구현하는지에 대해서도 말씀드리고자 합니다.
마이클 그림쇼: 좋은 질문입니다. 좋은 질문입니다. 그리고, 내 첫 반응에 대해 솔직히 말해보자. 업계의 모든 직원, 모든 CEO, CTO, CFO 등 모든 직원, 엔지니어, 사용자 – 우리 모두가 원하는 것은 우리가 할 수있는 마법의 총알, 우리가 매일 수행하는 것입니다.
그리고 우리는 마법 보안 총알을 가지고 있습니다. 스위치를 돌리면 모든 작업이 갑자기 안전해집니다. 모두가 원하는 건 그것이지만 현실은 아니다. 그러니까, 사람들이 우리에게 묻습니다. 저는 그들에게 묻고 싶습니다. 판타지 땅의 날씨는 어떤가요? 좋다고 들었다. 이러한 유형의 연도는 보안, infosec 및 개발에 접근하는 경우, 이것은 단지 볼트온 일 뿐입니다. 아시다시피, “오, 저는 우리가 모든 것을 개발, 구축 및 배포하고 모든 것을 안전하게 만들 후에 사용할 도구를 몇 개 사려고 합니다.” 당신은 매우 비싼 문진을 구입하고 있습니다.
이것이 바로, 여러분도 아시다시피, 인력, 프로세스, 및 공구. 그렇기 때문에 이 접근법의 일관성 있는 총체성이 매우 중요하다. 당신은, 우리는 멀리 년, 수십 년, 심지어 가능하다면. 솔직히 말씀드리자면, 저희는 여러분이 무언가를 디자인하고 보안 툴링을 설치한다는 아이디어에서 많은 교훈을 얻었습니다. 여러분은 이제 괜찮습니다.
비용에서 개발자 속도 및 고객 비용에 이르기까지 모든 것에 영향을 미칩니다. 그리고, 이것의 좋은 예는 내 의심, 자신의 경력의 어떤 시점에서 이 팟 캐스트를 듣고 거의 모든 사람들이 새로운 기능 또는 새로운 서비스 또는 그와 비슷한 뭔가, 심지어 패치와 업데이트가 배포 된 상황에 있었다. 모든 것이 좋아 보인다. 모든 것이 잘 진행되고 있습니다. 그런데 갑자기 고객으로부터 전화를 받거나 인포섹이 고객으로부터 전화를 받습니다. “우리는 방금 전당포 당했습니다.”또는 “방금 보안 사고가 발생했습니다.”또는 이와 비슷한 것입니다. 그 이유는, 좋아, 배포했지만 검사가 완료되지 않았거나, 검사를 수행하지 않았거나, 제대로 조정되지 않았거나, 방금 엄청난 보안 취약점이 생겼기 때문입니다.
어쩌면 당신에게 영향을 미칠 수도 있지만 더 중요한 것은 고객에게 영향을 미칩니다. DevSecOps는 일관된 프로세스에서 이 모든 것을 함께 굽고 이를 피하는 것입니다. 그것은 비용 절감에 관한 것입니다. 물론이죠. 마진 개선에 관한 것입니까? 오, 아주 큰 방법으로. 그러나 그것은 또한 당신의 회사와 당신의 고객에 대한 책임을 제거하는 것에 관한 것입니다.
DevOps에 보안을 통합하는 것은 마치 케이크를 만드는 것과 같습니다!
리처드 유: 물론입니다. 마이크가 그런 일관성 있는 총체성이라는 용어를 사용했던 것처럼, 베이킹에 대해 말하면서 말이죠. 이처럼 정말 사실입니다. 이것은 매우 강력합니다. 이 단어는 제자리에 구운 것이 왜 중요한지 보여주기 위해 매우 강력한 단어입니다. 아시다시피, 제가 에디오에서 유추적인 사람으로 알려져 있는 것처럼 말이죠.
저는여러가지비유를던지는것을좋아합니다. 그리고저는이것을훌륭하게들었습니다. 비유는 우리 모두가 알고 있듯이, 보안 담당자로서 우리 업무의 큰 부분은 복음주의입니다. 올바른 기술을 구현하고 프로세스를 만드는 것뿐만 아니라 실제로 많은 내부 마케팅을 수행하는 것입니다.
사람들에게 보안이 비즈니스에 중요하다고 말하는 것 아닙니까? 왜냐하면 보안 리더로서, 사람들이 보안을 생각하는 것처럼, 워크플로우에 프로세스 레이어를 추가하는 것과 같이 보안에 대해 생각하는 것과 같기 때문입니다. 하지만, 이러한 문제에 대한 올바른 생각은 보안이 비즈니스를 가속화할 수 있는 방법이라는 것입니다.
보안이 실제로 더 많은 수익을 창출할 수 있는 방법은 무엇일까요? 이는 조직의 보안을 보장하기 위해 수행해야 하는 추가 보안 구현을 정당화하는 좋은 방법이기 때문입니다. 그래서, 제가 들었던 비유 중 하나는, 보안이 케이크에 장식으로 취급되어서는 안된다는 것입니다. 케이크에서 구워서 모든 아이싱을 마지막 단계로 넣는 방법, 아시다시피, 보안, ICD 워크플로우가 없고 방화벽과 API 보호 등을 구현할 때 보통 이런 일을 합니다. 생산 단계의 마지막 단계에서 말이죠. 그것이 무엇이어야 하는지, 보안은, 밀가루와 같습니다. 처음부터 뭔가 있었어야 했다.
보안은 당신이 케이크를 구울 밀가루와 같습니다. 그리고 보안이 제대로 이루어지면 볼 수 없습니다. 그리고 보안의 요점은 그것이 제대로 끝났을 때, 그것은 구워져야하고 눈에 띄지 않는다는 것입니다. 그것은 도전을 만드는 것이 되어서는 안 된다. 조직을 늦추는 것이 되어서는 안 된다.
제가 비즈니스에 이것이 중요한 이유를 보여주곤 했던 비유처럼 강력한 보안 프로세스와 보안 기술 문화를 갖추는 것은 마치 강력한 브레이크를 사용하는 것과 같다는 것입니다. 경주용 자동차에서는 왜 모든 슈퍼카가 크고, 정말 크고, 멋진 브레이크를 가지고 있는지 알 수 있습니다. 왜냐하면 자동차가 더 빨리 코너링을 할 수 있기 때문입니다.
그것은 그들이 열심히 브레이크를 할 수 있습니다. 더 빨리 움직이고 더 세게 돌아갈 수 있게 해주죠, 그렇죠? 그것은 그들이 경주에서 이길 수있게 해줍니다. 그래서, 강한 브레이크를 갖는 것은 강한 엔진을 갖는 것만큼이나 중요합니다, 그렇죠? 이것이 우리가 철학적으로 안보를 바라보는 방식입니다. 아시다시피, 분명히 우리는 높은 수준에 대해 많이 이야기합니다. 그렇죠? 그래서, 우리는 분명히 그것에 대해 더 깊이 들어가기를 원합니다. 요점은, 좋아요, 이 모든 것이 괜찮습니다. 하지만 정확히 어떻게 구현할 수 있을까요?
마이클 그림쇼: 네. 제생각에제동을하는것은대단한소리입니다. 강력한 제동력은 제어력을 제공합니다. 우리가 앞으로 나아갈 길이 곡선과 헤어핀 회전 등으로 가득 차 있고, 물론 바닥에 바닥을 깔고 있는 직선도로가 있고 브레이크를 만지지 않습니다. 하지만 모든 것을 헤쳐나가기 위해, 제 생각엔, 저는 이 두 가지 비유를 좋아합니다. 리차드, 제동 비유는 제어력을 제공하고, 연석, 도전, 그리고 예상치 못한 일들에 직면했을 때 더 세밀한 제어력을 제공하기 때문입니다.
리처드 유: 대단한 전화입니다. 제가 명확히 하고 싶은 말은, 저는 에릭 코 박사라는 사람에게서 나온 비유를 생각해내지 못했습니다. 그는 가지고 있으며 훌륭한 팟캐스트를 운영하고 있습니다. 그래서 나는 모든 사람들이 그것을 보러 가기를 권한다. 그러나 예, 비즈니스에 개념을 설명 할 때, 특히 이러한 종류의 개념에 새로운 사람들과 너무 적절하다고 생각합니다.
문제가 있는 분산된 팀 및 변화하는 로드맵
로렌 브래들리: 리처드, 당신이 말한 방법에 대해 얘기합니다. DevSecOps가 완료되었습니다. 당신은 그것을 볼 수 없습니다. 그리고 분명히, 그 눈부신 가시성 중 하나는 비용입니다. 또한 사일로된 팀들이다. 또한 이러한 문제가 발생할 때 팀 간에 단절이 있는 것처럼 느껴지며 이전에는 왜 잡히지 않았습니까?
이러한 문제를 신속하고 효과적으로 해결하기 위해 어떤 프로세스와 커뮤니케이션이 이루어지지 않았습니까? 그래서, 당신에 게 내 질문은, 당신도 알다시피, 당신의 경험에서, 어떤 중… 아시다시피, 아마도 투명성이 부족할 것입니다. 의사 결정이 느리고 자원을 낭비할 가능성이 있습니다.
격리된 팀이 있을 때 팀이 격리된 상태로 운영될 때 가장 문제가 되는 경향이 있는 문제는 무엇입니까?
리처드 유: 네, 이거 가져갈게요. 제 생각에, 제가 과거에 경험했던 것 중 하나는, 그리고 우리가 같은 제품에 대해 이야기할 때, 알다시피, 계획과 같은 것들에 대해 이야기할 때, 때로는 CTO 조직처럼 R&D에 포함되지 않는 보안 팀이 있다는 것이 중요합니다.
많은 조직에서 보안 팀과 CTO 조직 간의 사일로를 관찰하는 경우가 있는데, 그 이후로 많은 프로세스가 수행되었다는 것을 알게 될 것입니다. 예를 들어, 우리는 많은 제품을 출시하고, 많은 코드를 공개하는 상황에 직면합니다. 왜냐하면 보안 팀과 엔지니어링 팀 사이에 강력한 커뮤니케이션 협력이 없기 때문입니다.
결국 조직은 규정을 준수해야 한다는 것입니다. 경우에 따라, 구체적인 예는 1년에 한 번 또는 두 번 정도 검사를 수행하는 팀이 있다는 것입니다. 그 스캔의 결과는 무엇입니까? “리처드, 다음 분기에는 속도를 늦춰야 해요. 왜냐하면 우리는 방금 수백 가지의 크고 작은 보안 버그를 발견했기 때문이죠. 아마 20개 정도, 상위 20개 중 심각도 1과 2 이상인 반면, 나머지는 알다시피 그것은 문제입니다, 당신은 그 것들을 고치는 데 집중해야합니다. “
조직 내에 해결해야 할 SLA가 있습니다. 결국 이렇게 하면 기본적으로 로드맵을 제거하고 다음 분기로 넘어갑니다. 그래서 왼쪽으로 이동하지 않고, 이 과정을 제대로 진행하지 않고, 오른쪽에서만 이런 일들을 함으로써, 우리는 근본적으로 로드맵을 추진하고 있습니다. 즉, 수익을 창출하는 결과물로서, 잠재적으로 우리의 사업을 확장하는 데 도움이 될 수 있습니다. 우리는 잠재적으로 그것을 바로잡을 것입니다. 그래서 우리는 실제로, 아시다시피, 분기 지출은, 그 후, 이러한 문제를 완화하기 위해 노력하고 있습니다.
이것이 바로 제가 말한 이유입니다. 조직과 기업들이 로드맵 항목을 분기별로 변경해야 한다는 것을 상상하기에는 엄청난 비용이 듭니다. 따라서 신제품, 특징 및 기능에 대한 모든 출시 일정을 변경해야 합니다. 왜냐하면 당신은 당신의 연습으로 왼쪽으로 이동하지 않았기 때문입니다.
그리고 이러한 것들 중 일부는 특히 조직 내의 애플리케이션 보안 팀과 개발 팀 간의 협업 개선을 통해 개선될 수 있었습니다. 그래서 많은 조직이 이 새로운 개념을 도입하기 시작했습니다. 여러분은 HR BP, HR 비즈니스 파트너에 대해 들어보셨을 겁니다. 서로 다른 사업부에 포함되어 있는 HR 비즈니스 파트너들이죠.
이제 Application Security BP의 개념이 생겼습니다. 그래서 여러분은 APP SEC BP와 같은 용어를 듣기 시작할 것입니다. 그것은 사람들이 일하는 곳에서 연습이 될 수 있습니다. 마치 엔지니어링 팀의 반 임베디드 매니저처럼 개발 워크플로의 각 단계에서 소프트웨어 구성 분석 구현, 보안 ID 구현, 모든 흑백 박스 작업 구현 등 올바른 지침, 도구 및 프로세스를 제공하도록 보장합니다. 프로세스 중에 이러한 문제 중 일부를 개발 수명 주기 초기에 포착할 수 있습니다.
마이클 그림쇼: 나는 모든 것을 사랑한다. 좋은 질문이에요, 로렌 그리고 난 당신이 말한 모든 것을 사랑해, 리처드 왜냐하면 그것과 관련된 비용이 있기 때문입니다. 만약 누군가가 제품에 들어가 소리를 듣는다면, 잠깐, 제가 왼쪽으로 이동하면 로드맵을 오른쪽으로 옮길 필요가 없습니다.
그것은 그들의 귀에 음악입니다. 하지만 아마도 CFO나 운영, 또는 다른 비즈니스 분야에서는 이렇게 말할 수 있습니다. “좋아, 그게 어떤 영향을 미칠까?” 그 영향은 엄청납니다. 방금 영업 부서를 무릎 꿇었잖아 특히 보안에 관해서는 많은 고객을 확보하고 있기 때문에 고객에게 영향을 미쳤습니다. 플랫폼 측면에서는 공급업체와 상담할 때 로드맵이 무엇인지 알고 싶습니다. 왜냐하면, 감사관에게 가서 여러분이 로드맵에 무언가를 공개할 때까지 보상 제어를 받아야 할 수도 있기 때문입니다. 음, 만약 여러분이 제게, 좋아요, 분기에 배달될 것으로 예상했던 것은 3분기가 될 것입니다. 다른 판매자들도 살펴보도록 하겠습니다. 왜 그럴까요? 왜냐하면 저는 제 감사관들에게 의무가 있기 때문입니다. 제가 만나야 할 의무가 있기 때문입니다.
그리고 저는 리처드도 사랑합니다. 감사관들과 규정 준수 절차를 소개해주셨죠. Lauren이라는 다른 예시입니다. 사일로화가 근본적으로 폭발할 수 있는 부분입니다.
PCI, SOC, ISO, FedRAMP 등 다양한 컴플라이언스 프레임워크 중 하나라도 제대로 통합되지 않았다면, 여전히 망명 정신을 운영하고 있다면, 컴플라이언스 또는 정보 보안 담당자가 감사관과 대화를 나누게 될 것입니다. 그들은 이것을 한 두 레이어를 통해 엔지니어링 측면으로 변환해야 합니다. 의도된 모든 것을 구현할 수 있기를 바랍니다. 그리고 그것을 구현하기 위해서입니다. 그리고 모든 증거와 스캔, 그리고 다른 사람들에게 다시 제공해야 할 모든 것들, 행운을 빕니다.
그것이 실제로 번역된다면, 우리는 모두 연주했습니다, 알다시피, 초등학교의 오래된 소문 게임은 비슷한 유형의 기능입니다. 감사관과 협력하여 특정 기술로 변환하는 방법을 즉시 알고 스캔을 통해 즉시 돌려 넣을 수 있습니다. 규칙 집합에서 실시간으로 뿐만 아니라 감사자와 회의할 때도 이를 검사하고 검증합니다. 당신은 모든 증거를 바로 거기에 가지고 있습니다. 이것은 근본적인 게임 체인저입니다. 이를 통해 Richard가 말한 대로 지금 바로 로드맵을 변경하는 대신 고객에게 더 빨리 제품을 제공할 수 있습니다.
로렌 브래들리: 네. 이에 대해 좀 더 구체적으로 말하자면, CISO와 AppSec 리더들은 비용에 미치는 영향 또는 일반적인 성공을 이해하기 위해 자신의 메트릭을 어떻게 수치화할 수 있을까요?
리처드 유: 재미있네요. 왜냐하면 우리는 왜, 무엇을 알고 있는지 많이 이야기하기 때문이죠. 하지만 더 깊이 들어가 봅시다. 왜냐하면 저는 그것을 알고 있기 때문입니다. 그것이 우리 청중들의 많은 이유입니다. 우리는 여러분에게 솜털같이 높은 수준의 진술을 하러 온 것이 아닙니다. 우리가 여기서 제공하고자 하는 것은 정확히 어떻게 구현할 것인지에 대한 약간의 가치입니다.
우리가 가지고 있는 DevSecOps 차트를 꺼내서 단계를 최적화할 수 있는 방법을 살펴볼 수도 있습니다. 그래. 기존의 보안 테스트에서 볼 수 있듯이 선형적인 방식으로 실행됩니다. 그렇죠? 마치 폭포에 대해 이야기할 때와 같죠. 여러분의 계획처럼 아름다움, 테스트, 그렇죠?
운영자 모니터링 단계에서 많은 보안 테스트가 수행되었습니다. 그러니까 오른쪽에 있습니다. 자, 이제 새로운 컨셉은, 다음 사진으로 넘어가면, 맞죠? 이 차트의 100 가지 종류를 찾을 수 있다는 것입니다. 마이크가 아까 말했듯이, 구글 DevSecOps를 사용했을 때, 이 개념은 7년 동안 존재해왔죠, 그렇죠? 일부 조직에서는 이러한 주기라고 부르지 않을 수도 있습니다. 일부 조직에서는 AppSec이라고 부르기도 합니다. 그래서 어떤 조직들은 이것을 보안 파이프라인이라고 부릅니다. 이것은 보안 파이프라인이 의미하는 바를 대략적으로 나타낸 것입니다. 그렇죠? 그래서, 처음부터 계획 단계에 있습니다, 그렇죠?
위협 모델링 위협 분석이 있습니다. 솔루션을 설계하는 동안 이 모든 모델링을 완벽하게 수행하려고 노력합니다. 코딩을 할 때, 두 번째 단계, 즉 코딩 단계로 넘어갈 때, 그렇죠? 당신은 당신이 후크가 있는지 확인하고 싶습니다. 코드를 작성하는 개발자가 실제로 실시간으로 일부 문제를 캡처하는 보안 IDE를 가지고 있는지 확인하고 싶습니다. 분명히, 그것은 은색 총알이 아닙니다, 그렇죠? 하지만 이는 추가적인 레이어이며 심층 방어 사이클에서 추가 레이어에 대해 이야기하고 있습니다. 자, 우리가 과정을 점점 더 내려가면서, 그렇죠? 코드에 전념한 거 맞죠? 프로세스가 있는지 확인해야 합니다. 자동 종속성, 공급망, 취약성 등을 확인하기 위해 모든 코드의 정적 스캔을 누가 제공할 수 있는지 확인해야 합니다. 소프트웨어 보상 분석과 함께 사용 중인 소프트웨어 버전을 보여주는 자료의 소프트웨어 보기를 생성합니까? 몇 살입니까?
때문에, 알다시피, 난 당신이 아이, 난 그냥 일주일 또는 2 전에 통계를 읽어 – 25% Apache log4j의 다운로드의 여전히 취약점이 포함 된 이전 버전 떨어져. 거의 2년이 지났으니 지금도 여전히 통계라고 해서 당황스러워요. 모르겠어요, 첫 번째 아파치 log4j 제로 데이 취약점이 12 월 초에 다시 발표 된 때로부터 2 년 또는 3 년? 2021년이었나? 따라서, 우리가 더 잘하는 데 초점을 맞추고 이러한 종류의 소프트웨어 대화/분석을 통해 실행 중인 소프트웨어의 버전을 정확히 알 수 있도록 해야 합니다.
중요해. 그래서, 우리는 시험을 향해 나아갑니다, 그렇죠? 내부 테스트가 있는지 확인하고 싶고, 동적 테스트를 실행하여 이를 보장합니다. 실행 중인 응용 프로그램을 테스트하여 악용될 수 있는 취약점이 있는지 확인할 수 있습니다.
당신은 이것이 보통 퍼징을 통해 이루어진다는 것을 알고 있습니다. 기존의 DevSecOps 사이클에 표시되지 않은 것은 무엇입니까? 이 모든 것이 꽤 표준적인 산업 관행으로 보이기 때문이죠, 그렇죠? 배포, 모니터링, 대응을 위해 모든 방향으로 나아가고 있습니다. 예전에는 웹 애플리케이션 방화벽, 봇 관리자, API 보안, 모든 웹 애플리케이션 API 보호 솔루션을 응답 및 모니터링 단계에 두었습니다. 이는 프로덕션 트래픽을 모니터링할 때 악용이 발생하지 않도록 하는 것입니다.
그러나 고려해야 할 것은 실제로 당신이 가지고있는이 웹 애플리케이션 API 보호 기능 중 일부를 이동하는 것입니다. 또한 왼쪽으로 옮기십시오. 이 경우에, 사진에서, 그것은 한 걸음 더 나아가는 것입니다. 동적 응용 프로그램 보안 테스트를 수행할 때 테스트 단계에 포함시키십시오. 그렇죠? 생산 보안 메커니즘을 통해 테스트하지 않는 이유는 무엇입니까? 사실 코드 사이에 얼마나 많은 취약점이 존재하는지, 얼마나 많은 취약점이 완화될 수 있는지를 알 수 있습니다. 중요한 것은 우리가 항상 현재의 앱 사이클을 개선할 방법을 찾고 있다는 것입니다. 실제로 개발 속도를 높임으로써 말이죠. 테스트 중에 보안 취약성을 발견했을 때 일반적으로 열차를 멈추는 것이 일반적입니다. 돌아가, 그렇지? 코드를 수정하고 다시 해제합니다. 다시 여덟 단계를 거친다. 하지만 만약 제가 여러분에게 “이봐, 기차를 멈추지 말자”라고 말할 수 있는 방법이 있다고 말한다면 어떨까요?
기차를 계속 가자. 4단계 앞에 보안 솔루션이 포함된 일종의 추가 테스트를 통해 교육을 중단할 필요가 없도록 프로덕션에서 가상으로 패치해야 할 사항을 미리 파악할 수 있습니다. 당신은 당신의 기차를 계속 달립니다. 당신은 당신의 속도를 유지합니다.
취약성을 완화하기 위해 가상 패치를 설치하여 코드를 배포한 다음 다음 주기에서 수정합니다. 매우 빠르게 이루어지기를 바랍니다. 이러한 방법 중 하나이기도 합니다. 기존 CICD 보안 워크플로우를 개선하기 위해 고객을 교육하고 협력하기 위해 우리가 원하는 혁신적인 방법이기도 합니다.
마이클 그림쇼: 사랑해요, 리처드. 저는 여러분이 이것을 왼쪽으로 밀어당기는 사실을 부르는 것을 좋아합니다. 그래서 당신의 요점은 당신의 게임 계획이, 오, 이걸 생산으로 가져 가자 그리고 우리는 그것에 대해 걱정할 것입니다. 개발과 배포 및 운영 프로세스를 통해 문제를 완화할 수 있는 무언가가 있을 것입니다. 나는 당신이 거기서 부르는 것을 사랑한다. 그리고 비유와 비슷한 비유는, 제가 말하자면, 혼돈원숭이와 같습니다. 여기 있습니다. 만약 여러분이 혼돈원숭이가 생산에 종사하고 있다면, 그리고 혼돈원숭이를 다루는 유일한 시간은 그것이 생산에 종사할 때입니다. 여러분은 끔찍한 발전과 운영 경험을 하게 될 것입니다.
생산에 들어가기 전에 이를 계획하고 설계하고 엔지니어링해야 합니다. 그렇지 않으면, 당신은 비참하게 될 것입니다.
비용 영향 및 성공을 이해하기 위한 메트릭 정량화
Richard Yew: 네, Lauren 씨, 앞의 질문에 답하고 싶습니다. 현재 DevSecOps 수명주기 전체를 살펴보고 어떻게 최적화할 수 있는지 말이죠. 모범 사례는 무엇입니까?
매우 빠르죠. 그래서 우리는 성공을 추적해야 합니다. 따라서 분명히 성공을 수치화 할 수 있어야합니다. 맞습니다. 보안 리더로서 애플리케이션 보안 프로그램의 성공을 측정하는 데 도움이 될 수 있는 몇 가지 지표가 있습니다. 살펴볼 수 있는 것 중 하나는 애플리케이션 커버리지의 양입니다. 그렇죠?
예를 들어, 조직 전체에서 전체 애플리케이션 또는 인터넷 연결 애플리케이션의 90/95% 이상이 동일한 프로세스로 처리되고 있습니까? 동일한 표준화된 프로세스가 있습니까? 맞습니다. 소프트웨어 구성, 분석, SAS, 테스트, 테스트, 테스트, 웹 애플리케이션, API 보호 등
혹시 계속 추적할 수 있는 그런 것들이 있나요? 얼마나 자주 해제하고 얼마나 자주 롤백해야 합니까? 감지한 보안 취약성 때문에 어떤 단계에서, 생산 단계에서 롤백해야 하는 빈도와 그 동안 롤백해야 하는 빈도 비교 프로덕션을 분명히 롤백하기 때문에 정적 분석을 수행하는 코드 커밋 단계입니다.
약간의 정적 코드 분석 후에 코드를 수정하는 것보다 훨씬 더 비쌀 것입니다. 맞습니다. 다른 두 통계는 로렌이 앞서 언급한 것처럼 측정하고 싶을 것입니다. 업계 평균 MTTD 탐지 시간은 200일입니다. 그래서, 저는 오른쪽 이동 왼쪽 과정과 오른쪽 과정으로 이것을 믿습니다, 당신은 감지하는 동안 크게 줄일 수 있습니다, 훨씬 더 짧은. 따라서 조직 내의 해당 건물을 탐지하는 데 취약점이 노출된 후 얼마나 걸리는지 탐지하기 위해 메트릭을 함께 모으기 시작하십시오.
또한 응답에 대한 동안에 실행하십시오, 그렇죠? MTTR은 해상도에 대한 중간 해결을 위해 그 동안, 맞습니까? 업계 평균은 70일이니까 취약성이 발견된 지 70일이 지났죠? 악용 그것을 해결하는 데 평균 70 일이 걸립니다. 그러나 추적을 시작하면 얼마나 빨리 해결할 수 있습니까? 소프트웨어 구성 분석에서 코드를 사용하여 J에 대한 취약한 버전의 로그를 발견하는 즉시 방화벽으로 가상 패치를 얼마나 빨리 할 수 있습니까, 아니면 라이브러리를 얼마나 빨리 업데이트하여 다른 소프트웨어를 사용할 수 있습니까? 그래서, 매우 성숙한 조직에서 이것을 측정하기 위해, 나는 실제로 우리가 말하는 것을 실제로 log4j 이벤트에 대한 시간을 해결하기 위해 평균 4 시간 동안 가지고 있는 몇몇 조직과 이야기했습니다.
대단히 인상적입니다. 이는 DevSecOps 프로세스의 성숙도를 나타냅니다. 그래서, 나는 모든 종류를 보았다. 그리고 log4j와 같은 중요한 문제를 해결하기 위해 몇 주 또는 몇 달 동안 해결해야 하는 고객 조직을 보았습니다. 따라서 프로세스를 전체적으로 개선하기 위해 이러한 지표를 염두에 두는 것이 매우 중요합니다.
Michael Grimshaw: 그리고 제가 여기서 던지고 싶은 KPI는 플랫폼 측면에서처럼 인프라를 다룰 때 또는 엔지니어링을 다룰 때 비용이 항상 중요한 요소였다는 것입니다. 하지만 지난 몇 년 동안 금리 상승과 함께, 아시다시피, 마개는 VC 화폐와 그 많은 정말 말라까지 있지만, 게임의 이름과 상승 금리 환경은 매우 수익성이 비트 업입니다.
여기에 한 가지 측면이 있습니다. 나는이 기술을 사랑한다. 분명히 아시다시피 플랫폼 엔지니어링 책임자입니다. 저는 기술적인 측면을 좋아합니다. 특히 지난 몇 년 동안 플랫폼에서 일하고 있다면, 인프라 같은 것들, 재무 측면, CFO와 CTO에게 피드백을 명확히 하고 제공하는 것이 필수적이었습니다.
따라서 KPI는 비용과 수익에 관한 것입니다. 이것은 또 다른 중요한 측면입니다. 그리고, 저는 이런 것들 중 몇가지를 말씀드리고 싶습니다. 예를 들어, 수익 측면에서요. 레드 라인 토론을 하고 있다면, 구매를 원하는 고객이 있지만 제품을 구매하려는 경우 보안이 모든 사람의 마음에 있고 고객은 보호되고 싶어하기 때문에 보안 레드 라인을 통과하게 됩니다.
그들은 여기서 위험을 최소화하고 싶어할 것입니다. 그리고 만약 당신이 오래된 학교 정신을 가지고 그에게 온다면. 아, 그렇습니다, 우리는 사물을 개발하고 나서, 우리는 우리의 infosec이 그것들을 스캔하고 모든 것을 확인하게합니다. 나는 많은 레드 라인 토론과 계약 토론을 해왔고, 그것은 단순히 더 이상 날지 않습니다.
고객의 리스크 부서 및 법무 부서의 설문지 및 설문지 수준은 지난 5년 동안 완전히 다른 수준으로 올라갔습니다. 또한 웹 애플리케이션과 API 보호를 위해 완벽하게 통합된 교대 근무 솔루션을 구축할 수 있습니다. 다른 사람들의 변호사와 이야기할 때, 이것은 바늘을 크게 움직입니다. 무슨 뜻이죠? 즉, 거래를 더 빨리 마감할 수 있습니다. 그리고 여러분이 shift left를 연습하지 않거나 단지 infosec을 애드온으로 생각한다면, 다시 돌아가서 종가율과 결산 지점을 살펴보고 특히 보안 관련 레드라인 논의를 살펴보시기 바랍니다. 이러한 유형의 제품 문제는 너무 자주 비용 센터로 간주되기 때문입니다. 그렇지 않습니다. 수익을 막을 수 있고 엄청난 돈을 절약 할 수 있습니다.
팟캐스트 초반에는 내부 비용에 대한 비용 절감에 대해 다뤘지만, 베타에 대한 수익은 여기서 강조해야 할 중요한 요소로 작용합니다. 왜냐하면 이자율 상승 세계에서 많은 사람들이 주목하고 있는 부분이기 때문입니다.
마무리
리처드 유: 훌륭한 점입니다. 나는 우리가 모자를 조금 바꾸어서 기쁘다, 알다시피, 내 SDLC 모자를 쓰고 당신의 비즈니스 모자를 쓰고처럼. 대단하네요. 우리가 공유한 모든 것들이 관객들에게 약간의 가치를 제공하기를 바랍니다.
로렌 브래들리: 두 분 모두 고맙습니다. 끝내야 할 좋은 메모라고 생각합니다. 지금까지 왼쪽으로 이동하는 것의 중요성과 웹 애플리케이션과 API 보호를 DevOps 라이프사이클에 효과적으로 적용하는 방법에 대해 살펴보았습니다. 그리고 물론, 성공을 효과적으로 측정하는 방법. 거짓 긍정이 더 적습니까? 평균 시간 해결책은 무엇입니까? 소프트웨어를 얼마나 빨리 배송하고 있습니까? 더 많은 수익을 올리고 있습니까?
이러한 모든 지표는 비즈니스의 성공에 매우 중요합니다. 마이클과 리처드, 오늘 함께 해주셔서 감사합니다. Beyond the Edge에 동참해 주셔서 진심으로 기쁘게 생각하며 청중에게도 감사의 말씀을 전합니다. 다음 에피소드에서 뵙겠습니다.
