사이버 보안의 가장 답답한 법칙 중 하나는 조직이 기술에 얼마나 많은 투자를 했거나 아키텍처가 얼마나 정교한지에 상관없이 일반적으로 기술을 해킹하는 것보다 사람이나 프로세스를 해킹하는 것이 더 쉽다는 것입니다. 멀티팩터 인증(MFA)은 매우 효과적이기 때문에 공격자는 직접 공격하지 않고 다음과 같은 방법을 찾습니다. MFA 회피 다른 비즈니스 계층이나 사용자를 타겟팅하여 환경의 발판을 마련할 수 있습니다.
사이버 범죄자들은 MFA를 회피할 때 "...에서 보낸 것으로 추정되는 사기 이메일, 문자 및 알림을 사용합니다.헬프 데스크 이메일 계정"의 사용자를 타겟팅하려면 프롬프트 폭격 및 MFA 피로 공격에 대응하고 있습니다. 하지만 해커가 전술을 발전시켜 헬프 데스크 자체를 노린다면 어떻게 될까요?
이는 단순한 이론적 문제가 아닙니다. 시저스 엔터테인먼트는 $1500만 사이버 범죄 그룹이 "시스템에 침투하여 혼란을 일으킨" 후입니다. 조직 보고 "아웃소싱 IT 지원 공급업체에 대한 사회공학적 공격"으로 인해 유출이 시작되었다고 밝혔습니다. 작년에 LAPSUS$ "조직의 헬프 데스크에 전화를 걸어 지원 담당자를 설득하여 권한 있는 계정의 자격 증명을 재설정하도록 시도했습니다.
시저스 엔터테인먼트에 대한 공격은 조직이 헬프데스크를 강화해야 하는 이유를 잘 보여줍니다. 하지만 말로는 쉽지만 보안을 최우선으로 하는 운영을 개발하려면 경영진의 지원, 기술 및 직원 투자, 교육 등이 필요합니다. 중요한 것은 최근의 공격 중 일부는 헬프데스크를 표적으로 삼았지만 헬프데스크가 특별히 공격에 취약하거나 안전하지 않거나 위험성이 높은 것은 아니라는 점입니다. 오히려 그 반대입니다. 조직은 다음과 같은 부분에 보안 우선 원칙을 적용해야 합니다. 모든 비즈니스 프로세스. 다음과 같습니다. 모두 위험에 처해 있습니다.
즉, 스캐터드 스파이더와 ALPHV/블랙캣 최근 헬프 데스크가 각광을 받고 있습니다. 따라서 보안 팀과 헬프 데스크가 제로 트러스트 헬프 데스크를 개발하기 위해 취할 수 있는 몇 가지 모범 사례와 질문해야 할 사항을 검토해 보겠습니다.
헬프 데스크(또는 서비스 데스크)는 대부분의 회사에서 IT 환경의 표준적인 부분입니다. 헬프 데스크는 다양한 기능을 수행하지만, 컴퓨터에 로그인할 수 없거나 리소스에 액세스하는 데 문제가 있는 사람이 가장 먼저 연락하는 곳이 되는 경우가 많습니다. 이러한 문제를 해결하기 위해 헬프 데스크는 다음과 같이 상당히 위험도가 높은 작업을 수행할 수 있습니다:
- 비밀번호 재설정하기
- 잠긴 사용자에 대한 MFA 제거하기
- 새 계정 만들기
헬프 데스크 직원은 시스템 전반의 문제를 처리하기 위해 관리 계정을 만들거나 일시적으로 MFA를 완전히 제거하는 등 더 위험한 작업을 수행할 수 있는 시작점이 될 수도 있습니다. 헬프 데스크 직원이 직접 이러한 조치를 취할 수 없더라도 다른 그룹을 위해 티켓을 개설할 수 있을 수도 있습니다.
헬프 데스크는 보안 정책을 일시 중단하거나 우회할 수 있기 때문에 공격자에게 매력적인 표적이 될 수 있습니다. 게다가 조직은 사용자와 고객이 연결성, 생산성, 만족도를 유지하기를 원하기 때문에 위협 행위자가 헬프 데스크 연락처 정보를 쉽게 찾을 수 있습니다.
다행히 헬프 데스크는 상당한 위험을 초래할 수 있지만 보안팀은 ID, 프로세스 문서화, 자동화 및 심층 방어 개발의 우선 순위를 정하여 이러한 위험을 최소화할 수 있습니다.
헬프 데스크에 대해 알아보는 것부터 시작하세요. 누가 헬프 데스크에 근무하나요? 일반적으로 어떤 일을 하나요? What could 무엇을 할까요? 액세스 권한이 있는 항목은 무엇이며 해당 액세스 권한이 필요한 이유는 무엇인가요?
모든 조직은 헬프 데스크가 자사 환경에 얼마나 많은 액세스 권한을 가지고 있는지 물어봐야 합니다. 보안팀은 최소 권한의 개념에 따라 그 답을 정기적으로 검토해야 합니다. 제로 트러스트에 가까워지려면 헬프 데스크는 필요할 때 업무 수행에 필요한 기능에만 액세스할 수 있어야 합니다. 헬프 데스크 직원에게 광범위한 관리 액세스 권한을 부여해서는 안 됩니다.
헬프 데스크의 서비스 카탈로그가 이를 판단하는 좋은 기준이 될 수 있습니다. 지원 담당자는 해당 서비스 및 해당 서비스를 실행하는 데 필요한 액세스 권한만 가져야 합니다. 보안팀은 헬프 데스크 직원이 특히 사용자의 ID 보안 설정을 조정할 수 있는 작업에 대해 필요 이상의 권한을 갖고 있는지 검토해야 하며, 권한을 갖고 있다면 그러한 권한에 대한 적절한 통제가 이루어지고 있는지 확인해야 합니다.
헬프 데스크가 일반적으로 어떤 일을 하는지, 어떤 일을 할 수 있는지 파악했다면 런북과 프로세스 문서를 요청하세요. 문서가 없다면 직접 작성하여 본인 확인을 비롯한 보안 모범 사례를 검토해야 합니다.
또한, 보안팀은 위험도가 높은 ID 작업은 표준 변경 관리 프로세스를 따라야 한다는 점을 강조해야 합니다. 새 페더레이션이나 디렉터리에 새 테넌트를 추가하는 등의 작업은 더 엄격한 프로세스를 따라야 합니다. 누군가 정상적인 프로세스를 벗어나 이러한 고위험 작업을 시작하려고 하면 보안 시스템이 이를 감지하여 보안팀에 경고하고 차단해야 합니다.
헬프 데스크 팀에서 멈추지 마세요. 헬프 데스크는 사용자를 지원할 수 있는 많은 재량권을 가지고 있지만 복잡하거나 위험한 작업을 완료하기 위해 다른 그룹의 도움을 받아야 할 때도 있습니다. 두 개 이상의 그룹이 함께 작업하는 경우에는 모든 팀이 어떤 작업에 두 개 이상의 기능이 필요한지, 누가 요청을 확인하는지, 어떻게 문서화해야 하는지 알고 있어야 합니다.
사이버 범죄자들은 어떤 팀이 어떤 작업을 담당하고 있는지에 대한 가정을 악용합니다. VIP가 관리 요청이 즉시 필요한 새 관리자를 고용했다고 말하는 경우 헬프 데스크는 어떻게 해당 요청을 접수하고, 이를 확인하고, 다른 팀과 조율할까요? 모든 가정을 확인하여 해당 요청이 조직 내부에서 오는 것인지, 그리고 나쁜 사람을 돕고 있는 것은 아닌지 확인해야 합니다.
헬프 데스크 직원은 경영진과 보안 팀으로부터 정해진 프로세스를 따르고, 문서화를 요구하고, 사용자를 확인해야 한다는 말을 들어야 합니다.특히 를 통해 예외적인 요청을 처리하여 안전한 관행을 유지합니다.
헬프 데스크는 보안 팀과 경영진이 자신을 지지하고 있다는 사실을 알아야 합니다. 이는 단순한 기술이나 운영상의 변화가 아니라 리더십이 조직 전체에 걸쳐 배양해야 하는 문화적 가치입니다. 내부 리더, 외부 VIP 또는 위협 행위자가 문제를 해결하거나 일부 액세스 권한을 얻기 위해 '긴급'하게 고객 지원팀에 연락하여 고위험 요청을 할 가능성이 높기 때문입니다.
이러한 상황에서 헬프 데스크 직원이 항상 "아니오"라고 말할 수는 없습니다. 대신 이렇게 말할 수 있는 기술, 프로세스 및 문화를 조성하세요: "네, 그리고 이를 위해 여러분이 해야 할 일은 다음과 같습니다."라고 말할 수 있는 기술과 프로세스 및 문화를 조성하세요. 이러한 단계를 미리 스크립트로 작성하고 추가 단계가 필요할 때 경영진과 보안팀이 헬프 데스크에서 대기할 것임을 알면 침해 예방에 큰 차이를 만들 수 있습니다.
하지만 단순히 하향식 프로세스가 아니라 조직은 다음을 사용해야 합니다. 자동화 수동 프로세스나 VIP의 압력에 대한 노출을 제한하는 것이 합리적일 때입니다. 헬프 데스크는 여전히 예외를 요청하는 전화에 대응하여 발신자를 자동화로 다시 안내하거나 신뢰할 수 있는 승인이 필요한 에스컬레이션 절차를 마련해야 할 수도 있습니다.
위의 모든 단계를 수행했다고 가정해 보겠습니다. 헬프 데스크와 만나 헬프 데스크가 할 수 있는 일을 파악하고, 우선순위를 정할 고위험 작업을 분류하고, 문서를 만들고, 리더십 팀이 사용자에게 불편을 주더라도 조직은 항상 보안의 편에 설 것이라고 일상적으로 설명한다고 가정해 보겠습니다.
다음 질문은 헬프 데스크나 고객 지원팀이 어떻게 신원을 확인할 것인가 하는 것입니다. 지원 보안이 아무리 잘 설계되거나 문서화되어 있어도 팀원 중 누군가가 사용자에게 권한이 없는 요청을 처리하는 경우에는 효과가 없기 때문에 사용자의 신원을 인증하는 것은 절대적으로 중요합니다.
최근 피싱 문제를 해결하기 위한 한 가지 방법으로 시각적 인증이 주목받고 있습니다. 조직은 다음을 검토할 수 있습니다. NIST 800.63A 를 통해 '우수한' 강도 검증에 필요한 기능이 해당 상황에 적합한지 확인합니다. 독립적인 육안 검증에 필요한 기술적 요구 사항과 헬프 데스크가 이 메커니즘을 구현하는 데 필요한 교육을 고려할 때 이 작업은 신중하게 수행해야 합니다. 요청하는 사람을 모르는 원격 헬프 데스크의 경우 시각적 검증은 점점 더 쉽게 이루어지고 있는 딥페이크에 여전히 취약할 수 있습니다. 이러한 문제 때문에 저는 대부분의 상황에서 시각적 인증이 효과적으로 구현될 수 있을지에 대해서는 회의적입니다.
대신 조직은 기존의 심층 방어 접근 방식과 MFA를 사용하여 누군가가 자신이 주장하는 사람이 맞는지 확인할 수 있습니다. 잘 구성된 요청 및 확인 방법은 정의된 이메일이나 지원 포털 로그인과 같은 단일 초기 신뢰 벡터로 시작할 수 있지만, 신뢰할 수 있는 두 번째 시스템을 사용하는 대역 외 연락처와 같은 추가 요소도 통합해야 합니다. 대역 외 연락처를 활용하는 방법에는 다음이 포함될 수 있습니다:
- 관리자 승인: 티켓팅 시스템에서 관리자가 액세스 요청을 승인했는지 체계적으로 확인합니다.
- 관리자(직원의 경우) 또는 등록된 연락처(고객의 경우)에게 전화하여 요청이 유효한지 확인하도록 합니다. 관리자는 일반적으로 대역 외의 방법으로 직원에게 연락할 수 있습니다.
- 서비스 데스크 직원과 요청을 하는 사용자가 전화 회의를 시작합니다. 그런 다음 관리자나 팀원 등 제3자에게 통화에 참여하도록 요청하여 사용자와 요청을 눈으로 확인합니다.
- 승인을 신속하게 처리하기 위해 회사 디렉토리에서 가져온 동료나 어시스턴트로 요청을 대신하여 확인할 수도 있습니다.
어떤 인증 시스템도 뚫릴 수 있지만 고위험 요청을 처리하기 전에 관련 없는 몇 가지 요소를 결합하여 신원을 확인하면 헬프 데스크가 대부분의 피싱 시도에 대해 강화되는 데 도움이 될 수 있습니다. 예를 들어 Active Directory, 이메일용 M365 및 Teams를 사용하는 Microsoft 매장의 경우 가장 강력한 MFA 접근 방식을 원한다면 서로 얽혀 있는 이러한 요소들을 결합하지 않을 수도 있습니다.
이와 같은 소셜 엔지니어링 공격으로부터 헬프 데스크 및 기타 비즈니스 운영을 강화하는 또 다른 방법은 신원 증명을 사용하는 것입니다. 신원 증명에 대한 자세한 내용은 곧 이 공간을 통해 알려드리겠습니다.
