How Secure are Composable Architectures?

According to Gartner, this year will see 60% of businesses making investments in composable architectures. What is more telling is their estimate that enterprises that move to a composable future will outpace 80% of their competitors.

Composable architecture is, in essence, a decoupling of single-source applications to a more agile vendor-agnostic approach to application development. So far, composable architectures have seen the most use in e-commerce as companies look to move away from their monoliths towards a headless, low-code, flexible and scalable development path.

The most high-profile advocate of composable architectures is the MACH (Microservices, APIs, Cloud Native, Headless) Alliance. Current research by MACH indicates that legacy is still holding companies back, with one in five companies spending over half their IT budget on upgrades; 87% of those who have increased MACH are more responsive and ahead of the competition.

“The data tells us that too many companies are stuck keeping the upgrade wheel turning. If you add the cost of time and business standstill, the absolute cost is much higher,” said Casper Rasmussen, MACH Alliance President. “At the same time, fewer companies see themselves as agile early adopters, and fewer also see themselves as being ahead of the competition compared to our research a year ago.

“The pace of transformation is relentless but the cost of not innovating is much higher. While transitioning to MACH is no small undertaking, continuing the status quo is an ongoing, big undertaking, especially for larger organisations, which needs addressing. We’re not going to wipe legacy out of the picture overnight. However, those moving toward MACH are better equipped to mitigate future obstacles.”

Security must be an integral component as businesses move towards their composable futures. With many digital elements that must work seamlessly together, what practical steps are being taken to ensure a composable future is secure for users of the services using composable techniques?

Composing security

Silicon UK spoke with several leading industry experts to gain insights into how security is managed in an environment of composable architectures.

Tom Ascroft, Chief Security Officer, Unit4 [TA]

Gabe Dimeglio, VP Global Security Services, Rimini Street [GD]

Conor Egan, Vice President of Product and Engineering ,Contentstack [CE]

Mark Mamone, CTO at digital identity specialists GBG [MM]

Mark Adams, SVP & GM of EMEA, BigCommerce [MA]

Dr Matt Bradbury, Lecturer in Cybersecurity at Lancaster University [MB]

Michael White, Technical Director and Principal Architect at the Synopsys Software Integrity Group [MW]

Allon Mureinik, Senior Software Engineering Manager, Synopsys Software Integrity Group [AM]

Tom Fairbairn, Distinguished Engineer, Solace [TF]

How does security factor into the composable architectures enterprises are building?

[TA] “Security is a critical factor in building composable architectures for cloud-based business software. Utilising the built-in security of the underlying cloud platform is important but not enough. Access control, data control, encryption, and privacy need to be addressed as horizontal concerns across all components. Regular assessments, vulnerability testing, threat modelling, and security training for developers are necessary. Implementing a security incident response plan and monitoring the system for security incidents are crucial. Finally, security policies and procedures should be reviewed and updated regularly to remain effective against evolving threats.”

[CE] “Whilst composable architecture means enterprises are dealing with more platforms, which can be perceived as a security risk, when employed correctly, headless solutions can reduce common risks to website stacks. The scalability of composable SaaS ensures that denial of service vulnerabilities is mitigated and makes anomalous use much easier to detect, helping to significantly reduce the risk of DDOS (distributed denial-of-service).”

[MW] “We’ve recently seen the term composable architecture emerge to connect many facets of enterprise architecture practices. The expression also matches the technology move toward microservices and API-driven design principles.

“When deployed, the notion of security of these complex system-of-systems should be considered from many angles. At the individual modular level, each component should of course follow all the usual security best practices during development. This means including security features, protecting against software supply chain risk, and performing appropriate security testing activities to eliminate flaws. But we also need to consider business logic vulnerabilities which exist only when the entire system is composed to support a specific customer journey. This is much trickier, but such vulnerabilities do often occur when there are inconsistencies in interfaces or integrations between multiple underlying services.”

Components are created that can be connected to form new applications and services. Is this approach inherently more secure than traditional approaches to application development?

[TF] “In and of itself, no! By having more communication between more components, you could actually argue the opposite. In practice, however, a common side effect is that data sources and application components are moved from the frontend server layer, which provides a level of security isolation. For instance, Server-side Request Forgery (SSRF) attacks on back end infrastructural layers such as the database are not eliminated but their scope and blast radius considerably reduced. The standard interface styles make them more attractive to bad actors, and the attack surface area is higher. Another complication is that composable components can and probably will be connected in ways the creators and maintainers of the component didn’t or couldn’t anticipate. Security concerns must be a top priority concern when implementing composable components and architectures.”

[MM] “In summary, yes! But there’s no room for complacency. The “attack surface” in a composable architecture (what a bad actor would try to attack) consists of smaller units, when it’s not a monolithic architecture. Trying to compromise a composable architecture application, therefore, is a bit like playing whack-a-mole for the bad guys. Then there is the “blast radius” to consider, which means if they do compromise it, they will be doing so (hopefully) with just one component and the impact is, therefore, much more likely to be smaller.”

[MA] “The composable approach to application development can be inherently more secure than traditional approaches, but it depends on how the composable architecture is designed and implemented. By breaking down the application into smaller components, it is easier to apply security measures to each component and the integration points between them.

“This makes it possible to implement security measures that are tailored to the specific needs of each component, which can enhance the overall security of the system. However, the composable approach also has some unique security challenges. For example, integrating multiple components or services may introduce new security vulnerabilities, especially if the integration points are not properly secured. In addition, the use of third-party components or services introduces the risk of supply chain attacks or other attacks that exploit vulnerabilities in these components.”

[MB] “Small components are a good idea; small attack surfaces are easier to test for vulnerabilities and faults can be checked and corrected quickly. Adding interactions between components via composing different components in a system can lead to new vulnerabilities as large numbers of small components can lead to new and complex sequences of interactions, depending on how applications are structured. This tends not to be the case with a single, monolithic application as there may not be multiple components of a distributed system interacting. Both composable and monolithic applications will be vulnerable to a common set of vulnerabilities (e.g., buffer overflow etc), but composable architectures can also be vulnerable to attacks on the interactions between components.”

In traditional application design, open-source code snippets are often used with potentially weak security. Is the composable approach also about educating development teams about the importance of paying close attention to security with their code?

[GD] “I think that this is an opportunity to educate more than just dev teams about the insecure open-source frameworks and objects. It’s a great opportunity to educate IT operations, including DBAs, SysAdmins, and even security practitioners who generally don’t have a lot of experience with this particular challenge. A Composable strategy or “Innovation Around the Edges” is a great opportunity to really assess and understand the use of these at risk components in a broader group setting, and to ensure that there is broad accountability in managing, even limiting or greatly reducing that risk.”

[CE] “Much of what you might have used open source code for in the past can be provided by a headless service today. The critical difference is that instead of the open source software being embedded into the code, you now have an actively-updated system monitored by dozens of engineers editing and improving as business needs develop. That way, you can respond quickly to security risks and mitigate vulnerabilities.

“With this approach, the risk of introducing a vulnerability by using open source software with a composable system, like Contentstack, is almost nonexistent. Customisations written on top of a composable system are using the same APIs and SDKs which would be written into their public-facing websites. This means that the highly-secure gateway is still in place, with the added bonus of benefiting from regular system updates.”

[MM] “Composable architecture does not mean there is no longer a requirement to write good code. However, all the sensible practices associated with writing good code should still stand, which must be communicated to development teams.
Developers still need to think about failure in their code, and all code must be robustly tested, both from a functional and non-functional perspective. I would warn against using open-source snippets verbatim, not only with composable architectures, because it can be hard to tell if it really is truly open source, and there could be IP issues associated with doing so. Then there are security concerns such as hidden exploits.”

[TF] “There is a danger that the positive security side effects of composable architectures lulls developers into a false sense of security. For instance, Cross Site Scripting vulnerabilities are not addressed by composable architectures. While reducing the attack surface area and blast radius of some attacks, poor code will always expose vulnerabilities. Your web site/app is only as secure as your code. The OWASP Top 10 2021 promoted “Vulnerable and Outdated Components” from position 9 in 2020 to 6 in 2021. Composable Architectures create additional security requirements due to their higher attack surface area and yield. Security must therefore be a top priority. Code should be thoroughly reviewed both for functionality and security, rigorous security audits implemented and developers educated on security practices.”

As businesses look towards their post-pandemic futures, are they looking to rationalise their tech stacks to remove complexity and, by extension, improve digital security by embracing composable architectures and development practices?

[MW] “Complexity is exactly the problem. In recent years as we have seen a rapid surge in digital transformation, and as enterprises have raced to add new interfaces and extensions to sometimes legacy systems, this has created a parallel world in terms of support – whereby both the old as well as the new must be supported. It is inevitable that the transition needs to be completed and in turn this means migrating away from some of the legacy systems as the new instances become more stable. This does of course help reduce the potential attack surface, but organizations’ should be cautious that they are not inadvertently creating new attack surfaces during the transition itself!”

[GD] “Organisations are absolutely focusing on application rationalisation, including all components of the stack that enable applications such as infrastructure. As a critical component of this, organisations concentrate on removing software that serves no business purpose. For example, it was considered acceptable that as long as software was installed by default, even if not utilised by the business system, it could just sit there, waiting in the shadows. But over the last several years, default services have been exploited in successful attacks. Many impacted organisations need to be made aware that they are running these services (thus not correctly protecting them) because they don’t control it as part of the service delivery.

“Much of the industry evolved to disabling these services as a risk mitigation technique, but even that has proven to not be sufficient as attack techniques and methodologies evolve to enable and exploit them as a part of the attack chain. Now the focus is to find the corresponding binaries of those unused services, mapping any potential functional dependencies, and to outright remove the binaries of any functionality that is simply not required to perform respective business functions. Removal of “dead code” as we think of it.”

[CE] “The pandemic was a wake-up call for companies and their need for agility. Suddenly a lot of activities that were working for them, including in-person events and 1-1 customer interaction, were completely off the table. Monolithic systems are very prescriptive and time consuming to change. In turn, businesses benefiting from composable architectures were able to adapt to changing business needs and had better chances of succeeding. Removing complexity not only makes it easier to maintain your security posture, but it offers an agile solution to adapt to change and quickly integrate updates developed for disruption.”

Are you seeing businesses making a wholesale move away from their monoliths? Or is the reality that enterprises need to make slow, highly focused changes, especially when considering their digital threat landscape?

[CE] “Some companies have done their homework and are ready to “rip off the Bandaid” and go straight to completely composable. Others start with a given use case or business unit to learn as they go. I think there is certainly more resistance in highly regulated industries to adopt new technologies. That being said, we work with healthcare, finance, and other very sensitive industries on the regular. As such, we ensure the required certifications (SOC II, ISO 27001, etc) and best practices are in place when releasing code changes which mitigates security concerns.”

[GD] “Given the opportunity, most organisations will be highly strategic in the transformation of their ERP systems and services. Changes will generally be slow and methodical providing adequate time for business process validation and acceptance per module or component. This also affords the security leadership time to properly plan, execute and measure the effectiveness of their controls for that given change. Many large ERP providers prefer and frequently pressure organisations into massive, accelerated and painfully complex upgrades or migrations of the full stack to their latest offerings. But this is something that rarely has the client’s best interests at heart and often proves to be extremely painful or in many examples fails completely.”

[TA] “While some businesses are making a wholesale move away from monoliths, the reality for many enterprises is that they need to make slow, highly focused changes, especially when considering their digital threat landscape. A gradual transition to composable architectures allows organisations to better manage risks and maintain existing systems during the process. Many companies have a significant sunk costs in their older systems and do not have the funding to make big changes.”

What critical components of a composable architecture must be robustly secured from potential attacks?

[TF] “Composable Architectures typically separate the content management and build and deploy processes from the server infrastructure, making certain classes of compromise, such as configuration error, less intrusive. Exiting attack vectors, such as broken access controls and cryptographic failures are still present. The third party edge network often used in composable architectures may provide vulnerabilities and you should evaluate your vendor’s security record. A composable architecture component has 3 main interfaces: UI; synchronous and event based. These interfaces are the attack surfaces and need to secured. The platforms or frameworks that provide these interfaces (e.g. Event Mesh or Service Mesh) are the components that will enable or hinder the required security.”

[MA] “The old saying “a chain is only as strong as its weakest link” comes to mind here. While there are some components that are extremely important, such as a payment gateway, it’s critical that every piece of the tech stack be secure to avoid providing an entry point to other areas.”

How do you see composable architecture security evolving?

[TA] “As composable architecture security evolves, we can expect to see improvements in component isolation, automation of security testing and monitoring, and the development of new tools and frameworks to facilitate secure design and implementation of composable systems. Additionally, the growing focus on zero-trust principles and the adoption of AI and machine learning for security analysis and threat detection will likely play a significant role in shaping the future of composable architecture security.”

[GD] “For starters, I see security vendors evolving their offerings and new startups developing technology that better serves this more interconnected multi-service provider future. But we can only assume the disparate controls utilised by organisations can be as effective from a coverage perspective as they should be with a way to simplify the inherent complexity that comes from security control applicability mapping across the services. As a result, I believe we’ll see a large push to a single pain of glass orchestration and risk remediation approach where the security vendors will take responsibility for providing the first level of understanding of the services and integrations, identifying the risk, and then reporting on and mitigating that risk.

“We’re already seeing some great solutions out there, they just need maturity. Organisations such as global financial institutions and intelligence services, that leverage both the disparate composable services and the security orchestration tools will heavily partner with all of the corresponding providers. Smaller organisations that don’t have the resources or internal skill sets will utilise managed service providers including managed security services and remain focused on business and risk management outcomes from their partnerships.”

[MM] “There’ll be more significant levels of convergence between cyber security and composable architectures. We’re already talking about cyber security mesh, and moving forwards; we’ll see cyber security controls working harmoniously with engineering practices to create the mesh on which platforms exist which will have security embedded within it. As part of this, we’ll obviously see secure and trusted APIs through Identity and Access Management (IAM) security – a kind of Identity Fabric.

“Security tokens, including keys, secrets and certificates, will be more prominent. We’ll also see more centralisation and control of policies to enable more consistent management. However, those components still need to be trusted and secure, so posture management becomes more of a concern in the cloud.
Finally, we’ll see lots more monitoring and analytics of the system and how it operates, not only from a performance perspective but also to help us assure its integrity and security.”

There is little doubt that all businesses not just those in the e-commerce space, will eventually embrace composable architectures as they offer the flexibility and agility all enterprises need to service their customers and continue to innovate.