SMB의 2022년 웹 애플리케이션 보안 모범 사례

엔터프라이즈 스택 보안과 관련하여 소프트웨어 애플리케이션은 가장 약한 링크입니다. 2020년 애플리케이션 보안 현황 에서 Forrester는 외부 공격의 대부분이 소프트웨어 취약점을 악용하거나(42%) 웹 애플리케이션(35%)을 통해 발생한다고 밝혔습니다.

개발자는 애플리케이션이 더 복잡해지고 개발 일정이 단축됨에 따라 가능한 한 빨리 기능을 출시해야 한다는 압력을 받고 있습니다. 차별화되고 매력적인 애플리케이션 기능을 달성하기 위해 개발자는 점점 더 타사 라이브러리에 의존하고 있습니다.

오픈 소스 구성 요소로의 이러한 전환은 기업의 보안 관행을 더욱 복잡하게 만듭니다. 컨테이너 및 API와 같은 새로운 프레임워크는 애플리케이션 보안을 더욱 복잡하게 만듭니다.

개발자들은 새로운 기능을 지속적으로 출시해야 한다는 압력을 받고 있기 때문에 조직은 보안이 보조를 맞추지 못하는 매우 실질적인 위험에 직면해 있습니다. 애플리케이션 보안 모범 사례를 소프트웨어 개발 수명 주기에 통합하고 구현함으로써 보안을 달성할 수 있습니다.

웹 보안 테스트가 왜 중요한가요?

보안 취약성에 대한 웹 응용 프로그램 및 해당 구성을 테스트하는 것이 웹 보안 테스트의 목표입니다. 응용 프로그램 계층 공격(즉, HTTP 기반 응용 프로그램을 대상으로 함)이 주요 대상입니다.

웹 응용 프로그램에 다양한 유형의 입력을 제출하여 오류를 유발하고 예기치 않게 작동하게 하는 것이 일반적입니다. 이러한 소위 "음성 테스트"에서 시스템은 의도하지 않은 동작에 대해 검사됩니다.

웹 보안 테스트는 단순히 애플리케이션에 구현된 보안 기능(예: 인증 및 권한 부여)을 테스트하는 것이 아닙니다.

또한 다른 기능(예: 비즈니스 로직 및 입력 및 출력 검증)이 안전한 방식으로 구현되었는지 테스트해야 합니다. 웹 애플리케이션 기능에 대한 보안 액세스가 목표입니다.

애플리케이션 보안 테스트는 조직의 위험을 어떻게 줄입니까?

대부분의 웹 애플리케이션 공격

• SQL 인젝션 기법
• XSS(교차 사이트 스크립팅)
• 원격으로 명령 실행
• 경로 순회

공격 결과

• 제한된 콘텐츠
• 도용된 계정
• 악성 소프트웨어 설치
• 수익 손실
• 고객은 신뢰를 잃는다
• 평판 손상
• 뿐만 아니라 훨씬 더

오늘날의 웹 환경은 다양한 문제에 취약합니다. 애플리케이션이 어떻게 악용될 수 있는지 아는 것 외에도 공격의 잠재적 결과를 아는 것은 회사가 취약성을 선제적으로 해결하고 취약성을 정확하게 테스트하는 데 도움이 됩니다.

취약성의 근본 원인을 식별한 후 SDLC의 초기 단계에서 완화 제어를 적용할 수 있습니다. 또한 웹 응용 프로그램 보안 테스트는 이러한 공격이 알려진 관심 지점을 대상으로 하는 방식에 대한 지식을 활용할 수 있습니다.

회사의 위험을 관리하려면 취약점의 전체 심각도를 측정하는 데 사용할 수 있으므로 공격의 영향을 이해해야 합니다.

보안 테스트의 결과로 감지된 문제의 심각도를 결정하면 개선 노력의 우선 순위를 효율적이고 효과적으로 결정하는 데 도움이 될 수 있습니다. 심각한 심각도 문제부터 시작하여 영향이 덜한 문제로 이동하여 회사의 위험을 최소화합니다.

문제를 식별하기 전에 회사의 애플리케이션 라이브러리에 있는 각 애플리케이션에 대한 잠재적 영향 평가는 애플리케이션 보안 테스트의 우선 순위를 정하는 데 도움이 될 수 있습니다.

웹 보안 테스트에 주요 애플리케이션 목록이 설정되어 있으면 귀사의 중요 애플리케이션을 먼저 대상으로 테스트를 예약하여 비즈니스에 대한 위험을 낮출 수 있습니다.

웹 애플리케이션 보안 테스트 중에 어떤 기능을 검토해야 합니까?

웹 응용 프로그램의 보안 테스트 중에 여러 기능을 검사해야 하지만 목록이 완전하지는 않습니다. 귀하의 조직은 각각의 부적절한 구현으로 인해 심각한 위험에 노출될 수 있습니다.

웹 애플리케이션 보안을 위한 10가지 모범 사례

다음은 조직에서 이미 구현해야 하는 상위 10가지 애플리케이션 보안 모범 사례입니다.

#1 자산 추적

가지고 있는 것이 무엇인지 모르면 보호할 수 없습니다.

특정 서버를 어떤 기능이나 앱에 사용합니까? 어떤 웹 앱에서 오픈 소스 구성 요소를 사용합니까?

자산을 추적하는 것이 중요하지 않다고 생각하십니까? 각 애플리케이션 내에서 어떤 소프트웨어가 실행되고 있는지 기억하는 것이 매우 중요합니다. Equifax에 문의하십시오. Equifax는 1억 4,500만 명이 넘는 고객의 데이터를 보호하지 못해 7억 달러의 벌금을 부과받았습니다.

오픈 소스 구성 요소인 Apache Struts가 패치되지 않은 후 신용 평가 기관의 고객 웹 포털 중 하나가 손상되었습니다. 회사는 고객 포털이 취약한 오픈 소스 구성 요소를 사용했다는 사실을 알지 못했다고 말합니다.

자산 추적을 빨리 시작할수록 나중에 겪을 골칫거리와 재난이 줄어듭니다. 조직이 개발을 확장함에 따라 이 프로세스는 Sisyphean 작업처럼 느껴질 수 있습니다.

또한 자산을 분류하여 비즈니스 기능에 중요한 자산과 덜 중요한 자산에 주목해야 합니다. 그런 다음 위협을 평가하고 나중에 수정할 수 있습니다.

#2 위협 평가 수행

보호해야 할 항목의 목록을 작성하면 직면한 위협과 이를 완화할 수 있는 방법을 식별할 수 있습니다.

해커가 어떻게 애플리케이션에 침입할 수 있습니까? 어떤 기존 보안 조치가 있습니까? 어떤 추가 도구가 필요합니까?

위협 평가의 일부로 이러한 질문과 기타 질문에 답해야 합니다.

그러나 즐길 수 있는 보안 수준에 대해서도 현실적이어야 합니다. 시스템을 아무리 안전하게 보호하더라도 여전히 해킹할 수 있습니다. 또한 팀이 시간이 지남에 따라 유지할 수 있는 측정값에 대해 정직해야 합니다.

너무 많은 것을 강요하면 보안 표준과 관행이 무시될 위험이 있습니다. 보안을 심각하게 생각하고 서두르지 마십시오.

다음 공식을 사용하여 위험을 평가하십시오.

위험 = 공격 확률 x 공격의 영향.

위험은 또한 결과의 심각성에 대한 어떤 일이 일어날 확률로 생각할 수 있습니다.

고래가 하늘에서 떨어져서 당신을 짓밟는다면 재앙이 되겠지만 일어날 것 같지 않습니다.

반면에 하이킹 중 모기에 물릴 가능성은 높지만 가려운 요철을 넘어 심각한 해를 입히지는 않을 것입니다.

#3 패치에 대한 최신 정보 유지

운영 체제에 최신 패치를 설치하시겠습니까? 타사 소프트웨어를 사용하고 있습니까? 뒤쳐져 노출될 가능성이 있습니다.

소프트웨어 보안을 보장하기 위해 수행해야 하는 가장 중요한 단계 중 하나는 상용 공급업체 또는 오픈 소스 커뮤니티에서 소프트웨어를 업데이트하는 것입니다.

취약점이 발견되어 제품 또는 프로젝트 소유자에게 책임있게 보고되면 WhiteSource Vulnerability Database와 같은 데이터베이스 및 보안 자문 사이트에 게시됩니다.

가능한 경우 수정 사항을 만들고 게시하기 전에 릴리스하여 사용자에게 소프트웨어를 보호할 수 있는 기회를 제공해야 합니다.

그러나 패치가 제공될 때 적용하지 않으면 향상된 보안의 이점을 얻을 수 없습니다.

최신 버전으로 업데이트하면 제품이 손상될까 걱정된다면 자동화된 도구가 많은 도움이 될 수 있습니다. 요일에 관계없이 애플리케이션 보안 모범 사례의 일부로 업데이트 및 패치 적용의 우선 순위를 지정해야 합니다.

#4 컨테이너 관리

최근 몇 년 동안 컨테이너는 유연성 덕분에 더 많은 조직에서 이 기술을 채택함에 따라 인기를 얻었습니다. 이 기술은 SDLC(소프트웨어 개발 수명 주기) 전반에 걸쳐 다양한 환경에서 구성 요소를 개발, 테스트 및 배포하는 프로세스를 단순화합니다.

일반적으로 컨테이너는 이점을 제공하는 보안 이점을 제공합니다. 또한 자체 OS 환경으로 인해 설계별로 세분화되어 위험 수준을 낮춥니다.

그러나 컨테이너는 격리가 해제된 브레이크아웃 공격과 같은 악용에 계속 취약합니다. 컨테이너는 또한 내부에 저장된 코드의 취약점을 포함할 수 있습니다.

CI/CD 파이프라인 보안을 위해 레지스트리를 포함하여 처음부터 끝까지 취약점을 스캔해야 합니다.

이러한 스캔 외에도 컨테이너 작업 시 애플리케이션 보안을 위한 모범 사례에는 Docker Hub를 사용하는 경우 Docker Content Trust와 같은 도구로 자체 이미지에 서명하거나 팀에서 Microsoft Azure를 사용하는 경우 Shared Access Signature와 같은 중요한 작업도 포함됩니다. .

#5 수정 작업의 우선 순위 지정

최근 몇 년 동안 점점 더 많은 수의 취약점이 발생했으며 이 추세는 조만간 둔화될 조짐을 보이지 않습니다.

결과적으로 개발자는 수정 작업에 바쁩니다. 정상적인 상태를 유지하면서 애플리케이션을 안전하게 유지하려는 팀의 경우 우선 순위가 필수적입니다.

위협 평가는 취약점의 심각도(CVSS 등급), 영향을 받는 애플리케이션의 중요도 및 기타 여러 요소를 기반으로 수행됩니다.

오픈 소스 취약점과 관련하여 오픈 소스 취약점이 실제로 소유권 코드에 영향을 미치는지 여부를 알아야 합니다.

취약한 구성 요소의 CVSS 등급이 귀하의 제품에서 호출을 수신하지 않는 경우 중요하더라도 비효과적이고 높은 위험은 아닙니다.

스마트 전략은 존재하는 요인에 따라 가장 시급한 위협의 우선 순위를 지정하고 위험도가 낮은 위협은 나중을 위해 남겨두는 전략입니다.

#6 암호화, 암호화, 암호화

OWASP Top 10에는 수년 동안 저장 및 전송 중인 데이터의 암호화가 포함되어 있어 모든 애플리케이션 보안 모범 사례 목록의 요구 사항이 되었습니다.

메시지 가로채기(Man-in-the-Middle) 공격 및 기타 형태의 침입은 트래픽을 적절하게 잠그지 못할 때 민감한 데이터를 노출시킬 수 있습니다.

예를 들어 암호와 사용자 ID를 일반 텍스트로 저장하면 고객이 위험에 처하게 됩니다.

암호화를 위한 기본 체크리스트의 일부로 업데이트된 인증서와 함께 SSL을 사용하는지 확인하십시오. HTTPS가 표준이라고 해서 뒤쳐지지 마십시오. 해싱도 권장됩니다.

또한 그들이 말하는 것처럼 "자신의 암호를 굴려"해서는 안됩니다. 업무를 제대로 수행할 수 있는 경험이 있는 전담 팀이 지원하는 보안 제품을 고려하십시오.

#7 권한 관리

조직의 모든 사람에게 모든 항목에 대한 액세스 권한을 부여할 필요는 없습니다. 네트워크 보안 모범 사례 및 응용 프로그램 보안 모범 사례를 따라 필요한 사람만 응용 프로그램과 데이터에 액세스할 수 있습니다.

여기에는 두 가지 이유가 있습니다. 가장 먼저 해야 할 일은 해커가 마케팅 자격 증명을 사용하여 재무 또는 법률과 같은 더 민감한 다른 데이터가 포함된 시스템에 액세스하는 것을 방지하는 것입니다.

랩톱을 분실하거나 이메일에 잘못된 첨부 파일을 보내는 것과 같이 의도하지 않거나 악의적인 내부자 위협도 우려됩니다.

직원에게 데이터 액세스와 관련하여 필요한 데이터만 제공하는 최소 권한 원칙은 통제가 없는 경우에 비해 노출을 줄일 수 있습니다.

#8 취약점 관리를 위한 자동화 수용

애플리케이션의 보안은 특히 취약성 관리와 같은 작업과 관련하여 지난 몇 년 동안 개발자에게 점점 더 중요해졌습니다.

보안의 좌향 이동을 해결하기 위해 개발자 팀은 초기에 자주 테스트하고 있으며, 취약성을 수정하는 것이 더 쉽고 저렴할 때 개발 프로세스 초기에 보안 검사를 최대한 많이 시행합니다.

엄청난 양의 취약점으로 인해 다루기 힘든 테스트 프로세스를 관리하기 위해 개발자는 자동화된 도구가 필요합니다.

독점 코드에서 잠재적인 보안 취약성을 찾기 위해 정적 애플리케이션 보안 테스트(SAST) 및 동적 애플리케이션 보안 테스트(DAST)를 개발 중에 사용할 수 있습니다.

보안 허점은 SAST 및 DAST로 해결되지만 독점 코드는 전체 코드에서 상대적으로 작은 부분을 차지합니다.

모든 최신 애플리케이션의 92% 이상에서 오픈 소스 구성 요소가 코드베이스의 60-80%를 구성합니다. 애플리케이션 보안 체크리스트는 오픈 소스 구성 요소의 보안을 우선시해야 합니다.

팀은 소프트웨어 구성 분석 도구를 사용하여 SDLC 전체에서 자동화된 보안 검사 및 보고서를 실행하여 환경의 각 오픈 소스 구성 요소를 식별하고 애플리케이션에 보안 위험을 제기하는 알려진 취약점이 있는 구성 요소를 표시할 수 있습니다.

오픈 소스 보안 문제에 대한 자동화된 테스트를 왼쪽으로 이동하여 취약성을 더 잘 관리할 수 있습니다.

#9 침투 테스트

자동화된 도구가 대부분의 보안 문제를 파악하는 데 도움이 되더라도 최고의 애플리케이션 보안 모범 사례 목록은 펜 테스트를 언급하지 않고는 불완전합니다.

펜과 종이로 테스트하면 앱을 찔러서 약점을 찾을 수 있습니다. 결단력 있는 해커가 애플리케이션에 침입하려고 시도하는 경우 우수한 펜 테스터는 어떤 조치를 취해야 하는지 정확히 알고 있습니다.

해킹 회사를 고용하거나 프리랜서가 BugCrowd 및 HackerOne과 같은 버그 현상금 프로그램에 참여할 수 있습니다. 아직 지원하지 않았다면 회사에서 버그 포상금을 후원해야 합니다.

펜 테스터를 고용하는 경우 실제 위반의 결과를 처리하는 것보다 비용을 지불하는 것이 훨씬 낫습니다.

#10 토큰 조심

이것이 보안하기 쉽다는 사실에도 불구하고 많은 개발자들이 제3자를 위해 토큰을 적절하게 보호하지 않습니다.

인기 있는 개발자 웹사이트를 검색하면 온라인에서 보안되지 않은 토큰을 쉽게 찾을 수 있습니다. 개발자는 토큰 세부 정보를 다른 곳에 저장하는 대신 오픈 소스 리포지토리에 포함하기만 하면 됩니다.

기본적인 애플리케이션 보안 모범 사례는 타사 토큰을 적절하게 보호하는 것입니다. 다른 사람이 가져갈 수 있도록 구매한 토큰을 코드에 남겨두어서는 안 됩니다.

기본 사례로서의 애플리케이션 보안 모범 사례

여기에 설명된 각 모범 사례는 조직의 지속적인 개발 프로세스에 통합되어야 합니다. 위험을 최소화하지 않으면 회사의 애플리케이션과 데이터가 위험합니다. 위험을 최소화하려면 다음 단계를 따르십시오.

다른 사람들이 저지를 가능성이 있는 실수를 피하는 것은 해커보다 앞서 나가는 한 가지 방법이므로 공격 대상이 되기가 더 어렵습니다. 완전히 해킹되지 않는 경계 또는 애플리케이션 보안 조치는 없을 것입니다.

그러나 이러한 기본 모범 사례를 따르면 응용 프로그램이 해커의 문제를 해결할 가치가 없도록 유지하는 데 큰 도움이 될 수 있습니다.