Application Security - An Inside Story - TCS

More documents

Recommendations

Info

Introduction Introducing application security is a great responsibility. Let me try. For the uninitiated this is about doing ‘everything’ to reduce the chances of the application from being breached. The ‘everything’ then of course fans out to various kinds of security assessments, reactive at large though. It takes time for the application owners to realize that a major portion of the effort can be reduced through proactive measures. The realization does not dawn easily and in most cases seen as unnecessary expenditure in dealing with something which has not happened yet! Those who are aware of the hustle and bustle of application security, will always come with their own opinion of how it should be done, they will force a tool and a certain kind of report customized to their requirement and if that’s not all, will also require a certification or warranty that the application has been secured and thereby breach-proof! However from a security group’s perspective it is probably neither. I’ll come back to my favorite ‘building a house’ analogy. To secure a house which has been in existence for about 2-3 years and where the ecosystem around it is constantly changing, it is not a one-day job. You have to analyze and visualize the possible threats and then see what can be done. You have to invite pseudo robbers (i.e. ethical burglars-) and see what they have to tell you about how easy or difficult it was to break into your house. (Ah! The black-box mode) or invite another set of experts to look at the inside of your house, look at potential articles inside which could provoke a burglary. (Ah! The white box mode) Securing an application is a continuous activity and is not confined to any pre-defined set of activities, at best you are thwarting a set of rookies from attacking your application, you are never far off from being attacked by a pro who might have a specific agenda or otherwise! There is not anything full-proof so far and probably, there will never be but a current application security assessment will at least ensure that you have taken care of some of the most fundamental loopholes in your application. Looking at high application breaches in the last 5 years and the type of attacks exercised, it is worth the effort to ensure that applications go through this fundamental scanning (Ah! The black box mode again!) Who Needs it and When? Great! Finally we have arrived at the age old consumer-provider story. Let us find out who needs application security and who is providing it? Or who should provide it? There are a lot of stakeholders to an application. n n n n n Owner/Sponsor Developer Data Modeler Database administrator Server administrator 6
n n n n n n n n n n Architect/Designer GUI designer Functional testers Performance testers (optional) <strong>Security</strong> testers (optional/non-existent) Network administrator/IS team Quality assurance Hosting server/deployment team Compliance team (if any) Other third party vendors (if any) So among the above who is responsible for security of the application? A consistent answer to this question is ‘Not us’. The classical SDLC does not factor in security in its testing phase, testing is implicitly known to be functional, performance is factored in only when asked for and security is ignored with over the top optimism of ‘Our application will not be attacked’. <strong>Security</strong> is passed in the name of following project or customer specific best practices on coding which in reality does encourage writing code in a manner to minimize server or other software/hardware resources but does little to encourage writing code in a secure manner. The owner or the sponsor is not necessarily worried about security unless he/she has the requisite budget, though he is accountable for any subsequent security breaches. The developer is under pressure to conform to the best practices coding standard and looks forward to having the minimum functional issues reported against his specific module or pages. All other stakeholders conveniently blame it on the developer and this ‘passing the buck’ game continues throughout the life-time of the application. So who needs security is not answered easily, however when it is needed is beginning to throw up some interesting trends. The deployment team or the hosting server team nowadays needs a security assessment for applications to be hosted on a particular server and that has got the owner of the application to commission a last minute security scan, almost always, 8-24 hours before the deployment. The owner has no time and budget to get this done, so it gets done somehow by somebody! This marginalizes the chances of the application withstanding any future attack, be it by a rookie or a pro. Let’s look at assessment options for the application owner/team. n n n n Project’s own security team The IS team Various security teams in the organization Third-party vendors from outside the organization 7
Page 1 and 2: White Paper Application Security -
Page 3 and 4: Security runs deep and runs through
Page 5: Table of Contents 1. Introduction 6
Page 9 and 10: tool) in a dynamic manner. Static s
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?