The landscape of IT security is changing, with two counteracting trends. From one side the threat landscape is increasing in impact, innovation and scale. Banking assets can be accessed or compromised through a combination of inadequate internal processes (permitting the theft or disclosure of data by insiders, such as at HSBC,LGT, Julius Baer, or rogue trading losses, such as at SocGen) or through use of increasingly sophisticated technology (such as the hacking of over 200,000 accounts at Citibank, the compromise of RSA’s SecureID token, etc). Destruction of key national assets is no longer limited to physical attacks, but is now in the domain of cyberspace – governments see Stuxnet as the precursor to a wider potential cyber-conflict, as the newly established high-level Cyber-hotline between the US and Russian governments attests. And the growth of industrial espionage for financial gain or competitive edge is visible even in Switzerland – one such example is the establishment in Geneva of a company offering “proactive, effective, intelligence-based approaches” to competitive due-diligence.

The second trend – that of increased focus by supervisory organs and governments on the pre-emptive management of operational risk – attests to the fear that the banking sector is vulnerable to another Black Swan event , this time in the area of operations, if banks take their eye off the ball. The term “Black Swan event” was popularised by Nassim Nicholas Taleb following the 2008 financial crisis. It refers to an event which is a statistical outlier, in terms of being extremely improbable, but with a very serious impact beyond the scope of ordinary events. Moreover while psychological bias and the non-computability of small probabilities make a Black Swan event difficult to predict, humans rationalise it in hindsight & try to build it into future predictive models.

The recent publication in June 2011 of a report on “Principles for the Sound Management of Operational Risk” by the Basel Committee on Banking Supervision, post-dating Basel III, states clearly that “sound operational risk management is a reflection of the effectiveness of the board and senior management in administering its portfolio of products, activities, process and systems” and that “supervisors should encourage banks to move along the spectrum of available approaches as they develop more sophisticated operational risk measurement systems and practices”. And the operational risk measurement methodologies and capital set-aside to counteract future operational losses mandated by Basel II still apply.

On the European level, the cost of a data breach in all industries will become more expensive end 2011 as the EU introduces a mandatory requirement to notify of data security breaches and any resulting data loss. The introduction of an enforced notification is intended to tip the scales in favour of investment in IT security, or according to Vivien Reding, the Vice President of the European Commission & EU Justice Minister to create a strong incentive for business to conduct a serious security risk assessment and to implement appropriate measures to better protect confidentiality and integrity of personal data.

So how does a bank move from the general framework prescribed by Basel to the “granularity” and level of detail required to apply this in a real-life environment? A bi-focal view is needed, where a significant level of detail per area of security must be combined into a holistic overall security framework. If we take for example the area of network security, then other regulations such as PCI-DSS plunge into precise operational detail, specifically requiring the encryption of credit card data as it passes a third-party public network. But how to comply with Basel which refers in more general terms to Best Practices? Is encrypting the credit card data on an application or database layer enough? What about other sensitive financial or corporate information? What about VoIP or video-conferencing? Common sense (and best practice) dictates that if the different buildings of the bank are physically separate but logically one domain, then the network “pipes” between them should be encrypted in their entirety, as well as the individual database fields or disparate applications. Compliance is easier to prove, as the default status is “encrypt-all”, rather than having to manage multiple exceptions in a dynamic environment as in application level encryption.

Moreover, any IT solution should be able to support the risk management processes defined by the bank in a coherent way. Technology and products should be adapted to the business processes, and not vice versa. Role-based access control should be built into the technology to ensure separation of duties, for example between the network team who manage the encryptors and the security team who should have control of the cryptographic keys, audit logs and new user creation. Moreover, IT security products should not be a black box, but should be certified to international standards. They should also provide as a core functionality the capability to monitor their own performance & compliance and audit requirements easily and transparently.

In reality, many banks still outsource core elements of their security to third parties, particularly in the area of network management . Telecoms can provide encrypted network services, but for the most part do not, preferring to offer instead standard Virtual Private Networks (VPNs). The name is undoubtedly misleading as Ethernet and MPLS VPNs have no inherent encryption, and are therefore neither secure nor private. So for core security elements a deep understanding of third-party services is required prior to outsourcing them –otherwise “counterparty” risk can be miscalculated leading to potential risk exposure. In the worst case banks can fail to acknowledge the need for network encryption at all – many still rely on the hope that their data is protected by sheer volume, or the fact that hackers have not yet bothered to tap into their optical fiber at the nearest convenient manhole. This head-in-the-sand/ignorance-is-bliss approach ignores the fact that there may already be taps on the network, with hackers or competitors happily downloading intercepted information freely and in great volume. But how would the bank even know, until the black swan event hits?

According to ISACA norms there are four potential Risk Response options: Avoid Risk, Reduce or Mitigate Risk, Share or Transfer Risk, or Accept Risk. In terms of data transfer on a public network many organizations still opt for Risk Acceptance, which means that much of their vital corporate information passes in the clear. Another option - Risk Avoidance - would mean that the bank retains all information within their own physically protected environment, an impossible feat in today’s global environment and in light of new Basel requirements to host data back-up at a minimum distance from the headquarters. The third option – Risk Transfer or Sharing – is the preferred option of many organizations, but can turn out to be illusory. Outsourcing security to a network operator does not actually transfer the responsibility or legal liability for any ensuing risks, as this is held by the bank. So technology outsourcing is not a valid Risk Transfer strategy, but simply Risk Acceptance in another form, unless the bank can ensure minimum standards of data protection by the third party. On the other hand, taking out insurance for data loss or data breaches is a valid risk transfer mechanism, but the premiums can be expensive if the data is not protected. So the best option is the application of Risk Mitigation through the judicious use of network encryption, combined with risk transfer of data breach to an insurance provider. A risk management strategy combining Risk Mitigation and Risk Transfer will generally provide the most flexible an effective results with a reasonable return on security investment.