맨위로가기

애플리케이션 보안

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

애플리케이션 보안은 애플리케이션의 무결성, 기밀성 및 가용성을 보호하기 위한 다양한 방법론과 기술을 포괄한다. 애플리케이션 보안은 위협을 인식하고, 애플리케이션 개발 프로세스에 보안을 통합하며, 네트워크, 호스트 및 애플리케이션을 보호하는 것을 목표로 한다. 애플리케이션 보안을 위한 접근 방식에는 설계 검토, 코드 검토, 블랙박스 테스트, 자동화된 도구 활용, 버그 바운티 프로그램 등이 있으며, 이러한 방법들은 애플리케이션의 취약점을 탐지하고, 소프트웨어 개발 수명 주기의 다양한 단계에서 효과적으로 적용될 수 있다. OWASP는 애플리케이션 보안과 관련된 위협, 공격, 취약점 및 대책에 대한 정보를 제공하며, 모바일 애플리케이션 보안을 위한 전략과 보안 테스트 기법도 존재한다. 또한, 사베인스-옥슬리법(SOX), ISO/IEC 27001 등 다양한 보안 표준 및 규제가 존재하며, CERT 보안 코딩 표준과 OWASP ASVS와 같은 국제 표준도 애플리케이션 보안을 강화하는 데 기여한다.

더 읽어볼만한 페이지

  • 모바일 보안 - 삼성 녹스
    삼성 녹스는 삼성전자의 모바일 보안 플랫폼으로, 개인 및 업무용 데이터를 분리하여 보호하는 컨테이너 기술과 다양한 보안 기능을 통해 기기 보호 및 기업의 모바일 기기 관리를 지원한다.
  • 모바일 보안 - 신뢰 실행 환경
    신뢰 실행 환경(TEE)은 하드웨어와 소프트웨어의 조합으로 메인 운영 체제와 격리된 보안 영역을 제공하여 신뢰성 있는 실행을 보장하는 기술이며, 원격 증명을 통해 신뢰성을 검증하고 다양한 분야에 활용된다.
  • 데이터 보안 - 정보 보안
    정보 보안은 정보의 기밀성, 무결성, 가용성을 보장하고 허가되지 않은 접근으로부터 정보와 정보 시스템을 보호하며, 심층 방어 전략, 리스크 관리, 암호학, 표준 준수 등을 통해 정보 자산을 보호하는 활동이다.
  • 데이터 보안 - 백업
    백업은 데이터 손실 위험에 대비하여 자료를 다른 저장 장치에 복사하는 작업으로, 전체 백업, 증분 백업, 차등 백업 등의 방식을 사용하며, 효과적인 시스템 구축을 위해서는 복구 시점 및 시간 목표, 데이터 보안 등을 고려해야 한다.
애플리케이션 보안
개요
정의애플리케이션 보안(AppSec)은 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 애플리케이션을 더욱 안전하게 만들기 위해 취해지는 조치
상세 내용
목표개발 단계에서 보안 취약점을 예방, 발견 및 수정
보안 요구 사항을 충족하는 소프트웨어 개발
관련 활동보안 요구 사항 정의
보안 설계
보안 코딩
보안 테스트
관련 기술
정적 분석소스 코드를 실행하지 않고 분석하여 잠재적인 보안 결함 식별
동적 분석애플리케이션을 실행하는 동안 분석하여 런타임 오류 및 취약점 탐지
침투 테스트실제 공격과 유사한 방식으로 애플리케이션의 보안을 테스트
퍼즈 테스트유효하지 않거나 예기치 않은 데이터를 입력하여 애플리케이션의 오류 처리 능력 및 보안 취약점 평가
참고 자료
참고 자료AppSec이란 무엇인가?
웹 애플리케이션 보안 개요
웹 애플리케이션 보안 개발 모델에 대한 체계적인 검토

2. 방법론

patterns & practices ''Improving Web Application Security'' 책에 의하면, 애플리케이션 보안을 위한 원칙에 기반한 접근은 아래와 같다.


다양한 접근 방식은 애플리케이션에 숨어 있는 보안 취약점의 서로 다른 하위 집합을 찾을 수 있으며, 소프트웨어 수명 주기의 서로 다른 시점에서 가장 효과적이다. 각 접근 방식은 시간, 노력, 비용 및 발견된 취약점 간의 서로 다른 균형을 나타낸다.

  • 설계 검토. 코드를 작성하기 전에 애플리케이션의 아키텍처와 설계를 검토하여 보안 문제를 확인할 수 있다. 이 단계에서 일반적인 기술은 위협 모델을 만드는 것이다.
  • 화이트박스 보안 검토 또는 코드 검토. 이는 보안 엔지니어가 소스 코드를 수동으로 검토하고 보안 결함을 발견하여 애플리케이션을 깊이 이해하는 것이다. 애플리케이션을 이해함으로써 애플리케이션 고유의 취약점을 찾을 수 있다.
  • 블랙박스 정보 보안 감사. 이는 보안 취약점을 테스트하는 애플리케이션의 사용을 통해서만 가능하며, 소스 코드는 필요하지 않다.
  • 자동화된 도구. 많은 보안 도구를 개발 또는 테스트 환경에 포함시켜 자동화할 수 있다. 이러한 도구의 예로는 코드 편집기 또는 CI/CD 플랫폼에 통합된 자동화된 DAST/SAST 도구가 있다.
  • 조정된 취약성 플랫폼. 이는 많은 웹사이트와 소프트웨어 개발자가 제공하는 해커 기반 애플리케이션 보안 솔루션으로, 개인이 버그를 보고하면 인정을 받고 보상을 받을 수 있다.

2. 1. 위협 모델링

다양한 접근 방식은 애플리케이션에 숨어 있는 보안 취약점의 서로 다른 하위 집합을 찾을 수 있으며, 소프트웨어 수명 주기의 서로 다른 시점에서 가장 효과적이다. 각 접근 방식은 시간, 노력, 비용 및 발견된 취약점 간의 서로 다른 균형을 나타낸다.

  • 설계 검토 코드를 작성하기 전에 애플리케이션의 아키텍처와 설계를 검토하여 보안 문제를 확인할 수 있다. 이 단계에서 일반적인 기술은 위협 모델을 만드는 것이다.
  • 화이트박스 보안 검토 또는 코드 검토 보안 엔지니어가 소스 코드를 수동으로 검토하고 보안 결함을 발견하여 애플리케이션을 깊이 이해하는 것이다. 애플리케이션을 이해함으로써 애플리케이션 고유의 취약점을 찾을 수 있다.
  • 블랙박스 정보 보안 감사 이는 보안 취약점을 테스트하는 애플리케이션의 사용을 통해서만 가능하며, 소스 코드는 필요하지 않다.
  • 자동화된 도구 많은 보안 도구를 개발 또는 테스트 환경에 포함시켜 자동화할 수 있다. 이러한 도구의 예로는 코드 편집기 또는 CI/CD 플랫폼에 통합된 자동화된 DAST/SAST 도구가 있다.
  • 조정된 취약성 플랫폼 이는 많은 웹사이트와 소프트웨어 개발자가 제공하는 해커 기반 애플리케이션 보안 솔루션으로, 개인이 버그를 보고하면 인정을 받고 보상을 받을 수 있다.

2. 2. 설계 검토

애플리케이션에 숨어 있는 보안 취약점을 찾기 위한 다양한 접근 방식은 소프트웨어 수명 주기의 서로 다른 시점에서 가장 효과적이며, 시간, 노력, 비용 및 발견된 취약점 간의 서로 다른 균형을 나타낸다. 코드를 작성하기 전에 애플리케이션의 아키텍처와 설계를 검토하여 보안 문제를 확인할 수 있으며, 이 단계에서 일반적인 기술은 위협 모델을 만드는 것이다.

2. 3. 코드 검토 (화이트박스 테스트)

설계 검토를 통해 코드를 작성하기 전에 애플리케이션의 아키텍처와 설계를 검토하여 보안 문제를 확인할 수 있으며, 이 단계에서 일반적인 기술은 위협 모델을 만드는 것이다. 화이트박스 보안 검토 또는 코드 검토는 보안 엔지니어가 소스 코드를 수동으로 검토하고 보안 결함을 발견하여 애플리케이션을 깊이 이해하는 것이다. 애플리케이션을 이해함으로써 애플리케이션 고유의 취약점을 찾을 수 있다.

다양한 접근 방식은 애플리케이션에 숨어 있는 보안 취약점의 서로 다른 하위 집합을 찾을 수 있으며, 소프트웨어 수명 주기의 서로 다른 시점에서 가장 효과적이다. 각 접근 방식은 시간, 노력, 비용 및 발견된 취약점 간의 서로 다른 균형을 나타낸다.

2. 4. 블랙박스 테스트 (침투 테스트)

블랙박스 정보 보안 감사는 소스 코드 없이, 보안 취약점을 테스트하는 애플리케이션 사용을 통해서만 이루어진다. 다양한 접근 방식은 애플리케이션에 숨어 있는 보안 취약점의 서로 다른 하위 집합을 찾을 수 있으며, 소프트웨어 수명 주기의 서로 다른 시점에서 가장 효과적이다. 각 접근 방식은 시간, 노력, 비용 및 발견된 취약점 간의 서로 다른 균형을 나타낸다.

2. 5. 자동화 도구 활용

애플리케이션에 숨겨진 보안 취약점을 찾기 위한 다양한 접근 방식은 소프트웨어 수명 주기의 서로 다른 시점에서 효과적이며, 시간, 노력, 비용 및 발견된 취약점 간의 균형을 나타낸다.

  • 설계 검토. 코드를 작성하기 전에 애플리케이션의 아키텍처와 설계를 검토하여 보안 문제를 확인할 수 있으며, 위협 모델을 만드는 것이 일반적인 기술이다.
  • 화이트박스 보안 검토 또는 코드 검토. 보안 엔지니어가 소스 코드를 수동으로 검토하고 보안 결함을 발견하여 애플리케이션을 깊이 이해함으로써 애플리케이션 고유의 취약점을 찾을 수 있다.
  • 블랙박스 정보 보안 감사. 소스 코드 없이 애플리케이션 사용을 통해서만 보안 취약점을 테스트한다.
  • 자동화된 도구. 코드 편집기 또는 CI/CD 플랫폼에 통합된 자동화된 DAST/SAST 도구와 같이 많은 보안 도구를 개발 또는 테스트 환경에 포함시켜 자동화할 수 있다.
  • 조정된 취약성 플랫폼. 해커 기반 애플리케이션 보안 솔루션으로, 개인이 버그를 보고하면 인정 및 보상을 받을 수 있다.

2. 6. 버그 바운티 프로그램

애플리케이션에 숨겨진 보안 취약점을 찾기 위해 다양한 접근 방식이 사용되며, 각 방식은 소프트웨어 수명 주기의 서로 다른 시점에서 효과적이다. 이러한 접근 방식들은 시간, 노력, 비용, 그리고 발견되는 취약점 간의 균형을 이룬다.

  • 설계 검토: 코드 작성 전에 애플리케이션의 아키텍처와 설계를 검토하여 보안 문제를 확인한다. 위협 모델을 만드는 것이 일반적인 기술이다.
  • 화이트박스 보안 검토 또는 코드 검토: 보안 엔지니어가 소스 코드를 수동으로 검토하여 보안 결함을 찾고 애플리케이션을 깊이 이해한다. 이를 통해 애플리케이션 고유의 취약점을 찾을 수 있다.
  • 블랙박스 정보 보안 감사: 소스 코드 없이 애플리케이션 사용을 통해서만 보안 취약점을 테스트한다.
  • 자동화된 도구: 코드 편집기 또는 CI/CD 플랫폼에 통합된 자동화된 DAST/SAST 도구와 같이, 많은 보안 도구를 개발 또는 테스트 환경에 포함시켜 자동화할 수 있다.
  • 조정된 취약성 플랫폼: 많은 웹사이트와 소프트웨어 개발자가 제공하는 해커 기반 애플리케이션 보안 솔루션으로, 개인이 버그를 보고하면 인정과 보상을 받을 수 있다.

3. 위협, 공격, 취약점 및 대책

patterns & practices ''Improving Web Application Security'' 책에 의하면, 다음 용어들은 애플리케이션 보안과 관련이 있다.[13]


  • '''자산'''. 데이터베이스의 데이터 같은 값의 자원 또는 시스템 자원.
  • '''위협'''. 보안 취약점을 공격하여 자산을 습득, 손해, 파괴하는 등의 행위
  • '''보안 취약점'''. 자산에의 비인가 접근을 획득할 수 있는 위협에 사용되는 익스플로잇 같은 약점.
  • '''공격''' (또는 익스플로잇). 자산에 위해한 행위.
  • '''대책'''. 위협을 완화시키는 위협에 대한 보호 장비.


OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 무료로 공개된 자료를 제공한다. 이는 OWASP 재단이라는 비영리 단체가 주도한다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 수집한 포괄적인 데이터를 기반으로 한 최근 연구의 결과이다. 이 데이터는 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에 따르면, 가장 심각한 10가지 웹 애플리케이션 보안 위험은 다음과 같다.[5]

# 깨진 접근 통제

# 암호화 실패

# 주입

# 안전하지 않은 설계

# 보안 구성 오류

# 취약하고 오래된 구성 요소

# 식별 및 인증 실패

# 소프트웨어 및 데이터 무결성 실패

# 보안 로깅 및 모니터링 실패

# 서버 측 요청 위조 (SSRF)

3. 1. 자산

3. 2. 위협

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하며 무료로 공개된 자료를 제공한다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공한 데이터를 기반으로, 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에서는 가장 심각한 10가지 웹 애플리케이션 보안 위험을 다음과 같이 제시했다:[5]

# 깨진 접근 통제

# 암호화 실패

# 주입

# 안전하지 않은 설계

# 보안 구성 오류

# 취약하고 오래된 구성 요소

# 식별 및 인증 실패

# 소프트웨어 및 데이터 무결성 실패

# 보안 로깅 및 모니터링 실패*

# 서버 측 요청 위조 (SSRF)*

3. 3. 취약점

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하여 무료로 공개된 자료를 제공한다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공한 데이터를 기반으로 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견한 연구 결과이다.[4] OWASP Top 10 - 2021에 따르면, 가장 심각한 10가지 웹 애플리케이션 보안 위험은 다음과 같다:[5]

  • 깨진 접근 통제
  • 암호화 실패
  • 주입
  • 안전하지 않은 설계
  • 보안 구성 오류
  • 취약하고 오래된 구성 요소
  • 식별 및 인증 실패
  • 소프트웨어 및 데이터 무결성 실패
  • 보안 로깅 및 모니터링 실패
  • 서버 측 요청 위조 (SSRF)

3. 4. 공격

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하며 무료로 공개된 자료를 제공한다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 수집한 포괄적인 데이터를 기반으로 한 최근 연구의 결과로, 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에 따르면, 가장 심각한 10가지 웹 애플리케이션 보안 위험은 다음과 같다:[5]

  • 깨진 접근 통제
  • 암호화 실패
  • 주입
  • 안전하지 않은 설계
  • 보안 구성 오류
  • 취약하고 오래된 구성 요소
  • 식별 및 인증 실패
  • 소프트웨어 및 데이터 무결성 실패
  • 보안 로깅 및 모니터링 실패
  • 서버 측 요청 위조 (SSRF)

3. 5. 대책

OWASP의 [https://top10proactive.owasp.org/ OWASP 탑 10 프로액티브 컨트롤 2024]는 모든 소프트웨어 설계자와 개발자가 알고 지켜야 할 보안 기술 목록이다.

현재 목록은 다음과 같다.

  • 접근 제어 구현
  • 암호화 기술 적절하게 사용
  • 모든 입력값 검증 및 예외 처리
  • 초기 단계부터 보안 고려
  • 기본적으로 보안 설정
  • 구성 요소 안전하게 유지
  • 디지털 ID 구현
  • 브라우저 보안 기능 사용
  • 보안 로깅 및 모니터링 구현
  • 서버 측 요청 위조 방지

4. 애플리케이션 위협/공격 유형

patterns & practices ''Improving Web Application Security'' 책에 따르면 다음은 애플리케이션에 대한 위협/공격의 분류이다.[13]

범주위협 / 공격
입력 유효성버퍼 오버플로; 사이트 간 스크립팅; SQL 삽입; 정규화
소프트웨어 부당 변경공격자들은 비인가된 행위를 수행하기 위하여 애플리케이션의 런타임 행위를 수정한다. 이것은 익스플로잇이나 바이너리 패칭, 코드 대체 또는 코드 확장을 통해 가능해진다.
인증네트워크 도청 ; 무차별 대입 공격; 사전 공격; 쿠키 리플레이
인가권한 확대; 기밀 자료 폭로; 데이터 부동 변경
구성 관리관리 인터페이스에 대한 비인가된 접근; 설정 저장소에 대한 비인가된 접근; 텍스트 설정 데이터의 검색; 개개인의 의무의 부족; 과한 권한이 부여된 프로세스와 서비스 계정
민감한 정보민감한 코드나 자료에 대한 접근; 네트워크 도청; 코드/데이터 부당 변경
세션 관리세션 하이재킹; 세션 리플레이; 중간자 공격
암호화형편없는 키 생성과 키 관리
파라미터 조작쿼리 문자열 조작
예외 관리정보 공개; 서비스 거부 공격
감사와 로깅사용자가 동작의 수행을 거부한다; 공격자가 추적 없이 애플리케이션을 취약점 공격한다



OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하여 무료로 공개된 자료를 제공한다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 수집한 포괄적인 데이터를 기반으로 한 최근 연구의 결과이며, 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에 따르면, 가장 심각한 10가지 웹 애플리케이션 보안 위험은 다음과 같다:[5]


  • 깨진 접근 통제
  • 암호화 실패
  • 주입
  • 안전하지 않은 설계
  • 보안 구성 오류
  • 취약하고 오래된 구성 요소
  • 식별 및 인증 실패
  • 소프트웨어 및 데이터 무결성 실패
  • 보안 로깅 및 모니터링 실패*
  • 서버 측 요청 위조 (SSRF)*

4. 1. 입력 유효성 검증 취약점

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하여 무료로 공개된 자료를 제공한다.[4] OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공한 데이터를 기반으로 5만 개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견한 연구 결과이다.[4] OWASP Top 10 - 2021에서는 가장 심각한 10가지 웹 애플리케이션 보안 위험 중 하나로 주입을 포함한다.[5]

4. 2. 인증 및 권한 관리 취약점

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단에서 제공하는 무료 공개 자료이다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공한 데이터를 기반으로 5만 개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] 2021년 OWASP Top 10에 따르면, 식별 및 인증 실패는 웹 애플리케이션 보안 위험 중 하나이다.[5]

4. 3. 구성 관리 취약점

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단에서 제공하는 무료 공개 자료이다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직으로부터 수집된 데이터를 기반으로 하며, 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에서는 가장 심각한 10가지 웹 애플리케이션 보안 위험 중 하나로 보안 구성 오류를 포함하고 있다.[5]

4. 4. 민감한 정보 노출

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하여 무료로 공개된 자료를 제공한다.[4] OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공한 데이터를 기반으로 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4]

4. 5. 세션 관리 취약점

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하여 무료로 자료를 공개한다. OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공한 데이터를 기반으로 하며, 5만 개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에서는 가장 심각한 10가지 웹 애플리케이션 보안 위험을 제시했다.[5]

4. 6. 암호화 취약점

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 비영리 단체인 OWASP 재단이 주도하는 무료 공개 자료 제공 프로젝트이다.[4] OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 제공받은 데이터를 기반으로 5만개 이상의 애플리케이션에서 약 230만개의 취약점을 발견하였다.[4] OWASP Top 10 - 2021에 따르면, 웹 애플리케이션 보안 위험 요소중 하나는 암호화 실패이다.[5]

4. 7. 기타

OWASP(오픈 웹 애플리케이션 보안 프로젝트)는 OWASP 재단이라는 비영리 단체가 주도하여 무료로 공개된 자료를 제공한다.[4] OWASP Top 10 - 2017은 40개 이상의 파트너 조직에서 수집한 데이터를 기반으로 50,000개 이상의 애플리케이션에서 약 230만 개의 취약점을 발견했다.[4] OWASP Top 10 - 2021에 따르면, 가장 심각한 10가지 웹 애플리케이션 보안 위험은 다음과 같다:[5]

  • 깨진 접근 통제
  • 암호화 실패
  • 주입
  • 안전하지 않은 설계
  • 보안 구성 오류
  • 취약하고 오래된 구성 요소
  • 식별 및 인증 실패
  • 소프트웨어 및 데이터 무결성 실패
  • 보안 로깅 및 모니터링 실패*
  • 서버 측 요청 위조 (SSRF)*

5. 모바일 애플리케이션 보안

모바일 장치의 사용 비율은 점차 증가하고 있다. 이러한 모바일 장치의 애플리케이션 보안을 강화하는 여러 가지 전략들이 있다.[14][15]


  • 애플리케이션 화이트 리스팅
  • 전송 계층 보안 강화
  • 강력한 인증과 인가
  • 메모리 쓰기 시 데이터 암호화
  • 애플리케이션 샌드박싱
  • API 수준 당 애플리케이션 접근 허가
  • 사용자 ID와 관련된 프로세스
  • 모바일 애플리케이션과 운영체제와의 미리 정의된 상호작용
  • 특권이 필요한 접근 시 사용자의 입력 요구
  • 적절한 세션 핸들링


2017년 구글은 취약점 보상 프로그램을 확장하여 제3자가 개발하고 구글 플레이 스토어를 통해 이용할 수 있게 했다. 업계 단체들도 GSM 협회(GSM Association)와 Open Mobile Terminal Platform(OMTP)을 포함한 권장 사항을 만들었다.

5. 1. 기기 및 운영체제 보안

5. 2. 애플리케이션 보안

6. 보안 테스트

보안 테스팅 기법은 취약점이나 보안 결점을 위해 만들어졌다. 취약점들은 애플리케이션을 공격당하게 만든다. 이상적인 보안 테스팅은 전체 소프트웨어 개발 프로세스 (SDLC) 동안에 구현되는 것이다. 하지만 불행하게도 테스팅은 종종 개발의 마지막 부분에서 수행된다.

취약점 스캐너는 역사적으로 보안 컨설턴트들이 보안 테스트를 자동화하기 위해 사용되어 왔다. 그러나 이것은 실제 소스 코드 검토의 필요성을 대체할 수 없다. 실제 코드 검토는 직접 또는 자동화된 방식으로 달성될 수 있다. 인간의 뇌는 애플리케이션의 모든 경로 확인에 요구되는 데이터 흐름 분석보다는 (특히 프로그램이 큰 경우에), 결과를 거르고 보고하는 것에 더 맞는 편이다.

애플리케이션 취약점 탐지와 관련된 자동화 툴로는 모의 해킹 (Penetration Testing) 툴(종종 블랙박스 검사 툴로 범주화 된다.)과 정적 프로그램 분석 툴들이 있다.(종종 화이트박스 검사 툴로 범주화 된다.)

애플리케이션 보안 테스트 기술은 애플리케이션의 취약점이나 보안 허점을 찾기 위해 사용됩니다. 이러한 취약점은 애플리케이션이 악용될 수 있도록 만듭니다. 이상적으로는, 보안 테스트는 전체 소프트웨어 개발 수명 주기 (SDLC) 동안 구현되어, 취약점을 시기 적절하고 철저하게 해결할 수 있도록 합니다.

애플리케이션의 취약점을 식별하기 위한 다양한 종류의 자동화된 도구가 있다. 애플리케이션 취약점 식별에 사용되는 일반적인 도구 범주는 다음과 같다.


  • 정적 애플리케이션 보안 테스트 (SAST)는 애플리케이션 개발 중에 소스 코드를 분석하여 보안 취약점을 찾는다. DAST에 비해 SAST는 애플리케이션이 실행 가능한 상태가 되기 전에도 사용할 수 있다. SAST는 전체 소스 코드에 접근할 수 있으므로 화이트 박스 접근 방식이다. 이는 더 자세한 결과를 얻을 수 있지만, 수동으로 검증해야 하는 많은 오탐 결과를 초래할 수 있다.
  • 동적 애플리케이션 보안 테스트 (DAST, 종종 취약점 스캐너라고 불림)는 웹사이트를 크롤링하고 분석하여 자동으로 취약점을 감지한다. 이 방법은 확장성이 뛰어나고, 쉽게 통합되며, 빠르다. DAST 도구는 주입 결함과 같은 낮은 수준의 공격을 처리하는 데 적합하지만, 논리 또는 비즈니스 로직 결함과 같은 높은 수준의 결함을 감지하는 데는 적합하지 않다.[6] 퍼징 도구는 일반적으로 입력 테스트에 사용된다.[7]
  • 대화형 애플리케이션 보안 테스트 (IAST)는 소프트웨어 계측을 사용하여 내부에서 애플리케이션을 평가한다. 이는 SAST 및 DAST 방법의 강점을 결합하고 코드, HTTP 트래픽, 라이브러리 정보, 백엔드 연결 및 구성 정보에 대한 액세스를 제공한다.[8][9] 일부 IAST 제품은 애플리케이션을 공격해야 하지만, 다른 제품은 일반적인 품질 보증 테스트 중에 사용할 수 있다.[10][11]
  • 런타임 애플리케이션 자체 보호는 기존 애플리케이션을 강화하여 애플리케이션 런타임 내에서 침입 탐지 및 예방을 제공한다.
  • 종속성 스캐너 (소프트웨어 구성 분석이라고도 함)는 알려진 취약점이 있는 소프트웨어 구성 요소의 사용을 감지하려고 시도한다. 이러한 도구는 소스 코드 빌드 프로세스 중에 또는 주기적으로 온디맨드로 작동할 수 있다.

6. 1. 정적 애플리케이션 보안 테스트 (SAST)

애플리케이션 보안 테스트 기술은 애플리케이션의 취약점이나 보안 허점을 찾기 위해 사용된다. 이러한 취약점은 애플리케이션이 악용될 수 있도록 만든다. 이상적으로는, 보안 테스트는 전체 소프트웨어 개발 수명 주기 (SDLC) 동안 구현되어, 취약점을 시기 적절하고 철저하게 해결할 수 있도록 한다.

애플리케이션의 취약점을 식별하기 위한 다양한 종류의 자동화된 도구가 있다. 애플리케이션 취약점 식별에 사용되는 일반적인 도구 범주중 하나인 정적 애플리케이션 보안 테스트 (SAST)는 애플리케이션 개발 중에 소스 코드를 분석하여 보안 취약점을 찾는다. 동적 애플리케이션 보안 테스트(DAST)에 비해 SAST는 애플리케이션이 실행 가능한 상태가 되기 전에도 사용할 수 있다. SAST는 전체 소스 코드에 접근할 수 있으므로 화이트 박스 접근 방식이다. 이는 더 자세한 결과를 얻을 수 있지만, 수동으로 검증해야 하는 많은 오탐 결과를 초래할 수 있다.

6. 2. 동적 애플리케이션 보안 테스트 (DAST)

동적 애플리케이션 보안 테스트(DAST, Dynamic Application Security Testing, 취약점 스캐너라고도 불림)는 웹 사이트를 크롤링하고 분석하여 자동으로 취약점을 감지하는 기술이다.[6] 이 방법은 확장성이 뛰어나고, 쉽게 통합되며, 빠르다는 장점이 있다. DAST 도구는 주입 결함과 같은 낮은 수준의 공격을 처리하는 데 적합하지만, 논리 또는 비즈니스 로직 결함과 같은 높은 수준의 결함을 감지하는 데는 적합하지 않다.[6] 퍼징 도구는 일반적으로 입력 테스트에 사용된다.[7]

6. 3. 상호작용형 애플리케이션 보안 테스트 (IAST)

정적 애플리케이션 보안 테스트 (SAST) 및 동적 애플리케이션 보안 테스트 (DAST) 방법의 강점을 결합한 대화형 애플리케이션 보안 테스트 (IAST)는 소프트웨어 계측을 사용하여 내부에서 애플리케이션을 평가한다.[8][9] IAST는 코드, HTTP 트래픽, 라이브러리 정보, 백엔드 연결 및 구성 정보에 대한 접근을 제공한다.[8][9] 일부 IAST 제품은 애플리케이션을 공격해야 하지만, 다른 제품은 일반적인 품질 보증 테스트 중에 사용할 수 있다.[10][11]

6. 4. 런타임 애플리케이션 자가 보호 (RASP)

런타임 애플리케이션 자체 보호는 기존 애플리케이션을 강화하여 애플리케이션 런타임 내에서 침입 탐지 및 예방을 제공한다.[6]

7. 보안 표준 및 규제


  • 사베인스 옥슬리법 (SOX)
  • Health Insurance Portability and Accountability Act (HIPAA)
  • IEEE P1074
  • ISO/IEC 7064:2003 ''Information technology -- Security techniques -- Check character systems''영어
  • ISO/IEC 9796-2:2002 ''Information technology -- Security techniques -- Digital signature schemes giving message recovery -- Part 2: Integer factorization based mechanisms''영어
  • ISO/IEC 9796-3:2006 ''Information technology -- Security techniques -- Digital signature schemes giving message recovery -- Part 3: Discrete logarithm based mechanisms''영어
  • ISO/IEC 9797-1:1999 ''Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher''영어
  • ISO/IEC 9797-2:2002 ''Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 2: Mechanisms using a dedicated hash-function''영어
  • ISO/IEC 9798-1:1997 ''Information technology -- Security techniques -- Entity authentication -- Part 1: General''영어
  • ISO/IEC 9798-2:1999 ''Information technology -- Security techniques -- Entity authentication -- Part 2: Mechanisms using symmetric encipherment algorithms''영어
  • ISO/IEC 9798-3:1998 ''Information technology -- Security techniques -- Entity authentication -- Part 3: Mechanisms using digital signature techniques''영어
  • ISO/IEC 9798-4:1999 ''Information technology -- Security techniques -- Entity authentication -- Part 4: Mechanisms using a cryptographic check function''영어
  • ISO/IEC 9798-5:2004 ''Information technology -- Security techniques -- Entity authentication -- Part 5: Mechanisms using zero-knowledge techniques''영어
  • ISO/IEC 9798-6:2005 ''Information technology -- Security techniques -- Entity authentication -- Part 6: Mechanisms using manual data transfer''영어
  • ISO/IEC 14888-1:1998 ''Information technology -- Security techniques -- Digital signatures with appendix -- Part 1: General''영어
  • ISO/IEC 14888-2:1999 ''Information technology -- Security techniques -- Digital signatures with appendix -- Part 2: Identity-based mechanisms''영어
  • ISO/IEC 14888-3:2006 ''Information technology -- Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms''영어
  • ISO/IEC 27001:2005 and ISO/IEC 27001:2013 ''Information technology -- Security techniques -- Information security management systems -- Requirements''영어
  • ISO/IEC 27002:2005 ''Information technology -- Security techniques -- Code of practice for information security management''영어
  • ISO/IEC 24762:2008 ''Information technology -- Security techniques -- Guidelines for information and communications technology disaster recovery services''영어 - '''현재 철회됨'''
  • ISO/IEC 27006:2007 ''Information technology -- Security techniques -- Requirements for bodies providing audit and certification of information security management systems''영어
  • ISO/IEC 27031:2011 ''Information technology -- Security techniques -- Guidelines for ICT readiness for Business Continuity''영어
  • ISO/IEC 27034-1:2011 ''Information technology — Security techniques — Application security -- Part 1: Overview and concepts''영어
  • ISO/IEC TR 24772:2013 ''Information technology — Programming languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use''영어
  • Gramm-Leach-Bliley Act
  • PCI Data Security Standarded (PCI DSS)
  • CERT 보안 코딩 표준
  • ISO/IEC 27034-1:2011 ''정보기술 — 보안 기술 — 애플리케이션 보안 -- 파트 1: 개요 및 개념''
  • ISO/IEC TR 24772:2013 ''정보기술 — 프로그래밍 언어 — 언어 선택 및 사용을 통한 프로그래밍 언어의 취약성 회피 지침''
  • NIST 특별 간행물 800-53
  • OWASP ASVS: 웹 애플리케이션 보안 검증 표준[12]

7. 1. 국제 표준

CERT 보안 코딩 표준은 안전한 코딩 관행을 장려한다. ISO/IEC 27034-1:2011은 정보 기술, 보안 기술, 애플리케이션 보안에 대한 개요 및 개념을 제공한다. ISO/IEC TR 24772:2013은 프로그래밍 언어 선택 및 사용을 통해 취약성을 피하는 지침을 제공한다. NIST 특별 간행물 800-53은 연방 정보 시스템 및 조직을 위한 보안 및 개인 정보 보호 통제에 대한 지침을 제공한다. OWASP ASVS는 웹 애플리케이션 보안 검증 표준이다.

7. 2. 국내 법규 및 규제

국내법은 아니지만, 국제적으로 널리 사용되는 표준은 다음과 같다.[12]

  • CERT 보안 코딩 표준
  • ISO/IEC 27034-1:2011 ''정보기술 — 보안 기술 — 애플리케이션 보안 -- 파트 1: 개요 및 개념''
  • ISO/IEC TR 24772:2013 ''정보기술 — 프로그래밍 언어 — 언어 선택 및 사용을 통한 프로그래밍 언어의 취약성 회피 지침''
  • NIST 특별 간행물 800-53
  • OWASP ASVS: 웹 애플리케이션 보안 검증 표준[12]

7. 3. 기타


  • CERT 보안 코딩 표준[12]
  • ISO/IEC 27034-1:2011 ''정보기술 — 보안 기술 — 애플리케이션 보안 -- 파트 1: 개요 및 개념''
  • ISO/IEC TR 24772:2013 ''정보기술 — 프로그래밍 언어 — 언어 선택 및 사용을 통한 프로그래밍 언어의 취약성 회피 지침''
  • NIST 특별 간행물 800-53
  • OWASP ASVS: 웹 애플리케이션 보안 검증 표준[12]

8. 더불어민주당의 정보보호 정책 기조 (참고)

참조

[1] 웹사이트 What is AppSec anyways? https://snikt.net/bl[...] 2021-06-03
[2] 웹사이트 Web Application Security Overview https://msdn.microso[...] 2015-10-23
[3] 논문 Systematic review of web application security development model 2013-01-17
[4] 논문 Latest OWASP Top 10 looks at APIs, web apps: The new OWASP Top 10 list is out, and while most of it remains the same, there are new additions focusing on web applications and APIs 2017-04-27
[5] 웹사이트 OWASP Top 10 - 2021: The Ten Most Critical Web Application Security Risks https://owasp.org/To[...] 2022-01-11
[6] 뉴스 Web Application Vulnerability Scanners http://samate.nist.g[...] NIST
[7] 뉴스 Fuzzing https://owasp.org/ww[...] OWASP
[8] 웹사이트 I Understand SAST and DAST But What is an IAST and Why Does it Matter? https://www.contrast[...] Contrast Security 2018-04-10
[9] 웹사이트 What is IAST? All About Interactive Application Security Testing https://hdivsecurity[...] Hdiv Security 2020-05-07
[10] 웹사이트 Introduction to Interactive Application Security Testing http://www.quotium.c[...] Quotium 2018-01-25
[11] 웹사이트 IAST: A New Approach For Agile Security Testing https://blog.secodis[...] Secodis 2015-11-26
[12] 웹사이트 OWASP Application Security Verification Standard https://owasp.org/ww[...]
[13] 문서 Improving Web Application Security: Threats and Countermeasures http://msdn2.microso[...] Microsoft Corporation
[14] 웹인용 Google launched a new bug bounty program to root out vulnerabilities in third-party apps on Google Play https://www.theverge[...] 2021-04-03
[15] 웹인용 OMTP - Open Mobile Terminal Platform https://www.omtp.org[...] 2021-04-03


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com