산업제어시스템(ICS)의 일반 방화벽 정책

심층 방어 구조가 배치되면 방화벽을 통해 허용되는 정확한 트래픽을 결정하는 작업이 시작된다. 비즈니스 수요에 절대적으로 필요한 트래픽을 제외한 모두를 거부하도록 방화벽을 구성하는 것은 모든 조직의 기본 전제이지만, 실제로는 쉽지가 않다. "비즈니스에 절대적으로 필요한"의 정확한 의미는 무엇이며, 해당 트래픽을 통과시키는 경우 보안 영향은 무엇인가?

예를 들어, 대부분의 조직에서 많은 데이터 이력 관리 장치(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 접근

When installing a single two-port firewall without a DMZ for shared servers (i.e., the architecture described in Section 5.5.2), particular care needs to be taken with the rule design. At a minimum, all rules should be stateful rules that are both IP address and port (application) specific. The address portion of the rules should restrict incoming traffic to a very small set of shared devices (e.g., the data historian) on the control network from a controlled set of addresses on the corporate network. Allowing any IP addresses on the corporate network to access servers inside the control network is not recommended. In addition, the allowed ports should be carefully restricted to relatively secure protocols such as Hypertext Transfer Protocol Secure (HTTPS). Allowing HTTP, FTP, or other unsecured protocols to cross the firewall is a security risk due to the potential for traffic sniffing and modification. Rules should be added to deny hosts outside the control network from initiating connections with hosts on the control network. Rules should only allow devices internal to the control network the ability to establish connections outside the control network.

On the other hand, if the DMZ architecture is being used, then it is possible to configure the system so that no traffic will go directly between the corporate network and the control network. With a few special exceptions (noted below), all traffic from either side can terminate at the servers in the DMZ. This allows more flexibility in the protocols allowed through the firewall. For example, Modbus/TCP might be used to communicate from the PLCs to the data historian, while HTTP might be used for communication between the historian and enterprise clients. Both protocols are inherently insecure, yet in this case they can be used safely because neither actually crosses between the two networks. An extension to this concept is the idea of using “disjoint”

protocols in all control network to corporate network communications. That is, if a protocol is allowed between the control network and DMZ, then it is explicitly not allowed between the DMZ and corporate network. This design greatly reduces the chance of a worm such as Slammer actually making its way into the control network, because the worm would have to use two different exploits over two different protocols.

공유 서버에 경계네트워크구간(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가지의 서로 다른 침입 시도를 해야 하기 때문에 이 설계는 침투의 가능성을 크게 줄인다.

One area of considerable variation in practice is the control of outbound traffic from the control network, which could represent a significant risk if unmanaged. One example is Trojan horse software that uses HTTP tunneling to exploit poorly defined outbound rules. Thus, it is important that outbound rules be as stringent as inbound rules.

Example outbound rules include:

< Outbound traffic through the control network firewall should be limited to essential communications only and should be limited to authorized traffic originating from DMZ servers.

< All outbound traffic from the control network to the corporate network should be source and destination-restricted by service and port.

In addition to these rules, the firewall should be configured with outbound filtering to stop forged IP packets from leaving the control network or the DMZ. In practice this is achieved by checking the source IP addresses of outgoing packets against the firewall’s respective network interface address. The intent is to prevent the control network from being the source of spoofed (i.e., forged) communications, which are often used in DoS attacks. Thus, the firewalls should be configured to forward IP packets only if those packets have a correct source IP address for the control network or DMZ networks.

Finally, Internet access by devices on the control network should be strongly discouraged.

In summary, the following should be considered as recommended practice for general firewall rule sets:

< The base rule set should be deny all, permit none.

< Ports and services between the control network environment and the corporate network should be enabled and permissions granted on a specific case-by-case basis.

There should be a documented business justification with risk analysis and a responsible person for each permitted incoming or outgoing data flow.

< All “permit” rules should be both IP address and TCP/UDP port specific, and stateful if appropriate.

< All rules should restrict traffic to a specific IP address or range of addresses.

실제로 상당한 변화의 한 영역은 관리되지 않는 경우 상당한 위험을 나타낼 수 있는 네트워크의 발신 트래픽 제어이다. 한 가지의 예는 HTTP 터널링을 이용하여 제대로 정의되지 않은 발신 규칙을 악용하는 트로이 목마 소프트웨어이다. 따라서 발신 규칙이 착신 규칙만큼 엄격한 것이 중요하다.

발신 규칙의 예는 다음과 같다.

n 제어 네트워크 방화벽을 통한 발신 트래픽은 필수 통신에만 제한되어야 하며, 경계네트워크구간(DMZ) 서버에서 발생하는 인가된 트래픽에 제한되어야 한다.

n 제어 네트워크에서 업무 네트워크로 향하는 모든 발신 트래픽은 서비스 및 포트별로 근원지 및 목적지가 한정되어야 한다.

이러한 규칙에 더불어, 방화벽은 제어 네트워크 또는

경계네트워크구간(DMZ)을 떠나는 위조된 IP 패킷을 정지시키기 위해 발신 필터링과 함께 구성되어야 한다. 실제로 이것은 방화벽의 각각의 네트워크 인터페이스 주소에 대하여 발신 패킷의 근원지 IP 주소를 확인하여 이루어진다. 의도는 제어 네트워크가 서비스 거부(DoS) 공격에서 종종 사용되는 스푸핑(즉, 위조된) 통신의 근원지가 되는 것을 막기 위한 것이다.

따라서 제어 네트워크 또는 경계네트워크구간(DMZ) 네트워크에 대한 올바른 근원지 IP 주소가 IP 패킷에 있는 경우에만 방화벽이 해당 패킷을 포워딩하도록 구성해야 한다. 마지막으로, 제어 네트워크의 장치에 의한 인터넷 접근은 절대로 피해야 한다.

요약하면, 다음 사항을 일반 방화벽 룰셋에 대한 권장 사례로서 고려해야 한다.

n 기본 룰셋은 모두 거부 및 아무것도 허용하지 않는 것이다.

n 제어 네트워크 환경 및 업무 네트워크 사이의 포트 및 서비스는 특정 사례별로 활성화되고 허가되어야 한다. 위험 분석과 사업 타당성 문서 및 허용되는 각각의 수신 또는 발신 데이터 흐름에 대한 담당자가 있어야 한다.

n 모두 “허용” 규칙은 IP 주소 및 TCP/UDP 포트 모두에 대해 구체적이어야 하며, 적절한 경우 상태 기반이어야 한다.

n 모든 규칙은 트래픽을 특정 IP 주소 또는 주소의 범위에 한정해야 한다.

< Traffic should be prevented from transiting directly from the control network to the corporate network. All traffic should terminate in the DMZ.

< Any protocol allowed between the control network and DMZ should explicitly NOT be allowed between the DMZ and corporate networks (and vice-versa).

< All outbound traffic from the control network to the corporate network should be source and destination-restricted by service and port.

< Outbound packets from the control network or DMZ should be allowed only if those packets have a correct source IP address that is assigned to the control network or DMZ devices.

< Control network devices should not be allowed to access the Internet.

< Control networks should not be directly connected to the Internet, even if protected via a firewall.

< All firewall management traffic should be carried on either a separate, secured management network (e.g., out of band) or over an encrypted network with multi-factor authentication. Traffic should also be restricted by IP address to specific management stations.

< All firewall policies should be tested periodically.

< All firewalls should be backed up immediately prior to commissioning.

These should be considered only as guidelines. A careful assessment of each control environment is required before implementing any firewall rule sets.

5.8 Recommended Firewall Rules for Specific Services

Beside the general rules described above, it is difficult to outline all-purpose rules for specific protocols. The needs and recommended practices vary significantly between industries for any given protocol and should be analyzed on an organization-by-organization basis. The Industrial Automation Open Networking Association (IAONA) offers a template for conducting such an analysis [37], assessing each of the protocols commonly found in industrial environments in terms of function, security risk, worst case impact, and suggested measures. Some of the key points from the IAONA document are summarized in this section. The reader is advised to consult this document directly when developing rule sets.

n 트래픽이 제어 네트워크에서 업무 네트워크로 곧장 경유하는 것은 방지되어야 한다. 모든 트래픽은 경계네트워크구간(DMZ) 내에서 종료되어야 한다.

n 제어 네트워크 및 경계네트워크구간(DMZ) 사이에서 허용되는 모든 프로토콜은 경계네트워크구간(DMZ) 및 업무 네트워크 사이에서 명백히 허용되어서는 안 된다(그 반대도 같음).

n 제어 네트워크에서 업무 네트워크로 향하는 모든 발신 트래픽은 서비스 및 포트에 의해 근원지 및 목적지가 한정되어야 한다.

n 제어 네트워크 또는 경계네트워크구간(DMZ)에서 시작되는 발신 패킷은 해당 패킷에 제어 네트워크 또는 경계네트워크구간(DMZ) 장치에 할당된 올바른 근원지 IP 주소가 있는 경우에만 허용되어야 한다.

n 제어 네트워크 장치는 인터넷에 접속하도록 허용되어서는 안 된다.

n 제어 네트워크는 방화벽을 통해 보호되더라도 인터넷에 직접 연결되어서는 안 된다.

n 모든 방화벽 관리 트래픽은 별도의 보안 관리 네트워크(예: 대역외) 또는 다원적 인증의 암호화된 네트워크를 통해서 수행되어야 한다. 또한 트래픽은 IP 주소에 의해 특정 관리 기지국에 한정되어야 한다.

n 모든 방화벽 정책은 주기적으로 시험해야 한다.

n 모든 방화벽은 시운전 직전에 백업해야 한다.

이러한 것은 가이드로만 고려되어야 한다. 모든 방화벽 룰셋을 구현하기 전에 각 제어 환경에 대한 신중한 평가가 필수적이다.