Plynt Penetration Testing and Code Review Blog

Why Application Owners love Security Code Reviews?

Sat, 17 Oct 2009 00:56:54 +0530

by Sachin Varghese

Transformation from SDLC to S²DLC is on!

Some of the software companies I have interacted with are now getting really serious about security. They bake security into everything, bring in security architects, build around secure technologies, hire excellent pen-testers and code reviewers etc.; the whole nine yards to transform their SDLC process to a S²DLC process.

The Cut above the Rest; Showcase Security

But the companies that really get it leverage their security initiatives and derive business benefit from it. I think salesforce.com is a sterling example. They have a website dedicated to communicate with their customers on the security of their systems and the processes and certifications they maintain. Companies that get it will leverage and market their security programs and initiatives as a sign of maturity giving prospects a confidence in their solution and even an edge in the prospects mind where most of the battles are really fought. When prospects learn that their software vendors take security more seriously that they themselves do, then confidence in the security of your offering starts residing in the customers mind.

Security Code Reviews: Rises to the Occasion

Security Code Reviews certainly fall in the category of major confidence boosters. Technically speaking they are a great way to catch accidental back doors, malicious back doors and all the vulnerabilities that an application penetration test with the added advantage that your developers now will know exactly where the defective code lies.

Everybody's Happy: Fix Code Faster for Less

Security Code Reviews makes fixing much quicker which application and business owners love. But the flip side always has been the cost of doing these comprehensive code reviews. The costs over the years have come down and today are pretty reasobale and comparable to what you would pay for an application penetration test. Certainly great news for all those application and business owners out there with PCI Compliance, due diligence questionnaires, demanding customer evaluators and aggressive sales guys to deal with.

Bottomline

Attn: Application Owners & Product Managers: Security Code Reviews are costing much less today and can get you an edge in the customers mind.

Best Practices for Protecting Banking Sites

Tue, 16 Jun 2009 10:17:04 +0530

by Roshen Chandran

Terence Cornelius, one of our senior security consultants, has written an article on "Best Practices for Protecting Banking Sites" at the Bankers Online website.

Terence provides a 14-point checklist that banks can use to quickly ensure that their public facing websites are safe.

How frequently should an Application be tested?

Wed, 22 Apr 2009 14:19:47 +0530

by Binu Thomas

We are often asked how frequently an application should be tested for security. In this post, I'd like to discuss the criteria for determining the frequency of tests.

First, let's review the benefits of doing periodic penetration tests:

New attacks are invented regularly. Jeremiah Grossman compiles a list of new attacks invented each year. He counted 70 new techniques in 2008, 83 in 2007 and 65 in 2006. That's 15-20 new attack ideas each quarter. A periodic test keeps you current on all the latest attacks too.
New features (and bugs) are added regularly If your application adds new features regularly, then any of those new features could also introduce security holes. In our periodic tests, we've noticed that new holes are added almost every time new features are added. Periodic tests are useful to spot them.
There's more focus on the residual holes This not-so-scientific graph shows the pattern of open vulnerabilities after repeated tests. This is what we've observed after our periodic tests, and suggests that developers fix tougher, residual holes after the easier ones are fixed.

Based on these observations, here're the criteria we recommend for you to determine the ideal frequency for your security tests:

Sensitivity of the data: If your application handles sensitive data like credit cards, you're a more likely target for new attacks, so test the app more frequently.
Criticality of the Application: If your application is business critical, it's better to test it more frequently and reduces your risk.
Frequency of changes: If your application adds new features or undergoes changes regularly, test it more frequently.

Most of the sensitive applications under our care are tested quarterly. The less sensitive ones are tested once in six months. The less sensitive ones with no changes are tested only annually.

Plynt wins "Tomorrow's Technology Today" Award

Tue, 21 Apr 2009 18:36:17 +0530

by Sachin Varghese

The InfoSecurity Products Guide has awarded Plynt this year's "Tomorrow's Technology Today" recognition for application security certification. Thank you to the readers and editors at InfoSecurity Products Guide.

HP WebInspect is the winner in the application security tool category.

The full list is available here.

Lessons Learnt in Managed Risk Services

Mon, 20 Apr 2009 09:57:44 +0530

by Roshen Chandran

This week Jose Varghese and Agnelo D'Souza present the lessons learnt in setting up an enterprise risk management program at the RSA Conference. Jose is the Director of Paladion/Plynt's Managed Security Services and Agnelo D'Souza is the CISO of Kotak Mahindra Bank.

We discuss what worked and what did not in the 18 months when we designed and implemented an integrated security program. If you're at the RSA Conference this week and are interested in hearing the lessons learnt from setting up this award winning program, please drop by at Orange Room 133 (GRC-301) at 8:00am on Thursday, April 23.

URLScan - First Line of Defense

Fri, 27 Mar 2009 13:00:26 +0530

by Siddharth Anbalahan

In this blog we look at how URLscan can be a useful first line of defense against attackers. We discuss the various configuration settings and how URLscan 3.0/3.1 can be used to protect against application layer attacks.

Attached with this blog are two files.
1.) URLScan.txt: Instructions to install and configure URLscan on IIS
2.) A UrlScan.ini file that can be used to protect against popular application attacks like SQL injection and Cross Site Scripting. The ini file can be used for IIS webserver hosting ASP, ASP.NET, PHP (all web applications).

Note:- The right place to fix application vulnerabilities is in the application. Using URLScan to protect against attacks should only be a stop gap measure. Moreover,URLscan does not filter HTTP POST.

So lets get started...

URLscan has been around since 2001 when Microsoft released it to protect attacks against IIS 5.0 webservers. At that time typical attacks included directory traversal, Webdav exploits etc. URLscan would work as a ISAPI filter to monitor URLs, HTTP Request headers to look for directory traversal strings like (%,\, ../ etc).

The typical URLscan filters that are configured on IIS are:

Deny access to various serverside scripts (except asp, .aspx)

Deny access to static sensitive files (.config, .log) etc.

[DenyExtensions]

.exe
.bat
.cmd
.com
.htw ; Maps to webhits.dll, part of Index Server
.ida ; Maps to idq.dll, part of Index Server
.idq ; Maps to idq.dll, part of Index Server
.htr ; Maps to ism.dll, a legacy administrative tool
.idc ; Maps to httpodbc.dll, a legacy database access tool
.shtm ; Maps to ssinc.dll, for Server Side Includes
.shtml ; Maps to ssinc.dll, for Server Side Includes
.stm ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services

; Deny various static files
.ini ; Configuration files
.log ; Log files
.pol ; Policy files
.dat ; Configuration files
.config ; Configuration files

For the above to be applied, set
UseAllowExtensions=0

[AllowVerbs] specifies the HTTP methods that are allowed. This effectively disables TRACE HTTP method and all Webdav methods

[AllowVerbs]
GET
HEAD
POST

For the above to be applied, set
UseAllowverbs=1

IIS6.0 is secure by default and the above settings come pre-configured with IIS 6.0

As IIS webservers have become secure, the focus of attacks has turned towards the applications hosted on them. Attackers are no longer restricted to specific versions of webservers.

SQL injection is one such popular attack on applications. It is simple to conduct and requires no or limited knowledge of the underlying webserver or operating system of the target system.

Clearly the best way to protect against a SQL injection attack is using parameterized sql queries and filtering inputs.

Attackers flood websites with SQL injection attacks. Even if applications are secure against SQL injection attack, such automated SQL injection attacks are invalid requests for the application. We need a way to prevent these attacks from reaching the application.

Fortunately, Microsoft has come up with URLScan 3.0/3.1, which allows web server administrators to extend the functionality of URLscan.

URLscan 3.0/3.1 now look for QueryStrings within the URL. The way we can extend the URLscan functionaility is using the [Rulelist] option. A [Rulelist] allows configuration of custom filters.

A Sample [Rulelist] configuration with custom filters to protect against SQL injection is given in the blog-

and is listed below

RuleList=SQL Injection
[SQL Injection]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Strings
ScanUrl=0 //Option to SCAN URL
ScanAllRaw=0
ScanQueryString=1
ScanHeaders= // OPTION to SCAN HTTP HEADERS, example: Cookie

[SQL Injection Strings]
--
%3b ; a semicolon
/*
@ ; also catches @@
char ; also catches nchar and varchar
alter
begin
cast
create // this will filter urls with ?action=create
cursor
declare
delete // this will filter urls with ?action=delete
drop
end
exec ; also catches execute
fetch
insert
kill
open
select
sys ; also catches sysobjects and syscolumns
table
update // this will filter urls with ?action=update

Rulelists can be used to check querystrings, HTTP Headers: Cookie, and the URL itself.

New Massachusetts Data Protection Standards, which states are next?

Thu, 05 Mar 2009 20:05:37 +0530

by Paresh Amin, CISSP

Do you conduct online credit card transactions with a Massachusetts resident? Do you collect social security or financial account numbers on a Massachusetts resident? If you answered yes to either of these questions then this law affects you. It does not matter where your company is located; once you touch Massachusetts Residents information this new law effects you.

In October 2008, the Commonwealth of Massachusetts introduced sweeping new regulations to protect the "personal information" of its residents. Unlike the data breach notifications laws enacted by most states (including Massachusetts), these regulations were not confined to situations where data is already compromised. Instead, the regulations impose a comprehensive new regime designed to prevent data breaches.

The regulations apply to any entities that handle Massachusetts residents' Social Security, credit card or financial account numbers, meaning virtually all Massachusetts businesses and many businesses outside of the Commonwealth are affected.

As of May 1, 2009 any company which stores personal information must have the needed security parameters in place. The Massachusetts Office of Consumer Affairs & Business Regulation ("OCABR") issued "Standards for Protection of Personal Information for Residents of the Commonwealth" (Regulation 201 Mass. CodeRegs 17.00). This new regulation represents one of the most far-reaching information security and related compliance requirements in the country.

Massachusetts now has the broadest data security regulations in the country. These regulations - which cover businesses inside and outside of Massachusetts - require the development and implementation of a comprehensive and detailed information security program.

Satisfying the new regulatory requirements will not simply be a question of allocating resources. It demands a dedicated and well-planned program/project-based effort.

The new law talks about many specific requirements including secure access to this type of sensitive PPI data regardless of where the data sits in system, servers and/or applications.

Here's the link to the new MA regulation (pdf).

NY has also recently put out their version of this law (Data Protection specify related to application Security), the questions that begs to be answered is how many states are next to put in place these extra data protection requirements. The bottom line is data protection continues to become a "front and center" initiatives for many states and this trend is only going to gain momentum. Business should start thinking about their own data protection controls around network, systems and application and quickly establish a baseline. Many of the steps needed to support these extra data protection requirements echo core PCI, HIPPA and other regulation requirements. This can be bad for many businesses still looking to establish compliancy to these already existing regulatory. This now just adds yet more support to get this done as quickly as possible.

OWASP Australia - Code Review Techniques

Thu, 26 Feb 2009 07:43:38 +0530

by Jaideep Jha

Siddharth and I are presenting on "Advanced Code Review Techniques" at the OWASP Australia Conference in a few hours. We share some efficient techniques to find common flaws in .Net and J2EE applications. The scripts we discuss are also available for download on our code review page.

In the next few weeks, we will analyze some of these techniques in this blog too.

State of New York takes a major step in Application Security

Tue, 20 Jan 2009 10:15:18 +0530

by Paresh Amin

The State of New York has elevated Application Security in a pioneering move. The State of New York's procurement contracts will now include language that takes application security into account. Specifically, programmers wishing to do business with New York will be required to based on newly implemented contract language to read the recently released list of the 25 most dangerous programming errors (More on this below). This effort is fully supported and sponsored by New York State Office of Cyber Security and Critical Infrastructure Coordination (CSCIS). CSCIC is responsible for leading and coordinating New York State's efforts regarding cyber security readiness, geographic information systems (GIS) and critical infrastructure preparedness. CSCIC works collaboratively with the public and private sectors to foster communication and coordination. CSCIC also coordinates closely with the NYS Office of Homeland Security (OHS).

This makes perfect sense. New York is the third largest state in population. The state serves its large populace through multiple state wide agencies through the use of internet facing web applications to get them easy access to the various state supported programs.

Web-based applications can pose significant information security risk for organizations and since the majority of them require the collection of private, personal and sensitive information (PPSI), such as Social Security numbers. Making the security of their application a key priority makes sense. Additionally, other NY state-wide agency applications support the transfer and disbursement of funds which again support the need for enhance application security and proper application-level testing. If that wasn't enough reasons most of the states agencies must also comply with multiple federal and state information security mandates, including the Federal Information Security Management Act (FISMA), the New York State Information Security Breach and Notification Act and New York State Cyber Security Policy.

In addition, CSCIS has developed a cyber academy with the state's colleges and universities to educate and train the next generation of programmers about the basics of application development security. This represents another key element in managing and more importantly avoiding application vulnerabilities/erros right at the beginning of the software development cycle.

As mentioned above the reference to the 25 most dangerous programming errors was an output generated by more than 30 U.S. and international cyber security organizations that have joined and come up with this list. The CWE/SANS Top 25 List was compiled with help from organizations and individuals including Apple, CERT, Microsoft, Oracle, Red Hat, to name a few. It is managed by The SANS Institute and Mitre, and funded by U.S. Department of Homeland Security's National Cyber Security Division and the U.S. National Security Agency, both of which also contributed to the development of the list. The hope is that by making these programming errors public, software code, and by extension the nation's cyber infrastructure, will be more secure.

CWE stands for Common Weakness Enumeration, a government-sponsored software assurance initiative. The Top 25 List consists of three categories of programming errors: Insecure Interaction Between Components (nine errors), Risky Resource Management (nine errors), and Porous Defenses (seven errors). Examples of errors in the respective categories include: CWE-20: Improper Input Validation; CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer; and CWE-285: Improper Access Control.

The hope is that the errors list will serve four major purposes:

To make software more secure for buyers by requiring that vendors certify their software is free of these top 25 errors
To incorporate awareness of these errors into software testing tools
To provide information necessary for educators to teach more secure programming techniques and
To provide a guide for employers to determine the abilities of programmers to write code free of these errors

Many of the errors on the list led to the majority of security breaches in 2008. That should not be a surprise, believe it or not most of the errors on the list are not well understood by programmers; secure coding practices are not widely taught by computer science programs; most developers are still only be requested to code of feature and functionality requirements not security requirements. Furthermore application vulnerabilities and errors are frequently not tested by organizations developing software for sale.

Hopefully the attempt made by these groups and by active participants like State of New York in leveraging this body of knowledge is further replicated across all industries and verticals for the purpose of improving the application security in order t o safeguard customer and corporate data.

New site - IT Governance Asia

Tue, 09 Dec 2008 15:27:57 +0530

by Vinod Vasudevan

Our publishers, IT Governance Publishing, has launched a new site today IT Governance Asia, targeted at the Asian markets.

Almost the entire catalog of books from IT Governance is available for electronic download at the site - including the book we wrote on Application Security in the ISO 27001 Environment. The site also features pocket guides and best practices reports from the IT Governance stable.

All the best for the new initiative!

Why App Penetration Tests take more than 2-3 days

Mon, 17 Nov 2008 12:02:51 +0530

by Roshen Chandran

Our application security tests usually take between 10-30 days. The effort depends on the size and complexity of each application. Though some small applications can be tested in 5 days, most apps take 10 days or longer.

At times, clients ask us why we can't just do it in 2-3 days with the help of a scanner.

Running a scanner is only a small part of the penetration test. A scanner is useful for finding SQL Injection and Cross Site Scripting vulnerabilities.

And those are not the most important attacks on your application.

The attacks you are most worried about are those that affect your business directly. In an online banking app, can an adversary siphon off funds? In an insurance application, can an adversary modify the terms of a user's policy? In a healthcare application, can an adversary change the prescription for a patient?

Scanners, naturally, do not understand the business context. They run generic test cases for popular attacks. They do a decent job of that, but they don't exercise your business logic.

The penetration tester dons the hat of the adversary. He studies the application and thinks through what the adversary wants to achieve. He constructs security test cases to beat the business logic - to siphon off funds, to modify the terms of a policy, to change the prescription. This requires understanding the application, constructing a threat profile, designing a test plan and then executing the test cases.

For most applications, that will take between 10-30 person days, with many of the efficiency improvements we have brought to our testing processes. A 3-day test would be a lot less thorough.

Download Link for Webinar

Mon, 17 Nov 2008 10:37:47 +0530

by Sangita Pakala

The Webex recording of the Emergency Threat Update is available for download now. (4.7 MB)

Please note you will need the Webex Playback client (3.3 MB) to view the webinar.

Emergency Threat Update: Windows Worm Breakout

Mon, 10 Nov 2008 17:09:11 +0530

by Sangita Pakala

Jose Varghese, who leads the Managed Risk Services practice at Paladion/Plynt, just completed an Emergency Threat Update Webinar to customers on the recent Windows Worm Breakout. He explains how to detect the worm, eradicate it and prevent it in the first place.

The slide deck is available here:

Emergency Threat Update Nov 10, 2008

I shall post the link to the recorded webinar as soon as I get a copy.

100% Compliant - Does not equal 100% Secure

Mon, 10 Nov 2008 08:38:36 +0530

by Paresh Amin

Don't be confused. Just because you have checked off all the boxes or answered "yes" to an online assessment questionnaire for PCI or SOX, it doesn't mean that you can hang your hat up.

You can be compliant to a regulation but still lack mature controls, policies and processes to protect your data. Compliance and security support each other. But it's risk management that helps define when and how each is fulfilled. Many companies over-emphasize compliance, without making sure the compliant environment is actually secure. For example, both Hannaford Brothers and TJX were PCI DSS compliant, but were not secure.

The good practice to meet your regulatory requirements along with a risk management program. Doing risk assessment and mitigation is also not a one-time deal. It's got to become standard practice, done multiple times a year. Also, consider technology and services that integrate risk management with compliance processes. Work towards maturing security policies. Enable them to be implemented, instead of having everyone wrapped up in preparation for the next compliance assessment.

It's tempting to argue that compliance is the only thing that gets priority when budgets are tightly controlled. But the role of good management is to meet compliance requirements and also strengthen security on the ground. Again, what may be compliant may not be secure - don't fall into that trap.

Webinar Alert: Value of Database Penetration Testing

Thu, 06 Nov 2008 16:37:29 +0530

by Sachin Varghese

An interesting listen. One of Plynt's industry peers and soon to be partner Ntirety hosted a live webinar on the "Value of Database Penetration & Vulnerability Testing" and invited Paresh Amin our US VP of Enterprise Business and Strategy to speak on this topic. As a security practitioner and a certified CISSP he was excited at the opportunity to share his experience with Ntirety's clients and prospects. As Paresh states, "There are many options open to an organization when looking for approaches to securing your databases and it can get confusing very quickly".

In today's highly sensitive information security world everyone (including the DBAs) have responsibilities in protecting their corporate and customer data from both internal and external threats.

If you are interested in learning about Database Security, please check out the webinar.

Here is the description of the webinar:

Title: The Value of Database Penetration & Vulnerability Testing

In this webinar, Paresh Amin discusses:

Why backend database testing is just as vital as front end testing
How to avoid backend database malfunctions that cause system deadlock, data corruption, poor performance, and data loss
An overview of backend database testing (functional vs. structural)
An overview of high profile database attacks in the past few years

By viewing this recorded webinar you walk away with an understanding of the overall benefits of a database vulnerability assessment and penetration test. You also learn some essential ideas to structure your own approach to database security testing.