by Danny Maland
Todd McCandless recently authored an article for this site called “The Khaki Invasion.” In his piece, McCandless set forth a number of strategies for dealing with the reality of IT having kingship over AV in the world of the information hyper-mesh.
“Hyper-Mesh” is, as far as I know, my own term. We have moved beyond the days of the information super-highway, where a small-ish number of devices specialized for network access drank from the bitstream. We are now in the era where pretty much everything can talk to pretty much everything else. Thus, we have a “hyper-mesh” of data — data that's careening around an invisible spiderweb of information links between all manner of devices. Sure, the enormously fat pipes of the cable and telecom infrastructure providers are still the major freeways, but now there are access roads every few centimeters.
Anyway... If you were reading McCandless's article and felt lost when he referenced DMZs, VLANs, and DHCP, you may have looked out into the vast wilderness of IT and wondered, “What do I have to know about this, and what don't I have to know? Here's Todd telling me that that I have to start answering to CIOs, and be ready to work with IT shops, and get trained, and figure out what I do well so that I can get my business model all nicely cozied up to the IT world, and HOLY COW I'm overwhelmed.”
If the preceding sounds like you in any way, then I have some opinions that I think you should consider. These opinions were formed in a number of contexts. One context was my three years of work with a mental-health research program, where I was officially a data-entry operator but spent almost all my time doing IT support. It was a great learning experience, because it was a “Chuck Yeager” flight school. That is, you learned by being thrown at a real-life problem, and you had to figure it out. (I once forgot to put a hard return at the end of a configuration file, which caused an expensive and brand-new server to not boot anymore. Figuring out how to fix the problem, and then implementing that fix was intense, exhilarating, and terrifying. I will never again forget that hard return...)
Another context is the plain-old, everyday, relatively low-intensity reality that even for us pro-audio folks, computers and computerized equipment have seeped into pretty much everything. (Heck, my current flagship mixing console IS a computer.) The last context is my formal education, which was a Bachelor of Science in IT. Along the way I went through A+, Network+, and Security+ certifications, and my degree capstone project was the writing of a guided tour through building and testing a computerized lighting control system.
Having at least been around the block, I've come to the conclusion that the really important parts of IT as it interfaces with AV are these:
1. Security: Forget all the whiz bangery for a bit. Forget all the technical details of how things talk to other things, just for a minute. Security is something that gets ignored for the sake of convenience or “Wowzers, it can do that?” all the time. Security also just plain gets forgotten. Here's the deal: You need to understand that every data link you add, every networked device you connect, and every “totally sweet thing you can run with your smartphone” that you put into play increases attack surface area. Attack surface area is the number of points where a system can be accessed and exploited. If you really want to rock (and who doesn't want to rock?) then you should make sure that you are intimately familiar with the ways that any data-enabled device could allow an intruder to do Not Nice Things on your client's network. You also need to become intimately familiar with all the ways that network enabled devices allow you to lock them down against intrusion.
Also, you should be aware that some attack vectors are not directly related to a specific network device. What I mean by this is that even the most access-restricted device can become a doorway for some nasty invader, by way of how many “trusted” devices are exposed to “untrusted” material these days. You can have all the restrictions and protections you want on a networked device, but what if that device is allowed to have a laptop or mobile device connect? What if that roaming laptop or mobile gadget has been exposed to some network-enabled nasty something-or-other? It is entirely possible that the evil little creature residing on the “trusted” (but no longer trustworthy) portable device is now connected to your client's data system, having bypassed any security perimeter in place simply by “walking in” with the right person.
Similarly, just having an ethernet cable running to a piece of network-enabled equipment is worth considering. If a DHCP (Dynamic Host Control Protocol) server is just handing out addresses willy-nilly to anything on the network that asks for one, an intruder could simply pull that cable out of the AV thingamabob, plug it into something else, and whammo, the intruder now has the nice advantage of an authentically-part-of-the-internal-system network address for their own device.
Now, you can't be so scared of everything that you do nothing, but you do need to know the risks, and how big those risks are for a given context. For instance, if you're working with IT folks who are paying close attention, they may already have set up their internal security structure to prevent AV network traffic from traveling to or from sensitive areas, but the thing is, you need to make sure that close attention is actually being paid.
2. Availability: Once you've thoroughly explored and addressed the security issues surrounding a device, I think the next thing you should look at is the question of “How do we make sure this thing stays usable? What happens if it drops off the network entirely?” There are plenty of folks who are satisfied by getting something to work in an impressive way, only to receive a rude awakening when a piece of equipment becomes an expensive brick because it stopped responding. Fault tolerance (the ability to recover from or ignore some sort of failure), redundancy, and backup are issues that you need to spend some time thinking about, and you may be surprised by where those issues pop up. For an ultra-critical computer-based remote control system, the issues are pretty easy to address. Have the computer set up so that it uses a RAID (Redundant Array of Independent Disks) of level 1 (mirror) or higher, so that a hard drive failure doesn't stop the fun. Have a redundant power supply installed for the computer itself, and then supply AC power through a UPS (Uninterruptible Power Supply) to keep that remote viable in case electricity is lost.
The above is not so hard, but things can get a bit more sticky when we're not talking about a traditional computer. For instance, what if you install a network-enabled control for some device, and the control loses connectivity for some reason? Does the endpoint device become useless? Is there some sort of “front panel” control that will allow the show to continue? Is that front panel control even any good? (I myself am the owner of a DSP box that works beautifully with a computer remote, but has a front panel control setup that is about as awkward as me at a school dance.)
The backup front ranges from the macroscopic scale (say, a spare video projector) down to all kinds of minutiae. Spend some time thinking about a quick and easy way to restore the programs for a networked control device, and you may just become a rockstar if that device loses its little electronic mind. Speaking more generally, you greatly increase your changes of being a rockstar if you've taken the time to ensure that your system remains usable even when everything else has failed catastrophically—and if your system does become unusable, that it can be made usable again in a very short timespan.
3. Professional Support: I'm willing to bet that the majority of AV folks out there have run into a situation where they've grumbled “Why didn't they hire us, the professionals, to deal with this instead of making such a mess by themselves?” This statement cuts both ways. When AV folks are in unfamiliar territory, they should also cede control to the folks who really know how it all works.
You have probably noticed that I haven't made this piece into a primer of IT basics, things like how networks are set up physically and logically, what a particular server does, and that kind of thing. The reason for that is because I see those things as incidental when compared to security, availability, and professional support. If you've got the interest and the drive to really delve into the security and availability aspects, then the “mechanical” bits of getting devices to talk to each other over cables or wireless links is just a matter of doing some reading and testing. If you're willing to put in the time, you can become your own professional support.
If, however, all of this is making your brain feel like wet bread, I think you will be far better served by either bringing people into your organization who are IT professionals, or farming your IT issues out to external IT professionals. If the security and availability aspects of interfacing with IT turn you off, I would respectfully but very directly put it to you that learning how to make it all work (and ignoring the rest) is becoming dangerous by way of getting a little knowledge.
If you don't want to do it from top to bottom, then I believe you should find someone else who does want to do it from top to bottom. When you do, you'll be able to enjoy the benefits of having strong integration with IT that really addresses the deeper issues involved, instead of just being able to deploy systems that make use of concepts recognizable by IT people.
