Tag Archives: Qualys Inc.

About 1572 days ago Business Software

Web Applications: The Coming Threats

our beautiful site

If you’re looking for a secure form of computing, you can certainly do a lot worse than software-as-a-service (SaaS), but like any technology, SaaS is far from 100 percent secure. SaaS, a remotely operated form of computing offered by the likes of Salesforce.com, nSite (part of SAP Business Objects), Qualys and others, is growing in popularity among small and mid-sized businesses, but still has fairly low penetration. A survey by Forrester Research, of Cambridge, Mass., of businesses with fewer than 1,000 employees in 2007 showed only 11 percent were using SaaS. “It’s starting to expand out and playing a much more crucial role,” says Liz Herbert, an analyst with Forrester. The appeal to small business is obvious. Having software managed by a third party obviates in-house IT positions and places the onus on maintaining consistent uptime (99.7 percent seems to be the norm) on someone else. Moreover, security concerns are fewer than with in-house systems. “It hasn’t prevented people from signing up,” says Robert DeSisto, vice president and distinguished analyst at Gartner, of Stamford, Conn., said regarding security. “I wouldn’t say it’s a big issue, but it’s an issue.” Security concerns The truth is, there are security gaps in any kind of technology. SaaS programs are vulnerable to the following threats: Mass SQL bots, which compromised hundreds of thousands of websites. The loss of data. And the publishing of confidential data on the Internet. Those are worst-case scenarios and not all that likely, but if you’re contemplating a contract with a SaaS vendor, Wolfgang Kandek, CTO of Qualys, recommends hitting the prospective company with questions about their approach to secure computing. First, Kandek suggests tackling the loss-of-data question. “You should ask, ‘If I lose data, how will you get it back to me?’” Kandek says. While most companies will back up information like CRM databases as a matter of course, a bigger issue is if such information is made available to the public or competitors somehow. Kandek deems it unlikely that a competitor would go so far as to hack a rival company to get such information. A more likely scenario is that the information is made available as collateral damage during a random hack or bug attack. Questions to ask a provider For the latter reason, Kandek advises that those who use Microsoft’s SQL Server especially to grill their potential SaaS provider about how often they update their software with patches provided by Microsoft and the like. “Patches could be important so you should ask when they do it, do they wait until the weekend or do it as soon as they can. That gives you a good idea of how diligent they are about it,” Kandek says. The issue doesn’t just apply to Microsoft. Even if you’re using a Linux-based system, there are patches issued on a regular basis that may be relevant. Kandek says another question to pose is about data security. “You should ask, ‘How do you make sure it doesn’t go away,’” he says. Meanwhile, Kandek says you can ask vendors for Web application codes for further reassurance, but you’re unlikely to get them. “That is usually considered proprietary and competitive information,” he says. Another tip is to ask for a third-party security monitoring of the prospective firm. While there’s always the possibility that such results could be questionable (the monitoring firm could be in cahoots with the SaaS vendor), there are ways of checking the integrity of the third-party monitor. In the end, just as there is no 100 percent guarantee of security with any form of computing, there’s no way to be completely certain that your vendor is on the level, either. “You can be defrauded,” Kandek says. “It’s a trust relationship you have to build.”

About 1634 days ago Computer Security

What New PCI Standards Mean to You

If your business accepts credit card payments, then the way you handle that data is governed by Payment Card Industry Data Security Storage Standards (PCI DSS), not as a matter of law, but as part of your contract with the credit card companies whose cards you accept. Depending on how much you follow such things, you may or may not know that those rules changed Oct. 1, when the Payment Card Industry Data Security Standards Council issued PCI DSS 1.2. Most of the changes are relatively minor, and intended to clarify points of misunderstanding contained in PCI DSS 1.1, which has been in effect since 2006, according to Bob Russo, the Council’s general manager. “People call us every day and ask, ‘Do security rules apply to routers?’ or to ask what we mean by ‘a regular basis,’” he says. The current changes are mostly intended to clarify this kind of confusion and remove redundancies, Russo says, but, he adds, “We did draw some lines in the sand.” Crossing those lines is a bad idea, with consequences including stiff financial penalties and increased transaction fees. Rather than take the risk it, it makes sense to learn about the new rules and the changes your company might need to make to comply with them. There’s no room to list them all here, so to get a complete picture we recommend reviewing both the new standards, and a summary of the changes on the Council’s website. Meantime, here are the items most likely to affect your business. WEP is disallowed. Wireless networks that contain or transmit cardholder data must be protected by encryption, and wired equivalent privacy (WEP) is no longer acceptable according to Requirement 4.1.1. It must be replaced with Wi-Fi protected access (WPA). “Over the years, WEP has been proven to be not as good as originally thought,” Russo says, and indeed the Internet offers many articles and videos that purportedly explain how to break WEP encryption in 10 minutes or less. “In the new standards, we said we don’t want to see any new WEP implementations after March 31, and existing implementations to be phased out by June 30, 2010,” Russo says. All systems “commonly affected” by malware must run anti-malware software. “It’s two changes in one,” notes Anton Chuvakin, director of PCI compliance solutions for Qualys, a software-as-a-service provider of security and compliance software and services. “The previous requirement was to use anti-virus software; now you have to have anti-spyware as well, and you have to extend it to all systems.” Those running the Linux operating system, for instance, might previously have skipped this step because few, if any, viruses or other threats are directed at Linux. The Council won’t specify exactly which systems are considered “commonly affected” by malware, except to say that most mainframes and some Unix-based server operating systems are probably exempted. But, it notes, the world of malware changes quickly and compliance with Requirement 6.2 means staying vigilant about the possibility of malware threats. Application firewalls are mandatory for Web applications. This was a recommended best practice until the Council made it part of Requirement 6.6 this past June. “Every Web facing application either has to go through a code review — which is impractical for most small companies — or install a Web application firewall,” Russo says. “You want to eliminate back doors and those sorts of things.” [A “back door” is secret access to software that bypasses passwords and other protections.] Logs must be saved for a year. Servers, computers, and other devices, as well as some applications, retain an internal log of all their activities. (For more on logs see this IncTechnology article.) Requirement 10.7 now requires companies to retain those logs for at least a year, and keep the most recent three months immediately available (archived online or available for quick backup from disk). PCI DSS 1.1 instructed companies to retain logs, but did not specify how long, Russo says. New-user passwords must be changed. It’s hard to believe anyone would be foolish enough to leave the factory-installed password on a router, server, or personal computer that processes cardholder information, but apparently, some companies are. Requirement 8.5 now makes that a violation of PCI DSS, and also requires that passwords include both letters and numbers. Things to come Before you get too attached to PCI DSS 1.2, keep in mind that yet another, newer version of the requirements will be arriving one day. During a recent conference on the PCI standards, representatives of the Council and industry representatives discussed items currently under review for future versions of PCI DSS. “They plan to work on addressing cardholder data after it’s been collected but before it gets authorized,” says Amer Deeba, vice president of product marketing at Qualys. A second area, he says, has to do with the rapid growth of virtualization and the challenges of securing virtual machines. The third area, is internal transmission of cardholder data, for instance to employees who have no need to know them. “There’s a huge desire in the credit card payment industry to address internal traffic,” he says. “PCI DSS 1.2 is still mostly focused on parameter threats.”

About 1634 days ago Spyware and Malware

What New PCI Standards Mean to You

If your business accepts credit card payments, then the way you handle that data is governed by Payment Card Industry Data Security Storage Standards (PCI DSS), not as a matter of law, but as part of your contract with the credit card companies whose cards you accept. Depending on how much you follow such things, you may or may not know that those rules changed Oct. 1, when the Payment Card Industry Data Security Standards Council issued PCI DSS 1.2. Most of the changes are relatively minor, and intended to clarify points of misunderstanding contained in PCI DSS 1.1, which has been in effect since 2006, according to Bob Russo, the Council’s general manager. “People call us every day and ask, ‘Do security rules apply to routers?’ or to ask what we mean by ‘a regular basis,’” he says. The current changes are mostly intended to clarify this kind of confusion and remove redundancies, Russo says, but, he adds, “We did draw some lines in the sand.” Crossing those lines is a bad idea, with consequences including stiff financial penalties and increased transaction fees. Rather than take the risk it, it makes sense to learn about the new rules and the changes your company might need to make to comply with them. There’s no room to list them all here, so to get a complete picture we recommend reviewing both the new standards, and a summary of the changes on the Council’s website. Meantime, here are the items most likely to affect your business. WEP is disallowed. Wireless networks that contain or transmit cardholder data must be protected by encryption, and wired equivalent privacy (WEP) is no longer acceptable according to Requirement 4.1.1. It must be replaced with Wi-Fi protected access (WPA). “Over the years, WEP has been proven to be not as good as originally thought,” Russo says, and indeed the Internet offers many articles and videos that purportedly explain how to break WEP encryption in 10 minutes or less. “In the new standards, we said we don’t want to see any new WEP implementations after March 31, and existing implementations to be phased out by June 30, 2010,” Russo says. All systems “commonly affected” by malware must run anti-malware software. “It’s two changes in one,” notes Anton Chuvakin, director of PCI compliance solutions for Qualys, a software-as-a-service provider of security and compliance software and services. “The previous requirement was to use anti-virus software; now you have to have anti-spyware as well, and you have to extend it to all systems.” Those running the Linux operating system, for instance, might previously have skipped this step because few, if any, viruses or other threats are directed at Linux. The Council won’t specify exactly which systems are considered “commonly affected” by malware, except to say that most mainframes and some Unix-based server operating systems are probably exempted. But, it notes, the world of malware changes quickly and compliance with Requirement 6.2 means staying vigilant about the possibility of malware threats. Application firewalls are mandatory for Web applications. This was a recommended best practice until the Council made it part of Requirement 6.6 this past June. “Every Web facing application either has to go through a code review — which is impractical for most small companies — or install a Web application firewall,” Russo says. “You want to eliminate back doors and those sorts of things.” [A “back door” is secret access to software that bypasses passwords and other protections.] Logs must be saved for a year. Servers, computers, and other devices, as well as some applications, retain an internal log of all their activities. (For more on logs see this IncTechnology article.) Requirement 10.7 now requires companies to retain those logs for at least a year, and keep the most recent three months immediately available (archived online or available for quick backup from disk). PCI DSS 1.1 instructed companies to retain logs, but did not specify how long, Russo says. New-user passwords must be changed. It’s hard to believe anyone would be foolish enough to leave the factory-installed password on a router, server, or personal computer that processes cardholder information, but apparently, some companies are. Requirement 8.5 now makes that a violation of PCI DSS, and also requires that passwords include both letters and numbers. Things to come Before you get too attached to PCI DSS 1.2, keep in mind that yet another, newer version of the requirements will be arriving one day. During a recent conference on the PCI standards, representatives of the Council and industry representatives discussed items currently under review for future versions of PCI DSS. “They plan to work on addressing cardholder data after it’s been collected but before it gets authorized,” says Amer Deeba, vice president of product marketing at Qualys. A second area, he says, has to do with the rapid growth of virtualization and the challenges of securing virtual machines. The third area, is internal transmission of cardholder data, for instance to employees who have no need to know them. “There’s a huge desire in the credit card payment industry to address internal traffic,” he says. “PCI DSS 1.2 is still mostly focused on parameter threats.”