how to approach regulatory compliance with public cloud … · 2018-12-04 · how to achieve mas...

How to approach Regulatory Compliance with Public Cloud Services

www.citihub.com

Demonstrating a Proof Point with Amazon Web Services and the Monetary Authority of Singapore’s Technology Risk Management Guidelines

How to achieve MAS TRM Compliance with Amazon Web Services

CONTENTS

3 Executive Summary

4 Highlights

5 Method & References

5 Overview of MAS’s TRM Guidelines

7 Summary of MAS’s TRM Guidelines

9 MAS TRM Sections 1 & 2: The Need for IT Controls

11 MAS TRM Section 3: Leadership and Oversight

13 MAS TRM Section 4: Technology Risk Management Framework

15 MAS TRM Section 5: IT Outsourcing

19 MAS TRM Section 6: Technology Acquisition

21 MAS TRM Section 7: IT Service Management

24 MAS TRM Section 8: Reliability, Availability and Recovery

27 MAS TRM Section 9: Security Management of Operational Infrastructure

31 MAS TRM Section 10: Data Centre Protection and Controls

33 MAS TRM Section 11: Access Controls

35 Conclusion

35 Authors and Contributors

2

Disclaimer: Citihub Consulting does not warrant that the information in this whitepaper is either complete or that it should be relied on, in part or in whole, to ensure regulatory compliance or to protect the integrity of business systems.


cloud services. The level of necessary change though, will be on a sliding scale relative to the architectures deployed and the sensitivity and criticality of workloads being hosted in the cloud environment.

Predicting how far and how quickly MAS will move on the cloud model is difficult. Banks are testing MAS with lower criticality workloads initially (e.g. stateless web tier or grids) and will build up to architectures involving sensitive and then confidential data, which may be a multi-year process to. It may also be true that smaller FIs who struggle with the cost and complexity of compliance find it easier to run secure and resilient applications in the cloud in the future. At some point for these FIs, regulators like MAS may consider them to be of lower risk in a cloud model with a security-focused provider like AWS.

Financial institutions must adapt existing IT Service Management routines for the cloud environment and make changes to policies, operating model, processes, governance, culture, and strategy.

Looking more broadly across the globe, the industry would greatly benefit from cross-jurisdictional alignment of policy between regulators on matters such as cloud. Setting a clearer, more consistent operating bar for FIs’ adoption of cloud services would enable far greater efficiencies to be achieved in an industry that desperately requires lower capital and operating expenses. Within the US, the Federal Government has aligned around NIST Special Publication 800-53 for its FedRAMP standard with 325+ specified controls. We would welcome a technically progressive regulator such as MAS to provide clear direction leveraging international standards (whether SOC, ISO, NIST etc.) and to work with other regulators, at least within the APAC region, to sponsor alignment.

Executive Summary

The Financial Services Industry (FSI) is on the cusp of a global wave of cloud services adoption that will see new technology delivery models applied to support a growing range of applications. As part of that trend, financial institutions (FIs) will need to convince regulators that cloud adoption does not compromise their ability to manage risks relating to systems availability and information security.

Given that challenge, Citihub chose to demonstrate a proof point for the maturity of cloud delivery models in servicing FSI requirements. We picked a regulatory regime that has been progressive in defining and controlling IT risk – The Monetary Authority of Singapore (MAS) – and mapped MAS’s Technology Risk Management (TRM) Guidelines to the capabilities of a leading provider of cloud technologies, Amazon Web Services (AWS). Despite being regarded as an opponent of cloud computing by many, MAS announced to Association of Banks for Singapore (ABS) in November 2013, that in concept, it supported cloud computing adoption for banks and other financial institutions in Singapore.

Our research concluded that AWS has a mature culture and environment of control, and the platform could be considered at least as secure as a typical global bank. This provides a solid foundation for a regulatory engagement. That said, the AWS model is one of shared responsibility and accountability remains with the FI, which is in line with regulatory positions on outsourced services.

However, this cannot be viewed in the same way as traditional IT Outsourcing (ITO), as clients cannot expect tailored service levels and negotiated liabilities in a direct relationship. Instead, AWS provides utility-style foundational services and building blocks that allow the FI (or a third party providing a layer of services between AWS and the FI) to broker and manage services in a well-controlled manner.

To ensure on-going regulatory compliance and to satisfy their own risk management duty of care, FIs must adapt existing IT Service Management routines for the cloud environment and make changes to policies, operating model, processes, governance, culture, and strategy, as the internal organisation adapts to becoming both a broker and integrator of

3

How to achieve MAS TRM Compliance with Amazon Web Services4

• Transparency• Does MAS perceive the FI to have sufficient• transparency into the way AWS provides services • and especially to the location of its data? AWS• customers can select the Region(s) in which their• data is stored but the physical data centre (DC) • locations within Regions are not disclosed to• customers. Similarly AWS does not disclose• services that it outsources to third parties.

• Data Co-Mingling• The FI will need to demonstrate to MAS that• sufficient isolation is achieved through a• combination of AWS’s service designs (e.g. • hypervisor-level privilege restrictions) and FI• controls (e.g. application level encryption), or • through leveraging dedicated environments • within Customer Virtual Private Clouds (VPCs).

• Portability• The FI’s ability to affect system recovery in• situations where AWS services are not available. • And the FI’s ability to migrate away from AWS• services to alternative services, should the need • arise in the future.

• Governance• Both inward facing governance (controlling • how and when to use AWS services) and external• facing governance (taking responsibility for• understanding the compliance and security • posture of AWS).

• Service Management Integration & Engagement• AWS is designed around a utility-style model• that minimises human intervention but time• critical functions (e.g. the recovery of critical • systems) require direct human engagement to• facilitate communications. MAS will want to see• that the FI has designed an effective operating• model including monitoring visibility and• service management workflows that deal with• the unique properties of the cloud model.

• Rapid Application Development• MAS will be keen to see that effective controls• are placed around developers or even DevOps• groups operating in an agile mode exploiting • time-to-market advantages of the cloud model.

• Concentration Risk• MAS will be concerned about the risk of too• many FIs hosting critical applications with a• single cloud vendor. However, this is a similar • situation that might exist today with multiple • FIs hosting critical infrastructure with co-location• data centre providers.

Highlights

Citihub believes that AWS’s risk and security posture combined with the right IT governance and controls within a FI can help alleviate regulatory concerns relating to adoption of cloud services.

However, we anticipate that the most contentious conversations with MAS, and other financial regulators, will involve:


Overview of MAS’s TRM Guidelines

In June 2013, the MAS released the latest version of its TRM Guidelines. Formally, only the Notice is legally enforceable but there are reasons that most FI’s also treat the Guidelines as mandatory:

• Section 9 of the Notice reads: “A bank shall • implement IT controls to protect customer • information from unauthorised access or • disclosure”. The implied answer is that you need to • implement the Guidelines for relevant systems. • FIs are being inspected against the Guidelines. • A poor inspection could result in a downgraded • risk rating for the FI. The effect is that • implementing the Guidelines has become an • imperative for many businesses.

In this version, the MAS has begun to explicitly address compliance Guidelines around the cloud delivery model, as a subset of IT outsourcing risks.

In Section 5, Management of IT Outsourcing Risks, the Guidelines declare,

Methods & References

We have created a full TRM mapping reference guide, which is a line-by-line correlation of MAS guidelines to AWS controls and FI actions. As part of this process we have extensively reviewed available AWS documentation. The following publicly available AWS documents were used extensively in the creation of this report and in many cases have been directly quoted in following Sections titled ‘The AWS Control Environment’.

• ‘Amazon Web Services: Overview of Security Processes’ whitepaper. Available at http://aws.amazon.com/security/ • ‘Amazon Web Services: Risk and Compliance’ whitepaper. Available at http://aws.amazon.com/compliance/

This paper is the independent work of Citihub, and all opinions and conclusions in this paper are our own.

5

In Section 5.1, the Guidelines add,

“Cloud computing is a service and delivery model for enabling on-demand network access to a shared pool of configurable computing resources (servers, storage and services). Users of such services may not know the exact locations of servers, applications and data within the service provider’s computing

infrastructure for the hosting, storing or processing of information.

In performing its due diligence for all forms of outsourcing arrangements, the FI should be aware of cloud computing’s unique attributes and risks especially in areas of data integrity, sovereignty, co-mingling, platform multi-tenancy, recoverability and confidentiality, regulatory compliance, auditing and data offshoring.

As cloud computing service providers may adopt multi-tenancy and data co-mingling architectures in order to process data for multiple customers, the FI should pay attention to these service providers’ abilities to isolate and clearly identify its customer data and other information system assets for protection.”

“The board of directors and senior management should fully understand [and monitor] risks associated with IT outsourcing… IT outsourcing should not result in any weakening or degradation of the FI’s internal controls… The FI should require the service provider to implement security policies, procedures and controls that are at least as stringent as it would expect for its own operations…”


In effect, the Guidelines acknowledge the risks inherent in a shared responsibility model where an FI outsources some of its IT operations and controls, but maintains accountability for the overall solution.

As such, it is critical for the leadership, management, and execution teams of all FIs to fully understand:

1. the risks in the cloud operating model 2. the controls that AWS has put in place to enable compliance 3. their oversight and operational responsibilities as an AWS customer

This paper and the underlying reference mapping provide a baseline through which to address the MAS Guidelines. As part of that, the document addresses the MAS Guidelines one TRM section at a time. Each section is broken into three parts:

• An explanation of the TRM Guidelines • The AWS control environment • The responsibilities of the FI

In addition, Citihub has separately proposed a Cloud Governance Framework (CGF) that deals with the specific organisational structures and routines needed to support shared governance, though not specific to AWS.

In particular, this document makes reference to the Global Cloud Governance Forum (GCGF), which is defined in the GCF and details a structure and set of workstreams required to ensure that using cloud resources delivers strong ROI.

Interested leaders should review the CGF and the GCGF as a supplement to this whitepaper. For more information, please contact us at [email protected]

6


Summary of MAS TRM Guidelines

# Section Summary

1 Introduction The importance of IT as a key enabler of business strategies.

2 Applicability of the Guidelines The objective of the Guidelines is to promote the adoption of sound practices and processes for managing technology but should be taken in the perspective of relevant regulatory requirements and industry standards.

3 Oversight of Technology Risks by Board of Directors and Senior Management

The importance of executive accountability for IT risk and effective governance.

4 Technology Risk Management Framework

The need for a systematic and consistent framework guiding internal risk management practices and controls, including: i) Protection of information system assets ii) Risk identification iii) Risk assessment iv) Risk treatment v) Risk monitoring and reporting

5 Management of IT Outsourcing Risks

Specifies guidelines around cloud related risks including: data integrity, sovereignty, co-mingling, platform multi-tenancy, recoverability and confidentiality, regulatory compliance, auditing and data offshoring.

6 Acquisition and Development of Information Systems

Controlling risk through the development of applications or acquisition of third party software, particularly relating to security vulnerabilities.

7 IT Service Management Service Management governance and controls particularly relating to change management, software release management, incident and problem management as well as capacity management.

8 Systems Reliability, Availability and Recoverability

Design and management of reliability, availability and disaster recovery planning and testing.

9 Operational Infrastructure Security Management

The implementation of security solutions at the data, application, database, operating system and network layers to adequately address and contain cyber-attacks include phishing, denial of service attacks, spamming, sniffing, spoofing, hacking, key-logging, middleman interception, and other malware attacks from mutating virus and worms.

10 Data Centres Protection and Controls

As FIs’ critical systems and data are concentrated and maintained in the DC, it is important that the DC is resilient and physically secure from internal and external threats.


# Section Summary

11 Access Control MAS focuses on three of the most basic internal security principles for protecting systems: a. Never alone principle b. Segregation of duties principle c. Access control principle

These internal control principles can be adapted depending on separation of responsibilities, division of duties, environmental variables, systems configurations and compensating controls, where relevant, physical security is imputed in applicable control principles and practices.

12 Online Systems Security This section pertains to security strategy and measures related to internet based eCommerce systems. We believe this section is inherently covered throughout the rest of the document and so have not included a specific section for it.

13 Mobile Online Services and Payments Security

Out of scope of this research paper.

14 IT Audit The establishment of an independent and objective internal IT Audit function and internal control systems to manage technology risks.

We have not included a specific section for IT Audit as this function will already exist in the FI and its incremental duties in the cloud model are covered through this paper.


AWS communicates its security and control environment relevant to customers by doing the following:

• Obtaining industry certifications and independent • third party attestations including SOC 1/SSAE • 16/ISAE 3402 (formerly SAS 70 Type II), SOC 2, • SOC 3, FISMA, DIACAP and FedRAMP, PCI DSS • Level 1, ISO 27001, ITAR and FIPS 140-2 • Publishing information about the AWS security • and control practices in white papers and website • content • Providing certificates, reports and other • documentation directly to AWS customers under • NDA (as required) • Providing resources such as the Auditing Security • Checklist to help customers optimise the • environment and govern effectively

MAS TRM Sections 1 & 2:The Need for IT Controls

Understanding the MAS Guidelines

In Section 1 & 2 of the MAS TRM Guidelines from June 2013, MAS acknowledges that the Financial Services Industry (FSI) faces unique challenges in the management of their IT platforms.

• IT has a profound impact on the business • The IT platform must handle increasingly complex • business requirements • Customers are demanding that their FIs keep pace • with the rapidly evolving IT industry, and this • introduces significant new risks

Given this context, MAS recommends that all FIs establish a sound and robust TRM framework that strengthens system security, reliability, resiliency and recoverability, and protects customer data, transactions and systems.

The AWS Control Environment

AWS acknowledges the importance of IT as a key enabler for business strategies and has adopted a Customer/AWS shared responsibility model that extends to IT controls. Just as the responsibility to operate the IT environment is shared between AWS and its customers, so too is the management, operation and verification of IT controls.

AWS’s part in this shared responsibility includes providing its services on a highly secure and controlled platform and providing a wide array of security features that customers can use. For example, taking AWS EC2 infrastructure as a service offering, AWS maintains responsibility for security up to the hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualisation security. The FI, in turn, is responsible for security controls that relate to the IT system (instance) including the operating system, applications, and data.

9

In our opinion, AWS’s TRM framework and culture meet MAS’s expectations of a FI and its outsource providers.

However, FIs should:• Continue to take direct responsibility for controls• above the hypervisor layer, extending their own• best practices, policies and controls into the AWS• environment while addressing the additional• complexities introduced through the cloud model

• Monitor the AWS controls at and below the• hypervisor layer ensuring they are satisfied with• ongoing operational control and audits

• Ensure they have the ability to access independent• audit reports that meet the objectives of MAS TRM• Guidelines

• Develop skills and dedicate resources to perform• sufficient control evaluation and verification• procedures


The FI Control Environment

With that said, as part of the shared responsibility model, AWS Customers have a critical role to play.

For example, FIs must develop the skills and dedicate resources to perform sufficient control evaluation and verification procedures to be comfortable with retaining accountability for their resources in the cloud.

As mentioned earlier, as part of the Citihub Cloud Governance Framework, we recommend that each firm commissions its own GCGF. The GCGF should assign responsibility for control evaluation and verification internally, and coordinate reviews.

In defining the commercial relationship with AWS, it is important for the GCGF to ensure the FI has access to independent audit reports that meet the objectives of MAS TRM, and engage and educate MAS about their contents and effect.

That said, as mentioned earlier, it is our opinion that the internal and external audit processes that AWS undergoes meet MAS TRM Guidelines. Thus, while there will certainly be an initial phase of close scrutiny as part of new relationship building, leadership should plan to rely more on the regular industry-standard audits that are part of AWS’s Standard Operating Procedures.

10


white paper at http://aws.amazon.com/compliance/

The culture begins with the AWS board and senior management, who are accountable for IT risk and controls, and who play important roles in establishing the company’s tone and core values.

Overall, the AWS organisational structure provides a framework for planning, executing, and controlling business operations. The organizational structure defines and assigns roles and responsibilities to provide for adequate staffing, efficiency of operations, and the segregation of duties.

AWS has also established an information security framework and policies based on the Control Objectives for Information and related Technology (COBIT) framework and has effectively integrated the ISO 27001 certifiable framework based on ISO 27002 controls, American Institute of Certified Public Accountants (AICPA) Trust Services Principles, the

MAS TRM Section 3:Leadership and Oversight


In Section 3, the TRM Guidelines declare that today, the IT Infrastructure of banks is critical to the business but leaves it to banks to identify which systems are critical.

Given the potential criticality of IT, the TRM Guidelines note that the accountability for the operations of the IT platform rests with the board of directors and senior management.

As part of this responsibility, leadership is accountable to ensure that the IT platform, and the risk inherent in the platform, are effectively managed. Effective management is defined as coverage across four leadership streams:

• People Selection • Roles and Responsibilities • IT Security Awareness and Training • Policies, Standards and Procedures


In the same way that a FI must ensure strong leadership across risk, security and compliance, AWS has in place a mature and encompassing controls culture that is regularly reviewed by independent external auditors during audits for SOC, PCI DSS, ISO 27001 and FedRAMP compliance. For up to date information, refer to the AWS Risk and Compliance

11

In our opinion, AWS’s leadership control and oversight meet the expectations of the MAS TRM.

However, FIs should:• Formally define and internally propagate a • cloud enterprise architecture strategy and • cloud-specific enterprise requirements, as well • as regularly review a register of cloud-related • risks

• Create a GCGF with: a charter that makes it• responsible for the execution of cloud strategy• and controls; a membership with the ability to• enforce said strategy and controls; and ongoing• judgement of AWS’s risk and security posture

• Bolster existing staff selection, management, • training and on-boarding processes with cloud• enterprise requirements

• Budget for resources to manage AWS client-• facing control tools like IAM and AWS Trusted • Advisor

“When critical systems fail and customers cannot access their accounts, a FI’s business operations may immediately come to a standstill. The impact on customers would be instantaneous, with significant consequences to the FI, including reputational damage, regulatory breaches, revenue and businesses.”

”The board of directors and senior management should have oversight of technology risks and ensure that the organisation’s IT function is capable of supporting its business strategies and objectives.”


the establishment of a GCGF, ideally with the involvement of their strategic cloud partners which is responsible for the execution of cloud strategy and controls and has members with sufficient internal power to enforce strategy and controls.

Deployment in the AWS cloud gives enterprises different options to apply various types of controls and various verification methods. Thus, this forum should make tactical decisions and communicate those enterprise requirements out to on-the-ground technologists. In addition, beyond receiving audit reports from AWS, the GCGF should have a senior-to-senior level relationship with the AWS support organisation in order to receive updates about controls and provide feedback.

With regards to People & Training, the FIs leadership must continue the careful selection and training of staff, vendors and contractors to minimise technology risks, especially due to system failure, internal sabotage or fraud.

However, as the FI moves further into the AWS platform, people-related processes such as selection, management, training, and off-boarding should be regularly-updated with cloud enterprise requirements, especially around cloud security and relevant cloud controls. Note that because of the simplicity of the AWS environment, it is tempting for employees to become over-reliant on AWS controls. Thus, it is important that training reinforces the importance and execution of FI-specific controls around cloud governance. AWS provides a number of training programs which can be used to prepare staff for proficient use of AWS services.

Further, the GCGF should have a work-stream focused on client-facing AWS Control Tools such as Trusted Advisor and AWS IAM. The AWS Trusted Advisor is a service available to customers with business-level and enterprise-level support. It can help identify security gaps as well as cost saving, performance and reliability improvement. The AWS IAM, on the other hand, provides fine-grained access control for Cloud resource management.1 Using IAM, the FI can automate the implementation of policies such as adherence to corporate standards e.g. by restricting the choice of available server images to those built and certified by the FI.

PCI DSS v3.0 and the National Institute of Standards and Technology (NIST) Publication 800‐53 Rev 3 (Recommended Security Controls for Federal Information Systems).

These Frameworks, including the policies and procedures are at least in-line with good FI practices.

The collective control environment encompasses the people, processes, and technology necessary to establish and maintain an environment that supports the operating effectiveness of AWS’s control framework. In addition, systems within AWS are extensively instrumented to monitor key operational and security metrics. Alarms are configured to automatically notify operations and management personnel when early warning thresholds are crossed on key metrics. When a threshold is crossed, the AWS incident response process is initiated. The Amazon Incident Response team employs industry-standard diagnostic procedures to drive resolution during business impacting events. Staff operates 24x7x365 coverage to detect incidents and manage the impact to resolution.

Acknowledging the shared responsibility of the cloud model, AWS also provides a wide range of information regarding its IT control environment to customers through white papers, reports, certifications, and other third-party attestations. This documentation assists customers in understanding the controls in place relevant to the AWS services that they use and how those controls have been validated. This information also assists customers in their efforts to account for and to validate that controls in their extended IT environment are operating effectively. As a result, although customers’ key controls may be managed by AWS, the control environment can still be a unified framework where all controls are accounted for and verified as operating effectively.


FIs will already have IT governance in place and this needs adapting to suit the unique challenges in the cloud model. The highest level of local executives will need to take responsibility for decisions relating to risk involving sensitive and confidential data. Citihub also recommends

12

1 Host access is operating-system based and customers should follow best practices by using a Bastion host to gain OS-level access to EC2 instances. Not only will this allow more stringent control in firewall (Security Group) access, it also enables the logging of audit trail for all access.


Clients have transparency into the audits and policies, as well as transparency into where their own systems and data will reside and what happens to the data through its life cycle.

MAS TRM Section 4:Technology Risk Management Framework


In Section 4 of the MAS TRM, Guidelines MAS notes that they expect FIs to have in place a Technology Risk Management Framework to manage technology risks in a systematic and consistent manner. According to the TRM Guidelines, the Framework should encompass the following attributes:

• Roles and responsibilities in managing technology • risks • Identification and prioritisation of information • system assets and a clear policy on information • system asset protection • Identification and assessment of impact and • likelihood of current and emerging threats, risks • and vulnerabilities • Implementation of appropriate practices and • controls to mitigate risks • Periodic update and monitoring of risk assessment • to include changes in systems, environmental or • operating conditions that would affect risk analysis • Effective risk management practices and internal • controls should be instituted to achieve data • confidentiality, system security, reliability, resiliency • and recoverability in the organisation


AWS’s risk management framework is in line with COBIT and will be recognisable to a financial services organisation as a well-controlled environment in line with regulatory expectations of financial services.

AWS controls access to its own physical and logical assets, and the logical assets of its customers through stringent policies and systems that are subject to verification through external audits, along with regular vulnerability testing.

13

In our opinion, AWS’s TRM Framework, including roles and responsibilities, identification and prioritisation of assets, and risk identification, assessment, controls, and monitoring meet the expectations of the MAS TRM, including those around data confidentiality, system security, reliability, resiliency and recoverability in the organisation. AWS’ standards and policies for risk management are consistently implemented globally across all their Regions.

However, FIs should:• Fully understand the AWS TRM Framework and• supporting processes and should annually review• the SOC 1, SOC 2 audit report, and PCI DSS and • ISO 27001 certifications that are available under • NDA

• Have a mechanism to integrate a relevant view of• AWS platform risk with in-house risk registers in• order to have a complete picture of risk, and• should have a forum to share and agree on • resolution plans

• Subscribe to Premium Enterprise Support in order• to ensure a coordinated approach to customer-• impacting change and issues resulting from• changes (whether initiated by the FI or AWS)

• Develop a plan to respond to potential breaches of• the FI’s environment and test the plan annually

• Harmonise risk assessment approaches, with • consistency in impact analysis criteria and• definition of likelihood and jointly develop risk• scenarios for the cloud service



FI’s existing risk management frameworks will provide a baseline structure, policies and controls to manage risks above the hypervisor level.

FIs retain direct ownership of their data (content) and are responsible for assessing and managing risk associated with the workflows of their data to meet their compliance needs.

FIs must be familiar and up to date with AWS audits, policies, controls, processes and tools etc. to satisfy themselves with the level of risk inherent in the cloud model and include any identified risks within their own risk portfolio.

The FI should also have redundancies and buffer/barrier points in place to mitigate serious risks as measured by high or medium likelihood and high impact.

The FI must fully understand the AWS TRM Framework and support processes. In particular, the GCGF should annually review the SOC1, SOC2 audit reports as well as the PCI DSS audit reports and ISO 27001 certifications that are available under NDA.

Further, the FI should have in place a mechanism (feed) to combine AWS-related risks with other platform risks (such as application risk). In particular, it is critical to agree to the prioritisation of risk resolution where risks have business impact.

Also, FIs should request advanced permission to conduct AWS vulnerability/ penetration testing of their cloud infrastructure (limited to each customer’s instances and in such a way that does not violate the AWS Acceptable Use Policy) on a regular basis.

Finally, FIs should have a mechanism to be aware of, and propogate details about, major changes that have impact. Citihub recommends that FIs subscribe to Premium Support offerings that include direct communication with the FI support team and proactive alerts for any FI impacting issues.

The AWS Security Organisation is guided by global compliance and security standards.2 In our view, AWS controls provide reasonable assurance that data handling between customers’ point of initiation to AWS resources is secured and mapped accurately.

AWS management has also developed a strategic business plan that includes risk identification and the implementation of controls to mitigate or manage risks.

As part of that plan, AWS has also implemented a formal, documented risk assessment policy that is updated and reviewed at least annually. This policy addresses purpose, scope, roles, responsibilities, and management commitment. In alignment with this policy, an annual risk assessment which covers all AWS regions and businesses is conducted by the AWS Compliance team and reviewed by AWS Senior Management. This is in addition to the certification, attestation and reports that are conducted by independent auditors. For up to date information, refer to the AWS Risk and Compliance white paper at http://aws.amazon.com/compliance/

Supporting this process, as mentioned earlier, AWS utilises a wide variety of automated monitoring systems, documentation, and a support organisation to provide a high level of service performance and availability.

Finally, at the customer level, AWS has also implemented various methods of external communication to support its partner base and the community. For example, mechanisms are in place to allow the customer support team to be notified of operational issues that impact the partner experience. The “Service Health Dashboard” is provided by the customer support team to alert customers of any issues that may be of broad impact.

14

2 Frameworks and policies are based on the COBIT framework and have effectively integrated the ISO 27001 & 27002 controls, the AICPA Trust Services Principles, the PCI DSS v2.0, and the NIST Publication 800‐53 Rev 3 (Recommended Security Controls for Federal Information Systems). In addition, the AWS Risk Management framework is reviewed by independent external auditors during audits for our SOC, PCI DSS, ISO 27001 and FedRAMP compliance.


In particular, the FI should require the service provider to employ a high standard of care and diligence in its security policies, procedures and controls to help protect the confidentiality and security of its sensitive or confidential information, such as customer data, computer files, records, program objects and source codes as well as business continuity and recovery.

MAS TRM Section 5:IT Outsourcing


In Section 5 of the MAS TRM, MAS explains its expectations for IT outsourcing, and specifically, cloud. Ultimately, IT outsourcing should not result in any weakening or degradation of the FI’s internal controls. The FI should require the service provider to implement policies, procedures and controls that are at least as stringent as it would expect for its own operations.

15

• Define and execute enterprise requirements and• cost optimisation around region management –• especially with regard to cross-border data• requirements

• Consider using single-tenant dedicated resource• options with particularly sensitive data

• Consider the use of strong encryption for data• in transport and at rest through the AWS• infrastructure. Choose storage with data • dispersion when available and remember that • most large data security breaches are the result • of poor application security or through internal • security loopholes.

• Encryption keys should be escrowed locally,• and when possible maintained locally

• Acquire dedicated resources and skill sets in key• management and CloudHSM. Define, propagate• and support encryption-specific enterprise• requirements

One of MAS’s main areas of concern in the cloud model is ‘data co-mingling’. AWS addresses this through customised hypervisor-level segregation with guest OS and applications running at progressively lower levels of privilege. On top of this, there is no customer access to raw disk devices. Customers can choose to provide additional protection by having Direct Connect and dedicated instances (i.e. reducing the extent of co-mingling) and by encrypting data.

FIs should:• Explore less sensitive, non-critical workloads with• the regulators first, and build up confidence to• explore more sensitive or critical workloads in a• multi-tenancy environment

• Ensure they have access to independent audit • reports that meet the objectives of MAS TRM, and• engage and educate MAS about AWS’s rigorous• and regular audit program and the contents and • effect of the audit information AWS makes• available to customers under NDA

• Engage internal audit, security, legal and• procurement departments to assess AWS’s service• level agreements and legal terms during the due• diligence and contracting process


The HypervisorAmazon EC2 currently utilises a highly customised version of the Xen hypervisor, taking advantage of para virtualisation (in the case of Linux guests). Because para virtualised guests rely on the hypervisor to provide support for operations that normally require privileged access, the guest OS has no elevated access to the CPU. The CPU provides four separate privilege modes: 0-3, called rings. Ring 0 is the most privileged and 3 the least. The host OS executes in Ring 0. However, rather than executing in Ring 0 as most operating systems do, the guest OS runs in a lesser-privileged Ring 1 and applications in the least privileged Ring 3. This explicit virtualisation of the physical resources leads to a clear separation between guest and hypervisor, resulting in additional security separation between the two.

Instance IsolationDifferent instances running on the same physical machine are isolated from each other via the Xen hypervisor. Amazon is active in the Xen community, which provides awareness of the latest developments. In addition, the AWS firewall resides within the hypervisor layer, between the physical network interface and the instance’s virtual interface. All packets must pass through this layer, thus an instance’s neighbours have no more access to that instance than any other host on the Internet and can be treated as if they are on separate physical hosts. The physical RAM is separated using similar mechanisms.

Customer instances have no access to raw disk devices, but instead are presented with virtualised disks. The AWS proprietary disk virtualisation layer automatically resets every block of storage used by the customer, so that one customer’s data are never unintentionally exposed to another. AWS recommends customers further protect their data using appropriate means. One common solution is to run an encrypted file system on top of the virtualised disk device.

Host Operating SystemAdministrators with a business need to access the management plane are required to use multi-factor authentication to gain access to purpose-built administration hosts. These administrative hosts are systems that are specifically designed, built, configured, and hardened to protect the management plane

In support of that goal, MAS expects that boards and senior managers complete proper due diligence to ensure that they fully understand risks associated with IT outsourcing.

As part of this, the Guidelines recommend that:

• Contractual terms and conditions governing the • roles, relationships, obligations and responsibilities • of all contracting parties are set out fully in written • agreements • SLA metrics are tracked and monitored • The service provider will grant access to all parties • nominated by the FI to its systems, operations, • documentation and facilities in order to carry out • any review or assessment for regulatory, audit or • compliance purposes • In the event of contract termination with the • service provider, either on expiry or prematurely, • the FI should have the contractual power and • means to promptly remove or destroy data stored • at the service provider’s systems and backups

Crucially, with respect to cloud computing, the TRM observes that service providers may adopt multi-tenancy and data co-mingling architectures in order to process data for multiple customers, and that FIs must understand the risks. This will be one of the main points of focus for MAS and other regulators especially with respect to sensitive and confidential data.


AWS customers designate in which physical region their data and servers will be located and AWS will not move customers’ content from the selected regions unless required to comply with the law or requests of government entities. A region does not span beyond a country’s borders, hence protecting data sovereignty within the jurisdiction of a regulator. AWS errs on the side of caution protecting customer privacy and claims to be vigilant in determining which law enforcement requests they must comply with.

It is possible to have single tenancy instances of EC2 within a customer defined VPC, providing isolation at the hardware level. Default AWS services though are multi-tenancy relying on hypervisor-level segregation between customers.

16


are all signed by Amazon Secret Access Key, which could be either the AWS Accounts Secret Access Key or the Secret Access key of a user created with AWS IAM. Without access to your Secret Access Key, Amazon EC2 API calls cannot be made on a customer’s behalf. In addition, API calls can be encrypted with SSL to maintain confidentiality. Amazon recommends always using SSL-protected API endpoints. AWS IAM also enables customers to further control which APIs a user has permissions to call.


Data protection is the regulators main area of concern in the cloud model and FIs will need to explore less sensitive, non-critical workloads with the regulators first, and build up confidence to explore more sensitive or critical workloads in a multi-tenancy environment. The FI takes accountability for effective system and data architecture and appropriate use of AWS services and controls to ensure compliance. AWS customers designate in which physical region (regions do not cross country boundaries) their data and their servers will be located, and this is important for regulators.3 They will also want to see that nobody (e.g. FI or AWS technical support) has access to confidential data across relevant jurisdictions.

It is a best practice to deploy servers without any remote console access thus avoiding risk of malicious access.

It is likely that MAS will require defensible encryption to be proven for sensitive or confidential data in transit and at rest, managed at the application level by the FI. Encryption at the disk level can be done strongly and with minimal impact on performance. However, anyone who is, or who breaks in and becomes, an authorised user will receive the information unencrypted, so the value of disk encryption is limited. It can still be useful for protecting data that is not considered sensitive by the application, and therefore remains unencrypted but providing contextual data that may one day be useful to someone with malicious intent.

Also note that AWS has the internal mechanisms and processes in place to provide compliant levels of data

of the cloud. All such access is logged and audited. When an employee no longer has a business need to access the management plane, the privileges and access to these hosts and relevant systems are revoked.

Guest Operating SystemVirtual instances are completely controlled by the customer. Customers have full root access or administrative control over accounts, services, and applications. AWS does not have any access rights to instances or the guest OS. AWS recommends a base set of security best practices to include disabling password-only access to guests, and utilising some form of multi-factor authentication to gain access to instances (or at a minimum certificate-based SSH Version 2 access). Additionally, customers should employ a privilege escalation mechanism with logging on a per-user basis. For example, if the guest OS is Linux, after hardening their instance, customers should utilise certificate-based SSHv2 to access the virtual instance, disable remote root login, use command-line logging, and use ‘sudo’ for privilege escalation. They should also generate their own key pairs in order to guarantee that they are unique, and not shared with other customers or with AWS.

AWS also supports the use of the Secure Shell (SSH) network protocol to enable customers to log in securely to UNIX/Linux EC2 instances. Authentication for SSH used with AWS is via a public/private key pair to reduce the risk of unauthorised access to instances. They can also connect remotely to Windows instances using Remote Desktop Protocol (RDP) by utilising an RDP certificate generated for their instance.

Customers also control the updating and patching of guest OS, including security updates. Amazon-provided Windows and Linux-based AMIs are updated regularly with the latest patches, so if they do not need to preserve data or customisations on running Amazon AMI instances, they can simply re-launch new instances with the latest updated AMI. In addition, updates are provided for the Amazon Linux AMI via the Amazon Linux yum repositories.

API Access: API calls to launch and terminate instances, change firewall parameters, and perform other functions

17

3 Data replication for S3 data objects is done within the regional cluster in which the data is stored and is not replicated to other data centre clusters in other regions. AWS will not move Customers’ content from the selected Regions without notifying the Customer, unless required to comply with the law or requests of governmental entities. As of this writing, there are nine regions: US East (Northern Virginia), US West (Oregon), US West (Northern California), AWS GovCloud (US) (Oregon), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), and South America (Sao Paulo).


sanitation prior to storage re-provisioning and destruction as described in its whitepapers. The FI controls and determines when to delete content.

In addition, as mentioned by the MAS TRM, the AWS environment is a virtualised, multi-tenant environment. AWS systems are designed to prevent FIs from accessing physical hosts or instances not assigned to them by filtering through the virtualisation software. As a point of reference, this architecture has been validated by an independent PCI Qualified Security Assessor (QSA) and was found to be in compliance with all requirements of PCI DSS version 3.0 published in October 2013.4

Note that AWS also has single-tenancy options. Dedicated instances are Amazon EC2 instances launched within a customer’s Amazon Virtual Private Cloud (Amazon VPC) that runs hardware dedicated to a single customer. Dedicated instances let customers take full advantage of the benefits of Amazon VPC and the AWS cloud while isolating their Amazon EC2 compute instances at the hardware level.

As part of this, FIs must adopt key management policies and procedures that should be sponsored by the GCGF and executed by risk and security, especially for corporate contexts where multiple business lines require multiple levels of keys. This is no trivial project, especially for organisations who have never needed key management capabilities. While AWS provides the AWS CloudHSM to help customers manage keys, customers must allocate internal resource to manage this tool.

Also, the GCGF should define enterprise requirements that define the proper usage of encryption in the cloud, and should work with an additional body to provide encryption advisory and encryption as a service to internal users.

18

4 Security within Amazon EC2 is provided on multiple levels: the operating system (OS) of the host platform, the virtual instance OS or guest OS, a firewall, and signed API calls. Each of these items builds on the capabilities of the others. The goal is to prevent data contained within Amazon EC2 from being intercepted by unauthorised systems or users and to provide Amazon EC2 instances themselves that are as secure as possible without sacrificing the flexibility in configuration that customers demand.


MAS TRM Section 6:Technology Acquisition


In Section 6 of the MAS TRM, noting that many systems fail because of poor system design and implementation, as well as inadequate testing, MAS requires that for all acquisition projects, FIs establish a steering committee, consisting of business owners, the development team and other stakeholders to provide oversight and monitoring of the progress of the project.5

Supporting the committee should be an enterprise project management framework and a project governance capability as well as enterprise requirements around security and security testing and source code review and control as pertains to FI applications.


AWS provides services and capabilities such as AWS Marketplace, AMIs and IAM which allow the FI to control internal sourcing of AWS services and enforce tight standards.

Because AWS provides a layer of virtualisation on top of the infrastructure, partners subscribe to services rather than underlying technology. As such, provided that AWS manages technology acquisition for itself adequately, there is no need for additional controls from AWS relation to acquisition.


Section 6 responsibilities are largely unchanged in the cloud model with respect to security-focused application development. The responsibilities for system and security requirements, design, testing, project management, source code review and end user development remain with the FI. Additional scrutiny and controls will need to be demonstrated over the FI’s AWS environment.

19

This section mainly pertains to the secure development (or acquisition) of applications but also has some implications for control of IaaS or PaaS sourcing.

FIs should:• Make changes to their own technology acquisition• processes in order to integrate the cloud operating• model to take advantage of AWS Marketplace and• avoid infrastructure sprawl

• Integrate Amazon Machine Images (AMI) into• existing standard platform build processes. IAM• can then be used to restrict the available choice of• EC2 builds to the appropriate corporate standards

• Ensure portability through proper cloud-related• enterprise requirements. Ensure that processes are• defined for exporting data from AWS in the event• that the FI decides to run workloads internally or• with other providers. AWS provides a range of • services and APIs to facilitate this.

• Provide appropriate controls around agile• development groups exploiting cloud services for• fast ‘time to market’ of new features. The cloud• model can enable these teams to bring new• functionality to market much faster but there is • also a reduced ‘time to risk’

5 including deliverables to be realised at each phase of the project and milestones to be reached according to the project timetable.

Where AWS is used for rapid prototyping to reduce time-to-market for new business functionality, especially using agile development techniques and perhaps DevOps operating models, expect a heightened level of scrutiny from MAS to ensure corners are not being cut because of the speed of change enabled by AWS.

Internal management of FIs’ cloud-based AWS Marketplace, charging, and resource acquisition process flows must all be managed by the FI.


As this will be a new operating model, FIs will need to change procurement and vendor management processes related to procuring cloud services. The utility model requires different mind sets and terms to traditional IT outsourcing. That said, because much of the operational risk traditionally controlled via the TRM practices are made vestigial due to the cloud, from a regulatory perspective, the cloud should make compliance easier along classical lines. Focus will move away from acquisition and end-of-life and towards control of the infrastructure sprawl as shadow IT is legitimised.

20


MAS TRM Section 7:IT Service Management


In Section 7 of the MAS TRM Guidelines. MAS notes that a robust IT service management framework is essential for supporting IT systems, services and operations, managing changes, incidents and problems as well as ensuring the stability of the production IT environment.

The framework, as defined by the TRM Guidelines, should comprise the governance structure, processes and procedures for change management, software release management, incident and problem management as well as capacity management.

The TRM Guidelines identify several control areas along the lines of IT Infrastructure Library (ITIL) that include:

• Change Management • Program Migration • Incident Management • Problem Management • Capacity Management


AWS has a robust IT service management framework geared towards ensuring continued availability and performance of FI facing systems. Through the use of automated processes that manage change, Amazon is able to achieve its goals of high availability, repeatability, scalability, security, and disaster recovery. Routine, emergency, and configuration changes to existing AWS infrastructure are authorised, logged, tested, approved, and documented in accordance with industry norms for similar systems and updates to AWS’s infrastructure are done to minimise any impact on the customer and their use of the services. 6 7

21

AWS has in place a robust IT service management framework, as will the FI. The challenge is to integrate the two in what is ostensibly a ‘utility’ model, rather than a traditional high-touch, high-engagement, outsourcing model.

Specifically, FIs should:• Create specialist in-house teams that have the• necessary tooling and notifications in place to• provide the required level of transparency into the• FI’s AWS and service quality to end users or engage• other third parties to provide a layer of • engagement above AWS. The level of tooling will• be proportionate to the criticality and sensitivity of• workloads, starting with AWS CloudWatch and• extending into third party infrastructure and• application performance management tools

• Adjust ITIL processes such as incident, problem,• change and release management to take into• account integration with AWS. For example: – Ensure that the FI’s change management – processes incorporate forward visibility of – AWS-driven maintenance when the timing is – deemed to be high risk – Understand the responsibilities of and – notifications available from AWS during – serious incidents or security breaches – The FI has a responsibility to comply with – outage notification periods (60 minutes) and – root cause analysis reporting (14 days) as – defined in the MAS Notice and so needs to – ensure it has timely visibility of relevant – issues and resolutions

• Spawn a workstream focused on Edge• Optimisation and Compliance via AWS CloudFront

• Understand how AWS defines events of interest• versus security incidents and what events or• incidents AWS reports

6 Changes are typically pushed into production in a phased deployment starting with lowest impact areas. Deployments are tested on a single system and closely monitored so impacts can be evaluated. Service owners have a number of configurable metrics that measure the health of the service’s upstream dependencies. These metrics are closely monitored with thresholds and alarming in place. Rollback procedures are documented in the Change Management (CM) ticket.7 Periodically, AWS performs self-audits of changes to key services to monitor quality, maintain high standards, and facilitate continuous improvement of the change management process. Any exceptions are analysed to determine the root cause, and appropriate actions are taken to bring the change into compliance or roll back the change if necessary. Actions are then taken to address and remediate the process or people issue.


technically and from an organisational perspective – and are constructed around a high level of human engagement where critical systems are involved.

Buying utility cloud services from a public cloud provider is a different model that brings additional challenges. Cloud services are not as opaque as many would believe and a high level of technical integration is possible from an operational perspective using provider APIs and third party tooling (Citihub has successfully tested popular FSI APM tools such as ITRS in this model).

However, AWS service management is focused on resolving core service issues, and providing customer ‘communications’ or self-help. This is different to customer ‘engagement’ and AWS does not have the responsibility of getting FI applications back on line – that remains the direct responsibility of the FI. FIs will need to purchase enterprise level support; engage other third parties to provide a layer of engagement above AWS; or create specialist in-house teams that have the necessary tooling and notifications in place to provide the same level of service.

Consider two scenarios:

1. High Severity Business Impact Incidents 1. Who will participate on FI ‘crisis’ bridges 1. (conference calls) usually split between technical 1. (identify and resolve issues) and management 1. teams (provide two-way notification of FI impact 1. and resolution progress)? Will AWS resource be 1. dedicated to these calls and, if not, who can 1. contribute with enough level of transparency into 1. the AWS services? Under an Enterprise Support 1. agreement a support engineer may be assigned 1. to the technical bridge and a technical account 1. manager may be assigned to the management 1. bridge. 2. FI Change Freezes 1. Can a FI influence AWS change schedules during 1. sensitive business periods (e.g. monthly non-farm 1. payrolls, or high profile IPOs)? The FI’s change

In addition, AWS has implemented a formal, documented incident response policy and program that addresses purpose, scope, roles, responsibilities, and management commitment.8 With ‘Enterprise’ level support, customers can buy a response time of less than 15 minutes for incident handling.

Further, AWS has implemented various methods of external communication to support its customer base and community to provide advance warning and alerts. Most notably, the “Service Health Dashboard” is available and maintained by the customer support team to alert customers to any issues that may be of broad impact.

There are other Beta programs running which will provide additional support tools for customers including:

• Support API – Beta • Integrate AWS Support case management and • Trusted Advisor data into customer applications • and extend existing support tools and workflows to • interact with AWS’s Support Centre. • Third Party Software Support – Beta • Provides Third Party Software Support, which • enables customers to work directly with AWS • Support on questions related to the customers’ • Amazon Elastic Compute Cloud (EC2) instance • operating systems, as well as the configuration and • performance of the most popular Third Party • Software components on AWS. This support covers • most widely used operating systems, common • application stack components, databases, disk • management tools and VPN Solutions.


MAS is looking for “a robust IT service management framework”. FIs will already have this in place, and invariably will already be dealing with the complexities of a supply chain of providers who play different roles in service management. These relationships are typically highly integrated – both

22

8 If an event meets incident criteria, then the relevant on‐call support engineer will start an engagement utilising AWS Event Management Tool system to start the engagement and page relevant program resolvers (e.g. Security team). The resolvers will perform an analysis of the incident to determine if additional resolvers should be engaged and to determine the approximate root cause.


1. management processes will need to be updated 1. to include full visibility into AWS maintenance 1. schedules and have the ability to postpone AWS’s 1. maintenance which could potentially impact FI 1. instances in the event that the FI needs to 1. implement a change freeze.

From the customer perspective, AWS provides a basic performance monitoring capability via CloudWatch. Alerts and rules can be set up for automatic scaling of various resources in order for customers to take advantage of the elastic nature of the cloud. However, proper configuration requires dedicated customer-side resources. In addition to the basic performance monitoring provided by CloudWatch, FIs should consider implementing more sophisticated Application Performance Monitoring tools on top of Cloud Watch.

23


data traffic away from the affected area. Core applicationsare deployed in an N+1 configuration, so that in the event of a data centre failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites.

AWS provides customers with the flexibility to place instances and store data within multiple geographic regions as well as across multiple availability zones (AZs) within each region. Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk flood plains (specific flood zone categorisation varies by region). In addition to discrete uninterruptible power supply (UPS) and on-site backup generation facilities, they are each fed via different power grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple tier-1 network providers.

MAS TRM Section 8:Reliability, Availability and Recovery


In Section 8 of the MAS TRM Guidelines, MAS reminds readers that the reliability, availability, and recoverability of IT systems, networks and infrastructures are crucial in maintaining confidence and trust in the operational and functional capabilities of a FI.

When critical systems fail, the disruptive impact on the FI’s operations or customers will usually be severe and widespread and the FI may suffer serious financial and reputational consequences.

Given that all systems are vulnerable, the FI should define its recovery and business resumption priorities. The FI should also test and practice its contingency procedures so that disruptions to its business arising from a serious incident may be minimised.

Along the way, FI’s must meet several requirements around the following topics:

• System Availability • Disaster Recovery Planning and Testing • Data Backup Management


Amazon’s infrastructure has a high level of availability in relevant industry terms and provides customers the features to deploy a resilient IT architecture. AWS has designed its systems to tolerate system or hardware failures with minimal customer impact. 9

Data centres are built in clusters in various global regions. All data centres are online and serving customers; no data centre is “cold.” In case of failure, automated processes move customer

24

Section 8 pertains to ‘critical systems’. It is left to the regulated entity to define which systems fall under this scope but it is intended for systems that directly affect Singapore Markets and the Singapore Citizen and is therefore typically restricted to clearing and settlement systems. A typical large bank may only define 10 to 20 applications as ‘critical’ and these are likely to be some of the last systems considered for the cloud model.

Nevertheless, AWS provides scalable and highly resilient building blocks for customers to base their application architectures around, and provides a lot of advantages over in-house infrastructure in this area.

However, FIs will need to consider DR scenarios that include the loss of AWS regions or AWS firm-wide and so will need to consider recovery capabilities which are independent of AWS.

9 As of this writing, there are nine regions: US East (Northern Virginia), US West (Oregon), US West (Northern California), AWS GovCloud (Oregon), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), and South America (Sao Paulo).


environments. It should be noted that all communications between regions is across public Internet infrastructure; therefore, appropriate encryption methods should be used to protect sensitive data.

Many AWS services have built-in high availability. FIs should be familiar with the level of resiliency for each service when designing their applications. There is rarely the need for cold standby components, specifically for DR. However, in designing resiliency in a system, one must be aware of the initiation time required to provision replacement resources to meet recovery time objectives. One should always design for failure for each cloud component. Replacing a failed component with a new instance is typically more cost effective and efficient than trouble shooting it. 11

AWS as a third party risk

FIs will need to consider the DR scenarios of AWS services not being available at multiple levels:

1. Availability Zone (AZ) loss 1. AWS services are designed to failover at this level 1. within a region with minimal disruption. 2. FI configuration loss 1. FI configurations, data and online backups within 1. AWS are deleted or not availabile (e.g. due to 1. negligence or malicious attack). 3. Region loss 1. This would be an extremely low probability 1. scenario, but the bank would need to consider 1. whether it can failover between regions or 1. whether due to constraints (e.g. data sovereignty 1. or performance reasons) it would need to failover


By its nature, AWS provides building blocks rarely available inside FIs, which simplify the creation of system architectures that are highly resilient, available and recoverable. It also provides a level of scalability that is not financially viable to create in-house. It is up to the FI to design these features into their applications so they can be exploited, noting that older applications, especially those with vertically scalable architectures, are less suitable to this model.

FIs will need to prove to MAS that their intended implementations have sufficient architectural and operational governance and controls in place to minimise their risk. Done well, this could represent a step forward in terms of risk versus internal implementations, e.g. AWS can provide a greater level of transparency and control of configuration management and usage tracking. AWS represents a ‘clean’ environment where all usage will be accounted for and billed. Many financial services firms still struggle to maintain accurate internal inventories of legacy systems and their usage.

FIs should architect AWS usage to take advantage of availability zones and multiple regions. Distributing applications across multiple availability zones provides the ability to remain resilient in the face of most failure modes, including natural disasters or system failures.10

However, FIs must be aware of location-dependent privacy and compliance requirements. Data is not replicated between regions unless proactively done so by the customer, thus allowing customers with these types of data placement and privacy requirements the ability to establish compliant

25

10 The resiliency of different services in AWS can be on AZ, regional or global level. These needed to be taken into consideration in designing the cloud deployment architecture. For example, when using Relational Database Services, AWS already provides Multi-AZ deployments which utilise synchronous replication with automatic failover capability. It is transparent to application making it much simpler to design and implement DR solution. In addition some database offering have Read Replica functionality that can provide an additional level of resiliency as well as performance enhancement.

AWS provide automated backups for RDS and Elastic Block Storage. It makes satisfying these requirement as simple as selecting the correct options in configuration.

Snapshots and backup stored in AWS S3 are secure in nature. You can securely upload/download your data to Amazon S3 via the SSL encrypted endpoints using the HTTPS protocol. Amazon S3 also provides multiple options for encryption of data at rest. If you prefer to manage your own encryption keys, you can use a client encryption library like the Amazon S3 Encryption Client to encrypt your data before uploading to Amazon S3. Alternatively, you can use Amazon S3 Server Side Encryption (SSE) if you prefer to have Amazon S3 manage encryption keys for you. With Amazon S3 SSE, you can encrypt data on upload simply by adding an additional request header when writing the object. Decryption happens automatically when data is retrieved.

11 In using many of the PaaS solutions from AWS (such as Relational Database Service, Elastic load balancer, etc.), there are different levels of resiliency built into the service. They can simplify the DR design and remove complexity in failover scenarios.


1. outside of AWS (e.g. back inside the FI’s facilities or 1. to another cloud provider). 4. Firm-wide loss 1. The FI would need to consider the scenario that 1. AWS stopped trading or had a firm-wide issue that 1. prevented them servicing customers (e.g. a 1. massive scale, successful, co-ordinated DDOS 1. attack).

In scenarios 2, 3 and 4, the FI will need to consider where data is replicated or where backups are held to ensure access in these scenarios.

MAS will also want to see effective testing of DR scenarios. The complication here will be in ‘faking’ the situation where an AZ, Region or AWS firm-wide are not available as AWS will not be able to cooperate in testing real scenarios over weekends as a bank would normally do. These scenarios will need to be created at a network level. Commercial and open source tools are available to help facilitate this.

26


Security Management of Operational InfrastructureMAS TRM Section 9:

27

The FI should:• Ensure that tactical roles and responsibilities • around data security are fully understood as• between itself and AWS

• Ensure that data privacy requirements are fully• understood (globally)

• Take advantage of the Amazon Virtual Private • Cloud (VPC)

• Consider adopting the Cloud Audit and Cloud Trust• Protocol to perform regular, automated testing of• the Cloud Supply Chain

• Consider how it and/or AWS will respond to a• subpoena or search warrant

• Monitor for large internal data migrations with• database activity monitoring and file activity• monitoring

• Monitor data moving to the cloud with URL filters • and DLP

• Choose storage with data dispersion when • available

• Arrange specific vulnerability scans on their own• AWS instances (which require advanced approval• from AWS)

In our opinion, there are a number of areas where a well-run, large-scale cloud operator like AWS, without a deep and diverse technology legacy should have advantages over a large financial services firm. This is largely due to standardisation and economies of scale. These areas include: technology refresh management; patch management; security monitoring; vulnerability assessment; and penetration testing.

Amazon provides network and security configuration management capabilities and controls that are compliant with SOC, FedRAMP, PCI etc. and include: secure network architecture; secure access points; transmission protection via SSL or IPSEC (using AWS VPC); and monitoring & protection.

AWS also has significant experience from running Amazon.com as well as AWS services in providing protection against external threats including: distributed denial of service (DDOS) attacks; man in the middle (MITM) attacks; IP spoofing; port scanning; and anti-virus as well as packet sniffing by other tenants.

MAS will want to see greater FI controls in areas that present a greater risk through multi-tenancy, including: data loss prevention (DLP) and management of FI-controlled networks services and open ports.

Much will also rest on the interpretation of TRM clause 9.1.4 ‘The FI should not use unsafe internet services such as... cloud-based internet storage sites’.

Citihub interprets this clause as applying to internet-based use of services such as DropBox or iCloud but not to a controlled implementation of enterprise services using AWS (or nearest equivalents).



The AWS Trusted AdvisorThe AWS Trusted Advisor is a customer support service that monitors cloud performance and resiliency, as well as cloud security. Trusted Advisor inspects your AWS environment and makes recommendations when opportunities may exist to save money, improve system performance, or close security gaps.12

Storage End of LifeWhen an AWS storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorised individuals. AWS uses the techniques detailed in DoD 5220.22‐M (“National Industrial Security Program Operating Manual “) or NIST 800‐88 (“Guidelines for Media Sanitization”) to destroy data.13 AWS’s storage device disposal process is regularly reviewed and assessed by independent third party auditors as a part of its continued ISO 27001 and FedRAMP compliance program.

Secure Network ArchitectureNetwork devices, including firewall and other boundary devices, are in place to monitor and control communications at the external boundary of the network and at key internal boundaries within the network. These boundary devices employ rule sets, access control lists (ACL), and configurations to enforce the flow of information to specific information system services.14


In Section 9 of the MAS TRM Guidelines, MAS warns that the IT landscape is vulnerable to various forms of cyber attacks, and the frequency and malignancy of attacks are increasing. They note that it is imperative that FIs implement security solutions at the data, application, database, operating system and network layers to adequately address and contain these threats. Such cyber attacks, they note, include phishing, denial of service attacks, spamming, sniffing, spoofing, hacking, key-logging, middleman interception, and other malware attacks from mutating virus and worms.

MAS defines a set of specific issues that it sees as critical for FIs:

• Confidential Information • Customer Authentication • Data Loss Prevention • Technology Refresh • Configuration Management • Anti-Virus • Perimeter Security • Vulnerability Assessment • Patch Management • Security Monitoring

12 For example, it provides alerts on several of the most common security misconfigurations that can occur, including leaving certain ports open that make you vulnerable to hacking and unauthorised access, neglecting to create IAM accounts for your internal users, allowing public access to S3 buckets, or not using MFA (Multi-Factor Authentication) on your root AWS Account.13 All decommissioned storage devices are degaussed and physically destroyed in accordance with industry‐standard practices.14 Several network fabrics exist at Amazon, each separated by devices that control the flow of information between fabrics. The flow of information between fabrics is established by approved authorisations, which exist as access control lists (ACL) which reside on these devices. These devices control the flow of information between fabrics as mandated by these ACLs. ACLs are defined, approved by appropriate personnel, managed and deployed using AWS ACL‐manage tool. Boundary protection devices are configured in a denyall mode.

Amazon’s Information Security team approves these ACLs. Approved firewall rule sets and access control lists between network fabrics restrict the flow of information to specific information system services. Access control lists and rule sets are reviewed and approved, and are automatically pushed to boundary protection devices on a periodic basis (at least every 24 hours) to ensure rule‐sets and access control lists are up‐to‐date.

AWS implements least privilege throughout its infrastructure components. AWS prohibits all ports and protocols that do not have a specific business purpose. AWS follows a rigorous approach to minimal implementation of only those features and functions that are essential to use of the device. Network scanning is performed and any unnecessary ports or protocols in use are corrected. Regular internal and external vulnerability scans are performed on the host operating system, web application and databases in the AWS environment utilising a variety of tools. Vulnerability scanning and remediation practices are regularly reviewed as a part of AWS continued compliance with PCI DSS and FedRAMP.


device to provide an encrypted tunnel between the Amazon VPC and a customer’s data centre.

AWS utilises a wide variety of automated monitoring systems to provide a high level of service performance and availability. AWS monitoring tools are designed to detect unusual or unauthorised activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorised intrusion attempts. The tools have the ability to set custom performance metrics thresholds for unusual activity.17

In addition to monitoring, regular vulnerability scans are performed on the host operating system, web application, and databases in the AWS environment using a variety of tools.

AWS network and firewall management and Amazon’s antivirus program are reviewed by independent third party auditors as a part of AWS’s ongoing compliance with SOC, PCI DSS, ISO 27001 and FedRamp.

Within the AWS environment, a configuration management

AWS has strategically placed a limited number of access points to the cloud to allow for more comprehensive monitoring of inbound and outbound communications and network traffic. These customer access points are called API endpoints, and they allow secure HTTP access (HTTPS), which allows customers to establish a secure communication session with their storage or compute instances within AWS.15

In addition, AWS has implemented network devices that are dedicated to managing interfacing communications with Internet service providers (ISPs). AWS employs a redundant connection to more than one communication service at each Internet-facing edge of the AWS network. These connections each have dedicated network devices.16

Customers can connect to an AWS access point via HTTP or HTTPS using Secure Sockets Layer (SSL), a cryptographic protocol that is designed to protect against eavesdropping, tampering, and message forgery.

For customers who require additional layers of network security, AWS offers the Amazon Virtual Private Cloud (VPC), which provides a private subnet within the AWS cloud, and the ability to use an IPsec Virtual Private Network (VPN)

29

15 To support customers with FIPS 140-2 requirements, the Amazon Virtual Private Cloud VPN endpoints and SSL-terminating load balancers in AWS GovCloud (US) operate using FIPS 140-2 level 2-validated hardware.16 Logically, the AWS Production network is segregated from the Amazon Corporate network by means of a complex set of network security / segregation devices. AWS developers and administrators on the corporate network who need to access AWS cloud components in order to maintain them must explicitly request access through the AWS ticketing system. All requests are reviewed and approved by the applicable service owner.

Approved AWS personnel then connect to the AWS network through a bastion host that restricts access to network devices and other cloud components, logging all activity for security review. Access to bastion hosts require SSH public-key authentication for all user accounts on the host. For more information on AWS developer and administrator logical access.17 Systems within AWS are extensively instrumented to monitor key operational metrics. Alarms are configured to automatically notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used so personnel are always available to respond to operational issues. This includes a pager system so alarms are quickly and reliably communicated to operations personnel.

Documentation is maintained to aid and inform operations personnel in handling incidents or issues. If the resolution of an issue requires collaboration, a conferencing system is used which supports communication and logging capabilities. Trained call leaders facilitate communication and progress during the handling of operational issues that require collaboration. Post-mortems are convened after any significant operational issue, regardless of external impact, and Cause of Error (COE) documents are drafted so the root cause is captured and preventative actions are taken in the future. Implementation of the preventative measures is tracked during weekly operations meetings.

AWS security monitoring tools help identify several types of denial of service (DoS) attacks, including distributed, flooding, and software/logic attacks. When DoS attacks are identified, the AWS incident response process is initiated. In addition to the DoS prevention tools, redundant telecommunication providers at each region as well as additional capacity protect against the possibility of DoS attacks.

The AWS network provides significant protection against traditional network security issues, and you can implement further protection. The following are a few examples: • Distributed Denial of Service (DDoS) Attacks • Man in the Middle (MITM) Attacks • IP Spoofing • Port Scanning • Packet sniffing by other tenants



FIs’ governance will need to ensure that AWS provides continued levels of appropriate protection against cyber attacks to allow the FI to remain compliant with MAS Guidelines.

FIs will also have specific responsibilities in ensuring that they do not cause security gaps themselves, including controls over customisable network services and open ports. They will be expected to arrange specific vulnerability scans on their own AWS instances (which require advanced approval from AWS).

MAS has a specific focus on DLP and FIs will need to demonstrate data protection in transit and at rest through defensible encryption. Protection of data at end points should not change in the cloud model. They will also need to satisfy MAS that there are satisfactory controls in place preventing potential malicious action by AWS employees.

The AWS Trusted Advisor service is available to AWS customers who have signed up for the Business or Enterprise levels of AWS Support. Certainly, any FI should sign-up for this service.

FIs should also extend existing corporate security capabilities to the cloud environment such as third party encryption, IDS, IPS, web application firewall and configuration-file integrity management tools.

tool is used to manage deployable software in packages, package groups, and environments.18

AWS errs on the side of protecting partner privacy and is vigilant in determining which law enforcement requests they comply with. AWS does not hesitate to challenge orders from law enforcement if they think the orders lack a solid basis.

30

18 AWS maintains the baseline OS distribution used on hosts. All unneeded ports, protocols and services are disabled in the base builds. Service teams use the build tools to add only approved software packages necessary for the servers function per the configuration baselines maintained in the tools. Servers are regularly scanned and any unnecessary ports or protocols in use are corrected using the flaw remediation process. Deployed software undergoes recurring penetration testing performed by carefully selected industry experts. Remediation of the penetration testing exercise is also incorporated into the baseline through the flaw remediation process.


MAS TRM Section 10:Data Centre Protection and Controls


In Section 10 of the MAS TRM Guidelines, MAS notes that since a FIs’ critical systems and data are concentrated and maintained in the DC, it is important that the DC is resilient and physically secure from internal and external threats.

To that end, MAS requires that all FIs undergo a Threat and Vulnerability Risk Assessment (“TVRA”) to identify security threats to and operational weaknesses in a DC (including perimeter and surrounding environment, as well as the building and DC facility) in order to determine the level and type of protection that should be established to safeguard it.

In addition, MAS mandates that FIs limit access to the DC to authorised staff only. For example, the FI should only grant access to the DC on a need-to-have basis and physical access of staff to the DC should be revoked immediately if it is no longer required. At the same time, the FI should ensure that the perimeter of the DC, DC building, facility, and equipment room are physically secured and monitored. Finally, the data centre should be resilient. Some of this becomes moot given AWS’s stance of not allowing customers access to the DCs. Physical security is covered in the SOC audits.

31

AWS facilities are designed and controlled for high availability and resiliency at least in line with standards and best practices adopted by international banks. AWS’s physical security is reviewed by independent external auditors during audits for SOC, PCI DSS, ISO 27001 and FedRAMP compliance. Quarterly vulnerability assessments are also performed.

The physical locations to AWS data centres are a closely guarded secret, even to large customers. This may be at odds with MAS’s guidelines for regulated entities to have transparency into and accountability over their supply chain. For this to work, MAS (and the FI) will need to be content with AWS’s ‘Region’ model and the implications for TVRAs. MAS requires TVRAs to be provided by the DC operator. For FIs using AWS services, MAS would need to allow the TVRAs to be sanitised to remove the physical locations.

FIs will also need to satisfy themselves and MAS with the facilities and M&E level monitoring and controls in place. This is possible without knowledge of physical locations and is necessary to support MAS reporting requirements around timeliness of outage notification and post-incident root cause analysis.



AWS’s data centres use best practice architectural and engineering approaches19 which compare well with typical FI facilities.


MAS requires TVRAs to be performed on DCs supporting FIs’ Singapore operations. It allows a TVRA report to be provided by the DC operator. For FIs using AWS services, MAS would need to allow the TVRAs to be sanitised to remove the physical locations.

FIs will also need to satisfy themselves and MAS with the facilities and M&E level monitoring and controls in place e.g. through the audit reports. This is necessary to support MAS reporting requirements around timeliness of outage notification and post-incident root cause analysis.

32

19 AWS data centres are housed in nondescript facilities. Physical access is strictly controlled at the perimeter and at building ingress points. AWS Physical Security Mechanisms are reviewed by independent external auditors during audits for our SOC, PCI DSS, ISO 27001 and FedRAMP compliance.

Automatic fire detection and suppression equipment has been installed to reduce risk. The fire detection system utilises smoke detection sensors in all data centre environments, mechanical and electrical infrastructure spaces, chiller rooms and generator equipment rooms. These areas are protected by either wet-pipe, double-interlocked pre-action, or gaseous sprinkler systems.

The data centre electrical power systems are designed to be fully redundant and maintainable without impact to operations, 24 hours a day, and seven days a week. Uninterruptible Power Supply (UPS) units provide back-up power in the event of an electrical failure for critical and essential loads in the facility. Data centres use generators to provide back-up power for the entire facility.

Climate control is required to maintain a constant operating temperature for servers and other hardware, which prevents overheating and reduces the possibility of service outages. Data centres are conditioned to maintain atmospheric conditions at optimal levels. Personnel and systems monitor and control temperature and humidity at appropriate levels.

AWS monitors electrical, mechanical, and life support systems and equipment so that any issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.


The key Access Management tool from the Customer’s perspective is AWS Identity Access Management (IAM). AWS IAM allows customers to create multiple users and manage the permissions for each user within their AWS Account.20

MAS TRM Section 11:Access Controls


In Section 11 of the MAS TRM Guidelines, the MAS lays out its recommendations around Access Controls. The section notes that there are some basic internal security principles that must be implemented by FIs: • Never alone principle • Segregation of duties principle • Access control principle • User Access Management • Privileged Access Management


The AWS Production network is segregated from the Amazon Corporate network and requires a separate set of credentials for logical access. The Amazon Corporate network relies on user IDs, passwords, and Kerberos, while the AWS Production network requires SSH public-key authentication through a bastion host.

The AWS Production network is also supported by robust access management and credential management tools, governance processes and a set of policies. This ensures that access is provided only to those who need it and for a limited scope and time.

33

Auditors are satisfied with the way in which AWS handles access control.

Internal access control is handled at least at the same level of control you would expect to see in a bank, including: personnel background checks; regular account reviews and audits; and a strict credentials policy.

Customer access is handled through the IAM tool, which supports a number of methods for unique, granular privileges over both customer instances and the AWS Marketplace (to control the creation of new instances) and is backed by granular activity logging.

FIs will need to extend their existing internal best practices and policies for access control into the AWS environment using single sign-on integration with Active Directory and exploiting AWS’s Multi-Factor Authentication capabilities for privileged access with the client retaining responsibility for key management. Further to this, FIs can use IAM to provide a greater level of granularity of access control over AWS services.

20 AWS IAM enables Customers to implement security best practices, such as least privilege, by granting unique credentials to every user within your AWS Account and only granting permission to access the AWS services and resources required for the users to perform their jobs. AWS IAM is secure by default; new users have no access to AWS until permissions are explicitly granted.

AWS IAM is also integrated with the AWS Marketplace, so that you can control who in your organisation can subscribe to the software and services offered in the Marketplace. Since subscribing to certain software in the Marketplace launches an EC2 instance to run the software, this is an important access control feature. Using AWS IAM to control access to the AWS Marketplace also enables AWS Account owners to have fine-grained control over usage and software costs.

AWS IAM enables Customers to minimise the use of your AWS Account credentials. Once Customers create AWS IAM user accounts, all interactions with AWS Services and resources should occur with AWS IAM user security credentials.

AWS IAM also enables Customers to grant any user temporary access to your AWS resources by using security credentials that are valid only for a limited amount of time.

The AWS IAM feature called roles uses temporary security credentials to allow you to delegate access to users or services that normally don’t have access to your organisation’s AWS resources. A role is a set of permissions to access specific AWS resources, but these permissions are not tied to a specific IAM user. An authorised entity (e.g. mobile user, EC2 instance) assumes a role and receives temporary security credentials for authenticating to the resources defined in the role. Using roles can save significant time for customers who manage a large number of instances or an elastically scaling fleet using AWS Auto Scaling.

Finally, AWS IAM eliminates the need to share passwords or keys, and makes it easy to enable or disable a user’s access as appropriate.



Auditors are satisfied with the way in which AWS handles internal access control.

FIs will already have internal best practices for access control such as ‘least privilege’ policies that can be extended directly to the AWS environment. For user privileges, it is expected that FIs will use single sign-on integration with Active Directory and to protect the management consoles, it will be expected by MAS to exploit AWS’s Multi-Factor Authentication capabilities with the client allocating, managing and rotating keys internally.

The GCGF should spawn work groups specifically focused on governance of IAM and MFA.

34


perspective to support the requirements of the Monetary Authority of Singapore – one of the more exigent financial regulators in managing technology risk and operations.

However, FIs will not be able to rely on AWS’s technical capabilities alone to comply with MAS’s TRM Guidelines. The nature of cloud services means they must take on new responsibilities, as well as adapting existing IT Service Management routines for the cloud environment. That means significant changes to operating models, policies, processes, governance, culture, and strategy.

These changes can be as challenging to accomplish as the technical integration piece, but getting them right will have more lasting impact on risk management, cost, and agility.

Conclusion

Cloud services have significant potential to benefit FIs by driving more streamlined, agile IT operations. However, they are challenging to incorporate into traditional FI technology operating models. More than most other organisations, FIs tend to be encumbered by high levels of technical debt, strict requirements around information security, systems availability, latency and regulatory compliance, along with rigid IT processes and controls to accommodate those requirements. Given that kind of environment, any concerted effort by financial institutions to adopt cloud technologies needs to be properly and carefully managed.

This research has shown that regulation should not be seen as an insurmountable barrier to adoption of cloud services for FIs. The best-in-class capabilities of a provider like AWS are, by and large, seen as sufficiently robust from a technical

35

Darren Thayre Darren is Director of Citihub’s Singapore office and has a deep background in data centres and core infrastructure. He has been directly involved in providing MAS-related TVRAs in the local market and working with clients on wider compliance issues.

Mark Wong Mark is a certified AWS solutions architect working from our Hong Kong office. He was previously with Deutsche Bank, responsible for their equity derivatives market making and proprietary trading platform in the APAC region.

Authors & Contributors

Citihub Consulting

Chris Allison Citihub co-founder, based in Hong Kong. Chris was previously with JPMorgan and was head of Infrastructure Architecture & Strategy for their Investment Bank.

Alan Bulley Alan joined Citihub from Credit Suisse in Singapore where he was Director responsible for infrastructure audits and controls across APAC including compliance with MAS TRM.


About Citihub Consulting

Citihub Consulting is a global, independent IT advisory firm with deep domain expertise across every layer of the technology stack – from business applications and data platforms down to core infrastructure. From IT strategy, architecture and solution development, through to cost optimisation, risk assessment and implementation – our trusted experts deliver the right results for your business.

For us consultancy is personal. We have a relentless commitment to great execution, integrity and client success. We aim to redefine perceptions of our industry and our commitment to delivering the right results for our clients has never changed, even as the business has grown consistently over the last decades.

2013/14 clients include 7 of the top 10 investment banks and 2 of the top 5 hedge funds.

For more information, please visit www.citihub.com

Contact Us

EMEARichard Hamstead, [email protected]

1 Canada Square London E14 5AB +44 207 536 5801

AMERICASKeith Maitland, [email protected]

757 3rd Avenue, 20th Floor New York, NY 10017 +1 212 878 8840

ASIA PACIFICChris Allison, [email protected]

20th Floor, 1 IFC Hong Kong +852 8108 2777

Bellerivestrasse 201CH-8034 Zurich+41 44 386 6080

The Dineen Building140 Yonge Street, Suite 200Toronto, Ontario M5C 1X6+1 416 848 1499

137 Market StreetLevel 5, Office 505Singapore 048943 +65 3152 2777

how to approach regulatory compliance with public cloud … · 2018-12-04 · how to achieve mas...

Documents