Useless 2FA in case of inside attacker

Question

Suppose a server-side signing scenario, where user keys are generated in a HSM and exported to a database, encrypted with a symmetric key derived from a user password and HSM's master key.

To sign, users must provide the referred password and an additional factor, like an OTP, for example. The OTP can't be used to protect the key because it's a dynamic value, so it's just used as an authorization barrier. The transmission of the two factors is done through SSL.

Now imagine a malicious inside attacker changes the application code, so the passwords the users submit get logged in a file.

Although the signing operation via the application requires 2 factors, somewhat preventing attacks from outside attackers, what can be done to prevent that an inside attacker accesses the HSM directly and decrypts a signing key with the password, and using it to sign documents on user's behalf?

Typically, physical access to HSMs is protected by dual control, but users may have logical access to HSM if they have the password to login remotely.

What kind of security measures can I implement to prevent this kind of inside attack?

Answer 1

Auditing and alerting is the general approach to insider threats.

If you make sure that activity on sensitive systems is heavily logged and monitored, you dramatically increase the difficulty of subverting those systems. Typically, you'd log and alert on any logons, and maintain an audit log of all actions taken on the system. To protect those logs from tampering, you send them to write-once media or another system that users of the sensitive system don't have access to.

Another effective, relatively cheap approach to the problem is the four eyes principle (requiring two people to oversee a given action).

Lastly, if you're worried about the integrity of your code, (or other files) you could always utilize code-signing. Attaching a cryptographic signature to whatever it is you're worried about being modified would give you a very high degree of certainty that the code isn't modified without authorization (assuming, of course, you get the PKI for that signing system setup properly).

Answer 2

Perhaps you are overthinking this. When you say:

Now imagine a malicious inside attacker changes the application code...

You are then trying to guess what the application code will be changed to, and are trying to come up with a solution for that particular change. The problem is, if they can change the code in the first place, they can change it to do many other things too, most of which you cannot predict. So even if you protect against one change, it likely won't protect against a different change.

The security measures you take to protect against an inside attack are to limit who has access to change application code in the first place, and to put a notification system in place so you immediately know if it is changed, and by whom.