Security is everybody's responsibility at Financial Engines Inc., an investment advisory and portfolio management firm in Palo Alto, Calif.
"We deal with security from as broad an approach as possible," said Matthew Todd, CISO and vice president of risk and technical operations at Financial Engines. "We address that at the point of a new employee hire. We let people know that security is a critical part of what we do as a company. We try to incorporate into the culture that it's not just developers who need to worry about security, but anybody who comes in contact with sensitive data."
Tapping an automated code-scanning tool gave the company yet another resource in its security-in-depth approach. And while it's no panacea in and of itself, the fact that Financial Engines uses such a tool "makes the response to RFPs more straightforward and significantly shortens the length of conversation around our coding practices" with potential customers, Todd said.
"The fact that we can say we do a code review as part of our development process gives [customers] comfort, and it demonstrates the maturity of our risk management process when it comes to code, and the fact that it's part of our overall program," he said.
Nobel Prize-winning economist William F. Sharpe founded Financial Engines in 1996, and today the company has just over 200 employees in three offices. In addition to a managed accounts program, its Advice Engines enable the company to provide personalized investment advice to its customers through online, in-person, telephone and call center channels.
Behind these engines is "a single set of code that provides all of our various services," Todd said, "so it's millions of lines of code, all using the same core engine and central database and the same back-office connection to providers."
Security an integral part of the development life cycle
At Financial Engines all developers are required to follow the secure Java coding practices defined by the company's architects and contained in a guidelines document that all developers are required to read, according to Todd. In addition, the developers undertake security-specific training from time to time, as well as yearly regulatory compliance training.
All code is reviewed by a senior architect and Todd -- a process that was 100% manual until about a year and a half ago when the company became a beta user of the Fortify Source Code Analysis tool from Fortify Software Inc. in Palo Alto, Calif.
"We presented a fair problem for [Fortify] because we have Java and JSP [Java Server Pages] together as one cohesive set of code. We had the product fairly early on, and we helped them to nail a lot of bugs," Todd said.
Today, the Fortify tool is used as part of the development process, Todd said. "For a major release we submit [the code] to review by Fortify and we have a senior architect responsible for going through the Fortify findings, who finds high, medium, and low [vulnerabilities]. He will review high-level ones with me, and together we come up with a remediation plan. While he's going through the scans, he may go directly to the developer who might have checked in something inappropriate that Fortify caught, say some cross-site scripting bug, and that also becomes part of the training process."
In addition, Todd said the company used the Fortify tool to analyze older code that was developed before the implementation of the secure coding practice guidelines. "Because we have a code base that has grown fairly organically, we have older pieces of code in the system that people hadn't looked at for a long time. The tool helped us to go into older areas of code and see where we were not capturing things properly," Todd said.
It made the process of finding vulnerabilities much more straightforward, Todd added. "In the medium- and low-risk areas it would capture a bunch of things we might not have considered, and in many cases we choose to ignore, but at a later date we might go after some of them," he said.
But the use of a scanning tool does not necessarily mean the code is secure, Todd cautions. "You can't use a tool like this and figure it will capture everything. You also have to know what your application is doing and how it should be used," he said. "It goes beyond security; you also have to be aware of privacy regulations, for example. Somebody might be checking in a change to the way users log in and that makes inappropriate use of social security numbers."
Expect to put some time into the scanning tool as well, Todd said. "The learning process wasn't much more than I would've expected, but the tool needs to be trained in your environment, so you shouldn't enter with your eyes closed," he said. "It's not a panacea. You do need someone with a good in-depth knowledge of the code base and what protections are in place to make it effective. You need to train the tool and you need to be a qualified trainer. I wouldn't give it to a junior person."
Security doesn't end at code review, Todd said. The company undergoes a third-party audit at least once a year, and it is subject to security audits by partners and customers. And the reviews the company performs internally go well beyond penetration testing, he said.
"It goes into policy procedure, social controls, physical controls -- we see it all as integral to security. That includes how well your data centers are managed, how robust your systems are in terms of recovery, how rapid your response is to disaster. It's a bigger picture of security," Todd said. "I'd like to think the world is moving away from security alone to looking at risk," Todd added. "Looking at security vulnerabilities in the context of your business is what risk is really about."
This was first published in October 2006