애플리케이션 보안(AppSec)이란?

애플리케이션 보안 위협: OWASP 상위 10개

소프트웨어 애플리케이션에 영향을 미치는 수많은 보안 위협이 있습니다. 그러나 OWASP(Open 웹 애플리케이션 보안 프로젝트) 상위 10개 목록에는 가장 널리 퍼져 있고 심각하며 프로덕션 환경의 애플리케이션에 영향을 줄 가능성이 가장 높은 애플리케이션 위협이 포함되어 있습니다.

AppSec 이니셔티브는 최소한 최신 애플리케이션에 대한 다음과 같은 세간의 이목을 끄는 위협에 초점을 맞춰야 합니다.

1. 삽입- 코드 삽입에는 악의적이거나 신뢰할 수 없는 데이터가 포함된 소프트웨어 애플리케이션으로 전송되는 쿼리 또는 명령이 포함됩니다. 가장 일반적인 것은 SQL 인젝션이지만 NoSQL, 운영 체제 및 LDAP 서버에도 영향을 줄 수 있습니다.
2. Broken Authentication(깨진인증) - 많은 애플리케이션에 부적절하거나 오작동하는 인증 및 권한 부여 기능이 있습니다. 이를 통해 공격자는 사용자 자격 증명을 훔치거나 적절한 자격 증명 없이 쉽게 액세스 권한을 얻을 수 있습니다.
3. 민감한 데이터 노출 - 애플리케이션 및 API는 재무 또는 결제 세부 정보, 개인 식별 정보(PII)를 포함하여 조직 또는 고객에게 속한 민감한 데이터를 공개적으로 노출할 수 있습니다.
4. XML 외부 엔터티(XXE)- 공격자는 이전 XML 파서의 취약성으로 인해 XML 문서에서 외부 엔터티 참조를 악의적으로 사용할 수 있습니다. 내부 파일에 액세스하고, 포트를 스캔하고, 코드를 원격으로 실행하는 데 사용할 수 있습니다.
5. Broken Access Control(손상된 액세스 제어) - 인증된 사용자에 대한 제한이 올바르게 구현되지 않습니다. 공격자는 이를 사용하여 권한이 없는 함수 또는 데이터에 액세스하거나, 다른 사용자의 계정에 액세스하거나, 중요한 파일을 보거나, 다른 사용자의 사용 권한을 변경할 수 있습니다.
6. Security Misconfiguration(보안 구성 오류) - 애플리케이션에 보안 기능이 있더라도 잘못 구성될 수 있습니다. 이는 일반적으로 아무도 애플리케이션의 기본 구성을 변경하지 않았기 때문에 발생합니다. 여기에는 운영 체제 및 프레임워크를 패치하지 못한 것이 포함됩니다.
7. XSS(교차 사이트 스크립팅)- 공격자가 사용자의 브라우저에서 악성 스크립트를 실행할 수 있습니다. 이는 세션을 훔치거나, 사용자를 악성 사이트로 리디렉션하거나, 웹 사이트를 훼손하는 데 사용할 수 있습니다.
8. 안전하지 않은 Deserialization- 파일에서 코드를 가져와 개체로 생성하는 방식에 오류가 있습니다. 이렇게 하면 악성 코드 실행, 권한 상승 및 권한 있는 사용자의 활동 재생이 가능할 수 있습니다.
9. 알려진 취약성이 있는 구성 요소 사용 - 여러 취약성 데이터베이스가 소프트웨어 구성 요소의 알려진 취약성을 보고합니다. 취약한 구성 요소를 사용하는 소프트웨어(해당 구성 요소 중 하나의 종속성인 경우에도)는 공격에 노출됩니다.
10. 불충분한 로깅 및 모니터링- 많은 애플리케이션에는 위반 시도를 식별하거나 기록할 수 있는 수단이 없을 수 있습니다. 이는 침해가 감지되지 않고 공격자가 추가 시스템을 손상시키기 위해 측면 이동을 수행할 수 있음을 의미할 수 있습니다.

기본 AppSec 프로세스에는 다음 단계가 포함됩니다.

1. 회사 자산 정의
2. 각 애플리케이션이 이러한 자산에 미치는 영향 확인
3. 각 애플리케이션에 대한 보안 프로파일 작성
4. 잠재적 위협 식별 및 우선순위 지정
5. 보안 인시던트 및 완화 시도 기록

애플리케이션 보안 테스트 도구

AppSec 도구 세트에는 SAST, DAST 및 IAST의 세 가지 기본 도구 범주가 있습니다.

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

SAST 도구를 사용하면 화이트박스 테스트를 수행할 수 있습니다. 애플리케이션 코드를 평가하고 스캔하여 보안 문제를 일으킬 수 있는 버그, 취약성 또는 기타 약점을 식별합니다. SAST는 컴파일된 코드, 컴파일되지 않은 코드 또는 둘 다에서 실행할 수 있습니다.

SAST 분석은 다음과 같은 문제를 식별할 수 있습니다.

• 경합 조건
• 경로 순회
• 입력 유효성 검사 누락
• 숫자 또는 데이터 형식 오류
• 안전하지 않은 참조 또는 포인터

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

DAST 도구는 블랙박스 테스트 방법을 사용하여 실행 중인 애플리케이션의 보안 문제를 테스트합니다. 실행 중인 소스 코드의 동적 분석을 수행합니다. DAST는 일반적으로 많은 수의 예기치 않은 무작위 요청으로 애플리케이션을 공격하는 퍼지 테스트를 사용합니다.

DAST는 다음과 같은 보안 취약성을 나타내는 조건을 감지할 수 있습니다.

• 보안되지 않거나 취약한 인터페이스
• 비정상적인 요청 및 응답
• JavaScript 및 Python과 같은 언어의 스크립팅 문제
• 데이터 또는 코드 삽입
• 세션 변칙
• 인증 문제

대화형 애플리케이션 보안 테스트(IAST)

IAST는 SAST와 DAST를 결합한 하이브리드 접근 방식입니다. 보안 테스트에 대한 대화형 접근 방식은 정적 분석과 동적 분석을 결합하므로 알려진 취약점을 식별하고 실행 중인 애플리케이션에서 실제로 사용되며 악용될 수 있는지 확인할 수 있습니다.

IAST 도구는 애플리케이션 실행 흐름 및 데이터 흐름에 대한 자세한 정보를 수집하고 복잡한 공격 패턴을 시뮬레이션할 수 있습니다. 실행 중인 애플리케이션의 동적 스캔을 수행할 때 애플리케이션이 응답하는 방식을 확인하고 그에 따라 테스트를 조정할 수 있습니다. 이것은 새로운 테스트 케이스를 자동으로 만드는 데 사용할 수 있습니다 (인간 침투 테스터와 유사).

이러한 접근 방식으로 인해 IAST 도구는 의심되는 보안 문제를 심층적으로 조사할 수 있으므로 오탐 수를 줄일 수 있습니다. 또한 빠른 릴리스를 통해 민첩한 개발 프로세스에 훨씬 더 자연스럽게 맞습니다.

Rule Based 웹 애플리케이션 방화벽 (WAF)

WAF는 네트워크 에지에 배포되는 솔루션으로, 네트워크 안팎으로 흐르는 트래픽을 검사하고 악성 트래픽을 식별 및 차단하려고 시도합니다.

기존의 규칙 기반 WAF는 유지 관리가 많이 필요한 도구로, 조직이 특정 트래픽 및 애플리케이션 패턴과 일치하는 규칙 집합을 꼼꼼하게 정의해야 합니다. 또한 규칙 기반 WAF는 지속적으로 변화하는 공격 벡터에 대한 적용 범위가 제한적입니다.

또한 기존 WAF는 새로운 마이크로서비스를 자동으로 보호할 수 없는데, 이는 새로운 마이크로서비스를 배포할 때마다 새로운 규칙과 정책을 정의하는 데 상당한 오버헤드가 필요하기 때문입니다. 실질적으로 이는 조직에서 배포한 새 시스템이 많은 경우 보호되지 않는다는 것을 의미합니다.

애플리케이션 Security Best Practices

다음은 조직에서 AppSec을 효과적으로 구현하는 데 사용할 수 있는 몇 가지 모범 사례입니다.

위협 평가로 시작

공격자가 애플리케이션을 침해하는 데 사용할 수 있는 주요 진입점이 무엇인지, 어떤 보안 조치가 마련되어 있는지, 적절한지 여부를 조사합니다. 각 유형의 위협에 대해 달성하려는 보안 수준에 대해 합리적인 목표와 시간 경과에 따른 이정표를 설정합니다.

시프트 시큐리티 레프트

보안 테스트는 계획 단계부터 개발, 테스트 및 배포, 프로덕션에 이르기까지 소프트웨어 개발 수명 주기(SDLC)와 완전히 통합되어야 합니다.

자동화된 도구를 사용하여 프로세스에서 가능한 한 빨리 애플리케이션을 테스트하고 CI/CD 파이프라인 전체의 여러 검사점에서 테스트하도록 합니다. 예를 들어 개발자가 코드를 커밋하고 빌드를 트리거할 때 해당 코드는 자동으로 특정 형태의 보안 테스트를 거쳐야 개발자가 코드의 보안 문제를 즉시 수정할 수 있습니다.

동일한 코드를 테스트 및 프로덕션 환경으로 승격할 때 보다 포괄적으로 다시 테스트해야 합니다.

문제 해결 우선 순위 지정

애플리케이션 보안은 애플리케이션의 취약성을 발견하는 결과를 낳으며, 모든 취약점을 해결할 수는 없습니다. 우선 순위 지정은 개발자 생산성을 저해하지 않고 중요한 취약성을 신속하게 수정하는 데 매우 중요합니다.

보안 테스트 프로세스에는 취약성 심각도 및 악용 가능성을 보여주는 자동화된 메트릭과 필요한 경우 취약성이 실제로 비즈니스 위험을 초래하는지 여부를 나타내는 수동 평가가 포함되어야 합니다. 프로덕션에서 실행되지 않는 취약한 구성 요소는 우선 순위가 아닙니다.

개발자가 세간의 이목을 끄는 실제 취약성에 대해 작업하고 있음을 알리고 SDLC에서 발생하는 모든 위치에서 문제를 해결할 시간을 갖도록 합니다.

AppSec 결과 추적

AppSec 프로그램에는 시간과 자원에 대한 막대한 투자는 물론 문화적, 조직적 변화도 필요합니다. 프로그램이 보안에 미치는 영향을 이해하여 프로그램을 정당화하고 경영진의 지원을 받는 것이 중요합니다.

AppSec의 성공을 입증하기 위해 추적 및 공유할 수 있는 중요한 지표 - 주간 또는 월간 추세를 통해 애플리케이션 보안 조치 도입의 영향을 확인할 수 있습니다.

• 내부 AppSec 정책 위반 횟수
• 컴플라이언스 위반 횟수
• 테스트 환경에서 발견된 보안 결함 수
• 생산에서 발견된 보안 결함의 수
• 보안 사고 수

권한 관리

애플리케이션 보안 프로그램과 관련된 모든 것은 공격자에게 매우 유용할 수 있는 민감한 데이터입니다. 다음을 신중하게 관리해야 합니다.

• 정책 및 프로세스 문서화
• 보안 도구에 대한 액세스
• CI/CD 및 개발 도구에 대한 액세스

최소 권한 원칙을 사용하고 각 사용자가 작업을 수행하는 데 반드시 필요한 데이터 및 시스템에만 액세스할 수 있도록 합니다. 통합 시스템 간에 제로 트러스트 원칙을 사용하여 각 시스템이 작동하는 데 필요한 최소한의 권한만 갖도록 합니다.

AppSec with 체크 포인트

체크 포인트의 CloudGuard에는 다음을 제공하는 제로 구성 애플리케이션 보안 솔루션이 포함되어 있습니다.

• 정확한 예방 – 오탐을 생성하지 않고 OWASP Top 10과 같은 정교한 공격으로부터 보호
• 제로 정책 관리 – 애플리케이션 변경 및 업데이트에 자동으로 적응
• 유연하고 빠른 배포 – 최대 48시간 내에 보호에 배포 가능

특허 출원 중인 맥락적 AI 엔진으로 구동되는 CloudGuard 애플리케이션 보안 은 완전히 자동화되어 모든 환경에 배포할 수 있습니다.