review comments addressed

_posts/2024-09-23-intro-finos-ccc.md

@@ -6,13 +6,17 @@ author: smendis-scottlogic
 summary: FINOS Common Cloud Controls (CCC) is an open standard by FINOS, to describe consistent controls for compliance public cloud deployments in financial services sector. The project is sponsored by Scott Logic, aligning with its mission to promote and support open-source initiatives. This is an effort to introduce FINOS CCC and its goals.
 ---
 
-In September last year (to be specific on year 2023), I was introduced to a somewhat unusual project, while on bench. This was not an ordinary software project. The project is sponsored by Scott Logic, aligning with its commitment to open source. It was led internally at Scott Logic by our beloved principal consultant Robert Griffiths. After spending about an hour listening to Rob explain this new venture, all I could gather was that we are trying to shape the future of the public cloud. I was excited, not only for the opportunity to contribute to an open-source project but also by the idea of playing a role in shaping the cloud itself.
+Since September last year (2023), I have been working on a somewhat unusual software project. The project is sponsored by Scott Logic, aligning with its commitment to open source. I was excited, not only for the opportunity to contribute to an open-source project but also by the idea of playing a role in shaping the cloud itself.
 
-Over the course of a year, we’ve come a long way—transforming what was once a vague, uncertain vision into fully fleshed compliance controls. This blog post aims to introduce the FINOS Common Cloud Controls (CCC) project and its goals in a simpler, more understandable manner.
+Over the course of a year, we’ve come a long way—transforming what was once a vague, uncertain vision into releasable open standard. This blog post aims to introduce the FINOS Common Cloud Controls (CCC) project, outlining its objectives, timeline, and benefits.
 
 ## What is FINOS CCC?
 
-As stated on the [official page](https://www.finos.org/common-cloud-controls-project) for the CCC project on the FINOS website, “FINOS Common Cloud Control (FINOS CCC) is the codename for an open standard project, originally proposed by Citi and now open source under Fintech Open Source Foundation (FINOS), to describe consistent controls for compliant public cloud deployments in the financial services sector”.
+![FINOS_LOGO]({{ site.github.url }}/smendis-scottlogic/assets/finos-logo.png)
+
+As stated on the [official page](https://www.finos.org/common-cloud-controls-project) for the CCC project on the FINOS website, 
+
+> “FINOS Common Cloud Control (FINOS CCC) is the codename for an open standard project, originally proposed by Citi and now open source under Fintech Open Source Foundation (FINOS), to describe consistent controls for compliant public cloud deployments in the financial services sector”.
 
 This statement outlines several important aspects of the project. First and foremost, it is designed to cater specific needs of the **financial services sector**, which includes banking, insurance, investment and wealth management, mortgage lending, and more. An **open standard** refers to a set of guidelines or specifications developed collaboratively that can be used freely or with minimal restrictions. **Consistent controls** imply standardized security, compliance, and governance measures applied uniformly across the infrastructure, applications and processes. These controls ensure that policies related to data protection, access management, auditing, encryption, and monitoring are reliably implemented. **Compliance public cloud deployments** involve using public cloud services, such as AWS, Microsoft Azure, or Google Cloud, that meet the regulatory and legal standards required by regulating authorities. 
 
@@ -22,9 +26,23 @@ In summary, FINOS CCC project aims to establish a set of guidelines that enforce
 
 Financial service sector retains sensitive data about their customers. They store personal identification information of the customer such as full name, date of birth, social security numbers, national identification numbers, home address, email addresses, phone numbers, etc. They also sometimes store customer income and credit data such as employment status, employer details, salary information, other income sources, credit score, defaults and bankruptcies, etc. Not only that, but financial services also usually have records of customer in-store & online purchase history, withdrawals, deposits, investment activities and related transactional and behavioral patterns. In a nutshell, they hold a vast amount of sensitive customer information, which could cause severe reputation and financial damage in an unfortunate event of a data breach.
 
-In the past, regulatory requirements for financial institutes mandated that data be stored in highly secured on-premise data centres. However, with the growing adoption of cloud services, the financial services sector is increasingly moving towards the public cloud. Key benefits driving this shift include agility, scalability, cost optimization, accelerated innovation, geographic availability, and enhanced resilience. But the controls and services offered. Some of the potential drawbacks and challenges, particularly given the sensitive nature of the financial data are security concerns, compliance and regulatory challenges, loss of control, downtime, data privacy risks, vendor lock-in and skills gap. Let’s elaborate more on few key concerns in moving financial data to the public cloud. Despite the robust security measures cloud providers offer, financial data is highly sensitive, and breaches can be devastating. Public cloud environments are multi-tenant, meaning data from multiple organizations shares the same infrastructure. While cloud providers enforce strict isolation, the risk of data leakage still exists. The cloud provider’s employees may have access to critical data, posing potential insider threats. When it comes to regulatory challenges, regulations in some regions require that sensitive financial data must be stored within national borders. Cloud providers may not offer appropriate data centre locations, or ensuring compliance with data residency laws can be complex. Auditing and proving compliance in cloud environments can be more challenging, especially with limited visibility into the provider’s operations.
+In the past, regulatory requirements for financial institutes mandated that data be stored in highly secured on-premise data centres. However, with the growing adoption of cloud services, the financial services sector is increasingly moving towards the public cloud. Key benefits driving this shift include agility, scalability, cost optimization, accelerated innovation, geographic availability, and enhanced resilience. Some of the potential drawbacks and challenges, particularly given the sensitive nature of the financial data are security concerns, compliance and regulatory challenges, loss of control, downtime, data privacy risks, vendor lock-in and skills gap. Let’s elaborate more on few key concerns in moving financial data to the public cloud. Despite the robust security measures cloud providers offer, financial data is highly sensitive, and breaches can be devastating. Public cloud environments are multi-tenant, meaning data from multiple organizations shares the same infrastructure. While cloud providers enforce strict isolation, the risk of data leakage still exists. The cloud provider’s employees may have access to critical data, posing potential insider threats. When it comes to regulatory challenges, regulations in some regions require that sensitive financial data must be stored within national borders. Cloud providers may not offer appropriate data centre locations, or ensuring compliance with data residency laws can be complex. Auditing and proving compliance in cloud environments can be more challenging, especially with limited visibility into the provider’s operations.
+
+According to the Linux Foundation [announcement](https://www.linuxfoundation.org/press/finos-announces-open-standards-project-for-financial-services-common-cloud-controls) on July 27, 2023 Jim Adams, CTO and Head of Technology Infrastructure at Citi, the world’s fifth largest bank, stated
+
+> “There is a need for a Cloud Standard that will improve certain security and control measures across the Financial Services industry, whilst simplifying and democratizing access for all institutions to operate and benefit by leveraging the public cloud. It is important to collaborate with our peers to ensure consistency across cloud service providers, ensuring the industry can realize true multi-cloud strategies,”
+
+## Goals of FINOS CCC
+
+Base on the Common Cloud Control GitHub repo the project aims to fulfil following goals, 
+
+* Defining Best Practices Around Cloud Security
+* One Target For CSPs To Conform To
+* Sharing The Burden Of A Common Definition
+* A Path Towards Common Implementation
+* A Path Towards Certification
 
-Jim Adams, CTO and Head of Technology Infrastructure at Citi, the world’s fifth largest bank, said, “There is a need for a Cloud Standard that will improve certain security and control measures across the Financial Services industry, whilst simplifying and democratizing access for all institutions to operate and benefit by leveraging the public cloud. It is important to collaborate with our peers to ensure consistency across cloud service providers, ensuring the industry can realize true multi-cloud strategies,” in his statement on July 27, 2023 .
+or a more detailed explanation of each project goal and how they are achieved, please refer to the [README.md](https://github.com/finos/common-cloud-controls) file in the project's GitHub repository.
 
 ## Timeline and Contributors
 
@@ -48,9 +66,7 @@ It is envisaged that eventually, CCC will offer certification for CSPs who confo
 
 ## Controls, Threats and Features
 
-To provide you with a clearer understanding of what a control is, let's take a closer look at a specific example: the control that prevent bucket deletion through irrevocable bucket retention policy in object storage. This control is designed to ensure that critical storage resources, like data buckets, are not accidentally or maliciously deleted, thereby protecting the integrity and availability of stored data. By examining this control, we can better understand what are the associated threats and how to mitigate those risks in cloud environments.
-
-This control defined in the `controls.yaml` under object storage is mapped to a specific threat within the system, identified as `CCC.TH06`, which we will explore in more detail later. Additionally, this control is mapped to a NIST control, specifically identified as `PR.DS-1`, which is part of the framework's guidelines for protecting data. There are also specific methods to test whether this control is effectively implemented within your cloud service provider, ensuring that it meets security and compliance standards.
+To provide you with a clearer understanding of what a control is, let's take a closer look at a specific example: the control that prevents bucket deletion through irrevocable bucket retention policy in object storage. This control is designed to ensure that critical storage resources, like data buckets, are not accidentally or maliciously deleted, thereby protecting the integrity and availability of stored data. By examining this control, we can better understand what are the associated threats and how to mitigate those risks in cloud environments.
 
 ~~~ yaml
 id: CCC.ObjStor.C03
@@ -70,7 +86,7 @@ test_requirements:
         Confirm that the bucket retention policy cannot be modified or unset.
 ~~~
 
-Let’s examine the threat `CCC.TH06` in  `common-threats.yaml` file, which pertains to the accidental or malicious deletion of data. This threat highlights the potential risk where important data could be lost due to human error or intentional actions by bad actors. This particular threat is also linked to the MITRE ATT&CK framework under the ID `T1485`, which refers to data destruction as a method used by attackers to disrupt operations or erase traces of their activities. Additionally, this threat is mapped to specific feature within the system `CCC.ObjStor.F11`. 
+This control defined in the file named `controls.yaml` under object storage, is mapped to a specific threat within the standard, identified as `CCC.TH06`, which we will explore in more detail later. Additionally, this control is mapped to a NIST control, specifically identified as `PR.DS-1`, which is part of the framework's guidelines for protecting data. There are also specific methods to test whether this control is effectively implemented within your cloud service provider, ensuring that it meets security and compliance standards.
 
 ~~~yaml
 id: CCC.TH06
@@ -84,7 +100,7 @@ mitre_attack:
     - T1485: Data Destruction
 ~~~
 
-The feature `CCC.ObjStor.F11`, found in the features.yaml file under the object storage category, allows for controlling access to buckets based on predefined policies. This functionality can be leveraged to deny the deletion of buckets, ensuring that once a bucket is created, it cannot be deleted. This feature directly supports the control we are discussing, as it helps enforce safeguards against accidental or malicious deletion of storage resources, aligning with the security objectives of the control.
+Let’s examine the threat `CCC.TH06` in the file named `common-threats.yaml`, which pertains to the accidental or malicious deletion of data. This threat highlights the potential risk where important data could be lost due to human error or intentional actions by bad actors. This particular threat is also linked to the MITRE ATT&CK framework under the ID `T1485`, which refers to data destruction as a method used by attackers to disrupt operations or erase traces of their activities. Additionally, this threat is mapped to specific feature within the standard identified as `CCC.ObjStor.F11`. 
 
 ~~~yaml
 id: CCC.ObjStor.F11
@@ -93,23 +109,15 @@ description: |
     Supports controlling access to specific objects within the object store.
 ~~~
 
+The feature `CCC.ObjStor.F11`, found in the file named `features.yaml` under the object storage, describes controlled access to buckets based on predefined policies. This functionality can be leveraged to deny the deletion of buckets, ensuring that once a bucket is created, it cannot be deleted. This feature directly supports the control we are discussing, as it helps enforce safeguards against accidental or malicious deletion of storage resources, aligning with the security objectives of the control.
+
 In summary, if your architecture relies on object storage to retain customer data in a financial institution, it's critical to prevent the deletion of storage buckets, whether due to accidental or malicious actions. This can be achieved by implementing retention policies and using object-level access controls to restrict deletion rights. By doing so, you ensure that vital customer data remains secure and compliant with regulatory requirements, safeguarding against data loss.
 
 For more details refer to the project's [GitHub](https://github.com/finos/common-cloud-controls) page.
 
-## Goals of FINOS CCC
-
-Base on the Common Cloud Control GitHub repo the project aims to fulfil following goals, 
-
-* Defining Best Practices Around Cloud Security
-* One Target For CSPs To Conform To
-* Sharing The Burden Of A Common Definition
-* A Path Towards Common Implementation
-* A Path Towards Certification
-
-or a more detailed explanation of each project goal and how they are achieved, please refer to the [README.md](https://github.com/finos/common-cloud-controls) file in the project's GitHub repository.
 
-## ScottLogic FINOS CCC Team
+## Scott Logic FINOS CCC Team
 
 Scott Logic was one of the first organizations to collaborate with the FINOS Foundation in establishing the FINOS CCC, under the leadership of Colin Eberhardt and Robert Griffiths. Robert, serving as the project’s sponsorship lead within Scott Logic, played a pivotal role in guiding this significant initiative as a key member of the FINOS CCC Steering Committee. Alongside Rob, Stevie Shiells, who chairs the Community Structure working group, and I, as the chair of the Taxonomy working group, represent Scott Logic in driving this open-source project. We've also received numerous invaluable contributions from our team at Scott Logic over time, including Joshua Isted, Cara Fisher, David Ogle, Mike Smith, Euthyme Ziogas, Daniel Moorhouse, and Ivan Mladjenovic. If you're interested in supporting Scott Logic's vision of empowering open source projects, reach out to any of us to get started on contributing to this exciting initiative.
 
+---