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.
 | | | | | 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.
Matthew Todd
CISO and VP of risk and technical operationsFinancial
Engines |
| | | | | |
| |
|
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."