Developers and their applications are the backbone of organisations across the world.

But in recent years, large scale security breaches have put data protection at the forefront for product development teams. With the likes of the GDPR now in place, security must be a priority.

So who is stepping up to take responsibility for the future and current applications being rolled out on a daily basis by modern IT organisations?

We put these questions to over 1,500 developers and IT decision-makers (ITDM) across Europe. In this post and the zine below, we’ll analyse the findings, unpick the tensions and set some key next steps.

What can developers do

The stakes are higher. Security must be the number one priority. The good news is developers agree.

Developers (92%) and the decision-makers (88%) reassure us that they take appropriate precautions when building new applications.

What’s more, both agree that the security of data is their top concern when procuring new software – 53% of ITDMs and 47% of devs. This is good to see.

What about the software we build?

This alignment, however, splits when it comes to writing software. But why?

It falls down to balancing priorities.

There is no security without first having functionality, so the responsibility is naturally distributed across different organizations. The good news is ITDMs and developers are mostly well aligned on the ratio of responsibilities, which means there is no source of conflict here.

When we asked developers who has the most responsibility for securing an application, just 29% cited themselves while the rest pointed the finger at security specialists (22%), the business leaders who briefed the project (18%), the ops team (16%) and even security members they don’t know (14%).

This compares well with ITDMs. The majority of them (28%) believe a security specialist holds the most responsibility. Yet a further 21% see it to be developers and an additional 21% point at the business leader who briefed the build.

So what does it all mean?

Lena Smart, Chief Information Security Officer at MongoDB articulates the challenges well:

“Control and convenience have long clashed. Developers are under relentless pressure to deliver – on time, to specification, securely and at scale. It’s a challenge that will only continue.”

How do we ensure that we can reconcile strong security with a need to deliver utility quickly to users?

Agile, MicroServices and DevOps are all disciplines that have worked hard to increase the rate at which software can adapt to changing business requirements. How do we bake security into the mix so we don’t end up adding it badly in a rush at the end?

The answer is DevSecOps.

Direction in disruption

Creating a ‘security as code’ culture with ongoing, flexible collaboration between release engineers and security teams will help mitigate the challenges. This is a people, process and technology task across the application delivery pipeline – from design and coding to testing and support.

It will help ensure a working balance between control and convenience where feedback loops give security the priority it deserves.

DevSecOps won’t be a smooth process right off the bat. It will take both skill and culture changes. Which means work and patience.

“When done properly, DevSecOps can provide deeper visibility and a better understanding of how resources are being used. It should become and remain a key part of an organisation’s development strategy,” shared Smart.

Here is how to get started.

Five principles of DevSecOps

1. Baked in

Security must be baked in. Consider any and all negative impacts a new feature may unknowingly cause, rather than just focusing on the positive impact it may generate.

2. Get specific

Determine your own organisation’s needs and goals and choose the right solutions for your situation. Not one size fits all.

3. Adopt a people approach

Infuse security principles at every step, and into every collaborator, including developers. It’s a team sport where skills and culture matter equally.

4. Share information

Open collaboration is essential in DevSecOps. Share, learn and improve constantly by communicating internally to meet your goals.

5. Be ambitious

Don’t put your ambitions on the back burner. Many cloud platforms today offer built-in security controls for all your data. Take the leap to the cloud.

—

About MongoDB

MongoDB is the leading modern, general-purpose database platform, designed to unleash the power of software and data for developers and the applications they build. Headquartered in New York, MongoDB has more than 15,000 customers in over 100 countries. The MongoDB database platform has been downloaded over 70 million times and there have been more than one million MongoDB University registrations.

Data background

* In June and in partnership with CensusWide, we surveyed 1516 people split evenly across France, Germany and the UK. There were two groups we spoke to – developers and IT decision-makers.

Developers were defined as ‘An individual that builds and creates software applications. Their role includes writing, debugging and executing the code of an application’.

IT Decision Maker, which I know is a slightly made-up industry term, were defined as ‘an employee who is empowered to make strategic IT decisions within a company including (but not limited to): recruitment processes for IT professionals, procurement of new IT software and hardware, technologically-focussed R&D decisions, data management and data security.’

The post Five security principles developers must follow appeared first on Artificial Intelligence.

Despite having brought forth a revolution in application design and deployment, microservices can create profound, even critical, security and compliance problems. To meet microservices-based development and deployment goals, you are often required to step into new areas of application design, including areas that defeat many of the traditional mechanisms for securing applications. Just as microservices possess multidimensional benefits, they also need multidimensional and layered security.

The post How to build a layered approach to security in microservices appeared first on Artificial Intelligence.

In the world of microservices, the goal is to have a small piece of software that performs a well-defined set of tasks. Microservices are software applications that are self-contained. They are small, independently deployable modular services that run a unique process and communicate through a well-defined, lightweight mechanism to serve a specific goal.

Typically, clear boundaries are set with regards to what your microservice can or cannot do. The move to microservices requires not only a change in architecture, but also a solid foundation of trust between the different teams who are working together to develop these microservices. Building this trust gives them the confidence they need to rely on the services’ availability and adherence to the agreed upon service contract for standard APIs.

Without a high level of trust between teams of developers, chaos will quickly ensue in your development organisation. Each team will build whatever they want and/or change APIs without notifying the rest of the organisation. In this state of disarray, functionality will break and your software development will come to a grinding halt.

While trust is extremely important in developing microservices, planning ahead for potential security issues is even more critical. Unfortunately, security considerations are often overlooked in the process of transitioning to microservices. The consequences of security failings can be devastating for your company.

For example, let’s say you are deploying a microservice that accepts input from a user and passes that input to a backend database. If your service is not secure and the input is not validated, hackers will be able to inject malicious code into the system and bring down your service — or perhaps even worse, compromise your entire system.

A plethora of microservices

As your repertoire of services and applications grows, it is probably safe to assume that the number of available microservices will grow as well. As the number of options increases, more and more security issues are bound to come up. In this post, we will review some of the issues and potential solutions that you should take into consideration before your business makes the shift to using microservices.

Reuse of code

Using shared code and libraries can help you jumpstart your move to microservices, but it can also be a double-edged sword. If you choose to borrow and use something off of the internet (i.e., an open-source solution), you are forever tied to that code and all of its shortcomings.

On one hand, reuse of industry standard technology can be a good thing since it has already been tested and used around the world. On the other hand, widespread usage of standard technology can be problematic. If a component vulnerability surfaces, your company and other companies that are using the technology will need to apply emergency patches to mitigate critical flaws in all of your applications. Imagine what it would be like to have to either deploy all of your services again because of a new security package, or to patch the servers with a whole new binary. Such a scenario sounds like a nightmare, doesn’t it?

Take the Heartbleed bug for example. When the bug was discovered in April of 2014, approximately 66 per cent of the internet’s web servers needed to be patched because the software that included the vulnerable libraries was used on almost all of the world’s web servers. This catastrophe required the patching and rebooting of hundreds of thousands of servers in a very short period of time.

If you happen to have a smaller number of servers, the solutions of deploying everything again or patching with a new binary are doable, either manually or with a basic amount of scripting. But when you scale, these are no longer viable options for solving your problem. In these cases with scaling, you need to have a tried and tested method of orchestration already in place in order for you to perform mass operations quickly to alleviate the problems.

Denial of service

Ensuring that your applications are secure is no easy feat, and managing a number of services that have multiple entry points from the outside can be difficult. As the number of services grow, the magnitude of this issue is amplified. Managing security groups appropriately will help you ensure that only the correct ports are exposed. Doing so can help save you and your applications a significant amount of pain and anguish if a malicious party targets your product in an attack.

Setting up a firewall application or an alternative solution in front of your system can correct a problem like this by ensuring that only the appropriate traffic arrives at your application’s front door and that it does not contain malicious codes or threats.

Traffic between microservices

Each microservice passes information from one to another. When the traffic is in a segregated part of your own network, it is safe to assume that your risk of having an eavesdropper is decreased since you are usually behind a corporate firewall, which makes you less susceptible to man-in-the-middle attacks.

When you move to the cloud, this assumption is no longer valid. Traffic between your microservices should be encrypted on the cloud. This means that, in addition to your microservices handling encrypted traffic, they will also need to ensure that the performance of your underlying applications does not suffer as a result of the extra work they have to perform with encrypting and decrypting information.

There are a number of methods that you can use to mitigate this problem. One such solution is creating a Virtual Private Cloud (VPC), which will enable you to segregate your workloads in the cloud without allowing a malicious intruder into the system who could eavesdrop on your traffic. However, this is not a foolproof solution, and it still has a number of attack vectors that you will need to address. Another option is offloading the encryption to an external service (e.g., a load balancing service) that will enable traffic protection with minimal disruption or changes to your current system.

Secret sharing

In order to make sure that your microservices are not open to the world, we suggest that you add authentication between the services in your system. Doing so will ensure that only the correct pieces are allowed to talk with each other and that they have the proper credentials to do so.

Embedding these secrets into your applications is a very bad idea. Best practices for modern architecture strongly advise against storing any credentials on your servers. Of course, this brings up the question of how you will allow applications to authenticate with each other and third-party services if the credentials cannot be stored locally?

There are a few ways to tackle this problem. One strategy is to use third-party tools or the tools and services that are already available from most cloud providers. The concept is pretty simple. When you initiate an authentication request, you ask another service to request a temporary set of credentials on your behalf, which allows you access for a set period of time. This solves the issue of longevity of credentials because they expire after a certain period of time, and because there are no credentials that are embedded in the microservice itself.

Security across the board

It is highly unlikely that those who are producing the microservice will actually belong to a single team. It makes sense that each team will develop, test, and deploy their own microservice (or set thereof). Therefore, the responsibility of securing the service cannot lie solely with a single, traditional operation security team and organisation—it should lie with all of the teams that are producing the software.

In order to ensure that your company will be protected and secure from outside attackers, we recommend that you consider some sort of partnership between the traditional OPSEC team and the developers. Establishing such a partnership will help the participants work together so that the software they are producing is secure by default, hardened, and continuously tested for compliance against a baseline of security requirements before it goes out the door. When the responsibility also lies with the teams who are creating the service, their level of engagement and awareness will definitely increase.

Code changes

The last issue we will address is the lifecycle of the application. No one writes software that is 100 per cent perfect the first time around — there will always be some bugs to fix before the software runs as efficiently as it is supposed to. For example, the foundation of Agile methodology is reiterated all the time, providing only the minimal viable product and improving as you progress with the project.

When you are dealing with microservices, there can be several changes each day. When you upgrade your application by changing or adding functionality, you will need to ensure that your code is (at minimum) the same as it was before, if not even better. This requires scanning the added code for vulnerabilities and weaknesses before the code is even deployed. You will need to tie this into your continuous integration processes so that this is performed as part of your release process.

Summary

Maintaining a secure system is usually a daunting task, and with the shift to microservices, there is an additional vector that needs to be addressed. Each microservice has its respective weak points that need to be secured, hardened, and continuously monitored for vulnerabilities.

The scope of this task should not be underestimated — as your use of microservice architecture grows, security issues become more significant and urgent. To protect yourself and your company, you should address these security issues early and often. We encourage you to use the suggestions from this post to help you with the process of securing your microservices.

The post Security in the world of microservices appeared first on Artificial Intelligence.

he emergence of microservices boosts business agility, enabling rapid application development, deployment and modification. The challenge is baking in microservices security processes. Traditional security processes can’t secure microservices, because the latter work in and communicate between both internal and external environments, according to Amir Jerbi, CTO of Aqua Security, a container security platform provider.

Using microservices makes security easier for developers or architects in some ways and harder in others. In this Q&A, Aqua Security Co-founder Jerbi offers advice on avoiding mistakes in setting up microservices security and balancing the often-conflicting needs for steel-trap security and rapid deployment of and communication between microservices.

What are the security pros and cons of microservices?

Amir Jerbi: Before cloud, you deployed your software on premises. You had to use the on-prem mechanism in order to secure your application. You had to use a firewall, host-based intrusion protection and maybe a code analysis tool and/or a tool to test for insecure coding. However, when deploying that app in the cloud, you had to use different tool sets and methodologies and build and deploy on one or separate cloud bases. With the shift to using microservices and containers, you can actually use the same tool set and methodologies to deploy on prem or in the cloud and even on every kind of cloud platform.

Microservices make it easier to develop an app that can run on multiple cloud platforms, because you’re using the same packaging and the same artifacts, and you can actually secure them exactly the same way. So, microservices can enable greater consistency in the way that you build, deploy and secure software.

What are some mistakes that could be made in developing and deploying microservices and building a microservices architecture that could lead to security issues?

Jerbi: With the monolithic architecture and application, all of the communications between different parts of apps would be internal. Now, to secure microservices, it’s more complex than that. You have multiple microservices running either on the same machine or distributed host, and there is a lot of communication between those microservices. Some of the communication can be on the same machine, some between different machines and some between different data centers.

When there are so many communications done between those microservices, it means that the perimeter is not something that is well-defined. You can’t put everything inside of a box and just protect that box. It’s not enough just to put a firewall in place, because all those communications must be governed and authenticated.

Easier app updating is a benefit of microservices. A developer can just redeploy a single microservice while letting the application run consistently. Doesn’t that require change management to be done differently than before in order to secure microservices and apps?

Jerbi: Yes. You need to make sure that the change that you’re adding to your system is controlled, and the software that is added doesn’t impact overall security of your application. Now, you need to manage so many small pieces, and that will require different mechanisms for authentication.

Microservice systems, many times, are open, allowing communication between the different services without any security control. So, it’s important to find ways to do strong authentication between microservices.

One way to do microservices authentication well is adopting a well-established authentication framework, like TLS [Transport Layer Security], and implementing two-factor authentication between all of the microservices. But to do that, you need to maintain new methods in order to publish security certificates and maintain those certificates. This is very different from traditional authentication, where they only needed to maintain TLS for the web server, which is much easier.

Are there other security perils that come with microservices?

Jerbi: There is a friction between the need for diligence in security and the need to make and deploy changes very, very fast because, well, you can and your competitors can, too.

Cloud deployment runs so fast today that Netflix and Google can roll out updates many times a day. Others want to do the same but often proceed without thinking through the security piece. The result can be pushing new changes into production apps without understanding the security impact of the change.

Traditionally, a security process ran slow. It required multiple intervals. It was a process that touched all along the pipeline. Now, people traditionally in charge of testing software and pushing it very fast to production are now also tasked with security — largely, securing the code. Wisely, many are taking the DevSecOps approach, wherein a group takes charge of security with a standard set of processes, such as two-factor authentication, RASP[runtime application self-protection], threat [modeling, etc.].

Which other approaches for securing microservices do you find useful?

Jerbi: Shift left testing is more focused on developers, and it allows you to do security analysis of your code or your microservices or your packages. Shift left allows you to fail fast and to fail the build, often to fail due to security issues. It might slow down development processes a bit, but it helps developers understand what’s needed from them in order to build applications with better security. Over time, the knowledge that comes from doing shift left will increase the level of overall security in the organization and allow faster deployment times. That’s because the code will be secure before deployment, and there won’t be after-deployment bottlenecks.

The post Aqua Security CTO reveals how to secure microservices appeared first on Artificial Intelligence.

In this Q&A, Daniel Bryant, CTO at SpectoLabs and an independent technical consultant, talks about some of the challenges that come up when addressing microservices security and some of the tools and techniques you can use.

Compared to more traditional architectures, what new challenges have microservices introduced in terms of security?

Daniel Bryant: In the traditional approach, you had one thing. So, if it was compromised, you’re in trouble. It’s like putting all your eggs in one basket kind of thing. The flip side of that is, when you break things up, suddenly, you’ve got to secure many more things. The attack surface gets much bigger. No longer are you doing things like hardening the edges, and then you won’t look behind it.

The biggest challenge now is that every developer has to be that much more conscious of security. There’s a lot more things, there’s a lot more attack surface and there’s a lot more communication going between all those things that is exposed.

What kind of tooling and techniques are important for microservices security?

Bryant: There are things like web application firewalls, [which are] very popular. A lot of companies I’ve worked with use things like F5, and they’re actually F5 firewalls. Increasingly, we’re seeing more software firewalls, even with Amazon.

That’s clearly prevention, but you also need to think about detection. So, basic stuff: logging low bands in traffic, logging the web traffic, logging SSH [Secure Socket Shell] access. [In] any public-facing web server, if you look through the logs, people are constantly probing the edges. [So,] you want to see [if it’s] only from this IP address or only from this country … you want to be doing sort of some kind of like continual analysis of where stuff is coming from.

[Also,] what attacks are there? What vectors are they trying to probe? If you’re not patching your systems, they may sort of get lucky one day. So, you definitely need detection and need to make sure everything’s patched up. [People will say:] ‘Yeah, we spend all this money on networks and on compute.’ That’s all great stuff, but don’t forget about the application. If the application has a massive vulnerability, all that other stuff is for nothing. It only takes one point of entry for someone to get in and start doing damage.

I definitely think things like threat modeling [are also] super useful. Understand how threats work, what threats there are and model how they might attack your system. And often, I find, a side effect of modeling things properly opens up my eyes to different ways things happen. So, if you start doing attack vectors, you suddenly think, ‘Well, I’m really hardening this thing in the application,’ where you realize there’s a massive flaw in your email system or something.

[And] OWASP [Open Web Application Security Project], they’re an awesome organization. They have a bunch of language sort of diagnostic tools for scanning for critical vulnerabilities in dependencies. So, if I’m using Java or Maven, I can put it in my Maven Palm. If I’m using Ruby, I can put it in my gems.

What’s the question everyone should be asking when it comes to microservices security?

Bryant: How can I contribute? Ask your team, ask your management, your leaders: What can I do? What’s my job in relation to our security? Should I be following certain standards? Should I be double-checking my work? These kind of things [are] the most critical.

I really think microservices security isn’t massively different to traditional security. As developers, we’re taking on more and more … I’ve got to be an operations person as well as the developer. You know, front end, back end, all these things. If you’re not careful, you become like sort of a mile wide and an inch deep.

But at the same time, if you as a developer are really well-educated across the stack but don’t know too much about security, it’s very easy to leave massive holes. If you leave some massive security holes, that’s potentially very bad. So, developing awareness, modeling, documenting, sharing, coming to conferences, chatting with people, learning as much as you can … those are all important.

What do you find that experts are still scratching their heads about when it comes to microservices security … the one thing that people still can’t really seem to get right?

Bryant: It’s not tacked [specifically] to microservices; it’s more of a case of as the world is getting more and more connected. There are things like bitcoin [that are] more and more attractive for attackers to attack now.

I think, as an industry, we’re not as responsible as we should be. So, it’s more of a case it’s just the human factor again. Are we paying enough attention to it as developers or as architects? Are we doing things like defense in depth? Are we doing things like auditing and logging and then looking back on those things? There’s some basic stuff like terms of coding which, we again, we don’t do.

When it comes to security, what was better in a traditional architecture like service oriented architecture (SOA) versus a distributed microservices architecture?

Bryant: Not much has changed in the principle point of view. The only thing I would say [is that], with SOA, we had a lot more governance. SOA was driven by the vendors’ law … [they] were saying, ‘You must use my ESB [enterprise service bus] or my [particular] technology.” There were a lot of disadvantages to that, but one of the advantages was that someone owned it. So, you have this ESB, this thing [managing] all the connections within your services [and it’s] their ass on the line basically. So, they really invested in policy and governance and all these kind of things. And if something went wrong, you knew who to call.

Whereas, these days, we go towards more lightweight technologies, but you have to take more responsibility as a developer and as an architect. The governance and policy and stuff, as bad as it sometimes was, there was an upside to it. It’s even the same with politics: the more control you have, the obviously less freedom you have, but it’s a balance that’s somewhere in there.

How can DevOps teams best work with security teams to ensure services are secured?

Bryant: The whole DevOps philosophy is about joining everyone together. So, a lot of consultancies I worked on we really try and bring in infosec [information security] — in a classic organization, they’re often called infosec. Bring them into the project early, because they’re generally good people, but they’re not consulted until things are going live. So, you have to get them involved earlier. Their knowledge is super valuable, so getting them involved earlier is great.

The post The challenges of microservices security and how to handle them appeared first on Artificial Intelligence.

Over the decades, the monolithic, tiered approach to building software has given way to a more distributed, component-based architecture commonly referred to as “microservices,” although some components aren’t “micro” at all. Separating out an app’s services into isolated, interoperable containers has revolutionized the way developers are able to update, add to, or expand parts of an app.

Microservices aren’t the perfect fit for every scenario, but for many this approach makes it far easier to build out a complex application from loosely coupled, reusable pieces. Whether an app is being run on your server, or within Docker, or on a cloud-based platform like Amazon Web Services (AWS), creating a distributed environment allows developers to divide and conquer without a lot of dependencies.

That said, while microservices have freed us from many of the constraints of the monolith, these benefits come with increased complexity, vulnerabilities, and risks that need to be mitigated with a tailored security strategy.

Monolith vs. Microservice

If you’re modernizing your app by making the move to a microservice-based architecture or starting from scratch, here’s a look at some key things to consider when it comes to securing your app from attack.

In a world of rapid iteration and frequent deployments, the monolith approach can be much like a Jenga tower: tinkering with parts of the whole may cause the whole structure to topple. When credentials are compromised, it’s easier to take down the whole app. On the flipside, it can be easier to secure because authentication is global (only one auth request needs to be made per user request), and there’s likely only one type of data store to encrypt.

However, when updates, bug fixes, or failures are being made to isolated components in a microservice-based app, all of a sudden it gets much easier to patch parts and pieces without updating the entire structure. Consider this vs. a traditional, monolithic approach, which is tiered instead of compartmentalized, and securing a microservice-based architecture will look quite different.

Right off the bat, you’re able to create a more diverse, app-specific security strategy and it’s easy to apply access permissions on a component-by-component basis. To implement that strategy well requires strict API management, visibility into each component, and a clear roadmap of how everything works together—and that’s where things get tricky.

“Establishing and respecting clear component boundaries is an architectural imperative as system complexity grows. HTTP-based services and service contracts (see below) constitute clear, bright lines that support the separation of logical subsystems and help engineers maintain and evolve these boundaries consciously.”

Stratis Karamanlakis, Chief Technology Officer, Upwork, from Upwork Modernization: An Overview.

When it comes to securing an application from hacks, knowing how it’s built and how it works is paramount to knowing how to properly secure it, but getting a bird’s eye view of that many moving parts requires discipline, organization, and foresight.

The Microservice Security Challenge

No matter how an application is constructed, security concerns typically reside in one bottleneck: the network. For microservices, this gets exacerbated due to the various network connections and APIs used to forge communication channels between all those components. These create more inroads for attack and interception of in transit data.

With a monolith, there are typically one or more servers within a network, which makes it easier to focus on the exposed ports and APIs, identify an IP address, and configure a perimeter around it. With microservices, this gets much more complex with many exposed ports and API gateways—and authentication becomes a distributed matter, too. At the risk of oversimplifying, all this means that running a distributed system means you need to enforce a distributed security approach, and everyone has to be on board to make it a success.

The Microservices Culture Shift: Adopting a DevSecOps Philosophy

Like we mentioned above, microservices aren’t the best solution for every application, but for those that it offers clear benefits, much of getting over that hurdle from monolith to microservices is a shifting of mindset.

You’ve likely heard of DevOps; DevSecOps is the security-specific philosophy that ensures a component’s security doesn’t take a back seat to its logic.

Abby Fuller, a developer advocate with AWS, said the following in a talk with WeaveWorks, a container management company: “To switch from a monolithic network to one comprised of synergistically functioning microservices, a company will need to transform both its culture and its system’s architecture. This process will not simply be a matter of atomizing the monolithic system into microservices. Service partnerships will be required to effectively manage the added complexities of testing, deploying and operating multiple microservices.”

Leverage the Good; Minimize the Bad

With your app’s components and services isolated, there are some clear security benefits, not the least of which is a reduced attack surface area. The best way to think about this is to picture a bank vault. If all of the money was stored in a large vault, a thief only has to crack one safe door to access all of the money. If it’s stored in many smaller safes, the thief’s job suddenly gets much more difficult. Microservices shrink that attack surface area because you don’t have all of your eggs in one basket.

Other advantages:

• You can be more granular. If you think of security as coarse-grained or fine-grained, microservices security can be much more fine-grained, applying service-specific rules to containers, APIs, and firewalls.
• You can be more diverse. Without all of your eggs in one basket, you can apply different rules and layers to different components, mixing up your tactics.
• You can tailor access requirements. Implement a “model of least privilege” on a service-by-service basis to tailor what services can do, e.g. read-only vs. read/write.
• You can better distribute responsibility. Each team can distinctly define precisely how their component should be interacted with. This is an advantage on a larger scale because the people who are closest to the code know its nuances better than a firewall team further upstream.

What all of this means for a microservices-based app is that, right off the bat, it’s much easier to protect with a “defense in depth” strategy—something that’s more difficult to accomplish with a monolithic architecture. To really capitalize on these benefits, it’s important to adjust the way you think about security for your application—because it’s a big shift from the old way of securing things.

Note that a microservices environment can amplify some existing security issues of the monolith, like network communications. Because services are decentralized and separated, how they communicate with one another is no longer internal, it’s happening over a network. The network security bottleneck therefore gets tricky, and access control gets more complex.

Within a microservices architecture, there are bound to be lots of transactions and interactions. Thus, the security of the app hinges on those container interactions, and knowing what they are and when they happen.

Tips to Approaching Microservices Security

The keys to securing a microservices environment? Getting into a DevOps state of mind, securing REST API gateways and permissions, and creating plenty of visibility into each service and the way they communicate with one another. Let’s break these down into some actionable tips.

1. Establish visibility into the entire infrastructure by mapping out each microservice and inter-service communication.

Having a clear, detailed map of each service, its dependencies, what other services it communicates with, and when and why those interactions happen will not only give you insight into how to best secure them and authenticate their access, it will also be a baseline to compare any aberrations against.

2. Implement “defense in depth.”

Layer your network security defenses. System firewalls aren’t enough; you’ll want to go component-by-component, pinpointing the most sensitive functions and data and locking them down with a “defense in depth” approach.

This can include building fine-grained firewalls between services. Fine-grained firewalling of containers and services ]creates safe dividers between services, creating and applying sets of firewall rules to each container with host-to-host encryption. Automation becomes a near necessity as this gets incredibly time-consuming and complex with traditional configuration management tools.

3. Rethink team structures.

The very philosophy behind microservices—many parts contributing to a greater whole—should also apply to a team structure supporting the development and security of the app. Security shouldn’t be a separate, standalone role from development, especially when there are so many small, moving parts.

Assemble teams whose contributions improve your product, not just a specific project. You want teams to complement one another and be aware of interrelated issues, not be silo-ed. Security isn’t always in the forefront for developers who are more (and rightfully) focused on logic, but making this a part of the team mindset can keep it more top of mind. Sitting them beside a security expert, while a simplified analogy, is a great way to ensure it’s secure from the ground up. This is something Netflix has done with its Platform Security Team, with great results.

4. Diversify your security tactics.

Your approaches to security can be varied. Think of each component like a locked room in a house. By applying different locking mechanisms to each door, if a thief breaks into one, they haven’t figured out how to crack every other door. Avoiding uniformity in your microservices security is helpful.

5. APIs are like communication contracts. Enforce them.

So how do all those components join forces to become an app as a whole? They have to communicate over the network, and it’s those communications that present the most complexity (and vulnerability) for a microservices-based app. If your application’s services handle sensitive data that require compliance, you’ll want to be extra strict about how services communicate with one another.

API gateways are typically how microservices communicate with one another, so protecting those APIs are important. Create rules around these communications so they act like contracts. This means creating very well-built APIs that use features like throttling, authentication, or access tokens from a centralized authorization server.

Protecting the “pipes” should be a priority. AWS customers can use their proprietary API gateway service, which offers the ability to host multiple app versions, safely store API keys, throttle requests to the API, and more.

6. Find an encryption strategy that works for you.

Part of any good defense in depth strategy should include encryption measures like HTTPS transport security to protect data in transit and at rest. HTTPS encrypted connections with certificate-based security (like SSL) become especially critical when your data travels externally from the network, and key management should be, too. While it’s a great default, it’s not a solution for all problems. Depending on the overhead it creates for your app, you might also consider other strategies.

Encrypting databases with microservices has its advantages, as well. With a monolith, it’s tricky to encrypt on a by-table basis, but with data stores broken up between microservices, it’s easier to decide on a component-by-component basis what needs encrypting and to what degree.

7. Code securely from the ground up.

Of course, writing code from day one that’s designed to be secure is optimal, and microservices are no different from other software in this respect. However, with microservices there’s a decentralized responsibility and accountability for individual components, so each has to be able to stand on its own security-wise.

8. Align with the “Principle of Least Access.”

Limit permissions to the bare minimum needed. This is an excellent rule of thumb across all areas of security. Restricting access between microservices is beneficial in the same way restricting access to a human is—the less access, the better.

Like we mentioned before, authentication becomes distributed between components. You can use the Spring Security framework with OAuth 2.0 and OpenID Connect for scalable delegation, access controls, and user identity. For AWS customers, Amazon’s IAM allows for user roles and permissions. By only giving services the permissions they need to function, you’re making things more difficult for hackers.

9. Automation is your friend!

There’s a harsh truth that comes along with the convenience of microservices, and that’s how tending to each can be incredibly time-consuming. For deployment, a service like AWS’ Lambda can help with automation during the development process, but automation can also be helpful from a security standpoint, as well. For automated security assessments, AWS offers Amazon Inspector to run audits and assess vulnerabilities and compliance.

10. Make testing a regular part of the build, update, and maintenance program.

The beauty of microservices is how it supports Agile development and the rapid deployment of new services, but this means that things are always changing within an app, so the security approach needs to be just as nimble.

Upwork’s CTO, Stratis, also notes “Testing a large distributed system is hard, and continuous delivery makes this harder since the shared runtime environment is changing constantly. We are seeing promising results with contract testing, which is one of the various microservices testing strategies we’ve considered.”

Every time a component is updated, test it and scan it for vulnerabilities. If they’re already running in their own containers, this is a bit easier. Or, you could set up a monitoring platform to keep an eye on the system as a whole, picking up any abnormal communications between microservices that might indicate a problem. Either way, the map we mentioned earlier still plays an important role and needs to remain updated. With everything visualized, anomalies will be easier to spot.

Sidenote: Running on AWS?

AWS is packed with security features that you can pick and choose from to suit your needs, covering everything from key management with CloudHSM and SSL certificates to Identity Access Management (IAM), firewalls, and DDoS protection.

The post Tips for Securing a Modernized Service-Based Architecture appeared first on Artificial Intelligence.