2019.10.08

데브옵스를 위한 보안 행동 분석의 효과

Andy Hawkins | InfoWorld
클라우드 네이티브 아키텍처(cloud-native architecture), 지속적 통합과 지속적 전달(Continuous Integration and Continuous Delivery, CI/CD), 데브옵스(Devops), 사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)과 같은 기술과 접근 방법은 소프트웨어 제품을 혁신하고 전달 속도를 높일 수 있게 해준다. 동시에 전통적인 소프트웨어 개발 및 유지보수 라이프사이클(SDLC)를 와해하고 기업이 애플리케이션과 비즈니스 서비스를 성공적으로 보호하기 위해 해야 할 여러 가지를 크게 변화시키기도 한다.
 
ⓒ Getty Images Bank 

트루포트(TrueFort)는 기업 조직의 안전한 애플리케이션 전달을 보장할 수 있게 해주는 클라우드 워크로드 보호 및 모니터링을 위한 접근 방법인 애플리케이션 보안 행동 분석(Application Security Behavior Analytics, ASBA)을 개발했다. ASBA는 실시간 애플리케이션 행동 프로파일링, CI/CD 보안 모니터링, 런타임 보호의 3가지 핵심 구성요소를 기반으로 한다.


실시간 애플리케이션 행동 프로파일링

비즈니스 애플리케이션은 일반적으로 행동, 그리고 다른 개체와의 관계의 조합으로 특징지을 수 있다.

예를 들어 일반적인 소매 전자상거래 애플리케이션에는 고객이 위치한 시간대, 그리고 해당 시간대와 연결된 네트워크에서 알려진 API 호출을 사용한 다른 서비스와의 커뮤니케이션이 포함된다. 또한 웹 서버, 로드 밸런서, 캐시, 문서 저장소, 데이터베이스 간의 활동이 동기화된다.

얼핏 ERP 시스템은 전자상거래 애플리케이션처럼 보일 수 있다. 웹, 애플리케이션, 데이터베이스 서버가 상호 연결되고 데이터베이스 활동량 증가와 같은 행동이 애플리케이션 서버 활동량 증가와 연계되기 때문이다. 그러나 전자상거래와 달리 ERP는 일반적으로 LAN에 위치하는 사용자에 의해서만 액세스되며 월별 보고 주기 및 일괄 처리와 관련해 특정 기간 동안 서버 측의 사용량만 많아지는 특징을 보인다.

악의적인 내부자와 외부 공격자는 이런 미묘한 행동적 특성과 위협 흔적에 대해서는 모르거나 무신경하며, 일단 기업 경계선 안에 침입하면 어떤 행동을 해도 발각되지 않는다고 믿는다. 불행히도 실제로 발각되지 않는 경우가 많다.

트루포트 플랫폼은 이상 현상과 잠재적 위협을 파악하기 위해 비즈니스 애플리케이션의 행동을 전체적으로 프로파일링해 “정상” 활동의 기준 모델을 구축함으로써 이 공백을 없앤다. 트루포트는 각 워크로드에서 관계, 종속성, 프로세스, 일시적 변동을 포함한 수백 개의 매개변수를 모니터링하고 이 데이터를 다른 워크로드에서 얻은 데이터와 연계한다.

캡처되는 텔레메트리의 예를 들면 네트워크 연결, 프로세스 세부 사항, 서비스 계정, VM/서버/컨테이너에 마운트된 파일 시스템, 다른 인프라 및 애플리케이션 계층과 업스트림/다운스트림 애플리케이션과의 관계 등이 있다.

ASBA는 이 종합적인 시야와 정립된 정상 기준을 기반으로 프론트 엔드 애플리케이션 서버가 유휴 상태인 동안 데이터베이스의 사용량이 평소와 달리 증가하는 등의 중요한 이상 현상을 파악할 수 있다(실제로 에퀴팩스(Equifax) 데이터 침해 당시 발생했던 현상이다). 정상 기준에서 벗어난다는 것은 악의적인 내부자 또는 외부 위협 공격자가 예상치 못한 위치에서, 비일상적인 시간에 네트워크에 대한 액세스 권한을 획득했음을 의미할 수 있다. ASBA는 빠른 대응과 포렌식 조사, 자동화된 교정을 위해 이와 같은 특성의 사건을 실시간으로 탐지한다.


SDLC와 CI/CD 보안 모니터링

디지털 트랜스포메이션을 시행하는 조직은 새로운 개발 방법론을 수용하는데, 이 과정에서 새로운 공격 표면으로 인해 새로운 위험에 노출되는 경우가 많다.

첫째, CI/CD 툴체인이 공격 표면이 됐다. CI/CD는 회사의 IP(코드, 데이터, 구성, 인증 정보)에 액세스하며 전용 보안 래퍼가 없다. 그러나 내부자 위협, 외부 공격자, 프로세스 유출로부터 반드시 보호해야 할 대상이다.

또한 젠킨스(Jenkins), 스핀네이커(Spinnaker)와 같은 CI 툴은 매우 유용하고, 워크플로우와 품질 게이트, 승격, 결함 탐지 등 개발 자동화에 흔히 사용되지만 이 부분에 장애 또는 공격이 발생할 경우 비즈니스에 심각한 피해가 발생할 가능성이 있다.

예를 들어 코드 푸시, 업그레이드 및 복구는 점차 자동화되고 있으며 복구 시간은 분 또는 초 단위로 측정된다. 악의적인 내부자나 외부자에 의해 CI 툴체인이 손상되는 경우 소프트웨어 빌드 활동이 무기한 중단되고 실패한 서비스의 복구도 차단된다.

ASBA는 피해가 넓게 확산되기 전에 툴체인과 비즈니스 프로세스의 손상을 프로파일링해 탐지하고 경보를 발령하고 통제할 수 있다. 구체적으로, ASBA는 누가 또는 무엇이 소스 리포지토리에 액세스하고 있는지, 누가 넥서스에서 풀링 작업을 했는지, 젠킨스 워크플로우의 변경이 어디서 이뤄졌는지 등을 포함한 여러 요소를 모니터링할 수 있다. 또한 ASBA는 포렌식 데이터를 제공하고 궁극적으로는 무단 활동을 차단할 수 있다.

둘째, 서드파티 코드 사용이다. 특히 오픈소스 구성요소 사용이 증가함에 따라 개발 환경 내에 보안 위험을 일으키는 요인이다. 이와 같은 빌딩 블록 내의 취약점과 복잡한 종속성 트리가 악용 가능한 결함을 찾는 스캐너의 비효율성과 결합되면 보안 위험은 대폭 증가한다.

트루포트와 ASBA 접근 방법은 서드파티 또는 맞춤 코드 등 공격 수단에 관계없이 행동 이상을 탐지함으로써 런타임 애플리케이션 보호를 위한 최후의 방어선을 제공한다.

셋째, 제품 팀은 테스트 주도 개발(Test Driven Development, TDD)을 채택해 소프트웨어 테스트를 자동화하지만 여기에 충분한 보안 검증이 포함되는 경우는 극히 드물다. 여기에는 릴리스 승격에 앞서 안전을 확인하기 위한 아티팩트(컨테이너, WAR 파일 등), 코드, API의 구현 평가가 포함된다(원점 회귀). 코드 품질과 코드 분석은 보안 측면에서 이점을 제공하지만 포괄적이라고 할 수는 없다.

ASBA는 검증 단계의 방어를 강화하기 위한 핵심적인 피드백 루프를 제공할 수 있다.

예를 들어 2019년 7월 8일, 강력한 비밀번호 확인을 위한 루비 라이브러리에서 제로데이 취약점이 보고됐다. 이 제로데이는 취약점 데이터베이스에서 인식되지 않으므로 이런 취약점 피드에 의존하는 정적 및 동적 코드 분석 툴에서도 문제를 탐지하지 못할 가능성이 높다. 방화벽에도 같은 한계가 있다. 즉, 방화벽은 경계를 보호하고 알려진 위협을 차단함으로써 데이터 유출을 막지만 제로데이 공격을 차단하지는 못한다.

반면 ASBA는 이 라이브러리가 침해된 이후에 발생한 비정상적인 URL로의 POST 활동을 탐지하고 경보를 발령할 수 있다. 이 예시에서 ASBA는 위험과 영향, 가능성을 낮춤으로써 검증 단계에 강도와 깊이를 더해준다.

테스트 단계(UAT, 부하, A:B)는 애플리케이션이 빌드되는 즉시 기능하므로 ASBA로 정상적인 행동 프로파일링을 시작하기 위한 이상적인 단계이기도 하다. 사용자 동의, 스트레스 테스트 등이 진행되는 동안 행동을 관찰함으로써 탐지, 차단, 보호를 위한 보안 정책을 구축할 수 있다. 예를 들어 카오스 몽키(Chaos Monkey)와 같은 워크로드 시뮬레이션과 탄력성 툴은 SRE에 정보를 제공하는 데 사용할 수 있는 유용한 데이터 집합과 트래픽을 생성하고 사고 대응 프로세스를 개발하고 마이크로 세그먼테이션 전략을 구현하고 대응 워크플로우를 자동화할 수 있다.


런타임 보호

이상적으로 보면 배포된 애플리케이션에는 개발 및 테스트 단계에서 습득한 모든 보안 교훈이 적용되어야 한다. 그러나 많은 경우 이와 같은 교훈은 일부 또는 완전히 간과된다.

데브옵스 환경에서는 “프로덕션에서 테스트한다”는 말을 자주 듣게 된다. 이것은 사실 뻔한 말이다. 배포 아키텍처, 운영, 규모를 비롯한 프로덕션 요소는 고유하기 때문이다. 이 고유함에 A:B 및 카나리아 테스트, 배포, 운영이 혼합되며 이는 모두 서로 다른 사용 사례로 이어진다.

ASBA는 피드백 루프 내에서 통찰력을 제공, 사이트 신뢰성 공학을 최적화함으로써 테스트와 배포 간의 간격을 없애 서비스 수준 목표를 달성할 수 있게 해준다.

ASBA의 실시간 경보와 포렌식 감사 기능은 전통적인 APM(Application Performance Management) 또는 로그 분석 솔루션과 달리 조치 가능한 해답을 제공하며 단서와 흔적을 찾기 위해 비구조적 데이터를 쿼리할 필요성을 없앤다. 이런 방법으로 ASBA는 SDCL 전반에서, 또한 애플리케이션이 배포되고 운영되는 동안 위협에 대한 시야를 제공한다. editor@itworld.co.kr 


2019.10.08

데브옵스를 위한 보안 행동 분석의 효과

Andy Hawkins | InfoWorld
클라우드 네이티브 아키텍처(cloud-native architecture), 지속적 통합과 지속적 전달(Continuous Integration and Continuous Delivery, CI/CD), 데브옵스(Devops), 사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)과 같은 기술과 접근 방법은 소프트웨어 제품을 혁신하고 전달 속도를 높일 수 있게 해준다. 동시에 전통적인 소프트웨어 개발 및 유지보수 라이프사이클(SDLC)를 와해하고 기업이 애플리케이션과 비즈니스 서비스를 성공적으로 보호하기 위해 해야 할 여러 가지를 크게 변화시키기도 한다.
 
ⓒ Getty Images Bank 

트루포트(TrueFort)는 기업 조직의 안전한 애플리케이션 전달을 보장할 수 있게 해주는 클라우드 워크로드 보호 및 모니터링을 위한 접근 방법인 애플리케이션 보안 행동 분석(Application Security Behavior Analytics, ASBA)을 개발했다. ASBA는 실시간 애플리케이션 행동 프로파일링, CI/CD 보안 모니터링, 런타임 보호의 3가지 핵심 구성요소를 기반으로 한다.


실시간 애플리케이션 행동 프로파일링

비즈니스 애플리케이션은 일반적으로 행동, 그리고 다른 개체와의 관계의 조합으로 특징지을 수 있다.

예를 들어 일반적인 소매 전자상거래 애플리케이션에는 고객이 위치한 시간대, 그리고 해당 시간대와 연결된 네트워크에서 알려진 API 호출을 사용한 다른 서비스와의 커뮤니케이션이 포함된다. 또한 웹 서버, 로드 밸런서, 캐시, 문서 저장소, 데이터베이스 간의 활동이 동기화된다.

얼핏 ERP 시스템은 전자상거래 애플리케이션처럼 보일 수 있다. 웹, 애플리케이션, 데이터베이스 서버가 상호 연결되고 데이터베이스 활동량 증가와 같은 행동이 애플리케이션 서버 활동량 증가와 연계되기 때문이다. 그러나 전자상거래와 달리 ERP는 일반적으로 LAN에 위치하는 사용자에 의해서만 액세스되며 월별 보고 주기 및 일괄 처리와 관련해 특정 기간 동안 서버 측의 사용량만 많아지는 특징을 보인다.

악의적인 내부자와 외부 공격자는 이런 미묘한 행동적 특성과 위협 흔적에 대해서는 모르거나 무신경하며, 일단 기업 경계선 안에 침입하면 어떤 행동을 해도 발각되지 않는다고 믿는다. 불행히도 실제로 발각되지 않는 경우가 많다.

트루포트 플랫폼은 이상 현상과 잠재적 위협을 파악하기 위해 비즈니스 애플리케이션의 행동을 전체적으로 프로파일링해 “정상” 활동의 기준 모델을 구축함으로써 이 공백을 없앤다. 트루포트는 각 워크로드에서 관계, 종속성, 프로세스, 일시적 변동을 포함한 수백 개의 매개변수를 모니터링하고 이 데이터를 다른 워크로드에서 얻은 데이터와 연계한다.

캡처되는 텔레메트리의 예를 들면 네트워크 연결, 프로세스 세부 사항, 서비스 계정, VM/서버/컨테이너에 마운트된 파일 시스템, 다른 인프라 및 애플리케이션 계층과 업스트림/다운스트림 애플리케이션과의 관계 등이 있다.

ASBA는 이 종합적인 시야와 정립된 정상 기준을 기반으로 프론트 엔드 애플리케이션 서버가 유휴 상태인 동안 데이터베이스의 사용량이 평소와 달리 증가하는 등의 중요한 이상 현상을 파악할 수 있다(실제로 에퀴팩스(Equifax) 데이터 침해 당시 발생했던 현상이다). 정상 기준에서 벗어난다는 것은 악의적인 내부자 또는 외부 위협 공격자가 예상치 못한 위치에서, 비일상적인 시간에 네트워크에 대한 액세스 권한을 획득했음을 의미할 수 있다. ASBA는 빠른 대응과 포렌식 조사, 자동화된 교정을 위해 이와 같은 특성의 사건을 실시간으로 탐지한다.


SDLC와 CI/CD 보안 모니터링

디지털 트랜스포메이션을 시행하는 조직은 새로운 개발 방법론을 수용하는데, 이 과정에서 새로운 공격 표면으로 인해 새로운 위험에 노출되는 경우가 많다.

첫째, CI/CD 툴체인이 공격 표면이 됐다. CI/CD는 회사의 IP(코드, 데이터, 구성, 인증 정보)에 액세스하며 전용 보안 래퍼가 없다. 그러나 내부자 위협, 외부 공격자, 프로세스 유출로부터 반드시 보호해야 할 대상이다.

또한 젠킨스(Jenkins), 스핀네이커(Spinnaker)와 같은 CI 툴은 매우 유용하고, 워크플로우와 품질 게이트, 승격, 결함 탐지 등 개발 자동화에 흔히 사용되지만 이 부분에 장애 또는 공격이 발생할 경우 비즈니스에 심각한 피해가 발생할 가능성이 있다.

예를 들어 코드 푸시, 업그레이드 및 복구는 점차 자동화되고 있으며 복구 시간은 분 또는 초 단위로 측정된다. 악의적인 내부자나 외부자에 의해 CI 툴체인이 손상되는 경우 소프트웨어 빌드 활동이 무기한 중단되고 실패한 서비스의 복구도 차단된다.

ASBA는 피해가 넓게 확산되기 전에 툴체인과 비즈니스 프로세스의 손상을 프로파일링해 탐지하고 경보를 발령하고 통제할 수 있다. 구체적으로, ASBA는 누가 또는 무엇이 소스 리포지토리에 액세스하고 있는지, 누가 넥서스에서 풀링 작업을 했는지, 젠킨스 워크플로우의 변경이 어디서 이뤄졌는지 등을 포함한 여러 요소를 모니터링할 수 있다. 또한 ASBA는 포렌식 데이터를 제공하고 궁극적으로는 무단 활동을 차단할 수 있다.

둘째, 서드파티 코드 사용이다. 특히 오픈소스 구성요소 사용이 증가함에 따라 개발 환경 내에 보안 위험을 일으키는 요인이다. 이와 같은 빌딩 블록 내의 취약점과 복잡한 종속성 트리가 악용 가능한 결함을 찾는 스캐너의 비효율성과 결합되면 보안 위험은 대폭 증가한다.

트루포트와 ASBA 접근 방법은 서드파티 또는 맞춤 코드 등 공격 수단에 관계없이 행동 이상을 탐지함으로써 런타임 애플리케이션 보호를 위한 최후의 방어선을 제공한다.

셋째, 제품 팀은 테스트 주도 개발(Test Driven Development, TDD)을 채택해 소프트웨어 테스트를 자동화하지만 여기에 충분한 보안 검증이 포함되는 경우는 극히 드물다. 여기에는 릴리스 승격에 앞서 안전을 확인하기 위한 아티팩트(컨테이너, WAR 파일 등), 코드, API의 구현 평가가 포함된다(원점 회귀). 코드 품질과 코드 분석은 보안 측면에서 이점을 제공하지만 포괄적이라고 할 수는 없다.

ASBA는 검증 단계의 방어를 강화하기 위한 핵심적인 피드백 루프를 제공할 수 있다.

예를 들어 2019년 7월 8일, 강력한 비밀번호 확인을 위한 루비 라이브러리에서 제로데이 취약점이 보고됐다. 이 제로데이는 취약점 데이터베이스에서 인식되지 않으므로 이런 취약점 피드에 의존하는 정적 및 동적 코드 분석 툴에서도 문제를 탐지하지 못할 가능성이 높다. 방화벽에도 같은 한계가 있다. 즉, 방화벽은 경계를 보호하고 알려진 위협을 차단함으로써 데이터 유출을 막지만 제로데이 공격을 차단하지는 못한다.

반면 ASBA는 이 라이브러리가 침해된 이후에 발생한 비정상적인 URL로의 POST 활동을 탐지하고 경보를 발령할 수 있다. 이 예시에서 ASBA는 위험과 영향, 가능성을 낮춤으로써 검증 단계에 강도와 깊이를 더해준다.

테스트 단계(UAT, 부하, A:B)는 애플리케이션이 빌드되는 즉시 기능하므로 ASBA로 정상적인 행동 프로파일링을 시작하기 위한 이상적인 단계이기도 하다. 사용자 동의, 스트레스 테스트 등이 진행되는 동안 행동을 관찰함으로써 탐지, 차단, 보호를 위한 보안 정책을 구축할 수 있다. 예를 들어 카오스 몽키(Chaos Monkey)와 같은 워크로드 시뮬레이션과 탄력성 툴은 SRE에 정보를 제공하는 데 사용할 수 있는 유용한 데이터 집합과 트래픽을 생성하고 사고 대응 프로세스를 개발하고 마이크로 세그먼테이션 전략을 구현하고 대응 워크플로우를 자동화할 수 있다.


런타임 보호

이상적으로 보면 배포된 애플리케이션에는 개발 및 테스트 단계에서 습득한 모든 보안 교훈이 적용되어야 한다. 그러나 많은 경우 이와 같은 교훈은 일부 또는 완전히 간과된다.

데브옵스 환경에서는 “프로덕션에서 테스트한다”는 말을 자주 듣게 된다. 이것은 사실 뻔한 말이다. 배포 아키텍처, 운영, 규모를 비롯한 프로덕션 요소는 고유하기 때문이다. 이 고유함에 A:B 및 카나리아 테스트, 배포, 운영이 혼합되며 이는 모두 서로 다른 사용 사례로 이어진다.

ASBA는 피드백 루프 내에서 통찰력을 제공, 사이트 신뢰성 공학을 최적화함으로써 테스트와 배포 간의 간격을 없애 서비스 수준 목표를 달성할 수 있게 해준다.

ASBA의 실시간 경보와 포렌식 감사 기능은 전통적인 APM(Application Performance Management) 또는 로그 분석 솔루션과 달리 조치 가능한 해답을 제공하며 단서와 흔적을 찾기 위해 비구조적 데이터를 쿼리할 필요성을 없앤다. 이런 방법으로 ASBA는 SDCL 전반에서, 또한 애플리케이션이 배포되고 운영되는 동안 위협에 대한 시야를 제공한다. editor@itworld.co.kr 


X