NETWORK SECURITY HAS ALWAYS BEEN PRIORITY #1 FOR IT MANAGERS AND DIRECTORS. WITH AV TEAMS BUILDING NETWORKED SYSTEMS, ARE YOU SURE THEY ARE AWARE OF THE OPERATIONAL POLICIES AND RULES?
“Security requirements for AV projects are often discovered at installation or even worse, on commissioning or later when the organization runs a security audit." That's Harman Professional’s manager of Enterprise Solutions, Paul Zielie explaining how the cost and schedule impacts of discovering new critical requirements late in a project can be significant. "The illustration below shows a typical AV project timeline with various points at which security requirement discovery occurs,” he added.
Security requirements are determined after the business use case and needs analysis since that will determine the features included in the project which need to be secured.
Ideally, security requirements should be developed in the initial planning and design phase of an AV project. This will ensure that any significant impacts to the proposed design are accounted for and budgets for the project are properly set. The security requirements should be included in any bid documents and added to the Statement of Work (SOW). In a consultant-led project this is achievable. In other acquisition models this may not be feasible for several reasons including that the organization does not want to expose its security to a large group of potential integrators, preferring to work with only the contracted integrator.
“If the security requirements cannot be determined prior to the integration contract award, language should be put in the tender that requires the offerors to specify standard security configurations and that specific security requirements will be determined after award with equitable adjustments for changes,” said Zielie. “This will allow a baseline comparison of security costs and still allow the project to meet the specific needs of the organization.
In all cases, security requirements should be agreed upon and added to the statement of work, project plan, and acceptance criteria prior to the final design sign off with the responsibilities and deliverables of each party, including the network configurations furnished by the network provider, typically a customer responsibility.
The Sextant Group’s Glenn added, “Internally the policy-level decisions, the security policylevel decisions, those management decisions— that takes time to work through internally and especially at a large corporation or university, so you want to engage those folks as early as possible so they can work on that internally. We can guide them through that process, but ultimately those are decisions and policies they have to do develop in-house.”
AV SECURITY BEST PRACTICES
There are simple configuration steps that are often overlooked by the team doing the integration which leave the systems wide open.
1. Change the default passwords
• There is no excuse for leaving the system open to anyone with access to Google
2. Separate Administrator and User accounts and privileges
• If possible each user should have their own account and password with just the privileges they need to do their job.
3. Enable auditing logs
• If there is a breach, these will help find out how it happened so that changes can be made to prevent it in the future
4. Disable unnecessary services
• Services such as telnet, ssh, http, https, and ftp can have vulnerabilities which are unknown at the time they are programmed in the system. If you don’t require a service and shut it down, you are not vulnerable to future exploits on that service.
5. Enable encryption
• If you can use ssh instead of telnet and https instead of http you will decrease the likelihood of someone discovering information via intercepting network traffic.
Modern IT security is implemented with a Defense in Depth approach. Defense in Depth is a concept in which multiple layers of security controls are placed throughout an information technology (IT) system. Its intent is to provide redundancy in the event a security control fails or a vulnerability is exploited. For example, if an intruder gets past the firewall, they still have to know a user name and password in order to log into a protected system. In practice, security should be implemented everywhere it is practical. Do you leave your safe unlocked because your house has an alarm?
Often AV systems do not have the types of security controls required by a security policy. If this is the case, the defense in depth approach can often be applied in order to put other security controls in place to meet the original intent. The process for this is called mitigation. Mitigation involves putting in configurations, external controls, or policies that lower risk factors to point that the risk is acceptable.
For example, if telnet is not allowed by policy because it is insecure, but it is the only way to control the required device, there are three options:
1. Use a different device.
2. Don’t control the device.
3. Mitigate the risk.
In this case the risk is that an intruder could obtain passwords to the system that are sent insecurely. A possible mitigation would be to put the device on an isolated network and restrict telnet traffic to that network so that an intruder will not have access to the traffic.
PUTTING THE AV SYSTEMS ON A SEPARATE VLAN SUPPORTS DEFENSE IN DEPTH
The illustration above shows a typical AV project timeline with various points at which security requirement discovery occurs.
There are limited valid reasons for remote access to the AV equipment that controls potentially sensitive meetings. An Access Control List (ACL), a list of traffic allowed between two networks filtered by IP address and port number, can be configured on the router between the AV VLAN and the rest of the network to stop unauthorized traffic. For example, there is no reason that Accounting needs to access a projector, and there is no reason an AV device needs to access the payroll server, so that type of traffic can be stopped.
The separate VLAN technique is supported by the fact that AV equipment communicates primarily among the AV devices with limited connectivity to the data network. With an AV VLAN devices in different parts of a building will communicate directly without having to traverse other networks. This can be a big advantage for applications like streaming or digital signage.
Additionally, network admins like AV VLANs because there is often significant broadcast traffic between AV devices and these broadcasts will not forward through a router. One of the uses of these broadcasts is device discovery so within a VLAN all the devices can discover each other. If they were attached to various subnets around a building more configuration may be required.
In the case of devices with network connections that utilize the Ethernet connection for both control and media, such as a VTC Codec or streaming encoder/decoder, the device should reside on the VLAN that makes the most sense for the media, but a route should be available to the AV VLAN with an ACL to allow for control traffic.
In using an AV VLAN, it is important to explain to the AV team, “They can lock down a port just like any other port on the network—that it’s a segmented VLAN so it’s not able to even communicate with the corporate LAN,” said Glenn. “The only thing it can communicate with are AV devices, not corporate content.” In situations needing the highest level of security such as government installations AV is usually on a physically separate network.
LACK OF AUDIO ENCRYPTION TODAY
It is not news to most network savvy AV folks that audio packets are not encrypted, but it is something IT departments might not be aware of. “Every audio product that’s in the commercial AV space today, that employs networked audio—none of them are encrypted,” said QSC Systems, director of installed systems, Product Management, TJ Adams. “CobraNet, AVB, RAVENNA, Q-LAN, Dante—you cannot encrypt those today. So the only choice—we’re all in the same boat as of the end of 2015—is to put them on separate networks which are physically isolated from the data network, if security is a concern.”
“Even if the media streams are encrypted, most AV products use the same security paradigm that is used for HDCP where any valid receiver can decrypt the stream,” Zielie added. “When these streams are transmitted via multicast, any host on the network that asks for the stream can get it. Therefore, even if the stream is encrypted or isolated on another network, the only protection you receive is from network eavesdropping. Anyone who is allowed to book a conference room could listen in to a meeting they are not authorized to attend.”
