The starting point for creating Secure by Design systems

Alexander Vinyavsky
Technology Evangelist

Markets and businesses today are being transformed by global factors. The complexity of systems is increasing, with the digital and physical worlds merging into a single cyberphysical world. New cyber-risks are emerging. This means the whole concept of cybersecurity needs to change. And the next inevitable step in its development is Cyber Immunity.

We’re launching a blog for IT professionals, business executives and anyone else who cares about cybersecurity. We’ll be talking about Cyber Immunity, the nuances and practical experience of creating secure systems, as well as sharing tips and stories.

The Secure by Design ideology is used to create truly secure systems. It assumes that we start thinking about security before we even start designing the architecture.
But what does it mean to “think” about security? To begin with, you need to understand exactly what it means for you and your project.

What is security?

There is no such thing as security in the “general” sense. It’s always specific — and different for each product, depending on its business purpose and context. By aiming for security “in general”, we’ll be attempting to make the system invulnerable by protecting it from every conceivable threat, which obviously cannot be done, e.g. because of resource constraints.

That means we have to choose protective measures. And if there are no formal requirements from the business — they often boil down to simply «make it secure» — then this task falls squarely on the shoulders of the developers. And there’s a very real risk that the measures chosen won’t be those that are necessary or sufficient, but rather those that are familiar. After all, it’s easier to do what you know well.

This approach to design is often seen in practice today — it creates the illusion that the system is secure. However, in the context of all the scenarios in which it will be used, it’s impossible to say with certainty whether it is truly reliable. So when creating a secure system, start by defining what you mean by security in your particular case. And your starting point for creating a Cyber Immune system will be your security goals and assumptions.

Security goals and assumptions

Let’s compare the two terms. Security goals are the immutable properties of the system that you want to attain so that it functions securely and safely in all possible use cases (adjusted for security assumptions). And security assumptions are the constraints you place on the use cases for the system.

For example, for a Cyber Immune gateway for the Internet of Things, the security goals may be as follows:

  • Data only passes through the gateway in one direction — from the protected subnet to the cloud, no matter what the circumstances.

And, for example, these security assumptions:

  • An attacker has no physical access to the device.
  • An internal intruder is unlikely.

In essence, the security goals and assumptions represent the security brief that the customer gives to the development team. Not in the form of general wishes like «make it secure», but in a form that the development team can actually work with. In this way, security goals and assumptions form the basis for the subsequent development of system requirements.

I will discuss security goals and assumptions in more detail in future posts.

If you want to learn more about what Kaspersky Cyber Immunity is and what principles lie behind it, watch our 8-min video:

Markets and businesses today are being transformed by global factors. The complexity of systems is increasing, with the digital and physical worlds merging into a single cyberphysical world. New cyber-risks are emerging. This means the whole concept of cybersecurity needs to change. And the next inevitable step in its development is Cyber Immunity.

We’re launching a blog for IT professionals, business executives and anyone else who cares about cybersecurity. We’ll be talking about Cyber Immunity, the nuances and practical experience of creating secure systems, as well as sharing tips and stories.

The Secure by Design ideology is used to create truly secure systems. It assumes that we start thinking about security before we even start designing the architecture.
But what does it mean to “think” about security? To begin with, you need to understand exactly what it means for you and your project.

What is security?

There is no such thing as security in the “general” sense. It’s always specific — and different for each product, depending on its business purpose and context. By aiming for security “in general”, we’ll be attempting to make the system invulnerable by protecting it from every conceivable threat, which obviously cannot be done, e.g. because of resource constraints.

That means we have to choose protective measures. And if there are no formal requirements from the business — they often boil down to simply «make it secure» — then this task falls squarely on the shoulders of the developers. And there’s a very real risk that the measures chosen won’t be those that are necessary or sufficient, but rather those that are familiar. After all, it’s easier to do what you know well.

This approach to design is often seen in practice today — it creates the illusion that the system is secure. However, in the context of all the scenarios in which it will be used, it’s impossible to say with certainty whether it is truly reliable. So when creating a secure system, start by defining what you mean by security in your particular case. And your starting point for creating a Cyber Immune system will be your security goals and assumptions.

Security goals and assumptions

Let’s compare the two terms. Security goals are the immutable properties of the system that you want to attain so that it functions securely and safely in all possible use cases (adjusted for security assumptions). And security assumptions are the constraints you place on the use cases for the system.

For example, for a Cyber Immune gateway for the Internet of Things, the security goals may be as follows:

  • Data only passes through the gateway in one direction — from the protected subnet to the cloud, no matter what the circumstances.

And, for example, these security assumptions:

  • An attacker has no physical access to the device.
  • An internal intruder is unlikely.

In essence, the security goals and assumptions represent the security brief that the customer gives to the development team. Not in the form of general wishes like «make it secure», but in a form that the development team can actually work with. In this way, security goals and assumptions form the basis for the subsequent development of system requirements.

I will discuss security goals and assumptions in more detail in future posts.

If you want to learn more about what Kaspersky Cyber Immunity is and what principles lie behind it, watch our 8-min video: