패치 배포 시간에 대한 생각

조직은 새로운 위협으로부터 보안을 유지하기 위해 시스템을 "제때" 패치하려고 노력합니다. 이러한 맥락에서 "제때"라는 것은 조직마다 다른 의미를 갖습니다. 어떤 조직은 취약점이 공개된 후 한 달 이내에 패치를 적용하려고 노력하는 반면, 어떤 조직은 패치가 제공되는 즉시 패치를 적용합니다( 라이브 패치를 통해 가능해진 것처럼) 패치가 제공되는 즉시 패치를 적용하는 조직이 있는가 하면, 비즈니스 요구 사항에 따라 필요한 다운타임이 허용되는 즉시 패치를 적용하는 조직도 있습니다.

하지만 여기서 시간을 제대로 계산하고 있을까요? 패치에 대해 이야기할 때 "제시간"이란 실제로 무엇을 의미할까요?

정시에

방금 발표된 다소 무해한 취약점의 예를 살펴보겠습니다: CVE-2023-25136 - 사전 인증 프로세스에서 이미 릴리스된 변수를 "해제"하려고 시도하여 잠재적으로 문제를 일으킬 수 있는 OpenSSH 취약점입니다. 이 취약점은 2월 3일에 공개되었으며, 일부 CVE 등록기관에서는 아직 세부 정보가 부족합니다.

(명백한) 위험성이 없다는 점을 무시하고 가설적으로 위험성이 높은 취약점이라고 가정할 때, 이 결함에 대해 "제때" 패치를 적용한다는 것은 무엇을 의미할까요? (이 글을 쓰는 시점을 기준으로) 오늘 패치를 적용한다면 공개 발표 후 일주일 이내에 패치를 적용하는 것이며, 이는 매우 좋은 일이며 인프라가 다시 안전해졌다고 생각할 수 있습니다. 한 달 이상 소요 고위험 취약점을 패치하는 데 한 달 이상이 걸렸다는 연구 결과에 비추어 볼 때 확실한 타임라인입니다. 모든 올바른 상자에 체크 표시를 하면 규정 준수 책임자는 매우 만족할 것이고, 사용자는 일상적인 활동으로 돌아갈 수 있습니다.

이 취약점이 실제로 1월에 OpenSSH 팀에 보고되었고, 공개 메일링 리스트에 공개 메일링 리스트 공개 메일링 리스트에서 교환된 메시지가 있었다고 생각해보세요. 이로써 실제 CVE가 공개되기 전에 잠재적으로 충돌을 유발할 수 있는 버그에 대한 공개 정보가 2주간 더 추가되었습니다. 그리고 이것은 버그가 CVE를 생성하는 눈에 보이는 측면일 뿐입니다. 버그가 처음부터 올바른 팀에 보고되지 않았다면 완전히 다른 시점이 될 수 있습니다. 예를 들어, 어딘가의 수상한 포럼에서 제로데이 익스플로잇으로 판매된 경우입니다. 이 특정 취약점의 경우 CVE가 발표된 당일에 패치를 적용했더라도 이미 2주 동안 위험에 노출되었을 가능성이 있습니다.

과대 평가된 CVE

따라서 "제때"라는 말은 "공식적으로 공개되었기 때문에" 또는 "CVE 번호가 붙어 있기 때문에"라는 뜻이지, 실제로 "알려진 이후"라는 뜻은 아닙니다. 버그와 관련된 초기 정보가 CVE가 나타나기 몇 달 전에 발생하는 경우도 있습니다. 왜 일부 CVE에 전년도 연도가 표시되는지 궁금한 적이 있나요? 이는 해당 버그가 전년도에 발견되어 분석-패치 제작-공개 과정에 몇 달이 걸렸기 때문입니다. 그리고 이 과정은 종종 버그 보고서와 깃허브 또는 메일링 리스트 토론을 가장하여 대중의 눈에 띄게 진행됩니다.

여기서 대화가 탈선할 수 있습니다. 사용자가 알 수 있는 CVE조차 없는데 안전하지 않은 시스템을 사용할 수는 없겠죠? 안타깝게도 이는 잘못된 질문입니다.

모든 취약점에 CVE가 할당되는 것은 아닙니다. 예를 들어, Kernel 보안 팀은 매주 새로운 취약점에 대해 (공개적으로 알려진) CVE가 할당되지 않은 채로 수정 사항을 소개하는데, 이는 부분적으로는 악의적인 공격자에게 패치되지 않은 시스템에 대한 벡터를 제공할 수 있기 때문이고, 부분적으로는 CVE 시스템 자체에 일련의 비효율성이 있기 때문입니다. 이에 대해 자세히 알아보기 여기에서.

사이버 보안 업계는 CVE에 집중하고 있습니다. 패치할 수 없는 취약점을 찾아내고, 추적하고, 우선순위를 정하고, 패치를 적용하고, 전략을 수립하지만 CVE는 빙산의 일각에 불과합니다. 

위험 기간 최소화

보안에 대한 유일한 지표가 규정 준수 요건을 충족하기 위해 주어진 기간 내에 패치한 CVE의 개수라면, 생각보다 '보안'이 취약한 상태일 수 있습니다. 위험 기간은 CVE가 발표된 시점이 아니라 그 이전부터 시작되며, 그 기간이 얼마나 될지는 불확실하므로 위험 기간을 최대한 단축하는 것이 가장 좋습니다. 위험 기간의 종료 시간만 제어할 수 있습니다. 조직이 패치를 적용하는 데 한 달 이상 걸리는 경우 이러한 암묵적 위험은 그 이전에 발생하는 다른 모든 일과 더불어 큰 영향을 미칩니다.

물론 패치가 나오기 전에 패치를 적용하는 것은 불가능하지만, 새로운 취약점을 처리하는 데 몇 주가 걸리지 않도록 가능한 한 빨리 패치를 적용하기 위해 모든 조치를 취해야 합니다. 

취약점이 실제로 공개되기까지 걸리는 (때로는 긴) 시간은 패치를 더 빠르게 적용해야 하는 가장 큰 이유입니다. 위협 행위자는 새로운 기회를 찾기 위해 버그 보고서를 적극적으로 모니터링하고 버그를 신속하게 '무기화'하는 데 필요한 기술을 갖추고 있습니다. 

해커를 돕지 마세요 - 해커는 필요하지 않습니다. 지금 패치하세요.

요약

기사 이름

패치 배포 시간에 대한 생각

설명

조직은 새로운 위협으로부터 보안을 유지하기 위해 시스템을 "제때" 패치하려고 하는 경우가 많습니다. 하지만 "제때"라는 것이 실제로 무엇을 의미할까요?

작성자

조아오 코레이아

게시자 이름

TuxCare

게시자 로고