Home

SaaS

SaaS
What is driving Web3 adoption?

Top Answer: Google announced that they’re creating a large Web3 effort, so it’s clear that Web3 creates opportunities to solve troubling issues with security and data management at the edge, as well as enabling metaverse deployment globally. By 2029, enterprises will have tremendous flexibility in what they deploy, where they deploy and what use case they can successfully deploy for. There will be a marketplace of solutions that can be aggregated into your own high-value and agile solution, ready to quickly exploit new opportunities, whether through edge or otherwise.

59 views
8 comments
1 upvotes
Related Tags
How can edge computing be simplified?

Top Answer: Everything we do today is complex; if it weren’t, there wouldn’t be security breaches or wasted resources in the public cloud. The difference is that we are now accelerating towards tools and services that alleviate much of the underlying complexity, while allowing you to better utilize the best of breed — or better yet, the best of what’s already available to you.

40 views
4 comments
1 upvotes
Related Tags
Which technologies or services will enable further edge growth?

Top Answer: Most of us give the large cloud providers a magical aura, as if what they’ve built isn’t repeatable. It’s true that their scale is almost insurmountable, but their tech isn’t magic. Infrastructure as code (IaC), among other things, is helping to make it so that almost any organization can support heterogeneity in distributed infrastructure. This area of opportunity is improving year over year, and by 2029 you won’t remember why everyone thought infrastructure was so hard.  We’ll see dozens of services go mainstream in the coming years, whether they’re distributed database services or AI services. By 2029, you’ll be able to license or SaaS any service both inside and outside the framework of public cloud, including application distribution services and Web3 managed data privacy. The cloud providers did much of the hard work required for the first iterations of these services and dozens more, but smaller organizations will make them consumable for edge deployments and on-premises IT. Tools and services, while in many cases disaggregated, will be available to even small businesses who want to build their own. You will be able to create solutions based on the economic reality of what most edge solutions will look like: lots of locations, with only a few servers in each.  As for cloud functions, there are already a wide range of edge players who have cloud platforms ready for edge use cases that are simple to use and easy to deploy. Whether you’re interested in bare metal as a service (BMaaS), private cloud at remote sites or public cloud like functionality across many locations, the solutions available today are amazing and are continuously improving.

55 views
5 comments
1 upvotes
Related Tags
Do you have a uniform approach to testing in SaaS, or is it always case-by-case?

Top Answer: We test on a "use case-by-use case" basis. That uniformity allows us to compare apples with apples, or droids with droids.

57 views
1 comments
0 upvotes
Related Tags
How should security leaders approach API security today?

Top Answer: Security leaders should approach API security holistically. The first generation of API security tools did a good job of illuminating the core problem and the need to monitor API traffic, but it was limited to a “spotlight approach,” which means it only focused on part of the problem. As a CISO, I want to see sunlight: I want to see everything from code to production, with simulated attacks to validate and prioritize exposures. For the last 18 years as a CISO, I've said to vendors, partners and suppliers, “Whatever the threat model is, I need to see assets; actors, meaning who's involved; interfaces, so I know how they are getting to my assets; and actions, which show me who's doing what to what via what.” Only when you have that visibility can you develop a baseline for what normal behavior looks like. Once you have that baseline and you can get your arms around your space, then you reduce your attack surface and deploy resources to remediation of code and 24/7 monitoring, and use machine learning and automated models to alert you when something deviates from that normative behavior. But you can't monitor or defend what you can't see, and blind spots are prevalent; around 50% of APIs are unmanaged today.  That focus on visibility is one reason I’m a fan of the NIST model here in the US; the first principle is “identify.” You can’t protect what you can’t see. Creating and exposing APIs is very easy, but finding, governing, and securing them all is not. Adoption of APIs and their exposed logic has outpaced security and DevOps teams’ ability to keep up with or even put a lens on how their data's coming in and out.

Why is API security so difficult to manage?

Top Answer: There’s an old saying in security: “Your defense must be informed by the offense.” In general, defenders are always one step behind the aggressors, whether we’re talking about the digital or the physical space.  The Maginot Line is a good analogy for the current state of API security in most organizations. The industrial revolution didn’t happen in order to build machine guns, it was for commercial reasons. But these innovations created new military capabilities and in 1914, defenders in Europe didn't anticipate the degree to which the attackers were embracing industrialization in the context of kinetic warfare. Unfortunately, this meant they went riding into battle to defend their homelands on horseback, only to be met by mechanized columns of machine gun fire. After that conflict, in 1930, the best military minds in Europe began construction of the Maginot Line, which was an amazing set of fortifications built to resist a robust ground invasion like the ones they had just endured. But only 10 years later, the next attacks went around the Maginot Line through Belgium and the Luftwaffe flew right over it. The Maginot Line, as impressive as it was, provided a false sense of security and failed to take into account the next set of innovative thought patterns of the attackers. This is basically what we’re seeing in the world of web security, and these same rules apply to what’s happening across the world as companies rapidly create and expose their APIs.  We've been dealing with and securing web apps for over 20 years, but 20 years ago they were built much differently than they are today. The legacy term is “monolithic application,” and that was a standard design pattern for years and years; many companies still operate this way. There’s a well-known application security model from an organization called OWASP, and while it’s still valid, it was first published in 2003. You still have to defend against the attacks from the original OWASP Top 10, like SQL injection and cross-site scripting (XSS). But now companies and governments are rapidly embracing APIs and microservices, and in doing so they're expecting these new exposed services to do a lot more of the security that used to be centralized. The “I” in API stands for interface, and publishing new interfaces changes your attack surface. Attackers always change their tactics to take advantage of new attack surfaces, and if your defenses don’t evolve in real time, you are left with gaps and undefended blind spots. A lot of security and development teams don’t know that OWASP published a new Top 10 specifically for API vulnerabilities beginning in 2019, so unless they’ve revisited their whole framework in the last year or two, there’s a very good chance that they haven’t taken these new attack vectors into account.  Going back to the Maginot Line analogy: they didn't have anti-aircraft capabilities when they built it because air power wasn't a big thing, so they had to adapt during battle and learn how to defend up, not just left and right. In the same vein, we need to increase our abilities to defend against the new attacks against APIs, but today API adoption is dramatically outpacing security and the longer this happens, the further apart adoption and security get. There's a huge paradigm change from monolithic applications and the old attacks to the new, distributed API and microservice attack surface. The changing attack surface is one thing, but another is what’s available on the new attack surface. APIs expose application and business logic directly. That's not a bug, it’s a feature. It's by design, but the defenses like web application firewalls (WAF) that we use to defend against the old Top 10 list can’t understand or defend against logic-based attacks.  Yet another aspect of modern application architecture is that you can have multiple teams iterating and changing their APIs quickly. Some folks change their APIs several times per week and sometimes several times per day, and security can’t keep up with these changes. But once you fall behind, it's very difficult to catch up. As API security is a very new space, I use the Maginot Line analogy only to provide a non-computerized historical perspective. This paradigm happens over and over again, and in 10 years, it'll be something else. But for now, when it comes to API security, we're all behind the curve and it's become a big problem that is only getting worse, at least in the short term.

Can anyone recommend an end-to-end POS SaaS solution that's cost-effective?

Top Answer: While I haven’t use it we had very good experience integrating to the Square POS and the Shopify POS systems. You may want to look at those

167 views
1 comments
0 upvotes
Related Tags