Another regulator is proffering its advice about how financial firms should deal with Cloud computing.

In a paper issued this week, the Australian Prudential Regulation Authority shares the lessons it has learnt on visits to the firms it regulates in respect of shared computer services, which include 'the Cloud.' APRA does this, however, in the most tentative language: the word 'ought' does not appear at all; the word 'should' appears only once; the word 'must' appears three times, and then only in relation to existing rules CPS 231 and SPS 231; the word 'would' appears 29 times. This seems to be a confession that the regulator still has a long way to go before it develops any real knowledge of the phenomenon.

Cloud computing is the practice of using a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server or a personal computer. APRA's paper contains a different and rather 'trippy' definition: "Cloud computing - a delivery model which leverages technologies (e.g. virtualisation and networking) to enable sharing of IT assets (hardware, software and/or data storage)."

Some people divide cloud computing into three categories: Infrastructure-as-a-Service (IaaS or the online use of hardware resources such as virtual server space and IP addresses), Platform-as-a-Service (PaaS, which allows users to create software applications using tools that the provider supplies) and Software-as-a-Service (SaaS, whereby consumers can access software apps over the Internet). A 'private cloud' involves a distinct and secure cloud based environment in which only one client-firm can operate. As with other cloud models, private clouds provide computing power as a service online but using an underlying pool of physical computing resources that might be located all around the world. Exponents of this model list its virtues as greater reliability, greater control, quicker responses to the demands of departments inside an organisation and relative safety from prying eyes, with 'cloud-bursting' (switching non-sensitive functions to a public cloud during spikes in activity) as a safety valve. The public cloud model (featuring pooled and shared physical resources, accessible over the Internet or, less often, some other public network) is what concerns APRA here. The APRA information paper focuses on ‘shared computing services,’ i.e. arrangements involving the sharing of IT assets with other parties (whether under the 'cloud' tag or otherwise). This excludes those arrangements where IT assets are dedicated to a single APRA-regulated entity (including ‘private cloud’ arrangements).

Flowery language about clouds

What has APRA gleaned on this subject on its visits to firms? It is certainly critical of the strategy that firms follow when embarking on the use of shared computing services, although it uses very flowery language that is sometimes difficult to decipher, coming out with phrases such as "an appropriate amount of rigour would typically be applied to the planning of the IT environment and the transition from current state to the desired architecture." It does make the serious point that it has seen firms basing their proposals solely on considerations of cost, "rather than a clearly defined strategy and architectural roadmap," a phrase that makes it appear (although it is impossible to tell) that it has found these companies to be rather chaotic in their choices, choosing the cheapest products and marrying them together at the last minute. It also says that "business cases and reporting to the board and/or senior management which only focuses on the benefits and do not provide adequate visibility of associated risks." Again, the language is unclear, but the reader might take this to refer to IT consultants, or even compliance officers, going to company directors with exaggerated claims for this-or-that cloud service that they are eager to have.

Governance and risk but not much compliance

In its own peculiar language, APRA appears to be exhorting companies to draw up outlines of the decision-making and overseeing responsibilities of their staff with respect to outsourcing (including the use of shared computing services). Its phrase "areas addressed typically include" seems to be code-language for "we would like you to write down..." It then refers to the role of board-members, senior managers and anyone else with a hand in governing the process, collectively calling them "the appropriate governance authority." In APRA's vaguely expressed view, this "would typically" take a view about whether "the arrangement" was being "managed" in line with the board's appetite for risk, a view that "would generally" be underpinned by some risk analysis.

APRA categorically states that it wants the "appropriate governance authority" to be informed of all material initiatives involving shared computing arrangements. This includes the receipt of information (it does not say by whom) at "significant stages" such as the identification of a "firm proposal," an unexplained phrase, and the moment when the firm in question has set up a "detailed solution" and a transition plan.

Such information includes: the alignment of the project "to strategy;" the business case for it; alternative options; the rationale for the selected solution (including a justification for additional exposures to risks); the IT assets at hand; the effect that the project is going to have on business processes, systems architecture, organisation and operating models; vague risk and control assessments; risk profiles; what to do if the worst happens; the project's relation to the company's appetite for (and tolerance of) risks; the services selected; the products and parties involved; delivery location(s); the 'due diligence' undertaken; the 'assurance' obtained; the operating model and security model to be applied, alongside associated roles/responsibilities of all parties (including handover and escalation points); whether it is in line with regulatory standards and guidance; an "architectural overview" for hardware, software and data stores; considerations about resilience, recovery and "provider failure"; organisational change management and transition planning; and the structure and schedule (including key stages and timeframes) of the project.

Security models and operating models

According to APRA, the phrase "operating model" describes processes for managing and monitoring the IT environment (both shared and dedicated components) including asset lifecycle, change, process scheduling, capacity, performance, incidents, security, access, backups and logging. The phrase "security model" means "everyting to do with security" and includes controls to isolate, delineate and protect the APRA-regulated entity’s IT assets from other parties, operational security, identity management, administration rights and management of encryption keys.

The selection process

When financial firms are selecting 'shared' IT services, APRA complains that they often bypass established risk management and outsourcing structures and whoever is in charge of the process often fails to work with the risk, security, outsourcing and assurance functions at that stage.

Buy Australian!

Interestingly, the regulator thinks that an APRA-regulated entity "would typically" (i.e. ought to) consider the benefits of purchasing "Australian hosted options, if available, in the absence of any compelling business rationale to do otherwise," as a way of reducing 'risk'. As Australia is one of the 'Five Eye' countries whose intelligence services gather data on their citizens without asking the courts, often illegally, one would have thought that 'risk' would be at its highest when data is hosted in Australia and lower almost everywhere else. APRA also floats the idea of a financial firm only sharing computing services with parties that have comparable security requirements, risk profiles and risk appetites, such as other financial firms.

Risk profiling

APRA has spotted several weaknesses among firms as they list the risks involved and assess information to gauge their severity. These are: vague descriptions of risk to start with; not enough thought being given to crucial and/or sensitive IT assets which are accessible from the shared computing service; ditto for the sensitivity of data ("collectively and at the individual field level," whatever that means); cursory risk assessments which fail to consider changes to risk profiles; and limited "due diligence and assurance" activities, with firms relying heavily on the attestations of software vendors and/or other organisations.

Transitionally speaking...

APRA wants every firm that is moving over to a shared computing service to take a cautious and measured approach. It would like (according to one interpretation of its scarcely fathomable language, at any rate) to see firms plan such a transition in definite stages. These seem to be:

• pilot projects for initiatives that are not very risky;
• an assessment of the appropriateness of the service in question and whoever is providing it;
• organisational "change management";
• assessments of any changes to risk profiles, taking the company's risk appetite into account;
• a consolidation of lessons learnt and the completion of remedial action; and
• "clear go/no-go criteria for each stage," a phrase that the regulator seems to have minted itself.

APRA says that it has observed two weaknesses at firms here: a tendency to rush the transition rather than take a cautious and measured approach; and "impediments placed on APRA access rights to the service provider."

Here the paper refers to prudential standards CPS 231 and SPS 231. CPS 231 requires an APRA-regulated entity to "identify, assess, manage, mitigate and report on risks associated with outsourcing to ensure that it can meet its financial and service obligations to its depositors, policyholders and other stakeholders." SPS 231 has an equivalent requirement for RSE licensees (the licensees of Registrable Superannuation Entities, regulated by APRA).

Under CPS 231 and SPS 231, regulated entities are required to consult APRA before signing any outsourcing arrangements involving "material business activities" in which 'offshoring' is involved.

Controls

The regulator has observed some weak controls at the firms it regulates. It complains about "inadequate consideration" of the following:

• controls to protect crucial and/or sensitive IT assets from unauthorised activity by the staff of the software provider who have highly privileged access (e.g. system administrators);
• controls relating to console system administration (either internally or externally hosted) and encryption key management;
• the protection of sensitive data, both in transit and at rest, through cryptographic techniques;
• controls to protect crucial and/or sensitive IT assets that are accessible from the shared computing service;
• the protection (e.g. using de-sensitisation) of sensitive data in non-production environments (e.g. development and test); and
• the alignment of the disaster recovery environment with the security-related requirements of the production systems.

APRA suggests that controls relating to system administration jobs could include:

• the restriction of access to the minimum time and capability required to perform an authorised activity;
• system administrators being restricted from accessing sensitive IT assets through the use of cryptographic, authentication and other techniques;
• the two-person rule to be applied to the most important activities;
• administrative tools, systems, consoles and other related software to be restricted;
• restrictions on the location and number of authorised system administrators;
• logging and other detective controls for monitoring system administrator activities; and
• back-up and log data to be protected by the segregation of administrative duties.