Don’t assume those third-party apps you buy are fully secure.
Despite the promise of cloud computing, companies are still buying software. And it is more cost effective to buy an application and plug it into your system than it is to develop anew. How many third-party applications has your company bought off the shelf? How secure are they? Have you conducted any actual testing?
Too many organizations are oblivious to the need for stringent security testing. Many third-party apps are purchased because they are functional and aesthetically pleasing, but how do you know that the developer has met security standards? Can you take their word for it?

Testing focuses on bugs

The developers of third-party applications will typically employ some QA, but it is invariably focused on fixing bugs. The software has to work as intended in order for them to sell it. What many companies are not aware of is the potential security risks and loopholes that can be exploited.
Whether it’s an online HR application, a website serving customers, or a financial application, security standards must be a consideration with interactive systems. Verifying security standards is absolutely vital and lifecycle management must also be taken into account to meet security compliance standards, both now and in the future.
The simple fact is that most third-party applications have not been exposed to any real security testing. The potential for session hijacking, cross-site scripting, and man-in-the-middle attacks has often not been considered. It is not necessarily a priority for the developers and, as a consequence, you can’t afford to assume that any third-party app you buy is fully secure.

Do your due diligence

This problem can be side-stepped right at the offset if you ask the right questions and insist on proof. Ensure that you investigate the potential risks and consider what the consequences could be if a security breach did occur. Don’t be afraid to ask the software vendor for test documentation. You need to ensure that penetration tests have been conducted by qualified parties and that regression testing was completed in order to confirm that any issues originally identified were actually fixed properly.
You also need to consider the same process for updates. If the developer promises various updates to your application or they work on a continuous deployment model, then each release must be tested for security, not just traditional QA bug hunting. You cannot afford to take the developer’s word on this.

What are the risks?

Ultimately the software developer may be liable for any security breach, but it depends on the nature of your agreement. In the worst case scenario your organization will face legal ramifications, especially if private information has been lost or stolen. Even if your company isn’t directly liable that won’t shield you from the negative press or the loss of customer faith.

How does this happen?

The release of software that contains security loopholes is not a deliberate attempt to pull the wool over your eyes. For many developers it is simply an oversight. The focus on third-party applications is typically usability and aesthetic because that’s what sells software. Security is an afterthought.
Perhaps your organization has an existing relationship with the software vendor or there is pressure to rush the product to market. Whatever the case, blind trust is never good trust. Make sure you ask the right questions and avoid security issues down the road. Remember you are only as secure as the weakest third-party link in the chain.

Build security testing in from the start

Developers should consider employing security QA themselves to avoid any issues down the line. This allows security issues to be considered and dealt with during the development cycle which is easier than trying to retroactively plug the holes.
It also allows them to put a badge of approval on the product and assuage any security concerns that potential customers may have. Pre-empting the trend towards greater security requirements could even provide a competitive edge in the application market.
By Michelle Drolet, founder and CEO, Towerwall
Special to BostInno.com
This article was recently published in BostInno.com