엔터프라이즈 스택 보안과 관련하여 소프트웨어 애플리케이션은 가장 약한 링크입니다. ~ 안에 2020년 애플리케이션 보안 현황, Forrester에 따르면 외부 공격의 대부분은 소프트웨어 취약점(42%)을 이용하거나 웹 애플리케이션(35%)을 통해 발생합니다.
애플리케이션이 더욱 복잡해지고 개발 일정이 단축됨에 따라 개발자는 가능한 한 빨리 기능을 출시해야 한다는 압력을 받고 있습니다. 차별화되고 강력한 애플리케이션 기능을 달성하기 위해 개발자는 점점 더 타사 라이브러리에 의존하고 있습니다.
오픈 소스 구성 요소로의 이러한 전환은 보안 기업의 경우 더 복잡한 관행이 있습니다. 컨테이너 및 API와 같은 새로운 프레임워크는 애플리케이션 보안을 더욱 복잡하게 만듭니다.
개발자가 지속적으로 새로운 기능을 출시해야 한다는 압력을 받으면서 조직은 보안이 보조를 맞추지 못할 위험에 직면하게 됩니다. 보안은 애플리케이션 보안 모범 사례를 소프트웨어 개발 수명 주기에 통합하고 구현함으로써 달성될 수 있습니다.
웹 보안 테스트가 왜 중요한가요?
웹 애플리케이션과 해당 구성의 보안 취약성을 테스트하는 것이 웹 보안 테스트의 목표입니다. 애플리케이션 계층 공격(즉, HTTP 기반 애플리케이션을 대상으로 함)이 주요 목표입니다.
웹 애플리케이션에 다양한 유형의 입력을 제출하여 오류를 유발하고 예상치 못한 동작을 유발하는 것이 일반적입니다. 이러한 소위 "음성 테스트"에서는 시스템이 의도하지 않은 동작을 검사합니다.
또한 중요한 점은 웹 보안 테스트 이는 단순히 애플리케이션에 구현된 보안 기능(예: 인증 및 권한 부여)을 테스트하는 것이 아닙니다.
또한 다른 기능(예: 비즈니스 로직, 입력 및 출력 유효성 검사)이 안전한 방식으로 구현되는지 테스트해야 합니다. 웹 애플리케이션 기능에 대한 보안 액세스가 목표입니다.
보안 테스트에는 어떤 유형이 있나요?
- 동적 애플리케이션 보안 테스트 (DAST). 규제 보안 평가를 준수하기 위해 이 자동화된 애플리케이션 보안 테스트는 내부적으로 위험이 낮은 애플리케이션에 이상적입니다. 수동 웹 보안 테스트와 DAST의 조합은 중간 위험 애플리케이션과 사소한 변경이 진행 중인 중요 애플리케이션에 대한 최선의 접근 방식입니다.
- 정적 애플리케이션 보안 테스트 (SAST). 애플리케이션 보안에 대한 이러한 접근 방식은 수동 및 자동으로 테스트됩니다. 애플리케이션을 프로덕션 환경에서 실행할 필요 없이 이러한 방식으로 테스트할 수 있습니다. 또한 이를 통해 개발자는 소스 코드를 스캔하여 소프트웨어 보안 취약점을 체계적으로 탐지하고 제거할 수 있습니다.
- 침투 테스트. 특히 대규모 변경이 진행 중인 애플리케이션의 경우 이 수동 애플리케이션 보안 테스트가 이상적입니다. 평가에는 고급 공격 시나리오를 식별하기 위한 비즈니스 로직과 공격자 기반 테스트가 포함됩니다.
- 런타임 애플리케이션 자체 보호(RASP). 애플리케이션 보안에 대한 이러한 진화하는 접근 방식에는 공격이 실행될 때 모니터링하고 이상적으로는 실시간으로 차단할 수 있는 방식으로 애플리케이션을 계측하기 위해 다양한 기술 기술이 사용됩니다.
애플리케이션 보안 테스트는 어떻게 조직의 위험을 줄이는가?
웹 애플리케이션 공격의 대부분
- SQL 주입 기술
- 사이트 간 스크립팅 (XSS)
- 원격으로 명령 실행
- 경로 순회
공격 결과
- 제한된 콘텐츠
- 해킹당한 계정
- 악성 소프트웨어 설치
- 수익 손실
- 고객은 신뢰를 잃습니다
- 평판 손상
- 뿐만 아니라 훨씬 더
오늘날의 웹 환경은 다양한 문제에 직면해 있습니다. 애플리케이션이 어떻게 악용될 수 있는지 아는 것 외에도 공격의 잠재적인 결과를 아는 것은 회사가 취약점을 선제적으로 해결하고 정확하게 테스트하는 데 도움이 됩니다.
취약성의 근본 원인을 식별한 후 SDLC의 초기 단계에서 완화 제어를 적용할 수 있습니다. 또한 웹 애플리케이션 보안 테스트에서는 이러한 공격이 알려진 관심 지점을 표적으로 삼는 방법에 대한 지식을 활용할 수 있습니다.
회사의 위험을 관리하려면 공격의 영향을 이해해야 합니다. 공격은 취약점의 전체 심각도를 측정하는 데 사용될 수 있기 때문입니다.
보안 테스트 결과, 감지된 문제의 심각도를 확인하면 교정 노력의 우선순위를 효율적이고 효과적으로 정하는 데 도움이 될 수 있습니다. 심각한 심각도의 문제부터 시작하여 영향력이 낮은 문제로 이동하여 회사의 위험을 최소화하십시오.
문제를 식별하기 전에 회사의 애플리케이션 라이브러리에 있는 각 애플리케이션에 대한 잠재적 영향 평가를 수행하면 애플리케이션 보안 테스트의 우선순위를 정하는 데 도움이 될 수 있습니다.
웹 보안 테스트에 주요 응용 프로그램 목록이 확립되면 회사의 중요한 응용 프로그램을 먼저 대상으로 테스트를 예약하여 비즈니스에 대한 위험을 낮출 수 있습니다.
웹 애플리케이션 보안 테스트 중에 어떤 기능을 검토해야 합니까?
웹 애플리케이션의 보안 테스트 중에 여러 기능을 검사해야 하지만 목록이 전부는 아닙니다. 각 기능을 부적절하게 구현하면 조직이 심각한 위험에 노출될 수 있습니다.
- 애플리케이션 및 서버 구성- 결함은 암호화 구성, 웹 서버 구성 등과 관련될 수 있습니다.
- 입력 유효성 검사 및 오류 처리 - SQL 주입 및 XSS(교차 사이트 스크립팅)를 포함한 가장 일반적인 주입 취약점은 잘못된 입력 및 출력 처리로 인해 발생합니다.
- 인증 및 세션 관리 - 취약점으로 인해 사용자가 가장될 수 있습니다. 강력한 자격 증명 정책도 필수적입니다.
- 권한 부여- 수직 및 수평 권한 상승을 방지하는 애플리케이션의 기능을 확인합니다.
- 비즈니스 로직- 이러한 유형의 논리는 대부분의 비즈니스 애플리케이션에 필수적입니다.
- 클라이언트 측 논리- 이러한 유형의 기능은 JavaScript가 많은 최신 웹 사이트는 물론 다른 클라이언트 측 기술(예: Silverlight, Flash, Java 애플릿)을 사용하는 웹 사이트에서도 점점 더 보편화되고 있습니다.
웹 애플리케이션 보안을 위한 상위 10가지 모범 사례
다음은 조직에서 이미 구현해야 하는 상위 XNUMX가지 애플리케이션 보안 모범 사례입니다.
#1 자산 추적
자신이 가진 것이 무엇인지 모르면 그것을 보호할 수 없습니다.
특정 서버를 어떤 기능이나 앱에 사용하시나요? 어떤 웹 앱에서 오픈 소스 구성 요소를 사용하시나요?
자산을 추적하는 것이 중요하지 않다고 생각하시나요? 각 애플리케이션 내에서 어떤 소프트웨어가 실행되고 있는지 기억하는 것이 매우 중요합니다. 700억 145만 명 이상의 고객 데이터를 보호하지 못해 XNUMX억 달러의 벌금을 부과받은 Equifax에 문의해 보세요.
오픈 소스 구성 요소인 Apache Struts가 패치되지 않은 후 신용 평가 기관의 고객 웹 포털 중 하나가 손상되었습니다. 회사는 고객 포털이 취약한 오픈 소스 구성 요소를 사용했다는 사실을 몰랐다고 말했습니다.
자산 추적을 빨리 시작할수록 나중에 겪는 어려움과 재난이 줄어듭니다. 조직이 개발을 확장함에 따라 이 프로세스는 Sisyphean 작업처럼 느껴질 수 있습니다.
또한 자산을 분류하여 비즈니스 기능에 중요한 자산과 덜 중요한 자산을 분류해야 합니다. 그런 다음 위협을 평가하고 나중에 수정할 수 있습니다.
#2 위협 평가 수행
보호해야 할 항목의 목록을 작성하면 직면한 위협과 이를 완화할 수 있는 방법을 식별할 수 있습니다.
해커는 어떻게 귀하의 애플리케이션에 침입할 수 있습니까? 기존에 어떤 보안 조치를 취하고 있나요? 어떤 추가 도구가 필요합니까?
위협 평가의 일부로 이러한 질문과 기타 질문에 답해야 합니다.
그러나 귀하가 누릴 수 있는 보안 수준에 대해서도 현실적이어야 합니다. 시스템을 아무리 안전하게 보호하더라도 여전히 해킹할 수 있습니다. 또한 팀이 시간이 지남에 따라 유지할 수 있는 측정값에 대해 솔직해야 합니다.
너무 많은 것을 강요하면 보안 표준과 관행이 무시될 위험이 있습니다. 보안을 심각하게 생각하고 서두르지 마십시오.
위험을 평가하려면 다음 공식을 사용하세요.
위험 = 공격 확률 x 공격 영향.
위험은 어떤 일이 일어날 확률과 결과의 심각성으로 생각할 수도 있습니다.
고래가 하늘에서 떨어져 당신을 짓밟는다면 재앙이 될지라도 그런 일이 일어날 가능성은 거의 없습니다.
반면, 하이킹 중 모기에 물릴 가능성은 매우 높지만 가려운 몇 번의 부딪힘을 제외하면 심각한 해를 끼칠 가능성은 없습니다.
#3 패치에 대한 최신 정보를 유지하세요
운영 체제에 최신 패치를 설치하고 계십니까? 타사 소프트웨어를 사용하고 있습니까? 당신이 뒤처지고 있다는 가능성은 당신이 노출되었다는 것을 의미합니다.
소프트웨어 보안을 보장하기 위해 취해야 할 가장 중요한 단계 중 하나는 상용 공급업체나 오픈 소스 커뮤니티에서 소프트웨어를 업데이트하는 것입니다.
취약점이 발견되어 제품 또는 프로젝트 소유자에게 책임 있게 보고되면 WhiteSource Vulnerability Database와 같은 보안 자문 사이트 및 데이터베이스에 게시됩니다.
가능하다면 수정본을 게시하기 전에 작성 및 릴리스하여 사용자에게 소프트웨어를 보호할 수 있는 기회를 제공해야 합니다.
그러나 패치가 출시되었을 때 이를 적용하지 않으면 향상된 보안 혜택을 누릴 수 없습니다.
최신 버전으로 업데이트하면 제품이 손상될까 봐 걱정되신다면, 자동화된 도구 많은 도움이 될 수 있습니다. 일주일 중 언제든지 애플리케이션 보안 모범 사례의 일부로 업데이트 및 패치 적용의 우선순위를 정해야 합니다.
#4 컨테이너 관리
최근에는 SDLC(소프트웨어 개발 수명주기) 전반에 걸쳐 다양한 환경에서 구성 요소를 개발, 테스트 및 배포하는 프로세스를 단순화하는 유연성으로 인해 더 많은 조직에서 이 기술을 채택함에 따라 컨테이너의 인기가 높아졌습니다.
컨테이너가 이점을 제공하는 보안 이점을 제공한다는 것이 일반적으로 인정됩니다. 또한, 독립형 OS 환경으로 인해 설계별로 세분화되어 위험 수준이 낮아졌습니다.
그러나 컨테이너는 격리가 깨진 브레이크아웃 공격과 같은 악용에 계속해서 취약합니다. 컨테이너에는 내부에 저장된 코드에 취약점이 포함될 수도 있습니다.
CI/CD 파이프라인 보안의 경우 레지스트리를 포함하여 처음부터 끝까지 취약점을 검색해야 합니다.
이러한 스캔 외에도 컨테이너 작업 시 애플리케이션 보안에 대한 모범 사례에는 Docker Hub를 사용하는 경우 Docker Content Trust, 팀에서 사용하는 경우 공유 액세스 서명과 같은 도구를 사용하여 자체 이미지에 서명하는 등의 중요한 작업도 포함됩니다. Microsoft Azure.
#5 해결 작업의 우선순위를 정하세요
최근 몇 년간 취약점의 수가 증가하고 있으며 이러한 추세는 조만간 둔화될 기미를 보이지 않습니다.
결과적으로 개발자들은 문제 해결에 분주합니다. 정상적인 상태를 유지하면서 애플리케이션의 보안을 유지하려는 팀의 경우 우선순위 지정이 필수적입니다.
위협 평가는 취약성의 심각도(CVSS 등급), 영향을 받는 애플리케이션의 중요성 및 기타 여러 요인을 기반으로 수행됩니다.
오픈 소스 취약점과 관련하여 오픈 소스 취약점이 실제로 독점 코드에 영향을 미치는지 여부를 알아야 합니다.
취약한 구성 요소의 CVSS 등급이 중요하더라도 제품으로부터 호출을 받지 못하는 경우 비효율적이고 위험도가 높지 않습니다.
현명한 전략은 존재하는 요인을 기반으로 가장 시급한 위협의 우선순위를 먼저 정하고 위험도가 낮은 위협은 나중에 처리하는 전략입니다.
#6 암호화, 암호화, 암호화
OWASP 상위 10개에는 수년간 저장 및 전송 중인 데이터의 암호화가 포함되어 있어 모든 애플리케이션 보안 모범 사례 목록의 요구 사항이 되었습니다.
트래픽을 적절하게 차단하지 못할 경우 중간자 공격 및 기타 형태의 침입으로 인해 민감한 데이터가 노출될 수 있습니다.
. 비밀번호 저장 예를 들어 일반 텍스트로 된 사용자 ID는 고객을 위험에 빠뜨립니다.
암호화를 위한 기본 체크리스트의 일부로 업데이트된 인증서와 함께 SSL을 사용하십시오. HTTPS가 표준이므로 이제 뒤쳐지지 마십시오. 해싱도 권장됩니다.
또한, 사람들이 말하는 것처럼 "자신만의 암호화폐를 굴리는 것"을 절대 해서는 안 됩니다. 올바른 업무 수행 경험을 갖춘 전담 팀이 지원하는 보안 제품을 고려해보세요.
#7 권한 관리
조직의 모든 사람에게 모든 것에 대한 액세스 권한을 부여할 필요는 없습니다. 애플리케이션과 데이터는 네트워크 보안 모범 사례와 애플리케이션 보안 모범 사례를 준수하여 필요한 사람만 액세스할 수 있습니다.
여기에는 두 가지 이유가 있습니다. 가장 먼저 해야 할 일은 해커가 마케팅 자격 증명을 사용하여 재무 또는 법률과 같은 더 민감한 데이터가 포함된 시스템에 액세스하는 것을 방지하는 것입니다.
노트북을 분실하거나 이메일에 잘못된 첨부 파일을 보내는 등 의도하지 않은 위협이거나 악의적인 내부자 위협도 문제가 됩니다.
직원에게 데이터 액세스에 필요한 데이터만 제공하는 최소 권한 원칙은 통제 수단이 없는 경우에 비해 노출을 줄일 수 있습니다.
#8 취약점 관리를 위한 자동화 수용
애플리케이션의 보안은 지난 몇 년 동안 특히 취약성 관리와 같은 작업과 관련하여 개발자에게 점점 더 중요해졌습니다.
보안의 왼쪽 방향 전환을 해결하기 위해 개발자 팀은 취약점을 수정하는 것이 더 쉽고 저렴할 때 개발 프로세스 초기에 최대한 많은 보안 검사를 추진하여 조기에 자주 테스트하고 있습니다.
엄청난 양의 취약점으로 인해 다루기 힘든 테스트 프로세스를 관리하려면 개발자에게는 자동화된 도구가 필요합니다.
독점 코드에서 잠재적인 보안 취약점을 찾기 위해 개발 중에 SAST(정적 애플리케이션 보안 테스트) 및 DAST(동적 애플리케이션 보안 테스트)를 사용할 수 있습니다.
보안 허점은 SAST 및 DAST로 해결되지만 독점 코드는 전체 코드에서 상대적으로 작은 부분을 차지합니다.
모든 최신 애플리케이션의 92% 이상에서 오픈 소스 구성 요소가 코드베이스의 60~80%를 차지합니다. 애플리케이션 보안 체크리스트는 오픈 소스 구성 요소 보안을 우선시해야 합니다.
소프트웨어 구성 분석 도구를 사용하면 팀은 SDLC 전반에 걸쳐 자동화된 보안 검사 및 보고서를 실행하여 해당 환경의 각 오픈 소스 구성 요소를 식별하고 애플리케이션에 보안 위험을 초래하는 알려진 취약점이 있는 구성 요소를 나타낼 수 있습니다.
오픈 소스 보안 문제에 대한 자동화된 테스트를 왼쪽으로 이동하면 취약점을 더 잘 관리할 수 있습니다.
#9 침투 테스트
자동화된 도구가 대부분의 보안 문제를 파악하는 데 도움이 되더라도 펜 테스트를 언급하지 않으면 최고의 애플리케이션 보안 모범 사례 목록이 불완전할 것입니다.
펜과 종이를 사용하여 테스트하면 앱을 찌르고 찌르며 약점을 찾을 수 있습니다. 결단력 있는 해커가 애플리케이션에 침입하려고 시도하는 경우, 훌륭한 펜 테스터는 취해야 할 단계를 정확히 알고 있습니다.
해킹 회사를 고용하거나 프리랜서가 BugCrowd 및 HackerOne과 같은 버그 현상금 프로그램에 참여할 수 있습니다. 아직 지원하지 않았다면 회사에서 버그 포상금을 후원해야 합니다.
침투 테스터를 고용하는 경우 실제 위반으로 인한 결과를 처리하는 것보다 비용을 지불하는 것이 훨씬 낫습니다.
#10 토큰에 주의하세요
이것이 보안을 유지하기 쉽다는 사실에도 불구하고 많은 개발자는 제XNUMX자를 위해 토큰을 적절하게 보호하지 않습니다.
인기 있는 개발자 웹사이트를 검색하면 온라인에서 안전하지 않은 토큰을 쉽게 찾을 수 있습니다. 개발자는 토큰 세부 정보를 다른 곳에 저장하는 대신 오픈 소스 저장소에 포함시키기만 하면 됩니다.
기본적인 애플리케이션 보안 모범 사례는 타사 토큰을 적절하게 보호하는 것입니다. 구매한 토큰을 다른 사람이 가져갈 수 있도록 코드에 남겨두어서는 안 됩니다.
기본 사례로서의 애플리케이션 보안 모범 사례
여기에 설명된 각 모범 사례는 조직의 지속적인 개발 프로세스에 통합되어야 합니다. 위험을 최소화하지 않으면 회사의 애플리케이션과 데이터가 위험에 처하게 됩니다. 위험을 최소화하려면 다음 단계를 따르십시오.
다른 사람들이 저지를 수 있는 실수를 피하는 것이 해커보다 앞서 나갈 수 있는 한 가지 방법이므로 공격 대상이 되기가 더 어렵습니다. 해킹을 완벽하게 방지할 수 있는 경계 또는 애플리케이션 보안 조치는 없습니다.
그러나 이러한 기본 모범 사례를 따르면 해커가 문제를 겪을 가치가 없는 애플리케이션을 유지하는 데 큰 도움이 될 수 있습니다.
