How to Secure Microservices: 3 Key Practices

The big promise of microservices is freedom – freedom to break an application into disparate services that are deployable independently, freedom to build these distinct services with different teams through their chosen programming language, database, and tooling, and freedom to develop applications with minimal bureaucracy. But with freedom comes the onus to ensure security.

In a microservices architecture, applications are broken down into independent services, which implies more complexities and more services to secure. There are technology strategies to all of this, yet only people can effectively secure microservices. Developers take on more responsibility for operating their code (DevOps) and securing the same code (DevSecOps). This drives a different kind of behavior relative to design, the kind of monitoring and tooling you have, and how you interface with systems that are built using a microservices architectural style. After all, strong microservices security is guaranteed by three guiding principles: traceability and development, compartmentalization, and continuous security visibility. These principles make life easy for security professionals and developers.

Traceability

The first key to ensure security is to build it into your continuous delivery (CD) workflow. It’s within the CD workflow that you insert tests and restrict regions for deployment and also set time for such restrictions. Doing so automates service delivery and guarantees auditability. Don’t create a group of new tools and new dashboards that people have to use. Don’t create interruptions in their workflow. Rather, integrate with the workflows and tooling developers are using already. The tool that you use is not more important than how you use it. As you work with the developers’ preferred workflow and automate as much as possible, security teams can upkeep with the speed and agility benefits of microservices, while assuring security checks are well-placed.

Another common and well-known technique to guarantee that a new service doesn’t introduce security or other problems is by launching a “canary workload”. A canary workload refers to a new production workload launched to a limited set of users. If this workload doesn’t trigger any automated security alert and looks good, the CD tool automatically rolls it into full production.

Continuous Security Visibility

Irrespective of the size of your organization, it is impossible to have enough security resources to penetration test every application or look at all lines of code. And then, one of the basic attributes of microservices is that they speed up change within and between applications. When you have hundreds or just dozens of applications that undergo change all the time, you need not rely on people giving information in an accurate or timely manner. Instead, you need automation or employ service discovery tools.

Service discovery can be defined as a registry of running instances for one or multiple services. As you employ service discovery tools, you can measure the riskiness of a specific service based on how many other services are dependent on it. The more the services depend on that particular service, the higher is its risk score. You also need to check if that service is exposed to external Internet traffic. Automated security risk assessment thus helps you with stratification of risk, allowing relatively scarce security people to focus on the microservices with maximum risk exposure. The majority of microservice frameworks offer one or many choices for service discovery.

Compartmentalization

The principle of compartmentalization is crucial for distributed systems as well as the microservices that constitute them. There are two reasons behind this criticality. First, all security will probably fail at some point, which urges you to limit the blast radius of that failure. Second, you need to keep the data reserved only for those who need to know.

In the case of a monolithic application, things are lumped together. Services are not independent of one another. Developers thus struggle to iterate on monoliths without breaking things during the process with every breakpoint introducing new security issues. Monolithic applications have quite sensitive systems with a lot of inputs and outputs, i.e. attack surfaces. Applications that have a large attack surface can be secured, but it isn’t easy to do so. In addition, it is harder to verify that things are working as they should.

In the case of a microservices application, however, security is effective and better. Here, the “blast radius” isn’t the entire application, rather it’s just the individual services. There are various security-forward companies who choose to further improve on the security model with a token vault that stores sensitive data. Tokens map to this sensitive data and these tokens can then be passed around the application without the data itself moving. The token service calls crypto infrastructure that is placed between the token and the sensitive data, thus protecting the data. You can thus execute much finer-grained access control, making it quite easy to trace what’s happening.

#microservices architecture #microservices application #microservices

What is GEEK

Buddha Community

Best Custom Web & Mobile App Development Company

Everything around us has become smart, like smart infrastructures, smart cities, autonomous vehicles, to name a few. The innovation of smart devices makes it possible to achieve these heights in science and technology. But, data is vulnerable, there is a risk of attack by cybercriminals. To get started, let’s know about IoT devices.

What are IoT devices?

The Internet Of Things(IoT) is a system that interrelates computer devices like sensors, software, and actuators, digital machines, etc. They are linked together with particular objects that work through the internet and transfer data over devices without humans interference.

Famous examples are Amazon Alexa, Apple SIRI, Interconnected baby monitors, video doorbells, and smart thermostats.

How could your IoT devices be vulnerable?

When technologies grow and evolve, risks are also on the high stakes. Ransomware attacks are on the continuous increase; securing data has become the top priority.

When you think your smart home won’t fudge a thing against cybercriminals, you should also know that they are vulnerable. When cybercriminals access our smart voice speakers like Amazon Alexa or Apple Siri, it becomes easy for them to steal your data.

Cybersecurity report 2020 says popular hacking forums expose 770 million email addresses and 21 million unique passwords, 620 million accounts have been compromised from 16 hacked websites.

The attacks are likely to increase every year. To help you secure your data of IoT devices, here are some best tips you can implement.

Tips to secure your IoT devices

1. Change Default Router Name

Your router has the default name of make and model. When we stick with the manufacturer name, attackers can quickly identify our make and model. So give the router name different from your addresses, without giving away personal information.

2. Know your connected network and connected devices

If your devices are connected to the internet, these connections are vulnerable to cyber attacks when your devices don’t have the proper security. Almost every web interface is equipped with multiple devices, so it’s hard to track the device. But, it’s crucial to stay aware of them.

3. Change default usernames and passwords

When we use the default usernames and passwords, it is attackable. Because the cybercriminals possibly know the default passwords come with IoT devices. So use strong passwords to access our IoT devices.

4. Manage strong, Unique passwords for your IoT devices and accounts

Use strong or unique passwords that are easily assumed, such as ‘123456’ or ‘password1234’ to protect your accounts. Give strong and complex passwords formed by combinations of alphabets, numeric, and not easily bypassed symbols.

Also, change passwords for multiple accounts and change them regularly to avoid attacks. We can also set several attempts to wrong passwords to set locking the account to safeguard from the hackers.

5. Do not use Public WI-FI Networks

Are you try to keep an eye on your IoT devices through your mobile devices in different locations. I recommend you not to use the public WI-FI network to access them. Because they are easily accessible through for everyone, you are still in a hurry to access, use VPN that gives them protection against cyber-attacks, giving them privacy and security features, for example, using Express VPN.

6. Establish firewalls to discover the vulnerabilities

There are software and firewalls like intrusion detection system/intrusion prevention system in the market. This will be useful to screen and analyze the wire traffic of a network. You can identify the security weakness by the firewall scanners within the network structure. Use these firewalls to get rid of unwanted security issues and vulnerabilities.

7. Reconfigure your device settings

Every smart device comes with the insecure default settings, and sometimes we are not able to change these default settings configurations. These conditions need to be assessed and need to reconfigure the default settings.

8. Authenticate the IoT applications

Nowadays, every smart app offers authentication to secure the accounts. There are many types of authentication methods like single-factor authentication, two-step authentication, and multi-factor authentication. Use any one of these to send a one time password (OTP) to verify the user who logs in the smart device to keep our accounts from falling into the wrong hands.

9. Update the device software up to date

Every smart device manufacturer releases updates to fix bugs in their software. These security patches help us to improve our protection of the device. Also, update the software on the smartphone, which we are used to monitoring the IoT devices to avoid vulnerabilities.

10. Track the smartphones and keep them safe

When we connect the smart home to the smartphone and control them via smartphone, you need to keep them safe. If you miss the phone almost, every personal information is at risk to the cybercriminals. But sometimes it happens by accident, makes sure that you can clear all the data remotely.

However, securing smart devices is essential in the world of data. There are still cybercriminals bypassing the securities. So make sure to do the safety measures to avoid our accounts falling out into the wrong hands. I hope these steps will help you all to secure your IoT devices.

If you have any, feel free to share them in the comments! I’d love to know them.

Are you looking for more? Subscribe to weekly newsletters that can help your stay updated IoT application developments.

#iot #enterprise iot security #how iot can be used to enhance security #how to improve iot security #how to protect iot devices from hackers #how to secure iot devices #iot security #iot security devices #iot security offerings #iot security technologies iot security plus #iot vulnerable devices #risk based iot security program

How to Secure Microservices: 3 Key Practices

The big promise of microservices is freedom – freedom to break an application into disparate services that are deployable independently, freedom to build these distinct services with different teams through their chosen programming language, database, and tooling, and freedom to develop applications with minimal bureaucracy. But with freedom comes the onus to ensure security.

In a microservices architecture, applications are broken down into independent services, which implies more complexities and more services to secure. There are technology strategies to all of this, yet only people can effectively secure microservices. Developers take on more responsibility for operating their code (DevOps) and securing the same code (DevSecOps). This drives a different kind of behavior relative to design, the kind of monitoring and tooling you have, and how you interface with systems that are built using a microservices architectural style. After all, strong microservices security is guaranteed by three guiding principles: traceability and development, compartmentalization, and continuous security visibility. These principles make life easy for security professionals and developers.

Traceability

The first key to ensure security is to build it into your continuous delivery (CD) workflow. It’s within the CD workflow that you insert tests and restrict regions for deployment and also set time for such restrictions. Doing so automates service delivery and guarantees auditability. Don’t create a group of new tools and new dashboards that people have to use. Don’t create interruptions in their workflow. Rather, integrate with the workflows and tooling developers are using already. The tool that you use is not more important than how you use it. As you work with the developers’ preferred workflow and automate as much as possible, security teams can upkeep with the speed and agility benefits of microservices, while assuring security checks are well-placed.

Another common and well-known technique to guarantee that a new service doesn’t introduce security or other problems is by launching a “canary workload”. A canary workload refers to a new production workload launched to a limited set of users. If this workload doesn’t trigger any automated security alert and looks good, the CD tool automatically rolls it into full production.

Continuous Security Visibility

Irrespective of the size of your organization, it is impossible to have enough security resources to penetration test every application or look at all lines of code. And then, one of the basic attributes of microservices is that they speed up change within and between applications. When you have hundreds or just dozens of applications that undergo change all the time, you need not rely on people giving information in an accurate or timely manner. Instead, you need automation or employ service discovery tools.

Service discovery can be defined as a registry of running instances for one or multiple services. As you employ service discovery tools, you can measure the riskiness of a specific service based on how many other services are dependent on it. The more the services depend on that particular service, the higher is its risk score. You also need to check if that service is exposed to external Internet traffic. Automated security risk assessment thus helps you with stratification of risk, allowing relatively scarce security people to focus on the microservices with maximum risk exposure. The majority of microservice frameworks offer one or many choices for service discovery.

Compartmentalization

The principle of compartmentalization is crucial for distributed systems as well as the microservices that constitute them. There are two reasons behind this criticality. First, all security will probably fail at some point, which urges you to limit the blast radius of that failure. Second, you need to keep the data reserved only for those who need to know.

In the case of a monolithic application, things are lumped together. Services are not independent of one another. Developers thus struggle to iterate on monoliths without breaking things during the process with every breakpoint introducing new security issues. Monolithic applications have quite sensitive systems with a lot of inputs and outputs, i.e. attack surfaces. Applications that have a large attack surface can be secured, but it isn’t easy to do so. In addition, it is harder to verify that things are working as they should.

In the case of a microservices application, however, security is effective and better. Here, the “blast radius” isn’t the entire application, rather it’s just the individual services. There are various security-forward companies who choose to further improve on the security model with a token vault that stores sensitive data. Tokens map to this sensitive data and these tokens can then be passed around the application without the data itself moving. The token service calls crypto infrastructure that is placed between the token and the sensitive data, thus protecting the data. You can thus execute much finer-grained access control, making it quite easy to trace what’s happening.

#microservices architecture #microservices application #microservices

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

Last year, we provided a list of Kubernetes tools that proved so popular we have decided to curate another list of some useful additions for working with the platform—among which are many tools that we personally use here at Caylent. Check out the original tools list here in case you missed it.

According to a recent survey done by Stackrox, the dominance Kubernetes enjoys in the market continues to be reinforced, with 86% of respondents using it for container orchestration.

(State of Kubernetes and Container Security, 2020)

And as you can see below, more and more companies are jumping into containerization for their apps. If you’re among them, here are some tools to aid you going forward as Kubernetes continues its rapid growth.

(State of Kubernetes and Container Security, 2020)

#blog #tools #amazon elastic kubernetes service #application security #aws kms #botkube #caylent #cli #container monitoring #container orchestration tools #container security #containers #continuous delivery #continuous deployment #continuous integration #contour #developers #development #developments #draft #eksctl #firewall #gcp #github #harbor #helm #helm charts #helm-2to3 #helm-aws-secret-plugin #helm-docs #helm-operator-get-started #helm-secrets #iam #json #k-rail #k3s #k3sup #k8s #keel.sh #keycloak #kiali #kiam #klum #knative #krew #ksniff #kube #kube-prod-runtime #kube-ps1 #kube-scan #kube-state-metrics #kube2iam #kubeapps #kubebuilder #kubeconfig #kubectl #kubectl-aws-secrets #kubefwd #kubernetes #kubernetes command line tool #kubernetes configuration #kubernetes deployment #kubernetes in development #kubernetes in production #kubernetes ingress #kubernetes interfaces #kubernetes monitoring #kubernetes networking #kubernetes observability #kubernetes plugins #kubernetes secrets #kubernetes security #kubernetes security best practices #kubernetes security vendors #kubernetes service discovery #kubernetic #kubesec #kubeterminal #kubeval #kudo #kuma #microsoft azure key vault #mozilla sops #octant #octarine #open source #palo alto kubernetes security #permission-manager #pgp #rafay #rakess #rancher #rook #secrets operations #serverless function #service mesh #shell-operator #snyk #snyk container #sonobuoy #strongdm #tcpdump #tenkai #testing #tigera #tilt #vert.x #wireshark #yaml

Microservices and Its Security Patterns

Common security patterns used in most of the API architecture practices.

What Are Microservices?

A microservice is a single business unit where all data and functions that are relevant to a single business purpose are put into one service.

Well, this is the general understanding of a microservice, but what do we really mean by it?

Here we can take the example of Legos, yes, you read that right, Legos.

You may remember when we used to play with Legos that we start building our whole piece from an individual Lego brick.

Just like each Lego brick is independent of each other, each microservices is independent, but come together to make something greater.

Here we can compare each microservice to a single Lego brick.

A single microservice

A complete application (containing multiple loosely coupled microservices)

Benefits of Using a Microservices Architecture

• Isolation
• Scalability
• Productivity
• Flexibility
• Faster project development
• Evolutionary

#microservice #microservices architecture #security tokens #microservice security

Testing Microservices Applications

The shift towards microservices and modular applications makes testing more important and more challenging at the same time. You have to make sure that the microservices running in containers perform well and as intended, but you can no longer rely on conventional testing strategies to get the job done.

This is where new testing approaches are needed. Testing your microservices applications require the right approach, a suitable set of tools, and immense attention to details. This article will guide you through the process of testing your microservices and talk about the challenges you will have to overcome along the way. Let’s get started, shall we?

A Brave New World

Traditionally, testing a monolith application meant configuring a test environment and setting up all of the application components in a way that matched the production environment. It took time to set up the testing environment, and there were a lot of complexities around the process.

Testing also requires the application to run in full. It is not possible to test monolith apps on a per-component basis, mainly because there is usually a base code that ties everything together, and the app is designed to run as a complete app to work properly.

Microservices running in containers offer one particular advantage: universal compatibility. You don’t have to match the testing environment with the deployment architecture exactly, and you can get away with testing individual components rather than the full app in some situations.

Of course, you will have to embrace the new cloud-native approach across the pipeline. Rather than creating critical dependencies between microservices, you need to treat each one as a semi-independent module.

The only monolith or centralized portion of the application is the database, but this too is an easy challenge to overcome. As long as you have a persistent database running on your test environment, you can perform tests at any time.

Keep in mind that there are additional things to focus on when testing microservices.

• Microservices rely on network communications to talk to each other, so network reliability and requirements must be part of the testing.
• Automation and infrastructure elements are now added as codes, and you have to make sure that they also run properly when microservices are pushed through the pipeline
• While containerization is universal, you still have to pay attention to specific dependencies and create a testing strategy that allows for those dependencies to be included

Test containers are the method of choice for many developers. Unlike monolith apps, which lets you use stubs and mocks for testing, microservices need to be tested in test containers. Many CI/CD pipelines actually integrate production microservices as part of the testing process.

Contract Testing as an Approach

As mentioned before, there are many ways to test microservices effectively, but the one approach that developers now use reliably is contract testing. Loosely coupled microservices can be tested in an effective and efficient way using contract testing, mainly because this testing approach focuses on contracts; in other words, it focuses on how components or microservices communicate with each other.

Syntax and semantics construct how components communicate with each other. By defining syntax and semantics in a standardized way and testing microservices based on their ability to generate the right message formats and meet behavioral expectations, you can rest assured knowing that the microservices will behave as intended when deployed.

#testing #software testing #test automation #microservice architecture #microservice #test #software test automation #microservice best practices #microservice deployment #microservice components