Aujas US

An IDG Ventures Company

PCI DSS Version 2.0 – Ready?

A quick introduction to PCI DSS
Payment Card security measures
The Payment Card Industry Data Security Standard (PCI DSS) is a set of comprehensive requirements for enhancing payment account data security. It was developed by the founding payment brands of the PCI Security Standards Council, including American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc.

The PCI DSS aims to facilitate the broad adoption of consistent data security measures on a global basis. These data security standards cover everything from the point of entry of card data into a system, to how the data is processed, through secure payment applications. The PCI Security Standards Council seeks to protect and educate industry players such as merchants, processors, financial institutions, and any other organizations that store, process, and transmit cardholder data around the world.

PCI DSS version 2.0

The release of the new PCI DSS version, numbered 2.0, seems to be a source of relief to many organizations in the credit card industry as it introduces only a few new requirements and offers greater clarification and guidance to help merchants with their compliance efforts. While there were fears that the PCI Security Standards would introduce dramatic changes between version 1.2 and 2.0, instead it does much to sharpen standards with guidance and clarification of the main themes.

With 2.0, the PCI Standards Council is trying to strike a balance between its goal as a standard for securing cardholder data with the realities of implementation by the merchant and vendor communities. The changes and guidelines are more about the administration of the PCI compliance process. Organizations already compliant with 1.2 will not find it difficult to comply with 2.0.

New approaches and standards

The new standard provides a much clearer timeline for compliance with the January 2012 deadline, giving organizations time to plan and move to version 2.0. However, unlike the previous version, PCI DSS 2.0 takes a more risk-based approach, providing Qualified Security Assessors (QSAs) in organizations with more discretion in deciding what level of security is appropriate to the circumstances.

For example, the standard in encryption key management that has always required keys be refreshed annually has now been relaxed, allowing QSAs to make an informed decision on when to refresh. The new standard also advocates the value of storing system logs, both to avert attacks and trace the cause of any breach. With updated system logs and effective software solutions, organizations would be able to detect earlier if systems are being attacked.

Among the clarifications in the PCI is the reinforced need for merchants to use a “discovery methodology” to find cardholder data in their networks as well as guidance on how security should be handled with new technology such as virtualization and cloud computing. While most organizations seem to have welcomed the renewed focus on risk, a few preferred regulations detailing what exactly should be done. The new standard moves away from Open Web Application Security Project (OWASP) to allow for others. The standard also leans support to virtual machines running on a physical server as long as each serves one primary function.

Conclusion

Though the standard has not changed any paradigms, it has rationalized and adopted a more pragmatic approach. It has moved away from rigid requirements around vulnerability management, lack of support of virtualization and OWASP to a risk-aligned vulnerability management, support of virtualization and key guidance on log management. Overall the new standard provides greater clarity on security requirements, improves flexibility for merchants, helps manage evolving risks, aligns with industry best practices and decreases redundant sub-requirements.

Advertisements

November 29, 2010 Posted by | Data protection, IT security | , | Leave a comment

New Trends in Phishing Attacks

Quick Introduction to Phishing

Trends in PhishingThe convenience of online commerce has been embraced by both consumers and criminals alike. Phishing involves stealing consumers’ personal identity data and financial account credentials. Social-engineering schemes use fake e-mails purporting to be from legitimate businesses to lead consumers to counterfeit websites designed to trick recipients into divulging financial data such as account and PIN numbers. Technical-subterfuge schemes plant crime-ware on PCs to steal credentials directly, often using systems to steal customers’ or organizations’ sensitive information.

Besides the obvious threats associated with phishing, other adverse effects include decreasing customer confidence in online commerce, and financial losses experienced by both businesses and consumers.

Although progress has been made in identifying threats and developing countermeasures, there has also been a simultaneous increase in attack diversity and technical sophistication in phishing and online financial fraud. Technical crime-ware resources are readily available and have been streamlined and automated, allowing for use by amateur criminals, making phishing economically viable for a larger population of less sophisticated criminals.

Latest Phishing Attacks

  • Tab Napping – Imagine you open the login page for your Intranet portal, but then you open a new tab to visit another website for a few minutes, leaving the first tab unattended. When you return to your Intranet Portal the login page looks exactly how you left it. What you haven’t realized is that a fake page has taken its place, so when you type in your authentication credentials, you have inadvertently given the fraudster easy access to your account.

 

  • Spear Phishing – This is a  rising phenomena that uses official-looking e-mails to lure people to fake websites and trick them into revealing personal information. However, unlike traditional phishing, spear phishers do not send thousands of emails randomly, but target select groups with something in common—they work at the same company, bank at the same financial institution, attend the same college, order merchandise from the same website, etc. The e-mails are ostensibly sent from organizations or individuals the potential victims would normally get e-mails from, making them even more believable.

 

  • URL Obfuscation – As users learn to detect fake emails and websites, phishers use techniques such as URL obfuscation to make phishing emails and sites appear more legitimate. This mechanism misleads the victims into believing that a link and/or web site displayed in their web browser or HTML-capable email client is that of a trusted site but are then redirected to a phishing site. For example, if the legitimate URL is http://www.login.example.com, the phishing URL may be http://www.login-example.com, thus tricking the customer into trusting the site by using an easily overlooked substitution.

 

  • Filter Evasion – This is an another e-mail phishing attack where attacker sends mail with picture images attached to malicious websites to retrieve personal details.

 

  • SMishing – Attacker uses SMS to launch phishing attack on cell phones to steal sensitive information. Scam message direct you to click on malicious banking websites or call a phone number. If you visit the link it downloads viruses into your system or if you dial the number will be asked for personal information.

 

  • Specialized Malware – Over the last couple of years, malware has been increasingly used for criminal activity against users of online banking and commerce sites. Specialized malware available today can easily be reconfigured to target information from a number of different websites. Malware also provides several mechanisms for stealing data that is then used for identity theft or stealing money from a victim’s account.

Conclusion

Though people today are more aware of phishing, countermeasures need to be designed in order to deal with the increasing technical sophistication of criminals conducting phishing scams exploiting human vulnerabilities.

Phishing awareness needs to grow to include law enforcement and employees of targeted businesses so that they are able to accurately recognize scams targeting them. It is also important to remain vigilant by developing and enforcing countermeasures, making the resources for phishing both scarce and expensive with increased policing and thereby making phishing less profitable.

The message is clear – the key to protecting oneself starts with continuous education and awareness.

The Aujas Phishing Diagnostic Assessment can help your company assess and remediate phishing risks. For more information about the Diagnostic, or other Aujas services, contact Karl Kispert, VP of Business Development at 201 633 4745 or karl.kispert@aujas.com.  

November 29, 2010 Posted by | Cyber Crime, Phishing, Social Engineering | , , | 5 Comments

Mobile Security with J2ME

J2MEWith the large number of financial applications that are available for Java-enabled devices, security is of paramount importance. Java 2 Micro-Edition Connected Limited Device Configuration (J2ME CLDC) is the platform of choice when it comes to running mobile applications on resource constrained devices (cell phones, set-top boxes, etc.). The large deployment of this platform makes it a target for security attacks. The intent of this article is to provide some insight into J2ME security and the common mistakes when developing such applications.

J2ME has fewer features than Java and has a smaller and efficient Java engine designed for small devices.  We could divide the security of J2ME into three categories:

  • Compile/Runtime Security
  • Database
  • User awareness

Compile/Runtime Security. Java compiler and runtime environment through the provision of non-customizable classloaders, pre-verified midlets, protection domain policy and limited/no access to native/reflection API ensures the safety of the mobile devices.  

One of the key improvements over the few years in MIDP is to allow only the trusted application to call the protected API. All trusted API’s would be signed. The trusted store in the mobile phone is usually populated with certificates of manufacturer’s choice and not all known CA’s root certificates are part of the store. The J2ME permission class cannot be inherited to customize the need. Also the permissions are not really atomic to allow finer control. Once permission is obtained by the application from the user the application is allowed to use the resource however necessary.  

Database Security. One of the most ignored parts of the J2ME is the RMS database. The database is a simple byte-level file that stores the contents on the local phone. The security of this file is left to the manufacturers and the application developers. Most of the time the application developers are under the belief that RMS database file is safe to use and it’s well protected. This is not the case. A simple example would be to install the application on a memory card and later on mount the memory card in a computer. You could see almost all the files including the RMS file. Application developers need to realize that nothing is as secure as or more secure than their application. Application-level encryption is a must to protect the local data in the RMS database.

User Awareness. Another factor that J2ME developers should be aware of is the knowledge level of the user base. The mobile phone user is not aware of all the computer-related functionality. The fundamental difference in the user base demands a security at higher level which is less complicated. The current basic security that is implemented in all J2ME application is the certificates.  The expectation that an average user in the market would understand a certificate and invalid application is questionable. As an average phone user, the trust of an application comes from his interaction with it. This interaction should be simple enough for the end user to understand. A better user interface design could help the end user understand the messages that he sees on the screen.  Companies should take special initiatives to spread the security measures.

Bottom line, one should understand that a mobile phone is not better than a laptop; it’s pretty much the same in the hackers’ view.  Beware and be Secure

November 29, 2010 Posted by | IT security, Mobile device security | , , , , , | Leave a comment