How would you do a heating controller, IOT client, securely?

[nctnico]

The easiest way to penetrate any company currently is to bribe or extort an employee with access to provide the information.
I assume "staff theft" is used to describe this pattern.

The only way to combat this is to assume everyone is a potential exploiter.

This, in turn, leads to sensible business practices where you do not have a single customer table exposed to your IoT server at all (for client verification purposes), and instead the IoT server only knows about client IDs and what level of service that ID is entitled to.

Most employees have no access to the customer/payment database; only those involved in payments have, and they need to be monitored for financial security anyway.

I don't think this will lead to a workable situation. If you have many devices in the field, you'll have a call center for customer service. People from this call center will need to be able to look at payment status and be able to change the state of the subscription quickly in order to keep customers happy. This is the area where the 'accounting' pillar of good security practises comes in. At some point the system will need to cross reference revenue in versus services rendered. When you break this down to an operator level, you can easely see if a call center employee is handing out too many freebees or not.

I'm not sure whether having seperated databases is a good idea. Lots of synchronisation issues. A long time ago I used stored procedures (which also did authentification) on a PostGresql database to keep an IoT device seperated from the actual database.

[Nominal Animal]

The easiest way to penetrate any company currently is to bribe or extort an employee with access to provide the information.
I assume "staff theft" is used to describe this pattern.

The only way to combat this is to assume everyone is a potential exploiter.

This, in turn, leads to sensible business practices where you do not have a single customer table exposed to your IoT server at all (for client verification purposes), and instead the IoT server only knows about client IDs and what level of service that ID is entitled to.

Most employees have no access to the customer/payment database; only those involved in payments have, and they need to be monitored for financial security anyway.

I don't think this will lead to a workable situation.

You mean, you think implementing sensible business practices requires actual experience and knowledge of how to do secure systems, and thus is too costly in your opinion?  That kind of thinking is exactly why so many peoples' personal details and credit card information has been "accidentally leaked".

People from this call center will need to be able to look at payment status and be able to change the state of the subscription quickly in order to keep customers happy.

Sure.  They have very limited access to the customer/payment database.  In that database, any change to the service status must trigger a related push to the IoT server within a guaranteed service interval, and here that could be seconds, say one minute maximum to see the server response change.

When you break this down to an operator level, you can easely see if a call center employee is handing out too many freebees or not.

That kind of thing is easily monitored automatically, and is not an actual problem in real life.

I'm not sure whether having seperated databases is a good idea. Lots of synchronisation issues.

There is no synchronization.  There is exactly one direction in which changes are pushed, and enforcing this is crucial for the security model.  If you have synchronization issues doing this you should not be doing anything with databases.

Even having the IoT server be technically capable of querying the customer/payment database for details instantly breaks the security model.  Separated databases are required for true privilege separation.  If the IoT server is technically able to access the customer information, then the customer information will be exfiltrated in the very first break of the IoT server.  In my opinion, any company that does that should get heavy penalties when that happens.

Security models that survive in the real world are those that do not assume every part in the model is secure.  They still provide security, albeit in degraded/reduced form, when invididual parts are compromised.  There are single point failure sources, like the customer/payment database implementation; minimizing both their number and access/exposure to them is at the core of proper security design.

[nctnico]

The point I'm making is that confining information to a few points is likely to end up with a system which isn't useable in a practical situation. You'd be unpleasantly surprised if you know how many people at a bank have access to your records. Same for the phone company. My assumption is that accesses are logged and audited though.

And there ain't no such thing as 'one way pushing' between systems. Synchronisation between distributed systems will fail at some point for some reason. So somewhere, somehow there needs to be a verification to make sure both databases (in case of a front / backend system with separate databases) have the same information (whether this process is hidden from the application layer or not). And what to do when the backend database is not working? Ideally the call center operator needs to have a way to see the backend is malfunctioning so there has to be some access to the backend as well from the call center. Again, you'll need information at various places. Worse if transactions need to be corrected manually. The British Post Office has learned that the hard way (see Mr Bates vs The Post Office ).

If you look at the stacked layers of a typical system you can also draw a column spanning all layers next to it. This column is called 'logging, error and exception handling' and typically ends up asking for operator intervention. Another weak point.

[Siwastaja]

So somewhere, somehow there needs to be a verification to make sure both databases (in case of a front / backend system with separate databases) have the same information

But the whole point is that the databases should have different information. If they have the same information, there is no security benefit from the separation at all and then indeed only extra complexity and syncronization issues ensue. But this wasn't at all what Nominal Animal suggested.

[nctnico]

So somewhere, somehow there needs to be a verification to make sure both databases (in case of a front / backend system with separate databases) have the same information

But the whole point is that the databases should have different information. If they have the same information, there is no security benefit from the separation at all and then indeed only extra complexity and syncronization issues ensue. But this wasn't at all what Nominal Animal suggested.

Nobody is suggesting that both databases are or should be 100% identical. Only that there is shared piece of information (a subset of all information available) between the databases which needs to be kept in sync. In case of a system with IoT devices this shared information could be about the services enabled in the IoT device.

[Nominal Animal]

My phone, electricity, and insurance companies all have web portals for payments, bills, and service status.
These obviously have access to the payment database, but with very limited privileges.  They need that access to work.

However, an electricity meter (power meter) installed at a client site will not have direct access to the customer/payment database.
It will access a separate database containing only information relevant for electricity meter operation, typically with customers identified by an arbitrary ID included in the meter.  That database is synchronized periodically with the customer/payment database.

If the electricity company provides an interface for customers to monitor their power use, that will use a yet separate database, containing only electricity usage histories (typically at reduced resolution) and no payment history.

Many legal auditability requirements can only be fulfilled by separating different parts of the services into separate databases, and periodically checking for differences, and having an exact transaction record.  Many of them are used to monitor for both technical problems as well as human operator misbehaviour.

While it is technically easiest to use a single database for everything, it also means any problem anywhere in your system is potentially catastrophic.  Yes, there are companies that operate this way, but I condemn them to hell.  There is very little difference to setting up a company that really is just a front for its executives to sell the customer information on the black market.  Ineptitude should not be a legal defense at all.

And there ain't no such thing as 'one way pushing' between systems.

Bullshit.  You typically do that via an intermediary that has very limited access to the customer/payment database (typically read-only plus delete access to a single table containing pending changes), read-write access to the IoT client database, is strictly limited in its automated actions, and leaves an auditable trail of every single transaction it makes between the two databases.  Exactly how this is set up depends on the database engine used.

It is the intermediary, via its access permissions, that provides the privilege separation between the two databases.

I would expect this to include a full state update every N hours using the same mechanism but as if all customer states had changed, with the intermediary checking for differences between the IoT database and the information from the customer/payment database, as any differences would indicate some updates were lost which should never happen.

[nctnico]

And there ain't no such thing as 'one way pushing' between systems.

Bullshit.  You typically do that via an intermediary that has very limited access to the customer/payment database (typically read-only plus delete access to a single table containing pending changes), read-write access to the IoT client database, is strictly limited in its automated actions, and leaves an auditable trail of every single transaction it makes between the two databases.  Exactly how this is set up depends on the database engine used.

It is the intermediary, via its access permissions, that provides the privilege separation between the two databases.

I would expect this to include a full state update every N hours using the same mechanism but as if all customer states had changed, with the intermediary checking for differences between the IoT database and the information from the customer/payment database, as any differences would indicate some updates were lost which should never happen.

The latter is exactly what I wrote in the part you snipped.  Indeed you'll need to read the data back from the target database in order to verify it (and take action when the verification fails). That is a bit more involved than just pushing data (one way) onto the target database and call it a day. You can only say that from a very high level functional perspective.

Still, you can ask yourself the question whether you'd actually need the second database for the IoT devices. What functionality does it add to the system? Why can't they connect with the intermediary directly and fetch data from the primary database through the intermediary?

[Nominal Animal]

Still, you can ask yourself the question whether you'd actually need the second database for the IoT devices. What functionality does it add to the system? Why can't they connect with the intermediary directly and fetch data from the primary database through the intermediary?

It provides privilege separation (principle of least privilege) in the case the IoT server is penetrated.  The separate database accessible from the IoT server limits the data that is exfiltratable in the case of full penetration of the IoT server.  It also helps avoid single point of failure.

Consider the case of the intermediary requiring updates.  Let's say that takes 15 minutes.  In your suggestion, that would mean the IoT server being down for 15 minutes.  In my case, it would mean changes in the payment database take effect on the IoT server 15 minutes (plus a bit) later.

Furthermore, consider the case where the IoT servers are geographically distributed across the world (or just a continent, if you prefer).  I for sure would consider the distributed replication of the full customer/payment database a huge risk, because there is no need.  Instead, I would only distribute the IoT service databases, with the intermediaries managing the data updates.  In the case of all IoT servers being breached, customers' payment information would be absolutely safe; additional systems not accessible by the IoT servers at all would need to be compromised for that.

(To make it clear: the intermediary is an automated process, with its own limited access to each database, which also provides an auditable trail of the changes it has applied.)