FAQ Category: Security Questions

How does ObjectSpectrum protect my data?


There are a few different areas to protect:

  • Access Control/Authentication – who or what has access to that data. Depending on the specific requirements of a particular solution, that might be anything from password protection to using some type of two-factor authentication to using secure certificates for third-party API integrations. But regardless of the method that you use, to be able to authenticate the user or the third-party that wants access to the data and then make sure that – based on their authentication – they only have access to the data that they’re allowed to have access to. Who has access and how do we authenticate that they are who they say they are.
  • Industry-Standard Encryption – we use industry standard encryption wherever it is possible to do so, for both data at rest (data we’re storing in a DB) and data in transit (being transmitted somehow – over the internet, over the air, etc.). So, that includes things like using TLS (transport layer security, which is what browsers use for banking-grade secure connections) and AES encryption that is used on both live data in the database and for backup data.
  • Segregation of Data – in our shared-tenant hosting infrastructure, where we have multiple applications and customers all running within the same physical infrastructure, the architecture of Prism is such that all code and all data that is related to a specific application, and even a specific customer instance of that application, is completely isolated from all other data. That is built-in to the architecture of Prism, specifically for this purpose.

How does ObjectSpectrum secure API access to my solution?


It would almost always be over a secure, encrypted connection. It would be very strange for it to not be. We can do anything from as simple as a static, pre-shared token that could be sent as part of the API request, to various types of key or certificate-based calculated tokens, to VPNs. For API we could set up VPNs between the party that wanted to access the API and our system. That’s kind of a continuum from a static secret token to VPNs – running the gamut from simple to sophisticated.

Is IoT secure (or can IoT be secured)?


IoT – like any technology – is not necessarily inherently secure. But when you design a solution, you design it with security in mind. And that means using best practices, it means putting in an appropriate level of security for the data for the application in question, it means making sure that all of the components that are used in the solution can be secured. And so, not only is security something that was built into Prism from the ground-up, it’s an inherent part of the architecture, but we also – as part of any solution design – will incorporate security best practices and ensure that third-party components are either also incorporating those best practices or that appropriate modifications can be made to bring them up to that standard.

What options does ObjectSpectrum offer with regard to user authentication?


This answer differs based on how secure something needs to be. One of the facts in the security world is the more secure something is, the more of a pain it is for the user. Meaning, the idea is to match the level of security to whatever it is you’re trying to secure. So on one end of the spectrum, it could be as simple as a username and password. Maybe we don’t even enforce password complexity or rotation because the level of security that is needed doesn’t warrant doing anything more. But then as you increase the needed level of security, we start adding other things in like password length and complexity enforcement, two-factor authentication using text messaging with a code (like most banking apps), or authentication by push notification (where you have an app on your phone and we’re sending a push notification to that app and then the app will use biometrics (fingerprint, face recognition, whatever) or another local method on the smartphone to authenticate that it’s really you.

The same is true for third-party APIs that could be anything as simple as a secret token to something as complex as an X.509 security certificate, or methods where we exchange keys separately and then we generate a unique token for every new request. It can be made super secure, but the more secure it is, the more of a pain it is for the third party, so appropriate balance is important here, too. 

Back to all FAQs