A04 2021 – Insecure Design

Insecure Design
2021년에는 디자인 및 아키텍처 결함과 관련된 위험을 다루는 새로운 카테고리가 추가되었다. 이는 위협 모델링, 안전한 디자인 패턴, 참조 아키텍처의 활용을 더욱 강조한다.
그러므로 코딩 단계에서 "shift-left"를 넘어, "Secure by Design" 원칙을 위한 중요한 pre-code activities로 나아가야 한다.

Insecure design은 "missing or ineffective control design(결여되거나 비효과적인 제어 설계)"로 표현되는 다양한 약점을 포괄하는 넓은 범주로, 다른 Top 10 위험 카테고리의 근원이 아니다. 디자인 결함과 구현 결함은 서로 다르며, 그 근본 원인과 해결 방법도 상이하다. 안전한 디자인이 존재하더라도 구현 결함으로 인해 취약점이 발생할 수 있다. 그러나 Insecure design은 정의상 필요한 보안 제어가 존재하지 않기 때문에 완벽한 구현으로도 수정될 수 없다. Insecure design의 원인 중 하나는 소프트웨어나 시스템에 대한 비즈니스 위험 프로파일링 부족으로, 이는 적절한 보안 디자인 수준을 결정하지 못하게 한다.


요구사항 및 자원 관리
비즈니스와 협의하여 애플리케이션의 비즈니스 요구사항을 수집하고, 데이터 자산의 기밀성, 무결성, 가용성 및 진정성에 대한 보호 요구사항을 포함해야 한다. 애플리케이션의 노출 정도와 접근 제어 외에 세분화가 필요한지를 고려한다. 기능적 및 비기능적 보안 요구사항을 포함한 기술 요구사항을 정리하고, 디자인, 구축, 테스트 및 운영 전반에 걸쳐 보안 활동을 포함하는 예산을 계획하고 협상해야 한다.


안전한 디자인
안전한 디자인은 위협을 지속적으로 평가하고, 알려진 공격 방법을 방지하기 위해 코드가 robust하게 설계되고 테스트되도록 보장하는 문화와 방법론이다. 위협 모델링은 refinement 세션에 통합되어야 하며, 데이터 흐름 및 접근 제어의 변화에 주목해야 한다. 사용자 스토리 개발 시 올바른 흐름과 실패 상태를 파악하고, 책임 있는 당사자들 간에 이를 잘 이해하고 동의하도록 한다. 예상 및 실패 흐름에 대한 가정과 조건을 분석하고, 이를 검증할 방법과 적절한 행동을 보장하기 위한 조건을 설정한다. 결과는 사용자 스토리에 문서화되며, 실수로부터 배우고 개선을 장려하기 위해 긍정적인 인센티브를 제공해야 한다. 안전한 디자인은 소프트웨어에 추가하거나 도구로 사용할 수 있는 것이 아니다.

안전한 개발 주기
안전한 소프트웨어는 안전한 개발 주기를 요구하며, 안전한 디자인 패턴, paved road 방법론, 안전한 구성 요소 라이브러리, 도구 및 위협 모델링을 포함해야 한다. 소프트웨어 프로젝트 시작부터 유지 관리까지 전 과정에 걸쳐 보안 전문가와 협력해야 한다. OWASP 소프트웨어 보증 성숙도 모델(SAMM)을 활용해 안전한 소프트웨어 개발 노력을 구조화하는 것을 고려해야 한다.

예방 방법

• AppSec 전문가와 협력하여 보안 및 프라이버시 관련 제어를 평가하고 설계하는 안전한 개발 주기를 설정하고 활용한다.

• 안전한 디자인 패턴 라이브러리 또는 사용 준비가 된 구성 요소를 구축하고 활용한다.

• 중요한 인증, 접근 제어, 비즈니스 논리 및 주요 흐름에 대해 위협 모델링을 사용한다.

• 사용자 스토리에 보안 언어와 제어를 통합한다.

• 애플리케이션의 모든 계층에서 plausibility check를 통합한다(프론트엔드에서 백엔드까지).

• 단위 및 통합 테스트를 작성해 모든 중요한 흐름이 위협 모델에 저항하는지 검증한다. 각 계층에 대한 사용 사례 및 오용 사례를 수집한다.

• 노출 및 보호 요구에 따라 시스템 및 네트워크 계층에서 계층을 분리한다.

• 모든 계층에서 견고하게 테넌트를 세분화한다.

• 사용자나 서비스에 따라 자원 소비를 제한한다.

공격 시나리오 예시

시나리오 #1
credential recovery workflow에 “질문과 답변” 기능이 포함되어 있는데, 이는 NIST 800-63b, OWASP ASVS, OWASP Top 10에서 금지된다. 질문과 답변은 여러 사람이 알 수 있으므로 신뢰할 수 있는 신원 증명이 아니다. 이러한 코드는 제거하고 더 안전한 디자인으로 대체해야 한다.

시나리오 #2
한 영화 체인이 단체 예약 할인과 최대 15명까지의 예약을 허용하지만 보증금을 요구한다. 공격자는 이 흐름을 위협 모델링하고, 몇 번의 요청으로 600석을 예약할 수 있는지 테스트할 수 있다. 이는 막대한 수익 손실을 초래할 수 있다.

시나리오 #3
한 소매 체인의 전자상거래 웹사이트는 scalper들이 고급 비디오 카드를 구매하여 경매 사이트에서 되팔 수 있는 bot에 대한 보호 장치가 없다. 이는 비디오 카드 제조사와 소매 체인에 대한 부정적인 평판을 남기고, 카드를 구매할 수 없는 팬들의 불만을 유발한다. 신뢰할 수 없는 구매를 식별하고 거래를 거부하기 위해 구매 시점을 기반으로 한 anti-bot 디자인과 도메인 논리 규칙이 필요하다.