You want to secure your business applications, but the attacks come from all sides. Where to start? Your application data, both at rest and in motion, is the hacker’s prime target. That’s why your infrastructure should use authentication, authorization, auditing and data security to keep content secure at runtime.
Before grappling with security measures, however, the organization should ask three simple questions, according to Rob Straight, senior manager of OpenEdge Product Management for Progress in Bedford, Mass. A 12-year Progress veteran, Straight’s focus on application servers, integration, mobile technology and business process management gives him insight into the holistic nature of enterprise application security.
How can enterprises best tackle application security? What’s the context?
Straight: Things are changing rapidly. Think about the 1980s and 1990s: You had monolithic apps and there the Internet was just evolving. Now everything is wide open, and it’s the Wild West. People are aware of vulnerabilities, whether it’s credit card number theft, or WikiLeaks and e-mails as recently seen with the political impact here in the U.S.
There are also many regulations around security, whether it’s HIPAA for healthcare privacy or the European data protection directive requirements. The question is, fundamentally, what are you trying to protect? Sometimes it’s obvious, like credit card information. But if it’s your manufacturing resource planning, what data is sensitive? Is it proprietary processes or pricing that you wouldn’t want the competition to know about?
There are vulnerabilities and intrusions like cross-site scripting that we’ve known about for 15 years, and yet applications still go unprotected. That implies that you need to work with companies that have that expertise.
In other words, get a second opinion.
No one organization is typically going to be able to do it all themselves. For example, you may want to do a security audit on your own software. More likely than not, you don’t have the full expertise for that. You should be comfortable hiring an expert so you can do three things: know what you don’t know, determine what you’re trying to protect, and get the help that you need.
Shouldn’t you simply protect everything?
There are situations where if your system is brought down by an attack, it’s not that big of a problem. You go to backup and say, “We have a recovery plan and the financial impact will be minimal.” On the other end of the spectrum, it could be that for every 10 minutes your retail site is down it will cost you US$1 million in lost revenue. If you are attacked, how will you keep running? Once you have a grip on what you’re trying to accomplish, you can determine what to do and how much to invest in protecting assets—and calculate the return on investment.
What about the performance costs of, say, encrypting over the wire with SSL?
Performance is secondary, in my mind. Once you start applying technologies to meet your particular security requirements, performance can be a factor, but you shouldn’t stress about performance hits. Technology will advance to offset it, and at least you’ll be protected. Compared to the cost of being attacked, taking a 5% performance hit doesn’t seem so bad.
Major security breaches make the nightly news. How often are you dealing with a customer who’s facing a nightmare security flaw?
I’m not aware of any of our customers being totally blown out of the water by a security flaw. It’s more likely that the people who need to take it seriously—in vertical markets like financial, medical, retail—are already doing it. There are instances where these customers may find vulnerabilities during routine audits and work to address them in their application and supporting infrastructure. It’s always a partnership with your infrastructure provider. In the case of Progress, the customer might be looking for the ability to encrypt data on disk, or to authenticate a user and then create a secure token. Once the person has been authenticated and authorized, it might need to employ a security token server and create a token that’s passed around. It might be supporting SSL/TLS communication over the wire. These are technologies that you would not invent yourself, but would instead rely on from your infrastructure provider.
In a recent white paper, Progress showed a timeline of security features added to each Progress OpenEdge release. What does that evolution reveal about security?
We’ve been offering security technology for a long time, based on risks that have escalated over the years.
When we offered SetuserId in OpenEdge 3.0, that was the mid-1980s when client-server was just taking off, and development environments needed to support identifying users. As computing became distributed in the later 1990s, there was a need to secure data transmissions via SSL, and to offer data encryption for data at rest.
Fast forward to OpenEdge 10.1 in early 2006. We added client-principal a decade ago to enable developers to seal login credentials. We were responding to the need in our developer community to create more secure apps. The main purpose was, once a user has been authenticated, how do you inform various components of the system? A client-principal is a handle-based sealed object that functions as a time-sensitive security token holding a user’s login information.
Transparent Data Encryption (TDE) followed a few years later in OpenEdge 10.2B, where your data at rest could be secured without requiring any coding changes.
Version 11.2 came around early 2013, and we formalized the use of Spring Security. We were not going to reinvent the wheel, so we went with open-source Spring Security, which is a Java framework for enterprise application security. It’s fully featured, well tested and stable. Our next-generation app server, Progress Application Server for OpenEdge, is using Apache Tomcat, which comes bundled with Spring.
Finally, with our upcoming release OpenEdge 11.7, we’re offering OpenEdge Authentication Gateway. It’s an STS, or security token service, which applications can use to authenticate users and issue security tokens. It prevents rogue clients from going around the authentication and trying to access the database or other application components directly.
Is there any other piece of application-level security that enterprises should consider?
Another piece that comes into play is auditing. The audit log is immutable. If you need to come back and determine who accessed or changed something, you have the audit trail. Non-repudiation is key.
Data-at-rest defenses are often lowest on the totem pole of security technology investments. How do you change that?
There are known, obvious things people want to do for protection, such as having a firewall and encrypting data they’re communicating. Data at rest tends to fall farther down the priority list, but that’s an oversight. If you have data sitting on disk or you’re reading it into memory, there are techniques to do that safely. It’s something that should be built into the infrastructure.
And how do you combat the problem of using a $10 lock on a $1 million product, as one of your colleagues called it?
When we deploy into production, the app defaults to the highest security levels. It reminds me of how voluntary 401k retirement savings programs work in the U.S. There was a study finding that if you hire a new employee and automatically sign them up for savings and then ask them to confirm it, more of them do it. It’s that mental hurdle: When the default is to save, they save.
By defaulting to essentially “no access,” we encourage our developers to deal with access and security when they deploy their apps. It forces them to think about it, as opposed to, “I can install this even though I don’t know how secure it is, and hope for the best.”
People are definitely thinking more about security. The next big hurdle is to ingrain this into the development process. Sophisticated organizations are architecting for security from day one. If security is an afterthought, it will come back to bite you if you try to retrofit.
To learn more about protecting Progress OpenEdge applications, visit www.progress.com/openedge-security.
