How to plug online gaps
- Posted:
- 15:08 09 Jun 2004
- Topics:
- Security | Internet Security
Protecting online assets is essential for any business wanting to benefit from its investment in the internet. This means securing brochure-ware and the corporate image as much as the e-shop and information store.
Consider the implications for a corporate website which is attacked and defaced. The organisation involved may not suffer any direct financial loss as a result but what about potential clients and customers? The company's management has demonstrated its failure to apply due diligence in protecting its assets.
Product security is rarely a priority and is often misunderstood. In the case of shared hosting environments, if one website contains an application vulnerability, such as SQL Injection, this could result in denial of service or defacements against other sites within the same environment.
ADVERTISEMENT
It is often assumed that web-based risks can be secured at the perimeter using the firewall or attempted exploits identified using the intrusion detection system. This is true of many attacks on the infrastructure which hosts the product, but wholly untrue of the attacks mounted directly against the product code. SQL Injection attacks are possible as a result of user input from a website not being validated or through poor coding practices.
All of the 10 most common vulnerabilities identified by the Open Web Application Security Project result from poor coding practice.
A variety of means are available to protect against application-level vulnerabilities:
Maintain developer training and awareness and use resources, such as Owasp, for standards references
Use encryption to protect confidential data while it is in transit
Carry out product vulnerability testing to find the holes before the bad guys do
Install application firewalls behind the perimeter defences to filter application-level attacks based on pre-defined rule-sets. The code holes remain but the bad guys cannot get to them
Use XML firewalls to secure web services.
It is also up to the business to identify product security as an issue. Both technical and business managers need to see not only revenue-generating products as requiring protection, but also the non-revenue sites which project the image of the company.
Finally, it is important not to forget that product code developed by your third-party suppliers should be subjected to the same standards as code produced in-house. My experience of vulnerability testing has identified third-party code as being a significant area of risk.
Stuart King is senior security consultant for the Reed Elsevier Group
www.owasp.org
