A co-creation with my colleague Janot van Wegen, Risk Officer.

Before the cloud era, you had your own IT organization as a reliable gatekeeper to make your company a cyber fortress. With a strong gateway, your data and applications were kept in house and in good hands. Nowadays a Fort Knox stance on cyber security is unrealistic. Applications that are designed to make the best use of the functionality of all aspects of the cloud are distributed and therefore cannot be captured in the traditional Fort Knox paradigm. With the rise of cloud-native computing, expertise in security and compliance is a must for everyone in the chain.

The context

Cloud-native applications are specifically designed and developed for the cloud. This is done to get maximum benefit from the advantages of the cloud and to minimize the unnecessary heavy lifting that goes with a traditional IT infrastructure. The trend is for companies to abandon monolithic applications in favor of interlinking best-of-breed functionalities. That very quickly leads to an extensive and complex ecosystem of components. Serverless computing, in which the components are distributed over infrastructures automatically, is an example par excellence of cloud-native design. In a serverless environment, you think in terms of functions and micro-services that you upload to the cloud as code and which the cloud then makes available via the internet. A cloud-native approach has its advantages, but it also leads to further fragmentation of the application landscape, increasing the risk of losing an overall perspective as well as losing control. If you don’t know what you’re guarding, or should be guarding, it’s hard to remain secure.

‘Embedded’ security

As compared to the old fortress approach, based on having ‘everything in house,’ what our customers now face is like a modern city in which every house must be secured against all kinds of misadventure. That means locks on every window and door, smoke detectors and fire extinguishers in every room, and secure routers so that connections with the world outside are safe and reliable. With cloud-native applications, the infrastructure is no longer a given, so the security components are built in to applications. In the latest series of summits for 2017, Amazon Web Services formulated these demands as follows: all the developers attending here should leave as security engineers. In other words, developers must invest in security skills. Right now few cloud-native developers have expertise in the field of security, which is a challenge for many companies. Cloud orchestration and cloud-native orchestration make this expertise even more crucial. In recent years our developers have been preparing for this new reality by developing their own security expertise.

Cloud-native: compliance is a job for a specialist

Ensuring that cloud-native applications work reliably and securely is one challenge and taking care of compliance is another. In the past auditors could run their checks in physical data centers but, because the big cloud providers are serving so many customers, they have contractually excluded the ‘right to audit’ in most cases. In practice they nominate a third, independent party who periodical issues a third-party statement. Such a statement is intended to guarantee that the processes of the provider have been audited (i.e. that they comply with the provider’s own requirements). As a result, the audit process for public cloud suppliers has become a technical process conducted for administrative and legal purposes. The audit process has also become more complex because the services that a customer purchases are increasingly distributed and divided over multiple suppliers. If you are in Europe, dealing with a startup in Silicon Valley whose functionality ‘as a service’ may be brilliant, how do you get the required assurance about security and other aspects of their service?

A forest of statements

We see that supervisory bodies and customers are setting tighter requirements for demonstrable control of IT, leading to increasingly formal statements, but that less attention is given to the precise content of such statements. What is the scope of the statement? For example, does a certificate provide sufficient cover for the company? Customers expect an ‘in control’ statement for their specific processes that says what software is running where, who is responsible for managing it, who guarantees that backups will be made, and whether the data is accessible. How do you ask the right questions so that later you can demonstrate that you really are in control? Who can read audit reports, interpret terms of service and explain to the developers what they need to bear in mind? Who maintains an overview?

Cloud-native assurance

Understanding such statements is increasingly a job for specialists — it requires domain-specific knowledge. Assurance boils down to being able to evaluate the supplier’s third-party statements in relation to the IT landscape and business processes. In a cloud-native environment it’s no longer possible to achieve the required level of assurance using traditional audit measures alone. The solution is to bundle traditional and cloud-native controls, which is an argument for outsourcing the coordination and ensuring a well-organized exchange of knowledge over the fields of business functionality, cloud functionality, regulations, and management. In recent years, Schuberg Philis has seen this complexity developing and has invested in the competencies and capacities required to yoke the various specialists together. This coordination role is crucial to surviving the transition to cloud-native computing.

Security by Design

For our security analyses we use the ‘Security Survival Pyramid’. It serves as a framework to help customer organizations make the security choices that suit their ambitions and needs.

Base layer: Defensible infrastructure

The base of the pyramid is the fortress that acts as the basic defense against the threats on the internet.

2nd layer: Craftsmanship, implementation, and operation

Combining the available experience and knowledge in the organization to define adequate responses to incidents.

3rd layer: Situational awareness

The field of security intelligence; security experts continuously keeping a finger on the pulse, so that they are aware of all existing risks and threats.

Top layer: Mitigating measures

Only at the fourth and highest level is attention paid to countermeasures in the form of specific security tools and managed security services. To be used in case of an unforeseen event or threat.

Bron: Blog Schuberg Philis