페이퍼요약 - 소프트웨어 보안 테스팅 by POTTER

제목: 소프트웨어 보안 테스팅(Software Security Testing)

저자: BRUCE POTTER 외 1인

문서유형: 저널 페이퍼(총 5페이지) , 2004년

 

소프트웨어 보안 테스팅에서 리스크 기반 접근 방법의 필요성에 대해 기술한 자료

---

아웃사이드-인(outside→in)에서 인사이드-아웃(inside→out)으로 전환

• 컴퓨터와 네트워크 보안 테스팅(computer and network security testing)의 전통적인 접근 방법은 네트워크 인프라구조, 방화벽, 포트 스캐닝(port scanning)에 중점을 둔다. 이 개념은 경계(a perimeter)를 식별하고 방어함으로써 취약한 시스템(소프트웨어)를 공격으로부터 보호하기 위한 것이며, 이 패러다임에서 테스팅은 아웃사이드-인 접근법(an outside→in approach)에 집중하게 된다. 이것의 전통적인 예가 네트워크 포트를 검사하기 위해 Nmap 같은 툴을 가지고 포트 스캐닝을 하는 것이다. 아래 그림은 방화벽 배치에 관심을 집중한 고전적인 아웃사이드-인 패러다임을 보여줌
• 그에 반해서 이 페이퍼의 저자는 보안에서 인사이드-아웃 접근법(an inside→out approach)을 지지함. 이 접근법에서는 LAN 내부의 소프트웨어(그리고 LAN 경계에 노출된 소프트웨어) 자체가 엄격한 리스크 관리와 보안 테스팅의 대상이 된다.

[아웃사이드-인 접근 방법]

방화벽이 안으로 들어오는 길에 있는 다양한 네트워크 트래픽을 막음으로써 LAN을 보호함. 아웃사이드-인 보안 테스팅은 어떤 포트가 “열려 있고(open)” 어떤 서비스들이 해당 포트를 듣고 있는지 보기 위해 포트 스캐너로 LAN를 조사하는 일과 관련 있음. 이런 접근법과 관련된 주요 보안 리스크는 방화벽을 통해 여전히 가용한 서비스가 안전하지 않은 소프트웨어로 구현될 수 있다는 점이다.

소프트웨어 보안

• 소프트웨어 보안은 악의적 공격이 있을 때에도 소프트웨어가 동작하도록 만드는 일에 대한 것이다.
• 일반적인 소프트웨어 테스팅 문헌은 소프트웨어가 실패하면 어떤 일이 발생하는지에 관심이 있을뿐 그게 의도적인지 아닌지는 상관하지 않는다. 소프트웨어 안전성(software safety)과 소프트웨어 보안성(software security)의 차이점은 시스템을 망가트리는데 열심인 똑똑한 적(an intelligent adversary)이 존재하는지 여부에 있다.
• 설계 레벨에서의 리스크 분석이 잠재적인 보안 문제와 그 영향을 식별하는데 도움을 줄 수 있으며, 이렇게 식별되고 순위가 매겨진 소프트웨어 리스크는 소프트웨어 보안 테스팅을 가이드 하는데 도움이 된다.

소프트웨어의 보안 취약점

• 취약점(a vulnerability)은 공격자가 이용할 수 있는 에러이며, 많은 타입의 취약점이 존재한다(컴퓨터 보안 연구자들이 이것의 분류 체계를 생성해 옴).
• 소프트웨어 시스템의 보안 취약점은 그 범위가 로컬 구현 에러(예, C/C++에서 gets() 함수 호출 사용)에서부터 프로시져간 인터페이스 에러(예, 액세스 콘트롤 체크와 파일 오퍼레이션 간의 경합 상황)와 훨씬 상위의 설계 레벨 실수(예, 안전하지 않은 상태로 실패하는 에러 핸들링과 복구 시스템)까지 이른다.
• 취약점은 통상적으로 구현 레벨의 버그(bugs at the implementation level)와 설계 레벨의 결점(flaws at the design level)의 두 개 카테고리로 나뉜다. 
• 공격이 점점 더 정교해지고 있기 때문에 어떤 취약점이 실제 문제가 되는지에 대한 생각이 변화하고 있음. 예를 들어, 몇 년 전만 해도 경합 상황(race condition)을 포함한 타이밍 공격이 이국적인 것으로 여겨졌지만 현재는 흔하게 볼 수 있으며, 트램펄린을 사용한 2단계 버퍼 오버플로우 공격(two-stage buffer overflow attacks)도 한 때는 소프트웨어 과학자의 영역이었지만 지금은 쉽게 등장함
• 설계 레벨 취약점은 다루기에 가장 어려운 결함 카테고리이면서 가장 만연하고 중대한 문제이기도 하다. 프로그램이 설계 레벨 취약점을 가지고 있는지를 알아내는데에 큰 전문성이 요구되며, 따라서 그러한 결점을 발견하는게 어렵고 자동화하기도 힘들다.
• 설계 레벨 문제의 예로 객체 지향 시스템에서 에러 핸들링, 객체 공유와 신뢰 이슈(object sharing and trust issues), 보호되지 않은 (내부/외부) 데이터 채널, 부정확하거나 누락된 액세스 콘트롤 메커니즘, 로깅 결여나 부정확한 로깅, (특히 멀티 쓰레드 시스템에서) 오더링 및 타이밍 에러 등이 포함되며, 이런 종류의 결점들은 거의 항상 보안 리크스로 이어진다.

리스크 관리와 보안 테스팅

소프트웨어 보안 종사자들은 소프트웨어 보안 리스크를 관리하기 위해 아래를 포함한 여러 태스크를 수행하며, 이 중 세 개 테스크(아키텍쳐적인 리스크 분석, 리스크 기반 보안 테스트 계획, 보안 테스팅)가 특히 밀접하게 연결되어 있다.

• 보안 악용/오용 사례 생성
• 보안 요구사항 나열
• 아키텍쳐적인 리스크 분석 수행
• 리스크 기반 보안 테스트 계획 구축
• 정적 분석 툴 사용
• 보안 테스트 수행
• 최종 환경에서 침투 테스팅(penetration testing) 수행
• 보안 위반(security breaches) 후의 청소/정리

[소프트웨어 개발 생명 주기에서 소프트웨어 보안 관련 태스크들 - 이 페이퍼는 그 중 리스크 기반 보안 테스팅에 대해 다루고 있음]

보안 테스팅이 아래와 같은 두 개의 다른 접근 방법을 취할 필요가 있다.

1.      보안 메커니즘(예, 암호화, 인증, 액세스 콘트롤)의 기능(functionality)이 제대로 구현되었는지 보장하기 위해 보안 메커니즘을 테스팅함

2.      공격자의 접근 방법을 이해하고 흉내내는데 동기가 있는 리스크 기반 보안 테스팅을 수행함

Java 카드 보안 테스팅 예

• 신규 기능 추가로 지불 카드(payment cards)를 개선하기 위해 많은 신용 카드 회사들이 멀티애플리케이션 스마트 카드로 전환하고 있음. 이 카드는 전통적인 마그네틱 스트라이프 카드 보다 수천 배 더 많은 정보를 처리 및 저장하는 내장 소프트웨어 애플리케이션을 사용함
• 보안 및 사기(fraud) 이슈는 스마트 카드 채택에 앞장선 금융 기관과 상공업자에게 아주 중요한 우려 사항이며, 스마트 카드 기술을 개발 및 전개 함으로써 신용 카드 회사가 사기와 악용을 낮추려는 노력을 하고 있음. 예를 들어, 스마트 카드가 트랜잭션을 인증하고 카드소지와 발급 은행의 신원을 검증하는데 정교한 암호화 시스템(crypto system)을 사용함
• 보안 커뮤니티가 1997년 초 이후로 오픈 플랫폼(지금은 Global Platform 또는 GP로 알려짐)과 Java Card를 위한 보안 리스크 분석 및 완화에 관여해 옴. 여기서 두 개 테스팅 카테고리(기능적 보안 설계 준수, 보안 리스크에 상응하는 특정 공격 하에서 올바른 동작)에 따라 특정 벤더 구현을 테스팅하는게 중요하다는 점을 강조함 

보안 테스팅 자동화하기

• 수 년간 저자가 GP/Java Card 플랫폼의 아키텍쳐적인 리스크(architectural risks)를 식별하는 여러 프로젝트에 참여하였고, 최종 제품을 위한 자동화된 보안 테스트를 설계 및 구축해 옴
• 수 년전에 Cigital이 광범위한 리스크 분석 결과에 기반하여 Java Card 2.1.1 상에 구축된 GP 카드를 위한 자동화된 보안 테스트 프레임워크를 개발하기 시작함
• 첫 번째 테스트 셋인 ‘기능적인 보안 테스트 스위트(the functional security test suite)’는 낮은 레벨의 카드 보안 기능(예, 클래스 코드, 가용한 커맨드, 암호화 기능)을 직접적으로 검사함. 또한 이 테스트 셋은 보안 손상(security compromise)으로 이어질 수 있는 종류의 부적절한 카드 동작을 적극적으로 검사함
• 두 번째 테스트 셋인 ‘적대적인 애플릿 테스트 스위트(the hostile applet test suite)’는 Java Card 구현 상의 GP의 높은 리스크 측면들을 검사하기 위해 설계된 의도적으로 적대적인 Java Card 애플릿들의 집합이다. 

결과

• 자동화된 테스트 프레임워크로 테스트된 대부분의 카드가 모든 기능적인 보안 테스트를 통과함(스마트 카드 벤더들이 보안 기능을 포함한 기능적인 테스팅은 열심이 하기 때문인 것으로 생각됨). 반면 카드들이 리스크 기반 테스팅 패러다임에서는(즉, 적대적인 애플릿 스위트로 테스트 되었을 때는) 어떤 식으로든 실패를 보임
• 일례로 안전한 카드를 위해서는 원자적 트랜잭션 프로세싱(atomic transaction processing)의 적절한 구현이 매우 중요하다고 Java Card 설계 문서의 리스크 분석에서 식별되었음. 트랜잭션 프로세싱을 조사하기 위한 리스크 기반 테스트를 생성할 때, 트랜잭션을 위반하려는 공격자의 시도를 흉내냄으로써 트랜잭션 프로세싱 에러 핸들링이 직접적으로 실행되게 만듬. 구체적으로는 트랜잭션이 중단되거나(aborted) 또는 최종화되지 않거나(never committed), 트랜잭션 버퍼가 완전히 채워지거나, 트랜잭션이 중첩되거나(Java Card 명세에서 이를 금지하고 있음) 등을 흉내냄. 이런 테스트는 카드의 기능에 엄격히 기반하고 있기 보다는 보안 테스트 엔지니어가 리스크 분석 결과에 따라 공격자 입장에서 생각을 하면서 의도적으로 생성해 낸 것들이다.
• 여러 카드가 이 트랜잭션 테스트 서브셋에서 실패함. 이 테스트 결과로 발견된 취약점은 공격자가 잠재적으로 이로운 방식으로 트랜잭션을 끝내는걸 가능케하며, 이 취약점을 가진 카드가 현장에 배포된다면 공격자가 대중에게 발행된 라이브 카드에 성공적인 공격을 하는걸 허용하게 됨. 적절한 리스크 기반 보안 테스팅 때문에 벤더가 이 문제를 알게 되었고 릴리즈 전에 관련된 코드를 수정하였음