Plynt Penetration Testing and Code Review Blog

Cross-Site Scripting Attack through SQL injection

Tue, 10 Jan 2012 03:38:38 +0530

by Atul Gaikwad

Now-a-days, application developers have become smart enough to take care of the different vulnerabilities which may affect their application. But sometimes, due to time constraints or maybe plain laziness, they fix issues only for the instances reported in an audit and do not fix them throughout the application. This would allow an attacker to craft an exploit for vulnerable instance which may cause severe damage and can also blemish the brand.

In a recent Black Box Application Security Assessment, we came across an interesting exploit which was an outcome of multiple vulnerabilities. The scenario was as follows:
The application had a 'Forgot Password' page which asked the user his/her username and upon submission of a valid username, it served the next page asking for the answer to a security question. After submitting the correct answer, an e-mail containing a link to reset the password is sent to the user.

The application was safe against SQL injection except for one instance; this was the 'Forgot Password' page. We could reach the page asking the security question for the first user entry present in the database after carrying out an SQL Injection attack on the username input field present on the 'Forgot Password' page. Breaking the security question was not an easy job and even if we could break it, the link to reset the password would be sent to the valid user's e-mail id. So, the vulnerability here was SQL Injection and though potentially lethal, it was difficult to exploit.

While testing, we found that the application was secured against Cross Site Scripting (XSS) attacks. But, after performing SQL Injection, we found that the application serves the page containing the security question with text in the format of "Dear <username>", where <username> was the value entered in the username field on the previous page. That meant the application could be vulnerable to the XSS as well. So now, SQL Injection, which seemed relatively less harmful because of the difficulty of exploit, could result in another possibly high-risk vulnerability.

When the query fragment used for SQL Injection is followed by a script, say, "<script>alert("XSS");</script>" in the username input field, an alert window pops up with the text "XSS". Thus, the application turned out to be vulnerable to XSS as well.

Now, we started thinking on how this SQL+XSS vulnerability can be scaled up further. For this, we thought of inserting an HTML code in the username input field which would get reflected on the next page and this would result in a page which would ask the victim to enter the credit card details like credit card number, CVV, Expiry date. To take advantage of the user's fear, we put the message "We have observed some suspicious activity in your account. Please provide us the necessary information to verify the same:"

But, still there is one hurdle. The application welcomes the user saying "Dear <username>'" and the <username> will also contain the SQL query fragment. A vigilant user may find this kind of message suspicious.

Now what?

The challenge was to hide the SQL query from the user. Here, the HTML comment tag () came in handy. We crafted a SQL query such that only a "Dear User" message would be displayed to the victim and the SQL query fragment would be commented out.

This means now, we are ready to steal sensitive data, in a manner similar to a 'phishing' attack, but by using the valid site.

The website, with the crafted page, is shown in the following screenshot:

There is a PHP code used at the back-end for capturing the values of the parameters sent by the victim. The attacker's e-mail ID is mentioned in the code. Hence, on clicking SUBMIT the credit card details will be sent to the attacker's e-mail ID.

This attack can have variations and the data to be stolen is up to the attacker's creativity and ingenuity.

Require Security?...Then Think Security

Thu, 05 Jan 2012 02:30:02 +0530

by Ashish Rao

So much has been written and documented about securing web applications that it should be a simple process by now. However, as it still stands, it is an overload to development teams across the globe. I doubt whether "security" falls within the "requirement specifications" of any application. Not everyone treats security as a requirement. It is usually an "add-on" or "patch-up", which is injected later on into the application; hence, the overload in terms of development effort and time. In such a process, even if a single security patch is missed, the overall security of the application can go for a toss - paving a way for the "Hackers"!

Treat security as a "requirement"... and I am sure it will make a big difference...

It is necessary to think about security at each and every stage of the application development process. It is just like cooking food while at the same time keeping health concerns in mind.

Developers often complain, "I don't know anything about application security".

I agree, not all of us are security experts but we all can, of course, think about "security". One can certainly consult security experts and involve them during the development process.

For instance, if you were to buy a new car and suddenly thought "security" should be one of the key aspects to look for, I am sure that you would probably check the number of features related to security e.g. locking or any tracking feature available. You would try and evaluate all its features with respect to security. You would even call up your friend to verify whether you are choosing right or whether you should be looking for some other safety feature. You would also take an opinion about all the existing features it offered.

It is the same in the case of web applications. Think about security for each and every feature that you develop. You can document whatever is not feasible to be remediated (or developed) immediately. Call your friends - i.e. security experts like "Plynt" to analyze these areas and features. It is very important that you involve security experts either during the development process (on an ongoing basis) or at the end of it. You must discuss all the application features thoroughly with them, in the same way that you would explain everything about your car to your friend; because the more you talk about the application and its controls, the more you will hear about security from the experts.

Familiarizing the security experts with all the features, entry points, integrations, add-ons, etc. is crucial. You may also discuss the security controls that you have already implemented in the application. I am sure if you are conscious about security, you would be proactive toward security controls right from scratch. The security experts will verify them and test their effectiveness against the latest attack vectors.

The security experts will carry out a complete security test based on the information in hand and make you understand what kind of security controls must be implemented in which area in the application. Such a comprehensive security test will also ensure that nothing is missed and your security requirement will also be met.

You can then have a safe drive...for a long long time :)

Ten Questions to Ask Before You Jump into Code Reviews

Wed, 07 Sep 2011 02:45:41 +0530

by Priya Gangwani

Someone once said to me, 'We need to ask a million questions to understand the application!', and that had me come up with a short list of ten questions (yeah, you heard it right!) that a code reviewer can ask to get a hang of the application's context.

Do I hear you ask, 'what is a context'? Context, in this sense, is the functionality of the application being reviewed. Suggesting military standard security mechanisms for an e-book application would be useless. Understanding the context of an application gives an overall idea of the impact to the company if its data is compromised. This is what defines security.

As the OWASP Code Review guide rightly says, 'Context is the "Holy Grail" of secure code inspection and risk assessment'. Code review is not just about reviewing code. It's also about ensuring that the code protects the assets and confidential data that the application is entrusted with. If one understands the business correctly, then creating a threat profile and other things that follow is merely child's play!

You may have your own set of questions, but listed below are the ten questions that should find a place in your 'Ask the developer' checklist.

What is the purpose of the application? From what the application does to how the business benefits from it as well as the nature of the application (small business marketing software or enterprise-level applications), examining every aspect provides a new perspective. All these perspectives go a long way in defining security for a particular application.
Who are its real users? Are they internal or external users? If both, are they authenticated differently? This question refers to the intended users of the application. Also, it should address the kind of users they are i.e. if they are human & technically efficient as well (the more crazy it gets, the merrier it is for us).
Also, one often sees that if an application is meant for internal users, security is often not considered very critical. Paradoxically, most hacking attempts occur from within an organization. The idea behind such questions is to figure out the differences between these users from a security standpoint and how they are authenticated in the application. Do they use AD or LDAP to authenticate internal and external users? Does the application distinguish between internal and external users?
What should be considered 'CONFIDENTIAL' data/assets in the application? This is most critical to security and therefore knowing the answer to this would help assess the right risk to the application. What is the impact if the information is compromised in any way?
What are the different environments in which the application is deployed? Is the code given for review in the same manner as the one deployed in production? Usually, an application is deployed in the test environment along with the production environment. It is always good to know how it is deployed and if there is any difference between the various environments. The difference might be with regard to integration with other applications, presence of a web application firewall, etc. Another critical thing to be confirmed is the authenticity of the code shared for review. Is the code base complete and same as that deployed in production? One often comes across developers who don't share configuration files, property files and the like, thinking that these might not be required to assess the security of the application.
How important is this application to the enterprise? This question may seem irrelevant but it is not so. Given this perspective, the reviewer will be in a better place to suggest mitigation techniques and counter measures to the vulnerabilities identified during code review. The cost of preparation if any and the business impact derived by the exploitation of the vulnerability are two key factors that should be kept in mind before suggesting solutions. Now, you do want them to implement your suggestions and fix their application, don't you?
Is the application integrated with other applications in the company? Is the data coming from somewhere and/or going somewhere? It is critical to understand how the application interacts with external entities. Another critical understanding would be to identify trust levels that represent access rights granted by the application to external entities like web services. A trust boundary exists when a user accesses or enters data into the application, and also when an application interacts with the database.
What are the entry points and exit points in this application? Entry and exit points define a trust boundary. This knowledge allows the reviewer to assess attack surfaces & come with possible threats to the application. Entry points, for example, can be:
- Browser input
- Cookies
- Property files
- External processes
- Data feeds
- Service responses
- Flat files
- Command line parameters
- Environment variables
Exit points, for example, can be:
- The Search page that writes the client's search string and its corresponding results.
- Error Page
- Information Page
Are audit trails and logs pertaining to the application maintained somewhere? Audit trails and logs are a form of documentation, which help in reviewing various activities undertaken by various users. These can provide a means to accomplish several security-related objectives, including individual accountability, reconstruction of events (actions that occur on the computer system), intrusion detection, and problem analysis as well as evidence of the correct processing regimes within a system.
Are there any security measures in place? 'Is there something that really needs to be secured apart from ensuring that the right users access the right data?', 'Does the application prevent external attacks like the submission of special characters to the application', 'Is the application protecting the right kind of data in the right manner?', 'Are there roles and privileges, which define what portion of data is accessible to which user?', 'What operations should an authorized user be able to perform on the data?' and 'Is the application defensive against attacks?' are some of the questions that are answered here!
What is the architecture of the application? This should leave the reviewer with a good knowledge of the key technologies used, application frameworks, servers (database server, web server, etc.), application tiers, software used (along with the version number), and type of application (data-intensive application, service-oriented application, etc.). Gathering maximum information about the operational environment of the applications helps in assessing the right security risks. Developers should share DFDs, Use Case diagrams, Process View diagrams and others of the same kind to enable better testing.

Last but not the least, make sure that some developers are always available in case you get lost in the maze!

Forgot Password Best Practices

Thu, 01 Sep 2011 01:19:34 +0530

by Sourabh Saxena

The Standard Best Practice followed by Gmail and other public websites are as below:

Ask the username and/or a Custom Security question
Display a Captcha, after successful verification of username and/or Security Question
Send a link to the user's registered email address. The link should have random token associated with it
The link should be short-lived, one time use only, and SSL enabled.
Once the user's resets the password, the link should no longer be usable.

For most applications the above solution should work fine. What the SSL enabled link does is that it never exposes the user's password to an external entity like Yahoo, Gmail or hotmail, and it never resets the password automatically.

We were brainstorming over this solution, and one of the concerns was that we are putting our trust on an external entity (like a yahoo, gmail or hotmail) to hold the key to reset our account passwords, albeit for a short period of time. For applications that hold critical or sensitive data and that still need to implement a web based forgot password solution, this may not be an acceptable solution.

We came up with a few enhancements to the above standard solution, here is how it goes.

The Plynt Secure Forgot Password Solution

Provide a publicly available Password Reset page over SSL, which asks for the user ID and 3 non guessable hint questions along with a CAPTCHA.
After a successful verification, allow the user to choose/enter a 6-character Temporary Authorization Pin/Token
Email another short lived SSL enabled tokenized URL to the user's email address.
On Clicking this tokenized URL, the user should be asked to enter the 6-character Authorization Pin/Token and the new password.
Expire the tokenized URL and Temporary Authorization Pin/Token
Notify the user that the password has been changed.
Force the user to change new password on the first login after resetting the password.

The above solution has all the benefits of the standard solution, in addition to that, we are protecting against a scenario where external entities like gmail, yahoo or hotmail accounts are compromised or data within them are sniffed over the network (traffic over HTTP). We protect this by adding a 6-character Temporary Authorization Pin/Token that the user enters on the web application's forgot password page, and hence is only known to the user. Without this token, the short lived SSL enabled tokenized URL will not be able to reset the password. Thus we have fulfilled both "What you know" and "What you have" principles of security.

We are Back!

Fri, 26 Aug 2011 09:21:39 +0530

by Harshvardhan Parmar

We have been off our blog since a year now, spare a lone post by Ashish in February earlier this year. This post is to update you on what we have been up to over the past 1 year and to mark the beginning of a more stable presence on the blogosphere.

We completed a decade last July, which was marked with celebrations across all our offices spread throughout the world. Last year also saw a growth spurt in our team strength. We are almost a 100-strong team now. Over the past 1 year, we have had over 50 people join us at varying levels. We now have a young, energetic team, which is led by a bunch of experienced guys at its helm. Over the next couple of months, these are the people who will be sharing their experiences and expertise with you via our blog.

Start Programming... And You Can Catch Up With Coding

Wed, 23 Feb 2011 03:37:20 +0530

by Ashish Rao

It was only when someone told me that programming is difficult stuff, I thought of passing this piece of my learning to you all. There is a perception about "programming" that it is not everyone's cup of tea. Well, that is far from the truth, all that we may find difficult is - "coding"; all of us can program.

Wait! There is a caution here - Provided we know what we need to do. We need to be clear of the objective.

Programming language is nothing but a language that compilers understand. These compilers then make the processors understand. But for all that to work well, it's "YOU" who would need to understand. The definition of the problem and the desired output are all that it takes to get started.

At times, during your projects, you might feel like coming up with certain programs of your own, maybe to write a script file, a web component or a UI component. No matter what it is, the principle behind programming remains the same.

A few useful pointers that will always hold you in good stead are:

Take the fear of "not knowing" the programming language out of your mind.
Given a problem domain, analyze it and draw the tasks to be achieved programmatically.
Never hit the keyboard and start writing the code right away. Always start writing the steps in your own language. In short, pen down your thoughts.

Write down the steps that would form the basic layout of the program. Don't worry about how to realize the steps into a piece of code. Steps that seem bulkier can be converted into function calls later. Initially, just assume that smaller functions such as calculateInterest(), findArea(), sum(), findAverage(), getConnection(), etc. exist.

Once the layout is ready, it's time to work on each step. People who know some programming language can now start coding in that language; however, others may have to rely on Google or other references to convert the step into programming language constructs.

Advantage: You can save a lot of time. You would know exactly what you are looking for in the vast pool of knowledge available about that language.

At the end of it, you will have the entire program ready in proper steps with bulkier steps present as separate function calls.

Now, it's time to create and work on smaller functions that we have in our layout. This is how one can build reusable smaller chunks of code, while the main body of the program is small, made of function calls, very readable and maintainable.

Advantage: By doing this, you divide your task into 10 smaller tasks. You can then easily concentrate on the smaller part of the problem by not worrying about the whole big task to be achieved.

Keep test cases for your program handy, i.e. sets of input and expected output. One must ensure that the program works fine by evaluating the output to the one desired.

Also, knowing a programming language thoroughly with the help of a standard book first is very essential.

Having said so, the sole intention of this piece of information was to convey that you should not hold yourself back from programming with an excuse that you lack a proper know-how of any programming language.

So, start programming... and you can catch up with coding on the way.

HITECH Act - Security Testing towards HITECH Compliance

Wed, 14 Jul 2010 02:35:53 +0530

by Sachin Varghese

Why is HITECH accelerating security programs in the healthcare industry?

It applies not only to all HIPAA regulated entities but also their business associates
Breaches of any "unsecured protected health information" need to be notified to affected individuals, HHS Secretary and media
Business Associates need to notify the covered entity
Cost of notification by mail and email are very high. Cost of maintaining a toll free number and staff to address concerns of affected individuals are very high
State Attorneys General can bring a civil action on behalf of the affected residents of the state in a US district court

What all data is Protected Health Information (PHI)?

Protected Health Information is a combination of the following identifiers that constitute information about health status, provision of health care, or payment for health care that can be linked to a specific individual.

Names
Postal address information, other than town or city, State, and zip code;
Phone numbers
Fax numbers
Electronic mail addresses
Social Security Numbers
Medical record numbers
Health plan beneficiary numbers
Account numbers
Certificate/license numbers
Vehicle identifiers and serial numbers, including license plate numbers;
Device identifiers and serial numbers;
Web Uniform Resource Locators (URLs)
Internet Protocol (IP) address numbers
Biometric identifiers, including finger, retinal and voice prints
Full face photographic images and any comparable images
Dates directly related to an individual, including birth date, admission date, discharge date, date of death

How should PHI be secured as per HIPAA and HITECH?

By encryption or destruction.
The HITECH rule states that though HIPAA does not mandate encryption, to avoid breach notification, the covered entity and business associates would need to employ encryption technologies as recommended by NIST.
If unprotected PHI has been breached then notification would be required.

Role of Security Testing in complying with the HITECH Act?

PHI Enterprise wide Data Analysis - Assess where in your organization is electronic PHI data in transit or data at rest in an unencrypted (unsecured) format.
Verify if the encryption mechanisms in force are as per recommended NIST standards.
Discover holes in internal and web applications which may expose PHI to unauthorized users by doing penetration tests and code reviews
Verify the strength of your networks access controls in force through internal and external network penetration tests
Conduct periodic testing programs to achieve long term sustainable compliance to HIPAA and HITECH requirements.

How to test applications to identify "unsecured PHI"?

As mentioned above, PHI refers to a combination of a lot of information relating to a person. Applications and databases that it communicates with contain a wealth of such information.

To test applications for "unsecured PHI", the following test cases can be performed:

SQL Injection
Cross-Site Scripting
Parameter Manipulation
Sensitive content in browser cache
SSL enabled application
Password Stealing
Session Hijacking

These test cases cover the most possible attack vectors that an attacker might use to obtain unauthorized access to PHI.

How to test networks to identify "unsecured PHI"?

To test networks for "unsecured PHI", the following test cases can be performed:

Unrestricted remote shares
Default users/passwords
Remotely exploitable vulnerabilities
Anonymous FTP access
Insecure services
Insecure mail relay

How to conduct an Enterprise wide PHI Data Discovery and Analysis?

PHI can reside anywhere within an Enterprise including database tables, application servers, browser memory, etc. An enterprise wide data discovery will have to look for PHI at its entry points, during transmission, storage, retrieval, distribution and destruction. An analysis of the same should result in a flow diagram that presents the flow of PHI from entry to destruction. Each of the entities in this flow diagram needs to be reviewed to ensure that appropriate protective measures have been implemented.

Some of the protective measures include establishing security awareness among data entry operators, hardening of workstations, servers & databases, securing applications, enabling logging, implementing strong access controls, authorizing distribution and using safe destruction techniques.

How SIEM (Security Incident & Event Management) plays a role in breach discovery and avoiding breaches?

An SIEM system monitors the network traffic for attack patterns and raises alerts whenever there is an attempted breach into the network. This ensures that attacks are detected in real-time and appropriate protective measures can be put in place to avoid potential breaches. In case of a successful breach, the SIEM system can be used to identify the incident and the events that led to such a breach. It also provides indicators on what information was likely compromised. The SIEM system can also be used to identify the root cause of the breach, which helps in determining the steps to implement the fix and the procedure to follow for breach notification.

Penetration Testing versus Vulnerability Scanning

Fri, 18 Jun 2010 19:05:01 +0530

by Sachin Varghese

Penetration Testing

Penetration Testing is usually referred to testing by an ethical hacker to break into a target network with limited information about the said network. It is also called a network (layer) penetration test or a black box test. It requires the bare minimum information about the targets, usually just the IP addresses of the systems to be tested. The testing is performed using a penetration testing tool kit which comprises of well over 25 custom, commercial and open source tools. The testing, though leverages tools, has a very high involvement of a well trained and experienced security tester. The results of a penetration test will usually be free of false positives and on request the tester will also conduct exploits and chained exploits on the target systems. Variations include conducting the penetration testing on internal networks; between inter connected LANS and VLANS, on wireless networks, and penetration through social engineering techniques. Penetration Testing plays an important role in securing enterprises by verifying the efficacy of existing security programs and mimicking real world network and application layer attacks to your systems.

Vulnerability Scanning

Vulnerability scanning is usually referred to running an automated vulnerability scanner against a block of IP addresses. The manual component is limited to the coordination and scheduling of the scanner and delivery of the automated report. The reports are very detailed and long, but are not free of false positives. The extent of false positives would depend on the accuracy of the selected vulnerability scanner. The scanning process is very quick and generally can be conducted at a pretty low cost. The scanners are sold as perpetual licenses and on subscription in a software-as-a-service model. Vulnerability Scanners play an important role in securing organizations as a key component of security vulnerability management programs.

	Penetration Testing	Vulnerability Scanning
Goal	Use Penetration Testing to verify if networks are secure, what does a hacker see, discover unknown security flaws. Do quarterly or at least annually.	Implement Vulnerability Scanning as part of an overall vulnerability management program. Do monthly or at least quarterly.
Tool Types Used	Automated Scanners, Proprietary Tools, Exploit tools	Automated Vulnerability Scanner
Manual Component	Extensive	Negligible
False Positives	Removed	Present
Exploitation	Yes, on request	No
Chained Exploits	Yes, on request	No
Duration	Days to Weeks	Hours to Days
Cost	$1000-$2500 per day	$10-$30 per IP
Flexibility to Client Needs	High	Low
Recommended by Regulators	Yes	Yes

Working at Paladion

Fri, 18 Jun 2010 18:29:18 +0530

by Prashant Verma

Working at Paladion has always been a pleasure for all of us. The varied learning we get here, across domains is amazing. I'd like to share with you a few such experiences I was part of.

The client was a big organization in India and various teams of Paladion worked here in tandem to meet our client's expectations.. I belong to a team called Sectest. My team is responsible here for conducting Source Code Reviews, Application Security Tests, Network Penetration Tests, Host Configuration Assessments and Secure Network Architecture Reviews.

The other teams in Paladion are Consulting; responsible for Process Audits, Ensuring Compliance with various standards, Creating customized Policies and Guidelines for various clients among others.

Another important team working here is our Managed Risk Services (MRS) team; they are responsible for monitoring the client network for the security risks. Apart from helping client in management of security devices like Firewalls and IDS, they also do real time monitoring of security events through remote SOC (Security Operations Center), located in Bangalore. This team operates round the clock to ensure that our clients are always ready to face the latest threats.

For client, these are not three different teams but they just belong to one team called Paladion. The work coordination between these teams is an example for others. I'd like to quote a few such examples:

Suspected hacking activities via SQL Injection. The team comprising of people from various Paladion teams coordinated to arrive at the root cause. Sectest did the detailed technical analysis of the attack, MRS performed log correlation using logs & other relevant data available with them. The Consulting Team researched on the history of such attacks and steps for future prevention. The entire team after sitting together concluded that a malicious intruder invoked xp_cmdshell, installed netcat via a SQL Injection vulnerability on a public form and escalated privileges.
Backdoor/Trojan Alert on a critical server in the client DMZ raised the alarm for team Paladion. The team worked together in unison, did a thorough log analysis, cleaned the backdoor, found that no damage was done to the server and finally provided valuable suggestions to ensure such incidents did not reoccur in the future.
Mock Drill - One member from each internal team was allotted for this activity. Sectest & Consulting team members jointly setup the pre-test environment, hardening and patching a vulnerable Vmware image installed in the client network. The MRS team continuously monitored all the attacks targetted at the VMWare image and notified the other teams on anything that might have been missed. They together did the incident response; their combined efforts were greatly appreciated by the client.
Numerous other medium & small activities where they coordinate. Any small project here requires the involvement of atleast 2 internal teams.

The amazing coordination seen here is what makes every project unique for all of us. On one hand, Paladion as a company can be proud of this. While on the other, employees of a particular team are also happy as they get to learn things beyond their normal team activities. A sectest guy gets to do log analysis, incident handling and malware analysis and a MRS team member learns how to perform an application security test and a network pentest.

The fact that there is always exciting work at Paladion and that there is always 100% co-operation between teams is the best part about working here; I for one love working here :)

Network Mapping Tool

Sat, 08 May 2010 02:30:03 +0530

by Arvind Doraiswamy

We continuously do a lot of Internal Network Penetration Tests for our clients. Many a time we're given permission to put a machine into their network and test the attack surface area from that machine. During these times its extremely helpful to understand the other valid network ranges that are present. With the help of a combination of many open source tools its definitely possible to do the same. However doing so and correlating the output of all of those tools is at times..time consuming.

So we thought of writing a small tool to automate the same. Since there's nothing proprietary that we used at all , we thought it'd be a good idea to get feedback from the Open Source community about how we can improve it. With that in mind we've hosted the tool on Sourceforge.

Do try it out and let us know how we can improve. All types of feedback is most welcome.

Plynt Certification Criteria Version 3.0 Released

Mon, 26 Apr 2010 22:25:24 +0530

by Runa Dwibedi

New technologies, new threats, new attacks - we live in a changing world.That is reason enough to keep us on our toes. Being an organization that specializes in application security services it is very important for us to be up-to-date.

One of the services we offer is Application Certification Test. The Certification test is based on the Plynt Certification Criteria. During the last few weeks we have been working on revising our Plynt Certification Criteria. Criteria Version 3.0 was released on April 15, 2010.

Some of the significant changes you will see in this version of the criteria are:

Five of the Criteria's were merged to be a part of other existing criteria and the individual ones were deleted.
Three of the Criteria's were modified.
Two of the Criteria were merged to form new Criteria.

You can read about the details of the changes made to the Plynt Certification Criteria version 3.0 here.

Version 3.0 of the Criteria is available here.

Budget options to secure your Killer Applications

Thu, 26 Nov 2009 10:42:23 +0530

by Sachin Varghese

1.	Periodic Vulnerability Scanning* (Catch network and standard application level vulnerabilities)	~$150
2.	Periodic Application Scanning* (Catch application level vulnerabilities like SQL injection, CSS etc.)	~$500
3.	Periodic Application Penetration Test* (Comprehensively catch application level vulnerabilities like SQL injection, CSS etc. including business logic security flaws)	~ $750
4.	*Periodic Security Code Review (Replaces 2 & 3)** (More comprehensive than 2 & 3 and also catch accidental / deliberate Backdoors in your source code)	~ $1000
5.	Daily Website Malware Scanning (Catch malware infections on the publicly accessible pages of your websites)	~ $50
6.	*Developer Training on Secure Coding Guidelines** (Reduce security bugs by educating developers)	~ $500
7.	Security Log Monitoring* (Monitor your webservers, firewalls, routers etc. on a real time basis to catch and deflect security attacks as they happen)	~ $1000

Budgeting Guide			Per Month (US$)
Minimum Budget	→	Go for 1,2	~ $650
Modest Budget	→	Go for 1,3,5,6	~ $1450
Recommended Budget	→	Go for 1,4,5,6,7	~ $2700

* — Recommended by PCI DSS.
Estimates are based on scopes we have seen amongst start up and mid size software companies with revenues less than $50M

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.