Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Home working is ripping the heart out of cities, the DoD’s bizarre cloud strategy, and Apple adds a $10,000 app price option. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Data centers cause climate change, and Meta is rolling out Precision Time Protocol. (more…)
Open banking has become the latest technological advancement for financial services applications that’s modernizing the industry. For instance, Mastercard recently began its Start Path Open Banking program, which provides select startups the opportunity to use Mastercard’s expertise while learning how to apply open banking to their own business. Open banking is creating new opportunities for revenue sharing and reducing data licensing and transaction fees between financial institutions and their partners.
Customers who take advantage of open banking also gain a more comprehensive, holistic view of their finances so they can be in a stronger position to manage their wealth. Just as importantly, open banking will provide more opportunities to use data for products and loyalty programs across the full spectrum of their organization’s offerings. Financial services companies like Mastercard also believe that open banking programs improve inclusiveness and financial literacy. With greater financial literacy, customers can work to lessen the chances of fraud in their accounts.
This follows an overall trend of breaking down barriers when it comes to connecting financial organizations with consumers through new, innovative financial technologies. In fact, 96% of consumers globally are aware of fintech services, including at least one money transfer and payment. Additionally, U.S. consumers are steadily adopting new fintech, including peer-to-peer payments.
While open banking has the potential to shake up the foundations of the banking industry, there is also the possibility of it becoming a target for threat actors and cybercriminals alike. The reason: application programming interfaces (APIs) that power open banking are being targeted.
Open banking uses APIs to connect financial institutions with third-party applications. The Open Banking Project is one of the leaders in providing open source APIs for banking and relies on an open source system for financial services providers to access consumer banking and financial data.
Yet, the more financial services organizations rely on APIs, the greater their attack surface becomes. APIs, as the building blocks of today’s modern web applications, are already a big target for threat actors and a primary attack vector. Banks, and the financial services industry as a whole, are also targets for cybercriminals.
IBM’s X-Force Threat Intelligence Index 2022 noted that finance and insurance organizations were the second-most targeted industries. Further, IBM also found that among those attacks, 70% were against banks and 14% were against other financial organizations. This tells us that while other organizations might make the data breach headlines, banks and financial institutions are most often under attack by threat actors and cybercriminals. While one of the major drivers for this is financial gain, there is also a wealth of data in banking, including personal identifiable information (PII), payment card industry (PCI) data, account and payment information. Much of this can be leveraged on the dark web for financial gain.
Unfortunately, attacks on financial institutions and the APIs that drive much of our engagement won’t change anytime soon. The problem associated with APIs is that, if left unsecured, they can provide threat actors a foothold into sensitive data that can be exploited. Additionally, many organizations don’t have a true understanding of how many APIs they have (many are interconnected) or how these vulnerable endpoints are being protected. It is incredibly difficult to protect something that you don’t even know exists! Adding an additional layer of complexity to the API conundrum is how third-party APIs are often relied upon. Using these sources, while potentially a time-saving strategy, can leave your networks open to attack.
If you’re a company that plans to start taking advantage of open banking, it’s important to mitigate some of these threats by establishing sound API protection strategies. First, gain visibility into your entire attack surface. After all, knowing yourself, including your APIs and web apps, along with understanding your enemy, will lead to success on the battlefield (to paraphrase Sun Tzu). Once you have a comprehensive view of your endpoints, including those older and deprovisioned APIs, you can be in a better position to protect against the multitude of threats that they face. Ideally, you will be able to get real-time analysis of traffic hitting your endpoints so you can get a more holistic view of a surface that is always changing.
It should also be emphasized that sophisticated attacks consist of bot armies generating API traffic and attacks. Malicious bots are being leveraged on an ever-growing basis in attacks, including DDoS attacks and account takeovers. While many bot attacks are automated, being able to detect and block them in real-time, when combined with continuous monitoring, can help to lessen the threat posed by bots.
A future with open banking is an exciting prospect due to the fact that it will put financial control back in the hands of businesses and consumers. While there should be a reasonable amount of caution placed in many of the API-centric open banking solutions, there are ways to alleviate these concerns. Strong API security, along with bot blocking and detection, can go a long way toward protecting against modern threats.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Meta’s latest results are very bad, Apple wants its cut of Facebook ads, and Lennart Poettering proposes a new Secure Boot for Linux. (more…)
The need to protect SaaS data has never been greater. A recent global survey from Odaseva found that 51% of ransomware attacks are targeting SaaS data, and they are more likely to succeed (52%) than were attacks on cloud, endpoint and on-premises data.
But there are plenty of reasons beyond the threat of ransomware to protect SaaS data. Employees accidentally—and maliciously–delete data. And while outages are not common, they do happen, and when they do, it can cause a lot of pain. Atlassian, for instance, suffered a two-week outage in April. If the data isn’t backed up, the organization is completely at the mercy of the provider to get the service back online before they can access it.
And though all respondents said their organizations say they have some form of SaaS data protection in place, 57% said they still have SaaS data that remains unprotected. Likely, that’s why only half of respondents whose SaaS data had been successfully encrypted by an attack said they were able to recover all of it, compared to more than eight in 10 (81%) who were able to do so for on-premises data.
That’s not surprising, because backing up SaaS data is very different from on-premises data protection. For starters, of course, IT has limited control, at best, over the application and data. IT will need to rely on APIs to back up and restore SaaS data, and those API calls will have hard caps. SaaS providers almost always run their services on a multi-tenant architecture, so they need to make sure API resources are available for everyone. To accomplish this goal, they set hard caps on API calls, typically over a 24-hour period, which means that IT must carefully manage API usage for backup and restore operations. And with many different APIs with different capabilities and limitations to choose from, IT will need to make some hard, complex choices.
Managing API usage is important, and not just for backup. These same APIs are also vital for connecting other applications integrated into the SaaS application. And for core SaaS apps, such as CRM or ERP, there will likely be many such integrated applications that require the use of those APIs.
To get the best performance, IT needs to be very careful with the APIs it uses for backup and recovery. Let’s take Salesforce as an example. The Salesforce REST API can transfer up to one million records per hour, while the BULK API can do up to ten times more in the same amount of time. And if you use parallel calls to multiplex data, the BULK API can do up to 300 million. The upshot is that the API you use can make a huge difference in your recovery point objectives (RPOs) because transferring more data faster means more backups throughout the day.
Unfortunately, Salesforce customers won’t be able to depend on BULK API for all their backup and recovery needs. Some objects can only be accessed via the REST or other APIs, for instance, and that BULK API will also be useful to other apps—you don’t want to hit that hard cap and leave other applications unable to connect. And you can’t always use the same API to write data as you do to read it.
The SaaS backup infrastructure has to achieve a balance of API usage, which must be closely managed. And don’t forget about restore, which can consume a ton of API resources. Make sure you have enough to account for a big restore—you really don’t want to hit the API cap while you’re trying to get your users back in business after a data loss event.
Lastly, APIs change over time and the backup system has to be able to adapt. You’ll need to make sure you keep up with API documentation so the system can be updated regularly; otherwise, data may go unprotected.
It’s now becoming widely accepted that SaaS data needs to be protected, but building a SaaS backup solution that meets an organization’s RPOs and RTOs is more complex than many in IT may realize. A strategic plan for API management is a must-have for any SaaS backup management solution.
There are more choices than ever when it comes to APIs–and that’s a good thing. But it also means you’ll need a strategic plan for choosing the right API solution.
Two questions I’ve found can help guide that decision:
Once you’re clear on the answers, you can evaluate API solutions based on the following five criteria to choose the one best suited to your needs.
In a highly competitive global market, it’s not enough to have reliable uptime. Speed also matters–a lot. A site that loads in one second has a conversion rate three times higher than one that loads in five seconds.
To accommodate current customer expectations for page speed, API response time should be no greater than 90 milliseconds. One way to blazing-fast API speeds is to take a client-side approach where data is delivered to an edge node of a CDN network instead of stored on a server somewhere in your data center.
But let’s return for a minute to the first question I introduced above: What problem are you trying to solve? If you’re an online retailer, you want your site to load fast so your customers don’t click away and you want everything on it to be accurate–for example, if an item sells out while a customer is browsing, they shouldn’t be able to put it in their cart.
Not every function requires the same level of speed. Product description content, for example, is mostly static, while inventory is not. So content delivered by your CMS’s API may not require the same speed as data from a transaction engine.
While high performance is important for every API you use, the actual performance benchmarks each one needs to meet vary based on function and on the end-user problem you’re solving.
Thorough documentation is a must-have for any API solution you adopt. Without thorough documentation, your team will be forced to figure out how to use the API via trial and error supplemented with time-consuming support interactions. Strong documentation lets developers use APIs more effectively and, ultimately, ship products to market faster.
But even among providers that offer thorough documentation, there are more and less helpful varieties. I’ve read plenty of documentation, for example, that is written with the assumption that the person reading it already understands how the API works. This makes it harder for newer developers to learn and understand the capabilities of an API.
As you consider providers, look for those with documentation written for someone who is totally new to the API–which you and your team will almost certainly be. As a stylistic guide, look to documentation from Mozilla, MDM and W3 schools, which I think do an excellent job of communicating for non-experts.
To gauge the helpfulness of a potential provider’s documentation, I recommend having your team read some of it and asking the partner team how often they update it. A best-case scenario is that they consider documentation an ongoing project that will never be complete.
Security is pretty self-explanatory, so I won’t spend a ton of time on it here. Any API provider should offer robust security to ensure that the API cannot be used nefariously by bad actors or hacked to expose sensitive information. REST APIs almost always follow standards like 0Auth and TLS to maintain security. It’s worth looking at how the API you’re using describes its security practice.
Your team should have the freedom to create whatever they want with the APIs you use, meaning they shouldn’t be hampered by roadblocks in the API’s design. This freedom to create should exist in all aspects of the API: It should let your team create whatever customer experiences they can dream up, and it should let you manage back-end information in whatever way makes sense for your organization.
In other words, an API solution should be well-defined but should not define everything you can do with it.
The final piece to take into consideration is the API’s pricing model, by which I mean not only its actual cost but also the way the provider charges to use its service.
For example, does it charge by order? By bandwidth? By number of records? Again, this comes back to the problem you’re trying to solve: If you have a lot of requests to make, for example, don’t choose a service that restricts requests per minute.
And even if a pricing model works for your business today, will it work as you scale? This question brings me to my final thought.
I started this piece with two key questions to guide the process of choosing API providers: What problem are you solving and where is your business going?
If you’re exploring APIs as part of a replatforming project, there’s a good chance you chose a platform 10 years ago that could do everything–but that can’t keep up with evolving customer expectations or that restricts your team’s creativity today. The APIs you choose should let you meet current needs and make it easy to make changes–including swapping one API provider for another–as your needs evolve.
In other words, when you choose the right API solutions, you should never need to do another replatform.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Passkeys is getting another big-tech supporter, and the four-day workweek train picks up speed. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: A third-party Instagram app causes ructions, remote work causes office slump, and more on Cali’s salary transparency law. (more…)