Log4j 취약점으로 인해 DevSecOps의 중요성이 강조되는 이유

2021년 12월, 전 세계의 IT 보안 팀과 개발 조직은 갑작스러운 모닝콜을 받았습니다. 연구원들은 수많은 Java 애플리케이션과 서비스에 내장되어 있는 인기 로깅 구성 요소인 Apache Log4j 유틸리티에서 심각한 보안 취약점을 발견했습니다. 이 취약점에 대한 소식에 IT 보안팀과 개발 조직은 자체 네트워크에서 취약한 버전의 Log4j를 모두 찾아내기 위해 분주하게 움직이고 있습니다.

또한 Log4j 취약점으로 인해 DevSecOps 팀은 이제 이론적이지 않은 질문에 답해야 했습니다. Log4j 또는 기타 취약점으로 인해 내부적으로 개발된 애플리케이션이 손상된 경우 보안팀은 공격을 격리하고 피해를 완화할 수 있을까요? 현재의 데브옵스 관행은 조직이 자체 코드를 통해 위협 헌팅을 신속하고 효과적으로 수행할 수 있도록 준비되어 있나요?

Log4j 취약점과 이것이 DevSecOps 팀에 미치는 영향, 그리고 취약한 소프트웨어가 수정되기 전에 공격을 받았을 때 Illumio의 제로 트러스트 세분화가 DevSecOps 팀이 위협을 완화하는 데 어떻게 도움이 되는지 간단히 살펴 보겠습니다.

Log4j 취약점과 이것이 중요한 이유

이 취약점이 주목을 받는 이유는 Log4j가 Java 애플리케이션에 널리 사용되는 명명 및 조회 API인 JNDI(Java 명명 및 디렉토리 인터페이스)를 사용하는 것과 관련이 있습니다. 초기 버전의 Log4j는 기본적으로 JNDI의 메시지 조회 대체 기능을 활성화했습니다. 공격자는 이 기능을 사용하여 신중하게 구성된 메시지를 애플리케이션에 전송하여 애플리케이션이 공격자의 통제 하에 있는 LDAP 서버 또는 기타 엔드포인트에서 로드된 코드를 실행하도록 할 수 있습니다. 이 코드는 애플리케이션의 네트워크에 멀웨어를 설치하거나 데이터를 유출하거나 기타 악의적인 작업을 수행할 수 있습니다.

Log4j가 널리 사용되고 있습니다. Google은 가장 중요한 Java 패키지 저장소로 널리 알려진 Maven 중앙 저장소에 있는 Java 패키지의 4%에 해당되는 것으로 추정합니다. Log4j는 웹 애플리케이션부터 백엔드 서비스, IoT 디바이스용 사용자 정의 앱에 이르기까지 모든 종류의 소프트웨어에 사용됩니다.

이 취약점이 발표되자마자 IT 보안팀은 네트워크를 샅샅이 뒤져 파일 이름과 환경 내 모든 디렉터리에서 Log4j의 존재를 나타내는 기타 징후를 찾기 시작했습니다. 데브옵스 팀도 자체 아카이브를 검색하여 자체 애플리케이션에서 Log4j를 사용할 수 있는지 찾느라 분주해졌습니다.

위험 부담이 높습니다. 사이버 범죄자들은 이미 이 취약점을 이용해 랜섬웨어 공격을 시작하고, 기업 네트워크에 코인 채굴 소프트웨어를 설치하고, 벨기에 국방부에 침투한 바 있습니다. 공격자들은 이 취약점을 노리는 새로운 형태의 멀웨어를 설계하고 있습니다. 예를 들어, 새로운 Night Sky 랜섬웨어는 VMware Horizon 소프트웨어의 Log4j 취약점을 표적으로 삼습니다.

더 큰 그림: 소스 코드 취약성과 이로 인한 위험

Log4j 취약점은 내부 개발 조직이 직면한 두 가지 큰 문제를 강조합니다. 첫째, 대부분의 조직은 DevOps 도구와 프로세스가 아무리 잘 구성되어 있더라도 애플리케이션에 사용되는 모든 구성 요소를 파악하는 데 어려움을 겪습니다. 특히 이러한 구성 요소가 라이브러리로 내장되어 있거나 다른 서비스와의 종속성을 통해 액세스되는 경우 더욱 그렇습니다.

예를 들어 Log4j의 경우, Log4j JAR 파일을 리포지토리에 두지 않고도 애플리케이션에 유틸리티를 포함할 수 있습니다. 애플리케이션에서 오픈 소스 등 모든 소프트웨어 구성 요소의 모든 버전을 찾는 것은 어렵고 시간이 많이 걸리는 작업입니다.

둘째, 애플리케이션이 취약점으로 인해 공격을 받고 있는 것이 발견되면 보안팀은 공격이 네트워크의 다른 시스템으로 확산되기 전에 즉시 공격을 격리할 수 있는 방법이 필요합니다.

민감한 데이터를 보호하고 운영의 연속성을 보장하는 것은 물론 Log4j 공격을 탐지하고 차단하는 것이 중요하지만, 이러한 목표는 분명히 중요합니다.

하지만 규정 준수 각도도 있습니다. 지난 1월,4 2022에서 미국 연방거래위원회(FTC) 는 Log4j 취약점으로 인해 소비자 기밀 데이터가 유출되도록 허용한 기업에 대해 처벌 및 벌금을 부과할 것이라고 발표했습니다.

FTC는 아파치 스트럿츠 프레임워크의 패치되지 않은 취약점으로 인해 소비자 데이터가 유출된 에퀴팩스에 대해 7억 달러의 벌금을 부과한 사례를 언급하며 "향후 Log4j 또는 이와 유사한 알려진 취약점의 결과로 소비자 데이터가 노출되지 않도록 보호하기 위한 합리적인 조치를 취하지 않는 기업을 추적하기 위해 모든 법적 권한을 사용할 계획"이라고 발표했습니다.

Log4j는 잠재적 위협의 거대한 빙산의 일각에 불과한 것으로 밝혀졌습니다. Log4j뿐만 아니라 자체 애플리케이션 또는 실행 중인 타사 애플리케이션의 모든 소프트웨어 구성 요소와 관련된 취약점을 찾아 수정하려면 기업은 소프트웨어 환경에 대한 포괄적인 가시성이 필요합니다. 데이터 유출로 이어지기 전에 이러한 취약점을 발견하지 못하면 막대한 규제 벌금이 부과되고 조직의 브랜드에 지속적인 손상을 입힐 수 있습니다.

다행히 DevSecOps가 도움이 될 수 있습니다.

소프트웨어 취약성 위협을 완화하는 데 있어 DevSecOps의 역할

데브섹옵스의 개념은 간단합니다: 소프트웨어를 개발하고 배포할 때 보안은 뒷전으로 미뤄서는 안 된다는 것입니다. 대신 보안은 설계부터 개발, 테스트, 릴리스 및 운영 관리에 이르기까지 DevOps의 모든 단계에 포함되어야 합니다. 데브섹옵스는 데브옵스 프로세스를 통해 개발 및 관리되는 소프트웨어 애플리케이션에 보안을 구축하는 관행입니다.

데브섹옵스가 Log4j 취약점과 같은 문제를 해결하는 데 어떻게 도움이 될 수 있나요?

첫째, DevSecOps 모범 사례에 따르면 개발팀은 애플리케이션을 빌드하고 관리할 때 Log4j와 같은 구성 요소의 업데이트된 버전을 사용해야 합니다.

둘째, 데브섹옵스는 개발 및 테스트 조직이 애플리케이션에 사용되는 오픈 소스 구성 요소를 포함한 모든 구성 요소의 버전을 추적할 것을 요구합니다. 이렇게 하면 IT 보안 커뮤니티에서 특정 구성 요소의 취약점을 발표하면 DevSecOps 조직은 자체 애플리케이션 중 영향을 받는 애플리케이션이 있는지 신속하게 파악할 수 있습니다.

마찬가지로 중요한 DevSecOps 모범 사례는 애플리케이션 내에 보안 제어 기능을 내장하여 불가피하게 다른 오픈 소스 라이브러리나 구성 요소가 취약한 것으로 발견될 경우 팀이 해당 취약점에 대한 제로데이 공격을 빠르고 효과적으로 차단할 수 있도록 준비할 수 있도록 하는 것입니다. 이미 방어 조치가 마련되어 있다면 취약점에 대한 패치가 며칠 또는 몇 주 후에 제공되더라도 조직은 공격을 방어하기 위해 조치를 취할 수 있습니다.

내장하기에 가장 좋은 보안 제어 중 하나는 시스템에 내장된 방화벽을 사용하여 네트워크 트래픽을 권한이 있는 사용자와 프로세스로만 제한하는 보안 정책을 시행하는 제로 트러스트 세분화 솔루션입니다. 제로 트러스트 세분화는 공격자가 사용할 수 있는 네트워크 경로를 획기적으로 줄임으로써 공격자가 처음에 침입할 수 있는 소수의 시스템에서만 공격자를 격리합니다. 제로 트러스트 세분화가 적용되면 공격자는 악성 사이트에서 코드를 다운로드하여 실행할 수 없습니다.

공격이 네트워크에서 격리되면 사이버 범죄자는 랜섬웨어를 다른 시스템으로 확산시킬 수 없습니다. 이들은 네트워크를 몰래 탐색하여 중요한 데이터를 빼내려고 할 수 없습니다. 마치 채광창을 통해 들어왔다가 곰 덫에 걸린 불운한 도둑처럼 제자리에 갇혀 버린 것입니다. 그들은 들어왔지만 아무데도 가지 않습니다. 그리고 알람이 울렸습니다.

일루미오가 제공하는 가시성 및 자동화 DevSecOps 팀에 필요한 기능

일루미오 제로 트러스트 세분화는 개발팀이 복잡한 네트워크 또는 보안 관행을 배울 필요 없이 애플리케이션에 엄격한 보안 제어 기능을 쉽게 내장할 수 있기 때문에 모든 DevSecOps 조직에 유용한 보안 솔루션입니다.

Illumio는 개발자와 보안 팀이 제로 트러스트 세분화 정책을 쉽게 정의할 수 있도록 지원하여 애플리케이션을 보호합니다. 일단 정책이 생성되면 조직은 조직의 애플리케이션이 실행되는 시스템에 이미 구축된 호스트 기반 방화벽과 함께 Illumio의 가상 시행 노드 (VEN)를 사용하여 이러한 정책을 쉽게 시행할 수 있습니다. 일루미오 벤은 소프트웨어 빌드에 쉽게 포함할 수 있는 경량의 장애 방지 클라이언트입니다. 광범위한 디자인 변경이 필요하지 않습니다.

Illumio 솔루션은 방화벽을 사용하지만 개발자가 복잡한 방화벽 규칙을 프로그래밍해야 하는 번거로움을 덜어줍니다. 대신 개발자와 보안팀이 적용하려는 정책을 정의하여 필요한 트래픽만 애플리케이션을 통과하도록 허용한 다음, 해당 정책을 애플리케이션에 내장된 VEN으로 푸시하여 적용할 수 있습니다.

DevSecOps 조직은 다양한 애플리케이션과 환경에 맞게 정책을 미세 조정할 수 있습니다. 특히 다음을 기반으로 정책을 정의할 수 있습니다:

• 애플리케이션 내 역할
• 애플리케이션 자체
• 개발, 테스트 또는 프로덕션과 같이 애플리케이션이 실행되는 환경
• 환경의 위치: 예: 미국 서부 해안 데이터 센터의 프로덕션 환경

그런 다음 DevSecOps 팀은 소프트웨어 빌드에 Illumio VEN을 추가하기만 하면 됩니다. 애플리케이션 환경에서 실행되면 VEN은 제로 트러스트 정책을 적용하고, 의심스러운 측면 이동이 감지되면 경고를 발생시키며, 활성 공격에 대응하여 트래픽을 차단하여 감염된 엔드포인트를 나머지 네트워크에서 격리합니다.

Illumio는 마이크로서비스 아키텍처에서 널리 사용되는 컨테이너화된 환경에서 사용할 수 있는 C-VEN 클라이언트와 Kubelink 서비스도 제공합니다. C-VEN은 경량 일루미오 에이전트로, Kubernetes 클러스터의 각 노드에서 파드로 실행되며 노드와 그 노드에서 실행되는 모든 파드를 보호합니다. 데몬셋으로 제공되는 C-VEN은 클러스터가 발전함에 따라 확장 및 축소할 수 있습니다. Kubelink는 클러스터 내의 리소스에 대해 학습하고 PCE에 Kubernetes 컨텍스트를 제공하기 위해 Kubernetes API 서버를 모니터링하는 Illumio 서비스입니다. 패키지로 제공되며 클러스터당 하나의 복제본만 필요하므로 Illumio 컨테이너 솔루션의 확장성이 뛰어납니다.

데브섹옵스 팀은 PCE 사용자 인터페이스 또는 잘 문서화된 REST API를 통해 Illumio PCE와 상호 작용하는 두 가지 방법을 사용할 수 있습니다. DevSecOps 팀은 API를 사용하여 일루미오를 CI/CD 파이프라인에 통합하여 제로 트러스트 세분화가 DevSecOps 워크플로우의 표준이 되도록 할 수 있습니다. 또한 API를 통해 보안팀은 Illumio를 다른 보안 도구 및 워크플로와 통합할 수 있습니다.

Illumio 제품군은 엔드포인트를 포함하여 애플리케이션과 서비스가 배포되는 모든 곳에서 제로 트러스트 세분화를 제공합니다:

• 데이터 센터 일루미오 코어
• 퍼블릭, 프라이빗 또는 하이브리드 클라우드: 일루미오 클라우드시큐어
• 엔드포인트 디바이스: 일루미오 엣지

Log4j가 위험한 취약점이 발견된 마지막 소프트웨어 구성 요소는 아닙니다. DevSecOps 관행을 채택하고 Illumio를 사용하여 모든 애플리케이션에 제로 트러스트 세분화를 적용함으로써 조직은 시간이 많이 걸리는 네트워크 스캔 및 위협 헌팅 작업을 계속하는 동안 데이터, 애플리케이션, 사람을 보호할 준비를 갖출 수 있습니다.

자세히 알아보려면 여기를 클릭하세요:

• 솔루션 브리프, DevSecOps를 위한 Illumio를 확인하세요.
• 데모를 원하시면 문의하세요.