네트워크 리스크를 줄이기 위해 어디서부터 접근해야 할지 모를 수 있다. 엣지 액세스의 모든 리스크를 인지하지 못하면, 리스크를 줄인다고 하더라도
리스크를 줄이는 데 있어 사이버 보안 리더의 역할은 항상 명확해야 하지만, 비즈니스에서 이를 충분히 정의하지 못하는 경우가 많다. 랜섬웨어, 피싱, 소셜 엔지니어링, 악용될 수 있는 수많은 취약점 등 오늘날 비즈니스는 여러 각도에서 공격을 받고 있으며 위험 요소는 도처에 있다.
위협으로 인한 리스크를 제한하기란 어려운 일이다. 리스크를 모니터링하고 완화하기 위해 적절한 리소스를 할당하고, 최신 공격 방법과 벡터에 대해 자신과 팀을 교육하는 것이 적절하다.
하지만 최고의 리스크 방지 계획은 엣지에서 시작된다. 엣지 액세스의 모든 리스크를 인지하지 못하면 리스크를 줄인다고 하더라도 실제로는 줄이는 것이 아닐 수 있다.
우선, 오래됐거나 취약한 VPN 또는 쉽게 공격받을 수 있는 기타 엣지 액세스 도구를 사용해선 안 된다. 원격 액세스 소프트웨어의 보안 문제를 식별하는 프로세스를 마련하고, 즉시 사용 가능한 패치가 없는 취약점이 확인될 경우 원격 액세스를 종료하는 어려운 결정을 내릴 수 있도록 대비해야 한다.
또한 어려운 결정을 전달할 방법을 생각해야 하며, 필요한 경우 경보를 발령하고 접근을 제한하는 이유를 이해관계자가 이해할 수 있도록 해야 한다.
SSL 또는 웹 기반 VPN 제거를 고려
원격 노드를 유지 관리할 역량이 없다면 최소한 원격 액세스 소프트웨어를 유지 관리할 수 있는 메커니즘으로 전환하는 것이 좋다. 윈도우 소프트웨어 업데이트 서비스와 같은 온프레미스 패치 도구에만 액세스할 수 있는 경우에는 원격 자산을 유지 관리하기 위해 서드파티 패치 도구 또는 인튠(Intune)과 같은 클라우드 솔루션에 투자하는 방법도 있다.
하지만 패치로 충분할까? 지난 몇 년 동안 웹 기반 SSL VPN은 원격 액세스를 얻기 위한 표적이었다. 따라서 회사가 원격 액세스를 허용하는 방식, VPN 솔루션이 공격받거나 리스크에 노출된 횟수를 평가하는 것도 고려해야 한다.
노르웨이 국가 사이버 보안 센터(NCSC)는 SSL VPN 또는 웹 기반 VPN의 교체를 권고하기도 했는데, SSL VPN, 웹 기반 VPN 또는 클라이언트 없는 VPN으로 알려진 SSL/TLS(secure socket layer/transport layer security)을 사용하는 VPN 솔루션의 중대한 취약점을 오랫동안 관찰한 뒤 경고를 제공한 경우다.
NSCS는 “취약점이 심각하고 공격자들이 이런 유형의 취약점을 반복적으로 악용하고 있기 때문에 SSL/TLS를 사용하는 보안 원격 액세스 솔루션을 보다 안전한 대안으로 대체할 것을 권장한다. 인터넷 키 교환(IKEv2)을 통한 인터넷 프로토콜 보안(IPsec)을 추천한다. 다른 국가의 당국도 이와 같이 권고하고 있다”라고 밝혔다.
NCSC는 향후 SSL VPN 제품 범주에서 새로운 제로데이 취약점이 발견될 가능성이 있다고 언급하면서 “IKEv2와 함께 IPsec을 사용하는 솔루션에도 취약점은 있을 수 있지만, 이런 기술은 공격 표면이 더 작고 솔루션 구성에서 내결함성 수준이 낮다는 점을 강조할 수 있다”라고 설명했다.
이런 원격 액세스를 재배포하면 조직에 리스크가 발생할 수 있기 때문에 보안 관리자는 알려진 위치 및 지역에 대한 액세스를 제한하도록 적절히 계획해야 한다.
적절하지 않은 곳에 비밀번호 저장 중지
부적절하게 저장된 인증 정보로 인해 보안 침해가 발생했다는 소식을 정기적으로 접한다. 프로젝트를 완수해야 한다는 의욕 때문에 이런 정보를 보호하지 못하는 경우가 많다.
인증 정보가 하드코딩되거나 부적절한 스토리지 플랫폼에 저장되는 방식으로 공유될 경우 공격자는 인증 정보뿐만 아니라 네트워크에도 액세스할 가능성이 있다.
보안 관리자는 액세스해야 하는 자격 증명이 무단 액세스로부터 보호되는 방식에 특히 주의를 기울일 필요가 있다. 모범 사례 프로세스를 활용해 비밀번호를 보호하고 각 사용자에게 적절한 비밀번호와 그에 따른 액세스 권한이 있는지 확인하라. 깃허브(GitHub)는 다음 사항을 권장했다.
1. 비밀번호 관리자를 사용해 15자 이상의 비밀번호를 생성한다.
2. 깃허브에는 자체 비밀번호를 생성한다. 깃허브와 동일한 비밀번호를 다른 곳에서 사용하다 해당 서비스가 손상된 경우, 공격자나 기타 악의적인 행위자가 해당 정보를 사용해 깃허브 계정에 액세스할 수 있다.
3. 개인 계정에 2단계 인증을 설정한다.
4. 선택 사항이지만, 계정에 패스키를 추가해 비밀번호 없이 안전하게 로그인할 수 있다.
5. 잠재적인 공동 작업자와도 비밀번호를 공유하지 않는다. 각 작업자는 깃허브에서 개인 계정을 사용해야 한다.
클라우드 자산에 대한 액세스 권한 검토
최근 마이크소프트조차도 OAuth 자격 증명의 오용으로 피해를 입었다. 클라우드 서비스를 사용할 때는 신뢰할 수 있거나 철저하게 검증한 벤더만 클라우드 서비스에 액세스할 수 있도록 해야 한다. 클라우드 서비스에 추가된 모든 서드파티 응용 프로그램에 대해 일종의 인증 승인 프로세스가 있는지 항상 확인하도록 마이크로소프트 365를 설정해야 한다.
어떤 애플리케이션이 승인됐는지, 그리고 해당 애플리케이션이 여전히 조직에서 사용할 가치가 있는지 정기적으로 검토하는 프로세스를 마련하는 것이 필수다. 컨설턴트를 활용하는 경우에는 어떤 애플리케이션이 양측의 자산에 액세스해야 하는지 논의한다.
또한 마이크로소프트의 악성 및 손상된 애플리케이션 조사를 위한 지침을 검토하고, 사고가 발생하기 전이라 하더라도 현재 사용자 환경에서 단계를 수행할 필요가 있다.
마이크로소프트는 “모든 ID, 사용자, 서비스 주체 및 그래프 데이터 커넥트(Microsoft Graph Data Connect) 애플리케이션의 현재 권한 수준을 인증 포털로 감사해 어떤 ID에 높은 권한이 있는지 파악해야 한다”라고 설명했다.
더 이상 사용되지 않거나 목적에 맞지 않는, 알 수 없는 개체와 ID의 권한을 더 면밀히 조사하는 것은 당연한 일이다. 마이크로소프트는 “ID에는 종종 필요 이상의 권한이 부여될 수 있다. 앱 전용 권한이 있는 앱에 과도한 액세스 권한이 있을 수 있기에 방어자는 주의를 기울여야 한다”라고 조언했다.
* Susan Bradley는 애스크우디닷컴(Askwoody.com), CSO온라인닷컴(CSOonline.com) 등에서 칼럼을 기고하는 전문 칼럼니스트다.
dl-ciokorea@foundryco.com
