Application Security - An Inside Story - TCS

More documents

Recommendations

Info

Usually if this is happening at the behest of the hosting server team, which is most often the case, then they have their own list of accredited teams from whom they will accept the security assessments as valid. (However more often than not, the word of mouth is the biggest advert in bringing a lot of security assessments to a particular team) On other fronts, large industry solution units are beginning to invest in having their own security teams but that is perhaps intended to take care of security, more in a proactive manner than otherwise. In bigger organizations, there are horizontal security center of excellence teams devoted to serving a multitude of operational units. Such teams use a combination of commercial and open source tools and have experienced security analysts manning a variety of assignments. Then there are small vendors who have collaborated with bigger organizations to serve such needs. Traditionally the security industry has gone through a jostle in addressing the unsecured cauldron of applications. IT organizations have tried to come to the fore with stringent SDLCs and a fix-as-you-develop methodology. A lot of organizations are also going in for commercial automated tools to scan their applications periodically. The efficacy of such tools is yet to be established but they do achieve the basic separation of the chaff from the grain. Intricacies of Application Security Assessments Let me provide you some cold statistics from our group having performed over 200 security assessments in the last FY (2011-12). About 80% of the application owners/groups were not very clear about the objective of such an assessment, they wanted a report and wanted it in a jiffy. 75% of the applications did not come back to verify if the issues reported were actually fixed by their A security assessment at the least is expected to make the application secure! The expectation is borne out of severe lack of awareness about the application’s potential to expose/leak information. The traditional focus areas of the application still continue to be its functionality and performance. Development team: 90% of application owners did not know what constituted a security assessment. Everybody had heard of a magic tool and they all thought it could rid the application of all its security maladies. Against this background every opportunity that came our way was serviced on two fronts, one on education/training of the application owners and the other on the assessment itself. As such there is a lot of mythical expectation from a security assessment. The assessment at the least is expected to make the application secure! A big enough responsibility for all security teams around the world. The expectation is borne out of severe lack of awareness about the application’s potential to expose/leak information. The traditional focus areas of an application around functionality and performance have blinded many a developers and architects into ignoring basic safety measures around authentication and privilege to access data. In the current scenario, an ideal security assessment would be a combination of dynamic and static scanning of the application. Dynamic mode of scanning (also called black-box scanning) would scan the application while it’s running in a pseudo environment and would react to a dummy user (the automated 8
tool) in a dynamic manner. Static scanning would be scanning the source code of the application using a variety of technologies including using a different set of automated commercial tools. In the dynamic mode, the application can be scanned with or without authentication to the application, though mostly it runs with authentication mode to expose maximum issues. A brief questionnaire is shared with application team to estimate the effort of assessing a particular application. The tools and the team are decided according the importance accorded to the assignment by the application team. Generally automated (commercial/open source) tools are employed and they generally take 2-40 hours depending upon the size and complexity to scan one application. Assessment policy is by default set to unearthing the OWASP top 10 issues (OWASP- Open Web Application Security Project). OWASP (a nonprofit organization) releases top 10 security issues every three years and are considered to be the most notable contributor to the initiative of making applications secure. In the static mode, the application code is reviewed with the help of automated tools (both commercial and open source) and is also targeted to unearth the OWASP top 10 issues. The static assessment mode is a more comprehensive method of security review and helps in unearthing and fixing of fundamental issues. A security expert is the ideal person in recommending the priority and frequency of the above assessments. There are other forms of security assessments too though not as popular as the ones mentioned above. Threat analysis and architecture review add substance and spice to a security assessment though the application owner is least likely to ask for the same. This is about as much that can be done till the tool churns out a report. Generally tool reports are bulky and esoteric. They report issues which may not be relevant to the application. One classic example of such a false positive was when an application reported an issue pertaining to alibaba.exe. The application team feigned their knowledge on the existence of such a “exe” and without any other apparent logic the security team declared that as a false positive. False positives are difficult to remove and are a manual process and are based on the bias and expertise of the security analyst working on a particular assignment. To remove such bias, security COEs keep a centralized repository of false positives which helps them to take consistent decisions in removal of such issues. Automated commercial tools do not always find all the issues and do not claim to do so either. The security analyst plays as important a role as the tool in getting the optimum set of issues. Many open source tools also help the analyst in addressing specific vulnerabilities. Tool reports almost always need customization and are prepared to cater to developers (technical) and to mangers/sponsors (nontechnical). Developers usually require help in remediation of issues and though general remediation is provided in the report, the security team is expected to offer specific solutions to different issues. 9
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: n n n n n n n n n n Architect/Desig
Page 11 and 12: esults. Report customization is dep
Page 13 and 14: Our investigation: Our preliminary
Page 15 and 16: List of Abbreviations Abbreviation/

Application Security - An Inside Story - TCS

Create successful ePaper yourself

Delete template?

Save as template?