취약점 검색 및 보안 개발. 1 부

전문 활동의 일환으로 개발자, 침투 테스터 및 보안 전문가는 Vulnerability Management(VM), (Secure) SDLC와 같은 프로세스를 처리해야 합니다.
이 문구 아래에는 사용자가 다르지만 서로 얽혀 사용되는 다양한 관행 및 도구 세트가 있습니다.

기술적 진보는 인프라 및 소프트웨어의 보안을 분석하기 위해 하나의 도구가 사람을 대체할 수 있는 지점에 아직 도달하지 못했습니다.
이것이 왜 그런지, 어떤 문제에 직면해야 하는지 이해하는 것은 흥미로운 일입니다.

프로세스

취약성 관리 프로세스는 인프라 보안 및 패치 관리를 지속적으로 모니터링하도록 설계되었습니다.
보안 SDLC 프로세스("보안 개발 주기")는 개발 및 운영 중에 애플리케이션 보안을 유지하도록 설계되었습니다.

이러한 프로세스의 유사한 부분은 취약성 평가 프로세스(취약성 평가, 취약성 스캐닝)입니다.
VM 내 검색과 SDLC의 주요 차이점은 첫 번째 경우 목표는 타사 소프트웨어 또는 구성에서 알려진 취약점을 찾는 것입니다. 예를 들어 오래된 버전의 Windows 또는 SNMP의 기본 커뮤니티 문자열입니다.
두 번째 경우의 목표는 타사 구성 요소(종속성)뿐만 아니라 주로 새 제품의 코드에서 취약점을 검색하는 것입니다.

이로 인해 도구와 접근 방식의 차이가 발생합니다. 제 생각에는 응용 프로그램에서 새로운 취약점을 찾는 작업이 버전 지문, 배너 수집, 암호 무차별 대입 등으로 귀결되지 않기 때문에 훨씬 더 흥미롭습니다.
애플리케이션 취약성에 대한 고품질 자동 스캐닝에는 애플리케이션의 의미, 목적 및 특정 위협을 고려하는 알고리즘이 필요합니다.

인프라 스캐너는 종종 타이머로 교체할 수 있습니다. 에이블레오노프. 요점은 순전히 통계적으로 한 달 동안 인프라를 업데이트하지 않으면 인프라가 취약한 것으로 간주할 수 있다는 것입니다.

도구

스캐닝은 물론 보안분석까지 블랙박스나 화이트박스로 할 수 있습니다.

블랙 박스

블랙박스 스캐닝을 사용하는 경우 도구는 사용자가 작업하는 것과 동일한 인터페이스를 통해 서비스와 작업할 수 있어야 합니다.

인프라 스캐너(Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose 등)는 열린 네트워크 포트를 찾고, "배너"를 수집하고, 설치된 소프트웨어 버전을 식별하고, 이러한 버전의 취약성에 대한 정보를 위해 지식 기반을 검색합니다. 또한 기본 암호 또는 데이터에 대한 공개 액세스, 취약한 SSL 암호 등과 같은 구성 오류를 감지하려고 시도합니다.

웹 애플리케이션 스캐너(Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP 등)도 알려진 구성 요소와 해당 버전(예: CMS, 프레임워크, JS 라이브러리)을 감지할 수 있습니다. 주요 크롤링 단계는 크롤링과 퍼징입니다.
크롤링 중에 크롤러는 기존 애플리케이션 인터페이스 및 HTTP 매개변수에 대한 정보를 수집합니다. 퍼징 중에 감지된 모든 매개변수는 오류를 유발하고 취약성을 감지하기 위해 변형되거나 생성된 데이터로 대체됩니다.

이러한 애플리케이션 스캐너는 DAST 및 IAST 클래스(각각 동적 및 대화형 애플리케이션 보안 테스트)에 속합니다.

화이트 박스

화이트박스 스캐닝을 사용하면 더 많은 차이가 있습니다.
VM 프로세스의 일부로 스캐너(Vulners, Incsecurity Couch, Vuls, Tenable Nessus 등)는 종종 인증된 스캔을 수행하여 시스템에 대한 액세스 권한을 부여받습니다. 따라서 스캐너는 설치된 패키지 버전과 구성 매개변수를 네트워크 서비스 배너에서 추측하지 않고 시스템에서 직접 다운로드할 수 있습니다.
스캔이 더 정확하고 완전합니다.

애플리케이션의 화이트박스 스캐닝(CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs 등)에 대해 이야기하는 경우 일반적으로 정적 코드 분석 및 해당 SAST 클래스 도구(정적 애플리케이션 보안 테스트)의 사용에 대해 이야기합니다.

문제

스캔에 많은 문제가 있습니다! 스캐닝 및 보안 개발 프로세스 구축을 위한 서비스 제공의 일환으로, 보안 분석 업무를 수행할 때 대부분 개인적으로 처리해야 합니다.

여러 회사의 엔지니어 및 정보 보안 서비스 책임자와의 대화에서도 확인되는 3 가지 주요 문제 그룹을 골라 보겠습니다.

웹 애플리케이션 스캔 문제

1. 구현의 어려움. 스캐너는 각 애플리케이션에 맞게 배포, 구성, 사용자 지정되고 스캔을 위한 테스트 환경이 할당되고 CI/CD 프로세스에서 구현되어야 효과적입니다. 그렇지 않으면 오탐만 발행하는 쓸모없는 공식 절차가 될 것입니다.
2. 스캔 기간. 스캐너는 2019년에도 인터페이스 중복 제거 작업을 제대로 수행하지 못하고 동일한 코드가 책임을 지고 있지만 서로 다른 것으로 간주하여 며칠 동안 각각 10개의 매개변수로 천 페이지를 스캔할 수 있습니다. 동시에 개발 주기 내에서 생산에 배포하는 결정을 신속하게 내려야 합니다.
3. 좋지 않은 추천. 스캐너는 상당히 일반적인 권장 사항을 제공하며 개발자가 위험 수준을 줄이는 방법과 가장 중요한 것은 지금 수행해야 하는지 또는 아직 무섭지 않은지 여부를 개발자가 신속하게 이해하는 것이 항상 가능한 것은 아닙니다.
4. 응용 프로그램에 대한 파괴적인 영향. 스캐너는 애플리케이션에 대해 DoS 공격을 쉽게 수행할 수 있으며, 많은 수의 엔터티를 생성하거나 기존 엔터티를 변경할 수도 있으므로(예: 블로그에 수만 개의 댓글 생성) 제품.
5. 취약성 탐지 품질이 낮습니다. 스캐너는 일반적으로 고정된 페이로드 배열을 사용하며 알려진 애플리케이션 동작에 적합하지 않은 취약성을 쉽게 놓칠 수 있습니다.
6. 스캐너가 응용 프로그램의 기능을 이해하지 못합니다. 스캐너 자체는 "인터넷 은행", "결제", "댓글"이 무엇인지 모릅니다. 그들에게는 링크와 매개변수만 있으므로 가능한 비즈니스 로직 취약성의 거대한 계층이 완전히 밝혀진 상태로 남아 있으며, 이중 기록을 추측하거나 ID로 다른 사람의 데이터를 엿보거나 반올림을 통해 잔액을 감을 수 없습니다.
7. 스캐너에 의한 페이지 의미론의 오해. 스캐너는 FAQ를 읽을 수 없고 보안 문자를 인식할 수 없으며 등록 후 다시 로그인하는 방법, "로그아웃"을 클릭할 수 없는 방법, 매개 변수 값을 변경할 때 요청에 서명하는 방법을 스스로 추측하지 않습니다. 결과적으로 대부분의 응용 프로그램은 스캔되지 않은 상태로 남아 있을 수 있습니다.

소스 코드 스캔 문제

1. 오탐지. 정적 분석은 많은 타협이 수반되는 복잡한 작업입니다. 정확도를 희생해야 하는 경우가 많으며 값비싼 기업용 스캐너도 엄청난 양의 오탐지를 제공합니다.
2. 구현의 어려움. 정적 분석의 정확성과 완성도를 높이려면 스캐닝 규칙을 세분화해야 하며 이러한 규칙을 작성하는 데 너무 많은 시간이 소요될 수 있습니다. 때로는 버그가 있는 코드의 모든 위치를 찾아 수정하는 것이 이러한 경우를 감지하는 규칙을 작성하는 것보다 더 쉽습니다.
3. 종속성 지원 부족. 대규모 프로젝트는 프로그래밍 언어의 기능을 확장하는 수많은 라이브러리 및 프레임워크에 의존합니다. 스캐너 지식 기반의 이러한 프레임워크에 위험한 위치("싱크")에 대한 정보가 없으면 사각지대가 되고 스캐너는 코드를 이해하지 못할 것입니다.
4. 스캔 기간. 코드에서 취약점을 찾는 것은 알고리즘 측면에서도 어려운 작업입니다. 따라서 프로세스가 지연되고 상당한 컴퓨팅 리소스가 필요할 수 있습니다.
5. 적용 범위가 낮습니다. 리소스 소비 및 스캔 시간에도 불구하고 SAST 도구 개발자는 여전히 절충에 의지하고 프로그램이 있을 수 있는 모든 상태를 분석하지 않아야 합니다.
6. 재현성 찾기. 취약점으로 연결되는 특정 라인 및 호출 스택을 가리키는 것은 훌륭하지만 실제로 스캐너는 외부 취약점을 확인하기에 충분한 정보를 제공하지 않는 경우가 많습니다. 결국 결함은 공격자가 도달할 수 없는 데드 코드에도 있을 수 있습니다.

인프라 스캔 문제

1. 인벤토리가 부족합니다. 대규모 인프라, 특히 지리적으로 분리된 인프라에서는 스캔할 호스트를 파악하는 것이 가장 어려운 경우가 많습니다. 즉, 스캔 작업은 자산 관리 작업과 밀접한 관련이 있습니다.
2. 나쁜 우선 순위. 네트워크 스캐너는 종종 실제로 악용할 수 없는 결함이 있는 많은 결과를 생성하지만 공식적으로는 위험 수준이 높습니다. 소비자가 해석하기 어려운 제보를 받고, 우선 시정해야 할 사항이 명확하지 않은 경우
3. 좋지 않은 추천. 스캐너 기술 자료에는 종종 취약점과 해결 방법에 대한 매우 일반적인 정보만 포함되어 있으므로 관리자는 Google과 함께 무장해야 합니다. 문제를 해결하기 위해 특정 명령을 실행할 수 있는 화이트박스 스캐너를 사용하면 상황이 약간 나아집니다.
4. 수공. 인프라에는 많은 노드가 있을 수 있습니다. 이는 잠재적으로 많은 결함이 있음을 의미하며 각 반복에서 수동으로 구문 분석 및 분석해야 하는 보고서입니다.
5. 잘못된 적용 범위. 인프라 검색의 품질은 취약성 및 소프트웨어 버전에 대한 기술 자료의 크기에 직접적으로 의존합니다. 여기서, 밝혀지다., 시장 리더조차도 포괄적인 지식 기반을 가지고 있지 않으며 무료 솔루션 데이터베이스에는 리더가 가지고 있지 않은 많은 정보가 있습니다.
6. 패치 문제. 대부분의 경우 인프라 취약점 패치는 패키지를 업데이트하거나 구성 파일을 변경하는 것입니다. 여기서 큰 문제는 시스템, 특히 레거시 시스템이 업데이트의 결과로 예측할 수 없게 작동할 수 있다는 것입니다. 실제로 프로덕션의 라이브 인프라에서 통합 테스트를 수행해야 합니다.

구혼

그런 일이 어떻게 될 수 있습니까?
다음 부분에서 예제와 이러한 많은 문제를 처리하는 방법에 대해 자세히 설명하지만 지금은 작업할 수 있는 주요 영역을 표시하겠습니다.

1. 다양한 스캐닝 도구의 집합. 여러 스캐너를 올바르게 사용하면 지식 기반과 탐지 품질이 크게 향상될 수 있습니다. 개별적으로 실행되는 모든 스캐너의 합계보다 훨씬 더 많은 취약점을 찾을 수 있으며 위험 수준을 더 정확하게 평가하고 더 많은 권장 사항을 만들 수 있습니다.
2. SAST 및 DAST 통합. 서로 정보를 공유함으로써 DAST 커버리지와 SAST 정확도를 높일 수 있습니다. 소스에서 기존 경로에 대한 정보를 얻을 수 있으며 DAST의 도움으로 취약점이 외부에서 보이는지 여부를 확인할 수 있습니다.
3. 기계 학습™. 2015년에 나는 말한 (그리고 더 많은) 통계를 사용하여 스캐너에 해커의 직관을 제공하고 속도를 높이는 방법에 대해 설명합니다. 이것은 미래의 자동 보안 분석 개발을 위한 확실한 음식입니다.
4. 자동 테스트 및 OpenAPI와 IAST 통합. CI/CD 파이프라인 내에서 HTTP를 통해 작동하는 HTTP 프록시 및 기능 테스트로 작동하는 도구를 기반으로 스캔 프로세스를 생성할 수 있습니다. OpenAPI/Swagger 테스트 및 계약은 데이터 흐름에 대한 누락된 정보를 스캐너에 제공하여 다양한 상태에서 애플리케이션을 스캔할 수 있도록 합니다.
5. 올바른 구성. 각 애플리케이션 및 인프라에 대해 인터페이스의 수와 특성, 사용된 기술을 고려하여 적합한 스캐닝 프로필을 생성해야 합니다.
6. 스캐너 사용자 정의. 종종 스캐너를 수정하지 않으면 애플리케이션을 스캔할 수 없습니다. 모든 요청에 ​​서명해야 하는 결제 게이트웨이를 예로 들 수 있습니다. 게이트웨이 프로토콜에 대한 커넥터를 작성하지 않으면 스캐너는 잘못된 서명이 있는 요청을 무심코 쪼아댈 것입니다. 또한 다음과 같은 특정 유형의 결함에 대한 특수 스캐너를 작성해야 합니다. 안전하지 않은 직접 개체 참조
7. 위기 관리. 다양한 스캐너를 사용하고 자산 관리 및 위협 관리와 같은 외부 시스템과의 통합을 통해 여러 매개변수를 사용하여 위험 수준을 평가할 수 있으므로 경영진은 개발 또는 인프라의 현재 보안 상태를 적절하게 파악할 수 있습니다.

계속 지켜봐 주시고 취약점 검색을 방해합시다!

출처 : habr.com