Database Reference
In-Depth Information
The problem in these circumstances wasn't a data breach or lack of data security. It was that the trader was able
to subvert the process by hiding their losses. This concealment was enabled by organizational acceptance of secrecy
as being a “good thing” that did not require justification. The problem stems from the fact that the only effective
methods of securing the system depended on some level of secrecy. If security could be achieved by transparent
controls, then it would be much harder to justify inappropriate secrecy or to get away with hiding losses. There is
a growing recognition that transparent controls are needed. An example is an openly shared audit trail with good
integrity (BIBA, not BLP).
Within financial services I have also noticed a shift of focus from data security to process integrity. Instead of
keeping secrets, the focus is on preserving the integrity of processes. Avoiding fraud, corruption, incorrect valuations,
hiding of losses, requires transparency to achieve. Another organizational aspect of architecture is risk and the human
incentive to accept or mitigate a risk.
Organizational Risk Incentive
Achieving organizational risk improvements with competing department interests is not straightforward. Individual
people and business units may be willing to risk potential negative outcomes to the organization, such as a short-
term trading loss or hacked system, in order to make a more local and predictable gain in the near term. If they lose
the risk, then they may have to get another job, but if they win the risk, the short-term bonuses are significant. This
imbalance of incentives encourages individual people and sub-departments to take risks that are not beneficial for
the organization as a whole in the long term, especially risks affecting reputational damage.
In my experience it tends to be the role of compliance and separate risk departments to enforce responsible risk
management and protect the organization's reputation through the process of auditing.
Compliance and Audit
Gaining compliance is the strongest governance tool for implementing information security controls. Compliance
is a concrete pass or fail with immediate consequences. This removes the ambiguity of risk perceptions involved in
spending money to avoid being compromised, and in that sense compliance is the friend and ally of the DB security
architect. I have experienced firsthand these compliance processes.
•
SOX
- Corporate managers made responsible for accurate account keeping.
•
PCI
- Credit card transactions mainly requiring encrypted credit card numbers, with other
standard infosec measures like audit trails.
•
SAS70
- Internal controls derived from account audit world (technically flexible depending on
context).
•
Internal audit
- Very context specific and potentially very useful depending on whether the
auditor is point-scoring or able to proactively help with improvements.
Compliance to an audit standard has these drivers:
•
Sales-based
- Customer wants the accreditation in order to do business with you (SAS70)
•
Regulatory
- Needs the audit pass to keep trading (PCI for credit cards)
•
Internal risk reduction
- Internal audits from banking
It is unusual for security teams or auditors to get their hands onto databases during an audit. Auditors tend to
be dealing with report output. They do like quick overview reports and will then drill down to test the organization's
oversight ability. In EM12c there is the potential to give auditors direct access due to its read-only COMPLIANCE
AUDITOR ROLES (see later chapters).
