Compliance is the discipline referring to methods, process and procedures for ensuring an organization is aligned towards enforced requirements from internal and external regulations, frameworks, standards, laws and polices.

I know there are different definitions and descriptions out there of what compliance is. This article is not about cutting words or saying my definition is right or others are wrong. The goal of this article is to address the subject, Compliance, from a cloud security governance perspective. Why it is a thing and how to manage it.

COMPLIANCE

Compliance includes, but is not limited to, an organization being aligned with requirements from external governing bodies in specific geographic, industries, standards, or frameworks. Such as for example GDPR, PCI-DSS, HIPAA, and FDA.

Compliance is also related to internal requirements, such as for example internal security requirements developed and stipulated within an organization. These are usually found as presented as security requirements in your organization through information security policies, processes, and procedures related to third parties, procurements, cloud services, outsourcing, and so forth.

This means that we can look at Compliance from two different perspectives. External requirements and internal requirements from the viewpoint of security.

Challenges related to compliance are generally something common in organizations spanning multiple geographical regions and operating in heavily regulated industries, for example, finance, medicine, and healthcare. The challenges are mainly manifested through that these organizations in these industries find it more challenging to ensure continuous compliance over time. The reason for this is related to, but not limited to, regulations from external entities and governing bodies frequently change over time and new regulations pop up each year.

And this, the introduction of new regulations every year, is also a trend that has increased year by year over the last decade. And there is a general prediction in the security industry that this trend will continue in the same direction. I am not saying this is a good or a bad thing. This is just how it is. And this is how, most likely, will continue.

When AI for example reaches a higher maturity and adoption in our societies and organizations there will most likely sprawl out several new regulations. These will be specific to certain industries, markets, organizations, and so forth. If we do not regulate AI according to intelligent security requirements, I personally think we are heading in the wrong direction. In my opinion, we as humans, organizations, and societies have the responsibility to act in advance. This means we need to think and be contemplative about the future implications of emerging technologies. We cannot leave it up to only those who invent the technologies. Or to the technology itself.

And when it comes to cloud services, this was not what we did. At least in my opinion. We did not gather collectively and do the thinking together. Not at least on larger scales. Security implications related to cloud services were less thought about during the period when the services entered the market. And this is one of the reasons why we now see specific regulations, standards, frameworks, and laws including requirements related to cloud services. And this is also one of the reasons why certain training, related to cloud security, has been developed.

Cloud services are today a commodity and security is not something that can be or should be ignored. But here and there this keeps happening. The reasons for this are several but one that I think is high in frequency that amplifies this to be happening is the lack of general security knowledge. Security is not totally unique in the context of cloud services. Fundamental and intelligent security principles still apply.

COMPLIANCE vs SECURITY

A service, technology, solution, product etcetera established in the cloud does not automatically mean it is more or less secure compared to an on-prem establishment. Generalizations can of course be made about some scenarios and concepts where a cloud service might provide a higher baseline level of security.

This, for example, implies scenarios where a cloud service provider (CSP) has evidence of compliance against several security standards, frameworks, and guidelines in terms of certifications, external audits, penetration tests, and so on.

It is important though to understand that compliance towards a specific standard, frameworks etcetera does not in absolute terms mean that a service (in the cloud or on-prem) is secure. Compliance shall not and does not dictate security. Unfortunately many out there have got this wrong and believe that “compliance towards X” equals “we are secure”. This is not always the case. It can be the case but there are no absolute guarantees.

Just because an organization complies with a specific regulatory framework or standard does not mean that things are secure. Things are from a compliance perspective in alignment according to the framework, regulation, standard, policy etcetera. Compliance is often and should provide a certain level of security. But this is not always the case.

A framework, regulation, standard, policy etcetera may dictate for example “strong authentication mechanisms” but do not require multifactor authentication. From a pure security perspective passwords, for example, are no longer determined as “strong authentication mechanisms”. But it might also be the only option in some cases where legacy systems and software do not support multifactor authentication. I guess you get the point.

A framework, regulation, standard, policy etcetera may dictate for example “strong authentication mechanisms” and the organization implements something else. The thing implemented may be good enough and based on a risk assessment but from a pure security perspective, it is still considered as weak. And this is just one example of when compliance dictates something and the reality does not reflect good security based on sound and intelligent security principles.

A service (independent of where it exists; the cloud or on-prem) needs to be built securely from the ground up and not the other way around. There is more to be said about compliance and the relationship towards security. But this is a topic I will leave for a separate article. I think you get the understanding my message. Compliance does not equal security by default. Rule number one: Build your stuff on good and intelligent security principles. There are no substitutes for good and sound security principles.

REAL LIFE SCENARIO

During a security audit of a SaaS service and the supplier’s organization, that I conducted on behalf of one of my customers, the following took place.

The customer needed my help, in an RFP (Request for proposal) process, to evaluate the security posture of 3 different suppliers and their cloud service. The customer was about to make investments in a SaaS service and replace an on-prem service used within the HR process at the organization.

”[…<Conversation>…]”
“Yes Henrik, we are compliant with [standard Z]!”
”May I see the certificate and relevant artifacts?”
”You know, it is 4 years old…we have not made any re-certifications since then.
“Ok.”
“But we did a penetration test not so long ago.”
”Ok, I understand. Can I have a look at the latest report?”
”Sure!”
“[…<Cliffhanger – Read more below>…]”

The penetration report I was given was 2 years old. And it was actually not a penetration test. It was a vulnerability assessment report. The firm that sold the service to the SaaS CSP (Cloud service provider) had presented it as a “penetration test”.

I explained that neither the certification nor ”penetration report“ provided any evidence or relevance to the security audit due to during this 2-4 year time period much has changed related to the standard, vulnerabilities, and threat landscape. Continuity is king. Security never sleeps. It is a highly dynamic and fast-paced landscape where change is continuous.

The CSP shall have credit though. They provided me with all the answers and did their best during the security audit. But the thing here is that if I had not asked the questions and asked for the evidence I would not have gotten this information. The SaaS provider was not a security expert, this was my job. I needed to ask and explain what and why I needed certain information. I was there to lead them through the audit and through all the questions (~250 questions + risk & threat assessment).

The SaaS service from a functionality perspective was solid. They got the highest score among the other suppliers in the RFP process. From a security perspective, they landed in the middle. And now, after I handed over my report to the customer, I was done with my part, and on to the next assignment in the security universe.

“Henrik, this was a very educating and insightful security audit ! Thank you for leading us through it and sharing your knowledge with us.“

N N, CTO, [REDACTED] SaaS CSP, Providing HR solutions

After a couple of months, I spoke with the customer who informed me that they had signed a contract with this SaaS provider. I was a bit surprised at first but as the conversation kept going I got a good understanding of their rationalization.

As the fulfillment of the functional requirements for the SaaS was a high score from the service provided the customer accepted certain risks that I had identified. Some of them were determined to fall within their risk appetite and others were yellow and red flags. The supplier of the SaaS service agreed to pull up the sleeves and mitigate the identified red flags before the onboarding of my customer. This part was also stipulated as a part of the commercial agreement, in an appendix.

This is not always the case though, that this goes this way. Or that a common agreement is found between the customer and CSP. But when this is the effect of a security audit it is a very satisfying feeling. When an audit turns out to be something value-adding for everyone. And when there is less blame game-bull-shit taking place or people trying to hide behind false beliefs, paper-based security, telling half-true stories, putting lipstick on the pig etcetera. I have been taking place during these forms of audits and assessments as well. They are in my opinion less charming…but they keep happening. But these types of audits and assessments also provide knowledge and perspective. But as I said, they are less charming to conduct.

EPILOGUE

Cloud services were one of those things that quickly became very popular in our industry and in organizations. Many organizations dived head-in first and did not contemplate around the implications from an external or internal compliance (or security) perspective. And very few regulations, those external requirements, were and still are not created to support cloud services and the nature in which they exist.

Think about it. Many old regulations and standards were created and entered the market before cloud services became a thing. So, what we have seen and still see is a natural effect of that technology is maturing and transforming faster in comparison to those regulatory standards, frameworks, and laws. And if we think about laws. A law is nothing that in general is changed just like that. It takes time and it should take time. Regulations and laws are not something that exists in an environment of wild-wild-west, also known as cowboy land.

Compliance from a responsibility perspective when it comes to cloud services is in general shared between the cloud service provider and cloud service customer (CSC). But at the end of the day, it is the CSC who is ultimately responsible for their own compliance. This is not something that can be transferred to the CSP. The customer can not transfer the accountability of compliance to an external party. The same goes for security. You and your organization can not outsource the accountability for security or compliance.

If you and your organization are having thoughts and plans about deploying or migrating services to the cloud, you need to start out by doing the due diligence on your organization’s compliance requirements. Only you and your organization can answer these questions. This is not something that the CSP is responsible for or can solve for you. The CSP can of course provide you with certifications, audit evidence, and similar for which regulations, standards, frameworks etcetera they are compliant with. But it is up to you and your organization to understand which compliance and security requirements you need to adhere to. Do not neglect this part of your organization’s cloud service journey.

RECOMMENDATIONS

Where do we go from here? I will give you and your organization a couple of good security recommendations that will instantly improve your cloud security governance process. These recommendations are mainly related to the procurement phase of cloud services, i.e. when investments are decided to be made in cloud services.

These activities shall be done before the ink is put on the papers –> the contracts and agreements are signed between you and the CSP.

• Assess each cloud service provider and their organization with the help of a standardized method and process.
  • For example with the help of CCM from the Cloud Security Alliance
  • Or you create your own method and process built around industry best practices and internal security requirements.
    • The requirements should be a collection of internal and external compliance enforcements and security requirements that you want to assess the CSP towards.

• Ask the CSP to provide you with:
  • Which standards, frameworks, laws, and regulations they are compliant with.
    • Audit evidence for these standards, frameworks, laws, and regulations.
    • Description of how the CSP continuously assures compliance over time.
  • An example of their standard contract and agreement.
    • Request the CSP to take responsibility to communicate internal and external compliance changes to their service and organization to you and your organization.
    • Embed compliance as a part of the overall governance process between you and your CSP.
  • A copy of their information security policy.
    • To assess gaps between your organization and the CSP’s organization.
    • To gain an understanding of the CSP’s information security compliance posture from an internal perspective and viewpoint from the supplier.

We are living at the beginning of a totally new substrate, i.e. digital. Cloud services are here to stay and do not get me wrong, I am a strong supporter of cloud services. And at the same time, I am a strong supporter of being contemplative about security fundamentals, independent if it is cloud or on-prem stuff.

We are just at the beginning of something totally new to humanity where cloud services today are something considered a commodity. Think about how fast we have come to this point, and what has happened in 20-30 years. It is pretty amazing. And what will the world look like +20-30 years from now? How will cloud services be consumed? How will they be delivered? Will old regulations and laws be replaced by new and more modern which are built around the digital substrate? Will security fundamentals shift in form as emerging technologies evolve? The future is very interesting in so many ways.

Stay contemplative about the future and keep doing those fundamental security governance things even for your cloud services, i.e. keeping track of your organization’s compliance requirements. Accountability for either compliance or security cannot be outsourced.

For your information

If you found this article interesting you may also like to read:

• Cloud Security Governance – The Process
• Cloud Security Governance – Contracts & Agreements

Henrik Parkkinen