HEIST는 위험인가 위협인가?

보안 전문가는 위험과 위협의 차이를 이해하고 그에 따라 조치를 취하는 업무를 맡습니다. 일반인(대부분의 사람들)에게는 둘 사이의 차이가 존재하지 않는 것처럼 보일 수도 있습니다. 결국, 의미적으로 동등하지 않나요? 취약점과 DDoS 공격, 최신 제로데이 익스플로잇을 설명하기 위해 이 두 단어를 서로 바꿔 사용하지 않나요?

그럴 수도 있겠지만, 보안 전문가들은 종종 그보다 훨씬 더 정확합니다. 그렇지 않으면 방어선을 무너뜨리는 데 사용되는 도구, 기법, 기술의 증가하는 비축량에 맞서 디지털 전쟁을 벌이는 동안 예산이 모든 IT를 앞지르기 때문입니다. 모든 위협이 동일한 위험을 수반하는 것은 아니기 때문입니다.

위험은 발생 가능성과 악용 시의 영향 등 여러 요소를 포함하는 계산된 측정값입니다. 우리 모두는 오늘날 도로를 건너다가 버스에 치여 끔찍한 결과를 겪을 수 있다는 사실을 알고 있지만, 그런 일이 일어날 가능성은 너무 낮아서 우리 중 대부분은 그것을 매우 낮은 위험으로 간주합니다(위험 측정기에 측정값이 표시된다면 말이죠). 반대로, 위스콘신의 한겨울에 밑창이 없는 3인치 힐을 신으면 불리한 결과를 초래할 수 있는 넘어짐 위험이 높기 때문에 저는 개인적으로 겨울철에 그 위험이 매우 높다고 생각합니다.

그건 위험해요.

위협은 또 다른 문제입니다. 날씨나 버스 노선, 공격자가 오늘 우리 웹사이트에 볼륨 공격을 가하기로 한 결정과 같이 우리가 통제할 수 없는 다른 것들도 있습니다.

보안 전문가와 조직의 목표 중 하나는 위협을 완화하고 악용 가능성을 줄여 위험을 최소화하는 것입니다. 영하 20도이고 차도가 얼음으로 뒤덮여 있으면 나는 평평하고 잘 굽은 부츠를 신습니다. 위협은 완화되지만 제거되지는 않으므로 위험이 감소합니다.  만약 새로운 취약점이 갑자기 발견된다면, 그 새로운 위협이 우리 조직에 어떤 위험을 초래하는지 결정해야 합니다.

사실, 이는 위험을 평가하는 방법론으로 너무나 널리 받아들여져 업계에서는 이를 수학적으로 다음과 같이 설명합니다.

A(세트) + V(취약성) + T(위험) = R(isk)

이를 통해 개별 조직은 비즈니스 요구 사항 및 위험 허용 범위에 따라 개별 요인의 가중치를 적용할 수 있을 뿐만 아니라 일관되게 행동할 수 있습니다. 이를 통해 새로운 취약점이 발표되었을 때 당황하고 무작정 반응하는 것을 방지할 수 있으며, 특히 평가된 위험이 조직의 허용 범위 내에 있는 경우 더욱 그렇습니다.

그렇다면 HEIST는 어떤가요?

여기서 HEIST라는 것이 등장하게 되었는데, 이는 TCP-Windows를 통해 HTTP 암호화된 정보를 훔칠 수 있음을 의미합니다. HEIST는 발음하기 훨씬 쉽고, 마치 미션 임파서블과 비슷한 느낌이 들지 않나요? 이 취약점은 BlackHat 에서 발표되었으며 현재도 Ars Technica 와 Engadget 의 기사를 통해 인터넷에 퍼지고 있습니다. 아직까지 야생에서 목격된 적은 없습니다. 이것은 간단히 악용할 수 있는 취약점이 아니며, 우리 연구원을 포함한 연구자들은 HEIST를 악용하는 것이 간단한 일이 아니라는 점에 주목합니다. 이는 브라우저 API 동작(응답 시간을 조절할 수 있는 브라우저 API와 TCP가 정상적으로 작동하는 방식을 관찰함), 웹 애플리케이션 동작, 콘텐츠 압축, TCP, 암호화를 결합하는 복잡한 사이드채널 공격입니다.

여러 요청을 완료해야 하는 경우 이 공격은 네트워크에 부담을 줄 수 있지만 "노이즈가 많은" 범주에 더 적합합니다. 두 작품 모두 눈에 띄고 싶지 않은 나쁜 배우들에게는 매력적이지 않습니다. 하지만 이것이 성공적으로 악용된다면 공격자는 이를 BREACH 또는 CRIME 과 결합하여 페이로드를 해독하고 디지털 잭팟을 터뜨릴 수 있으며, 민감한(아마도 중요한) 개인 및 기업 데이터를 노출시킬 수 있습니다. 그런 경우, 개인 식별 정보(PII)를 얻는 데 성공하면 아무리 시끄러워도 상관없을 것입니다. PII는 디지털 잭팟입니다.

이것은 위협입니다. 이는 데이터를 빼내는 데 사용될 수 있습니다. 그것을 침해라고 부르는데, 매우 나쁜 일입니다™. 문제는, 이 위협이 언제 실제로 위험으로 발전하는가입니다.

글쎄요, 오늘(정확히 말하면 제가 이 글을 썼을 당시) 이런 위협은 실존적 위협이 아니었습니다. 즉, 야외에서는 본 적이 없다는 뜻입니다. 하지만 그렇다고 해서 야생에 존재하지 않는다는 것은 아니고, 단지 야생에서 본 적이 없다는 것을 의미할 뿐입니다. 아직. 오늘. 지금 바로.

아직 머리가 돌지 않아? 이제 보안 전문가들이 항상 멍한 표정을 짓는 이유를 알았을 겁니다. 그들은 항상 이런 종류의 사고 과정과 의사 결정을 관리해야 하기 때문입니다. 

그래서 문제는 이 위협이 실존적 위협이 된다면 어떤 위험이 있는가입니다. 이에 답하려면 취약점이 악용될 경우 어떤 영향이 미칠지 판단해야 합니다. 만약 누군가가 여러분의 앱이나 사이트에서 데이터를 빼내는 데 성공한다면, 어떤 영향이 있을까요? 비용은 얼마입니까? 브랜드 영향을 포함하는 것을 잊지 마세요. 이는 (점점 더 복잡해지는) 방정식의 일부입니다. 완화 비용도 마찬가지입니다. 완화 비용이 높을 때와 영향이 상대적으로 낮은 해결책일 때 방정식은 달라집니다. 위협을 완화하기 위해 단 하나의 설정만 조정하더라도 데이터 센터(및 클라우드)의 모든 웹 서버를 건드려야 한다면 존재적으로 위협적일 수 있는 것에 많은 시간(그리고 그에 따른 비용)이 필요합니다. 위험이 낮다면, 당신은 그 소년이 "늑대다"라고 소리쳤다고 해서 급히 대처하기보다는 이해할 만한 "기다려보자"는 태도를 취할 가능성이 높습니다.

비용 측면에서 완화책의 영향이 상대적으로 낮은 경우, 예를 들어 공격자를 혼란스럽게 하여 반환되는 데이터의 크기를 변경하고 이로 인해 HEIST를 수행하기 어렵게 만드는 간단한 스크립트인 경우 계속 진행하여 완화책을 구현하는 것을 고려할 수 있습니다. 결국, 위험을 더욱 낮추는 데 드는 비용은 최소한이었고, 해당 HEIST가 미래에 실행된다면 그에 따른 결과보다 훨씬 적을 가능성이 매우 큽니다.

지속적인 (재)균형화 행위

현실적으로 보안은 위협을 완화하여 위험을 최소화하기 위한 끊임없는 싸움이며, 대부분 IT 조직이 겪고 있는 정치적 지뢰밭을 헤쳐 나가는 것입니다. 보안 전문가는 IT가 기능별로 분산되어 있기 때문에 위험 가능성이 변동하는 위협에 대해 간단한 완화책을 구현하려는 노력조차 하지 않는 경우가 많습니다.

그들은 위협이 커져서 대응해야 할 때까지 기다릴 뿐, 위협을 사전에 완화하려고 하지 않습니다. 예를 들어, 지난 2년 동안 가장 많이 화제가 된 공격 중 대부분은 애플리케이션 중심이었습니다. 이러한 문제를 완화하려면 솔루션을 애플리케이션보다 상류인 데이터 경로에 배포해야 합니다. 그렇게 하는 가장 효율적이고 효과적인 위치는 애플리케이션을 확장 및 제공을 위해 최종적으로 집계하는 지점이기 때문입니다. 하지만 그러한 전략적 통제 지점은 보안 팀이 아닌 애플리케이션 제공 팀에서 관리합니다. 이런 위협을 조기에 완화하는 데 필요한 노력은 위험보다 더 큽니다. 두 그룹이 중간에서 만날 수 있는 능력은 조직에 끊임없는 과제로 남아 있기 때문에 애플리케이션 계층에서 사전에 위험을 줄이고 위협을 완화하는 일은 불가능합니다.

현재 HEIST는 대부분의 조직에서 위험도가 낮은 것으로 간주될 가능성이 높습니다. 하지만 오해하지 마십시오. 그것은 위협이며, 따라서 그것이 실행되기 전에 우리 모두에게 그 존재가 알려져 있으므로 지금 고려할 가치가 있습니다. HEIST에 대한 이러한 완화책과 같은 "서버리스" 보안 솔루션을 위협이 실존적이 되고 악용 위험이 모든 사람을 비용이 많이 드는 활동과 구현에 열광하게 만들기 전에 배포할 수 있도록 교차 조정이 필요합니다.