Unified Threat Management

Supervisory Control and Data Acquisition

Jack Wiles , in Techno Security's Guide to Securing SCADA, 2008

Unified Threat Management (UTM)

Unified Threat Management is the latest and most innovative development in firewalling. According to IDC, a leading analyst firm, UTM security appliances unify and integrate multiple security features onto a single hardware platform, including network firewall capabilities, network intrusion detection and prevention, and gateway anti-virus. Some UTM offerings go further, incorporating an anti-spam and URL filtering capability on a hardened operating system as well. The UTM segment is the fastest growing segment of the firewall market.

Reasons exist even beyond convenience and practicality for integrating multiple threat protection applications into the same appliance and under the same interface. Many modern attacks today are blended attacks, which do not utilize any one-attack vector exclusively. For example, a blended attack may target multiple protocols, such as e-mail (SMTP) and the Web (HTTP), and it may do this by first sending out an e-mail, (which in itself may not contain any malware) that then tricks the recipient into clicking a Web link. The recipient is then taken to an infected site, where the malware is downloaded onto the computer. Mitigation of this sort of attack can take place either in the e-mail messaging protection (anti-spam) application, which would recognize the nature of the attack, or in the second stage, when the user attempts to go to the infected Web site, it would be blocked by the URL filter.

The addition of URL filtering is an important part of UTM that is often not included by other UTM vendors. URL filtering is often a first line of defense, especially against zero-hour threats. In addition, spam has also grown into a complicated and dangerous threat, and it is imperative to reduce the risk of spam with a best-of-breed anti-spam capability integrated into the UTM appliance.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492829000026

Introduction to UTM (Unified Threat Management)

Kenneth Tam , ... Josh More , in UTM Security with Fortinet, 2013

The History of the Unified Threat Management (UTM) Concept

Unified Threat Management is a concept that was used for the first time in a report 5 issued by IDC in 2004 and called "Worldwide Threat Management Security Appliances 2004–2008 Forecast and 2003 Vendor Shares: The Rise of the Unified Threat Management Security Appliance." This report, signed by Charles J. Kolodgy as author, mentioned that UTM was a new category of security appliances and that it was necessary to have at least the functionality of a firewall, a network intrusion prevention system, and a gateway Antivirus to be part of this security appliance category. However, even though the term was first mentioned at this point, the reality is that it actually described what it was already being done by some companies, especially Fortinet, which was already shipping a firewall that included IPS and Antivirus, alongside other functionality.

Fortinet was founded in 2000 6 by Ken and Michael Xie, two brothers that already had a history of innovation: Ken Xie was the previous Founder, President, and CEO of NetScreen, a firm that under his leadership pioneered the ASIC-accelerated security concept, overcoming the performance issues that software-based solutions had shown at the time. Michael Xie is a former Vice President of Engineering for ServGate and Software Director and Architect for NetScreen, 7 and also holder of several US patents 8 in the fields of Network and Computer Security. The original name of the company when it was founded on November 2000 was "Appligation, Inc," which was later changed to "ApSecure" on December of the same year. Later, the name was once again changed (this time for good) to Fortinet, 9 which comes from the combination of two words that symbolize what the company delivers with its technologies: Fortified Networks. The name was decided in an internal company competition.

From its inception, Fortinet had a vision to deliver-enhanced performance and drive consolidation into the Content Security market, developing products and services to provide broad, integrated, and high-performance protection against dynamic security threats, while simplifying the IT security infrastructure. So, the idea was to provide high-performance technology that was secure, consolidated, and simple to deploy and manage. While this concept was relatively easy to understand and a powerful business and technology proposition, it was contrary to what everybody else had been preaching at the time, and this posed some difficulties since the concept was not truly understood initially. Let's see why.

Around year 2000 when Fortinet was born, the biggest organizations with presence on the Internet already had some security solutions deployed: firewalls, IPSec VPNs, Intrusion Detection Systems, Web Content Filters. In the next few years, the same organizations were pushed to purchase new security elements such as SSL VPNs, AntiSpam, Intrusion Prevention Systems, AntiSpyware, and a whole set of additional solutions. While the complexity and cost of this approach increased, this was the accepted status quo: since most (if not all) organizations had all these technologies and operated that way, it was accepted that other approaches might be risky. Since the UTM concept was born at a time where people already had purchased some network security components that were working apparently fine, it faced fierce opposition. We say "apparently fine" since despite having all these security components, organizations didn't stop having issues: security technology wasn't making things easier at all and wasn't responding to the challenge of bringing more security to the environments where it was deployed.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597497473000016

Foreword

In UTM Security with Fortinet, 2013

Today UTM is a multi-billion dollar market and is growing rapidly. Fortinet is proud to be the market leader of this security segment. I believe the real drive for UTM's market growth is the growth in computer network technology. Today, building a computer network is no longer rocket science, no longer a place where only a few highly trained technologists can be successful. There are more and more homes, small offices, retail chain stores that are wired with dozens of devices such as printers, file servers, cash registers, stock control systems and workstations. People from all walks of life, such as doctors, lawyers, grocers, restaurateurs, taught themselves how to build up a network with a book, or some cursory Internet research. Following step-by-step instructions on web sites or stepping through online videos. While professional network security administrators are working on new challenges, creating the super fast networks (100Gbps and beyond) to feed the data centers of tomorrow; or building distributed, high availability virtual networks using load-balanced solutions and VPN technology.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597497473000235

FortiGate Hardware Overview

Kenneth Tam , ... Josh More , in UTM Security with Fortinet, 2013

The 'Black Art' of FortiGate Sizing

FortiGate sizing has always been considered as a black art we will try to tackle this subject in this section. Sizing any network product depends on various network elements with the environment's current and potential growth requirements. First and foremost, knowing the need for the product will help identify the elements surrounding the integration of the product in your environment. This includes such things as placement of the solution in your architecture and performance requirements. If there's an expectation to have the solution in place long enough to create a return on investment then the solution needs to be sized not just for today's environment but also for growth over   ×   number of months or years. When sizing a UTM solution, the elements involved in determining the proper solution is far greater to that of a typical network device such as a router or a switch. Given that a UTM solution can potentially replace multiple security stand-alone point products, each of these security product functions needs to be considered into the sizing of the proposed UTM solution. As with any investment, it's imperative a sizing exercise be done prior to any purchase. Besides figuring out which device best fits your current and future network environment, further diligence is needed to verify that the proposed solution does fit and work in your environment. You may wish to acquire the actual proposed UTM solution for a hands-on evaluation. At the end of the day, you do not want an incorrectly sized complex security & networking device in your environment that could potentially cause issues and cost more money to correct the problem.

To help determine which FortiGate UTM solution best fits your environment, there are two steps:

Step 1: Sizing Data Gathering — Gather as much information as possible to help with sizing the appropriate solution

Step 2: Assessing The FortiGate Solution—Taking that gathered data from Step 1 and apply the responses to several areas of information to identify the appropriate FortiGate model.

Sizing Data Gathering

Let's go over questions that should be answered to size a FortiGate UTM solution. The questions are separated in two general parts, Security Requirements and Network Requirements:

(1) Security Sizing Requirements Questions:

The purpose of these security related sizing questions is to determine the actual needs of the UTM solution. Each FortiGate UTM solution has fixed limit of resources allocated to certain functionalities. We'll outline some of these fixed resources to consider for each service with the below questions.

a.

What are the security feature requirements today?

b.

What are the security feature requirements that could be needed over the time for the purchase will be amortized and should this be considered in sizing the solution? Given the benefits of a UTM handling multiple features at an overall lower TCO (Total Cost Ownership) there could be the possibility of replacing an existing stand-alone point security solution when the service contracts expires e.g. an existing firewall, web filtering, intrusion protection system, etc.

c.

How many network users or devices expected to traverse through UTM solution?

Terminology

In-line vs. Sniffer mode

In-line mode: Traffic flows through solution for inspection.

Sniffer mode: Monitoring only mode on a switch port configured for Port Mirroring.

Here's a high-level checklist of security features currently offered on FortiGate UTM solutions along with related resources that could affect sizing:

•

Firewall

•

Number of expected firewall policies and objects

•

Concurrent connections (or sessions) support

•

New session setup per second handling

•

Packet size handling

•

VPN

•

The type of VPN protocol used e.g. IPSec vs. SSL

•

If IPSec: encryption requirements, number of site to site (device to device VPN), # software remote VPN clients, or both

•

If SSL: encryption requirements, # of web-mode termination, # of tunnel-mode termination

•

Network Anti-virus/Spyware

•

Methods used:

-

In-line: Flow-based method (faster performance) vs. proxy-based method (more secure). If proxy-based method, number of connections (or sessions/users) expected to be scanned

-

Sniffer mode for monitoring only

•

Protocols needed for scanning

•

Custom block/warning message usage

•

Quarantine usage

•

SSL inspection usage

•

Web Filtering

•

Methods used:

-

In-line Transparent (transparent in a way there's no modified needed on client end to support this) Flow-based method (faster performance) vs. proxy-based method (more secure). If proxy-based method, # of users expected

-

Sniffer mode for monitoring only

-

Explicit (want client to adjust web browser proxy settings to point to UTM) web proxy support. If so, number of explicit web proxy users

-

Redirection with WCCP

•

Custom block/warning/disclaimer message usage

•

SSL inspection usage

•

Application Controls

•

Methods used:

-

In-line with prevention capabilities

-

Sniffer mode for monitoring only

•

Intrusion Detection or Prevention

•

Methods used:

-

In-line with prevention capabilities

-

Sniffer mode for monitoring only

•

Anti-Spam

•

Email protocol usage

•

Custom block/warning message usage

•

SSL inspection usage

•

DLP

•

Methods used:

-

In-line Transparent (transparent in a way there's no modified needed on client end to support this) Flow-based method (faster performance) vs. proxy-based method (more secure). If proxy-based method, # of users expected

-

Sniffer mode for monitoring only

•

File filtering usage

•

SSL inspection usage

•

Web Cache

•

Hard disk usage

•

Wan Optimization

•

Hard disk usage

•

Wan optimization expected protocol usage

•

NAC/Endpoint controls

•

Number of FortiClient usage

•

Vulnerability Management

•

Expected number of hosts/subnets used

•

Historical logging & reporting

•

Number of UTM devices to support logging

•

Types of logs from UTM devices

•

Hard disk usage

•

Centralized management

•

Number of UTM devices to be managed

(2) Network Sizing Requirements Questions:

a.

Where's the UTM expected to be placed within your network architecture? Possible locations include the network perimeter, the access layer, distribution, or core of your network.

b.

What are the expected overall network performance requirements for the related security requirements for the placement of the solution?

c.

What is the current network performance where the UTM solution will be placed? Some of this data can be gathered from existing security or network solutions. The more complete answer on these questions the more accurate sized UTM solution could be proposed. Such as:

•

What is the current peak and/or average network throughput in bits or bytes per second?

•

What is the current peak and/or average new connections per second?

•

What is the current peak and/or average network volume?

•

What is the network packet size distribution?

d.

Will the UTM solution operate in-line, off-line, or a mixture of both in-line and off-line? If in-line, what's the planned operational mode such as Transparent (layer 2) mode, NAT/Route (layer 3) mode, or both?

e.

How many physical (including any redundant interface or 802.3ad LACP connectivity needs) and expected logical interfaces (802.1q VLANs)?

f.

What are the required physical interface requirements? e.g. Fast Ethernet, 1G fiber or copper, 10G.

g.

If there are multiple network physical or logical interfaces, what are the expected performance requirements for communications between these in either in-line or off-line?

h.

Is there a need for path or device redundancy? e.g. redundant interface support and High Availability clustering.

i.

Is there a need for jumbo frame?

j.

Is there a need to virtualize the UTM components into their own isolated UTM function via virtual domain (VDOM) (see Chapter 4 on VDOM description)? If so, which ones are likely to be used now and in the future?

k.

Are there any power supply requirements such as AC vs. DC? Is redundant power needed (depending on whether device redundancy is required redundant power may not be a critical requirement).

Assessing the Recommended FortiGate Solution

With the majority of the previous questions answered, the next step is to assess which FortiGate platform best meets the above requirements. To provide a more accurate decision on the platform of choice, we will need to analyze three areas:

I.

Feature Capabilities—To determine which platform would meet the requirements features

II.

Feature Capacity—To determine which platform would handle the requirement features based on current and future growth feature requirements

III.

Performance Capabilities—To determine which platform would meet current throughput & load requirements as well as expected future growth

Feature Capabilities

From a supported feature capabilities standpoint, the majority of the features are supported across all FortiGate platforms but there are a handful of features that are not. The information is maintained in the FortiOS documentations found at http://docs.fortinet.com/fgt.html.

Here's a quick reference of supported features that are limited to certain FortiGate models:

•

VDOM (virtual domains) are supported FortiGate 50B and higher models. By default it includes up to 10 VDOM license. FortiGate 1240B and higher has the ability to scale above 10 VDOMs (see those datasheets for maximum VDOM capacity).

•

WAN optimization and Web caching are supported only on FortiGate models with on-board storage (4G or higher) or with solid state hard drives options. WAN optimization requires both ends of a connection to be FortiNet technology. For example FortiGate to FortiGate or FortiClient to FortiGate.

•

802.3ad link aggregations are supported on FortiGate 200B and higher models.

•

High Availability is supported on FortiGate 40C and higher models.

•

Localized SQL logging is supported on FortiGate models with solid state drives.

•

SSL inspection and SSL offloading are supported on FortiGate models with SoC or CP6 & higher ASIC. Certain models maybe software restricted from leveraging this feature even though the hardware model supports this chipset. For example, FortiGate 20C has a SoC but function is disabled.

Feature Capacity

To find the feature capacity of each FortiGate platform, Fortinet provides publicly a Maximum Value Guide of all FortiGate platforms which can be found at: http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-max-values-40-mr3.pdf (as of this writing, FortiOS 4.0 MR3 was the most current version — in general the max value guide can be found in the related FortiOS version section under FortiGate products).

Review of this Maximum Value Guide will provide insight as to any feature settings that might affect current and future requirements.

Examples of such feature capacity limits include:

–

firewall rule limits

–

VPN capacity

–

Objects capacity

–

Routing capacity

–

UTM settings capacity, etc.

Some of the feature capacities can also be founded in the product datasheets.

The FortiGate datasheets and Maximum Value guide refer to System level vs. VDOM level capacity. Technically, all devices by default operate in a single VDOM instance even without VDOM enabled. So the capacity for VDOM denotes the capacity of the device. If VDOM is enabled then the combined capacity would equal the System level capacity. For example, a FortiGate 1240B can handle 10,000 gateway-to-gateway IPSec tunnels at the System level and 5000 at a VDOM level: If no VDOM configuration exists then the overall number of supported gateway-to-gateway tunnels would be 5000 (by default a device without VDOM enable is treated like a single VDOM instance). If two configured VDOMs exist then the number of gateway-to-gateway tunnels between the two VDOMs (max 5000 per VDOM) would be no more than 10,000 supported tunnels. Further, if there are three VDOMs, VDOM-A has 2000 tunnels configured, VDOM-B has 5000 tunnels configured then VDOM-C cannot have more than 3000 tunnels configured because it would reach the System level capacity of 10,000.

Performance Capabilities

The majority of FortiGate platform performance characteristics can be found on their main website. For a quick reference product matrix showing each FortiGate model specifications in a single area see: http://www.fortinet.com/doc/FortinetMatrix.pdf.

For a more in-depth specification, individual FortiGate datasheets are located at: http://www.fortinet.com/products/fortigate/.

Reviewing datasheets quickly helps to determine the potential FortiGate model ranges; in particular which FortiGate platform would meet the network throughput requirements:

•

Feature performance capabilities such as Firewall, IPS, Anti-virus, and IPSec & SSL VPN throughput numbers.

•

Concurrent sessions (connections) supported.

•

New session setup (TCP base) per second.

Tip

Additional general performance numbers

All performance testing are done in house using testing tools such as BreakingPoints [4] to provide the results. Not all performance metrics are highlighted in datasheets but here are some general rules regarding this missing features:

-For supported security features configured or using flow-base inspection methods such as Anti-virus, Web Filtering, DLP, and Application control, the expected performance should be slightly higher then published IPS throughput numbers.

-Supported security features that are configured for proxy-based inspection such as Web Filtering, DLP expected performance should be slightly higher then the published Anti-virus throughput numbers.

Also note, when particular security features are enabled it is not assumed that all traffic would fall into that throughput range. It is only the policy definition with the related security feature setting which could be affected by the stated performance throughput. For example, on a FortiGate 1240B, the anti-virus (proxy-based) throughput is noted as 900Mbps. There exists a policy in which anti-virus is the only security inspection service enabled within a policy, traffic that triggers the supported anti-virus proxy-based ports would be limited to 900 Mbps whereas other traffic that does not trigger the proxy listening ports would not have this limit.

Narrowing down the FortiGate platform based on the above criteria would help provide the minimum platform model but in most cases this is not enough. As the traffic load increases, the traffic patterns would vary (e.g. various packet sizes, more internet usage during a certain time, large file transfers occurring at various time, etc.), having varying traffic loads and patterns does not provide a predictable way of determining what effects this has on various features therefore finding the proper FortiGate platform is difficult to predict. The goal of the sizing exercise is to find a solution that best fits in your environment at the cheapest possible cost. Anyone can oversize the solution as a precaution but from a cost perspective this is generally not advised. Further discussion throughout the chapters will provide additional insight to help narrow down the FortiGate platform of choice.

Given the innovative capabilities at Fortinet, features may change after the writing of this book. It's always best to consult the latest published Fortinet documentations and, if possible, a certified Fortinet reseller or Fortinet sales engineer.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597497473000028

Understanding the threat

Allan Liska , in Building an Intelligence-Led Security Program, 2015

Unified threat management

In 2012 Gartner reported for the first time that the Unified Threat Management (UTM) market was larger than $1 billion in size ( Gartner Analysts, 2012). At a time when many security companies were struggling, the UTM market was experiencing double-digit growth, and it is easy to see why.

A UTM platform combines several different security functions such as firewall, VPN, mail filtering, proxy, and IDS into a single appliance with a single management console. The appeal of a UTM is obvious, overburdened security teams did not need to check three or four different consoles to track down a security incident. UTMs saved money, increased efficiency, sped up response times, and, usually, improved security within an organization.

Smaller companies were the early adopters of UTM technology. Large companies feared, not without foundation, that trying to support that much functionality with large amounts of traffic would cause slowdown.

As UTM technology continued to develop, companies like Cisco, Palo Alto, and Check Point delivered additional services on blades, which allowed them to support even larger organizations. Today, some of the largest organizations in the world rely, at least in part, on UTM technologies to secure their networks.

The rise of UTM technology adoption also rekindled the debate around single-vendor security solutions. A single-vendor security solution is when an organization relies on one vendor for all of their security needs. There are some advantages to this as it usually means that all of the solutions work together, which makes it easier for security teams to track a security incident through the network and speeds up remediation. There is also a commonality of security reporting within devices from the same vendor: A vulnerability rated critical in one platform will be rated critical in the same platform from that vendor. Similarly, the same nomenclature is used to describe threats across all devices from a single vendor, so if a bot is referred to as Zbot on one device it won't be called ZeuS on another.

On the other side of the argument, too much homogeny can cause security incidents to be missed. In single-vendor networks a threat may emerge that the adopted security vendor is slow to recognize, leaving organizations exposed for longer periods than those organizations with a mixed-vendor solution. Another potential issue is that even though a single-vendor solution should provide continuity between platforms, that is not always the case. Too many security companies have grown by acquisition. This acquisition strategy resulted in different technologies within the same security vendor being created and maintained by different teams who developed in silos and products within the same security vendor unable to communicate with each other. This situation is changing as more organizations are demanding interoperability from same-vendor solutions, but it is still a problem many organizations face.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128021453000016

Preventing System Intrusions

Michael West , in Network and System Security (Second Edition), 2014

Unified Threat Management

The latest trend to emerge in the network intrusion prevention arena is referred to as unified threat management , or UTM. UTM systems are multilayered and incorporate several security technologies into a single platform, often in the form of a plug-in appliance. UTM products can provide such diverse capabilities as antivirus, VPN, firewall services, and antispam as well as intrusion prevention.

The biggest advantages of a UTM system are its ease of operation and configuration and the fact that its security features can be quickly updated to meet rapidly evolving threats.

Sidewinder by Secure Computing is a UTM system that was designed to be flexible, easily and quickly adaptable, and easy to manage. It incorporates firewall, VPN, trusted source, IPS, antispam and antivirus, URL filtering, SSL decryption, and auditing/reporting.

Other UTM systems include Symantec's Enterprise Firewall and Gateway Security Enterprise Firewall Appliance, Fortinet, LokTek's AIRlok Firewall Appliance, and SonicWall's NSA 240 UTM Appliance, to name a few.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124166899000022

Establishing Secure Enclaves

Eric Knapp , in Industrial Network Security, 2011

Selecting Perimeter Security Devices

At a minimum, a firewall is typically required. Additional security—provided by IDS, IPS, and a variety of specialized and hybrid devices such as Unified Threat Management (UTM) devices, Network Whitelisting devices, Application Monitors, Industrial Protocol Filters, etc.—may be desired as well. Typically, the criticality of the enclave (see "Criticality") dictates the degree of security that is required. Table 7.1 maps the criticality of an enclave to required security measures of NERC CIP and NRC CFR 73.54, as well as recommended enhancements to improve security beyond regulatory requirements.

Table 7.1. Perimeter Security Requirements by Criticality

Criticality Required Security Recommended Enhancements
4 (highest) NRC CFR 73.54: Unidirectional Perimeter, NERC CIP 005: Firewall or IDS or IPS Application layer monitoring, Firewall, IDS and IPS
3 NRC CFR 73.54: Unidirectional Perimeter, NERC CIP 005: Firewall or IDS or IPS Application layer monitoring, Firewall, IDS and IPS
2 NERC CIP 005: Firewall or IDS or IPS Firewall and IDS and IPS
1 NERC CIP 005: Firewall or IDS or IPS Firewall and IPS
0 (lowest) NERC CIP 005: Firewall or IDS or IPS Firewall and IPS

Table 7.1 recommends that both a firewall and an IPS be used at each security perimeter. This is because firewalls and IPS devices serve different functions: firewalls enforcing what types of traffic are allowed to pass through the perimeter; and Intrusion Prevention Systems closely examining the traffic that is allowed through in order to detect "legitimate" traffic with malicious intent—that is, exploit code, malware, etc—that is transferred over allowed paths. Using both devices together provides two mutual benefits: first, it allows the IPS to perform deep packet inspection (DPI) on all traffic allowed in through the firewall; second, the firewall limits the allowed traffic based on the defined parameters of the security enclave, freeing the IPS to focus its resources on just that traffic and therefore enabling it to enforce a more comprehensive and robust set of IPS rules.

For even greater protection, DPI can be used to analyze specific industrial protocol functions. This may require the use of specialized SCADA IDS or SCADA firewall devices that are designed to identify these protocol functions, or even the use of an ICS protocol filter or application monitoring tool that provides DPI across all packets within a session—providing detection and analysis capability to protocol and application contents that span multiple packets. This provides an even deeper look into the contents of network traffic. Figure 7.14 illustrates the increased security capability of firewalls, IDS/IPS devices, and application session monitoring systems.

Figure 7.14. Relative Capabilities of Common Security Devices.

In the most critical areas, application layer session monitoring provides a valuable and necessary level of assurance, as they are able to detect both low-level protocol anomalies (such as a base64-encoded application stream inside of HTTP, used by many APTs and botnets) and application policy violations (such as an unauthorized attempt to write a new configuration to a PLC). However, unless monitoring very simple application protocols, where the desired contents are distinctly packaged within a single packet or frame, the application session must be reassembled prior to monitoring as illustrated in Figure 7.15.

Figure 7.15. Application Session Inspection vs. Deep Packet Inspection.

The most stringent perimeter security device may be the data diode, also referred to as a unidirectional gateway. A data diode is, very simply, a one-way network connection—often a physically restricted connection that uses only one fiber-optic strand from a transmit/receive pair. By only using TX optics, it is physically impossible for any digital communications to occur in a highly sensitive network area containing control system devices, while supervisory data may be allowed to communicate out of that highly secure enclave into the SCADA DMZ or beyond. In certain instances, such as for the storage of highly sensitive documents, the diode may be reversed, such that information can be sent into a secure enclave that is then physically prevented from communicating that information back outside of the enclave.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597496452000070

Implementing Security and Access Controls

Eric D. Knapp , Joel Thomas Langill , in Industrial Network Security (Second Edition), 2015

Selecting network security devices

At a minimum, some form of network firewall is usually required. Additional security—provided by IDS, IPS, and a variety of specialized and hybrid devices, such as Unified Threat Management (UTM) devices, Network Whitelisting devices, Application Monitors, and Industrial Protocol Filters—may be desired as well, depending upon the specific situation. Typically, the security level or criticality of the zone (see "Criticality") dictates the degree of security that is required. Table 10.1 maps the criticality of a zone to required security measures of NERC CIP and NRC CFR 73.54, as well as recommended enhancements to improve security beyond regulatory requirements.

Table 10.1. Perimeter Security Requirements by Criticality

Criticality Required Security Recommended Enhancements
4 (highest) NRC CFR 73.54: Unidirectional Perimeter, NERC CIP 005: Firewall or IDS or IPS Application layer monitoring, Firewall, IDS and IPS
3 NRC CFR 73.54: Unidirectional Perimeter, NERC CIP 005: Firewall or IDS or IPS Application layer monitoring, Firewall, IDS and IPS
2 NERC CIP 005: Firewall or IDS or IPS Firewall and IDS and IPS
1 NERC CIP 005: Firewall or IDS or IPS Firewall and IPS
0 (lowest) NERC CIP 005: Firewall or IDS or IPS Firewall and IPS

Table 10.1 recommends that both a firewall and an IPS be used at each security perimeter. This is because firewalls and IPS devices serve different functions. Firewalls enforce what types of traffic are allowed to pass through the perimeter by what is called "shallow packet inspection." Intrusion Prevention Systems on the other hand perform "deep-packet inspection" (DPI) by closely examining the traffic that is allowed through in order to detect "legitimate" traffic with malicious intent—that is, exploit code, malware, and so on—that is transferred over allowed paths. Using both devices together provides two mutual benefits: first, it allows the IPS to perform inspection of the "content" of all traffic allowed in through the firewall; second, the firewall limits the allowed traffic based on the defined parameters of the security zone, freeing the IPS to focus its resources on just that traffic and therefore enabling it to enforce a more comprehensive and robust set of IPS rules.

It is important to understand the distinction between "detection" and "prevention" in the context of intrusion prevention systems. Recall that the most important priorities of industrial networks are availability and performance. In other words, the network cannot tolerate accidental dropping of packets between hosts that are located on levels low within the ISA 95 model (i.e. Levels 1–3). This would occur if the security device generates a "false positive" and mistakenly interprets a valid packet as invalid and blocks it from reaching its destination. However, this may not necessarily be the case between industrial and business zones (i.e. Levels 3 and 4). This is the reason IDS is the preferred security appliance within industrial zones (placed "out-of-band" to network traffic) and IPS is used between industrial and business zones, or between semitrusted DMZs and untrusted business zones (placed "in-line" to all network traffic).

We have also learned that industrial protocols consist of common standards like Modbus and DNP3, but also depend heavily on vendor-specific proprietary protocols that have been optimized for a particular system. It is not common for major IT network security suppliers like Cisco, HP ProCurve, Juniper, Checkpoint, and others to offer solutions for industrial networks. So what options exist to implement advanced DPI analysis with industrial protocols? The answer is a new class of industrial security appliances that are industrial protocol aware and possess the capability to analyze and inspect both open and proprietary protocols. Companies supplying these devices include Tofino/Belden, Secure Crossing, ScadaFence, SilentDefense, and others. At the time this book was written, many other startups were in progress, and readers are encouraged to research the market thoroughly in order to fully understand all of the available options. In addition, OEM-branded solutions or recommended third-party solutions may be available from your control system vendors. Once an appropriate solution is selected and deployed, DPI can then be used to analyze specific industrial protocol functions. Figure 10.3 illustrates the increased security capability of firewalls, IDS/IPS devices, and application session monitoring systems.

Figure 10.3. Relative capabilities of security devices to detect threats using DPI.

In the most critical areas, application-layer session monitoring provides a valuable and necessary level of assurance, as it is able to detect low-level protocol anomalies (such as a base64-encoded application stream inside of an HTTP layer 4 80/tcp session, used by many APTs and botnets) and application policy violations (such as an unauthorized attempt to write a new configuration to a PLC). However, unless monitoring very simple application protocols where the desired contents are distinctly packaged within a single packet or frame, the application session must be reassembled prior to monitoring as illustrated in Figure 10.4.

Figure 10.4. Application session inspection vs. deep packet inspection.

The most stringent network security device may be the data diode, also referred to as a unidirectional gateway. A data diode is, very simply, a one-way network connection—often a physically restricted connection that uses only one fiber-optic strand from a transmit/receive pair. By only using TX optics on the source side, it is physically impossible for any digital communications to occur in a highly sensitive network area containing control system devices, while supervisory data may be allowed to communicate out of that highly secure zone into the SCADA DMZ or beyond. In certain instances, such as for the storage of highly sensitive documents, the diode may be reversed, such that information can be sent into a secure zone that is then physically prevented from communicating that information back outside of the zone. During this "flip" phase, the previous communication flow should be terminated to disable any ability for two-way communication to occur at any point in time through the gateway.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124201149000101

Logging events and monitoring the cardholder data environment

Branden R. Williams , ... Derek Milroy , in PCI Compliance (Fourth Edition), 2015

Intrusion detection and prevention

NIDS and IPSs are becoming a standard information security safeguard. Together with firewalls and vulnerability scanners, intrusion detection is one of the pillars of modern computer security. When referring to IDSs and IPSs today, security professional typically refers to NIDS and network IPS. As we covered in Chapter 4, the former sniffs the network, looking for traces of attacks, whereas the latter sits "inline" and passes (or blocks) network traffic.

NIDS monitors the entire subnet for network attacks against machines connected to it, using a database of attack signatures or a set of algorithms to detect anomalies in network traffic. See Figure 10.5 for a typical NIDS deployment scenario.

Figure 10.5. Network Intrusion Detection Deployment

On the contrary, network IPS sits at a network choke point and protects such a network of systems from inbound attacks or outbound exfiltration. To simplify the difference, IDS alerts whereas IPS blocks. See Figure 10.6 for a typical network IPS deployment.

Figure 10.6. Network Intrusion Prevention Deployment

The core technology of picking "badness" from the network traffic with a subsequent alert (IDS) or blocking (IPS) is essentially similar. Even when intrusion prevention functionality is integrated with other functions to be deployed as so-called Unified Threat Management (UTM), the idea remains the same: network traffic passes through the device with malicious traffic stopped, suspicious traffic logged, and benign passed through.

Also important is the fact that most of today's IDS and IPS rely upon the knowledge of attacks and thus require ongoing updates of signatures, rules, attack traces to look for, and so forth. This is exactly why PCI DSS mandates that IDS and IPS are not only deployed but also frequently updated and managed in accordance with manufacturer's recommendations.

In the context of PCI, IDS and IPS technologies are mentioned in the context of monitoring. Even though IDS can only alert and log attacks while IPS adds blocking functionality, both can and must be used to notify the security personnel about malicious and suspicious activities on the cardholder data networks. Below we present a few useful tips for deploying IDS and IPS for PCI DSS compliance and card data security. IPS is not required, but can be used in the place of an IDS.

Despite the domination of commercial vendors, the free open-source IDS/IPS Snort, now developed and maintained by its corporate parent, Sourcefire, is likely the most popular IDS/IPS by the number of deployments worldwide. Given its price (free) and reliable rule updates from Sourcefire (www.sourcefire.com), it makes a logical first choice for smaller organizations. It also shouldn't be taken off the shortlist even for larger organizations seeking to implement intrusion detection or prevention.

Although a detailed review of IDS and IPS technologies and practices goes well beyond the scope of this book, we would like to present a few key practices for making your PCI-driven deployment successful.

First, four key facts about IDS and IPS, which are also highlighted in the PCI standard:

1.

IDS or IPS technology must be deployed as per PCI DSS. If another device includes IDS or IPS functionality (such as UTM mentioned above), it will likely qualify as well.

2.

IDS and IPS need to "see" the network traffic in cardholder; for IDS, it needs to be able to sniff it and for IPS, to pass it through. An IDS box sitting in the closet is not PCI compliance (and definitely not security!).

3.

IDS and IPS must be actively monitored by actual people, devoted (full-time, part-time, or outsources) to doing just that. PCI DSS states that systems must be set to "alert personnel to suspected compromises."

4.

IDS and IPS rely on updates from the vendor; such updates must be deployed, or the devices will lose most of its value. PCI does highlight it by stating to "Keep all intrusion detection and prevention engines up-to-date."

The above four facts define how IDS and IPS are used for the cardholder requirement. Despite the above knowledge, IDS technologies are not the easiest to deploy, especially in light of the number 3 consideration above. PCI DSS-driven IDS deployments suffer from a few of the common mistakes covered below.

First, using an IDS or an IPS to protect the cardholder environment and to satisfy PCI DSS requirement is impossible without giving it an ability to see all the network traffic. In other words, deploying an NIDS without sufficient network environment planning is a big mistake that reduces, if not destroys, the value of such tools. Network IPS, for example, should be deployed on the network choke point such as right inside the firewall leading to cardholder network, on the appropriate internal network segment, or in the De-Militarized Zone (DMZ). For the shared Ethernet-based networks, IDS will see all the network traffic within the Ethernet collision domain or subnet and also destined to and from the subnet but no more. For the switched networks, there are several IDS deployment scenarios that use special switch capabilities such as port mirroring or spanning. When one or more IDS devices are deployed, it is your responsibility to confirm that they can "cover" the entire "in-scope" network.

Port mirroring and spanning should be avoided whenever possible. Switch vendors documentation will tell you that they do not scale for this type of monitoring and you may not see all data when the network is busy.

Network taps are the preferred method of deployment for IDS. Even if you decide to put IPS in-line, you should consider using taps to get the appliances in line. Even though all commercial IPS systems can be configured to fail open or "turn into a wire" if you do not use taps you may have to schedule a network outage whenever you have to swap out an appliance for maintenance or upgrades. In some environments, this can lead to failing to meet SLAs.

Second, even if an IDS is deployed appropriately, but nobody is looking at the alerts it generates, the deployment will end in failure and will not lead to PCI compliance. It's well known that IDS is a "detection" technology, and it never promised to be a "shoot-and-forget" means of thwarting attacks. Although in some cases, the organization might get away with dropping the firewall in place and configuring the policy, such a deployment scenario never works for intrusion detection. If IDS alerts are reviewed only after a successful compromise, the system turns into an overpriced incident response helper tool, clearly not what the technology designers had in mind. Even with IPS, a lot of suspicious indicators are not reliable enough to be blocked automatically, thus monitoring is just as critical as with IDS.

PCI DSS Requirement 12.5.2 does state that an organization needs to "Monitor and analyze security alerts and information, and distribute to appropriate personnel." Still, despite this, many organizations deploy IDS and develop a no response policy. As a result, their network IPS is deployed, it "sees" all the traffic, and there is somebody reviewing the alert stream. But what is the response for each potential alert? Panic, maybe? Does the person viewing the alerts know the best course of action needed for each event? What alerts are typically "false positives"—alerts being triggered on benign activity—and "false alarms"—alerts being triggered on attacks that cannot harm the target systems—in the protected environment? Unless these questions are answered, it is likely that no intelligent action is being taken based on IDS alerts—a big mistake by itself, even without PCI DSS. Some of the recent breaches of card data were directly attributed to ignored alerts from various security detection technologies.

The fourth and final mistake is simply not accepting the inherent limitations of network intrusion protection technology. Although anomaly-based IDSs might detect an unknown attack, most signature-based IDS will miss a new exploit if there is no rule written for it. IDS and IPS must frequently receive vendor signature updates, as mandates by the PCI DSS. Even if updates are applied on a schedule, exploits that are unknown to the IDS vendor will probably not be caught by the signature-based system. Attackers may also try to blind or evade the NIDS by using many tools available for download. There is a constant battle between the technology developers and those who want to escape detection. IPS/IDS are becoming more sophisticated and able to see through the old evasion methods, but new approaches are constantly being used by attackers like trusted server to trusted server or island hopping. Those deploying the NIDS technology should be aware of its limitations and practice "defense-in-depth" by deploying multiple and diverse security solutions.

Thus, IDS/IPS is a key monitoring technology for PCI DSS and data protection; however, when deploying it, many pitfalls need to be considered if it were to be useful for PCI compliance and security.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128015797000108