We’ve just taken a look at how simply being aware of possible threats to CRM system security can help foil phishing attacks, but there’s a lot more involved with the security equation.

Technological security measures will boost user awareness into a complete security strategy.

Many applications are written using Asynchronous Javascript and XML, or AJAX.

AJAX allows CRM vendors to provide “richer, more responsive” applications and more efficient CRM programs with more features to boost sales. However, it also provides more attack points into CRM system security, according to Cook.

AJAX applications aren’t always written from a security point of view. Being relatively new, AJAX is less understood than other application environments, and being written by Web developers rather than programmers, security may take a back seat to performance and features.

“I get kind of sad when I’m asked [about what customers can do to secure their CRM applications],” InsideCRM quotes Billy Hoffman, manager of HP Systems Security Labs, the Atlanta-based Web-security research department at Hewlett-Packard Development Company, L.P. “This is the part of my job where I feel bad because there are no good answers.”

While Hoffman mentions a few methods users can employ to protect themselves, it’s true that security should be addressed on the developer rather than the customer. However, like a “chain-link fence around the problem,” these methods can provide at least some protection.

Hoffman recommends choosing a CRM application with a high level of security, and asking about the application’s compliance with security standards that are appropriate to its use.

“For instance, OWASP (the Open Web Application Security Project) has a list of top 10 vulnerabilities [in Web applications],” said Hoffman. “One question you can ask is, ‘How are you in compliance about the OWASP top 10?’ How are passwords stored, what type of access rules do you enforce? Is there some kind of access-control system? Ask how granular it is. A lot of times looking at feature set of an application can give you an idea of how secure it is.”

Seek tools to boost the security of prewritten applications, such as the NoScript plug-in for Mozilla’s Firefox browser. NoScript can block JavaScript language on a user’s computer, requiring the user to specifically enable every JavaScript application he or she allows to run. Since many Web 2.0 attacks involve malicious JavaScript, the plug-in offers protection, at the expense of the user’s time to authorize JavaScript at each site he or she visits. NoScript also requires a user to have the knowledge to choose which JavaScript to allow, since it cannot distinguish between benign and malicious scripts.

For server protection, Hoffman recommends a proxy server, such as The Apache Software Foundation’s Module mod_proxy, with a whitelist of allowed addresses. The proxy server can filter sites that may be malicious or are restricted, but requires a time commitment to maintain the whitelist.

Application firewalls or intrusion-detection systems offer another layer of security. Firewalls are designed to “enforce protection policies for specific applications, such as CRM,” which can add security to a CRM application but aren’t as secure as a well-designed Web application, according to Hoffman. They do allow control of the traffic that can pass to and from the application—including downloads—as well as access to applications, however.

CRM security will remain incomplete until vendors begin to “get the idea,” which Hoffman says is beginning to happen. He predicts that in two or three years, CRM security will improve greatly.