책 발췌 – 보안 위협 모델링 예 by Gayathri Mohan

출처: 2022년, Full Stack Testing - A Practical Guide for Delivering High Quality Software, Gayathri Mohan, 7장 Security Testing

 

한줄요약: 위협 모델링(Threat Modeling)을 통해 애플리케이션의 보안 위협을 식별하고 보안 관련 테스트케이스를 도출하는 예를 제시한다.

 

---

 

위협 모델링

위협 모델링은 모든 잠재적인 보안 위협을 모으는 구조화된 방법이다. 애플리케이션의 작은 범위 각각에 대해 위협 모델링을 수행하는 것이 일반적 관행이다. 예를 들어 유저 스토리(user story)당 15분 동안 위협 모델링을 수행할 수 있다. 보안 위협을 모델링한 후에는 리스크의 영향(impact)과 가능성(probability)을 기준으로 우선 순위를 지정한다. 위협을 식별하고 우선순위를 정한 후에는 동일한 유저 스토리에서 솔루션을 다루거나 필요한 경우 이 목적을 위해 새로운 "악용자(abuser)" 또는 "사악한 사용자(evil user)" 스토리를 만든다.

 

 

위협 모델링 단계

위협 모델링은 팀으로 수행하는 것이 좋다. 팀이 구성되면 다음 마일스톤을 거친다.

 

단계1: 기능 정의(Define the feature)

첫 번째 단계는 위협 모델링을 위한 기능의 범위를 정의하는 것이다. 그런 다음 시스템의 사용자 흐름과 다양한 유형의 사용자(users) 또는 행위자(actors)를 그린다. 이것이 명확해지면 한 컴포넌트에서 다른 컴포넌트로 데이터 흐름을 매핑한다.

 

단계2: 자산 정의(Define the assets)

두 번째 단계는 보호해야 할 기능의 자산을 식별하는 것이다. 각 자산 손실의 영향에 대해 논의하고 리스크의 심각도를 파악한다.

 

단계3: 해커처럼 사고하기(Black hat thinking)

다음으로 해커처럼 생각하기 시작하고 애플리케이션 자산을 공격할 방법을 생각한다. 여기서 팀이 "시스템을 깨부수자!"라는 사고방식을 가져야 한다. STRIDE 모델을 사용하여 애플리케이션에 발생할 수 있는 모든 보안 위협을 브레인스토밍한다. 지금 당장은 어떤 것이 정말로 위협인지 아닌지 논쟁하지 않고 상상력을 자유롭게 흐르게 하고 모든 아이디어를 끈끈하게 포착한다.

 

단계4: 위협의 우선순위를 정하고 스토리를 포착(Prioritize the threats and capture stories)

식별한 위협의 가능성과 잠재적 영향을 분석하고 우선순위를 정한다. 위협 모델링 브레인스토밍 세션 후에 팀이 조치를 취할 수 있도록 이를 악용자 스토리(abuser stories)로 포착한다.

 

Note: STRIDE 위협 모델

애플리케이션 자산을 손상시킬 수 있는 가능한 모든 위협을 식별하는 데 도움이 되도록 Microsoft의 Loren Kohnfelder와 Praerit Garg가 개발한 위협 모델링 프레임워크이다. STRIDE는 Spoofed Identity, Tampering with inputs, Repudiation of Action, Information disclosure, Denial of Service, Escalation of privileges의 약어이다. 한 번에 하나씩 살펴보면서 애플리케이션에 대해 해당 범주에서 가능한 모든 위협을 논의할 수 있다. 

• 신원 도용(Spoofed identity): 해커가 자산에 접근하기 위해 다른 사람의 신원을 가장하는 공격이다.
• 입력 조작(Tampering with inputs): 무결성을 위반하는 방식으로 애플리케이션의 내용(코드, 데이터, 메모리 등)을 수정하는 것이 포함된다. 일반적으로 스크립트와 같은 악성 코드를 UI나 다른 레이어에 주입하여 수행된다.
• 액션 부인(Repudiation of actions): 악의적인 사용자의 액션을 입증하거나 추적할 수 없을 때 발생한다.
• 정보 노출(Information disclosure): 승인되지 않은 개체가 애플리케이션 자산에 대한 액세스 권한을 얻는 것과 관련이 있다.
• 서비스 거부(Denial of Service): DoS 공격은 애플리케이션의 서비스를 중단시켜 회사의 수익 손실과 평판 손상을 초래하는 것을 목표로 한다. 대표적으로 DDoS 공격이 있다.
• 권한 승격(Escalation of privileges): 권한 상승 공격은 악의적인 사용자가 승인되지 않은 권한을 얻어 액세스 권한을 높일 수 있을 때 발생한다.

 

 

위협 모델링 예

위협 모델링 연습을 위해 소매점에서 주문을 관리(생성/보기/변경/삭제)하는 애플리케이션이 있다고 가정하자. 애플리케이션에는 데이터베이스에 저장된 주문 데이터에 대한 비즈니스 오퍼레이션을 수행하기 위한 웹 UI와 백엔드 REST 서비스가 있다. 

 

단계1:

사용자/행위자, 데이터 흐름 및 다양한 컴포넌트 간의 통합을 정의하는 첫 번째 단계를 살펴보자.

 

시스템 사용자는 다음과 같다.

• 주문을 생성, 변경, 취소하는 매장 직원(store assistant)
• 인프라, 구성 및 배포를 관리하는 시스템 관리자(system administrator)
• 전화로 주문 상태와 관련된 문의에 응답하기 위해 애플리케이션을 사용하는 고객 서비스 담당자(customer service executive)

 

사용자 흐름은 간단하다. 매장 직원과 고객 서비스 담당자가 최신 주문 목록을 보려면 애플리케이션에 로그인해야 하며, 주문을 관리할 수 있는 옵션이 제공된다. 그림 7-4는 사용자 흐름을 위한 컴포넌트 통합과 컴포넌트 간의 데이터 흐름을 보여준다. 그림 7-5에 표시된 것처럼 시스템 관리자는 스크립트를 실행하거나 인프라를 구성하려면 가상 머신(VM)에 로그인해야 한다.

 

그림 7-4. 샘플 주문 관리 시스템의 사용자 흐름 및 데이터 흐름

 

그림 7-5. 시스템 관리자의 사용자 흐름

 

단계2:

다음으로 보호해야 할 자산을 살펴보면 다음과 같다. 

• 주문 정보(Order information)는 비즈니스에 중요한 자산이다. 고객의 주문이 변조되어 평판이 훼손되면 고객은 불만을 갖게 된다.
• 주문에는 이름, 전화번호, 결제 정보, 집 주소 등 고객의 개인 데이터가 포함된다. 기밀 정보가 노출되면 소송이 발생하고 고객에게 피해를 줄 수 있으므로 고객 세부 정보(customer details)는 또 다른 필수 자산이다.
• 데이터베이스에는 해당 기업의 전체 판매 정보(sales information)가 포함되어 있다. 이것이 노출되면 데이터가 암시장이나 경쟁업체에 판매될 수 있으므로 고객과 비즈니스에 위험할 수 있다.
• 가동 중지 시간이 발생하면 주문 거래 실패 및 판매 손실로 이어질 수 있으므로 애플리케이션을 호스팅하는 인프라(infrastructure)를 보호하는 것도 중요하다.

 

단계3:

다음은 해커처럼 생각하기다! 사용자와 데이터 흐름을 상기하고 해커가 자산을 어떻게 통제할 수 있는지 생각해 본다. STRIDE 모델을 사용하여 생각을 구조화한다. 완료되면 생각해낸 내용을 그림 7-6에서 식별된 가능한 위협과 비교한다.

 

그림 7-6. 식별된 위협 지도

 

신원 도용(Spoofed identity)

①    로그인 정보를 얻기 위해 시스템 관리자에게 사회 공학적 트릭을 사용할 수도 있고, 단순히 숄더 서핑(어깨너머로 보기)이나 악성 코드를 사용하여 트릭을 수행할 수도 있다. 시스템 관리자 역할에는 강력한 권한이 있으므로 악의적인 행위자가 이를 사용하여 인프라를 다운시킬 수 있다.

②    매장 직원이 로그아웃하는 것을 잊을 수 있으며, 매장에 있는 누구나 로그인된 세션을 사용하여 기존 주문의 배송 주소를 변경할 수 있다(예: 자신의 주소로 변경).

 

입력 조작(Tampering with inputs)

③    엔드포인트가 보호되지 않는 경우 공격자는 열려 있는 브라우저 세션에서 주문 서비스 엔드포인트를 확보하고 나중에 주문을 변조할 수 있다.

④    고객 결제 세부정보를 가로채기 위해 주문하는 동안 코드 삽입이 사용될 수 있다.

 

액션 부인(Repudiation of actions)

⑤    시스템 관리자는 자신의 액션에 대한 로그가 없다는 것을 알게 되면 데이터베이스에 직접 레코드를 삽입하고 기타 관련 프로세스를 트리거하여 가족과 친구를 위한 대량 주문을 생성할 수 있다.

 

정보 노출(Information disclosure)

⑥    데이터베이스가 백도어를 통해 공격을 당할 경우 데이터가 일반 텍스트로 저장되므로 데이터베이스에 포함된 모든 정보가 노출된다.

⑦    암호화되지 않은 로그나 기타 저장소에서 패스워드를 훔치면 공격자가 주문 데이터를 변조할 수 있다.

⑧    고객 서비스 담당 임원의 오퍼레이션에 어떤 제한도 없다. 그들이 해야 할 일은 현재 주문 상태 정보를 고객에게 전달하는 것뿐이지만 주문을 편집할 수도 있다. 그들은 공범과 협력하여 자신의 권한을 남용할 수 있다.

⑨    /viewOrders 엔드포인트를 사용하면 원하는 수의 레코드가 반환될 수 있다. 일단 뚫리면 이 엔드포인트를 사용하여 모든 주문을 볼 수 있다. 적어도 폭발 반경을 줄이는 것은 생각해야 한다.

 

서비스 거부(Denial of service)

⑩    공격자는 DDoS 공격을 감행하여 주문 서비스를 중단시켜 매출 손실을 초래할 수 있다.

 

권한 승격(Escalation of privileges)

⑪    공격자가 관리자 로그인 정보를 확보하는 경우 새로운 사용자를 추가하거나 기존 사용자의 권한을 상승시켜 향후 시스템에 대한 높은 수준의 액세스를 유지할 수 있다. 또한 시스템 관리자 액션에 대한 로그가 없기 때문에 아무도 모르게 주문 레코드를 생성, 수정 또는 삭제할 수 있다.

 

단계4:

다음 단계는 위협의 우선순위를 정하고 스토리를 포착하는 것이다. 식별된 위협의 가능성과 영향을 기반으로 다음과 같은 새로운 보안 관련 사용자 스토리 및 악용자 스토리를 추가할 수 있다. 

1. “악의적인 사용자로서 데이터베이스에 접근하더라도 고객 세부정보를 볼 수 없어야 한다.”
2. “악의적인 사용자로서 공개된 브라우저 세션을 이용할 수 없어야 한다.”
3. "악의적인 사용자로서 시스템 관리자나 고객 서비스 담당자의 로그인 정보에 접근할 수 있다면 주문을 편집할 수 없어야 한다."
4. “매장 직원으로서 나는 주문 서비스에 수정 요청을 할 수 있는 유일한 사람이어야 한다.”
5. “매장 직원으로서 비밀번호를 강력한 비밀번호로 변경하라는 메시지를 자주 받아야 한다.”

 

 

위협 모델에 기반한 보안 테스트케이스 도출 예

위협 모델을 통해 애플리케이션에 대한 공격이 이루어질 수 있는 다양한 방법에 대한 통찰을 얻을 수 있다. 그리고 악용자 스토리(abuser stories)를 기반으로 보안 관련 테스트케이스에 대한 생생한 아이디어를 얻을 수 있다. 아래는 주문 관리 시스템의 다양한 애플리케이션 계층에 대한 보안 테스트케이스 예이다.

 

1. UI 계층에서:

• 세션 타임아웃 후 사용자에게 다시 로그인하라는 메시지가 표시되는지 확인한다.
• 설정된 횟수만큼 로그인 시도가 실패하면 사용자 로그인이 잠기는지 확인한다.
• 입력 필드에 잘못된 입력(예: JavaScript 코드, SQL 쿼리 등)에 대한 유효성 검사가 있는지 확인한다.
• 짧은 기간 후에 액세스 토큰이 만료되는지 확인한다. 그러나 세션 타임아웃까지 사용자를 로그인 상태로 유지하려면 UI에서 새로고침 토큰 호출(refresh token call)을 수행해야 한다.
• 시스템 관리자 또는 고객 서비스 담당자로 로그인하면 UI에서 주문을 편집할 수 있는 옵션이 없음을 확인한다.

 

2. API 레이어에서:

• 만료된 액세스 토큰을 재사용하면 주문 서비스가 401 Unauthorized response를 반환하는지 확인한다(공격자에게 추가 정보 노출을 피하려면 400 에러가 선호됨).
• API 패러미터 값(UI 입력 필드와 유사)에 대해 적절한 유효성 검사가 수행되고 유효성 검사를 통과하지 못한 경우 API가 404 에러를 반환하는지 확인한다.
• 시스템 관리자 또는 고객 서비스 담당자의 액세스 토큰이 사용되는 경우 /editOrder 엔드포인트가 401 Unauthorized response를 반환하는지 확인한다.

 

3. DB 계층에서:

• NIST 지침(NIST Password Guidelines and Best Practices for 2020)에 따라 패스워드가 DB에 해시(동적 솔트 포함)로 저장되어 있는지 확인한다.
• 민감한 고객 세부정보가 DB에 암호화되어 있는지 확인한다.

 

4. 애플리케이션 로그에서:

• 애플리케이션 로그에 패스워드가 일반 텍스트(plain text)로 기록되지 않는지 확인한다.
• 민감한 사용자 정보가 애플리케이션 로그에 일반 텍스트로 기록되지 않는지 확인한다.
• 시스템 관리자(system admin)를 포함하여 시스템에서 수행된 모든 액션에 대한 적절한 애플리케이션 로그가 타임스탬프를 수반하여 기록되는지 확인한다.