martes, diciembre 6, 2022
InicioHealthCisco Cloud Native Safety - Half 4: Safety Analytics and Menace Detection

Cisco Cloud Native Safety – Half 4: Safety Analytics and Menace Detection


On this weblog publish we are going to talk about how you can add visibility, menace detection, safety analytics, and alerting within your Kubernetes cluster utilizing Cisco Safe Cloud Analytics (previously generally known as Stealthwatch Cloud). That is the fourth weblog publish in a sequence. In case you’ve missed the primary three elements, you possibly can verify them out right here:

On the backside of this weblog publish, we’ve a demo video that walks by means of all the things mentioned on this weblog publish. As at all times, take a look at the DevNet Safety Dev Middle for different cool demo movies and use circumstances! Additionally, we’ve a devoted web page for Safe Cloud Analytics, which you positively wish to checkout…

Let’s stroll by means of the steps that we’ll take on this part

Keep in mind, we even have a video walkthrough on the backside of this web page. First, we are going to deploy a cloud native software named Yelb, which is a 3 tier demo app with a Redis caching service. Yelb permits customers to vote on a set of alternate options (eating places) and dynamically updates pie charts based mostly on variety of votes obtained.  Subsequent, we are going to use the Kubernetes CLI (kubectl) to validate the cluster is up and working with an energetic employee node. Then we are going to use kubectl to deploy the cloud native Yelb app to the cluster. As soon as the app is up and working, we are going to deploy Cisco Safe Cloud Analytics into the Kubernetes cluster utilizing Terraform. Lastly, we are going to generate visitors to our software utilizing Locust, which is an open supply, simple to make use of, scriptable and scalable efficiency testing software. Additionally, we are going to use netshoot, which is a  used for debugging which we are going to use to run Nmap scans (assume insider menace).

Constructing apps could or might not be your factor however having demo apps obtainable on the push of a button is at all times good to have. Within the subsequent weblog publish, we are going to undergo constructing our personal apps and APIs simply so we are able to expose some vulnerabilities to safe, however for now we’re going to use the ability of automation and orchestration to deploy our apps instantaneously utilizing a Kubernetes Manifest file.

Earlier on this weblog publish sequence, we discovered how you can deploy our cloud assets utilizing Infrastructure as Code and GitOps. We deployed an AWS VPC, EKS Cluster, and two EC2 cases utilizing Terraform. One occasion is internet hosting the Cisco Safe Firewall and the opposite occasion internet hosting the EKS employee node. We then used Ansible to configure the Cisco Safe Firewall entry management insurance policies. We verified that all the things was deployed appropriately by going to the AWS Dashboard and Firepower Gadget Supervisor.

Earlier than we get into the step-by-step rationalization of how you can do the entire above, let’s elaborate a bit extra on what Cisco Safe Cloud Analytics brings to the desk. Safe Cloud Analytics offers complete visibility and high-precision alerts with low noise, with out the usage of brokers. Organizations may also monitor their cloud safety posture to make sure configuration finest practices and adherence to inner insurance policies, thereby limiting potential threat and publicity of their cloud infrastructure. Safe Cloud Analytics is a cloud-based, Software program-as-a-Service (SaaS)-delivered answer. It detects ransomware and different malware, knowledge exfiltration, community vulnerabilities, system, occasion and configuration threat, and function adjustments that point out compromise.

As at all times, you’ve a selection now… You may watch the demo video, or learn by means of the detailed directions under. (It’s also possible to do each!)

Detailed Directions

In case you are studying this, it means you have an interest to study the main points of this arrange. Let’s bounce proper in! First, let’s ensure that the Kubernetes cluster is prepared by utilizing CLI instruments such because the AWS CLI and KUBECTL. Keep in mind the Terraform output from Jenkins, we are going to use the outputs to entry our EKS surroundings.

Security part 4_1

First, we have to set our Kubernetes context by working aws eks –area us-east-2 update-kubeconfig –identify <cluster-name>:

Security part 4_2

It will replace the .kube/config context on the native host so we are able to entry the EKS cluster. On this instance the identify of the cluster is SPOT_ON_Prod and the area is US-EAST-2.

Subsequent, let’s take a look at if we’ve any employee nodes energetic by doing a kubectl get nodes.

Security part 4_3

We see that one of many EC2 cases is assigned to EKS cluster as a employee node and the standing is exhibiting Prepared.

Nice! We are able to deploy our Yelb app very simply now by working kubectl create –f <file.yaml>. The YAML file we will likely be utilizing to deploy our app is yelb_app.yaml, which will be discovered HERE.

Security part 4_4

Properly, that was tremendous simple and quick. Let’s take a look at what was simply created. We’ve a namespace which is a container for the app, there are 4 pods working our containers, and 4 companies that entrance finish the pods. Discover the yelb-ui service, which is TYPE = NodePort. This means that service port for this pod will likely be uncovered on the EKS employee node. The container runs on port 80, however it’s mapped to port 30001 on the employee node. This implies our app will likely be obtainable to the web on port 30001. Usually our apps run behind a community or software load balancer, however since that is only a demo utilizing one employee node, the node port will work tremendous for now.

Security part 4_5

We are able to entry the appliance utilizing the prod_eks_public_ip from the Terraform output and port 30001, for instance,

Security part 4_6

The applying is now up and working and we are able to entry it from the web. Within the earlier weblog we deployed a Cisco Safe Firewall to the sting of the VPC, which offers us entry management, intrusion prevention, and anti-malware safety for visitors coming out and in of the VPC. That is little question crucial to have, however what about visitors within the EKS cluster? How can we get visibility, analytics, and alerting into the micro-service surroundings?

Cisco Safe Cloud Analytics (SCA) detects early indicators of compromise inside the cluster, together with insider menace exercise and malware. SCA consumes telemetry and logs to seek out irregular conduct or indicators of malicious exercise and triggers alerts so you possibly can examine rapidly.

We deploy SCA into the Kubernetes cluster utilizing a DaemonSet. A DaemonSet ensures that every one (or some) employee nodes run a duplicate of a pod. As employee nodes are added to the cluster, pods are added to them. As employee nodes are faraway from the cluster, these pods are rubbish collected. We will likely be deploying our SCA DaemonSet utilizing Terraform inside our Jenkins pipleline.

First, we have to get the service key from the Cisco Safe Cloud Analytics portal. From the dashboard, go to Setting > Sensors.

Security part 4_7

Scroll all the way down to the underside of the web page and duplicate/save the Service key.

Security part 4_8

Let’s return to our code. First, we add new department known as secure_cloud_analytics to our repository.

Security part 4_9

We add a brand new module known as secure_cloud_analytics. Within the file we set the required suppliers wanted for the module.

Security part 4_10

We additionally create a file that can reference the Cisco Safe Cloud Analytics Service Key. We are going to move this safe variable from Jenkins.

Security part 4_11

Then we’ve the file which can create the Kubernetes Secret, Service Account, Cluster Position Binding and the SCA DaemonSet.

Security part 4_12

Try the total file HERE.

Within the root module file we add the Safe Cloud Analytics module configuration.

Security part 4_13

Lastly, we add the SCA Service Key to our Jenkinsfile surroundings variables.

Security part 4_14

Then move the variable to the Terraform Apply within the Jenkinsfile construct stage.

Security part 4_15

Now it’s time to commit our adjustments to the secure_cloud_analytics department and create a pull request to the principle department.

Security part 4_16

As soon as the merge has been accomplished it would set off a construct job in Jenkins.

Security part 4_17

If we take a look at the Terraform apply, we see that the SCA assets have been created.

Security part 4_18

Utilizing kubectl, we are able to see the SCA pods and daemonset working in our Kubernetes Cluster.

Security part 4_19

Return to the Cisco Safe Cloud Analytics portal and choose Settings > Sensor once more. There will likely be a sensor with the identify of the AWS EC2 occasion of our employee node.

Security part 4_20

Now that we’ve a micro-services app and Cisco Safe Cloud Analytics is put in and monitoring in our Kubernetes cluster, it’s time to generate some visitors and present the worth and visibility that SCA offers in a cloud native surroundings.

First let’s generate some visitors utilizing Locust. Locust is a simple to make use of, scriptable and scalable efficiency testing software. Within the repo there’s a listing named Locust with a python file named Locust is written in Python and will be put in by working pip3 set up locust. Directions will be discovered HERE.

Run Locust regionally out of your IDE or terminal. This program will run on port 8089 in your localhost.

Security part 4_21

Go to and begin a brand new load take a look at to the general public IP handle and port of the Yelb App.

Security part 4_22

Go to the net interface of your Yelb app and ensure the votes are incrementing.

Security part 4_23

Here’s a diagram of the Yelb app. We see that the UI is working on port 80 (mapped to port 30001 on the employee node), the app server on port 4567, the database on port 5432, and cache on port 6379.

Security part 4_24

Let’s take a look at what visibility SCA offers. From the Cisco Safe Cloud Analytics dashboard let choose Examine > Session Visitors.

Security part 4_25

Within the Session Visitors filter add the ports of all of the Yelb micro-services (4567, 5432, and 6379) and choose Replace. We are going to see all of the visitors move inside the Yelb app.

Security part 4_26

If we dive just a little deeper into every IP handle, we are going to see extra details about the Kubernetes Pod resembling pod hostname, previous IP addresses, roles, and the variety of inner and exterior connections.

Security part 4_27 Security part 4_28 Security part 4_29

If we choose the Connections Graph, it would map out the appliance and its companies.

Security part 4_30

Now let’s generate some safety alerts. We’re going to use a software known as Netshoot to run some inner scans and attempt to transfer laterally inside the cluster. From our Devbox we run kubectl run tmp-shell –rm -i –tty –picture nicolaka/netshoot — /bin/bash. It will spin up a pod named tmp-shell within the default namespace of the cluster and drop us into an interactive shell. Netshoot comes full of a bunch of troubleshooting instruments, however we’re going to use the NMAP software to generate some irregular conduct.

Security part 4_31

First, we do some recognizance by working a port scan contained in the cluster (nmap -sT). This generates an Inside Port Scanner Alert in Safe Cloud Analytics.

Within the SCA portal, if we go to Monitor > Alerts, we see the alert exhibits an outline, subsequent steps, and what MITRE techniques and strategies are getting used.

Security part 4_32

There are over 120 alerts enabled out of the field, and you may create your personal customized watchlists.

Security part 4_33

For instance, if you happen to go to Settings > Alerts/Watchlists > Inside Connections Watchlist, we’ve created a watchlist that can alert us anytime an SSH connection is made to any host contained in the cluster.

Security part 4_34

If we run one other Nmap from the Netshoot pod to SSH to all hosts on the cluster community (nmap -p22), we are going to get an Inside Connection Watchlist alert.

Security part 4_35

Security part 4_36

This concludes the detailed directions! Please let me know in case you have any questions within the feedback part under, or through the GitHub points. Within the subsequent episode of this sequence, we are going to talk about Cloud Workload Safety Platform (CWPP) and the way we deploy and use CWPP in our cloud native surroundings.  Hope to see you then!

We’d love to listen to what you assume. Ask a query or depart a remark under.
And keep related with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Fb Developer Video Channel






Por favor ingrese su comentario!
Por favor ingrese su nombre aquí