보안 잘못 구성: 무엇이며 재발 시 감지하는 방법

팀은 벤치마크에 맞춰 시스템을 강화하고, 사용하지 않는 포트를 닫고, 로깅을 켜서 검토를 통과합니다. 그 후 패치가 설정을 초기화하고, 엔지니어가 장애를 해결하기 위해 새벽 2시에 방화벽 규칙을 열었지만 닫지 않으며, 오래된 이미지로 새 서버를 구축합니다. 몇 달 후 환경은 승인된 환경과 전혀 달라 보입니다.

이것은 보안 잘못된 구성입니다. OWASP는 2021년에 다섯 번째, 2021년에는 두 번째로 순위를 매겼으며 2025년에도 계속 순위가 오르고 있습니다. 알려진 모든 취약점을 패치해도 아무도 변경하는 것을 기억하지 못한 설정으로 인해 문이 열려 있을 수 있기 때문입니다.

보안 잘못된 구성: 잘못되었거나 누락되었거나 기본값으로 남겨진 설정

보안 잘못된 구성은 누락되었거나 잘못되었거나 안전하지 않은 기본값으로 설정된 설정으로 인해 발생하는 취약점입니다. 소프트웨어는 설계된 대로 작동합니다. 설정 방식이 이를 노출시킵니다.

취약점은 코드의 결함이며, 공급업체가 패치로 수정합니다. 잘못된 구성은 시스템이 배포되거나 변경된 방식에 대한 결정 또는 그 부재에서 비롯됩니다. 수정은 설정 변경이며, 이를 수행하고 유지하는 것은 귀하 팀의 임무입니다.

오작동 구성은 운영 체제, 데이터베이스, 웹 서버, 클라우드 플랫폼, 네트워크 장치 및 애플리케이션에 있을 수 있습니다. 아무 것도 고장 나지 않고 시스템이 계속 작동하기 때문에 종종 눈에 띄지 않습니다.

서버, 클라우드 및 네트워크 장치에서의 보안 잘못된 구성 사례

이 중 많은 부분이 구성 파일의 한 줄로 귀결됩니다. 다음은 두 가지 일반적인 구성 파일에서 드리프트가 어떻게 나타나는지입니다.

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

두 가지 변형 버전 모두 잘 작동하여 아무도 이를 눈치채지 못합니다. Change Tracker는 이러한 구성 파일을 감시하고 값이 변경되는 순간을 표시할 수 있습니다.

이 중 대부분은 설정 변경만으로 해결됩니다. 대규모 환경에서 이를 찾는 것이 느린 부분입니다.

강화 후에도 잘못된 구성은 계속 다시 발생합니다

설정 오류는 발생하며, 설정 후에 이루어지는 변경도 마찬가지입니다. 두 번째 유형에 대한 기술 용어는 구성 드리프트(configuration drift)로, 승인되고 강화된 상태에서 시스템이 점차 벗어나는 현상을 의미합니다.

패치와 업데이트는 부수 효과로 설정을 변경합니다. 비즈니스가 기다릴 수 없기 때문에 긴급 수정은 정상 프로세스 외부에서 이루어집니다. 동일해야 할 시스템이 서로 다른 시간에 다른 사람이 구축됩니다. 무언가 변경될 때 누가, 언제, 왜 변경했는지에 대한 명확한 기록이 없는 경우가 많습니다.

그래서 일회성 감사는 부족합니다. 감사 시점의 시스템 상태만 보여주며, 다음 날부터 변동이 시작될 수 있습니다. 분기별 또는 연간 검토하는 팀은 항상 이미 오래된 스냅샷을 기반으로 작업합니다.

잘못 구성된 시스템이 초래하는 비용

잘못 구성된 시스템은 공격자가 침입하기 쉽게 만들고 감사자에게는 문제점을 제공합니다. 둘 다 시간과 비용이 듭니다.

잘못된 구성은 데이터를 노출시키고, 공격자가 내부에 들어왔을 때 얻는 접근 권한을 확대하며, 로그가 이를 포착하도록 설정되지 않아 침입을 발견하기 어렵게 만듭니다. 잘못된 설정은 또한 장애를 일으킬 수 있으며, 원인을 추적하는 데 몇 시간이 걸리는데 아무도 무엇이 변경되었는지 알 수 없습니다. PCI DSS, NIST 800-53 및 HIPAA와 같은 프레임워크는 조직이 안전한 구성 표준을 유지하고 시스템이 여전히 이를 준수한다는 증거를 보여줄 것을 기대합니다. 변질된 시스템은 아직 나쁜 일이 발생하지 않았더라도 이 테스트에 실패합니다.

보안 잘못된 구성 찾기 및 수정 4단계

1. 표준부터 시작하세요. 비교할 기준이 없으면 잘못된 구성을 찾을 수 없습니다. 대부분의 조직은 CIS Benchmarks 또는 DISA STIG과 같은 업계 벤치마크를 시작점으로 삼아 환경에 맞게 조정합니다. 일부는 이미 강화하고 신뢰하는 시스템에서 자체 표준을 만듭니다.
2. 모든 시스템을 이에 따라 평가하세요. 서버, 데이터베이스, 클라우드 계정 및 네트워크 장치를 벤치마크와 비교하여 결과를 평가합니다. 중요도에 따라 정렬된 문제 목록을 얻을 수 있습니다.
3. 발견한 문제를 수정하세요. 가장 높은 위험부터 시작하세요. 의도적인 편차인 경우 승인된 예외로 문서화하여 오경보로 돌아오지 않도록 하세요.
4. 변경 사항을 모니터링하세요. 수정 후에도 환경은 계속 변경됩니다. 지속적인 모니터링을 통해 시스템이 승인된 상태에서 벗어날 때 알 수 있어, 다음 감사 때 발견하는 대신 몇 시간 내에 변경된 설정을 수정할 수 있습니다.

맥락 없는 탐지는 경고 소음으로 변합니다

팀이 모니터링을 추가하면 경고가 쏟아지기 시작합니다. 모든 패치, 유지보수 시간, 승인된 업데이트는 변경 이벤트를 생성할 수 있으며, 수백 대의 장치 중에서 팀은 일상적인 변경과 위험한 변경을 구분할 수 없습니다.

구성 파일 변경은 의도하지 않은 경우에만 문제가 됩니다. 차이를 구분하려면 변경된 내용과 승인된 내용을 비교해야 합니다.

폐쇄 루프 변경 제어는 해당 비교를 수행합니다. 승인된 변경 사항은 IT 서비스 관리 시스템에 이미 요청이 존재하는 경우 연결하거나 직접 정의하여 계획된 변경 사항으로 기록됩니다. 시스템에 변경 사항이 나타나면 계획과 비교됩니다. 일치하는 항목은 계획된 것으로 분류되어 방해받지 않습니다. 그 외의 모든 항목은 계획되지 않은 것으로 표시되며, 팀이 조사하는 짧은 목록이 됩니다.

Netwrix Change Tracker를 만나보세요

Netwrix Change Tracker는 시스템을 알려진 표준과 비교하고, 변화가 발생하는 즉시 감지하며, 계획된 변경과 계획되지 않은 변경을 구분합니다.

평가를 위해 Change Tracker는 CIS Benchmarks를 기반으로 한 컴플라이언스 보고서를 포함하며, Netwrix는 CIS 인증 공급업체입니다. 보고서는 Windows, Linux, Unix, 데이터베이스, 네트워크 장치, VMware ESXi 및 Azure, AWS, GCP, Microsoft 365를 포함한 클라우드 플랫폼을 다룹니다. 조직에 자체 빌드 표준이 있는 경우, 모든 장치가 기준 소스로 사용될 수 있으므로 신뢰하는 시스템에서 골드 빌드를 정의하고 나머지를 이에 맞춰 측정할 수 있습니다.

모니터링을 위해 파일, 폴더 및 파일 내용뿐만 아니라 프로세스, 서비스 및 열린 네트워크 포트를 추적합니다. Windows에서는 레지스트리 설정, 설치된 소프트웨어, 로컬 계정, 보안 및 감사 정책도 추적합니다. 수집은 에이전트 유무와 상관없이 작동하며, 소프트웨어를 설치할 수 없는 서버, 어플라이언스 및 장치가 혼합된 환경에서 중요합니다. 모든 변경 사항은 무엇이 언제 변경되었는지 기록되어 문제가 발생했을 때 검색 가능한 기록을 구축할 수 있습니다.

변경 관리에서는 감지된 변경 사항을 계획된 변경 사항과 비교합니다. ServiceNow, BMC Remedy, Cherwell, ManageEngine ServiceDesk Plus, OpenText Service Management 등 ITSM 플랫폼과 통합되어 승인된 요청이 자동으로 계획된 변경으로 전환됩니다. 계획되지 않은 변경은 ServiceNow에서 인시던트를 발생시켜 시스템 소유자가 조사를 진행하도록 합니다.

언제든지 확인할 수 있는 보안 구성을 제공하며, 누군가 변경 사항을 물어볼 때 명확한 답변을 드립니다.