You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
_This post warns Devops from a false sense of security. Following security best practices when developing and configuring microservices do not result in non-vulnerable microservices. The post shows that although all deployed microservices are vulnerable, there is much that can be done to ensure microservices are not exploited. It explains how analyzing the behavior of clients and services from a security standpoint, named here **"Security-Behavior Analytics"**, can protect the deployed vulnerable microservices. It points to [Guard](http://knative.dev/security-guard), an open source project offering security-behavior monitoring and control of Kubernetes microservices presumed vulnerable._
12
-
13
-
As cyber attacks continue to intensify in sophistication, organizations deploying cloud services continue to grow their cyber investments aiming to produce safe and non-vulnerable services. However, the year-by-year growth in cyber investments does not result in a parallel reduction in cyber incidents. Instead, the number of cyber incidents continues to grow annually. Evidently, organizations are doomed to fail in this struggle - no matter how much effort is made to detect and remove cyber weaknesses from deployed services, it seems offenders always have the upper hand.
14
-
15
-
Considering the current spread of offensive tools, sophistication of offensive players, and ever-growing cyber financial gains to offenders, any cyber strategy that relies on constructing a non-vulnerable, weakness-free service in 2023 is clearly too naïve. It seems the only viable strategy is to:
11
+
_This post warns Devops from a false sense of security. Following security
12
+
best practices when developing and configuring microservices do not result
13
+
in non-vulnerable microservices. The post shows that although all deployed
14
+
microservices are vulnerable, there is much that can be done to ensure
15
+
microservices are not exploited. It explains how analyzing the behavior of
16
+
clients and services from a security standpoint, named here
17
+
**"Security-Behavior Analytics"**, can protect the deployed vulnerable microservices.
18
+
It points to [Guard](http://knative.dev/security-guard), an open source project offering
19
+
security-behavior monitoring and control of Kubernetes microservices presumed vulnerable._
20
+
21
+
As cyber attacks continue to intensify in sophistication, organizations deploying
22
+
cloud services continue to grow their cyber investments aiming to produce safe and
23
+
non-vulnerable services. However, the year-by-year growth in cyber investments does
24
+
not result in a parallel reduction in cyber incidents. Instead, the number of cyber
25
+
incidents continues to grow annually. Evidently, organizations are doomed to fail in
26
+
this struggle - no matter how much effort is made to detect and remove cyber weaknesses
27
+
from deployed services, it seems offenders always have the upper hand.
28
+
29
+
Considering the current spread of offensive tools, sophistication of offensive players,
30
+
and ever-growing cyber financial gains to offenders, any cyber strategy that relies on
31
+
constructing a non-vulnerable, weakness-free service in 2023 is clearly too naïve.
32
+
It seems the only viable strategy is to:
16
33
17
34
➥**Admit that your services are vulnerable!**
18
35
19
-
In other words, consciously accept that you will never create completely invulnerable services. If your opponents find even a single weakness as an entry-point, you lose! Admitting that in spite of your best efforts, all your services are still vulnerable is an important first step. Next, this post discusses what you can do about it...
36
+
In other words, consciously accept that you will never create completely invulnerable
37
+
services. If your opponents find even a single weakness as an entry-point, you lose!
38
+
Admitting that in spite of your best efforts, all your services are still vulnerable
39
+
is an important first step. Next, this post discusses what you can do about it...
20
40
21
41
## How to protect microservices from being exploited
22
42
23
-
Being vulnerable does not necessarily mean that your service will be exploited. Though your services are vulnerable in some ways unknown to you, offenders still need to identify these vulnerabilities and then exploit them. If offenders fail to exploit your service vulnerabilities, you win! In other words, having a vulnerability that can’t be exploited, represents a risk that can’t be realized.
43
+
Being vulnerable does not necessarily mean that your service will be exploited.
44
+
Though your services are vulnerable in some ways unknown to you, offenders still
45
+
need to identify these vulnerabilities and then exploit them. If offenders fail
46
+
to exploit your service vulnerabilities, you win! In other words, having a
47
+
vulnerability that can’t be exploited, represents a risk that can’t be realized.
24
48
25
49
{{< figure src="security_behavior_figure_1.svg" alt="Image of an example of offender gaining foothold in a service" class="diagram-large" caption="Figure 1. An Offender gaining foothold in a vulnerable service" >}}
26
50
27
-
The above diagram shows an example in which the offender does not yet have a foothold in the service; that is, it is assumed that your service does not run code controlled by the offender on day 1. In our example the service has vulnerabilities in the API exposed to clients. To gain an initial foothold the offender uses a malicious client to try and exploit one of the service API vulnerabilities. The malicious client sends an exploit that triggers some unplanned behavior of the service.
28
-
29
-
More specifically, let’s assume the service is vulnerable to an SQL injection. The developer failed to sanitize the user input properly, thereby allowing clients to send values that would change the intended behavior. In our example, if a client sends a query string with key “username” and value of _“tom or 1=1”_, the client will receive the data of all users. Exploiting this vulnerability requires the client to send an irregular string as the value. Note that benign users will not be sending a string with spaces or with the equal sign character as a username, instead they will normally send legal usernames which for example may be defined as a short sequence of characters a-z. No legal username can trigger service unplanned behavior.
30
-
31
-
In this simple example, one can already identify several opportunities to detect and block an attempt to exploit the vulnerability (un)intentionally left behind by the developer, making the vulnerability unexploitable. First, the malicious client behavior differs from the behavior of benign clients, as it sends irregular requests. If such a change in behavior is detected and blocked, the exploit will never reach the service. Second, the service behavior in response to the exploit differs from the service behavior in response to a regular request. Such behavior may include making subsequent irregular calls to other services such as a data store, taking irregular time to respond, and/or responding to the malicious client with an irregular response (for example, containing much more data than normally sent in case of benign clients making regular requests). Service behavioral changes, if detected, will also allow blocking the exploit in different stages of the exploitation attempt.
51
+
The above diagram shows an example in which the offender does not yet have a
52
+
foothold in the service; that is, it is assumed that your service does not run
53
+
code controlled by the offender on day 1. In our example the service has
54
+
vulnerabilities in the API exposed to clients. To gain an initial foothold the
55
+
offender uses a malicious client to try and exploit one of the service API
56
+
vulnerabilities. The malicious client sends an exploit that triggers some
57
+
unplanned behavior of the service.
58
+
59
+
More specifically, let’s assume the service is vulnerable to an SQL injection.
60
+
The developer failed to sanitize the user input properly, thereby allowing clients
61
+
to send values that would change the intended behavior. In our example, if a client
62
+
sends a query string with key “username” and value of _“tom or 1=1”_, the client will
63
+
receive the data of all users. Exploiting this vulnerability requires the client to
64
+
send an irregular string as the value. Note that benign users will not be sending a
65
+
string with spaces or with the equal sign character as a username, instead they will
66
+
normally send legal usernames which for example may be defined as a short sequence of
67
+
characters a-z. No legal username can trigger service unplanned behavior.
68
+
69
+
In this simple example, one can already identify several opportunities to detect and
70
+
block an attempt to exploit the vulnerability (un)intentionally left behind by the
71
+
developer, making the vulnerability unexploitable. First, the malicious client behavior
72
+
differs from the behavior of benign clients, as it sends irregular requests. If such a
73
+
change in behavior is detected and blocked, the exploit will never reach the service.
74
+
Second, the service behavior in response to the exploit differs from the service behavior
75
+
in response to a regular request. Such behavior may include making subsequent irregular
76
+
calls to other services such as a data store, taking irregular time to respond, and/or
77
+
responding to the malicious client with an irregular response (for example, containing
78
+
much more data than normally sent in case of benign clients making regular requests).
79
+
Service behavioral changes, if detected, will also allow blocking the exploit in
80
+
different stages of the exploitation attempt.
32
81
33
82
More generally:
34
83
35
-
- Monitoring the behavior of clients can help detect and block exploits against service API vulnerabilities. In fact, deploying efficient client behavior monitoring makes many vulnerabilities unexploitable and others very hard to achieve. To succeed, the offender needs to create an exploit undetectable from regular requests.
84
+
- Monitoring the behavior of clients can help detect and block exploits against
85
+
service API vulnerabilities. In fact, deploying efficient client behavior
86
+
monitoring makes many vulnerabilities unexploitable and others very hard to achieve.
87
+
To succeed, the offender needs to create an exploit undetectable from regular requests.
36
88
37
-
- Monitoring the behavior of services can help detect services as they are being exploited regardless of the attack vector used. Efficient service behavior monitoring limits what an attacker may be able to achieve as the offender needs to ensure the service behavior is undetectable from regular service behavior.
89
+
- Monitoring the behavior of services can help detect services as they are being
90
+
exploited regardless of the attack vector used. Efficient service behavior
91
+
monitoring limits what an attacker may be able to achieve as the offender needs
92
+
to ensure the service behavior is undetectable from regular service behavior.
38
93
39
-
Combining both approaches may add a protection layer to the deployed vulnerable services, drastically decreasing the probability for anyone to successfully exploit any of the deployed vulnerable services. Next, let us identify four use cases where you need to use security-behavior monitoring.
94
+
Combining both approaches may add a protection layer to the deployed vulnerable services,
95
+
drastically decreasing the probability for anyone to successfully exploit any of the
96
+
deployed vulnerable services. Next, let us identify four use cases where you need to
97
+
use security-behavior monitoring.
40
98
41
99
## Use cases
42
100
43
-
One can identify the following four different stages in the life of any service from a security standpoint. In each stage, security-behavior monitoring is required to meet different challenges:
101
+
One can identify the following four different stages in the life of any service
102
+
from a security standpoint. In each stage, security-behavior monitoring is required
103
+
to meet different challenges:
44
104
45
105
Service State | Use case | What do you need in order to cope with this use case?
@@ -53,25 +113,57 @@ Fortunately, microservice architecture is well suited to security-behavior monit
53
113
54
114
## Security-Behavior of microservices versus monoliths {#microservices-vs-monoliths}
55
115
56
-
Kubernetes is often used to support workloads designed with microservice architecture. By design, microservices aim to follow the UNIX philosophy of "Do One Thing And Do It Well". Each microservice has a bounded context and a clear interface. In other words, you can expect the microservice clients to send relatively regular requests and the microservice to present a relatively regular behavior as a response to these requests. Consequently, a microservice architecture is an excellent candidate for security-behavior monitoring.
116
+
Kubernetes is often used to support workloads designed with microservice architecture.
117
+
By design, microservices aim to follow the UNIX philosophy of "Do One Thing And Do It Well".
118
+
Each microservice has a bounded context and a clear interface. In other words, you can expect
119
+
the microservice clients to send relatively regular requests and the microservice to present
120
+
a relatively regular behavior as a response to these requests. Consequently, a microservice
121
+
architecture is an excellent candidate for security-behavior monitoring.
57
122
58
123
{{< figure src="security_behavior_figure_2.svg" alt="Image showing why microservices are well suited for security-behavior monitoring" class="diagram-large" caption="Figure 2. Microservices are well suited for security-behavior monitoring" >}}
59
124
60
-
The diagram above clarifies how dividing a monolithic service to a set of microservices improves our ability to perform security-behavior monitoring and control. In a monolithic service approach, different client requests are intertwined, resulting in a diminished ability to identify irregular client behaviors. Without prior knowledge, an observer of the intertwined client requests will find it hard to distinguish between types of requests and their related characteristics. Further, internal client requests are not exposed to the observer. Lastly, the aggregated behavior of the monolithic service is a compound of the many different internal behaviors of its components, making it hard to identify irregular service behavior.
61
-
62
-
In a microservice environment, each microservice is expected by design to offer a more well-defined service and serve better defined type of requests. This makes it easier for an observer to identify irregular client behavior and irregular service behavior. Further, a microservice design exposes the internal requests and internal services which offer more security-behavior data to identify irregularities by an observer. Overall, this makes the microservice design pattern better suited for security-behavior monitoring and control.
125
+
The diagram above clarifies how dividing a monolithic service to a set of
126
+
microservices improves our ability to perform security-behavior monitoring
127
+
and control. In a monolithic service approach, different client requests are
128
+
intertwined, resulting in a diminished ability to identify irregular client
129
+
behaviors. Without prior knowledge, an observer of the intertwined client
130
+
requests will find it hard to distinguish between types of requests and their
131
+
related characteristics. Further, internal client requests are not exposed to
132
+
the observer. Lastly, the aggregated behavior of the monolithic service is a
133
+
compound of the many different internal behaviors of its components, making
134
+
it hard to identify irregular service behavior.
135
+
136
+
In a microservice environment, each microservice is expected by design to offer
137
+
a more well-defined service and serve better defined type of requests. This makes
138
+
it easier for an observer to identify irregular client behavior and irregular
139
+
service behavior. Further, a microservice design exposes the internal requests
140
+
and internal services which offer more security-behavior data to identify
141
+
irregularities by an observer. Overall, this makes the microservice design
142
+
pattern better suited for security-behavior monitoring and control.
63
143
64
144
## Security-Behavior monitoring on Kubernetes
65
145
66
-
Kubernetes deployments seeking to add Security-Behavior may use [Guard](http://knative.dev/security-guard), developed under the CNCF project Knative. Guard is integrated into the full Knative automation suite that runs on top of Kubernetes. Alternatively, **you can deploy Guard as a standalone tool** to protect any HTTP-based workload on Kubernetes.
146
+
Kubernetes deployments seeking to add Security-Behavior may use
147
+
[Guard](http://knative.dev/security-guard), developed under the CNCF project Knative.
148
+
Guard is integrated into the full Knative automation suite that runs on top of Kubernetes.
149
+
Alternatively, **you can deploy Guard as a standalone tool** to protect any HTTP-based workload on Kubernetes.
67
150
68
151
See:
69
152
70
-
-[Guard](https://github.com/knative-sandbox/security-guard) on Github, for using Guard as a standalone tool.
71
-
- The Knative automation suite - Read about Knative, in the blog post [Opinionated Kubernetes](https://davidhadas.wordpress.com/2022/08/29/knative-an-opinionated-kubernetes) which describes how Knative simplifies and unifies the way web services are deployed on Kubernetes.
72
-
- You may contact Guard maintainers on the [SIG Security](https://kubernetes.slack.com/archives/C019LFTGNQ3) Slack channel or on the Knative community [security](https://knative.slack.com/archives/CBYV1E0TG) Slack channel. The Knative community channel will move soon to the [CNCF Slack](https://communityinviter.com/apps/cloud-native/cncf) under the name `#knative-security`.
73
-
74
-
The goal of this post is to invite the Kubernetes community to action and introduce Security-Behavior monitoring and control to help secure Kubernetes based deployments. Hopefully, the community as a follow up will:
153
+
-[Guard](https://github.com/knative-sandbox/security-guard) on Github,
154
+
for using Guard as a standalone tool.
155
+
- The Knative automation suite - Read about Knative, in the blog post
0 commit comments