저는 놀라울 정도로 복잡한 질문에 대해 고민해 왔습니다:

Secure by Design은 실제로 어디에서 끝나는가?

이 용어는 이제 위협 모델링 (threat modelling) 및 아키텍처 리뷰 (architecture reviews)부터 보안 개발 (secure development), 취약점 스캐닝 (vulnerability scanning) 및 보증 (assurance)에 이르기까지 모든 것을 포괄합니다.

이 모든 것들은 중요하지만, 시스템을 보안적으로 설계하는 것과 구현이 실제로 보안적인지를 입증하는 것을 분리하는 데 가치가 있다고 생각합니다.

저는 이를 위해 간단한 모델을 사용해 왔습니다.

Secure by Design을 위한 3D 방법론

설계 단계 (design-time) 프로세스는 세 단계로 구성됩니다:

1. 설계 (Design)

분석이 가능하도록 의도된 시스템에 대해 충분히 정확한 표현을 생성합니다.

이는 아키텍처 다이어그램 (architecture diagram), 모델 (model) 또는 사양 (specification)일 수 있습니다. 중요한 점은 이것이 최종적으로 구현된 것에서 재구성된 것이 아니라, 아키텍처적 의도 (architectural intent)를 나타내야 한다는 것입니다.

이러한 구분은 AI 지원 개발 (AI-assisted development)에서 특히 중요해집니다. 만약 확률적 AI (probabilistic AI)가 구현을 생성하고, 또 다른 확률적 AI가 그 구현으로부터 아키텍처를 재구성한다면, 우리의 보안 분석은 통제된 의도가 아닌 추론된 의도에 점점 더 기반하게 됩니다.

2. 정의 (Define)

시스템에 대한 보안 목표 (security objectives)를 정의합니다.

이를 수행하는 데에는 다음과 같은 여러 방법이 있습니다:

• 위협 모델링 (threat modelling)
• 리스크 평가 (risk assessment)
• 보안 정책 및 통제 평가 (security policies and control assessments)

저는 이러한 접근 방식들이 서로 경쟁할 필요는 없다고 생각합니다.

위협 모델링은 명확하지 않은 리스크를 발견하는 데 특히 유용합니다. 자산 수준의 리스크 평가 (Asset-level risk assessment)는 보안 목표를 설정하는 확장 가능한 방법을 제공할 수 있으며, 정책 (policies)은 반복 가능한 조직적 기대치를 제공할 수 있습니다.

3. 결정 (Determine)

해당 목표를 달기 위해 필요한 통제 항목 (controls)을 결정합니다.

이 지점이 맥락 (context)이 특히 중요해지는 부분이라고 생각합니다.

통제 항목은 단순히 무엇이 일어나야 하는지만 말해서는 안 됩니다. 이상적으로는 왜 해당 통제가 존재하는지, 그리고 그것이 어떤 아키텍처 요소 (architectural element)에 적용되는지를 유지해야 합니다.

이는 인간 개발자, AI 코딩 어시스턴트 (AI coding assistants), 그리고 궁극적으로는 자율 개발 에이전트 (autonomous development agents)에게 전달될 수 있는 무언가를 우리에게 제공합니다.

이 시점에서, 저는 Secure by Design (설계 단계부터의 보안)이 완성되었다고 주장하고 싶습니다.

우리는 우리가 무엇을 구축하고자 하는지 기술했고, 보안 목표 (security objectives)를 설정했으며, 이를 달성하기 위해 필요한 통제 항목 (controls)을 결정했습니다.

하지만 결과물인 시스템이 실제로 그중 어떤 것이라도 수행하는지는 아직 입증하지 않았습니다.

네 번째 D: 입증 (Demonstrate)

이는 선택적인 네 번째 단계로 이어집니다:

4. 입증 (Demonstrate)

구현된 시스템이 설계와 그 통제 항목들을 실제로 실현하고 있음을 입증하십시오.

여기에는 다음이 포함될 수 있습니다:

• 통제 검증 (control validation)
• 아키텍처 준수 (architectural conformance)
• 보안 테스트 (security testing)
• 보증 증거 (assurance evidence)
• AI 생성 구현물에 대한 평가 (evaluation of AI-generated implementations)

이는 제가 유용하다고 느낀 차이점을 만들어냅니다:

3D는 보안 설계된 시스템이 무엇이어야 하는지를 결정합니다. 4D는 구현이 실제로 설계를 실현함을 입증함으로써 이를 보안 인도 (secure delivery)로 확장합니다.

즉:

3D 방법론 — Secure by Design

Design (설계) → Define (정의) → Determine (결정)

그리고:

4D 방법론 — Secure Delivery

Design (설계) → Define (정의) → Determine (결정) → Demonstrate (입증)

AI 에이전트가 소프트웨어 인도 (software delivery)에서 더 큰 역할을 맡게 됨에 따라 이 구분은 더욱 유용해질 것이라고 생각합니다.

에이전트에게는 단순히 통제 항목의 목록만 필요한 것이 아닙니다. 해당 통제 항목이 무엇에 적용되는지, 그리고 왜 존재하는지를 이해할 수 있는 충분한 아키텍처 맥락 (architectural context)이 필요합니다.

그리고 만약 에이전트가 구현에 참여한다면, 에이전트가 생성한 결과물이 여전히 그러한 결정 사항들을 준수하고 있는지 평가할 방법이 필요합니다.

이 구분이 타당할까요?

이 부분이 제가 피드백을 받고 싶은 지점입니다.

필요한 통제 항목들이 결정되면 Secure by Design이 완성되었다고 간주하시겠습니까?

아니면 해당 통제 항목들이 올바르게 구현되었음을 입증하는 것이 Secure by Design 자체의 일부로 남아 있어야 할까요?

AI와 함께 어떻게 진화하는지를 포함하여 더 긴 버전의 글을 작성해 두었습니다:

The 3D Method for Secure by Design