EP6 – What You Need to Know About Composable Security

An Introduction to Beyond the Edge Episode 6 – What You Need to Know About Composable Architectures and Its Benefits for Performance and Security

Tom Mount: Hello and welcome to Beyond the Edge, where we dig into the insurance and outs of trends affecting modern digital businesses.

I’m Tom Mount. I’m a Senior Solutions Architect at Edgio. I focus on our applications platform and our security solutions that make up part of that platform. I’ve been a web developer for nearly 20 years, working mostly for or with digital marketing agencies. Done a lot of work with Higher Ed and e-commerce, including eBay, American Airlines and the University of Pennsylvania.

And today I’m joined by Howie Ross.

Howie Ross: Hello, I’m Howie Ross. I’m the Senior Director of Product Management for the Edgio Applications platform, where I focus on web acceleration, including our CDN and edge computing. I’ve been doing web development and cloud architecture for 20 years and during that time I’ve had the pleasure of working across many industries, including Fintech and EComm, where I’ve worked with numerous brands including Urban Outfitters, Coach, Verizon, and M&Ms.

Tom Mount: Great. Thanks Howie. So today we want to talk with you a little bit about security challenges that are facing composable architecture. Specifically now we know that there’s a lot of security threats out there for website owners and content managers.

According to IBM, there’s a study out there that’s they say that 83% of U.S. companies have experienced a data breach and that can cost upwards of like $9.4 million in the US. That’s more than double the global average. Okta, they’re one of the largest single sign-on identity business providers in the world. They published a report that 34% of all login attempts globally were by bots. So this is just bots literally just trying to get into network accounts just showed that one in four organizations have lost $500,000 from a single bot attack. So security is a huge threat. It’s a huge issue that we have to deal with.

And as we talk about composable architectures, that’s something that really starts to get a little bit more challenging to address. And so on, this podcast today, we want to take a look at some of the threats that are out there for composable architectures and what we can do about that.

So before we get too deeply into this, Howie, I wonder if you can maybe define for us what is composable architecture, what does that mean to you?

What is Composable Architecture?

Howie Ross: Sure, I can try. It’s kind of one of those things that is a little hard to define, but you know it when you see it. Composable architecture is really a reaction to the monolithic all-in-one platforms that were used, you know for the let’s say the previous decade and the limitations imposed on the user experience and the developer workflow.

So with composable architecture solutions are composed from tools and vendors across the stack that allow you to select the best-in-class tools to meet your organization’s and your user’s needs.

And composable is often associated with headless or decoupled front ends where we are separating the presentation layer from the data layer and often relying on microservices or at least API-driven architectures to facilitate this headless decoupled architecture and composing a complete solution out of various tools.

Tom Mount: So it sounds pretty flexible, but it also sounds like it may be a little bit more technically challenging to implement some of these stacks.

Why Choose Composable?

What would make a company choose to go with a composable architecture as opposed to this more monolithic, you know, well-established pattern?

Howie Ross: Yeah, it’s a great question. Well, there are numerous benefits to composable architectures including as I mentioned, improved user experience due to fewer UX limitations, right? So on a monolithic stack, you’re going to be limited often to, you know, what capabilities are provided by that stack. However, with composable architecture, it’s kind of like, you know, the sky’s the limit.

The team and the designers can dream up whatever experience they would like and then you know you’re going to have more agility in terms of being able to roll out those features to your end users.

So in fact, we’ve seen, we’ve seen organizations such as Iceland Air have a 90% reduction in the delivery time to roll out new features including promotions. So you’re going to have decreased time to market and time to value for the work.

In addition, as I mentioned, you get to select the best-in-class tools and vendors and really kind of build this network of ecosystem partners that you can rely on to build your solution and deliver that value.

And then and then also it’s a bit more future-proofed than a monolithic stack because you can swap these tools in and out as you see fit. So, say your customer review tool is no longer meeting your needs. You want to use a different one. You don’t have to go and replace your entire solution. You can just replace that specific tool and continue to iterate on your stack and keep it really modern.

Tom Mount: See now you’re talking about language a little bit there. My, a lot of my background is in building more applications on the web and you know, looking at the architecture of some of this, I love the idea, the idea of having to like a future-proofed stack where you can just move things in and out.

And I think too that future-proofing feels like it extends not just at the component level but also kind of the infrastructure level, right? I mean we’re seeing now a lot more focus on things done at the edge, things done serverless things in the cloud than we were, you know, 5 even years ago, 10 years ago.

Certainly, there’s a lot more emphasis on that and I think having a more flexible architecture where you can move components out of you know a larger data center and into more of an obviously it’s the cloud, everything’s in a data center, right? We understand that part.

But having something where you can focus more on the edge and build things specifically for edge processing for serverless functions and keep those things fast and nimble is I think a huge, a huge benefit as well. And I think too like security is, is also something that benefits from this, right? Because a lot of as we’ve migrated more and more services and more things onto the cloud and have these you know edge-enabled solutions, security comes along with that.

So we can do a lot of zero-trust security right at the edge now as opposed to having to come all the way back into a data center and having a composable architecture allows us to I think build zero-trust security right into the fabric of the application itself. And I and look like I said at the top, I’ve been building websites for 20 years. I’ve worked with toolchains all over the place. I think one of the nice things that we’ve seen especially with some composable frameworks out there is that a lot of these frameworks now have built-in capabilities for static site generation.

And those things can be just streamed right into that build pipeline and pushed right out as part of this you can just swap out whatever components or architectures you want. Your pipeline will build it all and it all ends up being you know, distilled into that, you know static files the HTML, the CSS, the JavaScript, the images that we need regardless of how they were built and what puzzle pieces fit together, the pipelines can still ultimately stay the same. The deploys can still reflect that. So I think that’s a that strikes me from the architecture perspective as another couple of benefits that you get from being able to kind of move these components in and out.

Client Success Stories – Universal Standard

Howie Ross: Yeah, those are great points you know so in addition to the benefits for the development team and for the customer, there are significant benefits for you know the DevOps team and the options that it offers you for your infrastructure architecture.

Whether it’s through leveraging static generation and you know really building your site for the CDN and for the edge or leveraging serverless and really taking advantage of those advancements in in cloud technology for your scalability and your security. And you know so you know Tom and I’ve had the pleasure to work with a number of customers who have gone on this journey to composable and have seen significant benefits.

So you know the customers include you know some of the ones I mentioned earlier such as Coach and M&Ms that are either you know have completed or are well along the way on their composable journeys.

One of the other little bit lesser-known customers is called Universal Standard that’s on their mission is to be the most inclusive clothing brand in the world. And you know for that mission they chose to go with a composable architecture built on top of the Shopify platform.

So you know rather than them being a bit constrained by the limitations imposed by Shopify in terms of the user experience and the developer workflow, they’re leveraging the Shopify Storefront APIs and building a composable solution using the Nuxt framework which is built on Vue JS.
And they saw you know significant performance improvement, you know, bringing the page load times down from you know multiple seconds to in many cases sub 2nd and improving you know, not just these technical performance metrics but actual business metrics.

In fact, they saw a 200% improvement on conversion rate as a result of this move to composable. That is of course really affecting, their bottom line and helping them on their mission.

Client Success Stories – Shoe Carnival

Tom Mount: Yeah, that’s really great. I mean we talked about you know sub second page loads here and it’s people always. I always when I’m talking with people I get the side eye like Are you sure about that And no, it’s true. You know one of the customers that I sometimes show off that has a similar story, it’s a company called Shoe Carnival, so they moved to headless as well. They had their previous architecture. They were looking specifically at performance concerns around things like first-page load and transitions between pages.

So their stats before they went headless, they were looking at, you know, 3, three, 3 1/2 seconds for a first-page load and sometimes up to 6 seconds when transitioning from one page to the next when you’re browsing. And they really wanted to get that down. And there’s a whole lot of reasons why it’s a great idea to move that down.

We do have a lot of market research that shows that for every additional second the customers are waiting as the page is loading, it increases their chance of just leaving the site and going somewhere else. So obviously page speed and conversion rate is pretty closely tied and they recognize this.

And so they came to Edgio looking for some help and at once they finished their move over to headless and they had done some of these performance improvements that we’ve been talking about. They took their transitions and even their first page loads to one second, sometimes even less than one second. They are up to 70% faster on Edgio. Their median load time for pages is one second, right? So they’re seeing huge performance gains as a consequence of choosing this headless architecture and being able to optimize their performance at every level of the stack. And even their page loads, their subsequent page loads from, you know, once they actually land on the site, they’re down 92% on that speed. They’re down to 500 milliseconds on some of those page loads. So huge performance gains they were able to realize coming over.

But it isn’t just performance that is an attractive feature of Composable. Sticking with the Shoe Carnival. In addition to the performance gains, they also took the opportunity of going into composable to ramp up some of their security efforts. And, what they found was within the first 30 days of launching their new composable site, they had tracked over 8 million malicious requests that were blocked. And I want to focus, I’m going to make sure that I reiterate that those requests were blocked.

It was not that they, you know, had 8 million requests they didn’t know what to do with, right? The security solution that they found that we provided was able to block all of those requests and provide visibility into what maybe they hadn’t been seeing before the volume of malicious requests that they’re receiving.

Security Benefits of Composable

So this kind of transitions me into a little bit talking about some of the security benefits because you know, we spent a lot of time so far talking about performance gains and they’re very real. And you know, we, we track our customers when they come over, we, we like to see the performance gains that they have and we have some amazing success stories.

But I think security gains is another good reason for choosing a composable architecture. I like to look at it as kind of a layered, tiered defense, right? So we want to keep the bad actors as far away as possible from your origin, from where your actual servers and your data is located. And you can think of it in terms of, you know, putting up a fence around your property. You can have signs on your fence, let’s say, keep out, you know, no trespassing whatever. But that doesn’t necessarily mean that you don’t lock your door at night. It just means that you want to put a guardrail up as far away as possible to keep out as much as you possibly can.

And when you choose a composable architecture, one of the advantages is that you then get to pick and choose the security features that you have in place and where those security features are located.

And we recommend that you have security at every level that you can put it right. So we’ll put that security out at the edge, We’ll put that security into the origin. If there are other APIs or services, you know, we mentioned that going composable generally means that you’re increasing, you know, the number of APIs that are exposed on your site. So we want to make sure that those APIs have security and with a composable architecture, it actually becomes really simple to do that. You do have to account for all of those places, but you can put out security at all of those different levels.

One of the other nice things about having a composable architecture, and I touched on this a little bit before, is the ability to have those static pages. Now, static pages are great for performance, but they also have a really nice benefit for security because static pages will minimize the amount of two-way data transfer that happens between the client and the server.

If you think of a traditional kind of monolithic app, PHP app, or something like that, somebody is entering data onto this application and it has to go into the back into the server. If you’re loading up a new page, the server has to go request this data and send it back. There are a lot of opportunities for data to come both in and out of your systems. And well, obviously it has some data has to come out.

You want to make sure that not all the data that is in your systems comes out. That’s what we call a data breach.

So having static pages cuts down on the opportunities for somebody to tinker with your server by means of the page that is displayed in the web browser because all that’s on the page is just HTML, right?

There’s no, it already has the data. It’s not fetching that data from anywhere. It was built with that data in mind already. So having static pages you know, while certainly a performance gain can also be a security gain and those static pages then can be served directly from a CDN.

And so I think that’s the kind of the last piece of the puzzle here in that particular part of the security is that instead of having to go back to your servers to fetch this data every single time the page is loaded with the CDN, that page is cached, it’s available worldwide and your servers don’t even see those requests because they’re all handled right at the outside edge.

Howie Ross: Yeah, that’s a great point. And I agree that you know one of the I would say primary benefits of a composable solution whether you’re doing you know static site generation or you’re leveraging you know serverless server-side rendering is that ability to leverage the CDN in a more effective way. That’s going to provide you with improved page load times but also Security benefits as well of you know keeping the bad actors as far away as possible.

You know from your data and your crown jewels and also you know minimizing that two-way data transfer as well but you know to while there are some Security benefits I think there are also some challenges as well.

So you know, we talked about how composable solutions, you know you’re selecting the best of breed of vendors and tools and so that means there are, you know, there’s more tools, there’s more vendors which means potentially you know more ways into your, your systems and your architectures. So you know, so that’s a risk.

And one of the increasingly common ways of compromising organizations is through you know impersonation, right, rather than you know brute forcing my way into your website or your servers. I’m just going to figure out how to social engineer my way into looking like one of your employees. And now as opposed to having to kind of breach your, you know, your core network and you know your enterprise tools. I may be able to just breach one of the many tools and vendors you’re using on your composable solution so you know identity and access management becomes increasingly important.

So it’s and you know this can be you know mitigated in in a number of ways through you know having standards and single sign-on and things like that. But it is something you want to be, you know thoughtful about because you know of the rise of data skimming and you know this is a class of vulnerabilities or exploits.

It’s often referred to as mage cart which was one of the original exploitations of this type of attack where you know a script is put onto a website by these attackers that is then going to, you know, skim personal information.

In this case, it was credit card information from primarily Magento sites and it was widespread and you know, it really kind of brought to the forefront the, you know, the criticality and the severity of this issue and the importance of having, you know, managing the integrity of your code through the whole supply chain.

And also you know, I mentioned the importance of really being careful about your identity and access management, yeah, that makes a lot of sense.

Tom Mount: You know, obviously with more tools there are more opportunities to come in. I think from an application architecture perspective, a lot of composable sites make use heavy use of API calls back to the server to populate new pages to facilitate quicker browsing. And I think API security is another area where you have to pay more attention to what you’re doing and to what’s going on.

So obviously, you know, I don’t want my page when I’m shopping on a site. I don’t want my page cached for you and you probably don’t want your cart cached for me because that just is confusing and I don’t understand why. You know why I have what I have in my cart when I pull it up.

So obviously we need to make sure that we have fast responsive pages, but we also want to make sure that they’re personalized for the individual user and usually, that’s done through some sort of API access, and a lot of times the visitor’s info ends up in that API data that’s being transmitted.

And so that is where kind of the zero-trust portion of the security comes in around API specifically, right? So we can do things like edge personalization where we’re grabbing content, cached content from the server, and at the edge rather than in the browser, we’re pulling this data from the server and incorporating that into the final response that we’re sending out. That’s a great way of having really fast, really responsive pages that are still cached but also have personal data on them.

Another way that we can kind of do a little bit of security magic at the edge is to use something like, you know, JSON Web Tokens for authentication. This is AI won’t go into the whole details of what they are because it’s one of my current favorite projects to play around with. And I could talk about it for probably another 20 minutes just on my own. But podcast, yeah, we’ll do, we’ll do a podcast on JTBTS later.

But yeah, the cool part about it is it’s data that’s transmitted kind of in clear text but it’s also got an encrypted signature to it that the server knows how to generate it’s own version of that encrypted signature.

And so you can check the validity of the user coming in to make sure that you know nothing’s been tampered with, that the credentials are correct, and that you know the user has access to everything that they say they should have access to.

You can validate that that access is still valid and correct. And you can do that also at the edge using, you know, surplus function or cloud function, things like that. So wrapping that up around the APIs is going to be really critical to address, you know, whether you use that zero-trust authentication or some other mechanism.

API security is a must, yeah, because sorry, I’m sorry, go ahead.

Howie Ross: So this is one of the major trade-offs of composable architectures, right? So you know we are you know we’re not building our application to take advantage of the CDN and Edge compute, but to retain those you know those dynamic experiences that that personalization we have to leverage APIs. So you know we have kind of a potential proliferation of services and APIs that can actually increase the threat surface area.

So it’s critical now to leverage an API security solution and these are going to be a bit different than you know some of your, you know the more conventional security solutions that we’re going to, you know we’re going to touch on momentarily because they need to be tailored for that API use case, right. And so we need to first of all we need to make sure that we know about all the APIs right?

So you’re going to want to leverage a tool that does API discovery and helps you find and manage all of your APIs and make sure that we don’t have any of what we like to call zombie APIs which are APIs that you know were developed at one point and maybe they’re no longer you know you’ve iterated and they’re maybe they’re no longer in use but they’re still out there.

So we need to have a complete inventory of our APIs and our threat surface area. And then in addition we want to have you know some basic security practices in place such as rate limiting, right?

We want to control the rate that someone can request data from these APIs and more specifically that a bot or an attacker using automation can request responses from these APIs so that they don’t become overwhelmed and effectively create a, you know, a denial-of-service situation.

And the other thing that we can do with API security that’s really interesting and is becoming increasingly accessible as we, you know, adopt and leverage AI is what we call schema validation. So that’s where we’re going to, you know, before our request, it’s your API right at the edge, we’re going to make sure that this request conforms to the schema of your API requests, right?

So if it doesn’t look like a properly formed API request, we’re going to block it at the gate, We’re going to stop it right at the edge of the network and it’s never even going to come into your, you know, your infrastructure to be, you know, hopefully rejected there. But yeah, it’s going to be critical to leverage to API security and it’s becoming, you know, increasingly common and accessible and useful.

Tom Mount: Yeah, definitely. And you know we talk about some of this composable specific security concerns that we have and ways that we can mitigate some of these things. But I think it’s important too that we also don’t forget the old standby security stuff, right? The stuff that served us pretty well for a while.

I mentioned earlier that you know security is a lot like you know having a bunch of different layers just because you just because you lock your gate at night doesn’t mean you leave your door wide open, right?

So let’s talk for a little bit about some of the general security practices that maybe still are perfectly fine and should be part of the overall architecture even if it’s not specifically geared towards composable architecture.

Best Practices to Enhance Your Security Posture

Howie Ross: Sure. So you know this layered security approach that you mentioned. We also often call that defense-in-depth, right? So you know between the attacker and the crown jewels which is often going to be you know your company’s and your user’s data. We want to have multiple layers of security so that in the event that one is breached that we still have these additional layers. So there are a number of mitigations and systems we want to have in place.

And the first you know the old standby that you mentioned Tom that’s going to be our web application firewall and we’re going to want to make sure that we have a robust WAF with a really great set of managed roles to block the expectation of all of the known vulnerabilities.

And we’re going to want to make sure that you know we’re working with a partner that releases patches for new and emerging what we call zero-day exploits rapidly right?

So then rather than having to go around and individually patch every one of your APIs we can deploy a patch on our WAF at the edge and mitigate that vulnerability across all of our services.

And then in addition, you know, we talked I think earlier about the impact of bots, the rise of bot attacks, the number of bot requests that are happening on our systems. Now not all bots are bad, right? Bots crawl our sites and make that data available to search engines. So it’s critical that we let certain bots in to do their work and that we block bots, malicious bots that are trying to do things like potential denial of inventory, right? They’re trying to buy all the sneakers or all the tickets before other users can get them.

The bots are also doing things like account takeover. They’re just trying different combinations of usernames and passwords or they’re trying usernames and passwords that were breached from another site. They’re trying it on your site potentially because they know that many people reuse passwords. So it’s going to be critical that we have our bot management solution in place.

Tom Mount: Yeah, definitely and I think you know one of the other we’ve all heard about you know bot management things we ticket sales like you know we’ve had issues with ticket vendors whose tickets go on sale and immediately get snapped up by bots, right?

New sneakers drop from the manufacturer and all of a sudden those sneakers are just gone. And I tell people sometimes about 50% joking that, you know, in 10 years the Internet is basically just going to be bots attacking other bots, right? That’s going to be it, right? Bots are going to be buying shoes from other bots. They’re going to be attacking other websites.

And I will say too, you know, as far as bot attacks go, I remember when I first started out in the industry, DDoS attacks were rare, right? Denial of service attacks were rare because it took a lot of money and a lot of effort to spend on one of those. Not the case anymore, right? Like we’ve seen bot attacks. This is, I guess this is the reality of the situation today is you don’t have to be huge to be a target of a denial-of-service attack and the attackers don’t have to be rich to run those attacks. The tool sets, the toolchains, and the cloud computing resources to spin these things up.

I mean, we’ve even seen denial-of-service attacks that include what we call them bot nets, right They’re just computers somewhere that got roped into running this attack, including probably the one that’s on your smart refrigerator or your washing machine, right?

Like it’s a consequence of more and more things being connected to the Internet and more computing available in smaller packages being more distributed globally. We’ve seen a huge rise in denial-of-service attacks.

And I think you know as we think about not just security but just best practices for, for building a website in general, right, it’s 2024 as of this recording at least you need a CDN, right, because the CDN is really going to be the best way to really absorb these levels of attacks and these especially these distributed attacks.

Is that going to stop every single one? None. But you know, I’ve had now in the last five years, I’ve had two or three companies specifically that did not know they came under attack because their CDN was just that good at absorbing the attack.

It was only after the attack happened that they were they went back in their logs. And I’m not talking like a long time after, you know, a couple hours or a day or two later they go back in their logs like wow, we just had millions and millions and millions of requests over the last.

I wonder what happened here. Sometimes, you know, if they’ve got alerting turned on, they can see the increase in traffic and they never really see it on their website. And so really a CDN is a deceptively simple way of handling these denial-of-service attacks.

And so you know even with all of the new security opportunities out there, like some of the API security stuff is really fascinating to me. I love talking about that stuff.

Some of that zero-trust security is there are things happening in that field that are just, you know, mind-blowing at how quickly we’re advancing in there.

But you know the old you still need to CDN, still need a WAF, right? I mean those are good tools to have, and they will continue to be good tools to have regardless of what kind of architecture you decide to choose as you move forward.

And Howie, I think one of the things you mentioned just kind of in passing I want to call out too because you mentioned having a good partner that understands these things.

I think there used to be a feeling in web application building especially among larger enterprises that we always had to go it alone, right? We need our own in-house experts, we need our own in-house people to do this. And it resulted in a lot of in-house people pulling a lot of long hours and really becoming very frustrating and kind of burnt out.

And so as you’re choosing a composable architecture, bear in mind that it’s not just the actual architecture that you can choose best in breed. You can also find best-in-breed partners that will help you navigate this space.

You know find somebody who’s done this before who’s got a good sense of the threats that are out there of the way things are building and work with that partner and build a relationship with them to help get your site and your architecture secured fast performance and get that pushed out.

I know we’ve talked a lot about the benefits of user experience to workflow. You know are there any other takeaways that you feel that would be good to just highlight as we wrap up here?

Final Key Takeaways

Howie Ross: Yeah, I mean I think you’ve hit the highlights of how you know composable has you know numerous benefits including to the user experience and to the workflow that can have tangible impacts you know whether they’re cost reduction or revenue increase. But it also introduces some you know some new concerns that we that we covered.

So, you know you’re still going to need the, the, the security solutions that you know we were leveraging and we’re going to want to make sure that we have some you know, new security tooling and we’re really paying attention to our identity and access management as well.

And then you know, just reiterate you know this, it provides an opportunity to, you know, not just select vendors but to select partners that have not only done this before but are currently doing this you know, with other companies so that you know you can benefit from their wealth of experience across various clients and industries.

Tom Mount: Yeah. Well, thank you Howie for taking the time to chat with me a little bit about this. It’s been, it’s been fun. I hope that for our listeners and our viewers out there, I hope this has provided you with some good information to think on and some things to consider.

And you know Edgio stands ready to help as a trusted partner for you and we would love to share with you some of our experiences and some of our successes.

Thank you all for joining us on Beyond the Edge and we will see you next time.

For faster performance, smarter security, and happier teams, talk to one of Edgio’s experts today.