23.03.2017 Views

wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Vertical Integration 13-9<br />

Internet<br />

Frequent, automated attacks (port scans)<br />

Standard IT solutions: VLANs, SSH, TLS<br />

Intranet<br />

Fieldbus<br />

AP<br />

Firewall, network address translation<br />

Main threat: malicious software<br />

Restricted, controlled user group<br />

Firewall, role-based access<br />

Reduced security, proprietary solutions<br />

Controlled access (maintenance staff)<br />

FIGURE 13.6<br />

Defense-in-depth security model for vertically integrated company networks.<br />

As the timeline in Figure 13.2 shows, most of these developments were concluded long before the<br />

Internet became known and was widely employed by the broad public. It is thus no wonder that security<br />

considerations never played a prominent role in automation before the end of the 1990s [D97,PS00].<br />

The most promising approach to cope with the heterogeneity of the networks is a hierarchical security<br />

model following the defense-in-depth approach. Figure 13.6 shows the three typical interconnection<br />

zones in the company network. The zones are separated from each other by dedicated network nodes<br />

that can be used as anchor points for the security strategy. The inner connection node (access point) to<br />

the actual fieldbus is the gateway or proxy already discussed in Section 13.3.<br />

As existing standards cannot be changed, the only viable option for the field level is to use the fieldbus<br />

simply as a transport channel and to tunnel secure packets over standard fieldbus protocols and<br />

services [SS02]. Such an application-level approach could easily achieve end-to-end security, which is<br />

desired in most applications, anyway. Unfortunately, it is likely to cause problems with interoperability<br />

unless all nodes in the network adhere to this enhanced standard, i.e., a mixture of secure and insecure<br />

devices would normally not be feasible. In addition, the limited messages size in some fieldbuses leaves<br />

only little room for the additional data blocks required by efficient security extensions. This problem is<br />

similar to the one encountered in IP tunneling discussed in Section 13.3.<br />

The access point itself has so far been the focal point of interest for most researchers. Given the lack<br />

of general field-level security, it is the only part of the automation system (apart from the Internet side)<br />

where security can easily be applied. One very common approach is to combine the access point with a<br />

firewall, which is the most widely employed security measure in the design of network interconnections<br />

today even in the field of automation [D97]. Indeed, the term “firewall” is nowadays frequently used as a<br />

synonym for network security. In practice, however, their application is not so straightforward. Owing<br />

to the inherently asymmetric operation of a firewall (transparent from the private network, opaque<br />

from outside), it is difficult to place a standard firewall in front of a fieldbus access point; it is better to<br />

tightly integrate the firewall into the access point and use, e.g., port forwarding to control the traffic<br />

[PS00]. On top of this, the access point is also the ideal point to control and manage access to the fieldbus<br />

zone. A suitable model for handling access rights is role-based access control, where all <strong>communication</strong><br />

partners (users, devices, tools) are associated with particular roles depending on the context of the data<br />

exchange. In the IT world, this concept is widely employed, and it can also be used in an automation<br />

context [WB04].<br />

Security in the Internet finally is a well-researched topic with a large number of meanwhile very<br />

mature solutions. In fact, for nearly all Internet application layer protocols, secure versions exist, or<br />

conventional insecure protocols can be used on top of a secure transport layer. This standard mechanism<br />

of first establishing an encrypted channel between <strong>communication</strong> partners is called Transport<br />

© <strong>2011</strong> by Taylor and Francis Group, LLC

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!