Is Sugar PCI compliant?

[mypetrock]

I work in the payments processing industry. As such, we need to be PCI compliant. We are looking at Sugar CRM, but I'm concerned about its apparent two-tier architecture. The standard says that no publicly accessible server can interact directly with a server that holds cardholder data. But the Sugar PHP code interacts directly with the database, a PCI no-no.

Am I missing something? Is there a way to convert Sugar's two tier architecture into an N-tier architecture?

Thanks,

mypetrock

[Angel]

Based on my limited knowledge of PCI compliance, I believe the answer would be no, given that by default, there is no way to store data in an encrypted manner.

[mypetrock]

Angel,

Thanks for the reply. I'm confident that the lack of encryption is not a showstopper. None of the data that we would plan to store on the system would be required to be encrypted. My concern is more whether there would be a way to change Sugar from a two tier system into a n-tier system with firewall separations between presentation/webserver, businesss logic, and the database.

mypetrock

[HolmesA]

You cannot separate presentation from business and put them on different servers.

They are separate layers within the application but they should work on single machine. I think you may be understanding the PCI compliance incorrectly. Can you point to a document that states they should be on separate machines?

You can put database server and protect it with firewall. You can also protect sugar server with firewall so clients actually contact firewall not the server directly. Does this help?

[berdelyi]

See https://www.pcisecuritystandards.org...i_dss_v1-1.pdf for the standard.

I'm familiar with the payment card industry data security standards (PCI DSS). Are you intending to use SugarCRM to host cardholder data?

1.4 "Prohibit direct public access between external networks and any system component that stores cardholder data."
1.4.1 Implement a DMZ to filter and screen all traffic and to prohibit direct routes for inbound and outbound Internet traffic.
1.4.2 Restrict outbound traffic from payment card applications to IP addresses within the DMZ.

The intent here is that cardholder data must not be directly accessible via the Internet. With SugarCRM, the application can be hosted in your DMZ while the DB (data storage) resides in your corporate network. Make sure that only the SugarCRM application server can communicate with the database via firewall rules. No direct access from the Internet to the DB server.

In this case, it's how you implement SugarCRM that determines if it's PCI compliant.

I would look into the following as I don't know if SugarCRM can support or enforce these requirements.

8.3
8.5 (I dont think SugrCRM can enforce 8.5.11, 8.5.12, 8.5.13, 8.5.14)
10.2
10.3
10.5

[mypetrock]

berdelyi,

We aren't planning on hosting cardholder data on the system, but the Sugar database may end up residing on the same server. I think we may have found our solution in that we can place a server in the DMZ and have it reverse proxy requests on to the Sugar server. We're planning on developing a custom authentication module to use our current authentication module which should answer 8.3 and 8.5. The 10s could represent a problem, unless we can drop triggers on to the database that hosts Sugar.

mypetrock

[berdelyi]

Choosing to implement SugarCRM on the same server as the DB server is not a limitation of the technology. Why are you insisting the DB and webserver reside on the same server?

If no cardholder data is involved then the PCI standards are not mandatory. Why do you think the PCI standards will apply to your instance of SugarCRM?

[Kalendrinn]

Oh snap. So the 10s in Sugar to do it properly would require rework in the audit subsystem of Sugar to get it to log audit trails someplace completely different than the Sugar database, as well as to add missing data to comply with 10.2 and 10.3. 8.3 and 8.5 like mypetrock said should be easy enough to overcome just by reworking a little of the auth code or implementing a plugin auth module to do all you need.

Like berdelyi said, if you're not storing the cardholder data, you don't really have to worry about PCI compliance except to make the transactions between processing gateway and Sugar (or whatever you're using) safe. If you're storing the orders in the database you should encrypt them as good practice but PCI doesn't come into play unless you are keeping card holder data such as the credit card number in them.

[berdelyi]

It would be nice if SugarCRM provided robust account policies out of the box without the need to create custom authentication modules as this is an area you wouldn't want to do something wrong.

10.2 is about what events should be logged.

10.3 is about what information should be logged for the events.

10.5.3 could be done by supporting syslog or using a process to constantly push or pull log data to a different server. This is typically the purpose of various SIM products.

[Kalendrinn]

It would be nice if SugarCRM provided robust account policies out of the box ...

Hah! It would be nice! Keeping certain thoughts to myself....