Secure, Test, Go
Application level security is emerging as the next frontier
on the battlefront of securing the enterprise, says Varad G Varadarajan,
Head, Digital Security Practice, Cognizant Technology Solutions
Varad G Varadarajan
Blackhat hackers are now attacking applications directly,
because it is easier than launching attacks through the network layer. In other
words, they slip in undetected through the network, using legitimate packets
and launch their attacks on the vulnerabilities found deep inside the applications.
Poor quality of software is the key reason for such attacks. The US National
Institute of Standards and Technology reports that 93 percent of the reported
vulnerabilities are software-related.
The patch later approach
One reason for this is the fact that most developers do not code with security
in mind. They spend most of their time in addressing functional, performance
or usability requirements.
Software and systems integrators are always under deadline pressures and they
deal with security in their applications in one of the two ways:
- Do not worry about security build and release first;
- Build first; test for security at the end.
This is an excellent situation for a blackhat, because there
are hundreds of poorly written applications that do not adequately protect critical
data. With the increasing Web-enablement of such applications, data is exposed
to such attacks.
Secure from the start
However, there is a shift taking place in the build firstsecure later
process. First, there has been a steady increase in the number and severity
of security breaches.
New regulations (SOX, GLBA, HIPAA, and California SB 1386#) and increased customer
awareness have made companies proactive instead of reactive. The realisation
that fixing security bugs at the end is far more expensive than fixing them
at an early stage is also becoming common now.
The earlier security vulnerabilities are found in the software cycle, the easier
it is to fix them. A security bug that is found at the end of the development
or testing cycle may necessitate fundamental changes to the architecture or
design. Even later, one needs to address issues such as testing the fix, deploying
the patch or new release, ensuring backward compatibility with older releases,
documentation, end-user training and integration with other applications.
Testing the application post-development has to be exhaustive. Remember, that
a blackhat hacker needs just one bug to exploit. Gartner reports that the estimated
cost of fixing security vulnerabilities pre-deployment is less than two percent
of the cost to fix the same vulnerability once the system has been deployed.
Thus, the case is strong for development teams to incorporate security at an
early stage in the design process.
Companies are trying to approach this in a structured way, by incorporating
security at every stage of the software development lifecycle (SDLC). Software
development teams have found that it helps to think of this as a process change
right from the beginning, rather than introduce this on-demand at different
stages of an engagement.
Adopting a structured approach involves the creation of best practices, guidelines
and checklists. Various tools are incorporated into the development environment
or at the testing phase of the engagement. Developers are trained to code with
security in mind. A well engineered application builds adequate defences inside
itself, making no assumptions whatsoever about the defences from the network,
firewalls and intrusion detection tools.
The illustration on the adjacent page shows how companies are overlaying Secure
Coding initiatives over a standard engagement cycle.
List security objectives
The core tenets of every application are confidentiality, integrity and availability.
The objectives must answer the following:
- What data is being protected by the application?
- How is the application ensuring that such data will not
- How is the application protected against denial of service
Security design guidelines
Design guidelines are usually documents that highlight best practices, design
patterns and principles. Sometimes, these guidelines will vary depending on
the specific policies and processes of customers.
Security architecture and design
This is a comprehensive application review from the security angle. It examines
the approach taken at each tier of the application, as well as examines deployment
At the design stage, security architects need to take a hard look at the design
from a security perspective. Often, this requires thinking like a blackhat hacker
to see how vulnerabilities can be exploited. For example, If an attacker wants
to crack the backend database, what would he need to do? Can the channel be
spoofed if two components are involved in communication? Is the transmission
secure when data is sent across the Internet?
Checklists are used at various stages of this process.
- During the Requirements Gathering phase, to list general
security objectives and policies that may be of interest.
- During the Design Guidelines phase, to list acceptable
design patterns and principles for the platform of choice.
- During the Code Review phase, to list all the coding guidelines
for the language of choice.
Code checklists are a set of dos and donts for every language or
platform that can be used by developers. These can also form the basis for rules
that can be incorporated into tools that are used for source code review and
Every programming language comes with its own strengths and limitations. Pointer-based
languages suffer from stack and heap overflow exploits. Languages used to design
Web pages (JSP, ASP, PHP etc.) have well documented weaknesses that can be exploited
(e.g. OWASP Top 10 www.owasp.org).
During the deployment phase, to ensure that all the configuration settings,
ports etc. are taken care of in the application / package / platform.
Security code review
Normally, programmers do not code with security in mind. Hence, security flaws
can creep into the code. Security code reviews perform detailed walk-through
of code to identity common security flaws.
These are typically performed continuously throughout the development cycle,
as and when code gets checked in or a milestone is reached. Tools are available
today that can attach to the Integrated Development Environment (IDE) to perform
automated source code reviews for security.
These normally take the following approaches:
- Testing the application from the outside, to identify
vulnerabilities: Examples of this approach are penetration-testing and vulnerability
assessments (VA). Such tests are usually performed by ethical hackers.
- Testing the application from the inside: Examples of this
include running this code through automated source code analysis tools, usually
fitted as part of the IDE.
|Our customer is behind a firewall, so application is well
||Firewalls do not address application level security
|It is only a buffer overflow—not a security bug
||Buffer overflows offer a great opportunity to
launch security attacks
|Our application needs to run with administrative privileges
because it accesses critical resources
||Running as root makes it very easy for hackers
to access critical resources once they break in
|We do not have time for this. We will release security now,
patch later when security vulnerabilities are discovered
||Customers today are not very tolerant of breaches
|Our customer regularly updates anti-virus software.
They might not need this
||Anti-virus software may not protect against application level
|We use home-grown encryption techniques
||Home-grown techniques may be easily broken. Use well-tested
packages and industry-standard library functions
|We have done code review and found no security
||Identifying security bugs is not easy and it requires training
|Adding security is an inconvenience for the customer.
We will ship it with 'security turned off' and the user can add it later’
||Most applications will continue to run as shipped—theuser
will never turn security on
|We have automated scanning tools to identify
||Automated tools are not a panacea. They generate a number
of false positives that require human intervention. They also completely
miss out a few vulnerabilities (false negatives)
Security deployment review
Usually this is the Achilles heel of a project. An application could
be well-fortified under a controlled environment, but it may expose some vulnerability
during deployment based on the configuration of your underlying OS.
Deployment configuration for your application has to be reviewed
thoroughly so that weak or inappropriate configuration settings do not introduce
Tools of the trade
Application security testing approaches can be classified in the following broad
categories: testing using Penetration-Testing Tools, testing using Binary Analysis
Tools, testing using Automated Source Code Analysis Tools, and testing using
Manual Source Code Analysis.
Each approach has its pros and cons. Application VA and Penetration
tools can only be used later. Binary Analysis tools can be used only after application
Automated Source Code Analysis tools suffer from false positives. The better
ones are also more costly. However they can be integrated into the IDE. Manual
Source Code review is exhaustive and time consuming, but it can integrate well
The best option seems to be a hybrid approach, consisting of manual and automated
source code review during development. This can be followed by an Application
VA or Penetration-testing exercise before deployment to detect bugs.
The need of the hour is a thorough overhaul of the Build TestGo
lifecycle. Security needs to be embedded right from the start in software development.
Hence it may be more apt to call this Secure (Build)TestGo.