Get In Touch
Recently by Rich Bolstridge
A DDoS attack targeted at one web site is bad enough. But what happens when that single attack poses the distinct possibility of doing even more damage than originally intended. The kind of collateral damage I'm talking about is very real when you take into account IT architectures reliant on shared services.
Shared services include anything that serves more than one application or set of users, for example:
- Network infrastructure
- Network bandwidth
- Market data and other sources of information.
- Domain name servers
And while shared services can benefit an organization by bringing down IT costs, creating resource efficiencies and shrinking the IT footprint, in the case of a DDoS attack, there can be significant disadvantages. An attack on an organization with a healthy amount of shared services has the capability to cause unforeseen outages across a wide number of applications, users, and geographies.
In this post I'll present three cases in which a DDoS attack impacted a shared service, knocking out applications far beyond the attack target. In each of these cases, the companies were not using Akamai to protect the systems under attack.
We're at that time of year again when we sharpen our pencils and write down all the things we want to accomplish during the next12 months. Don't worry; I'm not going to bore you with my personal New Year's Resolutions. Instead, I'll share some quick thoughts on what I believe the resolutions should be for the banking industry as it continues to do more and more business on the web.
Resolution #1: Rethink Internet and Web Security
High profile attacks on banking web sites in 2012 illustrated that despite having defenses in place, and even having forewarning of attacks, many banks were unable to adequately prevent their sites from going down. Banks have watched the size of attacks targeted against them increase in volume - to levels that even the largest banks do not have the infrastructure to handle.
Attacks in 2012 also highlighted how the infrastructure and tools available to the attackers has changed dramatically. A Moore's Law-like rule applies here. Increased Internet connection speeds and 4G for mobile along with video game-like attack tools have made it significantly easier to launch a crippling attack against several targets at once.
And finally, the effectiveness of the attackers in knocking out sites, and in generating media attention, is putting the focus of bank attacks on the "hacktivist" community. Unfortunately, this may ultimately provide a convenient cover for criminals bent on fraudulent money movement, not web activism.
As a result, in 2013 banks will need to consider more effective ways to stop attacks well before they reach their data centers and seek out innovative alternatives to keep their sites available and secure on the Internet.
Resolution #2: Take Mobile to the Next Level
In 2012, small banks, including many local banks with just a handful of branches, produced mobile banking apps with the same convenience features of the big banks. Remote Check Deposit, bill pay, and other features that just a year ago were considered advanced are now table stakes. Interestingly, some of these smaller banks provided such features as RDC to their customers before some of the big national banks.
In 2013, banks should strive to differentiate their mobile apps from their competitors and the focus should be on engagement - getting customers to use their apps more frequently, and keeping the user in the app longer. For example, explore "No login required" apps that do not require a customer to enter a username and password to access their account details. Just like mobile check deposit, once a handful of banks figure it out, it will fast become the next "must have" app.
Banks must consider that the practice of delivering only a limited set of functions to the mobile app is unacceptable and resolve to migrate major functions once only considered appropriate to a web site, to their mobile apps.
Resolution #3: Get a Handle on Big Data
In 2012, big data was all about big hype. In 2013, big data is going to be a big reality. Due to customer reservation and legal privacy concerns, we may just see that in the banking industry, big data will first applied to security in an effort to help protect customers. Banks should explore how to apply usage patterns and behaviors to solve the problems of protecting banking web sites and customer accounts.
Here's to a happy and prosperous 2013.
Happy New Year.
Rich Bolstridge is Akamai's Chief Strategist for Financial Services
The meeting was held under Chatham House Rule, a well-known format in the UK, but not as well known in the U.S. and other regions. Under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker or participants may be revealed. The rule allows people to speak as individuals and encourages free discussion. As a result some very interesting information was shared.
One workshop attendee reported that their organization is under nearly continuous DDoS attack. This attendee estimated that 97 percent of the attacks against the bank are volumetric DDoS, while only three percent are logic attacks attempting to do something more malicious. This percentage of 'easy' attacks at first seemed surprisingly high to the others in the room, and that three percent seemed quite a reasonable number to handle. But when asked if the bank experiences attempted fraudulent money movement masked by the volumetric attacks, their answer was 'yes'. We hear frequently of such patterns by industry analysts and the publications covering the space. To hear it directly from a security executive at a bank is much more impactful.
Security information sharing within the banking industry is especially important. There are many established industry associations which allow this information sharing between the banks. But security vendors such as Akamai also have much to share, and those channels are not nearly as well developed. The channels between the vendor and banks must extend beyond the banks directly to the regulators. Regulators should open up to vendors to understand how the latest security innovations may help protect the banking industry.
Based on the success of our London event, Akamai is planning Financial Services Security Roundtables in cities across the U.S. and around the globe. If you are interested in attending or hosting one of our roundtables please let me (firstname.lastname@example.org) know. I look forward to meeting you there.
Rich Bolstridge is Akamai's Chief Strategist for the financial services industry
We have all heard about banking web sites being attacked and taken down by hackers, and a few of us (myself included) have seen our banking sites temporarily wiped off the Internet by attacks. But have you ever seen an actual DDoS attack launched against a bank's web site? Well here is your chance.
Next week, Akamai will be demoing its Kona Site Defender web security solutions at the Finovate conference in New York. I have been attending Finovate events for years. It's an exciting and fast-paced conference, showcasing the best innovations in financial services and banking technology from a mixture start-ups and established companies.
For our demo we have created the Bank of Akamai web site. We will show two versions of the site: one protected by Kona, and one unprotected. We'll then launch a live DDoS attack against both sites and demonstrate how Kona automatically protects a banking web site with no intervention by the customer.
Our demo is at 2:45 PM on the afternoon of Wednesday, Sept. 12. If you or anyone from your company is attending Finovate be sure to catch the demo, and please stop by our booth afterwards. I look forward to seeing you there!
Rich Bolstridge is chief strategist, financial services at Akamai
When I say "mobile banking applications", I mean any native Smartphone application used in the world of financial services. This could be banking, brokerage and trading, insurance, investment advice, or others. And my advice here applies to more than financial services - it applies to other areas as well, such as social media apps, commerce, media and entertainment, and gaming. In reality, instant-on should be applied to any app that you may use on your Smartphone.
Let me define what I mean by instant-on. An instant-on application is one that immediately launches and displays the start screen, without any request/response over the WiFi or carrier connection. This means that the startup is completely in the code of the application and Smartphone. It is instant, in that the startup occurs entirely on the Smartphone. Instant-on apps can launch in as little as under 100 milliseconds, vs. up to many seconds for apps that communicate back to a server upon startup. As I like to say, "It's only software, it will do anything we tell it to do." Well, then why do developers tell their apps to "call the mother ship" just to launch?
Of the dozens of mobile apps that I have examined, less than 5% are instant-on. For those apps that do make a request back to a web server, it's amazing to see what is being requested. Sometimes it's a small configuration file, sometimes it's a lengthy disclaimer document (which does not even show up in the start screen), and other times is a huge waterfall, with over a dozen hostnames and dozens of objects. In many cases, it has nothing to do with what is required for the start screen.
But perhaps most interesting (or puzzling, depending on how you look at this topic) is that this concept isn't new. Noted web performance evangelist Steve Souders lists "make fewer HTTP requests" as his number 1 rule for faster loading web sites. If we're doing it (or should be doing it) for "wired" web pages and applications, why aren't we doing it for mobile?
How to Examine Native Apps:
The first step to understand instant-on applications is to investigate the request/response flow from the app. You can do this easily on a web page using tools such as httpwatch, but for native apps, it's not that simple. To "sniff" a native app, you need to setup a network sniffer on your PC, and proxy your Smartphone through that PC. You can then watch the requests from the native app, and the responses from the server back to the app. It sounds difficult, but it's really quite simple. And once you have it setup, it takes only a few seconds to sniff a native mobile app.
I have detailed document that provides step-by-step instructions on how to sniff native apps, which I would be glad to share with you. You can request a copy by posting a comment to the blog, or email me directly. Just ask for the document "Taking the Mystery Out of Native Applications".
Of course, once launched, a banking app will require communications to a server, and there are many techniques that can be used to make those screens fast. I have seen the good, the bad, and the ugly there as well. But let's at least start off by giving users what they want, and make banking apps instant-on.
- By 2015, Forrester predicts that one in five US adults will be using mobile banking.
- Mobile customers are the new "sweet spot" segment for the banks. They are younger, they are more affluent, and buy more financial products.
Source: Forrester Research "US Bankers Want More From Digital Banking", April, 2012
- "Tablet Banking" is now an established channel, and is tracked separately from Mobile Banking.
- At a conference I recently attended, one bank reported a 70% drop in Mobile Web Site traffic over the past two years. The decline is attributed to customers adopting the bank's native mobile app.
- They also reported customer usage patterns as follows:
-- Branch: 1-2 visits per month.
-- Web Site: 7-8 visits per month.
-- Mobile App: 28-30 visits per month.
- Cannibalization of the web channel is underway in banking, and some banks are now experiencing a reduction in web sessions.
- Multiple banks are now reporting that they are expecting and planning for the web-to-mobile crossover by 2014 or 2015.
Research shows that younger, more affluent and more profitable customers are the first customer segment adopting mobile banking. These same customers are also visiting more frequently. What are the drivers behind this? Mobile banking is all about convenience. Mobile check deposit is a good example of this convenience. If you have not tried mobile check deposit with your bank, please try it. Experience this first hand, and you may never deposit a check in an ATM again. Remote deposit capture (RDC) is now "table stakes" and a great example of the convenience of mobile banking.
"An even immeasurable increase in trade volume as a result of Akamai performance and reliability improvements can result in a significant increase in commission revenue."
In this final section of blog series I will continue the ROI analysis and look at the impact of performance on the net income of a brokerage firm.
Continuing with the example brokerage firm from Part 2 of the blog, I see on their website that 20 stock analysts cover this firm. Most of those analysts have an Excel spreadsheet with a detailed financial model, and you can be sure that DARTs is a major element in their model. How will a change in DARTs affect earnings?
Let's pull more figures from their 10K:
1) Net income = $650M (rounded)
2) Shares Outstanding = 570M (rounded)
We know that all profit is made at the margin, so what is the profit margin per trade?
Net Income from Commissions = (Net Income) * (Percent of Income from Commissions)
= $650M * 45%
= $290M (rounded)
Number of Trades per Year = (DARTs) x (Number of Trading Days per Year)
= 400,000 x 250
Average Profit per Trade = $290M / 100,000,000 Trades
And how many trades would it take to produce that $290M in profit?
Profitable trades = $290M / $12 CPT
= 24,000,000 (rounded)
And how many "profitable" days are there?
= 24,000,000 Trades / 400,000 Trades per Day
= 60 days
Think about this for a minute. Out 250 trading days for the year, it was the last 60 days that produced the profit. Ten months of work just to cover your costs, and then only two months to reap the rewards. To be sure, every trade has some costs, but with a highly automated trading system, we could assume that once the fixed costs are covered, each additional trade may result in a profit of perhaps $10. Let's work with this figure.
"How much would you be willing to spend to increase your net income by $10M?"
"How much would you be willing to spend to increase your net income by 1.5%?"
The formula for ROI is:
(Gain from investment) - (Cost of investment) / (Cost of investment)
Using the approach above, you can select the gain that makes sense to you, and easily calculate your ROI.
This 3 part blog series was not a quick read. That's part of the problem with ROI - everyone wants a quick answer but it takes an effort to do the analysis. I only tackled one of the many elements that could be included in a full ROI analysis. A similar approach can be taken with Account Opening, Call Center Reduction, Ad Spending, and other items. The 10K presents much of the data required for the analysis. Other data must be provided by the firm itself. This example can be extended to other segments of the financial services industry, or even to other industries.
Performance improvement can have a major impact on revenue, on net income, and on earnings. Investments into products, services, and internal improvement programs that improve your site or app performance can quickly pay off.
Akamai has years of experience in dealing with the ROI of performance improvements. I invite you to contact me directly with your comments or questions, or if you would like to discuss other ROI cases.
Rich Bolstridge is Akamai's Chief Strategist for Financial Services
Part Two: The ROI of Performance
There are many reasons why ROI is difficult to calculate. I have dealt with this challenge as it relates to performance, user experience, and technology adoption for over 20 years, and across many segments of financial services. The best way to deal with it is to dive right into an example, and then consider how to extend the example to other segments.
In Part One I showed how the brokerage segment is most keen on performance. The brokerage segment also provides some very good metrics from which to build an ROI case.
The first step is to identify the elements for our ROI case. You can categorize these elements as income producing elements, and expense elements. Personally, I prefer to first examine top line elements which grow the business, and can make the biggest impact for a firm. In brokerage, the common elements I work with are:
1. Daily Average Revenue Trades (DARTs)
2. Account Openings
3. Call Center Reduction
4. International Users
5. DDoS and intrusion mitigation
6. Ad spending
Prior to joining Akamai I was one such person. I experienced the thrill and rewards of making a web site faster, of moving from #11 to #1 on a performance benchmark, and knocking off competitors along the way.
In this two-part blog, I will examine why performance continues to play such an important role in financial services. Today in Part One, I will dive into user experience. In Part Two, I will present the ROI of performance - always a challenging topic. In the future I am going to tackle tablets. Is the industry meeting the performance expectations for tablet users? How can FSIs make them faster? I have some answers. So stay tuned.
Part One: The Performance Arms Race:
One of the major drivers in the arms races is that the performance expectations of users continue to increase. In fact, a recent study shows that almost 50% of users expect a 1 second page load time. And don't forget, most of the performance tools and benchmarks only measure the time to the last byte to the browser, and do not measure the actual render time to the user. So if you are happy that your page load time is 1 second on a benchmark, remember that time is likely double to the user looking at the screen.