For many Java developers, application security has not been an issue they've wanted to address. That changed last...
week as a panel of application security experts tackled the subject at TheServerSide Java Symposium in Las Vegas.
The panel's message was clear: Not only is it important to know what your risks are, but you need to develop a plan to incorporate security in all levels of software development.
Led by moderator Cameron Purdy, president of Somerville, Mass.-based Tangosol, panelists Jeremiah Grossman, Ted Neward, Christopher Steel and Justen Stepka agreed that application security can't be an afterthought. You need a plan from the beginning.
"You need a defense-in-depth approach," said Jeremiah Grossman, founder and CTO of WhiteHat Security and founder of the Web Application Security Consortium (WASC). "From Web applications to whatever else you have, you need to build security in."
Ted Neward, independent consultant and author of Effective Enterprise Java, agreed. You have to know what you're trying to protect, he said. "It goes under the name of threat modeling. You need some idea of what you want to build, and you need to have some idea of what you want to protect," Neward said.
Christopher Steel, founder and president of FortMoon Consulting and author of Core Security Patterns, went even further and said you need to ensure security is built in at every layer and at ever step of the software development life cycle. "You need to make sure testing is done all along the way -- white box testing, black box testing -- and sign off on each step."
Additionally, application security is just one part of a company's entire security strategy, said Justen Stepka, CEO of Authentisoft. "You need to address all layers of security. You need firewalls, you need security at the code level and at the social level," he said.
Threats and vulnerabilities
What security issues and vulnerabilities should you look for? The number one thing, which the panelists said would take care of many of the threats to applications, is input validation. If you test for that, you can avoid problems such as buffer overflows and SQL injection. Other top concerns include authentication and authorization.
Two-factor authentication, whereby two different forms of authentication are tied together, is emerging as an important technique in the battle to protect applications and data. The traditional username and password technique is nothing to hackers, the panelists said. "Without that additional authentication, they can easily get in," Grossman said.
Additional authentication can be biometric -- fingerprint scanners and iris scanners. Steel said he's seeing an increased use of that and is now seeing them in Web applications.
Neward, however, warned of the use of biometrics. "If my password is lost or stolen, I can get a new one. What if a scan of my thumb is stolen? Do I get a new thumb?"
When asked about the benefits of a federated security model, the panelists were skeptical. The federated model allows enterprises to use different security mechanisms. Federation standards then create a mechanism by which these different systems can exchange security information, without in-depth knowledge of the security services on each side of the agreement.
"The federated security model is a great idea, but I don't know if it would work because you would have to trust the companies involved," Neward said.
Steel and Grossman agreed that acceptance of the model is a business issue. Not only are you dealing with a lot of advanced technologies, but you're also giving over all your data.
How to get more secure
What will it take to make application security more pervasive? Grossman said business managers need to get scared. "They need to be afraid of what will happen if their applications are exploited," he said. "Unless developers get pushed by management or the government, we won't do it. We're not motivated to solve the security problem."
Stepka, on the other hand, says change needs to come from the bottom up -- not from the top down. Everyone who uses the systems needs to be educated about secure practices.
Neward disagreed, saying, "I think we use that as an escape clause too often -- blame the users. Part of the problem is we make security easy for technologists and not for users. We need to start thinking of the end users and we need to give them more user-friendly ways to work securely."
One way to do that, Stepka said, is to minimize the number of usernames and passwords users are required to enter. "That should be the minimal thing you should do," he said.
If security isn't implemented in applications, what's the worst thing that could happen?
If you conduct sales via a Web application, Visa could cut you off, Grossman said. You need to comply with Visa's regulations if you want to play with them.
Neward said people could lose trust in online transactions and stop doing business via the Web. "However, I think security is better now. We've taken the first step and admitted there's a problem. Now we need to take the second step," he said.
For Steele, the worst case scenario is significantly more damning. "Within the next 10 years, someone will learn how to factor prime numbers and our whole HTTPS system will be out the window," he said, referring to the fact that Internet security mechanisms are based on prime numbers.
Dig Deeper on Building security into the SDLC (Software development life cycle)