Why you might be 'Californicated' by SB-1386

SB 1386 is something most of us havent heard of. In the PCI and (fading) ISO juggernaut, organizations (especially outsourcing companies) have not taken cognizance of an important legal statute that might be a game changer for the way they do business with their principals in the US. Let me throw some light on what SB 1386 is all about. This is based on a conversation I had with another person from the outsourcing industry. The conversation might make a lot of sense to many people reading this....

What is the SB 1386?
SB 1386 is popularly known as The California Breach Security Information Act. It was an act enacted in the year 2002 and came to effect in 2003. The act focuses on the privacy of the personal information of the citizens of the state of California. The act states that any organization that believes that there has been a breach of un-encrypted personal information of California state residents is required to disclose the breach publicly.

What is 'Personal Information'? It is very vague...
No, its not vague. The act defines 'Personal Information' as the individual's first name or initial and last name in combination with one of the following: social security numbers, California State Identification Numbers, Credit/Debit Card numbers, PINS or access codes.

Ok. I am listening. Who does it apply to?
It applies to anyone doing business with anyone who is a California resident. If you have employees or customers in California, even a single one, it applies to you. If you are an outsourcing company that has a customer who has employees or customers who are California residents, then it applies to you. If you store data for entities that have information of California residents, then it applies. Large and small does not make a difference. It applies all the same.

That's alright. Its just a disclosure clause. No big deal....
That is where you are very wrong. You will have to disclose the breach to all those affected by it. These leads to a public relations war which you might have to wage with a great deal of reputational and financial expense. Your reputation WILL go to the cleaners because of a breach. You WILL face lawsuits from angry consumers and IF you are an outsourcing company, your customers will probably walk away from you and your prospects will NOT return your calls. Catch my point?

Yes, I think so. Wow, that seems worrying. I am an outsourcing partner for a lot of clients in the US. Can you tell me how it affects me?
Well, for starters if you are call center or a similar entity making outbound calls to US customers, you probably have the information which is defined by the act as "personal data", then you are in scope. If you are a back-end data processing center handling accounting or payroll or any other data processing activity for your client, then you are in scope. You will need to start securing all that data and doing it seriously. A lot of companies have breached your customer's data and you dont want that to happen. See here and here

I think I need some water now. My throat has gone dry. Anyway, what do I do now? How do I prevent a disaster from occurring?
For starters, call in a professional to audit your information security practices and let it be a thorough technical review and not a documentation and policy audit. Conduct a risk assessment for the data you handle and store and then formulate protection strategies in conjunction with your client. Have the auditor issue a formal audit report on completion and please, for heaven's sake, follow all the advice which you have been given. Dont try and cut corners on security practices, you will be in for a rude shock. Also be especially vigilant about employees who are working in your processes. It is very important to conduct periodic assessments and actively investigate any traces of malpractice from employees. Remember that insiders are the greatest cause of data theft in your industry.

Right then, but didnt you say something about encrypted data. So, if I encrypt data will I not have to disclose?
Well, yes, but have you encrypted data? and are you confident that your data has been consistently encrypted and the encryption keys managed properly for all your encrypted data?

I dont think I have encrypted any data. I am not really sure. I have got to check......
Then you most probably wouldn't have. Anyway, you better get going and do something about SB1386 otherwise you might be in for a world of pain. Think on the lines of being shot in the face with an AK-47.

(Gulps) Yes, not a pleasant situation. Anyway, I got to go. See you then...
Bye...

A Possibly Fresh perspective about Secure Code for Software Development Companies

I am sure most of you wont believe the reasons for my hiatus for almost 4 months. Let me try and explain. I was involved in a theater production very dear to my heart, so my evenings would be lost in that. I am pursuing a heavy writing assignment, which has been uber-demanding on the small space of time I have left and I actually took my vacation in September, when I had been to beautiful South Africa. Great place! You guys must all visit.

Anyway, enough with the chatter. This piece was prompted by a talk I heard at the Business Technology Summita few days ago. Of course, I blabbed about web app sec and scared the pants off a few nervous developers and architects, but it was mostly fun. The conference mostly focused on SOA ang governance, but there were a few pure tech talks. There was one talk, which I was quite impressed with, by a fellow Java man, Eben Hewitt. He spoke on a topic entitled "10 Things Software Architects must know", which is based on a book similarly entitled, except that the '10' has been replaced with '97'. The talk was mostly about concepts which software architects should keep in mind in order to be successful. While the talk didnt really have a specific security-related context, I applied some of those theories to the way software development companies can deal with security for the apps they develop. These are just my two cents. I am sure some of you can add more to it.

I have heard of several instances where software development companies have been severely criticized for writing non-secure code. Undoubtedly so. Several software development companies dont really take secure coding to be an important practice. Time is not spent developing security in the application from the beginning, which subsequently results in a non-secure web app. The most common excuse that most of these entities give in terms of security or any other functionality not implemented is "This type of security functionality was not laid out in our Requirements Specification" or "There was nothing in RFC specifying these security requirements" and blame is thrown right back at the customers or the business users of the application for their lack of foresight. It is as if we believe that customers who will be using the application or who are functional stakeholders of a web application are actually extremely clear about their requirements. The truth is very simple. They are as clueless as you are. In most cases, they will never really know what they want even functionally, unless they are given several ideas, security is quite a mile away in these circumstances. I believe that it is upto the company or the team developing the application to incorporate a risk assessment process to ensure that they capture all the critical information assets that will be stored, processed and transmitted by the application, threats and the impact of an attack on the application and subsequently on business, and then draw out security controls for the same. I have highlighted a detailed methodology for risk assessment for web apps, in my book "Secure Java for Web Application Development".It is wrong to assume that customers or business stakeholders will be able to provide the razor sharp clarity necessary to build security into an application. Software Development companies need to rise to the occasion and use their expertise to suggest solutions and functionality for security at the beginning of the application development lifecycle.

Which brings me to my second point. People reading my first point are going, "Yeah, but isnt that going to be more expensive than a regular application development effort, without going Mother Teresa on my customer?" Yes it will be a longer, probably marginally more expensive process, but Quality is a Feature. We all try and sort out all problems all the time. Let us not try to do that and examine reality. Software development companies focussed on a greater level of quality of their products must make it explicit. You have various product and service offerings today, but it is important to realize that all services and products will not be of the same quality. A restaurant on the roadside, will not be as focused on quality than a snazzy five star restaurant. Its high time that we understood that about code as well. And its also high time that software development companies that are taking the first point seriously, start making it explicit and derive as much benefit as possible. There may be customers out there (despite the recession) that may be willing to pay better for a better service that is accentuated and re-iterated by processes like Risk assessment, effective understanding security functionality at the start of the lifecycle, vulnerability assessments, security code reviews and practices delving into security. Superior quality, in my opinion is a feature by itself, which needs to be advertised, and made explicit and should not be spoken about or practiced like its a part of the proverbial 'package'.

Let me know what you think of this....

PA-DSS 101

That blank feeling in my stomach, which was there for the past 2 weeks or so is slowly disappearing as I sit down to write this piece. My blog hasn't been impregnated in the past 2 weeks with my words and (sometimes meaningless) rants. I was unwell during the week and till yesterday I was at a Risk Assessment workshop on the OCTAVE methodology, where I spoke on Vulnerability Assessment and generally had some engagements which didnt allow me the time to sit down and pen something in the interest of security.

This piece is a result of an article I read in blogosphere somewhere today. It was something about Visa giving a great thrust to Software security through the PA-DSS program. Visa has indicated that Visa acquirers in all regions of the world must ensure that the merchants they newly sign must use PA-DSS Compliant Applications in their environments by the July 2010 and existing merchants should be transitioned to PA-DSS compliant Applications by the July 2012. I would see that as a welcome step in software/application security, and something that will be helpful to a huge extent in the application security quest. This is why:

What is the PA-DSS?
The PA-DSS is not as famous as its mother standard, which we all lovingly know as the PCI-DSS also known simply, as PCI. The PA-DSS is the Payment Application Data Security Standard. It is meant for commercial applications which come in contact with cardholder information either during the authorization or settlement function of the card payment transaction. PA-DSS is entirely meant for an application and consists of 14 requirements encompassing all aspects of security which a payment application will have to adhere to. This includes secure storage of cardholder information, logging, authentication&authorization, secure development and deployment, etc. The PA-DSS is a sub-set of the PCI-DSS, with the core focus on the application as opposed to the cardholder data environment in PCI-DSS. This is better explained with an example. For instance, a application developer "A" has developed an E-Commerce application which is to be sold to several merchants. Merchants all over the world are either thinking about, undergoing or have undergone PCI Compliance. If 'A' has to support his prospective customer's PCI Compliance effort, then it imperative that the application be validated as per the PA-DSS requirements. The PA-DSS is a certification for the application and not for the environment. So, if 'A' gets his application validated PA-DSS, then the application is readily designed to support the PCI requirements and merchant's PCI compliance effort wouldn't be hindered. The PA-DSS has been designed to ensure that the payment applications deployed in PCI environment must support PCI compliance, which is why the PA-DSS has come to be.

Why PA-DSS?
One of the greatest impediments for security are the applications. I have seen several environments, where the entire process of security compliance or practices comes to grinding halt because of applications being unsupportive of security requirements. Applications are the lifeblood of any entity in business today. An e-commerce merchant cannot do business without the e-commerce application and its related components. A payment processor will find it impossible to process millions of transactions a day without the financial switch and its related applications. Customers are wedded to the applications they purchase and any change is resented and sometimes not recommended as a 24x7 scenario is the need of the hour. Most of these applications fall short of basic and advanced security needs by a long shot. Several financial switch applications log the entire magnetic stripe information, including the Card number, CVV and other track elements in CLEAR TEXT, a strict no-no from the PCI standpoint as well as from a general security standpoint. Several E-commerce applications purchased and deployed by customers don't support hashing of passwords, encryption of cardholder information and not to mention web application security practices like input validation. Point of Sale applications used by merchants log the entire card number in the transaction logs and several of them dont support anything more than a 4 char password. This is a huge impediment in adhering to security requirements. Merchants and processors often struggle with security implementation because of the applications and even after the best workarounds, the risk of data being stolen, modified or destroyed still remains amply. The aim of the PA-DSS is to correct this situation by ensuring that application vendors creating commercial payment applications to be sold, must get their applications validated against the PA-DSS requirements.

Why not just PCI? Doesn't it cover Application Security?
Yes, PCI does cover application security in its requirements. In fact Requirement 6 is dedicated largely to application security practices and web application security practices, including a great deal of wisdom from the OWASP knowledge base, providing a much-needed boost to AppSec, but PCI addresses the applications which are custom developed or developed in-house. The focus of the PA-DSS is for payment applications which are to be sold, distributed or licensed to third parties. So the loop is pretty simple

if (inHouseApplication() || customCode()) {
 validateAsPerPCIDSS();
} else {
 validateAsPerPADSS();
}

Thats great, I have developed a log management app for PCI, when can I get it PA-DSS validated?
Well, you do not. The PA-DSS is only applicable for applications which are part of the payment authorization and settlement cycle. So if you are a log management application, WAF, or any other application which is looking for a marketing boost from the PCI fever, you will not able to go the PA-DSS route as it is specifically for Payment Applications.

Why attackers love your developers!

Kind Sir

My name is Developer A. I am having a problem with database connectivity to Oracle. I think I am doing everything right, but I am getting an HTTP 500 error with the following details:
(Full Stack trace follows)
The sample of the source code is given here.
(Source Code follows)
The error where it is occurring is at this URL (Organization's url follows)
Please help me out with this as soon as possible. I reeeallly need help!!!
Email me at developerA@organization.com

Yes. This was one of the messages I found sifting through my Google hacking results while I was pen-testing a web application the other day. Needless to say that, the page with the stack trace was open for me to go and gain a complete understanding of the application and penetrate. The organization which I was pentesting had gone great distances to get secure. They had spent a lot of time, money and resources in getting secure and staying that way. They had gotten a few things wrong, but mostly they were on target. Unfortunately, they had forgotten to explain to their developers that dirty laundry (or in this case confidential laundry) should not be washed in public. I have seen this with several organizations (mostly in Software development) where developers post their queries in Internet forums and get some other professionals to look at it and give them some insight into the matter. While there is nothing wrong with this practice, the way it is followed is quite shocking. Developers dont even go through the trouble of hiding the name of the organization they are working for. They advertise their email address and in several cases the URL of the page which is problematic and buggy. When posting code snippets or source code, they mostly never remove sensitive details like certain class references or database drivers (sometimes, even usernames and passwords to dbs) and last but not the least, they use words like "Kind Sir" on an Internet forum (although the last one is not a vulnerability, it is bloody irritating). I am sure all of you would realize that such information can be extremely useful to anyone looking to break into an application or a site. It would be worth its weight in gold. And, of course, as usual the only thing you really have to do is "Google it" or "Bing it" (my vendor agnostic comment for the day).

My advice to organizations to prevent against such ignominious disclosures are these:

• Instruct developers never to post in internet forums under their own name or with their company credentials like emails, etc.
• Encourage developers to first find help within the organization. I have seen that several greenhorns tend to be afraid of asking their seniors or project managers any doubts regarding the code, fearing a nasty remark or backlash. Build an environment of openness and encourage questions. Not doing so, would result in these juniors asking questions anyway, but to someone you are totally not aware of, not bound by confidentiality agreements, etc.
• If someone really has to post queries on the Internet, make sure that these are approved. Source code should not be posted. Stack trace should not be posted. Questions should be based on peripheral details and no sensitive information should be posted. Words like "Kind sir" should definitely be filtered out of posts ;)
  
• Have your risk folks scour the internet regularly checking for violations and take action against people violating these instructions.

PCI Compliance: Hazards of the "Dull-Clarity" effect

It has been a while since I sat down to write a post for my blog. The monsoon season has just set in this part of the world. The days are hot and it rains heavily on occasion causing one to just enjoy the comfort of his bed a little more than usual.

This was a piece, which had been in the works for sometime now. I had planned to write it, close on the heels of the Savvis lawsuit (for the CardSystems breach), but I missed my cue. Anyway, here goes. This lawsuit has been abuzz in blogosphere because some of the banks that were processing their card transactions through CardSystems (which was involved with one of the largest credit card breaches in history), have decided to file a lawsuit against Savvis, the organization that attested to the compliance of CardSystems, with the Visa compliance requirement called CISP (Cardholder Information Security Program). The CISP was the predecessor to someone we all know lovingly as the PCI-DSS (Payment Card Industry Data Security Standard). A little background here. CardSystems was one of the largest credit card processors in the US, and they were involved in a breach which compromised over 40 million card numbers. Savvis was the company, which certified CardSystems as compliant with the standards. Now, four years later, Merrick Bank has filed a case against Savvis, alleging that it has been negligent in certifying CardSystems. Frankly, I am not aware of whether Savvis has been negligent or not, but blogosphere and online news portals have gone wild with the news. The Security gurus are quoting their same old lines of the inadequacy of PCI Compliance and are questioning the 'rigour' of the standard in the protection of cardholder information.

My intention with this piece is 1) To introduce the some people out there to the concepts of "Reasonable Assurance" and "as on date"; Two concepts which have been in lost in the rhetoric which several security folks have been dishing out relentlessly. 2) Drive home my point of Risk based compliance, another concept which has been dulled with wrong interpretations of the PCI Standards 3) and hope that a few organizations would actually understand the concept of PCI being risk-driven as opposed to a dull checklist, requiring their meek submissiveness.

The security world has much to learn from the Financial audit and assurance world. No auditor will be able to guarantee that an organization's financial statements are free from error or misstatement. The auditor has to do everything that a prudent person in his place would do and in the end, signs off on a report which states that a "reasonable assurance" can be provided with respect to the financial statements. The auditor is not god, and the laws are quite aware of that and have provided for a similar treatment. Moreover, the auditor does not have to look for fraud, another basic truth in the financial audit world. The auditor must perform a risk assessment and gain an understanding of Internal control, before he performs his audit tasks. Contrast this with the security world. Information Security assurance, being nascent as it is, has not promulgated such basic truths to its practicing professionals. It still (subtly) preaches the utopian ideals of "Perfect security" Furthermore, PCI as a standard still has a very hazy understanding of what assurance the QSA actually provides. Is it "Reasonable Assurance" or is it a guarantee, because if it is a guarantee, then QSAs should pack their bags and quit the business, because that is impossible to provide. When it comes to reasonable assurance, the only defense that an auditor should provide in his alleged negligence, is his working papers and evidence. So my advice to people who are QSAs, please keep your workpapers and evidence in perfect auditor, they are your only saving grace tomorrow when fingers are pointed at you.

Another important concept which people usually miss out with PCI Compliance is the "as on date" concept. When an assessor certifies an organization for PCI, the certification is done as on date and not for the "period ending". I have seen several companies take the proverbial snooze after their PCI Compliance. 8/10 organizations I have seen have serious issues with their applications, or their network configurations or their log management and review. They would have slipped into non-compliance several times during the year and would have remained so till the the recertification for PCI Compliance. An assessor cannot be held responsible for the negligent organization on a future date, unless he has wrongfully or negligently assessed the misgiving as compliant as on the date of certification. I would like to add, at this juncture that I am not aware of whether Savvis was actually negligent or not. Its negligence can only be established once its made to produce evidence of its assessment and its work papers in front of a court. My advise to assessors is to go ahead and fail organizations which have not demonstrated compliance throughout the year.

When it comes to Risk based compliance, my views have already been aired, but I would like reiterate some practical angles to the same. Several clients ask me, "Where does it say that this has to be done in the PCI Standards?" The greatest advantage of the PCI Standards is also its weakest point. Its clarity. Several organizations interpret PCI to be a checklist requirement set which they need to fulfill and be done with. The PCI has acquired a reputation of being a standard which prescribes exaclty what to do and how to do it and that it is inflexible in its approach. True, it is specific, which is why, when a recommendation outside its realm, but very much in the realm of specific risk is given, it is quickly shot down by an organization as not being specific in the requirement. I have several (often heated) arguments with clients who ask me questions like, "Where does PCI say that Internet access to these partiular set of users should be blocked?", My reply to them is that PCI is a baseline set of controls to be applied to any environment storing, processing or transmitting cardholder information. For such specific requirements, a risk assessment is in order, which narrows down certain risks which are specific to the environment. If the risk of individuals having access to cardholder information as well as the Internet (where cardholder information can be sent over email or over the internet in any way) is high, then it is only prudent that you mitigate the risk and not let it become your Achilles Heel. My advice to organizations. Dont look at PCI as a checklist for truly being secure. Treat PCI as a baseline and add to it controls for the risks which are specific to your environment.

I would like to conclude by stating this. PCI Compliance, like anything else in Information security, is at its growing phase. There are bound to be a few teething problems with respect to the standard and its expectations. An organization intent on pursuing PCI Compliance should not be misguided by the pure view of the 12 requirements of PCI, but to understand the risks before going into requirements.

OWASP Membership

I became a member in the OWASP (Open Web Application Security Project) today. I am glad to support the great initiative for Web Application Security, which has been taken by OWASP.

For all reading this, please become OWASP members, it is a great initiative, which is completely free. We should do all we can to support it. It costs just $50 for the Individual membership for a year.

Please join up and make a difference

OWASP Bangalore Chapter Meet: 7th June 2009

It was the first meeting of the OWASP Bangalore Chapter that I was attending. The meeting was scheduled at 9am at the India Coffee House on Church Street in Bangalore. Although, the location was not the most suitable, especially keeping in mind that that presentations on App Sec and other Info Sec related issues would be part of the meeting. Nevertheless, it was nice seeing some energy from this chapter.

Rajiv Vishwa's was the only presentation on using Firefox as the ultimate App Sec assessment tool. Rajiv demonstrated the use of several Mozilla Addons like Tamper Data, XSS-Me, SQL Inject-me demoed over Webgoat to a small group of dedicated OWASPers in Bangalore. It was an interesting presentation, which highlighted the fact, that there are several tools for performing AppSec assessments and a pen-tester would never really have to leave the comfort of the browser to perform security testing for applications. Mozilla provides several other addons like Firebug, FoxyProxy, etc, which allow the easy assessment of web applications. Although Rajiv had to leave early, I took over and we discussed talked more AppSec. I stressed on the use of exploit frameworks like Metasploit for Pentests and also discussed how Application development needs to be given the impetus, it so badly deserves from the security standpoint. We signed off on a positive note.

The Bangalore Chapter has some great energy going but needs a lot more to live up to the reputation of being the OWASP Chapter in the Silicon Valley of India. It would be great to see more Bangaloreans interested in AppSec and InfoSec attend the Chapter meets and play an active role in the development of this community. I will try and get in touch with the ISACA Chapter in Bangalore for some joint meetings and meeting space. Hopefully, things should go well on that front. I would request anyone part of the OWASP Bangalore Mailing list to actively participate and probably initiate some action on the location issue for the chapter. There is a nice quote which I would like to share with all of you, "I ask not for lighter burden, but for stronger shoulders".

Thanks

My brush with the Gumblar worm

Some of you might have heard of the new worm out there known as the Gumblar worm or the gumblar.cn worm. It is a worm which has been spreading rampantly across the internet. This worm has become the scourge of the internet after the conficker worm. The Gumblar worm has two ugly sides to it, both of which I have been exposed to.

This was way back in March, when we were performing a company's website assessment. The company had outsourced their website development activity to a organization that designs websites. The company had run into a few security issues including Directory traversal vulnerabilities and weak passwords which the web design company had caused. Once the website was up, I opened up the page to see my Avast Anti-virus light up like a Christmas tree, with a malware alert for a "JS:Redirect" worm. Needless to say upon exploring the source in the php and html files, I found that a large piece of javascript code, which had no apparent business being on the page, was there. It was obfuscated code, which obviously caused the worm to propogate. The Javascript code for Gumblar is given below:

I have removed the Gumblar worm code as some AV apps were throwing up alerts from their content filtering engines. Please check elsewhere for a copy of the code.

The gumblar worm infects the PC when the PC opens up the website which is infected the malicious javascript.












The execution of the malicious code results in a backdoor being installed which attaches itself to Internet Explorer and also manipulates Google searches. Furthermore the worm is also known to disable anti-virus software, install fake av applications and also sends out spam. This is the one facet of the Gumblar worm. The other facet of the Gumblar worm, is worse and is extremely worrisome for a security professional. Gumblar also steals FTP credentials and appends itself to pages hosted in the webserver, thereby wreaking havoc to a webserver. This means to say that Hosting providers and webservers hosted by organizations may well have already been seriously compromised. FTP credentials have been stolen several webpages hosted in webservers all ovetr the world have been affected by the gumblar worm. The number of attacks over the last week have grown by 188% and counting and has accounted for over 42% of the malware detected all over the world. The number of infected websites has jumped from 800 to over 3000 in a matter of a few weeks.

As you can see, the gumblar botnet really goes two different types of systems. One it goes after PCs, where the PC is infected and the Google searches, Internet Explorer and the vulnerabilities in Adobe Acrobat are exploited. The other system is the Webserver, where it goes after FTP passwords and then appends the code onto all the web pages in the webserver. I first experienced this worm in March of this year and the worm has now started surfacing in all its glory. So, for all of you, here are some tips to stay safe and keep your website safe:
1. Latest AV Definitions: The biggest issue has been that Antivirus vendors except, I think, Avast and Kaspersky have not woken up to this issue till recently. Please make sure that your AV definitions are up and functional against Gumblar's many variants.
2. FTP Credentials: This is a good time to run a thorough manual and automated scan of the webserver and change the FTP credentials for all users in the system. It would also make sense for organizations hosting their web content with hosting providers to talk to them and see how their dealing with the situation. Also, please make sure that the FTP passwords are stored securely and that there is adequate encryption or hashing which is used to protect the same.
3. NoScript: For ordinary users out there, please use NoScript with Mozilla Firefox, it goes the distance in protecting you from the malicious javascript in websites against executing and infecting your PC.
4. Hosting and Web Design organizations: Please make sure that your hosting providers also take the same precautionary measures. In case you are having your website being designed by others, please make sure you test it in a staging environment before deploying it over the Internet. You might be aiding in the propogation of the worm.
5. IPS signatures: I already know for a fact that ISS Proventia has signatures released for the Gumblar worm. I am sure others would have also done so. Please keep the IPS updated for the Gumblar sigs.

Why doesn't anyone pull their security SOx up?

This is a question, which has been raging in my mind for a while now. It has been something, which I see a great scope for improvement for and something that is currently, very rarely, if ever, followed.

The Prologue
First, a prologue to the entire story. I am sure all of you know the Sarbanes Oxley Standard, popularly known as SOx. It is one of the most important compliance requirements of publicly listed companies in the US. It is governed by the PCAOB (Public Company Accounting Oversight Board), which is an independent oversight body for SOx. SOx arrived in the wake of several scams such as Enron and WorldCom. These scams rocked the business world and caused a great deal of embarassment for corporate America. All these scams had something in common; they had cooked the books (misstated financials) and this syndrome percolated to the very top, including the CEOs and CFOs of some of these organizations.

Enter SOx. SOx was the brainchild of two US senators whose last names have been given to the standard. Their take on this was that shareholders and the general public need to be able to reaffirm their faith in an organization's financial statements. This involved, first of all, establishing accountability from the top management (as they had been intricately involved in the scams previously and had the most reason to misstate financials) and providing auditors with the teeth to ensure that the organization's control environment was adequate to ensure the "true and fair" view of financial statements. Therefore, as one can clearly see, SOx is primarily concerned with the integrity of the Financial Statements and the environment in which they are processed and created. The auditor assessing an entity for SOx needs to ensure that the environment in which Financials are prepared is secure and more importantly, an environment with controls which can be relied on to ensure the integrity of information and lastly make sure that the Financials are not misstated. This involves a process many of us have heard of. Identify scope, perform Risk Assessment, Document controls, Test controls, identify gaps, continuous improvement.

The Conundrum
Our look at SOx was fine and dandy, but all that is not new, right? All of you have heard it time and time again. Especially those of you who work for large consulting firms have seen SOx being thrown around in a conversation a lot of times. I have been interacting lately, with a lot of the auditors who assess their clients for SOx compliance. My question to them usually is, "How do you assess the integrity of the environment, which is involved in the creation and processing of financial information?". Their answer to that is something like this, "We usually ask a few questions about their IT policies and procedures and establish whether we can rely on the financial statements. Our worry is more on the business processes".

When I say "financial information", it means information from all quarters which is leading to the preparation of financial statements. It means, any system which is involved in the initiation, authorization, recording, processing and reporting of financial information. So you can imagine that this is.....a lot. An ERP system which is part of the organization would be a part of it, in case of an e-commerce company, for instance, the e-commerce accounting and inventory management modules of the applications would probably need to be a part of the SOx assessment.

Let me give you, quite a real scenario and then explain the matter. What if an ERP application is vulnerable to an Application vulnerability like XSS or SQL Injection where an insider might be able to hijack sessions, gain access to the privileged information and make unauthorized changes which are not logged, not checked in any way. If an employee were able to submit an expense statement and hijack his manager's session and authorize the expense statement, with no logging. Would I, as an auditor rely on the financial statements for a SOx environment, knowing that the application could be compromised and the financials could potentially be modified or in some cases even destroyed, and more so, without being checked (no logging). Taking the business process side of things, if the same person could could initiate an expense statement and authorize it himself as part of a business process, that would be looked upon as a serious hole in the internal control of an organization and the assessor would have no doubt that it was a significant deficiency. Let us take another instance, if a business unit of a corporation were vulnerable to several network issues, let us assume that they do not have proper firewalls rules, restricting specific IP and port sets, that default passwords still exist on their network devices and servers. Let us assume that a supplier breaks into this network and overstates the value of the organization's account payables. Would, I as an auditor sign off on that entity's financials, knowing that the entity can be easily breached and integrity of data can be adversely affected?

This is just from the auditor's standpoint. A company would be held equally responsible for its negligence to IT security (as IT is a key driver in financial statements) and its reputation and business value would be seriously impacted.

Unfortunately, the scenarios I gave you have real life significance and are quite real in the corporate environment and I believe that they are largely going unchecked, because the auditors for SOx are usually not capable of assessing IT controls and are under the false belief that SOx only applies to business process and related internal control, whereas the real scenario is quite different. In today's world of highly connected enterprises, IT is a huge area of consideration. IT controls, in essence form an integral part of the entity's internal control and can significantly impact the way financial statements are initiated, authorized, processed and recorded.

The Solution
My advice to the SOx assessors and auditors of the world is this. IT security is an important consideration for any entity today. SOx does not absolve you of the duty of performing basic risk assessment and control testing (like you would do for business process with assessment of internal control to ensure that financial statements may be relied upon). Integrity of information can be made or broken by IT security in today's digital age. SOx must be treated like any other security compliance which requires scoping of processes and applications affecting financial information, performing Risk Assessment, testing controls of the processes or applications and gap analysis. As you can see, this clearly involves issues like Firewall management, Application and Network security testing, Secure Application development, deployment and configuration, Network Change Management, Logging, Integrity Monitoring, Patching, AV and all the other IT security requirements which one can formulate through effective risk assessment and best practices. Bottom line. SOx is not just a financial standard. It has a serious impact in an IT environment and from an IT standpoint.

Rediff XSS, the redux

It seems like my praise for Rediff was too quick. I had not tested out the Rediff search site exhaustively. This was brought to my attention by an OWASP Delhi member. Apparently, our friends at Rediff have not "fixed" the XSS Vulnerability in the search area. My attempts at performing a rudimentary XSS were thwarted, but I hadnt explored the possibility of encoding my payload using Javascript escape(), so this time, I tried and came up with this:













Apparently, the folks at Rediff have performed some very poor input validation and have probably only filtered the "<" and ">".

Rediff Redressal.....

My good deed was done for the week. Everytime one does something good for something or someone, one tends to feel good about it, sometimes even gloat about it.

I was surfing the Rediff Site yesterday, yes, the same one which I had eviscerated previously and entered the vile xss script and expected another tirade of scripts to rain down, but to my surprise discovered that it had been fixed. No more output encoding issues and the malicious payload seemed to have been encoded to prevent malicious XSS payload

Here is the screenshot.














But unfortunately, Rediff has not fixed a small pothole, whereas a large patch of road still remains undone. Several other Rediff sites (Rediff Products) are still vulnerable to XSS.

Screenshot:

OWASP Chennai Meet - 17 May 2009

The OWASP Chennai Chapter meet was held on the 17th of May 2009 at Chennai. It was very nice to see some dynamism from the OWASP Community in India. I am happy to see great steps being taken by the Chennai OWASP Team (Chandrasekar and the rest) in taking initiative.

The talks scheduled for the day were on Globalization and its role in Information Security and Mobile Crimes

I was invited to speak and I spoke on Application Security Risk, in a talk entitled "Application Security Risk - The Full Circle"

Here's the presentation:

OWASP Chennai Talk - Application Security Risk - The Full Circle

View more presentations from abhaybhargav.

This presentation highlights the importance of Application Security Risk and how to perform effective and comprehensive Risk Assessments for Web Applications to provide for a robust protection strategy. It highlights how an effective Application Security Risk Assessment can result in the development of a secure SDLC, feed the Security Testing area with threat modeling and the development of "Abuse Cases" and become the foundation for a strong and secure web application.

Google Hacking with Webex - Cool Recon tool

The idea for this actually sprang from a webex conference I was involved in recently. Before what turned out to be an eventually boring conference, with esoteric Powerpoint slides being shoved into my screen. I received an email from the organization that was hosting the meeting. Upon clicking the link to join the meeting, I was directed to the organization's WebEx Enterprise Site page. where I signed in using a Conference ID and a meeting password. Simple enough.

After the odious meeting I attended, as I signed out of the conference, a feedback form was thrown at me asking me how the meeting went, which I duly ignored and went about my business. This idea actually sprung in my head when I was sitting through the conference and thought about using WebEx to perform some initial reconnaissance activity for a Pen test. I noticed, before signing in that the organization had planned some more sales meetings with what looked like their prospective customers, which intrigued me.

I then put my Google Hacking Hat on and wrote a simple Google query intitle:"WebEx Enterprise Site" based on the title I had seen in the organization's WebEx site. Not surprisingly, several organization's WebEx links popped up in the Google Search results. As I started exploring around, I noticed some very confidential information up for grabs in several sites. Not only could I gain some valuable information about some sales meetings and internal group meetings they had lined up with their prospective clients or already-existing clients, not to mention internal organization members, but also some of them had recorded their conferences and these recordings were available for me to view.

While this is not a "Security Vulnerability" in the traditional, technological sense. It is a way for competitors to get some valuable info about your potential clients or your new offerings to the market (some internal meetings had the names of the products or projects these organizations were currently working on). This, is also an excellent way to perform an all-round Penetration Tests. While the ordinary Pen-test involves performing garden variety Network and App layer exercises, these methods can add significant value to a pen test and provide a bit of the old "Out of the Box" information.

Who's got the last laugh now. The Blogger XSS Vulnerability

I guess I was asking for punishment. I go looking for Web App Vulnerabilities all over the world, and sure as hell, this is what I will get.

I discovered that once I posted my Rediff Search Engine XSS Vulnerability on Blogger, I noticed something I had seen all too often, the Javascript alert with the rudimentary XSS, and this time, it was on my blog. I was not to happy about it to say the least. I thought "Some Smart Alec must have written up a comment causing the XSS alert, but I was quite sure that couldnt happen because Blogger had some sort of a filter on the comments. I then realized that the XSS alerts were popping up because of the XSS vectors in my Rediff post.

Surprisingly Blogger does not do any kind of validation or output encoding to prevent against these attacks in the posts section. So the blog-author can potentially be serving up XSS on his/her blog and potentially be exposing all the visitor's accounts with that, and since Blogger is a Google service, my session credentials are good for any Google Website. Mail, docs, everything.

But its ok now folks, the bitter pill of my own medicine has been swallowed................ or has it?

Rediff Search Engine XSS Vulnerability

This was something which was quite shocking as the series of events unfolded. I was researching up on output encoding methods to prevent against Cross Site Scripting and I experienced the full blown effect of the evils of bad/no output encoding and of course, no Input validation.

This was something I discovered on Rediff.com's search engine. When I typed in "search:followed by the Javascript alert, I received the infamous Javascript alert with simple 'XSS' written all over it. I was a little perturbed, because my NoScript said that it blocked a cross site scripting attack against taking place, but why was the alert still popping up? Then I was sure that the site was vulnerable to cross site scripting and decided to write about it. When I clicked the "Ok" on the Javascript alert box, another one popped up. This was definitely odd, I hadnt configured the alert for more than once. Then I clicked OK once more to find that there were more Javascript alerts to arrive with things like "XSS", session cookie details, "try_xss" and other alerts which I hadn't written. I then realized that rediff's search engine is scouring the web for pages with the XSS variants was executing that script on the rediff site, which was, beyond imagination and quite horrible. As I was clicking "OK" on the Javascript alert boxes new search results kept showing up and new alerts kept popping. The alerts only stopped with the end of the page.

Not only is Rediff vulnerable to XSS, Rediff has failed to encode their outputs from the search engine and is serving the xss, fresh from other websites, which have ironically, encoded their outputs.


I tried this out on a Google page, but it didn't work .

Anyone want to play around with the Search string try and enter your regular XSS reflected XSS tags check it out.

I have informed Rediff about the vulnerability, hopefully, they should rectify it soon.


Here are the series of screenshots of the xss alerts and the search results expanding each time.

The Berkeley Data Theft

I just received word that the University of Berkeley has had a major security incident.

The Campus Health Services Center databases have been hacked (supposedly by foreign hackers) and over 160,000 records of PII (Personally Identifiable Information) have been exposed and may have been stolen.

According to the university, the databases contained individuals' Social Security numbers, health insurance information and non-treatment medical information, such as immunization records and names of some of the physicians they may have seen for diagnoses or treatment.

It is believed that the breach began sometime in the month of October 2008 and continued till April 9th 2009, when the campus administrators discovered the breach. The University has said "The attackers accessed a public Web site and subsequently bypassed additional secured databases stored on the same server."

This seems like another Web Application attack, where the attackers have been able to gain access to Databases using the Web applications and cause the breach. It might be a case of SQL injection coupled with various other types of attacks.

This is a "wake up call" for universities all around the world. Universities are perhaps the largest repositories of data (student data) and they have access to sensitive information about the students. Such breaches can cause massive instances of identity theft.

I find this even more alarming thinking about the Indian state of affairs. India's universities have recently taken to computerization and the number of students in Indian universities is a mind-boggling number of something like 8-10 million. Such security incidents put all that data at risk.

Incredulous Interactions with Web Application Developers: 2 of Many

Here's wishing that all of you have a good weekend. I left early from the office today to attend to some household duties. While I was sitting and watching TV, I came up with a concept, which resulted in this title. I interact with several application developers over the past few years and now as I steeped in AppSec, I have been interacting with a lot of Web Application Developers during my application assessments. Normally, they are a nice bunch, who are quite convinced about the authenticity of my claims of having their applications torn apart on the internet. But, everytime I discuss security, there are always this few developers who end up astounding me or completely disarming my constant efforts to bring about change in the way they think (or don't think) about Web Application Security . I thought, "Why not chronicle my interactions with these people, for the benefit of the community, and for a few laughs (or atleast a smile) in the normally tense lives of security folk?", and so, I present to you, the second in the series of "Incredulous interactions with Web Application Developers". You might be wondering what happened to the first of the series. It is the first entry in this blog, but has not been grouped under this title. Anyway here it goes....

It was at the end of the day, and I had almost finished assessing this application. The application was being developed by a small group of developers working for a small company. Their product claimed to be the only one of its kind and one of their potential clients wanted the application to reviewed for security.

I had reviewed the Application for over 2 days. I had spent some time interacting with the project manager and the developers, and had performed a combination of black and white-box tests on the application. The application had some serious issues, there was almost no validation and whatever little validation it had, it was on the client-side, utilizing trusty old Javascript. I knew it was a problem. The developers were quite sold when I showed them a Cross Site scripting PoC as well as a Embedded Flash injection PoC. The only problem was getting through to the Project Manager. He was not convinced, and a conversation on the following lines ensued.

I used Burp proxy to perform my scripting attacks and he said this. "This application is going to be used only by the Company employees. why will they want to steal this data from the company?", for which I gave him standard insider threat lecture, statistics, et all. I tried explaining to him the fact, that this application stored extremely sensitive data (which it did) and an insider would also have a clear motivation to break into the application to steal information, not to mention disgruntled employees, or other employees with malicious intent. I also explained to him the CSRF angle, where this site might be attacked by another site violating the same origin policy.

He was yet unconvinced and he said, trying desperately to prove a point, "I have worked for over 12 years in Software development and have developed dozens of applications, never before has a client asked me for all the security features you are asking me for, it seems that you just want to prove a point." I burst out laughing at this and told him that if he believed that his potential clients weren't concerned about security, then they wouldn't have engaged my services to perform the assessment. I also had to tell him, that the way he or anyone else has been developing web apps in the cavalier manner that they have been all these years, does not make it right. Quantity is not quality, I told him and I also informed him of the fact, that awareness has been rising in the community about the effects of web application attacks, which is the reason why, if he wants his product to remain competitive and viable in any market, he would have to do "complicated things" like input validation based on a whitelist of "known good" characters to prevent against a smorgasbord of attacks. I told him finally that it would be for the benefit of the application and the data it holds as all these measures would prevent against any untoward incidents and not result in loss of reputation for his company. The man finally backed down after that and we discussed some implementation strategies for input validation across his web app.

This got me thinking, that developers have churned out several thousands of web applications which are working all over the internet and organizational intranets over the years. This was a single project manager from a single small company, who had himself been involved in the development of over 20 applications in his career. It would be quite scary to think of other developers over the years who would have developed similar applications with similar if not worse vulnerabilities.........

Overreliance on Javascript: Pen-tester's pet

I am sure all of you have been acquainted with the input validation situation where the developer validates all his input on the client-side using some poorly written Javascript to boot. Well, I recently experienced a new high in Javascript overreliance, and this was precious!!

I came across an application which relied heavily on Role Based Access Control. The Application is an Enterprise Application which has several types of users and several different "screens" that each user can access, thereby restricting the user's access based on the user's role. Well, this is how a traditional access control system works.

So, what would one do to ordinarily circumvent these controls? The first thing I tried was the URL route, where I scanned the app for URLs and entered these URLs to elevate my privileges. I was easily able to do this and the pages that clearly weren't meant for my user role kept appearing. When I tried to input some data and submit the form, the server threw me a big fat Javascript alert, "Access Denied".

Then I revoked the temporary permissions on my NoScript and the entire application fell apart. The Application so heavily relied on Javascript that the access to the links was controlled using Javascript only.

The code went something like this:

function Menu()
 {
 var UserRole=document.getElementById('userRole').value;

 switch(UserRole)
 {
 case 'elevatedPrivUser':      
  document.getElementById('thisScreen').style.display='none'; 
  break;
 case  'lowerPrivUser':       
  document.getElementById('someOtherScreen').style.display='none';
  break;
 case 'evenLowerPrivUser':
  document.getElementById('yetAnotherScreen').style.display='none';
  break;

As you can see here the Developer had left this brilliant bit of Javascript on each and every page. This was the basis of the Role Based Access Control System of the Application. Then I thought, surely, even if I accessed any one of these pages and tried to submit a request, the server would stonewall me and throw me out. I tried it out. Guess what?....More Javascript. Luckily, the Javascript wasnt available on plain view in that page, but clearly Javascript was the only validation which had been provided to validate user role and by disabling Javascript, I was able to pass my request over to the server which was accepted instantaneously.

So, the next time I go try to test an app for elevation of privileges, I will not bother with the session hijacking or the sniffing. I will just ask my NoScript to do the job and I will check whether the developer believes that "Client-side Scripting is the best!!!!"

The Devil's Advocate: Compliance vs Security

The fires in blogosphere are ablaze with talk about the Heartland Payment Systems breach. There has been a great deal of PCI bashing, right from Bob Russo's statements to the whole issue of Compliance and Security.

For those who are not aware of the HPS, or who have had their head in the ground because of the current economic meltdown, I shall recap. Heartland Payment Systems is a large Payment processor in the US. Malicious software in their payment processing network seems to have caused one of the largest breaches in history. It seems as though over a 100 million cards may have been stolen. The great gory details of the story are not known yet as forensics for this sort of thing takes quite a while.

Security vs Compliance is one of the most significant things I have heard being posted all over the Internet. Everyone seems to be talking about the fact that Compliance cannot be equated to Security and that the PCI Standards are flawed in their attempt to make their industry more secure.

Us security folk secretly love an incident of this magnitude. Its incidents like these which makes people sit up and take notice of security needs and this is our time to shine :) But on a more serious note, let us take stock of some important facts at this point.

Agreed, Security != Compliance. I believe strongly that those who expect their plain-vanilla compliance program to do miracles for them. Compliance can never take the place of a voluntarily committed security program which comes from experience and a proactive risk approach. But, at the same time, one cannot simply discount the fact that compliance is important. Take the case of the American Capital markets. The deregulation (lack of compliance and enforcement) did not ensure that all the Banks and large Investment houses take a "Safety First" stance. They continuously created their weird and arcane financial intruments, which were toxic for the economy. Until there was a Sarbanes Oxley for the Corporate world, there would be no accountability for any of the Top Management's statements and actions (case: Enron). In fact, only the stick that is accompanied with non-compliance (fines, increased transaction costs, de-listing, etc) gets some companies adopt a security program. The carrot that comes (proactive security, better understanding of risks, threats and vulnerabilities, etc) with compliance simply does not appeal to these companies.
In my time handling several PCI projects, I realized that there are always a bunch of organizations which are driven towards genuinely acheieving optimum security and not just chasing a certification and there are others, who decide to "dress their processes well" before the auditor walks in. We need to understand that there are always going to be organizations like the latter and accept the fact that these organizations can only be driven to better security by incentivizing them in forms such as low cost of security, increased business opportunity because of enhanced security and of course, once they get hacked and lose data and reputation (and if they are still not bankrupt in the process), would try and develop a proactive, risk based approach to security. This brings me to my second point....

PCI = Risk-based Security Compliance. When I hear someone talk about PCI Compliance, I usually hear the word "checklist". PCI is viewed as more of a checklist assessment and once the checklist is filled with "Yes", everyone's happy. This is very very far from the truth. Companies and Security professionals who look at PCI in this light are actually getting it all wrong. PCI is nothing but Asset Based Risk Assessment, where the asset in question is Cardholder Information and the ultimate objective is the protection of Cardholder Information. Which is why Security pros need to understand the systems of interest, access paths, points and containers in which the asset is housed and devise security solutions based on the PCI Requirements. One cannot advise a small organization getting PCI Compliant to drive its entire encryption process using a HSM (Hardware Security Module) or a large processor like Heartland to use something like TrueCrypt to drive encryption. Yes, PCI is granular, PCI is very clear on most counts, but by treating PCI Compliance as a checklist assessment or a checklist compliance program, security assessors are actually saying that Compliance = Security, which brings me to my next point.

In the long run, compliance ultimately becomes "bastardized" because of the people advocating and following it. The same thing happened for ISO-27001, which is a great standard, but eventually became mis-understood and mis-interpreted beyond recognition. I came across and ISO-27001 certification which was only done for the "Security Components" of a company's infrastructure (namely 2 firewalls and 2 routers, in which case the routers are not actually a "Security Component"). There is nothing inherently wrong with the standard. It is just that for the sake of convenience of both the security assessor and the assessee, the standards are interpreted in a way which does not take into account, the all-important aspect of Risk (which is unique to every organization). So, to re-iterate, when an organization is going in for PCI Compliance, it needs to determine what kind of entity it is. Is it the former type, proactive, and risk-based towards security needs, or is it like the latter, the "Chasing certifications 'cause I need this business" type. If a company actually believes that it is in the first type, then it needs to evaluate security professionals who share the same values and ensure that the professionals deliver on their promises at performing a solid evaluation of risk and then concomitant controls.

In conclusion, I would like to say this. Although Compliance and Security are not necessarily the same thing, we need to appreciate the fact that compliance, when interpreted and enforced correctly does eventually lead to a solid Information Security program. It is upto the people in the organization to determine what they want, Compliance leading to Effective Security or Compliance just leading to.....Compliance.

Payment Application Pacman

Lately, I have been flooded with Application Security Assessment work. Applications of all forms, shapes and sizes have been given to me to test, which I have gleefully accepted. The work is supremely interesting. I always knew that there were tons of applications being developed all over the place, but I always figured that they would be of a certain nature, like a plain vanilla E-Commerce Application or a Banking Application, etc. Because of the spate of application security testing I have been doing recently, I have found that there is an application for everything. Right from Flea-Market Management to Cold Storage Management Applications. The granularity of business verticals which applications are catering to today are mind-boggling. Wait, I think I have diverted from my story, haven't I? Damn, I do this all the time, okay, back to the story.

I was testing this application for Payment Card Industry Compliance recently. I was quite impressed with the application at the outset. The application seemed to be loaded with some innovative features and it seemed like a great application for the business vertical it was hoping to address.

I started to test the application a few days later. It was sometime in the evening. I was not in the mood for any more testing. I had done quite a bit that day. I had already finished a preliminary vulnerability assessment of the server and as the assessment would be performed over a few days (yes, I procrastinate, a lot!), I thought of playing some Pacman. It is one of my favourite games. I thought of a slightly weird way to play it. The application I was testing was structured in a way where the user would use the input fields to enter values to be stored in the Database and as the Database updated, the previous inputs would be displayed in the table below it. Great way to test for persistent XSS, thought I. Therefore, I entered this harmless reflected XSS script alert in a field


and this is what I got


"Not bad", thought I, "the developers have managed to keep the bad apples out, or could it be the simplistic process of weeding out the angular bracket using a even simpler client side validation routine?"

Not to be deterred, I fired up my ever-trusty WebScarab and decided to take this attempt at killing two birds with one stone (namely me wanting to play Pacman in a different way and app sec testing) and caught a perfectly harmless request and gave it a interesting twist. I entered as input an html embed pointing to the Pacman Flash game, a lo I was gleefully playing Pacman on an application which had no business storing this in its Databases. One part of my test was done, quite a finding too. Cross Site Scripting (and later CSRF) vulnerabilities rampant on this site.

Coming back to my initial tangent. There are around 108 million distinct websites in the world today and even now, 23% of the world's population is exposed to the Internet, which is looking at a meteoric growth pattern in the future. According to the WASC (Web Application Security Consortium), almost 50% of web applications are vulnerable to Scripting and Information leakage vulnerabilities. As development becomes easier for everyone, we are only going to see more number of sites and apps falling prey to session hijacking, SQL Injection, Denial of Service and many other evolving attacks.

BTW, You can play the evergreen Pacman here

The Indian Broadband Consumer and the Vicious Circle of Insecurity

This article was the result of a trip to my grandmother's house in Mysore(a small city in Karnataka, South India). My granny recently took to computers and the internet and has been hooked ever since. She never forgets to send all of us, a large number of e-greetings for every festival or for any other momentous occasion like birthdays and anniversaries. She keeps in touch with my uncle, who lives in the US and is now looking at having an online banking account, which will enable her to make things very very easy for herself. She has got a laptop and a Wifi connection at home. Some friends in that small neighbourhood in Mysore also have the same tools. They use these gizmos to keep in touch with family, and pretty much do the same things my granny does.

It was a saturday when we got there and I opened up my laptop for checking my mail and some other "cloud based" activities. Her Wifi was on. It was WEP enabled and it took me all of 2 minutes to crack the WEP key. When I cracked and read her WEP key, I began to think horrible thoughts. I had visions of bots, paralyzed networks, stolen identities and ladies like my granny being named as attackers in a online banking fraud scheme. Let me just break some of these visions down for you.

First, some statistics. India has seen a phenomenal increase in broadband penetration. It is currently rank 18 in the list of countries with highest broadband penetration and will take a giant leap to rank 6 in the same list in 3 years time. The growth rate for broadband in India is likely to be whopping 489%, which is double the second-largest growing market, Vietnam, which is 276%. Secondly, Wifi has also taken off in a big way. People are waking up to the fact that Wifi is an extremely convenient way to connect to a network or to the internet. I can attest to this fact, because my granny's neighbourhood in Mysore has around 50 homes and almost all of them have broadband internet and wireless routers. Laptop sales have also been growing at a scorching pace in the country. India registered a 114% percent growth in laptop sales with 1.8 million units getting sold in '08. According to India’s Manufacturers Association for Information Technology (MAIT), laptops account for 25 percent of the total PC market in 2007-2008, shooting up from less than 3 percent in 2004.So, as you can see, as tech costs are being driven down, these technologies are in everyone's reach and it is great. The world should be able to harness the power of computers and the internet in all its glory. But once again, as always, with great power comes some serious security issues.

I am sure some of you are aware about the concepts of bots. Nevertheless, I shall explain. Wikipedia defines bots as so "Internet bots, also known as web robots, WWW robots or simply bots, are software applications that run automated tasks over the Internet. Typically, bots perform tasks that are both simple and structurally repetitive, at a much higher rate than would be possible for a human alone. The largest use of bots is in web spidering, in which an automated script fetches, analyses and files information from web servers at many times the speed of a human."Bots are used heavily for malicious purposes. Ebay sued a bunch of third party bot makers that were scrounging sround ebay and making repititive bids for products at low prices, but once the lawsuit became public knowledge, ebay had to deal with hundreds more of such bots. A botnet is a group of compromised computers which have been overrun by bots send by a bot-herder. The bot-herder may compromise your computer through a variety of ways like viruses, trojans, backdoors or even through a Instant Messaging Application. Once the bot is in your machine, your machine has now become a zombie and does the bidding of the bot-herder. The bot-herder may use your machine for anything. Let me just give you an example, In 2007 there was a bot called the "Storm worm" which an email attachment. The email was something like this "230 dead as storm batters Europe" and it contained a trojan horse and like this managed to become one of the most popular worms of its time. It resulted in 8% of all malware infections all over the world. This is just an example of one bot. My friend downloaded some files using peer-to-peer networks like Torrent and other sites and he had keyloggers which had managed to sneak past his "Anti-Virus" program and manifest in his machine. A keylogger is a tool which captures all the keystrokes entered into a computer and sends the data to a bot-herder. So, the next time you want to shop online with your credit card, you will have to type it in, right? and if there is a keylogger, well...you know where I am going with this. Botnets are also used to attack different websites and IPs. If you have a bot-infested computer, chances are that you are attacking the website of a company, and you dont even know it. As I type this, a new worm affecting Windows has just made the news and it seems more than 4 million PCs all around the world have been affected by it.

So why is this article on India? This can happen all over the world, why are you talking about India only? Well, yes. This can happen all over the world, but you see, it happens in places where this faster internet speeds. For instance the Sobig virus, which was used as a spam propogator, uses the faster internet speeds available in broadband for propogating millions of spam messages. India and China, which have been growing in their appetite for broadband internet have fueled this new bot wave. In fact, researchers from all over the world have said that the bot activity in the US and Europe has been static, but there has been a new wave of bot activity in Asia, especially from India and China, due to sheer numbers.

What is the vicious circle? Let me just tell you how some of practices which are innately Indian, fuel this sort of botmania. I am sure you would all agree that pirated software is rampant in this country. 70% of software in India is pirated. Most people use tools like Torrents or other peer-to-peer networks to download their favourite apps and give them a whirl. Many of these applications have key-gens or key generators which generate keys for a particular application and unlock the full versions of these apps. These keygens usually contain malware and when you run it, eager in anticipation of getting that new application, you want so badly, but are not willing to pay for, then that small trojan is installed on your machine and you are not the one who has the last laugh.

The other major issue with this bot menace in India is that the majority of our broadband consumers arent aware of Computer Security vulnerabilities. This is true of most countries, including the US, where the large percentage of Internet users are blissfully unaware, but it is worse in India. Compounded with the piracy issue and fledgling broadband industry and a general "cost sensitive" attitude (with reference to investing in Anti-Virus and Anti-Spyware solutions) India will be the next big botnet destination.

There is one other practice, that I want to highlight. This is not perhaps, directly related to bots, but it is a seriously unsafe practice. Coming back to my granny's house. Her WEP key, which the ISP had set up was her phone number. In India, most telcos provide the Internet bundled with a phone line, or they tie your Internet plan with your phone. So, they usually stick the phone number as your wep key. First of all, WEP is totally insecure and secondly, anyone would be able to access any other Wireless Access Point in an area, if they know the phone number, can freely mooch off other people's Wireless Internet connections. I tried to experiment with her neighbour's Wireless AP and it worked quite easily. This is another disturbing trend. In India, most broadband Internet connections are metered, i.e. consumers are charged based on their usage, and if we have a situation like this, some neighbourhood moocher can download 100s of GBs worth of data without ever having to pay for it. Most people wont even know what a WEP key is, forget changing it. Their laptops only need the WEP key once in their lifetimes and then they are pretty good to go. The telco engineer entered the WEP key in my granny's laptop for the first time, since then she has been good to go, totally oblivious that there is even something called a WEP key. Not to mention, the Wireless Router (Access Point) has a default username and password set, which is "really hard to break".

I think one can suggest a really really long list of protections for this sort of thing. Being in security, I hear of news exploits and protection mechanisms every day, but for me, it really comes down some basics. They are:

1. Don't open email attachments which look suspicious. Things like "You won a lottery" or "Cheap drugs" or from senders titled "me". These emails should be junked, and fast.

2. Use a good Anti-Virus Program. Use a Legitimate and Non-pirated Anti-Virus program. For all you recession freaks, AVG is a possibility (its free!!!), Avast is not bad either. It is quite good. More than just using an Anti-Virus make sure that it is updated regularly. Most Anti-Virus providers provide daily updates of their Virus definitions. Make sure that your AV Application is updated.

3. Use an AntiSpyware Application. Spyware from the Internet is one of the prime causes of malicious programs entering your system. MalwareBytes Free Anti-Malware Application is pretty good for this purpose.

4. Use Licensed Software. If you are using Windows for which you have no serial information, you are most likely using a pirated copy. Windows Update is required, as Windows is a bunch of holes and they issue a huge number of security patches for fixing bugs in Windows Security. Consider moving to other OSs like Ubuntu or Mandriva (Linux based OSs) if you are relatively tech-savvy or are open to experiment. They are not invulnerable to viruses and malware, but they are definitely more robust and relatively impervious to malware.Like I said earlier, Malware can spread through Key gens and cracked software downloaded from the Internet, so if you are not buying a commercial app, stick to Open Source.

5. If you are using Windows XP or Vista, enable Windows Firewall and Windows Defender (Vista only). They are not the best, but with good Anti-Virus and Malware tools, they keep you quite safe.

6. Wireless (In)Security. Dont use WEP keys on your Wireless Router. WPA is safer and definitely more recommended than WEP. Dont use easy to guess information as keys, like your phone number for instance. Also, dont forget to change the default password for administering your Wireless Router and Broadband Modem/Router.