I’ve written past blogs about how today’s collaboration needs require an “any-to-any” mindset, and about how the look of enterprise conference rooms is changing. In the first blog I explained that “any” represents the expectation from the now seasoned users of collaboration that everything should just work – in any combination and anywhere they happen to be. That it no longer matters where one is – in an office building, in a conference room, in transit or working from home – our suite of tools needs to work in every circumstance. A good example of this idea coming together is the recent release of Cisco’s Spark – a next generation collaboration platform that lets users connect from a conference room, a PC, a tablet or a smartphone – and in each case access all the data irrespective of the device.
In the second blog I explained how at many organizations, 1980s style big, complex, mostly unused AV conference rooms are finally giving way - to smaller, simpler, standard, repeatable, scalable and reliable all-in-one systems.
Cisco’s MX800 All-In-One Room System
These rooms and systems support the real, changed needs of today’s enterprise users, and shun the out-of-date thinking of many AV consultants and facility architects (who often still want to construct a customized, integrated, complex system for each room.)
While all of that advice is supported by the facts provided at face value, there is another reason that adopting these modern best-practices is very urgent. Specifically, old-style AV integrated conference rooms represent a significant security risk that organizations simply can no longer afford to take.
A typical old-style integrated room uses discrete components from multiple manufacturers to perform its required tasks. These components can include the following:
Video Display (s)
Video Processor (s)
Video Camera (s)
Video Recorder / Player
DSP Audio Mixer
Audio Playback System
Wireless Presentation Connection System
Table Connection Interface (s)
Touch Panel (s)
Lighting Control Interface
Windowshade Control Interface
As opposed to the norm of years ago, most if not all of these components now require network connections with each other to operate. Many require internet access to function or be updated as well. Also, in many circumstances, most of the components come from a different “best in breed” manufacturer – with each one using different embedded operating systems, firmware, protocols, ports, etc.
A recent client of mine commissioned an analysis of their integrated AV systems to determine how secure they actually were – and the results were startling. 90% of the systems failed the most basic ITSM requirements. Issues were discovered in areas such as password handling, open ports, known compromised protocols, known vulnerabilities, etc. Even understanding which manufacturers provided support to update discovered vulnerabilities was a daunting task. Some had the information and processes on their website, some required a telephone call to their support hotline, and some provided no support at all. If one did identify a vulnerability and somehow managed to obtain and install a patch it would likely cause the component to stop working properly with the other components in the system. Keep in mind that Integrated AV rooms are so complex that they often need off-site “staging” and commissioning just to get them to work correctly in the first place. Making a change to one sub-system might require that commissioning to happen all over again.
The scariest discovery in the analysis was the realization that the standard procedure for adjusting or troubleshooting the AV system was to have an AV integrator’s support technician come to site and connect his or her personal notebook PC to the AV components. That external device – with none of an enterprise’s standard security protections – could be the source of malware and viruses – which could be transferred to a user’s network via any one of the twenty or so unprotected component types. (This is similar to how one of the most infamous recent retail breaches occurred – with a malware infected service technician’s notebook being connected to the firm’s HVAC system.)
While a few enterprises try to mitigate the potential damage by isolating the AV system network from their core network in some way, this is never a guarantee that components and/or users won’t cross over at some point, enabling the spread of malware. I personally predict that this is the year that an integrated AV system will be the cause of an enterprise’s significant data breach.
What should organizations be doing to protect themselves from this threat? For starters, I am advising my clients to no longer permit personal notebooks to be used to set-up or troubleshoot their AV systems. Each integrated AV system purchase should add the required service notebook to the BOM. This then becomes a typical enterprise PC running the organization’s standard image, and is always connected to their network to ensure appropriate patching. Should service work on an AV system be required, the external technician can check-out this unit to use and check it back in when done.
Beyond that however, I go back the modern best-practice advice I mentioned earlier. Using a good all-in-one system from one manufacturer mitigates most if not all of the security issues. When organizations do that, there is one manufacturer to go to for security updates and patches; no update will disable other parts of the system because it’s all a single product; and because the system is the same at all locations, one effort to research and fix resolves all open issues.
I’ve personally given presentations with lots more detail on why these all-in-one solutions are unquestionably the right direction in 80%-85% of AV and collaboration use cases – and why there are good systems to embrace and bad systems to avoid. If you’d like to see one of these on-line, or have me go over it personally for your organization, just send me an email and I’ll be happy to follow-up.
This article was written by David Danto and contains solely his own, personal opinions. David has over three decades of experience providing problem solving leadership and innovation in media and unified communications technologies for various firms in the corporate, broadcasting and academic worlds including AT&T, Bloomberg LP, FNN, Morgan Stanley, NYU, Lehman Brothers and JP Morgan Chase. He now works with Dimension Data as their Principal Consultant for the collaboration, multimedia, video and AV disciplines. He is also the IMCCA’s Director of Emerging Technology. David can be reached at David.Danto@Dimensiondata.com or DDanto@imcca.org and his full bio and other blogs and articles can be seen at Danto.info. Please reach-out to David if you would like to discuss how he can help your organization solve problems, develop a future-proof collaboration strategy for internal use, or if you would like his help developing solid, user-focused go-to-market strategies for your collaboration product or service.
All images and links provided above as reference under prevailing fair use statutes.
Hi! On our ASR9010 we have a lot of bridge domains and storm control configured. In chassis are installed both trident and typhoon line cards, so it works in mixed mode.In log I see this message:pfm_node_lc: %PLATFORM-L2FIB_ALARM-3-STORM_CONTROL...
Hello, I'm trying to turn off the critical led on a ASR-9006, but nothing works and I don't find anything on google. I see this output: show environment ledWed Jul 15 12:10:34.502 BRASILIAR/S/I Modules LED Status0/RSP0/*host Critical-A...
Hello, We're getting Cisco NCS-5501-SE 7.0.0 from Cisco. Before we use it in production I will update it to 7.0.2.Looking at update guide the main steps are here: router(config)#fpd auto-upgrade enable
install add source h...
Below is our scenario: PPPoE Server <---> G1-R1(ASR920)-G2 <------MPLS Core-------> G2-R2(ASR920)-G1 <----> PPPoE Client We configured xConnect between G1 of R1 to G1 of R2 and session was up. 1. If we configuration IP bas...
Hello, We are working on a lab deployment of SRv6 across two ASR9001 platforms running 6.6.3 software. We are using IS-IS as our IGP so we will be pushing the locator prefixes across the devices using that. I was following the cisco segment routing c...