ClickCease RSAC 2020: 더 빠른 패치 관리로 규정 준수 지원 - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

RSAC 2020: 더 빠른 패치 관리로 규정 준수 지원

2020년 2월 27일 TuxCare 홍보팀

RSAC 2020: 더 빠른 패치 관리로 규정 준수 지원

RSA 컨퍼런스 2020에서 KernelCare의 CEO인 이고르 셀레츠키가 더 빠른 패치 관리로 규정 준수를 가능하게 하는 모범 사례를 공유했습니다. 이 글에서 연설의 핵심 내용을 확인하실 수 있습니다.

기업에게 규정 준수는 트렌드가 아니라 필수입니다. 규정을 준수하지 않으면 고객과 거래하지 않으려는 기업이 점점 더 많아지고 있습니다. 규정을 준수하지 않으면 매출 및 비즈니스 전반에 걸쳐 심각한 손실을 초래할 수 있습니다.

규정 준수 모범 사례는 직원과 HR 부서부터 IT 인프라의 핵심에 이르기까지 회사 비즈니스의 모든 부분에 영향을 미칩니다. 선택할 수 있는 표준은 수십 가지가 있습니다.

독병 및 IT 보안 표준이 있는 슬라이드

예를 들어 SOC2나 사베인즈-옥슬리 법을 보면 "소프트웨어 취약점은 30일 이내에 완화해야 합니다.". 서버를 관리해 본 적이 있다면 이것이 말처럼 쉽지 않다는 것을 알 것입니다.

그래서 오늘은 패치 관리를 간소화하여 규정을 준수하는 방법과 패치 관리가 보안 및 규정 준수에 중요한 이유를 설명하고자 합니다.

 

패치 관리가 중요한 이유는 무엇인가요?

첫째, 패치 관리가 중요한 이유는 무엇인가요?

오래되거나 취약한 소프트웨어가 보안 침해의 주요 원인 중 하나라는 것은 누구나 알고 있는 사실입니다. 다음은 이 사실을 상기시켜주는 몇 가지 예시입니다:

  1. 2017년 발생한 에퀴팩스 데이터 유출 사건은 패치되지 않은 apache 스트럿츠 취약점으로 인해 해커가 약 1억 5천만 명의 고객 데이터를 탈취한 사건입니다. 이 취약점은 해커가 웹 서버의 권한으로 명령을 실행할 수 있다는 것을 의미합니다. 이 취약점은 완전한 원격 명령 실행이 가능하며 최초 공개 이후 활발하게 악용되고 있습니다. Equifax는 7억 달러에 가까운 손실을 입었으며, 여전히 이 취약점으로 인한... 친절하게도 "감독"에 대한 비용을 계산하고 있습니다.
  2. 2018년 발생한 메리어트 데이터 유출 사고는 호텔 예약 시스템에서 3억~5억 건의 고객 정보가 해킹으로 유출된 사건입니다. 메리어트는 그해 9월 8일 내부 보안 도구로부터 누군가 미국 내 스타우드 고객 예약 데이터베이스에 액세스하려고 시도하고 있다는 경고를 받았습니다. 조사 결과, 권한이 없는 사람이 데이터베이스의 내용을 복사하고 암호화한 후 다운로드한 사실을 발견했습니다. 데이터 유출의 원인은 메리어트가 이전에 인수한 시스템(스타우드 네트워크)의 소프트웨어에 패치가 적용되지 않아 해커가 고객 데이터베이스에 액세스할 수 있었기 때문이었습니다.
  3. 포춘지 선정 500대 전력 회사 데이터 유출. 익명의 전력 회사가 1년 이상 물리적 제어 시스템 소프트웨어 패치를 무시하여 필수 보안 규칙을 위반하여 수백만 가구의 전력 공급이 위험에 처했습니다. 근본 원인은 잘못된 구성으로 인해 시스템 자동 업데이트가 중단된 것이었습니다. 이 회사는 시스템을 폐기하고 있었기 때문에 백업이 없었습니다. 수동 패치는 재부팅을 의미하기 때문에 원하지 않았습니다. 이 회사는 서부 전력 조정위원회에 사건을 자진 신고하고 벌금을 납부했지만, 문제가 된 물리적 출입 통제 시스템을 교체하고 새로운 보안 패치 관리 프로그램을 구현한 2017년 7월까지 규정을 준수하지 않았습니다.

관련 게시물: 세 가지 유명 데이터 유출 사고

이는 패치 관리의 중요성을 설명하는 데 도움이 되는 많은 사례 중 일부에 불과합니다. 문제는 유명 인사와 대규모 데이터 유출 사건만 헤드라인을 장식한다는 것입니다. 제 말이 무슨 뜻인지 보시려면 privacyrights.org를 보세요. 이 사이트에는 9000건이 넘는 사례가 담긴 스프레드시트가 있는데, 이는 미국에만 해당되는 것입니다. 전 세계에서 보고되지 않은 다른 모든 사례를 상상해 보세요.

따라서 취약점이 공개된 후 30일 이내에 취약한 소프트웨어를 패치해야 한다는 사실을 우리 모두 알고 있어야 합니다. 필수적인 IT 보안 관행은 취약점을 검사한 다음 일반적으로 패치 관리 도구를 통해 패치를 적용하는 것입니다.

 

반드시 사용해야 합니다: 취약점 스캐너 및 패치 관리 도구

이러한 취약점 스캐너에 대해 들어보셨을 것입니다.

    1. Qualys
    2. Nessus
    3. Rapid7

이러한 도구를 사용하면 취약성 관리가 훨씬 쉬워집니다. 심지어 취약점을 찾아서 패치할 수도 있어 보안 및 운영 담당자에게 큰 도움이 됩니다. 스캐너는 시스템 약점을 탐지 및 분류하고, 수정 우선순위를 정하며, 때로는 대응책의 효과를 예측하는 데 도움을 줄 수 있습니다.

일반적으로 패킷 구성의 이상 징후, 익스플로잇 가능한 프로그램 또는 스크립트의 경로 등 알려진 보안 취약점에 대한 정보 데이터베이스에서 표적 공격 표면을 찾습니다.

  1. 패치 관리 도구
    1. Yum / apt 업데이트
    2. Ansible
    3. 인형
    4. 솔트스택
    5. 셰프
    6. 우주 유영

이와 같은 자동화된 패치 관리 도구는 시스템 관리자의 부담을 덜어줍니다. 시스템 관리자에게 물어보면 여러 장치에 패치를 자동으로 다운로드하고 설치하는 도구가 얼마나 좋은지 알게 될 것입니다. Linux 서버 패치는 더 빠르고 안정적으로 배포됩니다.

 

패치 관리 - 몇 가지 모범 사례

기업들은 일반적으로 Linux 서버가 40대 또는 50대 이상으로 늘어나면 자동화된 패치 관리 도구 사용을 고려합니다. 이 정도 규모가 되면 IT 부서는 수동 패치 적용이 너무 힘들어져 결국 긴급하거나 우선순위가 높은 패치만 배포하게 됩니다.

Linux 패치는 Kernel의 소스 코드를 단순히 업데이트하는 것 이상을 포함합니다. 이러한 패치에는 시스템 보안을 보장하고 오류를 최소화하며 최신 기능을 도입하는 업데이트가 포함됩니다. 하지만 가장 중요한 것은 적절한 패치 관리를 통해 소프트웨어와 운영 체제의 취약점을 해결함으로써 기업의 보안을 크게 향상시킬 수 있다는 점입니다.

하지만 Linux 서버 패치는 복잡할 수 있습니다. 오픈 소스 소프트웨어 개발이 덜 체계적이기 때문에 업데이트의 릴리스 주기가 예측하기 어렵습니다. 또한 오픈 소스 소프트웨어는 소프트웨어 스택의 모든 지점에서 실행되므로 변경 사항을 주의 깊게 분석해야 합니다.

대부분의 업데이트는 Linux 명령을 실행하는 것만큼이나 쉽지만, 기술적인 측면만 있는 것은 아닙니다. 조직적인 문제도 있습니다. 업데이트해야 하는 항목을 추적하고 업데이트의 영향을 이해해야 합니다. 업데이트를 테스트하고 단계적으로 진행해야 하며, 변경 사항을 여러 부서에 전달해야 합니다.

파란색 배경의 돈과 패치는 비싼 텍스트입니다.

포네몬 연구소의 조사에 따르면, 매년 조직은 패치 활동에 평균 18,000시간과 110만 달러의 비용을 지출하고 있습니다. 이러한 노력에도 불구하고 패치된 취약점에 대한 익스플로잇이 야생에 출현하는 데 걸리는 시간이 줄어드는 것을 경험한 기업은 많지 않습니다. 강력한 패치 관리 모범 사례를 구현하지 않으면 기업은 시간을 낭비하고 공격의 문을 열어두는 위험을 감수해야 합니다.

또한, 사이버 공격 피해자의 약 3분의 2가 패치를 적용했더라면 공격을 막을 수 있었다고 답했다는 사실도 포네몬 조사에서 밝혀졌습니다. 그리고 3분의 1은 공격 전에 취약점에 대해 알고 있었지만 아무 조치도 취하지 않았다고 답했습니다. 무섭습니다.

따라서 견고한 패치 관리 프로세스는 성숙한 보안 프레임워크의 필수적인 부분입니다. 올바른 애플리케이션에 올바른 패치를 더 빨리 적용할수록 환경의 보안은 더욱 강화됩니다.

 

패치 관리는 어려운 일이지만 불가능한 것은 아닙니다. 기업에서 유용하게 사용하는 패치 관리 모범 사례가 많이 있습니다:

  1. 먼저 환경 내의 모든 소프트웨어와 하드웨어에 대한 포괄적인 인벤토리를 작성합니다. 기업이 보유하고 있는 것을 명확하게 파악한 후에는 알려진 취약점과 인벤토리를 비교하여 중요한 패치를 신속하게 발견합니다.
  2. 앞서 기업들이 잘못된 시스템을 패치하는 데 연간 평균 18,000시간을 낭비하고 있다고 말씀드린 바 있습니다. 이를 방지할 수 있는 방법이 있습니다. 모든 시스템을 패치해야 하지만, 인벤토리의 각 항목에 위험 수준을 할당하는 것이 좋습니다. 예를 들어, 일부 구성 요소에 대한 패치는 계획된 활동일 수 있지만 Linux Kernel에 주요 CVE에 대한 보안 업데이트를 적용하는 것은 기업에게 매우 중요합니다. 공격에 더 많이 노출된 항목일수록 더 빨리 패치를 적용해야 한다는 것이 황금률입니다.
  3. 기업은 소프트웨어 버전 (및 소프트웨어 자체)을 통합하는 데 사용됩니다. 조직에서 사용하는 소프트웨어의 버전이 많을수록 노출 위험이 높아집니다. 또한 많은 양의 관리 오버헤드가 발생합니다. 사용 중인 모든 소프트웨어와 그 목적을 주기적으로 검토하고, 동일한 기능을 수행하는 여러 소프트웨어를 찾아서 하나를 선택하고 나머지는 제거하세요.
  4. 패치 관리 프로세스의 또 다른 일반적인 관행은 공급업체의 패치 발표를 따라 잡고 각 패치가 패치 일정에 추가될 수 있도록 프로세스를 만드는 것입니다.
  5. 패치를 적용하려면 패치가 작동하도록 변경해야 하는 등 패치를 적용하는 데 더 많은 시간이 필요한 경우가 있습니다. 이러한 경우 기업은 가능한 한 위험을 완화합니다. 패치를 안전하게 적용할 수 있을 때까지 익스플로잇의 영향과 가능성을 줄이는 것이 중요합니다.
  6. 새 패치를 받아 모든 프로덕션 서버에 한꺼번에 적용하는 것이 아무리 신나더라도 먼저 테스트해 보세요. 모든 환경은 고유하기 때문에 간단한 패치로도 문제가 발생하거나 서버가 다운될 수 있습니다. 일반적으로 기업은 시스템의 일부에 패치를 적용하여 큰 문제가 없는지 확인합니다.

Linux Kernel 패치 적용

99%의 패치 유형은 시스템 재부팅이 필요하지 않습니다. 하지만 Linux Kernel 패치의 경우, 99%의 조직이 서버를 재부팅하는 동일한 방식으로 패치를 적용합니다. 서버를 재부팅하는 것은 골치 아픈 작업이기 때문에 사람들은 가능한 한 오랫동안 재부팅을 미룹니다. 즉, 패치가 가능한 한 빨리 적용되지 않는다는 뜻입니다. 패치 문제와 패치 적용 사이의 이러한 격차는 위험과 과실을 의미합니다.

또한 대부분의 엔터프라이즈 기업은 오프라인 상태가 될 수 없기 때문에 시스템 소프트웨어를 최신 상태로 유지하는 것이 어렵습니다. 기업들은 유지보수 기간이나 재부팅 주기를 개발하고 이를 엄격하게 준수하는 방식으로 이 문제를 해결합니다. 이러한 방식은 계획하는 데 많은 시간이 걸리고 구현하는 데 많은 리소스가 필요하며, 결국 시스템을 재부팅하고 또 다른 재부팅 주기를 시작하게 됩니다. 다음은 일반적인 패치 프로세스입니다.

 

  1. 먼저, 무엇을 패치해야 하는지 알아야 합니다. 즉, 기업 전반의 모든 서비스와 플랫폼을 포괄하는 정확한 시스템 인벤토리를 확보해야 합니다.
  2. 그런 다음 영향을 파악하고 일종의 변경 관리 프로세스를 진행해야 합니다.
  3. 테스트는 반복 가능하고 감사할 수 있어야 합니다.
  4. 다음으로, SLA와 가동 시간 기록에 문제가 생기지 않기를 바라는 수십 명의 이해관계자들과 유지 보수 기간을 협상하는 기쁨이 있습니다.
  5. 그런 다음 업데이트를 수행합니다. 밤늦게까지 일하고 주말에도 일해야 하는 엔지니어를 제외하고는 이 작업이 가장 쉬운 부분인 경우가 많습니다.
  6. 마지막으로 또 다른 재부팅 주기를 계획합니다. 그렇게 계속 진행됩니다.

 

하지만 이 과정이 왜 그렇게 복잡할까요? 그 진짜 이유는 무엇일까요? 제가 말씀드리겠습니다. 바로 그 이유 때문입니다:

  1. 재부팅은 관리하기 어렵습니다.
  2. 재부팅하려면 다운타임 예약이 필요합니다.
  3. 재부팅이 불안하다 - 시스템이 복구되지 않으면 어떻게 하나요?
  4. 서버가 많을수록 재부팅 문제가 더 많이 발생합니다.

많은 기업들이 30일 이상 패치되지 않은 소프트웨어로 30일 이상 사용해야 했습니다! 
많은 사례에 따르면 데이터 유출로 이어질 수 있으며 
수십억 달러의 손실을 초래할 수 있습니다. 

 

KernelCare 고객은 6년 이상 중단 없이 운영되는 완전 패치된 서버를 보유하고 있으며, 모든 주요 Linux 배포판을 지원합니다. 클라우드 또는 온프레미스, 방화벽 또는 에어 갭 환경 뒤에서 작동합니다. 취약성 스캐너 및 패치 관리 솔루션과 커스텀 Kernel 패치를 즉시 지원합니다.

작동 방식은 다음과 같습니다:

패치 프로세스 다이어그램 (1)

 

KernelCare는 300,000대 이상의 서버를 보유한 기업이 SOC2 규정 준수 상태를 달성할 수 있도록 지원했습니다. 다음은 그 중 몇 가지 사례입니다.

  1. Efinity Insurance - 14개국의 고객과 방대한 개인 데이터를 보유한 온라인 보험사입니다. 실시간 보험 견적 서비스를 판매하여 수익을 창출합니다. 이 앱은 Java로 구현되었으며 AWS의 CentOS에서 실행됩니다. 여러 가지 이유로 이 앱을 클러스터링할 수 없었기 때문에 서비스 가용성을 잃지 않으면서 서버를 호환성, 즉 패치를 유지하기 위해 저희를 선택했습니다. 이 연구 사례에서 자세히 알아보세요.
  2. 저희 고객 중 한 곳은 수억 명의 고객과 맞춤형 Linux Kernel, 엄격한 방화벽 시스템을 갖춘 포춘지 선정 500대 기업 중 하나인 유명한 온라인 디지털 결제 회사입니다. 이름을 알려드리면 여러분도 이 회사를 아실 것 같지만, 저희는 이 회사와 비밀유지계약(NDA)을 맺었기 때문에 죄송합니다. 제가 말씀드릴 수 있는 것은 지속적인 전자 결제 서비스에 필수적인 수백 가지 Kernel 보안 패치를 재부팅 없이 유지하기 위해 KernelCare를 사용하고 있다는 것입니다. 이 연구 사례에서 자세히 알아보세요.
  3. 잘 알려진 기업용 화상 회의 솔루션입니다. 이 회사의 규정 준수 분석가가 먼저 저희에게 연락을 취했습니다. SOC2 감사가 예정되어 있었고 재부팅 주기로 인해 규정 준수 기준을 충족하지 못하고 있었습니다. 그들은 2개월 동안 KernelCare를 사용해 본 후 정식 PoC에 들어갔습니다. 이 테스트는 7일 동안만 진행되었고, 그 후 KernelCare를 프로덕션 환경으로 전환했습니다. 우리는 7,000대 이상의 서버에 KernelCare를 배포하기 위해 Ansible과 통합하는 데 도움을 제공했습니다. 또한 완전히 깨끗한 스캔을 확인해야 하는 Qualys 취약성 스캐너와의 통합과 관련하여 훌륭한 피드백을 받고 함께 작업했습니다.

KernelCare는 금융 및 보험 서비스, 화상 회의 솔루션 제공업체, 가정 폭력 피해자를 보호하는 회사, 호스팅 회사, 공공 서비스 제공업체 등 서비스 가용성과 데이터 보호가 비즈니스에서 가장 중요한 부분인 다양한 기업의 30만 대 이상의 서버에서 규정 준수를 강화합니다.

다양한 서버 제품군을 위한 유연한 가격 책 정, 누구나 사용할 수 있는 무료 평가판, 맞춤형 인프라를 갖춘 고객을 위한 맞춤형 개념 증명(PoC)을 제공합니다.

7일 지원되는 KernelCare 무료 체험판 받기 

 

 

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기