this is not an official ofbiz stance. short answer you need a person that understands security and how to test applications.
http://www.qualys.com/forms/google/pci_trial/?lsid=6874&leadsource=80886 on the fire wall and the Linux firewall I have three ports open. 80, 443, and the webadmin port. I change the web admin port on a regular basis. this is a hassle but keep it from being found as easy. I review the log to see if any attempts have been made against the port. * Requirement 1 is about having a properly configured firewall. You could get fancy and use a policy reporting tool or run an automated pen testing tool to make sure the right attacks are blocked. But ultimately, just make sure the customer has simple perimeter defenses in place and working. * As of PCI 1.2, which goes live in October, antivirus (Requirement 5) is now beyond Windows devices. You need to help customers think about how they are going to "prove" viruses are blocked on Linux, Unix and Mac OS X. It's not clear whether customers will be expected to load Symantec on their mainframes, but ultimately, this is a pretty easy box to check. this is especially true for the Content side of ofbiz. * Change the default passwords (Requirement 2) on devices like firewalls and servers. Yes, if you use the default password in a wireless access point or any other device, you'll be owned. This isn't hard, but most folks don't think about it. I have added Eca that checks longing and sends a email to change it. also an Eca for password strength. they are locked out if they do not change or do not put in a proper strength password A majority of attacks now directly target Web applications, so PCI pays a lot of attention to securing Web applications in Requirement 6. Though customers need to walk before they run, some customers focus on just installing a Web application firewall and figure their work is done. Not so much. The reality is that Web application firewalls and code reviews (the key aspects of Requirement 6.6) are important, but most customers don't know what they don't know. So run a Web application scanner on the Internet-accessible applications and find out how porous those apps are. Then you can figure out how to fix the issues. This what you are ask here. but as the trunk is always changing there is no pat answer, other than do the processes each time you upgrade. Requirement 3 of PCI-DSS is all about protecting credit card data where it lives -- the database. Many organizations focus on strengthening the perimeter of the network, which I term an "outside-in" perspective. That's great and important, but not sufficient. You also need to work with your customers on looking from the inside out. This means finding all the credit card data and figuring out what systems and/or resources have access to the data. Ensure those attack vectors are protected. It also makes sense to think about database monitoring and vulnerability assessments to keep perspectives on the data, not just the systems. This will depend if you use a seperate db server. if you have the single server and the ports are closed. you only have to worry about having the webtools accessible. Logging event and other key data is the focus of Requirement 10. While it's easy to meet this requirement, it's hard to do it right. To meet the spirit of PCI-DSS you just need to gather some event data and keep it for a while. But that won't necessarily help your customers when they have to respond to an incident. I advise customers to log as much as they can, from networks, systems, databases, applications, physical security systems and so on. The more log data, the better. Make sure the customer is protecting the log data -- this includes storing off- device and cryptographically signing and sequencing -- to make sure it can be used as evidence in a prosecution. The customer can always throw log data out if they don't need it -- hopefully, they won't! also run a cron job looking for holes. I see a lot of customers that are just looking to check the box that says "compliance," as opposed to focusing on protecting the credit card data. Compliance is not a thing you finish, so when I talk to folks I always caution them against taking an "audit-centric" view of compliance. Many security gurus say security is a process, not a product or an audit, and they are right. The best way you can help your clients and ensure they don't have silly compliance errors is to help them understand the lifecycle of information protection. For better or worse, security people are never finished, and this philosophical adjustment is the best gift you can give to any client. phug sent the following on 10/16/2008 2:47 PM: > Thanks for the quick reply. > > Setting the router/firewall policies issue aside, my follow-up then is > what's required for a 'proper installation' of OfBiz to prepare for a PCI > audit. If we follow the Apache OfBiz Production Setup Guide, is that enough > to secure OfBiz for us to then tackle the network issues (router/firewall)? > http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide > > Has anyone gone though a PCI audit and is willing to share some insights > into what is covered in one of these audits? > > Has anyone used a 3rd-party audit service or would recommend one from > experience such as: > McAfee - http://www.mcafeesecure.com/us/pci-intro.jsp > Truste - https://getcertified.truste.org/ecommerce/ > 403 Labs - http://www.403labs.com/solution/vulnerability > > Thx, > -PH >
