Is Your CPaaS Integration Opening a Data Breach?

Comparitech, a UK-based Technology Research and Evaluation company recently identified a potential data leak that could impact up to 2.8m CenturyLink customer records, though only name, address, and phone number. As a loss of data, it does not even get to the back page of the news. Names, addresses, and phone numbers are hardly private anymore.

However, in reading a bit about the leak, the culprit was a misconfigured MongoDB that was open and visible on the Internet. What makes this interesting is that MongoDB is used as the database for many of the real-time applications that I have had an architectural exposure to. Essentially, if the database is set up to be remotely accessed, it must be adequately secured.

An example of this is an attack called MongoLock that finds these exposed databases and then locks and ransoms access to the data (after locking it remotely).

Databases are used throughout CPaaS and UCaaS implementations. A developer might set up an intermediate database with all of the current records for notification. This way there can be two processes, one that populates the database with new notifications, and one that processes the notifications to the CPaaS vendor. This database could be on premises or somewhere in the cloud. If the database is compromised, all info would be also, including individual specific information in the notifications. A UCaaS database compromise could be very damaging. For example, accessing calling records or tracking/recording information of UCaaS sessions could be significant. If it also extended to recordings and analytics it could be very damaging.

Clearly, database security is yet another security issue that needs to be considered in a UCaaS analysis as well as both CPaaS vendor and implementation decisions. Understanding where your data moves to and is stored is part of the new oversight that the convergence of IT and communications is bringing us.