Application Security - An Inside Story - TCS
Application Security - An Inside Story - TCS
Application Security - An Inside Story - TCS
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
White Paper<br />
<strong>Application</strong> <strong>Security</strong> –<br />
<strong>An</strong> <strong>Inside</strong> <strong>Story</strong><br />
<strong>Application</strong> security has become ‘the’ requirement!<br />
Not so long ago it used to be a mid-summer reverie.<br />
<strong>Application</strong> owners took pride in their functionally<br />
meticulous and performance rich applications, they<br />
did not envisage or prepare their applications to<br />
withstand untoward intrusive attempts. I do not<br />
blame them, you do not think too much about the<br />
main door lock when you are building a house. You<br />
deal with the lock when the house is built and the<br />
main door is ready and considering how much you<br />
are left with in terms of finance, you choose a lock. All<br />
through there has been an over the top optimism that<br />
your house won’t be burgled or “why should anyone<br />
be interested in my house!”<br />
Web applications or owners of such applications<br />
suffer from the same ‘main door lock’ syndrome. They<br />
are left with no budget to provide any security for<br />
their application and they take it for granted that no<br />
intruder will ever target their application.<br />
Some recent high-profile application breaches have<br />
brought ‘application security’ to the fore again. It has<br />
re-emerged as a requirement; it seems the house is<br />
being built around the main door lock now! Who can<br />
enter the house is influencing a lot design changes to<br />
how the house is going to be built. A five year weather<br />
prediction is being sought to make sure the place<br />
does not run dry of water, the soil supports vegetation
and solar panels can generate enough electricity for<br />
the house. All threats imagined and more importantly<br />
all threats are factored into the design of the house.<br />
Is this for real? Do we really have to spend money in<br />
securing applications? Spending money for security<br />
has long been considered as the same thing as<br />
splurging money. If you have enough, you of course<br />
do and nobody seems to have enough! <strong>Security</strong> or for<br />
that matter application security is conveniently<br />
postponed to yet another rosy day in spring, where<br />
you think you will have enough to splurge on<br />
security. Like the utopia that day never arrives or even<br />
if it does, you have something else to splurge on.<br />
<strong>Application</strong>s, especially the ones on the web have<br />
long suffered this lack of attention from their owners.<br />
The world it seems has been divided into two kinds of<br />
species, ethical and unethical hackers. The ethical<br />
ones are honing their skill at intrusion to stop the<br />
unethical ones. Intrusion to random applications<br />
remains the common objective of both the groups.<br />
The ethical community will warn before they strike,<br />
the unethical ones will simply strike.<br />
<strong>Application</strong>s have many stakeholders – sponsors,<br />
users, architectures, designers, developers, data<br />
modelers, testers, system integrators, server<br />
administrators and other support personnel. Who<br />
needs to own and ensure security? When we say<br />
security, what kind of security? Is it source-code,<br />
database, client based front-ends? What needs to be<br />
protected? Expectedly it’s not as simple as it seems.<br />
2
<strong>Security</strong> runs deep and runs through (or should) all<br />
veins of the application. Bring in a security team and<br />
make them jell well with developers and you will have<br />
a secured application for sure! A bit of optimism but<br />
we will see!<br />
Running through 200 applications last FY 2011-12 was<br />
a gargantuan task. Without any intention of being<br />
condescending it was actually running through other<br />
people’s private stuff and trying to find hidden<br />
bombs. Passing comment on what people call source<br />
code is risky business and it touched a lot of raw<br />
nerves and created many a frictions<br />
3
About the Author<br />
Srimant Acharya<br />
4
Table of Contents<br />
1. Introduction 6<br />
2. Who Needs It & When? 6<br />
3. Intricacies of <strong>Application</strong> <strong>Security</strong> Assessments 8<br />
4. The 200 Assignment <strong>Story</strong> 10<br />
5. The Buzz and the Hoopla! 12<br />
6. The Future 14<br />
5
Introduction<br />
Introducing application security is a great responsibility. Let me try.<br />
For the uninitiated this is about doing ‘everything’ to reduce the chances of the application from being<br />
breached. The ‘everything’ then of course fans out to various kinds of security assessments, reactive at<br />
large though. It takes time for the application owners to realize that a major portion of the effort can be<br />
reduced through proactive measures. The realization does not dawn easily and in most cases seen as<br />
unnecessary expenditure in dealing with something which has not happened yet!<br />
Those who are aware of the hustle and bustle of application security, will always come with their own<br />
opinion of how it should be done, they will force a tool and a certain kind of report customized to their<br />
requirement and if that’s not all, will also require a certification or warranty that the application has been<br />
secured and thereby breach-proof!<br />
However from a security group’s perspective it is probably neither. I’ll come back to my favorite ‘building a<br />
house’ analogy. To secure a house which has been in existence for about 2-3 years and where the ecosystem<br />
around it is constantly changing, it is not a one-day job. You have to analyze and visualize the<br />
possible threats and then see what can be done. You have to invite pseudo robbers (i.e. ethical burglars-)<br />
and see what they have to tell you about how easy or difficult it was to break into your house. (Ah! The<br />
black-box mode) or invite another set of experts to look at the inside of your house, look at potential<br />
articles inside which could provoke a burglary. (Ah! The white box mode)<br />
Securing an application is a continuous activity and is not confined to any pre-defined set of activities, at<br />
best you are thwarting a set of rookies from attacking your application, you are never far off from being<br />
attacked by a pro who might have a specific agenda or otherwise! There is not anything full-proof so far<br />
and probably, there will never be but a current application security assessment will at least ensure that<br />
you have taken care of some of the most fundamental loopholes in your application. Looking at high<br />
application breaches in the last 5 years and the type of attacks exercised, it is worth the effort to ensure<br />
that applications go through this fundamental scanning (Ah! The black box mode again!)<br />
Who Needs it and When?<br />
Great! Finally we have arrived at the age old consumer-provider story. Let us find out who needs<br />
application security and who is providing it? Or who should provide it?<br />
There are a lot of stakeholders to an application.<br />
n<br />
n<br />
n<br />
n<br />
n<br />
Owner/Sponsor<br />
Developer<br />
Data Modeler<br />
Database administrator<br />
Server administrator<br />
6
n<br />
n<br />
n<br />
n<br />
n<br />
n<br />
n<br />
n<br />
n<br />
n<br />
Architect/Designer<br />
GUI designer<br />
Functional testers<br />
Performance testers (optional)<br />
<strong>Security</strong> testers (optional/non-existent)<br />
Network administrator/IS team<br />
Quality assurance<br />
Hosting server/deployment team<br />
Compliance team (if any)<br />
Other third party vendors (if any)<br />
So among the above who is responsible for security of the application? A consistent answer to this<br />
question is ‘Not us’. The classical SDLC does not factor in security in its testing phase, testing is implicitly<br />
known to be functional, performance is factored in only when asked for and security is ignored with over<br />
the top optimism of ‘Our application will not be attacked’. <strong>Security</strong> is passed in the name of following<br />
project or customer specific best practices on coding which in reality does encourage writing code in a<br />
manner to minimize server or other software/hardware resources but does little to encourage writing<br />
code in a secure manner. The owner or the sponsor is not necessarily worried about security unless<br />
he/she has the requisite budget, though he is accountable for any subsequent security breaches. The<br />
developer is under pressure to conform to the best practices coding standard and looks forward to<br />
having the minimum functional issues reported against his specific module or pages. All other<br />
stakeholders conveniently blame it on the developer and this ‘passing the buck’ game continues<br />
throughout the life-time of the application.<br />
So who needs security is not answered easily, however when it is needed is beginning to throw up some<br />
interesting trends. The deployment team or the hosting server team nowadays needs a security<br />
assessment for applications to be hosted on a particular server and that has got the owner of the<br />
application to commission a last minute security scan, almost always, 8-24 hours before the deployment.<br />
The owner has no time and budget to get this done, so it gets done somehow by somebody! This<br />
marginalizes the chances of the application withstanding any future attack, be it by a rookie or a pro.<br />
Let’s look at assessment options for the application owner/team.<br />
n<br />
n<br />
n<br />
n<br />
Project’s own security team<br />
The IS team<br />
Various security teams in the organization<br />
Third-party vendors from outside the organization<br />
7
Usually if this is happening at the behest of the hosting server team, which is most often the case, then<br />
they have their own list of accredited teams from whom they will accept the security assessments as<br />
valid. (However more often than not, the word of mouth is the biggest advert in bringing a lot of security<br />
assessments to a particular team) On other fronts, large industry solution units are beginning to invest in<br />
having their own security teams but that is perhaps intended to take care of security, more in a proactive<br />
manner than otherwise.<br />
In bigger organizations, there are horizontal security center of excellence teams devoted to serving a<br />
multitude of operational units. Such teams use a combination of commercial and open source tools and<br />
have experienced security analysts manning a variety of assignments. Then there are small vendors who<br />
have collaborated with bigger organizations to serve such needs. Traditionally the security industry has<br />
gone through a jostle in addressing the unsecured cauldron of applications. IT organizations have tried to<br />
come to the fore with stringent SDLCs and a fix-as-you-develop methodology. A lot of organizations are<br />
also going in for commercial automated tools to scan their applications periodically. The efficacy of such<br />
tools is yet to be established but they do achieve the basic separation of the chaff from the grain.<br />
Intricacies of <strong>Application</strong> <strong>Security</strong> Assessments<br />
Let me provide you some cold statistics from our<br />
group having performed over 200 security<br />
assessments in the last FY (2011-12). About 80% of<br />
the application owners/groups were not very clear<br />
about the objective of such an assessment, they<br />
wanted a report and wanted it in a jiffy. 75% of the<br />
applications did not come back to verify if the<br />
issues reported were actually fixed by their<br />
A security assessment at the least is expected<br />
to make the application secure! The<br />
expectation is borne out of severe lack of<br />
awareness about the application’s potential to<br />
expose/leak information. The traditional focus<br />
areas of the application still continue to be its<br />
functionality and performance.<br />
Development team: 90% of application owners did<br />
not know what constituted a security assessment. Everybody had heard of a magic tool and they all<br />
thought it could rid the application of all its security maladies. Against this background every opportunity<br />
that came our way was serviced on two fronts, one on education/training of the application owners and<br />
the other on the assessment itself.<br />
As such there is a lot of mythical expectation from a security assessment. The assessment at the least is<br />
expected to make the application secure! A big enough responsibility for all security teams around the<br />
world. The expectation is borne out of severe lack of awareness about the application’s potential to<br />
expose/leak information. The traditional focus areas of an application around functionality and<br />
performance have blinded many a developers and architects into ignoring basic safety measures around<br />
authentication and privilege to access data.<br />
In the current scenario, an ideal security assessment would be a combination of dynamic and static<br />
scanning of the application. Dynamic mode of scanning (also called black-box scanning) would scan the<br />
application while it’s running in a pseudo environment and would react to a dummy user (the automated<br />
8
tool) in a dynamic manner. Static scanning would be scanning the source code of the application using a<br />
variety of technologies including using a different set of automated commercial tools.<br />
In the dynamic mode, the application can be scanned with or without authentication to the application,<br />
though mostly it runs with authentication mode to expose maximum issues. A brief questionnaire is<br />
shared with application team to estimate the effort of assessing a particular application. The tools and the<br />
team are decided according the importance accorded to the assignment by the application team.<br />
Generally automated (commercial/open source) tools are employed and they generally take 2-40 hours<br />
depending upon the size and complexity to scan one application. Assessment policy is by default set to<br />
unearthing the OWASP top 10 issues (OWASP- Open Web <strong>Application</strong> <strong>Security</strong> Project). OWASP (a nonprofit<br />
organization) releases top 10 security issues every three years and are considered to be the most<br />
notable contributor to the initiative of making applications secure.<br />
In the static mode, the application code is reviewed with the help of automated tools (both commercial<br />
and open source) and is also targeted to unearth the OWASP top 10 issues. The static assessment mode is<br />
a more comprehensive method of security review and helps in unearthing and fixing of fundamental<br />
issues. A security expert is the ideal person in recommending the priority and frequency of the above<br />
assessments.<br />
There are other forms of security assessments too though not as popular as the ones mentioned above.<br />
Threat analysis and architecture review add substance and spice to a security assessment though the<br />
application owner is least likely to ask for the same.<br />
This is about as much that can be done till the tool churns out a report. Generally tool reports are bulky<br />
and esoteric. They report issues which may not be relevant to the application. One classic example of<br />
such a false positive was when an application reported an issue pertaining to alibaba.exe. The application<br />
team feigned their knowledge on the existence of such a “exe” and without any other apparent logic the<br />
security team declared that as a false positive. False positives are difficult to remove and are a manual<br />
process and are based on the bias and expertise of the security analyst working on a particular<br />
assignment. To remove such bias, security COEs keep a centralized repository of false positives which<br />
helps them to take consistent decisions in removal of such issues.<br />
Automated commercial tools do not always find all the issues and do not claim to do so either. The<br />
security analyst plays as important a role as the tool in getting the optimum set of issues. Many open<br />
source tools also help the analyst in addressing specific vulnerabilities. Tool reports almost always need<br />
customization and are prepared to cater to developers (technical) and to mangers/sponsors (nontechnical).<br />
Developers usually require help in remediation of issues and though general remediation is<br />
provided in the report, the security team is expected to offer specific solutions to different issues.<br />
9
The 200 Assignment <strong>Story</strong><br />
In Tata Consultancy Services Pvt. Ltd. (<strong>TCS</strong>) there<br />
are several horizontal groups in existence,<br />
essentially to serve the verticals. (Industry Solution<br />
Units) Technology Excellence Group (TEG) is one<br />
such group, which has a dedicated sub group<br />
looking at all the niche technologies of tomorrow<br />
and building competencies for them. <strong>Application</strong> &<br />
Network <strong>Security</strong> (ANS) is one such group under<br />
200 assignments were carried out in FY 11-12<br />
with a delivery pool of 10 resources, 4<br />
commercial licenses and two different security<br />
labs on isolated network (non-<strong>TCS</strong>) and labs<br />
having separate physical access for security<br />
associates only.<br />
the umbrella of NTDG (Niche Technology Delivery Group) which is devoted to ensuring security for<br />
<strong>Application</strong>s and Infrastructure surrounding them.<br />
ANS has two dedicated security labs and several commercial tools to carry out various forms of security<br />
assessments. Majority of our assignments are on web applications in the black box mode. Here’s some<br />
cold stats regarding doing 200 of them in the last FY 2011-12<br />
Black-box or dynamic assessments are all about the<br />
critical issues, everybody from application owners<br />
to developers to security analysts are after this.<br />
Surprisingly average no. of critical issues is only 2 to<br />
3 out of about 12-15 issues that is reported for an<br />
application. These issues are generally around<br />
Cross Site Scripting (XSS), Broken Authentication and<br />
forced browsing.<br />
n<br />
n<br />
n<br />
Avg. critical issues found per apps 2-3<br />
10% of apps without a single critical finding<br />
Avg. issues per app is 12-15<br />
Two very important observations made were that<br />
half of the applications did not seek any issue<br />
closure verification with us. The other 50% who<br />
followed up their closure verification had only<br />
solved 60% of the issues reported for various<br />
reasons.<br />
20% of applications actually instituted a 2nd round<br />
of assessment within the first 3 months of the first<br />
one.<br />
The stats may seem very economical but trust me<br />
when I say, these took about 2 years to achieve this<br />
speed and a different security team might portray a<br />
different set of figures for this.<br />
False positive removal is an important part of a<br />
security assessment and requires some discipline<br />
and consistency to achieve an accurate set of<br />
n<br />
n<br />
n<br />
n<br />
20% of apps come back for a reassessment<br />
and 60% of issues are closed by 2nd<br />
assessment<br />
50% of apps failed to come back for any<br />
sort of issue verification<br />
Avg. span of an assessment 3-7 days<br />
60% of false positives reported and 1 day is<br />
spent on their removal<br />
n 1 day on report customization<br />
10
esults. Report customization is dependent on customers but two sets of reports are provided to<br />
developers and managers respectively.<br />
We observed some interesting trends post<br />
scanning of the applications. Only about 15% came<br />
back to us until all issues were closed, they did not<br />
care how many iterations it required. 30% required<br />
formal remediation sessions and 10% asked for<br />
specific solutions to issues reported.<br />
From all categories of issues reported, 70% simply<br />
ignored the ‘low’ category issues and did not take<br />
any action on them.<br />
n<br />
n<br />
n<br />
Only15% of application owners ensured<br />
100% closure of issues<br />
30% insisted on remediation sessions &<br />
10% sought specific technical help<br />
70% of apps do not prioritize or fix ‘low’<br />
category issues<br />
The common excuse of not fixing issues were always given to be ‘ will be fixed by the time it is deployed<br />
to production’<br />
As expected, the top 2 issues of OWASP top 10<br />
were in news! While most issues pertaining to XSS<br />
were reported against 80% of apps, injection issues<br />
it seemed were handled better with only 15% of<br />
apps reporting such issues. Majority of scans ran<br />
with default policy (which includes OWASP top 10<br />
issues), the exception being 2-3% of app owners<br />
asking for a specific or customized policy.<br />
The 200+ assignments were possible due to<br />
diligent resources and availability of automated<br />
commercial tools and security labs. Support from<br />
senior management along encouragement to go<br />
for the unknown and unseen, also helped us to<br />
chase down these impressive numbers.<br />
n<br />
n<br />
n<br />
n<br />
n<br />
n<br />
70-80% of applications reported Cross site<br />
scripting(XSS) issues<br />
10-15% reported SQL injection issues<br />
Only 2-3% app owners dictated a specific<br />
scan policy<br />
Total of 4 automated commercial tools and<br />
5-6 open source tools<br />
Two dedicated security labs<br />
About 10-12 app security associates<br />
We have already shifted focus and now look at<br />
enterprise wide security issues and plan to ensure app security for 100s of applications and not just one.<br />
Static scanning or source code review of<br />
application is an integral part of security<br />
assessment, however the cost and expertise<br />
involved in carrying out such a requirement is very<br />
complex. Commercial automated tools are three<br />
times more expensive than dynamic scan tools.<br />
Secured source code review has not gained<br />
momentum and only 5% applications considered<br />
doing a SCR after/before doing a dynamic scanning.<br />
n<br />
n<br />
n<br />
5% assessments were on source code review<br />
Source code review tools are more<br />
expensive<br />
Only 5% of applications went through SCR<br />
after Black-box<br />
11
SCR does reveal a lot more issues but these are<br />
actually multiple instances of the same issue. False<br />
positives are less but do vary across tools used. Av.<br />
Assessment period is less but does require more<br />
manual intervention and substantial expertise in a<br />
particular programming language.<br />
n<br />
n<br />
n<br />
A6-10 critical issues per app out of a total of<br />
35-40 issues<br />
False positives are about 20%-70% on a<br />
range of tools<br />
Avg. assessment period is 2-4 days<br />
The issues in the mode scanning are more or less<br />
same. However some typical issues are not<br />
reported as they can only be exposed in active<br />
(dynamic) mode of scan. There is not any magic<br />
formula to decide as if this precede or succeed a<br />
black-box scan and is usually decided best by a<br />
security analyst.<br />
n<br />
n<br />
XSS & Injection also dominate the issues<br />
found<br />
Issues pertaining to URL manipulation<br />
session are difficult to find(by tools)<br />
The Buzz and the Hoopla!<br />
The buzz and hoopla is created by some high-profile<br />
security incidents with best known enterprises. The<br />
Every organization wanted to scan all their<br />
incidents, if not anything else, have come as a major<br />
applications in the first month itself! Every<br />
advert for the security industry or vendors<br />
major security incident would create this<br />
providing security solutions. All leading research<br />
frenzy. Unfortunately security incidents<br />
analyst firms have predicted increased spending<br />
involving major organizations are on the rise!<br />
and increased focus on security, more so on<br />
application security. However it remains to be seen if<br />
the buzz can withstand the stark reality of how enterprises function and operate with respect to security.<br />
Apparently the security breaches hurt the enterprises severely at different levels. It cripples their finance<br />
and puts a question mark against their brand value. It’s not easy to defend a security attack nor is it any<br />
easier to recover from one. <strong>Security</strong> incidents are often around poor ‘best practices’ and a laxity in terms<br />
responsibility and accountability. Hardening your firewalls, servers and applications post to an attack is<br />
like bolting the gate after the horse has left.<br />
Let’s look at some interesting case studies from our own experience of dealing with such incidents.<br />
Incident 1: Site defaced. Hacker had left behind a message!<br />
Post-incident paranoia: Attempt to back up the site is unsuccessful, important forensic imprints are<br />
compromised in the process, logs have not got the whole story; finally handed over to cyber crime<br />
investigators, all breached instances are seized for further investigation. Our security team was contacted<br />
to help!<br />
12
Our investigation: Our preliminary request to have all original logs was stalled due to the unavailability<br />
of production instances. We suggested a vulnerability assessment of the backed up version hoping to<br />
find some glaring loopholes. A black box assessment on the replica application did not reveal much. We<br />
then targeted the upload functionality suspecting that to be the major offender through which the<br />
hacker might have uploaded something. We did find certain laxities in the uploading functionality; it did<br />
not have a maximum upload limit, it did not limit the type of files that could be uploaded and moreover it<br />
duly provided the path of upload when it failed to do so. For the hacker guessing the landing page of a<br />
site is not very difficult and one such file was put in every conceivable folder in the application directory.<br />
The pattern suggested that it was a blind attack and in all probability an automated script was used.<br />
Incident 2: Database cleaned up. Database log wiped clean.<br />
Post-incident paranoia: Heavily suspected to be an insider job; all database administrators are stopped<br />
from attending to production instances.<br />
Our investigation: It was revealed that the information security policy was very weak and best practices<br />
were non-existent or were flouted openly. It was a case of an unfortunate accident where one DBA<br />
accidentally deleted a table of records and then panicked enough to erase the log records. Since the<br />
databases were not backed up real-time and there was no proper induction it became a major incidence<br />
and the company providing DB support lost their contract.<br />
Incident 3: Major web site hacked. Personal information put on blogs.<br />
Post-incident paranoia: Major policy change. Sudden keenness to invest in security. All applications to<br />
be scanned in a month!!! Plans are afoot to form a security COE.<br />
Our investigation: Subsequently it emerges that one of the so called ‘non-sensitive’ database was hacked.<br />
The DB contained personal details of employees and their family members who participated in the<br />
organization’s internal fun events. The database was not accorded the usual rights that another sensitive<br />
DB would have enjoyed in terms of back-up, archival or encryption, the data it contained was treated as<br />
informal and was lying stale in a DB. The hacker(s) used simple SQL injection queries to steal data and<br />
later put it in their personal blogs as prized possessions.<br />
A lot of buzz happened due to these incidents and there was a sudden increase in the frequency of<br />
applications being lined up for scanning, it was like an epidemic had broken out and there was a long<br />
queue for vaccination shots. Organizations suddenly discovered hidden funds and ridiculous deadlines to<br />
make their applications secure. Every organization wanted to scan all their applications in the first month<br />
itself. Each one of them wanted to know what was wrong and how soon they could fix it. The scanning<br />
factories around the world went into a tailspin unable to cater to this mad rush. Some common sense<br />
began to prevail as soon as it was realized that a mere vulnerability scan was not going to make the<br />
application secure, instead there would have to be long term measures combined with a sustained<br />
campaign on application security that would solve this malady.<br />
What compounded the problem was the availability of automated commercial tools with the promise<br />
that all or almost all vulnerabilities can be found out, thereby making the application breach-proof. The<br />
original intent of these tools was lost in this buzz around the sudden necessity of application security.<br />
13
Though all the tools were after the same set of vulnerabilities, they employed different technologies to<br />
find them. Some were found, some were not but each tool reported lots of ‘false positives’. False positives<br />
are essentially issues not relevant to the application it is reported against. It kept the security analyst on<br />
tenterhooks and it created a genre of reports that were heavily tool dependent and did not match against<br />
one another in terms of issues reported against the same application. Manual effort in unearthing<br />
vulnerabilities began to exceed the estimation as applications owners became more and more aggressive<br />
in pursuing vulnerability free applications.<br />
Ensuring security for applications is not always about vulnerability scans and code reviews, it should be<br />
treated as much proactively as it is done reactively. As the application is conceived, a security threat<br />
landscape should be drawn and all phases of SDLC should factor in security. Where the concept of<br />
secured SDLC has failed is in its ideology. It requires thorough understanding of the applications<br />
architecture and its business functionality. Developers have traditionally ignored security having been<br />
brought up on the culture of error-free functionality and adequate response time. Even when prompted<br />
by automated tools or otherwise they are least expected to change their style of coding to accommodate<br />
a looming threat that has not happened yet!<br />
Project managers have harped on coding tools and aids that would prompt and persuade the developers<br />
to fix and eliminate security loopholes creeping into their code. Many are trying to win this capital space<br />
of development lifecycle through smarter IDEs or plug-ins but none have emerged as a clear winner. No<br />
single tool has been able to catch an unsecured flow or approach thus rendering the whole effort to be a<br />
‘something is better than nothing’ approach. Many a firewalls are now being supplemented with IPS/IDS<br />
etc. trying to catch unwarranted traffic as it flies past. No doubt they have had their prized catches but<br />
they also stop legal traffic which has been a staggering concern. Maintaining a list of false positives<br />
around IPS/IDSes has become a humongous job requiring round the clock manning of such devices.<br />
Web <strong>Application</strong> Firewalls are also being touted as another life saver but it suffers from the same<br />
syndrome as well. Blocking of real and legal traffic has been a growing concern though it serves its<br />
purpose by only concentrating on the application layer. They have been a welcome addition to the ever<br />
evolving security potpourri to protect applications.<br />
The Future<br />
If there is anything that has remained consistent, it is our inability to predict the future. <strong>Security</strong> incidents<br />
despite increased awareness will actually increase and they will be immune to the security posture of an<br />
application. Hackers are always a step ahead of the current technology and defense mechanisms. With<br />
increased cyber warfare and state level sponsoring of security attacks, applications are going to be<br />
targeted now based on the country, race and business they represent and that is a frightening prospect<br />
as applications classified as ‘not of interest to anybody’ will now be in the radar of organized hackers.<br />
It becomes essential that the applications are armed with real-time monitoring tools and adequate<br />
logging mechanisms so that potential attempts to break into an application can be stopped before any<br />
potential damage in terms of loss of data, brand and money.<br />
14
List of Abbreviations<br />
Abbreviation/ Acronym<br />
ANS<br />
COE<br />
FY<br />
IDE<br />
IDS<br />
Expansion<br />
<strong>Application</strong> & Network <strong>Security</strong><br />
Center of Excellence<br />
Financial Year<br />
Integrated Development Environment<br />
Intrusion Detection System<br />
IPS Intrusion Prevention System<br />
IS<br />
NTDG<br />
OWASP<br />
SDLC<br />
<strong>TCS</strong><br />
TEG<br />
Information <strong>Security</strong><br />
Niche Technology Delivery Group<br />
Open Web <strong>Application</strong> <strong>Security</strong> Project<br />
Software Development Life Cycle<br />
Tata Consultancy Services<br />
Technology Excellence Group<br />
15
Contact<br />
For more information about <strong>TCS</strong>’ consulting services, contact ntdg.scan@tcs.com<br />
Subscribe to <strong>TCS</strong> White Papers<br />
<strong>TCS</strong>.com RSS: http://www.tcs.com/rss_feeds/Pages/feed.aspx?f=w<br />
Feedburner: http://feeds2.feedburner.com/tcswhitepapers<br />
About Tata Consultancy Services (<strong>TCS</strong>)<br />
Tata Consultancy Services is an IT services, consulting and business solutions organization that<br />
delivers real results to global business, ensuring a level of certainty no other firm can match.<br />
<strong>TCS</strong> offers a consulting-led, integrated portfolio of IT and IT-enabled infrastructure, engineering<br />
TM<br />
and assurance services. This is delivered through its unique Global Network Delivery Model ,<br />
recognized as the benchmark of excellence in software development. A part of the Tata Group,<br />
India’s largest industrial conglomerate, <strong>TCS</strong> has a global footprint and is listed on the National<br />
Stock Exchange and Bombay Stock Exchange in India.<br />
For more information, visit us at www.tcs.com<br />
IT Services<br />
Business Solutions<br />
Outsourcing<br />
All content / information present here is the exclusive property of Tata Consultancy Services Limited (<strong>TCS</strong>). The content / information contained here is<br />
correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in<br />
any form without prior written permission from <strong>TCS</strong>. Unauthorized use of the content / information appearing here may violate copyright, trademark and<br />
other applicable laws, and could result in criminal or civil penalties. Copyright © 2013 Tata Consultancy Services Limited<br />
<strong>TCS</strong> Design Services I M I 02 I 13