Security

01:10 PM
Lev Lesokhin
Lev Lesokhin
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Leaving Out the Welcome Mat for Financial Services Hackers

Everyone knows the financial services industry is a prime target for hackers. Despite the dangers, many applications have software vulnerabilities that expose real risks.

When you think of the term "hacker," you probably imagine Guy-Fawkes-wearing teenagers hacking celebrity iCloud accounts, or Russians with zombie servers crawling the web for vulnerable credit card information. However, it turns out the most dangerous threat facing our IT infrastructure doesn’t come out of a Hollywood summer blockbuster.

The real problem lies in easily identifiable software vulnerabilities that are present in most enterprise applications. These vulnerabilities are like welcome mats for hackers, who can use the exploits to find and collect information, install malware, or crash the application completely. Embarrassingly, we’ve known about these vulnerabilities for two decades.

Recent findings in our ongoing research on application health unearthed an average of 50 to 100 input validation flaws -- much like the issue seen in Heartbleed -- in 70 percent of major financial services applications. If your 2015 IT risk management playbook doesn’t have a plan to stop these vulnerabilities from being introduced into your software, you’re leaving your organization open to some serious risk in the future.

No easy button
Unfortunately, there isn’t a “more secure” button you can press for a bulletproof application portfolio. The entire software creation process is a balancing act among robustness, security, and speed of delivery. If you want your application to be ready as quickly as possible, you’ll have to cut a few corners around robustness. And on Wall Street, that’s exactly what we try to do.

[Learn more about security for the Internet of Things at Interop's Internet of Things Summit on Monday, September 29].

Wall Street is inherently a risk-taking culture where the goal is to always try to make money before the other guy does. So it makes sense to roll the dice and push an application into production that might not have airtight security. Besides, our rockstar programmers know what they’re doing and can fix it once they find any holes. But applications are getting ever more complex and distributed, even for the rockstars to handle, and the more quality sacrificed in favor of the schedule, the less robust and secure the result.

It’s not the rockstar programmers who are to blame for leaving security vulnerabilities in the code. Developers in the financial services industry are some of the best at what they do, but they’re faced with tough constraints. They are under incredible pressure to deliver a sound product on time, and one that performs fast. Certain pockets of the industry turn to the programming languages C and C++ because they offer very detailed control over how an application accesses the computer’s memory, which can greatly increase the performance. But it requires a lot of examination and defensive coding to ensure an application’s security is airtight before going into production.

Performance matters
Many security experts claim that coding in C and C++ at all is a liability. But until more modern programming languages can meet or exceed their performance, developers in ultra-high speed environments aren’t going to be switching anytime soon. That means they’ll need to find a way to incorporate secure coding practices with their high-performance coding practices so they don’t leave tiny slivers of their systems open to hackers.

Since most financial services applications are multi-component, multi-tier, and multi-technology, it requires a panoramic technical understanding across the application architecture to spot resilience and security problems. And even though you might be paying your developers like the starting lineup of the New York Yankees, that level of technical understanding is beyond even the best of the best. It is inappropriate and unfair to ask developers to self-manage systems that are beyond their scope.

It’s time for IT management to stop leaving the question of robustness and security purely to the technologists. While you may not be able to describe the inner workings of the architectural framework of your company’s software, today’s managers can direct their development teams with a layer of technical product governance that provides real-time analytics for robustness, security, and performance.

This might sound daunting, but it doesn’t require going back to school, or changing programming languages, or ripping out your entire infrastructure and starting from scratch. It just requires a change in attitude:

  1. It doesn’t matter how talented your programmers are; development does require adult supervision.
  2. You have to measure more than speed to delivery; robustness and security should be KPIs that affect compensation as well.
  3. Deployment decisions should be based on more than launch days and gut reactions; real-time robustness and security analytics can help reduce costs and security incidents in the future.

By putting an end to these easily identifiable software vulnerabilities, we can begin to stem the tide of software glitches and hacks that have been sweeping through financial services over the past decade. Or, at the very least, take away the welcome mat hackers have been using for years without consequence.  

Lev Lesokhin is executive vice president of strategy for CAST. He is responsible for market development, strategy, thought leadership and product marketing worldwide. He has a passion for making customers successful, building the ecosystem, and advancing the state of the art ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
lesokhin
50%
50%
lesokhin,
User Rank: Apprentice
9/30/2014 | 5:17:30 PM
Re: Don't forget the vendor incentives
Indeed. Eventually this industry will have to go to an inspection/certification model. The big office towers in Midtown and Jersey City that house our financial services colleagues were all built with some oversight of the structural integrity. Engineers did designs, permits were issued, the structures and then the plumbing were inspected, the finished product was certified by professionals. That's why you can't drive a car through one of these buildings and that's why they don't fall down on themselves. At some point in the near future software will have to be delivered the same way - and if the vendor has to certify that the software is free of well-known security and robustness flaws, our development teams will get to enjoy some more Yankee games - in their off time, of course.
Becca L
50%
50%
Becca L,
User Rank: Author
9/30/2014 | 5:08:50 PM
Re: Don't forget the vendor incentives
Good point, and since developers are being paid like the "starting lineup of the New York Yankees" they are often expected to take on the responsibility and have the expertise to patch the holes the software vendors create. I do question if hunting down vendor security holes is a good use of IT's time. And in that light, I can see how working with less-than-reputable vendors that are slow to fix security holes are a big stress for developers.
lesokhin
50%
50%
lesokhin,
User Rank: Apprentice
9/30/2014 | 4:56:47 PM
Re: Don't forget the vendor incentives
Very true, and that's bound to change with the recent fever pitch about security. This is also relevant vis-a-vis custom application services providers. Most of us have many vendors writing code for us all the time - it's often unclear who's responsible for secure code. In the end, it's the client IT organization that's held accountable by the business.
Becca L
50%
50%
Becca L,
User Rank: Author
9/30/2014 | 1:59:08 PM
Don't forget the vendor incentives
Rockstars or not, I'm told many vendors are made aware of the security holes in their software but aren't inclined to fix them all because a) they are not legally required to b) the high cost c) perceive it as unlikely that hackers will exploit the vulnerability (because it's relatively difficult to attack). However a lot of the big headlined security breaches fall into this last category, so developers and programmers have to reconsider their priorities.
lesokhin
50%
50%
lesokhin,
User Rank: Apprentice
9/17/2014 | 8:56:43 PM
Re: Don't Blame the Developers
Thank you for your comment, Ivy. You point to several issues here. There's a disconnect between the technology teams and the senior leadership at most firms. So, indeed the CEO and business leaders get impatient with process discipline and push developers to move as fast as possible, eschewing as much process as possible. It seems Reg SCI has gotten stalled in the works a bit, mostly due to industry pushback, which is not surprising. But, it will eventually hit the street and will make it easier for the technology team to push back on senior leadership to introduce more software assurance processes.


Also, you make an interesting point about positive incentives vs. blame. Our team at CAST has over ten years experience rolling out metrics programs in IT organizations. It's tempting for management to use metrics as a way to come down on developers. This never yields good results. The most successful implementations of metrics involve bonuses for improvement and leaderboards for positive peer pressure. If your application is consistently ranked last in terms of its Security scores, your peers will notice - this is true among developers and among business leaders. There's not implied blame or management pressure - just hard facts for all to see. This truly works, in almost any environment.
IvySchmerken
50%
50%
IvySchmerken,
User Rank: Author
9/16/2014 | 10:23:37 AM
Don't Blame the Developers
Lev, this is a very interesting piece about how the software development process can be letting in the hackers. No doubt in financial services, and in capital markets especially, developers must be under extreme pressure to roll out applications quickly to maintain a competitive advantage. And if there are glitches, the company assumes they can fix it. But with systems becoming so complex and distributed, this is challenging and can have serious conseuqences. So it seems unfair to blame the developers when it's probably the CEO who decides to roll the dice and launch a system prematuraly. Perhaps firms should reward their developers for security practices as much as for high-performance? With Regulation SCI looming from the SEC, do you see this attitude changing?
More Commentary
A Wild Ride Comes to an End
Covering the financial services technology space for the past 15 years has been a thrilling ride with many ups as downs.
The End of an Era: Farewell to an Icon
After more than two decades of writing for Wall Street & Technology, I am leaving the media brand. It's time to reflect on our mutual history and the road ahead.
Beyond Bitcoin: Why Counterparty Has Won Support From Overstock's Chairman
The combined excitement over the currency and the Blockchain has kept the market capitalization above $4 billion for more than a year. This has attracted both imitators and innovators.
Asset Managers Set Sights on Defragmenting Back-Office Data
Defragmenting back-office data and technology will be a top focus for asset managers in 2015.
4 Mobile Security Predictions for 2015
As we look ahead, mobility is the perfect breeding ground for attacks in 2015.
Register for Wall Street & Technology Newsletters
White Papers
Current Issue
Wall Street & Technology - Elite 8
The in-depth profiles of this year's Elite 8 honorees focus on leadership, talent recruitment, big data, analytics, mobile, and more.
Video