9년 2003월 XNUMX일, Microsoft CEO Steve Ballmer는 "예측 가능성과 관리 가능성을 향상시켜 IT 관리자의 부담을 줄이기 위해" 보안 패치를 한 달에 한 번만 발행할 것이라고 발표했습니다.

XNUMX년이 지난 후에도 Microsoft는 매달 두 번째 화요일에 보안 업데이트를 계속해서 발표하고 있습니다. 단, 긴급 상황에 대한 예외는 있으며 Oracle 및 Adobe와 같은 다른 많은 회사도 유사한 규칙을 따릅니다.

패치 화요일 위험 관리를 월별 약속으로 바꾸었지만 많은 혁신과 마찬가지로 위기에서 시작되었습니다. 2002년 초, 세계가 최초의 사이버 종말을 두 차례 경험한 직후, 코드 레드와 님다, Microsoft는 보안에 대한 철학을 바꾸기로 결정했습니다. 몇 시간 만에 수십만 대의 컴퓨터를 감염시킨 두 웜은 패치가 제공되는 취약점을 악용했습니다.

“문제는 우리가 패치를 구축하지 않는다는 것이 아닙니다. 2000년부터 2010년까지 Microsoft에서 근무했으며 현재 Sophos의 위협 연구 선임 관리자인 Christopher Budd는 말합니다.

그 당시 북미에서는 9/11의 충격이 눈에 띄었고 Microsoft 내에서 보안에 대한 우려가 커지고 있었습니다. 15년 2002월 XNUMX일 빌 게이츠는 그의 유명한 신뢰할 수 있는 컴퓨팅 메모, 고객과 시스템 보호의 중요성을 강조합니다.

보안을 개선하는 한 가지 방법은 패치 제공 방식을 변경하는 것이었습니다. 따라서 예상하지 못한 방식으로 발표하는 대신 배송 준비가 되면 일주일에 여러 번 Microsoft는 고객이 모든 것을 쉽게 따라갈 수 있도록 함께 쌓기 시작했습니다.

처음에 이 아이디어는 "조용한 파일럿 프로젝트"로 구현되었다고 Budd는 말합니다. 그러나 유망한 결과를 보여 곧 공식화되었습니다. 그만큼 첫 번째 공식 패치 화요일 14년 2003월 XNUMX일에 발표된 보고서에는 XNUMX개의 취약점이 포함되어 있으며 그 중 XNUMX개는 치명적인 것으로 나타났습니다.

"화요일은 우리가 이것을 지속 가능하게 제공할 수 있다고 느꼈던 주 중 가장 빠른 날이었습니다."라고 화요일 패치 빌드를 도운 Budd는 말합니다.

이 고정 일정 접근 방식은 표준 산업 관행이 되었습니다. 그러나 그 길은 항상 순탄하지 않았습니다.

화요일 패치 초반

수년 동안 Microsoft는 보안 패치에 대한 접근 방식을 발전시키고 개선하여 변화하는 위협에 적응했습니다. 다음과 같은 Code Red를 따르는 주목할만한 웜 새서와 블래스터, 패치 화요일이 성장하고 결국 성숙하도록 도왔습니다.

Trustworthy Computing 메모 이후 "갑자기 엄청나게 중요해졌던" Microsoft Security Response Center의 Budd와 그의 동료들은 패치 배포 및 탐지를 개선하기 위해 노력했습니다. 한 가지 핵심 성과는 관리자가 스캔을 수행하고 보안 업데이트가 필요한 시스템을 식별할 수 있는 도구를 구축한 것입니다. 이는 단순하지만 게임 체인저임이 입증된 아이디어입니다.

패치를 릴리스하는 전체 프로세스에는 광범위한 작업이 필요했으며, 특히 화요일 패치 전 월요일에는 모든 것을 확인해야 했습니다. 보안 전문가들은 집에 갈 시간이 없었기 때문에 긴 시간을 보내고, 생일 파티를 놓치고, Microsoft 본사에서 샤워를 하기까지 했습니다.

확성기에서 흘러나오는 음악과 함께 게시판의 발표를 축하하는 이유도 바로 이 때문입니다.

2008년부터 2014년까지 Microsoft에서 근무했으며 현재 Trend Micro의 Zero Day Initiative에서 위협 인식 책임자인 Dustin Childs는 "게시판이 게시되었을 때 우리에게는 큰 일이었습니다."라고 말합니다.

일반적으로 해당 게시판의 릴리스 관리자가 음악을 선택했습니다.

“한 달은 Klingon 음악이었지만 대개는 로큰롤이었습니다.”라고 Childs는 말합니다.

때때로 음악이 멈춘 직후 일부 패치로 인해 의도하지 않은 결과가 발생하여 혼돈이 뒤따랐습니다. 2010년 XNUMX월에 수천 명의 고객이 거의 즉시 블루 스크린을 보고한 주목할만한 사건이 발생했습니다.

Redmond의 보안 전문가들은 블루 스크린 문제에 대해 듣고 이를 복제하려고 시도했지만 성공하지 못했습니다. 더 나은 솔루션이 없기 때문에 Microsoft는 문제를 보고하기 위해 달라스 근처의 지원 센터에 전화한 고객의 컴퓨터를 구입했습니다.

"그리고 그 컴퓨터를 받자마자 우리는 그 컴퓨터에 루트킷이 설치되어 있다는 것을 알게 되었습니다."라고 Childs는 말합니다.

XNUMXD덴탈의 알 레온 루트킷은 Windows 커널 바이너리를 수정하여 시스템을 불안정하게 만들었습니다. 회사는 패치를 재발행하고 문제를 수정했습니다.

"하지만 정말 재미있는 부분은 루트킷을 만든 사람들이 우리보다 더 빨리 문제를 파악했고 [출시 후] 48시간 이내에 패치를 피하기 위해 루트킷을 업데이트했다는 것입니다."라고 Childs는 말합니다. “고치는 데 일주일이 걸렸어요!”

그리고 패치 튜즈데이 역사상 유일하게 기괴한 에피소드가 아니었습니다. 예를 들어 Childs는 Internet Explorer 패치가 한국에서 온라인 뱅킹을 중단시킨 반면 Windows Media Player 패치가 국가 전체를 두 번 중단했던 것을 기억합니다.

"어떤 이유로 덴마크의 시스템에서는 블루스크린이 발생했습니다."라고 그는 말합니다. “그래서 우리는 해당 패치를 회수하고 수정하여 다시 릴리스해야 했습니다. 그리고 그 다음 달에도 같은 일이 반복됐다. 덴마크의 시스템이 구체적으로 어떤 것인지 모르겠습니다.”

오늘날에도 Microsoft뿐만 아니라 일반 소프트웨어 회사에서 출시하는 일부 패치는 설치하는 사람들에게 문제를 일으킬 수 있습니다. Childs는 공급업체가 이러한 수정 사항의 안정성을 개선하면 고객이 다른 사람이 문제를 경험했는지 확인하기 위해 몇 주 또는 몇 달을 기다리는 대신 신속하게 적용할 의향이 더 커질 것이라고 주장합니다.

대기 접근 방식을 사용하면 시스템이 알려진 취약성에 취약해지기 때문에 위험할 수 있습니다. 이것이 바로 Childs가 사용자에게 가능한 한 빨리 패치를 적용할 것을 권장하는 이유입니다. 그는 또한 그들에게 주의를 환기시키라고 말한다. 품질이 좋지 않은 패치.

"공급업체에 책임을 물읍시다"라고 Childs는 말합니다. "그들이 좋은 패치를 생산하고 있는지 확인합시다."

Microsoft의 부 CISO인 Aanchal Gupta는 회사가 패치에 대해 "광범위한 테스트"를 수행하고 있다고 말합니다.

“고객에게 패치를 제공하기 전에 Microsoft 내에서만이 아니라 엄격한 테스트를 거칩니다. … [W]e는 또한 일련의 베타 테스터, 외부 회사를 보유하고 있으며 패치가 실제로 공개되기 전에 초기에 패치를 받습니다.”라고 그녀는 말합니다. "그들은 자신의 환경에서 테스트하고 패치가 작동하지 않도록 만들 수 있는 고유한 환경이 있는지 여부를 우리에게 다시 보고할 수 있습니다."

오늘 패치 화요일

패치 튜즈데이는 Klingon 음악이 스피커에서 흘러나온 초창기 이후 먼 길을 왔습니다. 시간이 지남에 따라 릴리스는 더 조용해지고 심지어 자동화되어 일부 사용자에게는 보이지 않게 되었습니다.

지난 2010년 동안 Microsoft는 프로세스를 간소화하기 위해 몇 가지 사항을 변경했습니다. 예를 들어 XNUMX년대 중반에는 XNUMX개의 패치를 놓친 고객이 나머지 패치가 포함되어 있기 때문에 마지막 패치만 적용하면 되도록 누적 업데이트를 발표했습니다. 이 회사는 또한 기계 판독이 가능한 보안 업데이트 가이드를 출시했는데, 이는 대규모 플릿 배포를 가진 조직이 자동화에 의존할 수 있음을 의미했습니다.

그러나 모든 변화가 커뮤니티에서 환영받은 것은 아닙니다. Microsoft가 보안 게시판을 제거하고 보안 업데이트 가이드로 교체하기로 결정했을 때 고객은 받은 정보가 덜 직관적이라고 불평했습니다. 2020년 가을에 기술 대기업이 취약점에 대한 자세한 정보가 포함된 요약을 제거했을 때도 비슷한 일이 일어났습니다. 다시 한 번, 업계의 많은 사람들이 충분한 정보를 받지 못해 의사 결정 과정이 어렵다고 주장했습니다.

보안 연구원인 Claire Tills는 이것이 Microsoft가 내린 "아마도 가장 파괴적인" 결정이라고 말했습니다. "일부 수비수들도 그런 문제를 겪었다는 것을 알고 있습니다."

더 최근인 2022년에 Microsoft는 패치 화요일을 정규 화요일로 만들기 위해 또 다른 조치를 취했습니다. 오토 패치, Windows Enterprise E3 및 E5 라이선스를 보유한 고객의 취약성 해결 프로세스를 용이하게 하겠다고 약속했습니다. 이러한 움직임으로 인해 조직은 우리가 알고 있는 화요일 패치가 사라질지 궁금해했지만 Microsoft는 부인했습니다.

화요일 패치에 대한 홍보가 점점 줄어들고 있으며 패치 화요일 취약점 수 정점에 달했을 수 있습니다. 특히 "공격적인 해"인 2020년에 Tills는 약 1,200개를 세었고 2022년에는 663개를 보았습니다.

"취약점 유형 측면에서 볼 때 지속적으로 권한 상승 및 원격 코드 실행입니다."라고 그녀는 말합니다. "때때로 정보 공개와 보안 기능 우회가 최고조에 달할 것입니다. 이 두 가지도 나타납니다."

그러나 패치 적용 프로세스를 간소화하기 위한 기능에도 불구하고 이 작업은 전담 기술 지원 팀을 고용할 여력이 없는 소기업에게는 여전히 벅찰 수 있습니다. Gupta가 이러한 고객에게 클라우드로 이전할 것을 권장하는 이유입니다.

“그러면 순전히 비즈니스에 집중할 수 있고 시스템 패치 및 관리에 대해 걱정할 필요가 없습니다.”라고 그녀는 말합니다. "또한 사람들이 기본 업그레이드를 비활성화하지 말 것을 권장합니다."

그러나 프로세스 자동화로 전환함에 따라 업데이트에 하루를 할애하는 것이 쓸모없게 되었습니까?

화요일 패치가 더 이상 사용되지 않습니까?

XNUMX년 동안 업계의 필수적인 부분이었던 패치 화요일 없이는 사이버 보안의 세계를 가늠하기 어렵습니다. 그러나 위협이 더욱 정교해지고 지정학이 더욱 불안정해짐에 따라 전통적인 화요일 패치 모델로는 더 이상 시스템 보안을 유지하기에 충분하지 않을 수 있습니다.

경쟁이 치열한 지역이나 우크라이나와 같은 뜨거운 지역에 기반을 둔 복잡한 환경에서 운영되는 조직은 패치 관리와 관련하여 실수를 해서는 안 됩니다. 사이버 보안 스타트업 UnderDefense의 설립자이자 CEO인 Nazar Tymoshyk는 위협 행위자들이 종종 "특정 개인이나 조직이 아닌 기술적 취약점을 표적으로 삼았다"고 말했습니다.

"기술 스택 또는 오래된 웹 리소스의 패치되지 않은 취약점을 악용하는 것이 여전히 [러시아] 사이버 인텔리전스 운영 성공의 50%를 차지합니다."라고 그는 말합니다.

Tymoshyk는 화요일 패치가 여전히 필요하며 폐기되어서는 안 된다고 생각합니다. 그러나 조직은 그 위에 구축해야 합니다. 추가 패치 루틴 인프라의 크기와 복잡성 또는 사용하는 소프트웨어 및 시스템 유형에 따라 다릅니다.

Tenable의 수석 연구 엔지니어인 Satnam Narang도 패치 화요일을 유지하는 것을 선호합니다. 보안 중심 문화.

“매주 사람들이 우리 거리에서 쓰레기를 주우러 옵니다. 우리는 매주 특정한 날에 이런 일이 일어나고 있다는 것을 알고 있습니다.”라고 그는 말합니다. "Patch Tuesday가 귀중한 리소스인 이유는 매월 특정 날짜에 발생하므로 조직이 이러한 취약점을 패치하는 데 필요한 시간을 확보할 수 있기 때문입니다."

혼란스러운 패치 시스템은 작동하지 않을 수 있다고 Narang은 말합니다. 보안 팀이 이미 압도당하고 있기 때문입니다. Votiro의 CTO이자 창립자인 Aviv Grafi도 이에 동의합니다. Grafi는 "시간이 가장 중요하며 보안 팀에게 더 많은 시간을 제공하는 기술과 소프트웨어를 활용하는 데 집중해야 합니다."라고 Grafi는 말합니다.

보안 연구원들은 또한 지속적인 패치 주기와 자동 업데이트 경우에 따라 엔터프라이즈 수준에서 항상 실현 가능한 것은 아닙니다. Nucleus의 솔루션 아키텍트인 David Farquhar는 "문제 발생 시 대규모 조직은 시스템을 알려진 상태로 되돌릴 수 있어야 하며 이를 위해서는 계획이 필요합니다."라고 말합니다.

패치 화요일은 많은 조직의 일상에서 중요한 요소이지만 그럼에도 불구하고 예측할 수 없습니다. 지난 몇 년 동안 그 구조가 사전 경고 없이 변경될 수 있음을 보여주었습니다. Tills는 “화요일 패치가 매우 기초적이고 견고하게 느껴지지만 한 방울의 모자에 바뀔 수 있습니다.”라고 말합니다. "Patch Tuesday의 끝은 많은 조직에 재앙으로 느껴질 수 있습니다."

그러나 당분간은 Microsoft가 프로그램을 계속 실행하는 것으로 보입니다. 굽타는 “화요일 패치가 곧 사라질까 걱정하지 않을 것”이라고 말했다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://www.darkreading.com/edge-articles/how-patch-tuesday-keeps-the-beat-after-20-years