Networks & Building Controls

The computerization of building control systems has brought operational improvements and lower cost, but it can make the systems more vulnerable.

The economic impact of September 11 has prompted building owners, facility managers and their consulting engineers to take dramatic action with regard to both network security and related building management systems. Many security issues that involve building control systems — such as links between HVAC and fan control systems, and upgraded access control systems — are based on network communications within and between various applications.

The proliferation of IT networks for building control systems has led to improved functionality and faster emergency response. However, these improvements also open up new risks. Every network component creates a new avenue of infiltration for viruses, hackers and other threats.

Five Security Myths

1. “A top-of-the-line firewall is all the protection I need.” Firewalls are necessary, but they are only one part of a comprehensive security plan. Even the best firewalls can be infiltrated if they are the only line of defence. Also, remember firewalls protect against invasions from the outside, but what about the internal network threats? It is estimated that between 60 per cent and 70 per cent of network attacks are from within. Firewalls, anti-virus software and embedded operating system protection are not totally effective against internal attacks or those on the physical system itself.

2. “Anti-virus software will keep all of the bugs out.” Again, a solid anti-virus solution is a must-have, but not a silver bullet. Regular, proactive software updates are necessary for anti-virus software to do its job.

3. “Network security is an IT department’s job.” IT professionals cannot solve the entire problem alone. They are part of a team that also includes the building engineers, facility operators, and product suppliers.

4. “Hackers aren’t interested in attacking building control systems.” Hackers do indeed target building control systems, but they are not always in search of system control. Instead, they may break into networks to harness computer resources for storage and file serving MP3s and digital movies on remote web sites. Their goal is resource theft.

5. “We run on a well-respected operating system; the industry standard is secure enough by default.” Whether closed or open-source, all operating systems are vulnerable to attack if not configured for secure operation, properly protected and regularly updated with the vendor’s suggested updates.

Defining a security policy

One of the best lines of defence is to develop a written plan to protect the security network and improve the operators’ ability to identify and respond to attacks. This plan must be communicated to everyone involved in network security: engineers, operators and administrators. It is also important to regularly test and evaluate the security plan and processes. Since network vulnerabilities are constantly being found, the plan should be considered a constant work in progress. The frequency of review and testing should be based upon how critical the system is to the operation, but at a minimum these tasks should be done semi-annually.

Start by taking a look at the system from within, and create policies that limit the risk of internal attacks. Then consider holistically the internal/external security at each layer of the network.

Physical access — Servers should use BIOS (basic input/output systems) password protection, OS logon and audits. And they should be kept in physically locked locations, secured by access control systems which can provide an audit log of who has been in the server room.

Logical access — Only authorized users should have log-on access to the server or workstations. In very secure settings this precaution may even involve multi-factor authentication including biometrics and smart card technology.

OS security — Operating system security policies can be set at either the local or domain level. Be sure that you understand the implications of each type. Take appropriate steps to ensure consistent policies throughout your system.

User management — Make sure that the local security policy addresses audit policies, password strength, lockout, user rights, and options to control access to resources.

Checklist

Use the following checklist as a starting point for a policy to prevent infiltration from the outside:

Turn off or disable unnecessary services. For users’ convenience, some operating systems automatically turn on all available services such as File Transfer Protocol (FTP), at the expense of system security. This practice is changing, but it is important always to be sure how the system functions.

Secure ports and other points of access. Consider employing a software- or hardware-based firewall on the server to protect vulnerable ports that cannot be secured any other way. This is for internal network protection and should not be used to supplement the use of a hardware-based standalone firewall to protect against internet-facing attacks. You need both.

Cut down or eliminate modem and wireless access to the network. Try to use virtual private networks (VPN) or other secure means of remote access. If modem and wireless connections are involved, place tight constraints on their use. Wireless connections should also incorporate an encryption solution.

Employ an anti-virus solution in the network security policy. Many anti-virus solutions now include basic firewall and intrusion detection systems for a reasonable price.

Use tools to evaluate system security levels and update status. Tools like Microsoft’s Security Baseline Analyzer, which will help analyze the current security of a server, are invaluable to help identify vulnerabilities and provide step-by-step instructions to secure the system. Gibson Research provides a tool called “Shields Up” that can be used over the internet to determine open ports and vulnerability surfaces on any server or workstation. These and other tools will help operators both test and reduce the attack surface of a system.

A comprehensive security plan will make a network less susceptible to attacks, but unfortunately it will not be invincible. Attacks will happen. When they do, employing an incident response plan is as important as having a security policy and helps manage incidents effectively. An incident response plan walks an operator through the steps to take when an attack is identified. It will explain how to minimize the attack, how to protect the system and data, and how to preserve data for an investigation after the event. The incident response plan is vital.

Ongoing security maintenance

Regularly updating the operating systems and building management applications, and maintaining vigilant anti-virus software updates, are the most vital parts of an ongoing security strategy. A building owner should develop a plan to regularly identify the updates most critical to their system, and then follow through. Until vendors completely automate the update process, a proactive update plan is an absolute must.

The building owner should also regularly and thoroughly test the system’s security policy and practise the incident response plan. This will help eliminate surprises, refine incident response activities and identify needed adjustments. The frequency of review and testing should be based on the critical assessment of the system to the business. At a minimum, it should be done every six months.

As is the case throughout the technology world, information is key when it comes to maintaining an open network system’s trustworthiness. Operating system vendors, industry consultants, security organizations, alert agencies and the groups referred to below are all good resources to tap when considering a network security policy.

Reference:

Microsoft Operating System security — http://www.microsoft.com/security/

Linux Operating System security –http://www.linuxsecurity.com/

SANS Institute for security policies
and more — http://www.sans.org

Stay current on new vulnerabilities by checking for alerts at CERTS –http://www.cert.org/

Mark Cherry is product development manager for Honeywell Automation Control Solutions Service in Minneapolis, Minnesota. E-mail: mark.cherry@honeywell.com