I am watching with some interest a growing trend with district’s implementing newer IP-based building systems (HVAC control, food service temperature controls, door control, video surveillance, etc.) and when properly implemented I think this a fine thing.
However, one of the main “selling” features of some of these new systems is the ability to access them from anyplace on the Internet. For example, it seems that district administrators are really drawn to the idea of being able to unlock a door or view a video camera from an app on their mobile device from the comfort and convenience of wherever they happen to be at the time.
Whether or not this type of universal access, particularly to something like a security system, is really, really necessary will be left as a topic for another day and place.
My issue today is the concern is that there are very risky ways to implement this type of remote access and much more secure ways to implement it.
What I don’t see going on is much research or discussion between district administrators and district technical staff and advisers prior to solution selection and implementation of a solution in their district. This can significantly open up the risk to the rest of the district’s network and data if solutions are just implemented according to the solution vendor’s instructions without review.
This post is designed to provide you some food for thought as you think about remote access to any application, but particularly security system applications in your districts.
First, let’s agree we need to proceed from the assumption that there is no such thing as an un-hackable system. And that any system that is exposed directly to the Internet increases exponentially the risk to that system and that it might be hacked. If I am allowing “ME – the good guy” to potentially access the system from anywhere, then I am also allowing “ANYONE – including the bad guy” to potentially access it from anywhere as well (or probe the system for a vulnerability that will allow them to break in to the system to do harm).
This means you should think very carefully about any solution that requests you to open up access to that system on your internal network directly from the Internet.
Remote access to systems and services is part of the very fabric of the Internet but as the Internet has evolved into a much riskier place, more and more of the significant systems and services we publicly access have now been moved to large data centers. These data centers are maintained and monitored by trained data and security engineers using all sorts of sophisticated tools, 24-hours a day, 365 days a year, to help ensure both access and security of these systems. Staff are available round the clock to respond instantly to any security threat to the service.
How does that compare to something you expose to the Internet that is located directly inside your district’s network?
For district’s that really want to consider public access to district internal systems CSI recommends consideration of one of two more secure choices:
1 – Choose a vendor whose public access to their solution is based upon a 3-way connection. Both the internal network system and the user desiring remote access to it connect outbound to a third system housed in the vendor’s data center. Upon proper authentication of both sides the user and the system are connected together through that vendor data center housed system. With this type of solution, no open inbound Internet access is ever granted to any district devices. The expectation is that the vendors data center systems are monitored, managed, and maintained by professional staff who keep the service running.
2 – Require all access to district internal systems be granted through the use of an encrypted VPN session into the district. Again, this eliminates the need to expose any internal systems directly to the Internet. All internal systems are accessed the exact same way that they would be if you were sitting inside the local network once the VPN connection is established. The only direct Internet exposure is the VPN termination device itself, which is usually a hardened firewall specifically designed for this purpose. And all VPN connections can be logged which assists in managing and maintaining the overall security of who has been remotely accessing what internal resources and when.
Anytime, anywhere access to anything is certainly one of the great promises of today’s Internet. The explosion of new offerings and apps on mobile devices offer some very enticing new options for remote access to services. Unfortunately, many of the implementations we have seen can also offer some significant challenges to your overall network security.
I encourage district administrators and their technical staff to work together to thoroughly discuss what type of remote access to any district internal system is really required to fulfill the functional need being contemplated. Given the reality that the more direct access you allow the more you increase the risk to the system and the rest of the network, the goal should be to provide the minimum required type of remote access needed to get the job done.
The team here at CSI is prepared to work with your district to facilitate these conversations and help you put in place a method of secure remote access that will let your administrators do the work they need done without introducing major new risks to your district’s networks.
Reach out to us, we are here to help.
You must be logged in to post a comment.