오용 사례 테스트
더 많은 작업
- Misuse Case Testing; 오용 사례 테스트, 악용 사례(abuse case) 테스트
- 시스템이 해서는 안 되는 일을 공격자나 부주의한 사용자 관점에서 시나리오로 정의하고, 시스템이 그 시나리오를 실제로 막는지 확인하는 테스트
일반적인 기능 테스트는 유스케이스(use case), 즉 "사용자가 시스템으로 무엇을 할 수 있어야 하는가"를 기준으로 한다. 오용 사례(misuse case)는 이것을 뒤집어 "악의적 행위자가 시스템으로 무엇을 하려 하는가"를 같은 형식으로 적는다. 정상 경로만 시험하면 "로그인이 된다"는 확인할 수 있지만 "비밀번호를 수만 번 바꿔 넣어도 로그인이 되는가"는 확인하지 못한다. 오용 사례 테스트는 이런 부정적 요구사항(negative requirement)을 테스트 대상으로 끌어들인다.
용어는 문헌마다 조금 다르게 쓴다. 오용 사례는 악의적 공격과 실수로 인한 잘못된 사용을 모두 포함하는 넓은 뜻으로, 악용 사례(abuse case)는 의도적인 공격에 초점을 둔 뜻으로 쓰는 경우가 많다. OWASP의 Abuse Case Cheat Sheet는 악용 사례를 "구현자가 예상하지 못한 방식으로 기능을 사용해, 공격자가 자신의 행동이나 입력으로 그 기능이나 결과에 영향을 미치는 것"으로 정의하고, 온라인 상점에서 주문 전에 상품 가격을 마음대로 바꾸는 것을 업무 측면 악용 사례의 예로 든다. 또 악용 사례를 개발 초기에 정의해 보안 요구사항과 테스트로 연결하라고 권한다. CISSP 6.2는 "Misuse case testing"을 보안 통제 테스트 기법의 하나로 든다.
노르웨이의 굿토름 신드레(Guttorm Sindre)와 안드레아스 오프달(Andreas L. Opdahl)은 학술지 Requirements Engineering 제10권(2005)에 실린 논문 "Eliciting security requirements with misuse cases"에서 유스케이스 기법을 확장해 보안 위협과 요구사항을 체계적으로 도출하는 방법을 제시했다. UML 유스케이스 다이어그램에 다음 요소를 더한다.
| 요소 | 의미 |
|---|---|
| 오용자(misuser) | 시스템에 해를 끼치려는 행위자(외부 공격자, 악의적 내부자). 정상 행위자와 구분되게 색을 반전해 그리는 경우가 많다 |
| 오용 사례(misuse case) | 오용자가 수행하려는 행위 순서. 정상 유스케이스와 구분되게 표시한다 |
| 위협한다(threatens) | 오용 사례가 어떤 정상 기능(유스케이스)을 위협하는지 나타내는 관계 |
| 완화한다(mitigates) | 어떤 보안 기능(유스케이스)이 오용 사례를 완화하는지 나타내는 관계 |
논문은 기존 유스케이스 관계(include, extend) 대신 위협·완화 관계를 쓰도록 정리했다. 다이어그램을 그리면 "어떤 기능이 어떤 공격에 노출되어 있고, 그 공격을 막는 기능은 무엇인가"가 한눈에 보이며, 완화 관계가 없는 오용 사례가 바로 보안 요구사항의 공백이다.
- 정상 유스케이스와 행위자를 정리한다.
- 각 유스케이스에 대해 오용자를 정한다(익명 외부인, 인증된 일반 사용자, 악의적 관리자, 자동화된 봇 등).
- 오용자가 노리는 목표와 행위 순서를 적는다. 위협 모델링 결과(예: STRIDE 분류)와 OWASP Top 10 같은 공격 목록을 참고하면 빠뜨림이 줄어든다.
- 오용 사례마다 이를 막거나 탐지할 보안 요구사항(완화 유스케이스)을 정한다.
- 보안 요구사항을 검증할 수 있는 테스트 케이스로 바꾸고 기대 결과를 적는다.
- 위험도에 따라 우선순위를 정해 자동 테스트와 수동 테스트로 나누어 수행한다.
| 항목 | 예 1: 로그인 무차별 대입 | 예 2: 장바구니 가격 조작 |
|---|---|---|
| 관련 유스케이스 | 회원 로그인 | 상품 주문·결제 |
| 오용자 | 자동화 도구를 쓰는 외부 공격자 | 인증된 일반 회원 |
| 오용 시나리오 | 유출된 계정 목록이나 사전 단어로 로그인 요청을 대량 반복한다(무차별 대입 공격, 크리덴셜 스터핑) | 웹 프록시로 요청을 가로채 상품 가격이나 수량을 음수·0원으로 바꿔 결제 요청을 보낸다 |
| 위협받는 자산 | 계정, 개인정보 | 매출, 재고, 정산 무결성 |
| 보안 요구사항(완화) | 실패 횟수 제한과 지연, 계정 잠금 또는 추가 인증, 봇 탐지, 실패 로그와 경보, 다중 인증 | 가격·할인은 서버의 상품 정보로 다시 계산하고 클라이언트 값은 무시, 수량 범위 검증, 결제 금액과 주문 금액 대조 |
| 테스트 케이스 | 같은 계정에 틀린 비밀번호를 연속 입력했을 때 정해진 횟수 이후 차단되고 경보가 발생하는지 확인 | 가격 필드를 1원으로 바꾼 요청이 거부되거나 서버 가격으로 처리되는지 확인 |
| 기대 결과 | 차단, 감사 로그 기록, 정상 사용자 안내 | 거부 또는 정상 가격 결제, 이상 거래 기록 |
두 번째 예처럼 업무 논리(business logic)를 악용하는 공격은 자동 스캐너가 거의 찾지 못한다. 업무 흐름을 아는 사람이 오용 사례로 정의해야 테스트 대상에 들어간다.
| 구분 | 위협 모델링 | 오용 사례 |
|---|---|---|
| 관점 | 시스템 구조(데이터 흐름, 신뢰 경계) 중심 | 사용자 행위·시나리오 중심 |
| 산출물 | 위협 목록, 위험도, 대응책 | 오용 시나리오, 보안 요구사항, 테스트 케이스 |
| 강점 | 구조적 빠뜨림을 줄인다 | 업무 담당자도 이해하기 쉽고 테스트로 바로 이어진다 |
둘은 경쟁 관계가 아니다. 위협 모델링으로 "어디가 위험한가"를 찾고, 오용 사례로 "그 위험이 사용자 행위로 어떻게 나타나는가"를 적어 테스트로 만든다. 생성형 AI 기능이 있는 서비스라면 프롬프트 주입으로 내부 지시를 우회하거나 다른 사용자 데이터를 끌어내는 시나리오도 오용 사례로 정의해 시험한다.
- 오용 사례 테스트는 "시스템이 하지 말아야 할 일"을 시험한다. 정상 기능만 시험하는 유스케이스 테스트와 구분한다.
- 오용 사례는 요구사항 단계에서 만들수록 효과가 크다. "보안 요구사항을 가장 이른 시점에 도출하는 방법"을 묻으면 오용 사례나 위협 모델링을 고른다.
- 업무 논리 결함(가격 조작, 절차 건너뛰기)은 자동 스캐너보다 오용 사례 기반 테스트로 찾는다.
- 다이어그램의 관계는 "위협한다(threatens)"와 "완화한다(mitigates)"이다.