In the 1st chapter of the book,Microservices Security in Action_, which I authored with _Nuwan Dias, we list out a set of key challenges in securing microservices, and then throughout the book see how we can methodically address them.
A monolithic application has few entry points. An entry point for an application is analogous to a door in a building. Just as a door lets you into a building (possibly after security screening), an application entry point lets your requests in.
Think about a web application running on the default HTTP port 80 on a server carrying the IP address 192.168.0.1. Port 80 on server 192.168.0.1 is an entry point to that web application. If the same web application accepts HTTPS requests on the same server on port 443, you have another entry point. When you have more entry points, you have more places to worry about securing. (You need to deploy more soldiers when you have a longer border to protect, for example, or to build a wall that closes all entry points.) The more entry points to an application, the broader the attack surface is.
A monolithic application typically has few entry points. Here, there are two: ports 80 and 443
Most monolithic applications have only a couple of entry points. Not every component of a monolithic application is exposed to the outside world and accepts requests directly.
In a typical Java EE web application such as the one in the above figure, all requests are scanned for security at the application level by a servlet filter.This security screening checks whether the current request is associated with a valid web session and, if not, challenges the requesting party to authenticate first.
Further access-control checks may validate that the requesting party has the necessary permissions to do what they intend to do. The servlet filter (the interceptor) carries out such checks centrally to make sure that only legitimate requests are dispatched to the corresponding components. Internal components need not worry about the legitimacy of the requests; they can rightly assume that if a request lands there, all the security checks have already been done.
In case those components need to know who the requesting party (or user) is or to find other information related to the user, such information can be retrieved from the web session, which is shared among all the components. The servlet filter injects the requesting-party information into the web session during the initial screening process, after completing authentication and authorization.
Multiple entry points (ports 80 and 443) are funneled to a single servlet filter. The filter acts as a centralized policy enforcement point.
Once a request is inside the application layer, you don’t need to worry about security when one component talks to another. When the Order Processing component talks to the Inventory component, for example, you don’t necessarily need to enforce any additional security checks (but, of course, you can if you need to enforce more granular access-control checks at the component level). These are in-process calls and in most cases are hard for a third party to intercept.
In most monolithic applications, security is enforced centrally, and individual components need not worry about carrying out additional checks unless there is a desperate requirement to do so. As a result, the security model of a monolithic application is much more straightforward than that of an application built around microservices architecture.
Mostly because of the inherent nature of microservices architecture, security is challenging. In this blog, we discuss the challenges of securing microservices without discussing in detail how to overcome them. In the book, we discuss multiple ways to address these challenges.
In a monolithic application, communication among internal components happens within a single process — in a Java application, for example, within the same Java Virtual Machine (JVM). Under microservices architecture, those internal components are designed as separate, independent microservices, and those in-process calls among internal components become remote calls. Also, each microservice now independently accepts requests or has its own entry points.
As opposed to a monolithic application with few entry points, a microservices-based application has many entry points that all must be secured.
Instead of a couple of entry points, as in a monolithic application, now you have a large number of entry points. As the number of entry points to the system increases, the attack surface broadens too. This situation is one of the fundamental challenges in building a security design for microservices. Each entry point to each microservice must be protected with equal strength. The security of a system is no stronger than the strength of its weakest link.
Unlike in a monolithic application, each microservice in a microservices deployment has to carry out independent security screening. From the viewpoint of a monolithic application, in which the security screening is done once and the request is dispatched to the corresponding component, having multiple security screenings at the entry point of each microservice seems redundant. Also, while validating requests at each microservice, you may need to connect to a remote security token service (STS). These repetitive, distributed security checks and remote connections could contribute heavily to latency and considerably degrade the performance of the system.
Some do work around this by simply trusting the network and avoiding security checks at each and every microservice. Over time, trust-the-network has become an antipattern, and the industry is moving toward zero-trust networking principles. With zero-trust networking principles, you carry out security much closer to each resource in your network. Any microservices security design must take overall performance into consideration and must take precautions to address any drawbacks.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
In terms of security, there are numerous challenges that you may encounter, especially in big data. Generally, big data are huge data sets that may be calculated using computers to find out relations, patterns, and trends, primarily which is linked to human interactions and behavior.
Since big data contains huge quantities of personally identifiable information, privacy becomes a major concern. The consequences of security breaches affecting big data can be devastating as it may affect a big group of people. For this reason, not only will the damage be reputational, but there would also be legal ramifications that organizations have to deal with.
Fortunately, there are numerous ways on how to overcome big data security challenges like bypass geo blocking , including the following:
#big data #latest news #security #big data security challenges: how to overcome them #big data security challenges #challenges
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)
#microservice #microservices architecture #security tokens #microservice security
The book Microservices Security in Action, which I authored with Nuwan Dias is now available to buy online from Amazon and Manning. Nuwan and I spent last 27+ months writing/re-writing the book. It was a marathon effort, but yet a great experience, and we both are very glad to see how it came out at the end! This is the story, which lead us to write the book.
While working at WSO2 for more than a decade, we’ve seen how the integration domain evolved over time from SOAP-based services to JSON/RESTful services and then to microservices. We spent most of our early days at WSO2 contributing to the Apache Axis2 project, which was a popular SOAP engine in those days, and to the Apache Rampart project, which implements many Organization for the Advancement of Structured Information Standards (OASIS) standards for web services security.
Even though SOAP was quite promising in those days, it started to fade rapidly over time, and clearly JSON/RESTful services had won. Most of the microservice implementations we see today follow RESTful design principles.
In the last two to three years, we’ve seen a genuine interest from many companies we’ve worked with to move into microservices architecture, and projects starting from scratch are adopting microservices principles. Most of the early adopters of microservices just wanted to get things done, and worried mostly about implementing functional requirements. They didn’t worry too much about security, although they should have. In many cases, securing microservices would mean securing the interactions among microservices with Transport Layer Security (TLS), and may be, for some, enforcing mutual TLS for service-to-service authentication. But none of them are quite adequate. There are two main reasons many didn’t worry much about security: complexity and awareness.
Some time back, we found that most tools for securing microservices were not easy to use or couldn’t address the challenges specific to microservices deployments. This complexity was a barrier to securing microservices. At the same time, people who didn’t put much effort into security weren’t fully aware of the risks. We started hearing these stories from many of our customers as well as from the extended open source community we work with. That motivated us to write this book on securing microservices. Bringing an idea from inception to reality takes considerable time and effort.
We lived with this idea of writing a book for more than two years until Manning reached out to us. During that period, with the increased adoption of microservices, the infrastructure around microservices security also evolved.
Writing a book about a rapidly evolving domain is bit of a challenge; you never know when your book will be obsolete. After discussing this challenge with the publisher, we decided to put more weight on principles and patterns, and use tools just to demonstrate how to apply those principles and patterns in practice. This was our ground rule in picking up the technology stack for the book. We use Spring Boot/Java to develop all the samples, though we don’t expect you to know either Java or Spring Boot in detail. If you have development experience in any programming language, you should be able to follow all the samples in the book with no difficulty.
Security itself is a larger domain. Securing microservices can mean different things to different people, based on their experiences and expectations. This fact was highlighted by one of the reviewers of the book, who comes from a security testing background.
In our book, we wanted to focus on managing access to microservices. In other words, we wanted to focus on securing access to microservices with authentication and authorization. So, the book doesn’t talk about protecting microservices against different types of attacks, such as SQL injection, cross-site scripting (XSS), cross-site request forgery, and so on.
#security #microservices #book review #microservices security
With an immense number of companies and entities climbing onto the digital bandwagon, cybersecurity considerations have come up as limelight. Besides, new technologies such as Big Data, IoT, and Artificial Intelligence/Machine Learning are gradually more making inroads into our everyday lives, the threats related to cybercrime are mounting as well. Additionally, the usage of mobile and web apps in transacting financial information has put the complete digital stuff exposed to cybersecurity breaches. The inherent risks and vulnerabilities found in such apps can be exploited by attackers or cybercriminals to draw off crucial information data counting money. Internationally, cyber-security breaches have caused a yearly loss of USD 20.38 million in 2019 (Source: Statista). Plus, cybercrime has led to a 0.80 percent loss of the entire world’s Gross domestic product, which sums up to approx. USD 2.1 trillion in the year 2019 alone (Source: Cybriant.com).
In this article, take a look at ten cyber security tools to watch out for in 2021, including NMap, Wireshark, Metasploit, and more!
#security #cyber security #security testing #security testing tools #cyber security tools