심층 방어 구조가 배치되면 방화벽을 통해 허용되는 정확한 트래픽을 결정하는 작업이 시작된다. 비즈니스 수요에 절대적으로 필요한 트래픽을 제외한 모두를 거부하도록 방화벽을 구성하는 것은 모든 조직의 기본 전제이지만, 실제로는 쉽지가 않다. "비즈니스에 절대적으로 필요한"의 정확한 의미는 무엇이며, 해당 트래픽을 통과시키는 경우 보안 영향은 무엇인가?
예를 들어, 대부분의 조직에서 많은 데이터 이력 관리 장치(Data Historians) 서버에 대해 비즈니스에 필요한 데로 방화벽을 통한 SQL 트래픽을 허용하는 것을 고려했다. 안타깝게도, SQL 취약성도 슬래머웜의 표적이 되었다[표 C-8.
적대적 사건 사례]. 업계에서 사용되는 많은 중요한 프로토콜(예: HTTP, FTP, OPC/DCOM, 이더넷/IP 및 Modbus/TCP)에는 상당한 보안 취약점이 있다.
이 절의 나머지 자료는 국가기반보호센터(CPNI)의 감시 제어 및 데이터 수집(SCADA) 및 공정제어 네트워크에 대한 방화벽 배치: 우수 사례 가이드(Firewall Deployment for SCADA and Process Control Networks:
Good Practice Guide)에서 발췌한 일부 핵심 요점을 요약한 것이다[35].
외부 VPN 접근
공유 서버에 경계네트워크구간(DMZ) 없이 단일 2포트 방화벽을 설치하는 경우(즉, 제5.5.2절에 설명된 구조), 규칙 설계에 특별한 주의를 기울여야 한다.
최소한, 모든 규칙은 IP 주소 및 포트(응용 프로그램) 모두에 구체적인 상태 기반 규칙이어야 한다. 규칙의 주소 부분은 수신 트래픽을 업무 네트워크의 통제된 일련의 주소로부터 제어 네트워크의 매우 작은 일련의 공유 장치(예:
데이터 이력 관리 장치(Data Historians))로 제한해야 한다. 업무 네트워크의 IP 주소로 제어 네트워크 내부의 서버에 접근하는 것을 허용하는 것은 좋지 않다. 추가로, 허용 포트는 하이퍼텍스트 전송 프로토콜 보안(HTTPS) 등의 상대적으로 안전한 프로토콜로 신중하게 제한해야 한다. HTTP, FTP 또는 기타 보안이 보장되지 않는 프로토콜이 방화벽을 통과하도록 허용하는 것은 트래픽 스니핑 및 수정에 대한 가능성 때문에 보안이 위험해진다. 제어 네트워크 외부의 호스트가 제어 네트워크의 호스트와 연결을 시작하는 것을 거부하는 규칙을 추가해야 한다. 규칙에서는 제어 네트워크 내부 장치만이 제어 네트워크 외부의 연결을 설정할 수 있는 기능을 허용해야 한다.
반면에, 경계네트워크구간(DMZ) 구조가 사용되고 있는 경우, 어떠한 트래픽도 업무 네트워크와 제어 네트워크 사이를 곧장 통과할 수 없도록 시스템을 구성할 수 있다. 아래에 명시된 몇 가지 특별한 예외를 제외하고 양측의 모든 트래픽은 경계네트워크구간(DMZ)의 서버에서 종료할 수 있다. 이를 통해 방화벽에서 허용되는 프로토콜에 더 많은 유연성을 줄 수 있다. 예를 들어, HTTP는 이력 관리 장치(Historians)와 기업 클라이언트 사이의 통신에 사용되는 반면, Modbus/TCP는 프로그래머블 로직 컨트롤러(PLC)에서 데이터 이력 관리 장치(Data Historians)으로의 통신에 사용될 수 있을 것이다. 두 프로토콜은 본질적으로 불안정하지만, 이 경우에는 실제로 그 어느 쪽도 두 네트워크 사이를 가로지르지 않기 때문에 안전하게 사용될 수 있다. 이 개념에서 확장된 아이디어는 업무 네트워크 통신에 대해 모든 제어 네트워크에서 “분리된” 프로토콜을 사용하는 것이다. 즉, 프로토콜이 제어 네트워크와 경계네트워크구간(DMZ) 사이에서 허용되는 경우, 경계네트워크구간(DMZ)과 업무 네트워크 사이에서는 명백히 허용되지 않는 것이다. 실제로 제어 네트워크에 침투하는 슬래머와 같은 웜은 2가지의 서로 다른 프로토콜에 대해 2가지의 서로 다른 침입 시도를 해야 하기 때문에 이 설계는 침투의 가능성을 크게 줄인다.
실제로 상당한 변화의 한 영역은 관리되지 않는 경우 상당한 위험을 나타낼 수 있는 네트워크의 발신 트래픽 제어이다. 한 가지의 예는 HTTP 터널링을 이용하여 제대로 정의되지 않은 발신 규칙을 악용하는 트로이 목마 소프트웨어이다. 따라서 발신 규칙이 착신 규칙만큼 엄격한 것이 중요하다.
발신 규칙의 예는 다음과 같다.
n 제어 네트워크 방화벽을 통한 발신 트래픽은 필수 통신에만 제한되어야 하며, 경계네트워크구간(DMZ) 서버에서 발생하는 인가된 트래픽에 제한되어야 한다.
n 제어 네트워크에서 업무 네트워크로 향하는 모든 발신 트래픽은 서비스 및 포트별로 근원지 및 목적지가 한정되어야 한다.
이러한 규칙에 더불어, 방화벽은 제어 네트워크 또는 경계네트워크구간(DMZ)을 떠나는 위조된 IP 패킷을 정지시키기 위해 발신 필터링과 함께 구성되어야 한다. 실제로 이것은 방화벽의 각각의 네트워크 인터페이스 주소에 대하여 발신 패킷의 근원지 IP 주소를 확인하여 이루어진다. 의도는 제어 네트워크가 서비스 거부(DoS) 공격에서 종종 사용되는 스푸핑(즉, 위조된) 통신의 근원지가 되는 것을 막기 위한 것이다.
따라서 제어 네트워크 또는 경계네트워크구간(DMZ) 네트워크에 대한 올바른 근원지 IP 주소가 IP 패킷에 있는 경우에만 방화벽이 해당 패킷을 포워딩하도록 구성해야 한다. 마지막으로, 제어 네트워크의 장치에 의한 인터넷 접근은 절대로 피해야 한다.
요약하면, 다음 사항을 일반 방화벽 룰셋에 대한 권장 사례로서 고려해야 한다.
n 기본 룰셋은 모두 거부 및 아무것도 허용하지 않는 것이다.
n 제어 네트워크 환경 및 업무 네트워크 사이의 포트 및 서비스는 특정 사례별로 활성화되고 허가되어야 한다. 위험 분석과 사업 타당성 문서 및 허용되는 각각의 수신 또는 발신 데이터 흐름에 대한 담당자가 있어야 한다.
n 모두 “허용” 규칙은 IP 주소 및 TCP/UDP 포트 모두에 대해 구체적이어야 하며, 적절한 경우 상태 기반이어야 한다.
n 모든 규칙은 트래픽을 특정 IP 주소 또는 주소의 범위에 한정해야 한다.
n 트래픽이 제어 네트워크에서 업무 네트워크로 곧장 경유하는 것은 방지되어야 한다. 모든 트래픽은 경계네트워크구간(DMZ) 내에서 종료되어야 한다.
n 제어 네트워크 및 경계네트워크구간(DMZ) 사이에서 허용되는 모든 프로토콜은 경계네트워크구간(DMZ) 및 업무 네트워크 사이에서 명백히 허용되어서는 안 된다(그 반대도 같음).
n 제어 네트워크에서 업무 네트워크로 향하는 모든 발신 트래픽은 서비스 및 포트에 의해 근원지 및 목적지가 한정되어야 한다.
n 제어 네트워크 또는 경계네트워크구간(DMZ)에서 시작되는 발신 패킷은 해당 패킷에 제어 네트워크 또는 경계네트워크구간(DMZ) 장치에 할당된 올바른 근원지 IP 주소가 있는 경우에만 허용되어야 한다.
n 제어 네트워크 장치는 인터넷에 접속하도록 허용되어서는 안 된다.
n 제어 네트워크는 방화벽을 통해 보호되더라도 인터넷에 직접 연결되어서는 안 된다.
n 모든 방화벽 관리 트래픽은 별도의 보안 관리 네트워크(예: 대역외) 또는 다원적 인증의 암호화된 네트워크를 통해서 수행되어야 한다. 또한 트래픽은 IP 주소에 의해 특정 관리 기지국에 한정되어야 한다.
n 모든 방화벽 정책은 주기적으로 시험해야 한다.
n 모든 방화벽은 시운전 직전에 백업해야 한다.
이러한 것은 가이드로만 고려되어야 한다. 모든 방화벽 룰셋을 구현하기 전에 각 제어 환경에 대한 신중한 평가가 필수적이다.