Application Security - An Inside Story - TCS

More documents

Recommendations

Info

SCR does reveal a lot more issues but these are actually multiple instances of the same issue. False positives are less but do vary across tools used. Av. Assessment period is less but does require more manual intervention and substantial expertise in a particular programming language. n n n A6-10 critical issues per app out of a total of 35-40 issues False positives are about 20%-70% on a range of tools Avg. assessment period is 2-4 days The issues in the mode scanning are more or less same. However some typical issues are not reported as they can only be exposed in active (dynamic) mode of scan. There is not any magic formula to decide as if this precede or succeed a black-box scan and is usually decided best by a security analyst. n n XSS & Injection also dominate the issues found Issues pertaining to URL manipulation session are difficult to find(by tools) The Buzz and the Hoopla! The buzz and hoopla is created by some high-profile security incidents with best known enterprises. The Every organization wanted to scan all their incidents, if not anything else, have come as a major applications in the first month itself! Every advert for the security industry or vendors major security incident would create this providing security solutions. All leading research frenzy. Unfortunately security incidents analyst firms have predicted increased spending involving major organizations are on the rise! and increased focus on security, more so on application security. However it remains to be seen if the buzz can withstand the stark reality of how enterprises function and operate with respect to security. Apparently the security breaches hurt the enterprises severely at different levels. It cripples their finance and puts a question mark against their brand value. It’s not easy to defend a security attack nor is it any easier to recover from one. <strong>Security</strong> incidents are often around poor ‘best practices’ and a laxity in terms responsibility and accountability. Hardening your firewalls, servers and applications post to an attack is like bolting the gate after the horse has left. Let’s look at some interesting case studies from our own experience of dealing with such incidents. Incident 1: Site defaced. Hacker had left behind a message! Post-incident paranoia: Attempt to back up the site is unsuccessful, important forensic imprints are compromised in the process, logs have not got the whole story; finally handed over to cyber crime investigators, all breached instances are seized for further investigation. Our security team was contacted to help! 12
Our investigation: Our preliminary request to have all original logs was stalled due to the unavailability of production instances. We suggested a vulnerability assessment of the backed up version hoping to find some glaring loopholes. A black box assessment on the replica application did not reveal much. We then targeted the upload functionality suspecting that to be the major offender through which the hacker might have uploaded something. We did find certain laxities in the uploading functionality; it did not have a maximum upload limit, it did not limit the type of files that could be uploaded and moreover it duly provided the path of upload when it failed to do so. For the hacker guessing the landing page of a site is not very difficult and one such file was put in every conceivable folder in the application directory. The pattern suggested that it was a blind attack and in all probability an automated script was used. Incident 2: Database cleaned up. Database log wiped clean. Post-incident paranoia: Heavily suspected to be an insider job; all database administrators are stopped from attending to production instances. Our investigation: It was revealed that the information security policy was very weak and best practices were non-existent or were flouted openly. It was a case of an unfortunate accident where one DBA accidentally deleted a table of records and then panicked enough to erase the log records. Since the databases were not backed up real-time and there was no proper induction it became a major incidence and the company providing DB support lost their contract. Incident 3: Major web site hacked. Personal information put on blogs. Post-incident paranoia: Major policy change. Sudden keenness to invest in security. All applications to be scanned in a month!!! Plans are afoot to form a security COE. Our investigation: Subsequently it emerges that one of the so called ‘non-sensitive’ database was hacked. The DB contained personal details of employees and their family members who participated in the organization’s internal fun events. The database was not accorded the usual rights that another sensitive DB would have enjoyed in terms of back-up, archival or encryption, the data it contained was treated as informal and was lying stale in a DB. The hacker(s) used simple SQL injection queries to steal data and later put it in their personal blogs as prized possessions. A lot of buzz happened due to these incidents and there was a sudden increase in the frequency of applications being lined up for scanning, it was like an epidemic had broken out and there was a long queue for vaccination shots. Organizations suddenly discovered hidden funds and ridiculous deadlines to make their applications secure. Every organization wanted to scan all their applications in the first month itself. Each one of them wanted to know what was wrong and how soon they could fix it. The scanning factories around the world went into a tailspin unable to cater to this mad rush. Some common sense began to prevail as soon as it was realized that a mere vulnerability scan was not going to make the application secure, instead there would have to be long term measures combined with a sustained campaign on application security that would solve this malady. What compounded the problem was the availability of automated commercial tools with the promise that all or almost all vulnerabilities can be found out, thereby making the application breach-proof. The original intent of these tools was lost in this buzz around the sudden necessity of application security. 13
Page 1 and 2: White Paper Application Security -
Page 3 and 4: Security runs deep and runs through
Page 5 and 6: Table of Contents 1. Introduction 6
Page 7 and 8: n n n n n n n n n n Architect/Desig
Page 9 and 10: tool) in a dynamic manner. Static s
Page 11: esults. Report customization is dep
Page 15 and 16: List of Abbreviations Abbreviation/

Application Security - An Inside Story - TCS

Create successful ePaper yourself

Delete template?

Save as template?