By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The main point I'll make is that it's not enough to protect the perimeter. Firewalls are becoming less effective because enterprises are using a growing number of applications. Those applications are becoming so integrated in financial institutions and other companies. Many are built using complicated frameworks. When something complicated is implemented, problems can occur later. My concern is that there is so much integration using complex tools that it's diluting the effectiveness of the firewalls. Give an example of how this becomes a problem.
In Finland, if a company wants to fetch credit card invoices electronically for accounting purposes, it's fetched using a .NET-based protocol. Every major enterprise in the country is supposed to use that protocol. .NET [and] Java-based frameworks are the main ones used to integrate. If there was a virus using .NET to spread -- using a bug in the framework -- it could spread to credit card company servers and servers of enterprises all over the country.
Yes. Application attacks are a growing trend. My real concern is that this integration of applications, combined with the potential for fast-spreading viruses, could cause major problems, something that would be truly upsetting to society. What's the answer?
We must be more careful in what we integrate and how we design the protocols. We must hold back on integration and leave gaps between systems. It would only take one very bad thing to be exploited and it'll be years before we fully recover. We need to learn to hold back a bit. We can also build defenses in-depth so if it's possible for something to get inside, we can defend against the attack. You need internal boundaries so if something comes through integrated avenues, its reach is still limited and there are multiple lines of defense.
Whatever is done must be done automatically. You can't shut everything down. So whatever you do, plan it out in advance. Don't have things you don't need running. As a general rule, don't have all the applications and protocols running all the time. Just have the things you really need. It's very critical to protect the database passwords as well as the data transferred between database server and application server. Multiple defenses and comprehensive backup recovery plans are a must. How does user behavior factor into all this?
It's important to educate users on how social engineering works and what the threats are, such as automated attack systems like worms. They've become quite sophisticated. But it's not realistic to educate the user on the deeper aspects of security. When all is said and done, protection must be built into the back-end systems. Something must be built into the infrastructure -- encryption, authentications. Mostly, it must be invisible to the users.
The protocol has been quite stable. Many cryptographers have gone through it and analyzed it. I don't necessarily see the technology changing, but I see a change in how it is used. How so?
It is increasingly used to protect applications. Recent versions now make it possible to automate, so one can effectively add encryption to applications without modifying the applications. People are using SSH for things it wasn't written for, but it seems to be working well. One customer uses it to secure digital archiving. It's not so much how we develop the product to meet the need. People are figuring out ways on their own to use it in nontraditional ways to secure themselves. Based on user feedback, where has there been room for improvement?
Before, if someone asked what a drawback of SSH was, it was that it's hard to implement in large environments. Deployments would take years. We've been working on those issues with [the Tectia product line] for the last three years. SSH Tectia Manager was our answer to the changing way in which SSH is being used to deal with today's threats. You can centrally manage the Tectia environment and have audit logs, change policy and restrict users.
Originally, my goal was to make it very easy for administrators to use on a small network of machines. Now we have to make it work well within a larger organization with integrated security policies. That has been our focus.
Dig Deeper on Secure software development