sockets for vendor products & services

There are a number of things to think about when planning and deploying an IoT system in your institution. In posts here since last spring, several issues have been touched upon — the idea of sockets and seams in vendor relationships, the rapid growth in vendor relationships to be managed and the resulting costs to your organization, communicating IoT risk, some quick risk visualization techniques based on Shodan data, initial categorization of IoT systems, and others.  The FBI warning on IoT last week is a further reminder of what we’re up against.

There is a lot to chew on and digest in this rapidly changing IoT ecosystem. Below is a partial list of some things to consider when planning and deploying IoT systems and devices in your institution. It’s not a checklist where all work is done when the checking is complete. Rather, it is intended to be a starting list of potential talking points that you can have with your team and your potential IoT vendors.

Some IoT Planning Considerations

• Does IoT vendor need 1 (or more) data feeds/data sharing from your organization?
  • Are the data feeds well-defined?
  • Do they exist already?
  • If not, who will create & support them?
  • Are there privacy considerations?
• How many endpoint devices will be installed?
  • Is there a patch plan?
  • Do you do the patching?
  • Who manages the plan, you or the vendor?
• Does this vendor’s system have dependencies on other systems?
• How many IoT systems are you already managing?
  • How many endpoints do you already have?
  • Are you anticipating/planning or planning more in the next 18 months?
• Is there a commissioning plan? Or have IoT vendor deliverable expectations otherwise been stated (contract, memorandum of understanding, letter, other?)
  • Has the vendor changed default logins and passwords? Has the password schema been shared with you?
  • Are non-required ports closed on all your deployed IoT endpoints?
  • Has the vendor port scanned (or similar) all deployed IoT endpoints after installation?
  • Is there a plan (for you or vendor) to periodically spot check configuration of endpoint devices?
• Has the installed system been documented?
  • Is there (at least) a simple architecture diagram?
    • Server configuration documented?
    • Endpoint IP addresses & ports indicated?
• Who pays for the vendor’s system requirements (eg hardware, supporting software, networking, etc?)
  • Does local support (staffing/FTE) exist to support the installation? Is it available? Will it remain available?
  • If supporting IoT servers are hosted in a data center, who pays those costs?
    • startup & ongoing costs?
  • Same for cloud — if hosted in cloud, who pays those costs?
    • startup & ongoing costs?
• What is total operational cost after installation?
  • licensing costs
  • support contract costs
  • hosting requirements costs
  • business resiliency requirements costs
    • eg redundancy, recovery, etc for OS, databases, apps
• How can the vendor demonstrate contract performance?
  • Okay to ask vendor to help you figure this out
• Who in your organization will manage the vendor contract for vendor performance?
  • Without person/team to do this, the contract won’t get managed
• Can vendor maintenance contract offset local IT support shortages?
  • If not, then this might not be the deal you want
• For remote support, how does vendor safeguard login & account information?
  • Do they have a company policy or Standard Operating Procedure that they can share with you?
• Is a risk sharing agreement in place between you and the vendor?
  • Who is liable for what?

Typically, with the resources at hand, it will be difficult to get through all of these — maybe even some of these. The important thing, though, is to get through what we can and then be aware of and acknowledge the ones we weren’t able to do. It’s way better to know we’ve come up short given limited resources than to think we’ve covered everything when we’re not even in the ballpark.