.jpg)
.jpg)
기업에 취약점 보고하는 화이트해커 수 크게 증가...사람, 프로세스, 툴 간 조합 필요
단일 데브섹옵스 플랫폼의 단순성과 심층 방어전략 결합시 조직의 가시성과 제어 지점 개선가능
[보안뉴스= 현태호 깃랩 코리아 지사장] 오픈소스 기술과 소프트웨어 코드 저장소(Repository)는 의심할 여지없이 혁신을 위한 기업들의 진입장벽을 낮추고, 출시시간을 단축할 수 있는 수단이다. 최근 발표된 스태티스타(Statista)의 전망자료에 따르면, 전세계 모바일 애플리케이션 매출이 2023년까지 9,350억 달러에 이를 것으로 예상되고 있다. 그러나 이러한 성장에는 보안 위험이 내재돼 있다.
기업들은 경쟁우위를 확보하기 위해 오픈소스 툴과 혁신 문화를 채택하는 데 집중하고 있지만, 애플리케이션 보안 문제에 대해서는 간과하는 경우가 많다. 개발자들이 애플리케이션에 추가하는 각 계층들은 공격 노출(Attack Surface)을 증가시키고, 새로운 침입 가능성을 높이는 것은 물론, 애플리케이션 코드 자체에도 종종 많은 취약성이 포함되기도 한다. 2021년 해커 보고서(Hacker Report)는 20개의 각기 다른 취약성 범주의 버그에 대해 언급하고, “모든 범주에 걸쳐 기업에 취약점을 보고하는 화이트 해커(White Hat)의 수가 크게 증가했다”고 밝혔다.
이와 관련한 해결 과제는 개발자와 보안 담당자가 더욱 긴밀히 협력하고, 데브옵스(DevOps) 내에 보안 툴과 프로세스 및 문화를 포함하는 것이다. 4,300명의 전문가를 대상으로 한 깃랩(GitLab)의 자체 조사에 따르면, 기업들은 여전히 보안 담당자를 결정하는 데 어려움을 겪고 있는 것으로 나타났다. 또한, 보안 전문가의 31%는 자신이 전적으로 보안을 책임지고 있다고 응답한 반면, 28%에 달하는 보안 전문가들은 모든 사람에게 책임이 있다고 밝혔다. 보다 최근에 실시한 설문조사에서도 데브옵스와 보안 전문가 중 누가 소프트웨어 보안을 책임져야 하는지에 대해 의견이 분분했다. 이러한 불확실성이 계속되는 가운데, 소프트웨어 팀은 어떻게 수많은 오픈소스 제공업체들의 새로운 애플리케이션과 구성요소를 보다 효과적으로 구성하고, 테스트할 수 있을까?
조사에 따르면, 테스트 책임에 대한 혼란이나 개발자가 보유한 적절한 테스트 툴의 부족으로 인해 애플리케이션 릴리스와 기업의 테스트 능력 간의 격차가 벌어지는 것으로 나타났다. 일부 조사원들은 개발자의 80%가 문제가 있는 코드임을 알고도 릴리스했음을 인정했다고 지적하기도 했다.
선도적인 데브옵스 기업들은 IT 팀이 소프트웨어 공급망을 효과적으로 제어하고, 가시화할 수 있도록 총체적 보안 프로그램과 최신 데브옵스 플랫폼을 결합하는 것이 애플리케이션 보안을 개선할 수 있는 핵심이라고 판단하고 있다. 이러한 노력을 위해서는 부서 간 협업은 물론, 사람과 프로세스 및 툴 간의 조합이 필요하다.
1단계: 새로운 공격노출을 고려하여 보안 위생(Security Hygiene) 평가
많은 공격들이 기업들의 기본적인 보안 위생(패치 및 암호 등)에 대한 관리 부족을 악용해 이미 오래전부터 존재해 온 악용 행위를 통해 재시도되는 경우가 많다. 기업들은 소프트웨어 개발 툴체인과 컨테이너, 오케스트레이터 및 코드형 인프라(IaC: Infrastructure as Code)와 같은 잠재적인 공격 노출 가능성을 고려하고, 보안 정책을 검토해야 한다. 다중 인증이 사용되고 있는지, 인증정보가 탐지되고 있는지 살펴봐야 한다. 또한, 기업들은 가시성과 액세스 제어를 위한 관리자 설정을 확인해야 한다.
2단계: 스캐닝, 정책, 컴플라이언스 자동화
많은 기업들이 테스트 및 컴플라이언스 등의 복잡한 작업을 데브옵스 툴 영역 내에서 수행할 수 있다는 사실에 놀랄 수도 있을 것이다.
기업들은 CI 파이프라인 내에 보안 스캔을 자동화하고 있을까? 대부분의 사람들은 SAST나 또는 의존성 스캐닝(Dependency Scanning)을 사용한다. 각 유형의 스캔은 서로 다른 유형의 취약성을 탐지할 수 있지만, 전체 애플리케이션 포트폴리오에 포인트 스캐닝을 적용하는 것은 많은 비용이 소모될 수 있다.
더 큰 규모의 개발자 팀과 복잡한 툴체인에 기반하고 있는 기업들은 최근의 데브섹옵스(DevSecOps) 혁신과 계속해서 증가하는 애플리케이션 보안 및 스캐닝 리소스를 따라가지 못할 수 있다. 데브옵스 툴은 소규모 스타트업은 물론, 중소기업 및 대기업에서도 효과적으로 사용할 수 있으며, 여러 포인트 솔루션보다 사용이 간편하기 때문에 기업들이 코드 스캐닝과 같은 작업을 자동화할 수 있을 뿐만 아니라, 고위 IT 임원과 개발자 및 보안 전문가 간의 협업을 보다 긴밀하게 촉진시킬 수 있다.
예를 들어, 데브옵스 단일 플랫폼은 개발자들이 다음과 같은 3가지 주요 작업을 수행할 수 있도록 SAST, DAST, 의존성 및 컨테이너 스캐닝, 인증정보 탐지, 퍼즈 테스트(Fuzz Testing) 등과 같은 포괄적인 애플리케이션 스캐닝을 제공한다.
- 제3자 코드 및 컨테이너 코드를 포함한 기업의 모든 코드를 스캔한다.
- 모든 코드의 변경사항 스캔: 데브옵스 툴은 여러 스캔 방법을 사용하여 모든 코드 변경에 대한 앱 보안 테스트 스캔을 가능하게 하며, 최상의 CI 툴은 검토 앱을 활용하여 CI 파이프라인 내에서 DAST도 실행할 수 있다. 또한, 이러한 모든 스캔을 코드가 메인 브랜치로 푸시되기 전에 배치할 수 있기 때문에 공유 환경에 취약점이 발생하는 것을 최소화할 수 있다.
- 퍼즈 테스트를 사용하여 알려진 CVE 서명이 없는 안전하지 않은 로직 결함을 찾을 수 있다. 데브옵스 제공업체의 보안 스캐닝은 웹 API와 툴에 대한 커버리지-가이드(Coverage-Guided) 테스트와 동작(Behavioral) 테스트를 모두 포함하고 있다. 팀 단위에서는 CI 파이프라인에 통합된 퍼즈 테스트 기능을 갖춘 제품을 독립형 퍼즈 테스트보다 더 쉽게 사용할 수 있다.
자동화에 대한 보안 및 효율성을 확보하기 위해서는 제어 가능한 표준화된 CI 프로세스를 적용해야 한다. CNCF는 “소프트웨어 공급망을 최대한 자동화하면, 인적 오류 및 구성 드리프트(Configuration Drift) 가능성을 크게 줄일 수 있다”고 지적했다.
기업들은 모든 프로젝트에 대해 표준화된 CI 템플릿이 필요한가? 자동으로 산업 표준 컴플라이언스를 적용하고 있는가? 취약점이 발견되면, 정책 예외가 있는 MR을 누가 승인할 수 있는가?
CI/CD 자동화는 다음과 같은 일반적인 제어를 적용할 수 있는 하나의 수단이다.
- 공존할 수 없는 업무 분리
- ID(Identity) 및 액세스 승인 제어
- 구성 관리 및 변경 제어
- 구성 및 파이프라인 변경에 대한 액세스 제한
- 브랜치 및 운영환경 보호
- 감사(Auditing)
- 라이선스 코드 사용
- 보안 테스트
이러한 일반적인 제어를 통해 정책 실행을 자동화하면, 보다 일관된 컴플라이언스를 보장하는 동시에 감사 영역을 줄일 수 있다.
선도적인 제품들은 컴플라이언스 대시보드, 컴플라이언스 관리 및 감사 보고서를 비롯해 단일 데브옵스 플랫폼 내에서 각기 다른 다양한 컴플라이언스 기능을 제공한다.
3단계: 애플리케이션 인프라 보호
최신 애플리케이션은 코드 자체보다 훨씬 더 많은 것에 의존하고 있다. 도커(Docker)와 쿠버네티스(Kubernetes) 환경과 같은 클라우드 네이티브 인프라를 고려해야 하고, 헬름 차트(Helm Chart)를 스캔하기 위해 컨테이너 스캐닝을 적용하고, SAST를 사용한다. 또한, 컨테이너 호스트 보안 및 컨테이너 네트워크 보안을 이용해 모니터링과 보호 기능을 고려해야 한다. 팔코(Falco) 및 앱아머(AppArmor)와 같은 오픈소스 툴을 CI 환경에 사용하면, 빌드 서버가 예약된 작업 및 OS 구성에 대해서 임의로 수정하지 못하도록 경고하고 방지할 수 있다.
또한, 개발팀과 보안팀은 컨테이너 레지스트리와 같이 더욱 모호한 요소들도 확인해야 한다. 기업에서 쓰기 권한을 가지고 있는 사람은 누구인가? 한 명의 개인이 잘못하면, 컨테이너 레지스트리가 손상될 수 있으며, 파이프라인을 통해 여러 소프트웨어 프로젝트에 취약성을 초래할 수 있다.
4단계: 소프트웨어 팩토리 보안
최신 데브옵스 플랫폼은 액세스와 소프트웨어 팩토리 정책 및 반복 가능하고 측정할 수 있는 프로세스를 한 곳에서 관리함으로써 소프트웨어 팩토리를 보호하는 데 필요한 노력을 간소화할 수 있도록 설계됐다. 모범사례는 다음과 같다.
- 제로 트러스트(Zero Trust) 원칙 적용: 공급망 환경의 모든 개체에 대한 최소한의 권한 액세스 및 인증 등
- 데브옵스 인스턴스 강화를 고려한 다음, 정기적으로 확인 및 검증
- 코드 서명 및 증명
- 의존성에서 악성 코드를 탐지하는 최신 툴 사용
- CI/CD 변수는 파이프라인의 동작을 제어할 수 있다. 범위가 지정된 환경은 사용할 수 있는 환경(예: 운영환경)을 정의해 CI/CD 변수의 범위를 제한할 수 있다.
- 컴플라이언스 파이프라인에서 관리자가 개발 프로젝트에 적용되는 보안 스캔을 결정할 때 쓰이는 템플릿을 제어한다.
5단계: 지속적인 평가 및 개선 반복
보안 팀이 최신 소프트웨어 공급망을 보호하기 위해서는 위에 언급한 1~4단계를 지속적으로 재검토해야 하기 때문에 복잡한 툴체인과 보안의 통합을 조정하기가 훨씬 더 어려워진다. 최신 애플리케이션 개발 프로세스에는 빌드 후 코드를 검사하는 대신, 보안 및 제어를 위해 소프트웨어 팩토리 자체를 정비할 수 있는 새로운 사고방식이 요구된다.
보안은 절대적으로 보장되는 것은 아니다. 하지만 단일 데브섹옵스 플랫폼의 단순성과 심층 방어 전략을 결합하면, 보안 노력을 간소화하고 조직의 가시성과 제어 지점을 개선할 수 있는 강력한 지원군을 얻게 될 것이다.
[글_현태호 깃랩 코리아 지사장]
[필자 소개]
현태호 깃랩 코리아 지사장_ 30년 이상 컴퓨터 소프트웨어 및 SaaS 비즈니스 분야에서 다양한 경력을 보유한 전문가이다. 2020년 12월부터 공식적으로 깃랩의 한국 지사장으로 부임했다. 깃랩 입사 이전에는 15년간 한국IBM과 IBM 아시아지역 본부에서 영업 및 마케팅 부서에서 일했으며, 머큐리 인터랙티브에서 전무 이사로서 해당 기업을 애플리케이션 테스팅 1위 기업으로 성장시켰다. 이후 VMware 한국지사장, HP엔터프라이즈 소프트웨어 사업부 총괄 책임자를 역임하기도 했다.
단일 데브섹옵스 플랫폼의 단순성과 심층 방어전략 결합시 조직의 가시성과 제어 지점 개선가능
[보안뉴스= 현태호 깃랩 코리아 지사장] 오픈소스 기술과 소프트웨어 코드 저장소(Repository)는 의심할 여지없이 혁신을 위한 기업들의 진입장벽을 낮추고, 출시시간을 단축할 수 있는 수단이다. 최근 발표된 스태티스타(Statista)의 전망자료에 따르면, 전세계 모바일 애플리케이션 매출이 2023년까지 9,350억 달러에 이를 것으로 예상되고 있다. 그러나 이러한 성장에는 보안 위험이 내재돼 있다.
[이미지=utoimage]
기업들은 경쟁우위를 확보하기 위해 오픈소스 툴과 혁신 문화를 채택하는 데 집중하고 있지만, 애플리케이션 보안 문제에 대해서는 간과하는 경우가 많다. 개발자들이 애플리케이션에 추가하는 각 계층들은 공격 노출(Attack Surface)을 증가시키고, 새로운 침입 가능성을 높이는 것은 물론, 애플리케이션 코드 자체에도 종종 많은 취약성이 포함되기도 한다. 2021년 해커 보고서(Hacker Report)는 20개의 각기 다른 취약성 범주의 버그에 대해 언급하고, “모든 범주에 걸쳐 기업에 취약점을 보고하는 화이트 해커(White Hat)의 수가 크게 증가했다”고 밝혔다.
이와 관련한 해결 과제는 개발자와 보안 담당자가 더욱 긴밀히 협력하고, 데브옵스(DevOps) 내에 보안 툴과 프로세스 및 문화를 포함하는 것이다. 4,300명의 전문가를 대상으로 한 깃랩(GitLab)의 자체 조사에 따르면, 기업들은 여전히 보안 담당자를 결정하는 데 어려움을 겪고 있는 것으로 나타났다. 또한, 보안 전문가의 31%는 자신이 전적으로 보안을 책임지고 있다고 응답한 반면, 28%에 달하는 보안 전문가들은 모든 사람에게 책임이 있다고 밝혔다. 보다 최근에 실시한 설문조사에서도 데브옵스와 보안 전문가 중 누가 소프트웨어 보안을 책임져야 하는지에 대해 의견이 분분했다. 이러한 불확실성이 계속되는 가운데, 소프트웨어 팀은 어떻게 수많은 오픈소스 제공업체들의 새로운 애플리케이션과 구성요소를 보다 효과적으로 구성하고, 테스트할 수 있을까?
조사에 따르면, 테스트 책임에 대한 혼란이나 개발자가 보유한 적절한 테스트 툴의 부족으로 인해 애플리케이션 릴리스와 기업의 테스트 능력 간의 격차가 벌어지는 것으로 나타났다. 일부 조사원들은 개발자의 80%가 문제가 있는 코드임을 알고도 릴리스했음을 인정했다고 지적하기도 했다.
선도적인 데브옵스 기업들은 IT 팀이 소프트웨어 공급망을 효과적으로 제어하고, 가시화할 수 있도록 총체적 보안 프로그램과 최신 데브옵스 플랫폼을 결합하는 것이 애플리케이션 보안을 개선할 수 있는 핵심이라고 판단하고 있다. 이러한 노력을 위해서는 부서 간 협업은 물론, 사람과 프로세스 및 툴 간의 조합이 필요하다.
1단계: 새로운 공격노출을 고려하여 보안 위생(Security Hygiene) 평가
많은 공격들이 기업들의 기본적인 보안 위생(패치 및 암호 등)에 대한 관리 부족을 악용해 이미 오래전부터 존재해 온 악용 행위를 통해 재시도되는 경우가 많다. 기업들은 소프트웨어 개발 툴체인과 컨테이너, 오케스트레이터 및 코드형 인프라(IaC: Infrastructure as Code)와 같은 잠재적인 공격 노출 가능성을 고려하고, 보안 정책을 검토해야 한다. 다중 인증이 사용되고 있는지, 인증정보가 탐지되고 있는지 살펴봐야 한다. 또한, 기업들은 가시성과 액세스 제어를 위한 관리자 설정을 확인해야 한다.
2단계: 스캐닝, 정책, 컴플라이언스 자동화
많은 기업들이 테스트 및 컴플라이언스 등의 복잡한 작업을 데브옵스 툴 영역 내에서 수행할 수 있다는 사실에 놀랄 수도 있을 것이다.
기업들은 CI 파이프라인 내에 보안 스캔을 자동화하고 있을까? 대부분의 사람들은 SAST나 또는 의존성 스캐닝(Dependency Scanning)을 사용한다. 각 유형의 스캔은 서로 다른 유형의 취약성을 탐지할 수 있지만, 전체 애플리케이션 포트폴리오에 포인트 스캐닝을 적용하는 것은 많은 비용이 소모될 수 있다.
더 큰 규모의 개발자 팀과 복잡한 툴체인에 기반하고 있는 기업들은 최근의 데브섹옵스(DevSecOps) 혁신과 계속해서 증가하는 애플리케이션 보안 및 스캐닝 리소스를 따라가지 못할 수 있다. 데브옵스 툴은 소규모 스타트업은 물론, 중소기업 및 대기업에서도 효과적으로 사용할 수 있으며, 여러 포인트 솔루션보다 사용이 간편하기 때문에 기업들이 코드 스캐닝과 같은 작업을 자동화할 수 있을 뿐만 아니라, 고위 IT 임원과 개발자 및 보안 전문가 간의 협업을 보다 긴밀하게 촉진시킬 수 있다.
예를 들어, 데브옵스 단일 플랫폼은 개발자들이 다음과 같은 3가지 주요 작업을 수행할 수 있도록 SAST, DAST, 의존성 및 컨테이너 스캐닝, 인증정보 탐지, 퍼즈 테스트(Fuzz Testing) 등과 같은 포괄적인 애플리케이션 스캐닝을 제공한다.
- 제3자 코드 및 컨테이너 코드를 포함한 기업의 모든 코드를 스캔한다.
- 모든 코드의 변경사항 스캔: 데브옵스 툴은 여러 스캔 방법을 사용하여 모든 코드 변경에 대한 앱 보안 테스트 스캔을 가능하게 하며, 최상의 CI 툴은 검토 앱을 활용하여 CI 파이프라인 내에서 DAST도 실행할 수 있다. 또한, 이러한 모든 스캔을 코드가 메인 브랜치로 푸시되기 전에 배치할 수 있기 때문에 공유 환경에 취약점이 발생하는 것을 최소화할 수 있다.
- 퍼즈 테스트를 사용하여 알려진 CVE 서명이 없는 안전하지 않은 로직 결함을 찾을 수 있다. 데브옵스 제공업체의 보안 스캐닝은 웹 API와 툴에 대한 커버리지-가이드(Coverage-Guided) 테스트와 동작(Behavioral) 테스트를 모두 포함하고 있다. 팀 단위에서는 CI 파이프라인에 통합된 퍼즈 테스트 기능을 갖춘 제품을 독립형 퍼즈 테스트보다 더 쉽게 사용할 수 있다.
자동화에 대한 보안 및 효율성을 확보하기 위해서는 제어 가능한 표준화된 CI 프로세스를 적용해야 한다. CNCF는 “소프트웨어 공급망을 최대한 자동화하면, 인적 오류 및 구성 드리프트(Configuration Drift) 가능성을 크게 줄일 수 있다”고 지적했다.
기업들은 모든 프로젝트에 대해 표준화된 CI 템플릿이 필요한가? 자동으로 산업 표준 컴플라이언스를 적용하고 있는가? 취약점이 발견되면, 정책 예외가 있는 MR을 누가 승인할 수 있는가?
CI/CD 자동화는 다음과 같은 일반적인 제어를 적용할 수 있는 하나의 수단이다.
- 공존할 수 없는 업무 분리
- ID(Identity) 및 액세스 승인 제어
- 구성 관리 및 변경 제어
- 구성 및 파이프라인 변경에 대한 액세스 제한
- 브랜치 및 운영환경 보호
- 감사(Auditing)
- 라이선스 코드 사용
- 보안 테스트
이러한 일반적인 제어를 통해 정책 실행을 자동화하면, 보다 일관된 컴플라이언스를 보장하는 동시에 감사 영역을 줄일 수 있다.
선도적인 제품들은 컴플라이언스 대시보드, 컴플라이언스 관리 및 감사 보고서를 비롯해 단일 데브옵스 플랫폼 내에서 각기 다른 다양한 컴플라이언스 기능을 제공한다.
3단계: 애플리케이션 인프라 보호
최신 애플리케이션은 코드 자체보다 훨씬 더 많은 것에 의존하고 있다. 도커(Docker)와 쿠버네티스(Kubernetes) 환경과 같은 클라우드 네이티브 인프라를 고려해야 하고, 헬름 차트(Helm Chart)를 스캔하기 위해 컨테이너 스캐닝을 적용하고, SAST를 사용한다. 또한, 컨테이너 호스트 보안 및 컨테이너 네트워크 보안을 이용해 모니터링과 보호 기능을 고려해야 한다. 팔코(Falco) 및 앱아머(AppArmor)와 같은 오픈소스 툴을 CI 환경에 사용하면, 빌드 서버가 예약된 작업 및 OS 구성에 대해서 임의로 수정하지 못하도록 경고하고 방지할 수 있다.
또한, 개발팀과 보안팀은 컨테이너 레지스트리와 같이 더욱 모호한 요소들도 확인해야 한다. 기업에서 쓰기 권한을 가지고 있는 사람은 누구인가? 한 명의 개인이 잘못하면, 컨테이너 레지스트리가 손상될 수 있으며, 파이프라인을 통해 여러 소프트웨어 프로젝트에 취약성을 초래할 수 있다.
4단계: 소프트웨어 팩토리 보안
최신 데브옵스 플랫폼은 액세스와 소프트웨어 팩토리 정책 및 반복 가능하고 측정할 수 있는 프로세스를 한 곳에서 관리함으로써 소프트웨어 팩토리를 보호하는 데 필요한 노력을 간소화할 수 있도록 설계됐다. 모범사례는 다음과 같다.
- 제로 트러스트(Zero Trust) 원칙 적용: 공급망 환경의 모든 개체에 대한 최소한의 권한 액세스 및 인증 등
- 데브옵스 인스턴스 강화를 고려한 다음, 정기적으로 확인 및 검증
- 코드 서명 및 증명
- 의존성에서 악성 코드를 탐지하는 최신 툴 사용
- CI/CD 변수는 파이프라인의 동작을 제어할 수 있다. 범위가 지정된 환경은 사용할 수 있는 환경(예: 운영환경)을 정의해 CI/CD 변수의 범위를 제한할 수 있다.
- 컴플라이언스 파이프라인에서 관리자가 개발 프로젝트에 적용되는 보안 스캔을 결정할 때 쓰이는 템플릿을 제어한다.
5단계: 지속적인 평가 및 개선 반복
▲현태호 깃랩 코리아 지사장 [사진=깃랩 코리아]
보안은 절대적으로 보장되는 것은 아니다. 하지만 단일 데브섹옵스 플랫폼의 단순성과 심층 방어 전략을 결합하면, 보안 노력을 간소화하고 조직의 가시성과 제어 지점을 개선할 수 있는 강력한 지원군을 얻게 될 것이다.
[글_현태호 깃랩 코리아 지사장]
[필자 소개]
현태호 깃랩 코리아 지사장_ 30년 이상 컴퓨터 소프트웨어 및 SaaS 비즈니스 분야에서 다양한 경력을 보유한 전문가이다. 2020년 12월부터 공식적으로 깃랩의 한국 지사장으로 부임했다. 깃랩 입사 이전에는 15년간 한국IBM과 IBM 아시아지역 본부에서 영업 및 마케팅 부서에서 일했으며, 머큐리 인터랙티브에서 전무 이사로서 해당 기업을 애플리케이션 테스팅 1위 기업으로 성장시켰다. 이후 VMware 한국지사장, HP엔터프라이즈 소프트웨어 사업부 총괄 책임자를 역임하기도 했다.
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
위아람기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
