The issue of device security has once again returned to the forefront in light of the recent botnet attacks that have leveraged CCTV cameras, DVRs and other Internet of Things (IoT) devices. As a community, especially those of us who are CISSPs, it is our responsibility to think several chess moves ahead and to take deeper dives into the investigative questions that aren’t being discussed in the aftermath of such attacks.
Device security has to move beyond debate and move into action. Specifically, we need to be asking ourselves what is next and how do we counter it.
In my experience in the defense industrial base sector, or the DIB, I recall encountering on many occasions increasingly connected and intelligent CCTV cameras, fire systems (including alarms, suppression, sprinklers, etc.), and other building-attached devices and automation systems. I also noticed there is a continued lack of understanding on how truly connected at OSI layer 1 (both wired and wireless/RF), layer 2, and on occasion layer 7 these devices are.
Based on some past experience and the investigative questions I haven’t seen in the recent DDoS attacks, I have some of the following questions I believe we as a community should start looking into:
- To whom do the CCTV cameras belong?
- What facilities and assets are the CCTV cameras monitoring in real-time?
- Has anyone checked the CCTV camera configurations and internal network communications for pivot points?
- How are the cable and ISP provider DVRs talking back to the public internet?
- Are cable provider DVRs sitting in our homes using our home modems and routers as a NAT to talk directly to the internet, or are they talking back into the cable or ISP providers’ networks and reaching the internet via their networks?
- Can you access the cable or ISP providers’ networks via a rooted home DVR?
There are many questions we should be asking about device security from a broader perspective. We should avoid missing the boat on being proactive, curious and investigative. For example, when you pwn a device or host, you now have access to it, which means you can do far more than just add it to your botnet for DDoS activities.
Below are some recommendations for the industry to consider, many of which aren’t new to the infosec community:
- Evaluate I/O interfaces and protocols used to connect, monitor, configure and control devices, and use or create secure protocols and interfaces only.
- Evaluate hardware components, firmware, software, communications protocols and compatible conduits. We should validate chipset computation, use security features of RTOS, etc.
- Sign your hardware, firmware and software, and hash your binaries.
- Invest in R&D for deterministic, real-time security for low power, low memory and low processor devices.
- Create an agile security process within product design, development, testing and deployment phases.
- Create catalogs of tested and certified devices. UL CAP 2900 is a great testing and certification regimen to put devices through.
- Implement device-level authentication and authorization for machine-to-machine and human-to-machine interactions.
- Do not use hardcoded passwords and/or IP addresses. Instead, enable and enforce the changing of default credentials.
- Segment I/O interfaces to enable bus isolated out-of-band monitoring by security and safety solutions.
- Create bug bounty programs to encourage vulnerability disclosure and testing by the security community.
- OEMs need to create a 5-star rating catalog of integrators, contractors, and third-party suppliers that are trained and certified to implement their products following proper security guidelines.
- Enable customer feedback portals, so they can also report as communities of interest on emerging and evolving security needs.
There are many more steps that can and should be taken to improve device security for IoT and ICS, OT or IIoT. This list and the recent CCTV camera botnet should encourage OEMs to make device security a priority, not a continued debate. Be proactive, not reactive. Device security, or the lack thereof, should be considered a public safety hazard going forward.
This should once again be a wake-up call to the end user owners and operators who still don’t understand insecure devices are a threat to all other devices. A device does not have to be on your IT network or connecting to the internet to be a threat to your operations or other systems.
About the Author: Isiah Jones is a non-supervisory GS-2210-15 INFOSEC Specialist with an independent government regulatory agency but his opinions are his own. He has CISSP, C|CISO, GICSP and Security+ce certifications as well as a Master of Professional Studies (iMPS) degree in Homeland Security – Information Security and Forensics option and a Bachelor of Science degree in Information Sciences and Technology (both from Penn State University). Isiah was first exposed to IT back in 2004 and shifted more into security back in 2010. He’s a life learner who is concerned about the future of technology, security, risk, and information in the human context for the remainder of this 21st century and beyond.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.