AppSec이 중요한 이유
조직에 배포된 애플리케이션은 디지털 공격 표면의 대부분을 차지합니다. 사내에서 개발했든 타사에서 개발했든 공용 애플리케이션은 민감한 정보를 훔치거나, 멀웨어를 배포하거나, 조직에 대해 다른 조치를 취하는 데 악용될 수 있습니다.
AppSec은 조직이 수명 주기 전반에 걸쳐 조직의 애플리케이션으로 인해 발생하는 위험을 관리할 수 있도록 하기 때문에 중요합니다. AppSec은 개발 모범 사례와 보안 애플리케이션 구성, 배포 및 관리를 통합하여 조직의 애플리케이션에 존재하는 취약성의 수를 줄이고 공격자가 이러한 취약성을 악용하지 못하도록 합니다.
최고의 애플리케이션 보안 모범 사례
효과적인 애플리케이션 보안 프로그램은 애플리케이션이 수명 주기 전반에 걸쳐 직면하는 잠재적 위험과 위협을 해결합니다.
일부 애플리케이션 보안 모범 사례는 다음과 같습니다.
#1. 위협 평가로 시작
애플리케이션은 다양한 위협에 취약할 수 있습니다. 애플리케이션이 노출될 수 있는 잠재적인 공격을 이해하는 것은 수정 작업의 우선 순위를 적절하게 지정하는 데 필수적입니다.
위협 평가는 조직에 대한 가장 가능성이 높은 위협, 잠재적인 영향 및 조직이 이미 보유하고 있는 보안 솔루션을 식별하는 좋은 방법입니다. 이 정보를 통해 조직은 이러한 잠재적 위험과 위협을 해결하기 위한 전략을 개발할 수 있습니다.
#2. DevSecOps 모범 사례 구현
DevSecOps 또는 Shift Security Left 운동은 소프트웨어 개발 수명 주기(SDLC) 초기에 보안을 통합하는 데 중점을 둡니다. 보안을 SDLC의 테스트 단계로 이관하는 대신 DevSecOps에는 다음이 포함됩니다.
- 보안 요구 사항 정의: SDLC의 요구 사항 단계에서 개발 팀은 애플리케이션에 포함되어야 하는 다양한 기능을 정의합니다. 여기에는 기능 및 성능 요구 사항과 함께 코드에서 완화해야 하는 보안 제어 및 잠재적 취약성을 간략하게 설명하는 보안 요구 사항도 포함되어야 합니다.
- 테스트 케이스 만들기: 개발자는 일반적으로 정의된 요구 사항에 대한 애플리케이션의 준수 여부를 평가하는 테스트 사례를 만듭니다. 보안 요구 사항이 만들어지면 팀에서는 테스트 사례를 만들어 제대로 구현되었는지 확인할 수 있습니다.
- 테스트 자동화: 가능한 경우 자동화는 DevOps 및 DevSecOps의 핵심 원칙 중 하나입니다. 보안 테스트 케이스와 정적 애플리케이션 보안 테스트(SAST), 동적 애플리케이션 보안 테스트(DAST) 및 대화형 애플리케이션 보안 테스트(IAST)와 같은 애플리케이션 보안 도구 사용을 모두 포함하여 보안 테스트를 자동화하면 마찰을 줄이고 SDLC 중에 보안 이 실제로 수행되도록 할 수 있습니다.
취약점은 프로덕션 코드에서 흔히 발생하며, 그 주된 이유 중 하나는 개발 과정에서 보안이 과소 평가되기 때문입니다. DevSecOps 원칙을 구현하면 이 문제를 해결하고 조직의 애플리케이션에 대한 위험을 줄이는 데 도움이 됩니다.
#3. 권한 관리
PAM(Privileged Access Management) 은 개발 프로세스 중에 필수적입니다. 조직의 개발 환경에 액세스할 수 있는 공격자는 잠재적으로 다음을 수행할 수 있습니다.
- 중요한 정보가 포함된 정책 및 프로세스 문서에 액세스합니다.
- 애플리케이션 코드를 변경하여 취약성, 오류 또는 악성 코드를 도입합니다.
- 테스트 케이스와 테스트 코드를 수정하여 보안 격차를 도입합니다.
- 자동화된 보안 테스트를 비활성화합니다.
- 보안 도구 설정을 수정합니다.
이러한 이벤트는 조직의 데이터 및 애플리케이션 보안에 부정적인 영향을 미칠 수 있습니다. 최소 권한 원칙에 따라 강력한 액세스 제어를 구현하고 다중 인증(MFA)을 사용하는 강력한 인증으로 지원하면 공격자가 개발 환경에 액세스할 수 있는 위험과 해당 액세스로 인해 발생할 수 있는 피해를 줄일 수 있습니다.
#4. 소프트웨어 공급망 모니터링
전부는 아니지만 대부분의 애플리케이션은 특정 기능을 구현하기 위해 외부 라이브러리와 구성 요소에 의존합니다. 코드를 처음부터 작성하면 시간이 오래 걸리고 코드의 성능과 보안성이 떨어질 수 있으므로 안전한 코드 재사용이 일반적인 개발 모범 사례입니다. 그러나 소프트웨어 공급망은 점점 더 공격의 대상이 되고 있습니다. 사이버 위협 행위자는 널리 사용되는 라이브러리의 취약성을 표적으로 삼거나 이러한 라이브러리 자체에 취약성 또는 악성 코드를 주입할 수 있습니다.
소프트웨어 공급망 관리는 강력한 애플리케이션 보안에 필수적입니다. 소프트웨어 구성 분석(SCA) 솔루션은 애플리케이션 내에서 사용되는 라이브러리 및 타사 코드를 식별하여 공급망 위험을 관리하는 데 도움이 될 수 있습니다. 개발 팀은 이 목록을 사용하여 알려진 취약성을 식별 및 수정하고 오래된 구성 요소에 업데이트를 적용할 수 있습니다.
#5. 자동화 및 AI 활용
개발 및 보안 팀은 일반적으로 광범위한 책임과 빡빡한 일정을 가지고 있습니다. 개발 과정에서 보안은 릴리스 기한을 맞추는 데 필요한 시간과 리소스가 필요하기 때문에 과소평가되는 경우가 많습니다.
인공 지능(AI) 및 보안 자동화 는 개발 프로세스에서 보안의 리소스 요구 사항을 줄이는 데 도움이 될 수 있습니다. AI는 경고 및 로그 파일을 구문 분석하여 개발자와 보안 담당자에게 문제를 알리는 동시에 오탐을 최소화하는 데 도움이 될 수 있습니다. 보안 자동화는 테스트가 실행되도록 하는 동시에 개발자가 개발자와 릴리스 일정에 미치는 영향을 최소화합니다.
#6. 문제 해결 우선 순위 지정
프로덕션 애플리케이션의 취약점 수는 많고 압도적일 수 있습니다. 대부분의 경우 조직에는 배포된 소프트웨어 내의 모든 취약성을 해결할 수 있는 리소스가 부족합니다. 그 결과, 기업은 취약성 관리에서 뒤처지고 있습니다.
적절한 우선 순위 지정은 효과적인 취약성 관리에 필수적입니다. 취약점 중 극히 일부만 악용될 수 있습니다. 훨씬 더 적은 수가 사이버 위협 행위자에 의해 적극적으로 악용될 것입니다. 활성 익스플로잇이 있는 이러한 취약성은 조직에 매우 다양한 수준의 위험을 초래할 수 있습니다.
보안 테스트 프로세스 중에 자동화된 도구를 사용하여 취약성을 식별할 뿐만 아니라 심각도와 악용 가능성을 추적해야 합니다. 필요한 경우 자동화된 분석으로 백업되는 이러한 자동화된 메트릭을 사용하여 조직에 실질적인 위협이 되는 취약성을 확인할 수 있습니다. 이를 기반으로 팀은 취약성 관리에 소요되는 시간과 리소스가 조직에 실질적인 가치와 상당한 ROI(투자 수익률)를 제공하도록 보장하는 수정 전략을 개발할 수 있습니다.
#7. AppSec 결과 추적
비즈니스가 하는 모든 일과 마찬가지로 애플리케이션 보안에는 시간과 리소스가 필요합니다. 그러나 애플리케이션 보안의 이점과 ROI는 애플리케이션 보안 성공 사례가 조직에 피해를 입히고 비용이 많이 드는 사이버 보안 사고를 초래할 수 있는 취약성을 해결하는 것이기 때문에 보기 어려울 수 있습니다.
부정적인 것을 증명하는 것은 어렵기 때문에 애플리케이션 보안 프로그램의 가치를 입증하려면 프로그램이 명확하고 측정 가능한 차이를 만드는 메트릭을 식별하고 추적해야 합니다.
이에 대한 몇 가지 예는 다음과 같습니다.
- 개발 중에 감지된 취약성 수입니다.
- Number of vulnerabilities detected in production 애플리케이션.
- 악용된 취약성으로 인한 보안 인시던트 수입니다.
- 내부 AppSec 정책 위반 수입니다.
- 기업 및 규제 컴플라이언스 요구 사항 위반 횟수.
이상적으로 AppSec 프로그램은 보안 개발 관행과 AppSec 정책이 개발 팀에 뿌리를 내리게 됨에 따라 시간이 지남에 따라 이러한 모든 메트릭이 감소합니다. 그러나 보안 사고의 일환으로 개발과 프로덕션에서 취약점이 감지되는 전환조차도 취약성이 조직에 미치는 비용과 피해를 줄이기 때문에 성공적입니다.
피드백