보안을 더 왼쪽으로 이동

DevSecOps에 대한 아이디어는 엔지니어가 개발 시점에 보안 문제를 통합할 것으로 예상되어 사실 이후에 계층화되지 않은 문제가 아닌 한동안 존재했습니다. 우리는 이것을 "왼쪽으로 이동"이라고 불렀고, 나는 우리가 충분히 왼쪽으로 이동하고 있다고 생각하지 않습니다.

보안은 제품 수준의 문제입니다. 그것은 제품 아이디어에서 논의되어야 하고 제품 에픽과 사용자 스토리에 일급 시민으로서 포함되어야 합니다. 우리는 "항공사 마일리지 사용"이라는 서사시를 사용해서는 안 되며 모든 사람이 사용자 경험이 암묵적으로 안전해야 한다는 것을 알고 있다고 가정해야 합니다. 대신 우리의 에픽은 "안전하게 항공사 마일리지 사용"으로 이름을 지정해야 합니다.

거기에서 보안은 제품 설계 및 구현의 모든 요소를 ​​통해 흘러야 합니다. 개념적 아키텍처에는 ID와 같은 보안 문제가 포함되어야 합니다. 물리적 아키텍처에는 암호화 및 인증서 관리와 같은 보안 문제가 포함되어야 합니다. 배포 아키텍처에는 레지스트리에서 그리고 프로덕션에서 실행되는 동안 컨테이너 스캔이 포함되어야 합니다. 물론 우리 소프트웨어는 보안을 염두에 두고 작성해야 합니다.

몇 년 전 소프트웨어 및 클라우드 플랫폼에 대한 "DevSecOps" 접근 방식을 구축하면서 보안 전문가와 함께 일할 수 있는 행운이 있었습니다. "왼쪽으로 이동"의 일환으로 우리는 개발자에게 OWASP 교육을 받고 PCI DSS 및 SOC2의 사양을 연구하도록 했습니다. 그것은 어느 정도 효과가 있었지만 우리는 여전히 이것을 왼쪽으로 옮기기 위해 할 수 있는 일이 더 있다고 느꼈습니다. 그들은 엔지니어에게 소프트웨어에서 CAIQ를 수행하도록 제안했습니다.

CAIQ (Consensus Assessment Initiative Questionnaire)는 플랫폼 또는 ISV 제품에서 구현된 보안 제어를 식별합니다. 보안 전문가는 공급업체가 해야 하는 방식으로 응용 프로그램을 직접 수행하여 처리할 것을 제안했습니다. 그들은 우리에게 제품을 판매하려는 모든 IaaS/PaaS/SaaS ISV가 CAIQ를 작성했어야 하며 그것이 무엇인지 알고 있고 우리에게 제공할 답변이 준비되어 있다면 좋은 제품이라는 신호라고 말했습니다. 우리 자신에게 이렇게 함으로써 우리는 우리가 충족한 통제를 스스로 식별하고 유사한 표준을 유지할 수 있었습니다.

나는 그 이후로 이것에 대해 생각해 왔습니다. 소프트웨어 팀이 CAIQ를 수행하는 것은 좋은 생각일 뿐만 아니라 SDLC에 관련된 모든 사람이 설문지의 개념을 알고 제품 연습으로 구현 범위에 속하는 컨트롤을 식별하는 것입니다. 소프트웨어 개발 초기에 이 작업을 수행하면 보안이 완전히 왼쪽으로 이동하고 빌드하는 것의 핵심 개념이 됩니다. 현재 버전(v4)에는 261개의 ​​예/아니오 질문이 있지만 비즈니스 연속성, 변경 제어, GRC, 인프라 및 가상화 보안, 공급망 등과 같은 영역을 다루는 71개의 질문만 있는 "Lite" 버전도 있습니다. CAIQ는 ISO/IEC 27001/27002/27017/27018, CCM V3.0.1, AICPA TSC(2017), CIS Controls V8, NIST 800–53r5, PCI DSSv3.2.1 및 ISF SOGP 2022와 같은 보안 표준에 매핑됩니다.

더 왼쪽으로 이동해야 합니다. CAIQ와 같은 도구를 사용하여 팀을 지원하고 SDLC 전체에서 그렇게 할 수 있도록 돕습니다. 제품 소유자, 비즈니스 분석가, 설계자, 엔지니어, 테스터, DevOps, SRE 등 모든 사람을 포함하여 팀과 함께 LITE 버전을 검토하십시오. 제품 사양 및 아키텍처 아티팩트에 대해 논의하고 차이가 있을 수 있는 부분을 확인합니다. 이 리뷰를 제품 개발 초기 단계의 일부로 만들어 더 왼쪽으로 이동하십시오.