CASA 업데이트

2023년 3월 29일 업데이트

업계 동향 및 권장사항에 따라 2023년 1분기 앱 방어 연합(ADA) 실무 그룹은 CASA 테스트 절차를 업데이트, 간소화, 표준화하기 위해 검토 세션을 진행했습니다. 이러한 작업 세션에 따라 CASA 요구사항 및 프로세스가 다음과 같이 업데이트되었습니다.

  • CASA 요구사항이 134개에서 73개로 업데이트되었습니다 (아래 세부정보 참고).

  • CASA 평가를 통과하려면 애플리케이션이 CWE 등급과 관계없이 73개의 CASA 요구사항을 모두 통과하거나 통과해야 합니다.

  • 실습을 Tier 2로 포함하도록 등급 설명을 업데이트함

  • 각 등급의 보증 정보를 추가했습니다.

  • Tier 2 셀프 스캔 프로세스를 간소화하기 위한 소규모 업데이트

CASA 요구사항 업데이트

  • 현재 요구사항의 업데이트된 목록은 여기에서 확인하세요.

  • 다음 요구사항이 삭제되었습니다.


필수_ID

실무 그룹 의견

8.1.6

이 요구사항을 보다 실용적인 조치로 재고합니다 (예: 백업은 X시간 동안만 보관해야 함, 백업은 도난/손상이 있는지 모니터링해야 함, 백업은 프로덕션으로 다시 이동하는 기능을 확인하기 위해 정기적으로 감사되어야 함). 현재 가정은 너무 광범위하여 더 많은 정의가 필요합니다.

5.1.4

다른 테스트 사례와 중복됩니다. 매우 적은 노력으로 진행되는 테스트 사례입니다. 삭제 권장

7.3.3

다른 테스트 사례와 중복됩니다. 매우 적은 노력으로 진행되는 테스트 사례입니다. 삭제 권장

1.2.2

4.1.1 등 기타 버전의 적용 범위로 인해 삭제

2.2.4

4.3.1이 적용되는 Req를 삭제합니다.

(4.3.1 관리 인터페이스가 적절한 다중 인증(MFA)을 사용하는지 확인

(관리자 인터페이스 및 기타 내부 액세스 경로에서 피싱에 대한 명의 도용 방지를 다루는 승인되지 않은 사용 방지)

2.2.5

대부분의 CSP에서 mTLS를 지원하지 않으므로 삭제합니다. CASA 테스트를 거친 대다수 개발자는 비밀번호 기반 인증을 사용하게 됩니다.

2.4.3

작성된 표준이 구체적이지 않고 적용 가능하지 않음

2.4.5

ASVS의 V5에서 삭제된 요구사항 및 2.4.1의 권장 해싱 알고리즘이 이 요구사항을 충족할 수 없습니다.

2.7.5

서드 파티 OOB 제공업체를 분석해야 할 수 있으므로 테스트를 실행할 수 없습니다. 인증 코드는 수명이 짧기 때문에 위험이 낮습니다.

2.8.2

요구사항은 6.4.2 및 6.4.1이 적용되는 커스텀 MFA 솔루션에만 관련이 있습니다.

2.8.5

2.7.6의 적용을 받으므로 요구사항 삭제, 실패한 시도의 로깅에는 ASVS의 로깅 요구사항이 적용됩니다.

2.8.6

애플리케이션 수준의 실제 OTP는 일반적인 사용 사례가 아닙니다. 이 요구사항은 관리자 인터페이스에 필요합니다. 하지만 요구사항 4.3.1(관리 인터페이스가 무단 사용을 방지하기 위해 적절한 다중 인증(MFA)을 사용하는지 확인)은 관리 인터페이스의 MFA에 해당하며 이러한 위험을 감수합니다.

2.9.1

이 요구사항은 ASVS에 따른 실제 기기에 적용됩니다. 암호화 보안 키는 사용자가 스마트 플러그 또는 FIDO 키이며

컴퓨터에 암호화 장치를 설치합니다. 인증자는

암호화할 수 있으며, 기기 또는 소프트웨어가 안전한

저장된 암호화 키) 실제 기기 인증 위험이 MFA (물리적 또는 소프트웨어) 목적으로 4.3.1에 포함되므로 이 요구사항을 CASA 범위를 벗어나게 함

2.9.3

이 요구사항은 ASVS에 따른 실제 기기에 적용됩니다. 암호화 보안 키는 사용자가 스마트 플러그 또는 FIDO 키이며

컴퓨터에 암호화 장치를 설치합니다. 인증자는

암호화할 수 있으며, 기기 또는 소프트웨어가 안전한

저장된 암호화 키) 실제 기기 인증 위험이 MFA (물리적 또는 소프트웨어) 목적으로 4.3.1에 포함되므로 이 요구사항을 CASA 범위를 벗어나게 함

2.10.1

2.10.2의 모순

2.10.3

2.4.1이 적용됩니다 (애플리케이션의 사용자 비밀번호를 저장할 때 비밀번호 해싱 함수 중 하나가 사용되는지 확인: argon2id, scrypt, bcrypt 또는 PBKDF2). 이는 오프라인 공격 및 비밀번호 저장의 위험을 포함합니다.

2.10.4

6.4.2가 적용됩니다. 키 자료가 애플리케이션에 노출되지 않고 암호화 작업에 Vault와 같은 격리된 보안 모듈을 사용하는지 확인합니다.

3.2.3

3.4.1, 3.4.2, 3.4.3이 적용됨

3.5.1

사용자는 OAuth 제공업체를 통해 토큰을 취소할 수 있습니다.

4.3.3

관리 인터페이스 및 독점 액세스와 관련된 MFA가 Req에 적용됨

5.1.3

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

5.1.4

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

5.3.2

모든 유니코드 문자가 유효한지 지정하는 요구사항 부분에서는 테스트하기 어려울 수 있습니다. 모든 애플리케이션에 모든 유니코드 문자를 넣을 수 있을 만큼 큰 텍스트 양식이 모든 애플리케이션에 포함되는 것은 아닙니다. 또한 전체 유니코드 공간에서 특정 운영체제 및 해킹 도구에 관한 지원이 부족하여 서버에서 지원하더라도 이를 테스트할 수 없습니다. 전반적인 보안 가치가 의심스럽습니다. 원래 베타 버전에 포함되었지만 테스트 문제로 인해 삭제되었습니다.

6.2.5

6.2.4 및 6.2.3이 적용됨

6.2.6

6.2.4 및 6.2.3이 적용됨

6.3.1

6.2.4 및 6.2.3이 적용됨

6.3.3

다른 임의의 숫자 생성 요구사항이 적용됩니다.

7.1.2

7.1.1이 적용됨

7.1.3

7.1.1이 적용됨

7.3.1

7.1.1이 적용됨

7.3.3

7.1.1이 적용됨

8.1.3

허용되는 매개변수나 필수 매개변수를 설명하기는 어렵습니다. 테스트 가능한 케이스가 아닙니다. 무엇이 필요한가요? 예외가 유효한지 어떻게 판단하나요? CASA의 지원 범위 외로 간주됨

8.3.3

테스트 가능한 요구사항이 아니며 개인정보처리방침 및 서비스 약관과 관련이 있으며 애플리케이션 보안과는 관련이 없습니다. 이는 법률 및 규정 준수 검토에 해당하며 CASA 범위에 포함되지 않습니다.

8.3.6

제어는 시스템 관련 (Windows/Linux 변형) 및 기기에 따라 달라지며 대부분의 경우 애플리케이션 제어가 아닙니다.

8.3.8

1.8.1, 1.8.2, 1.1.4가 적용됨

9.2.5

애플리케이션의 로깅 정책 검토에 적용됩니다.

10.1.1

아키텍처 검토에 해당하며 권장사항입니다. 요구사항은 테스트할 수 없습니다.

10.2.3

적절한 시간 내에 할 수 없습니다. 모든 이상한 코드를 문서화하고 검토해야 하지만 백도어가 없도록 특정 작업을 설정하면 심층 코드 행 검토가 필요하며 백도어가 존재하지 않을 수도 있습니다.

제대로 설계된 악성 함수를 테스트하기 어려움

10.2.4

테스트할 수 있는 방법이 없습니다. 적절한 시간 안에 할 수 없는 작업입니다. 모든 이상한 코드를 문서화하고 검토해야 하지만 백도어가 없도록 특정 작업을 설정하면 심층적인 행 코드 검토가 필요하고 백도어가 존재하지 않을 수 있습니다.

제대로 설계된 악성 함수를 테스트하기 어려움

10.2.5

테스트할 수 있는 방법이 없습니다. 적절한 시간 안에 할 수 없는 작업입니다. 모든 이상한 코드를 문서화하고 검토해야 하지만 백도어가 없도록 특정 작업을 설정하면 심층적인 행 코드 검토가 필요하고 백도어가 존재하지 않을 수 있습니다.

제대로 설계된 악성 함수를 테스트하기 어려움

13.1.1

5.2.6 및 5.3.9가 적용됩니다.

12.3.1

ASVS 및 CASA 5장 (유효성 검사, 정리 및 인코딩)의 다른 기존 요구사항이 적용되는 경로 순회 위험

12.3.3

5.2.6 및 5.3.9가 적용됩니다.

12.3.6

10.3.2 12.4.1 및 12.4.2가 적용됨

12.5.1

10.3.2 및 12.4.2가 적용됨

12.5.2

10.3.2 12.4.1 및 12.4.2가 적용됨

13.1.5

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

13.2.2

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

13.2.3

4.2.2가 적용됨

13.2.5

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

13.3.1

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

14.4.1

5.3.1이 적용됨

14.4.2

이 요구사항은 다른 입력 유효성 검사 요구사항의 적용을 받으며 유효성 검사로 인해 실제 비즈니스 로직 취약점이 발생하지 않는 경우에는 더 낮은 심각도일 수 있습니다. 예를 들어 전화번호를 제대로 검증하지 않으면 정보 페이지에 전화번호가 부적절하게 표시되는 경우 보안에 직접적인 영향이 없습니다.

14.4.3

5.2.7 및 5.3.3이 적용됨

14.4.5

6.2.1 및 9.2.1이 적용됨

14.4.7

12.4.1이 적용됨

14.5.3

14.5.2가 적용됨

2.1.5

2.1.1이 적용됨

2.1.6

2.1.1이 적용됨

2.2.3

다른 안티 자동화 제어에 의해 위험이 포함되므로 CA와 관련이 없습니다.

2.5.6

다른 비밀번호 보호가 적용됨

3.1.1

노출 위험이 낮으며 ASVS의 다른 통제 범위에 해당함

3.2.1

노출 위험이 낮으며 ASVS의 다른 통제 범위에 해당함

3.4.4

노출 위험이 낮으며 ASVS의 다른 통제 범위에 해당함

3.4.5

노출 위험이 낮으며 ASVS의 다른 통제 범위에 해당함

4.2.1

13.1.4 적용

5.2.8

다른 입력 유효성 검사 및 검사 확인

5.3.5

다른 입력 유효성 검사 및 검사 확인

7.4.1

로깅 검사가 적용됨

8.2.3

8.1.1이 적용됨

9.1.1

6.2.1 및 9.2.1이 적용됨

1.2.3

1.1.4, 1.8.4, 1.8.2가 적용됨

1.4.4

1.1.4, 1.8.4, 1.8.2가 적용됨

1.5.2

1.1.4, 1.8.4, 1.8.2가 적용됨

1.5.3

1.1.4, 1.8.4, 1.8.2가 적용됨

1.5.4

1.1.4, 1.8.4, 1.8.2가 적용됨

1.9.1

1.1.4, 1.8.4, 1.8.2가 적용됨

1.11.3

1.1.4, 1.8.4, 1.8.2가 적용됨

1.14.1

1.1.4, 1.8.4, 1.8.2가 적용됨

1.14.2

1.1.4, 1.8.4, 1.8.2가 적용됨

1.14.3

1.1.4, 1.8.4, 1.8.2가 적용됨

1.14.4

1.1.4, 1.8.4, 1.8.2가 적용됨

1.14.5

1.1.4, 1.8.4, 1.8.2가 적용됨

1.14.6

1.1.4, 1.8.4, 1.8.2가 적용됨

6.1.2

6.1.1이 적용됨

6.1.3

6.1.1이 적용됨

2.10.2

2.5.4가 적용됨

2.2.1

11.1.4가 적용됨

2.7.3

2.7.2가 적용됨

2.7.4

2.7.2가 적용됨

5.1.2

자동화 방지가 적용됨

6.2.2

승인된 암호화 알고리즘이 정의되지 않음

8.2.1

8.1.1 적용

9.1.2

9.2.1이 적용됨

9.1.3

9.2.1이 적용됨

5.5.1

1.8.2가 적용됨

14.2.1 -

1.14.6이 적용됨

3.3.4

스테이트리스(Stateless) AuthN/Z를 사용하는 애플리케이션에는 적용되지 않습니다. NCC 그룹의 삭제 권장사항에 동의하세요. 여기에는 3.3.3이 포함되어야 합니다.



  • 다음 요구사항이 추가되었습니다.


필수_ID

설명

1.1.4

모든 애플리케이션의 신뢰 경계, 구성요소, 중요한 데이터 흐름에 관한 문서와 근거를 확인합니다.

1.8.1

모든 민감한 정보가 식별되어 보호 수준으로 분류되었는지 확인

1.8.2

모든 보호 수준에 관련 보호 요구사항 세트(예: 암호화 요구사항, 무결성 요구사항, 보관, 개인 정보 보호, 기타 비밀유지 요구사항)가 있고 다음을 충족하는지 확인합니다.

살펴보겠습니다

2.1.1

사용자가 설정한 비밀번호 길이가 12자 이상인지 확인합니다.

2.5.4

공유 계정 또는 기본 계정 (예: 'root')이 없는지 확인합니다.

'admin' 또는 'sa').

4.2.1

민감한 정보 및 API가 다른 사람의 레코드 생성 또는 업데이트, 모든 사용자의 레코드 보기, 모든 레코드 삭제와 같은 레코드 생성, 읽기, 업데이트, 삭제를 대상으로 하는 안전하지 않은 직접 객체 참조 (IDOR) 공격으로부터 보호되는지 확인합니다.

1.14.6

애플리케이션이 지원되지 않거나 안전하지 않거나 지원 중단된 것을 사용하지 않는지 확인합니다.

NSAPI 플러그인, Flash, Shockwave, ActiveX와 같은 클라이언트 측 기술

Silverlight, NACL 또는 클라이언트 측 자바 애플릿입니다.