선생님, 항상 흥미로운 영상 감사합니다!! 일 끝나고 맥주 한잔 마시면서 보면 힐링이 됩니다:) 이 사건에 대해 제 의견도 남기고자 합니다. 보편적으로 발생한 문제 = 일반적인 테스트를 시행했다면 쉽게 발견되었을 문제, 라고 생각합니다. 그렇다면 정상적인 테스트 없이 해당 패치를 배포했을 가능성이 높아 보입니다. 만약 실제로도 그렇다면, 크라우드 스트라이크사의 담당 엔지니어는 도대체 무슨 악과 깡으로 테스트 없이 배포할 생각을 했을까요?! 마이크로소프트사는 많이 억울하겠네요. 괜히 엮여서 고생입니다. 제가 일하던 전 직장은 해외의 유명한 금융회사 였는데, 이곳은 극히 예외적인 경우를 제외하면 절대로 테스트 없이 소프트웨어 변경을 하지 않습니다. 또한 테스트가 끝난 경우에도 절대로 동시에 적용하지는 않으며, 무언가 잘못될 경우 대체하여 투입 할 수 있는 리소스 및 시스템은 항상 준비하여 둡니다. 분산 투자와 마찬가지 이유로요. 델타 항공 이야기가 나왔는데 이 부분은 다른 업계, 다른 회사에서도 진지하게 고려 해 볼 부분이라 생각합니다. 또한 저는 클라우드 100% 의존은 몹시 위험한 발상으로 보고 있습니다. 그리고 이런류의 IT사건은 의외로 흔하다면 흔하지요. 미국 나이트 캐피탈, 한국 한맥 증권 사건을 살펴보는 것도 재미있을 것 같습니다. 비교적 최근에는 도쿄 증권 거래소가 잘못된 IT 인프라 교체로 인해 크게 사고를 친 적도 있지요. 술 한잔 했더니 말이 길어졌습니다. 기회가 되면 리스크 관리에 대해 이야기 해 보고 싶네요ㅎㅎ
제 생각은 조금 다릅니다. 테스트 절차를 시행하지 않았다기 보다 엉뚱한 파일을 배포하는 실수를 했다거나 자신들이 구축한 테스트 환경을 벗어났을 수 있습니다. 개인적으로는 전자 가능성이 높지 않나 추측해봅니다. 직원의 사소한 실수 하나로 조직이 무너지는 경우는 종종 있으니까요. 사실 중요한 것은 왜 재해대책 시스템이 전혀 작동하지 않았는가 입니다. 그 문제는 아예 논의 조차 하지 않는 것으로 보이는데...이 역시 이해할 수 없는 부분입니다. 의견 고맙습니다. :)
@@nullnull_not_eq_null 아! 선생님 말씀을 듣고보니 “엉뚱한 파일을 배포하는 실수”의 가능성이 높아보이네요!! 오래전 읽은 사례라 정확한 기억은 아닐 수 있습니다만, 예시로 든 미국 나이트 캐피탈 사건이 그와 비슷한 사례였다고 합니다. 해당 사례는 1) 직원의 조작 실수로 잘못된 패치를 적용 2) (고빈도 트레이딩 시스템이기 때문에) 사람이 대응 하기에는 이미 늦음 3) 순식간에 도산 이었던 것으로 기억합니다. 금융권 IT리스크도 무섭지요. 이런 부분을 감정적으로 감당할 수 있는 사람이 많지 않기 때문에 월급이 높은 것일지도 모르겠습니다.
웹개발자여서 요런 생각을 하는 것일지 모르지만욤 이런 종류의 제품은 카나리 배포처럼 5% -> 50% ->100% 이런식으로 적용범위를 조금씩올리는 배포는 힘들까요? 배포과정이 어떻게 될까 단순 궁금증이 생기긴 합니다. 기본지식없이 상상해본 배포과정으로! yum repository에 새로운 버전을 등록하는 순간 전체적으로 적용이 되기때문에 방법이 없는걸까? 생각도 드네요(자신감없음...)
궁금했는데, 내용 올려주셔서 감사합니다! 예전에 알약 랜썸웨어 BSOD도 드라이버 충돌로 인한 비슷한 문제였던 것 같네요 드라이버 충돌을 기술적으로는 API Hooking 중복으로 인한 문제로 이해하면 맞을까요?? 혹시 가능하다면, AV NGAV EPP EDR에 대한 차이를 알려 주실 수 있으실까요? 여러 자료들을 보아도 이 차이가 명확하게 이해가 되질 않아서요 ㅠ
써드파티 앱 잘못이라 ms가 좀 억울한 면이 있긴 하지만 그 여파로 치면 전대미문의 사건은 맞습니다. 그런 대비가 안되어있다는 점에서는 ms 도 자유로울 수 없죠. 자동으로 부팅 성공한 마지막 버전으로 돌리던지 방법이 아주 없진 않았을거 같구요. 해외뉴스도 원인을 잘 모른채로 ms 탓을 하거나 해당업체 지사에서 대응미숙 탓을 하기도 했답니다. 어쩔 수 없다고 생각합니다
이거 안올려주시나 했는데 역시나 올려주셨군요. 잘 보겠습니다~
기대에 부응한 것 같아 다행이네요. :)
오늘도 잘 듣고 갑니다~~
최소한 IT기사 쓰시는 분들은 기술을 알아보고 적을 필요가 있는것 같습니다.
언론사도 장사를 해야 돈을 벌 것이니... 이해 하고자 합니다. 의견 고맙습니다. :)
와 이거 커뮤니티 댓글에 해주먄 좋겠다고 했는데 바로 올라오시는군요!! 하하
오늘도 영상 감사드립니다~
제가 더 고맙습니다. :)
IT관점에서의 기사 설명. 감사히 잘 봤습니다.
좋게 봐주셔서 고맙습니다. :)
설명을 재대로 하는 기사를 찾기 어려웠는데, 잘 설명해주셔서 감사합니다.
좋게 봐주셔서 고맙습니다. :)
업계에서 잔뼈가 굵은 고수의 향기가 아주 진하게 묻어나오는 설명 잘 듣고 바로 구독 박고 갑니다 알찬 영상 감사합니다!
좋게 봐주셔서 고맙습니다. 앞으로도 열심히 영상 올리겠습니다. :)
선생님, 항상 흥미로운 영상 감사합니다!! 일 끝나고 맥주 한잔 마시면서 보면 힐링이 됩니다:)
이 사건에 대해 제 의견도 남기고자 합니다.
보편적으로 발생한 문제 = 일반적인 테스트를 시행했다면 쉽게 발견되었을 문제, 라고 생각합니다. 그렇다면 정상적인 테스트 없이 해당 패치를 배포했을 가능성이 높아 보입니다. 만약 실제로도 그렇다면, 크라우드 스트라이크사의 담당 엔지니어는 도대체 무슨 악과 깡으로 테스트 없이 배포할 생각을 했을까요?!
마이크로소프트사는 많이 억울하겠네요. 괜히 엮여서 고생입니다.
제가 일하던 전 직장은 해외의 유명한 금융회사 였는데, 이곳은 극히 예외적인 경우를 제외하면 절대로 테스트 없이 소프트웨어 변경을 하지 않습니다. 또한 테스트가 끝난 경우에도 절대로 동시에 적용하지는 않으며, 무언가 잘못될 경우 대체하여 투입 할 수 있는 리소스 및 시스템은 항상 준비하여 둡니다. 분산 투자와 마찬가지 이유로요.
델타 항공 이야기가 나왔는데 이 부분은 다른 업계, 다른 회사에서도 진지하게 고려 해 볼 부분이라 생각합니다. 또한 저는 클라우드 100% 의존은 몹시 위험한 발상으로 보고 있습니다.
그리고 이런류의 IT사건은 의외로 흔하다면 흔하지요. 미국 나이트 캐피탈, 한국 한맥 증권 사건을 살펴보는 것도 재미있을 것 같습니다. 비교적 최근에는 도쿄 증권 거래소가 잘못된 IT 인프라 교체로 인해 크게 사고를 친 적도 있지요.
술 한잔 했더니 말이 길어졌습니다. 기회가 되면 리스크 관리에 대해 이야기 해 보고 싶네요ㅎㅎ
제 생각은 조금 다릅니다. 테스트 절차를 시행하지 않았다기 보다 엉뚱한 파일을 배포하는 실수를 했다거나 자신들이 구축한 테스트 환경을 벗어났을 수 있습니다. 개인적으로는 전자 가능성이 높지 않나 추측해봅니다. 직원의 사소한 실수 하나로 조직이 무너지는 경우는 종종 있으니까요.
사실 중요한 것은 왜 재해대책 시스템이 전혀 작동하지 않았는가 입니다. 그 문제는 아예 논의 조차 하지 않는 것으로 보이는데...이 역시 이해할 수 없는 부분입니다. 의견 고맙습니다. :)
@@nullnull_not_eq_null
아! 선생님 말씀을 듣고보니 “엉뚱한 파일을 배포하는 실수”의 가능성이 높아보이네요!!
오래전 읽은 사례라 정확한 기억은 아닐 수 있습니다만, 예시로 든 미국 나이트 캐피탈 사건이 그와 비슷한 사례였다고 합니다.
해당 사례는
1) 직원의 조작 실수로 잘못된 패치를 적용
2) (고빈도 트레이딩 시스템이기 때문에) 사람이 대응 하기에는 이미 늦음
3) 순식간에 도산
이었던 것으로 기억합니다.
금융권 IT리스크도 무섭지요. 이런 부분을 감정적으로 감당할 수 있는 사람이 많지 않기 때문에 월급이 높은 것일지도 모르겠습니다.
영상 감사합니다
좋게 봐주셔서 고맙습니다. :)
다른 정보봤더니 컴퓨터가 무한 리부팅이되서 컴퓨터에 직접 키보드 연결해서 safe boot 한다음 config 파일을 지워줘야 됬다고 하는데 조치가 필요해 보이네요 ㄷㄷ
되서->돼서
커널 드라이버 오류가 발생하면 블루스크린이 떠버리기 때문이지 싶습니다. :)
@@d2341a ㅈㅅ합니다.. 외국살다와서..
부탁드렸던 영상 감사합니다!
답변이 됐으리라 기대해봅니다. :)
정말 궁금했던 사안인데 감사합니다
그러셨군요. 마침 요청이 있어서 올리긴 했는데... 적절했던 것 같네요. 고맙습니다. :)
웹개발자여서 요런 생각을 하는 것일지 모르지만욤
이런 종류의 제품은 카나리 배포처럼 5% -> 50% ->100% 이런식으로 적용범위를 조금씩올리는 배포는 힘들까요?
배포과정이 어떻게 될까 단순 궁금증이 생기긴 합니다.
기본지식없이 상상해본 배포과정으로! yum repository에 새로운 버전을 등록하는 순간 전체적으로 적용이 되기때문에 방법이 없는걸까? 생각도 드네요(자신감없음...)
커널 모듈은 그게 불가능 합니다. 그리고 그 배포라는 것이 윈도우 업데이트와 비슷한 성격이라 보시면 되겠습니다. 참고하시기 바랍니다. :)
궁금했는데, 내용 올려주셔서 감사합니다!
예전에 알약 랜썸웨어 BSOD도 드라이버 충돌로 인한 비슷한 문제였던 것 같네요
드라이버 충돌을 기술적으로는 API Hooking 중복으로 인한 문제로 이해하면 맞을까요??
혹시 가능하다면, AV NGAV EPP EDR에 대한 차이를 알려 주실 수 있으실까요?
여러 자료들을 보아도 이 차이가 명확하게 이해가 되질 않아서요 ㅠ
네, 맞습니다. 드라이버 충돌은 늘 심각한 문제로 이어지지요. 그리고 그 원인이 항상 API hook 때문만은 아닙니다. 물론 다수의 원인이 되기는 하지요. 참고하시기 바랍니다. :)
참, 용어에 대한 해설은...고려해보겠습니다.
오늘의 결론 엔드포인트 보안은 인간이 할 것이 아니다
네, 저는 포기했습니다. ㅠㅠ
써드파티 앱 잘못이라 ms가 좀 억울한 면이 있긴 하지만 그 여파로 치면 전대미문의 사건은 맞습니다.
그런 대비가 안되어있다는 점에서는 ms 도 자유로울 수 없죠. 자동으로 부팅 성공한 마지막 버전으로 돌리던지 방법이 아주 없진 않았을거 같구요.
해외뉴스도 원인을 잘 모른채로 ms 탓을 하거나 해당업체 지사에서 대응미숙 탓을 하기도 했답니다. 어쩔 수 없다고 생각합니다
그 대비의 기준이 참 애매한 측면이 있습니다. 어쨌든 재해대책 시스템이 정상적으로 가동되지 않은 것은 분명해 보입니다. 그 관점에서 책임을 논하는 것이 적절하겠다는 생각을 해봅니다. 좋은 의견 고맙습니다. :)
와... 제목만 보고 ms 장애인줄 알았는데
보안업체 문제였구만
네, 우리나라에서도 몇 번 있었던 일이지요. ㅡㅡ
그날 저희회사 엔지니어분들도 몇백대 서버를 일일히 조치하느라 고생하셨죠....
인공지능 시대가 오더라도...이런 문제는 대응하기가 참 쉽지 않을 것 같습니다. :)
널널한 = 커널이죠 ;; ㅋㅋㅋㅋㅋ
이야기가 그렇게 되는 군요. 피드백 고맙습니다. :)