Re: Trigger programme without a trigger.

My comments are not about the security. They are about process. When data is in error, the humans will almost surely attempt to correct it, irrespective of process established to do so. The implementor of the data correction as directed by the CFO is going to [have to] be run with the so-called HSA or a QSECOFR[esque] profile, regardless of the process that is in place, due to whatever urgency. They are not always going to call the developer, nor even wait to get a fix and/or data correction if\when they do call. To have that human implementor manage the data in the file outside of the process, outside of the-program, is not considered a security breach when directed by the /powers above/; maybe a job security issue, as in people wanting to fix the data to keep their jobs.

My point was that when the chosen [human as] implementor is not privy to the nuances of some specific program being responsible for having implemented a trigger function within, they are also going to be unaware of their having bypassed those business rules in that program by their use of SQL or DFU. However if that same implementor were to find some requirement to disable or remove a database trigger in order to effect their SQL or DFU activity, then unless they are a complete flunky that should not be doing any updates in the first place, they will realize that the work they performed probably bypassed business rules. But the most *important* point is that, if the implementor did their DFU or SQL without being privy to the existence of the database trigger, then the business rules were applied.

Regards, Chuck

Joe Pluta wrote:

CRPence wrote:

And so it is very true, that the same concern exists as an issue with the database trigger, e.g. some result is not to the satisfaction of the implementor, so when they find the trigger they CHGPFTRG to disable it while they do their magic to correct the data. However in the case of either CHGPFTRG or RMVPFTRG, the implementor should at least *know* they are bypassing the business rules. That as compared to accidentally [not "accidentally"] bypassing the business rules, which is much more likely to occur with I/O access control established outside the database. The trigger is visible, whereas an application as expected arbiter to the I/O is not so plainly obvious. The trigger can be found and subverted, but even overlooked, it is still enforced. However the application as arbiter may be easily overlooked as a result of either human error or negligence, and overlooked, it will not be enforced.

I'll disagree once more just to reiterate my point, and then move on.

It is no more likely to accidentally get around high-security access profile than it is to accidentally remove a trigger. Both require subverting security policies which *should* be incapable of being subverted. Otherwise, they're really not security policies. That either one could happen is an abject failure of the system.

Remember, I'm talking about a specific architecture in which the database can only be accessed through a specific user profile. Subverting that requires an security breach as egregious as that which would allow removing a trigger. A properly deployed security system prevents both. Improperly deployed security prevents neither.

So, in the end, the data protection aspect of trigger vs. I/O module is moot: both work exactly the same, and both depend on a properly deployed security policy. And thus the choice between the two should come down to an application-driven business decision.

This is simple stuff. Rather than designing systems based on theoretical security lapses, you should instead deploy your systems correctly. If you disagree, then fine. I can leave it at that. But it's a fallacious argument to say that triggers protect data any better than HSA profiles.

Joe