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; patch later.
• 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 first—secure 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.

Security industrialisation

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 be tampered?
• How is the application protected against denial of service attacks?

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 review

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 and infrastructure.

Threat-Modelling

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

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 do’s and don’ts 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 analysis.

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.

Security testing

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.

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 further vulnerabilities.

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

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 into SDLC.

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– Test–Go lifecycle. Security needs to be embedded right from the start in software development. Hence it may be more apt to call this Secure (Build)–Test–Go.