Application Security - An Inside Story - TCS

White Paper
Application Security –
An Inside Story
Application security has become ‘the’ requirement!
Not so long ago it used to be a mid-summer reverie.
Application owners took pride in their functionally
meticulous and performance rich applications, they
did not envisage or prepare their applications to
withstand untoward intrusive attempts. I do not
blame them, you do not think too much about the
main door lock when you are building a house. You
deal with the lock when the house is built and the
main door is ready and considering how much you
are left with in terms of finance, you choose a lock. All
through there has been an over the top optimism that
your house won’t be burgled or “why should anyone
be interested in my house!”
Web applications or owners of such applications
suffer from the same ‘main door lock’ syndrome. They
are left with no budget to provide any security for
their application and they take it for granted that no
intruder will ever target their application.
Some recent high-profile application breaches have
brought ‘application security’ to the fore again. It has
re-emerged as a requirement; it seems the house is
being built around the main door lock now! Who can
enter the house is influencing a lot design changes to
how the house is going to be built. A five year weather
prediction is being sought to make sure the place
does not run dry of water, the soil supports vegetation

and solar panels can generate enough electricity for
the house. All threats imagined and more importantly
all threats are factored into the design of the house.
Is this for real? Do we really have to spend money in
securing applications? Spending money for security
has long been considered as the same thing as
splurging money. If you have enough, you of course
do and nobody seems to have enough! Security or for
that matter application security is conveniently
postponed to yet another rosy day in spring, where
you think you will have enough to splurge on
security. Like the utopia that day never arrives or even
if it does, you have something else to splurge on.
Applications, especially the ones on the web have
long suffered this lack of attention from their owners.
The world it seems has been divided into two kinds of
species, ethical and unethical hackers. The ethical
ones are honing their skill at intrusion to stop the
unethical ones. Intrusion to random applications
remains the common objective of both the groups.
The ethical community will warn before they strike,
the unethical ones will simply strike.
Applications have many stakeholders – sponsors,
users, architectures, designers, developers, data
modelers, testers, system integrators, server
administrators and other support personnel. Who
needs to own and ensure security? When we say
security, what kind of security? Is it source-code,
database, client based front-ends? What needs to be
protected? Expectedly it’s not as simple as it seems.
2

Security runs deep and runs through (or should) all
veins of the application. Bring in a security team and
make them jell well with developers and you will have
a secured application for sure! A bit of optimism but
we will see!
Running through 200 applications last FY 2011-12 was
a gargantuan task. Without any intention of being
condescending it was actually running through other
people’s private stuff and trying to find hidden
bombs. Passing comment on what people call source
code is risky business and it touched a lot of raw
nerves and created many a frictions
3

About the Author
Srimant Acharya
4

Table of Contents
1. Introduction 6
2. Who Needs It & When? 6
3. Intricacies of Application Security Assessments 8
4. The 200 Assignment Story 10
5. The Buzz and the Hoopla! 12
6. The Future 14
5

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)
Security 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’. Security 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

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

The 200 Assignment Story
In Tata Consultancy Services Pvt. Ltd. (TCS) there
are several horizontal groups in existence,
essentially to serve the verticals. (Industry Solution
Units) Technology Excellence Group (TEG) is one
such group, which has a dedicated sub group
looking at all the niche technologies of tomorrow
and building competencies for them. Application &
Network Security (ANS) is one such group under
200 assignments were carried out in FY 11-12
with a delivery pool of 10 resources, 4
commercial licenses and two different security
labs on isolated network (non-TCS) and labs
having separate physical access for security
associates only.
the umbrella of NTDG (Niche Technology Delivery Group) which is devoted to ensuring security for
Applications and Infrastructure surrounding them.
ANS has two dedicated security labs and several commercial tools to carry out various forms of security
assessments. Majority of our assignments are on web applications in the black box mode. Here’s some
cold stats regarding doing 200 of them in the last FY 2011-12
Black-box or dynamic assessments are all about the
critical issues, everybody from application owners
to developers to security analysts are after this.
Surprisingly average no. of critical issues is only 2 to
3 out of about 12-15 issues that is reported for an
application. These issues are generally around
Cross Site Scripting (XSS), Broken Authentication and
forced browsing.
n
n
n
Avg. critical issues found per apps 2-3
10% of apps without a single critical finding
Avg. issues per app is 12-15
Two very important observations made were that
half of the applications did not seek any issue
closure verification with us. The other 50% who
followed up their closure verification had only
solved 60% of the issues reported for various
reasons.
20% of applications actually instituted a 2nd round
of assessment within the first 3 months of the first
one.
The stats may seem very economical but trust me
when I say, these took about 2 years to achieve this
speed and a different security team might portray a
different set of figures for this.
False positive removal is an important part of a
security assessment and requires some discipline
and consistency to achieve an accurate set of
n
n
n
n
20% of apps come back for a reassessment
and 60% of issues are closed by 2nd
assessment
50% of apps failed to come back for any
sort of issue verification
Avg. span of an assessment 3-7 days
60% of false positives reported and 1 day is
spent on their removal
n 1 day on report customization
10

esults. Report customization is dependent on customers but two sets of reports are provided to
developers and managers respectively.
We observed some interesting trends post
scanning of the applications. Only about 15% came
back to us until all issues were closed, they did not
care how many iterations it required. 30% required
formal remediation sessions and 10% asked for
specific solutions to issues reported.
From all categories of issues reported, 70% simply
ignored the ‘low’ category issues and did not take
any action on them.
n
n
n
Only15% of application owners ensured
100% closure of issues
30% insisted on remediation sessions &
10% sought specific technical help
70% of apps do not prioritize or fix ‘low’
category issues
The common excuse of not fixing issues were always given to be ‘ will be fixed by the time it is deployed
to production’
As expected, the top 2 issues of OWASP top 10
were in news! While most issues pertaining to XSS
were reported against 80% of apps, injection issues
it seemed were handled better with only 15% of
apps reporting such issues. Majority of scans ran
with default policy (which includes OWASP top 10
issues), the exception being 2-3% of app owners
asking for a specific or customized policy.
The 200+ assignments were possible due to
diligent resources and availability of automated
commercial tools and security labs. Support from
senior management along encouragement to go
for the unknown and unseen, also helped us to
chase down these impressive numbers.
n
n
n
n
n
n
70-80% of applications reported Cross site
scripting(XSS) issues
10-15% reported SQL injection issues
Only 2-3% app owners dictated a specific
scan policy
Total of 4 automated commercial tools and
5-6 open source tools
Two dedicated security labs
About 10-12 app security associates
We have already shifted focus and now look at
enterprise wide security issues and plan to ensure app security for 100s of applications and not just one.
Static scanning or source code review of
application is an integral part of security
assessment, however the cost and expertise
involved in carrying out such a requirement is very
complex. Commercial automated tools are three
times more expensive than dynamic scan tools.
Secured source code review has not gained
momentum and only 5% applications considered
doing a SCR after/before doing a dynamic scanning.
n
n
n
5% assessments were on source code review
Source code review tools are more
expensive
Only 5% of applications went through SCR
after Black-box
11

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. Security 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

Though all the tools were after the same set of vulnerabilities, they employed different technologies to
find them. Some were found, some were not but each tool reported lots of ‘false positives’. False positives
are essentially issues not relevant to the application it is reported against. It kept the security analyst on
tenterhooks and it created a genre of reports that were heavily tool dependent and did not match against
one another in terms of issues reported against the same application. Manual effort in unearthing
vulnerabilities began to exceed the estimation as applications owners became more and more aggressive
in pursuing vulnerability free applications.
Ensuring security for applications is not always about vulnerability scans and code reviews, it should be
treated as much proactively as it is done reactively. As the application is conceived, a security threat
landscape should be drawn and all phases of SDLC should factor in security. Where the concept of
secured SDLC has failed is in its ideology. It requires thorough understanding of the applications
architecture and its business functionality. Developers have traditionally ignored security having been
brought up on the culture of error-free functionality and adequate response time. Even when prompted
by automated tools or otherwise they are least expected to change their style of coding to accommodate
a looming threat that has not happened yet!
Project managers have harped on coding tools and aids that would prompt and persuade the developers
to fix and eliminate security loopholes creeping into their code. Many are trying to win this capital space
of development lifecycle through smarter IDEs or plug-ins but none have emerged as a clear winner. No
single tool has been able to catch an unsecured flow or approach thus rendering the whole effort to be a
‘something is better than nothing’ approach. Many a firewalls are now being supplemented with IPS/IDS
etc. trying to catch unwarranted traffic as it flies past. No doubt they have had their prized catches but
they also stop legal traffic which has been a staggering concern. Maintaining a list of false positives
around IPS/IDSes has become a humongous job requiring round the clock manning of such devices.
Web Application Firewalls are also being touted as another life saver but it suffers from the same
syndrome as well. Blocking of real and legal traffic has been a growing concern though it serves its
purpose by only concentrating on the application layer. They have been a welcome addition to the ever
evolving security potpourri to protect applications.
The Future
If there is anything that has remained consistent, it is our inability to predict the future. Security incidents
despite increased awareness will actually increase and they will be immune to the security posture of an
application. Hackers are always a step ahead of the current technology and defense mechanisms. With
increased cyber warfare and state level sponsoring of security attacks, applications are going to be
targeted now based on the country, race and business they represent and that is a frightening prospect
as applications classified as ‘not of interest to anybody’ will now be in the radar of organized hackers.
It becomes essential that the applications are armed with real-time monitoring tools and adequate
logging mechanisms so that potential attempts to break into an application can be stopped before any
potential damage in terms of loss of data, brand and money.
14

List of Abbreviations
Abbreviation/ Acronym
ANS
COE
FY
IDE
IDS
Expansion
Application & Network Security
Center of Excellence
Financial Year
Integrated Development Environment
Intrusion Detection System
IPS Intrusion Prevention System
IS
NTDG
OWASP
SDLC
TCS
TEG
Information Security
Niche Technology Delivery Group
Open Web Application Security Project
Software Development Life Cycle
Tata Consultancy Services
Technology Excellence Group
15

Contact
For more information about TCS’ consulting services, contact ntdg.scan@tcs.com
Subscribe to TCS White Papers
TCS.com RSS: http://www.tcs.com/rss_feeds/Pages/feed.aspx?f=w
Feedburner: http://feeds2.feedburner.com/tcswhitepapers
About Tata Consultancy Services (TCS)
Tata Consultancy Services is an IT services, consulting and business solutions organization that
delivers real results to global business, ensuring a level of certainty no other firm can match.
TCS offers a consulting-led, integrated portfolio of IT and IT-enabled infrastructure, engineering
TM
and assurance services. This is delivered through its unique Global Network Delivery Model ,
recognized as the benchmark of excellence in software development. A part of the Tata Group,
India’s largest industrial conglomerate, TCS has a global footprint and is listed on the National
Stock Exchange and Bombay Stock Exchange in India.
For more information, visit us at www.tcs.com
IT Services
Business Solutions
Outsourcing
All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is
correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in
any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and
other applicable laws, and could result in criminal or civil penalties. Copyright © 2013 Tata Consultancy Services Limited
TCS Design Services I M I 02 I 13