6

In planning the next phase of our platform, I am trying to ensure that the production deployment process is PCI compliant.

We have a central platform which acts as a CMS, serving custom content based on an event type, that will reside in a hardened IIS server/environment.

Each new event has a basic splash screen and a custom domain name, i.e. www.myevent1.com, www.myevent2.com, etc.

The issue is that we will need to add new domain names frequently. Being PCI-compliant, we can't have developers accessing production servers.

PCI-DSS 6.4 states:

A separation of duties between personnel that are assigned to the development/test environments and those persons assigned to the production environment.

I'm trying to maintain the separation of tasks per compliance specs.

Thus, I my thoughts were to maintain the CMS server as-is, fully hardened - no developer access. Then have a secondary IIS server where developers can add new domains as needed, and upload the static splash pages that link to the CMS content.

Thoughts?

-- UPDATE --

We will be using PCI-DSS Level 4 compliance, so we won't have any card-holder data on our servers. The payment processor will have this info.

ElHaix
  • 161
  • 4
  • 1
    I always thought the goal was to maintain separation of duties, rather than forbid developers access. I thought it was around multiple users needed to maintain different areas to stop one person having full access. Anyway, in relation to your question, can't you have a none developer create domains? I don't fully understand your setup thought. One other thing, if your using a CMS make sure you maintain seperation of duties and auditing correctly. – ISMSDEV May 29 '17 at 21:28

2 Answers2

4

Is there real need of having CMS inside of the CHD (card-holder data) environment? We always recommend to keep the CHD as small as possible. Isn't it possible to design it in another way where your PCI DSS environment will just process/transfer/store the CHD and pass something as "tokens" outside (i.e. to CMS) instead of storing the CHD directly in CMS?

Its hard to recommend anything here as I have no clue where do you store the CHD, what is the purpose of it and many many other things...

As @ISMSDEV said, why developers should access such the production area? Developer develops the code while app admin deploys it and maintains. I can't see any reason why developers should have access to production...

By the way, if you design PCI DSS environment and you plan to certify it, I would recommend to hire some consultancy company / person with deep knowledge of it. It will help you so much and it is worthy as it is really not easy to get everything compliant. While I consider PCI DSS as a best security standard I have ever seen it is really hard to fulfill all its requirements. Sometimes, even if you think you are doing things right the auditor tells you it can't be like that. Simply because you just wrongly understood the requirement or you can't see all aspects of it. And if he tells you this once you have complete design of the environment finished, applications developed, documentation written and you keep evidence of everything its hard and expensive to rework it...

If you don't store, process or transfer the CHD you DON'T NEED TO BE PCI DSS compliant in any way. Of so, you are lost.

Fis
  • 1,200
  • 7
  • 10
  • The IT team is very small at the company, where the one developer had previously been in charge of doing most IT-related tasks. In the forthcoming iteration, an external managed services team will be responsible for environment maintenance and provisioning. I was hoping that we could have in-house developer resource continue to maintain the custom domains. – ElHaix May 29 '17 at 22:00
  • 1
    I understand, this make things more worse. If you plan to certify your environment the another company will have to be compliant with the standard as well... Be ready for it. It can dramatically increase your expenses. But I am pretty sure that your developer can't manage anything in the CHD. He can be a support (in meaning he will be sitting behind somebody and direct him what to do), but he should not have access to it at all. Another thing is he has to document everything anyway. This is so called configuration standard or operational procedure so even little childrens hould be able to do – Fis May 29 '17 at 22:06
  • I think you might need to get some advice. You edit says you are not storing card data and your payment provider is - if that's the case then your PCI compliance is a lot easier and developers should be able to access the server fine. PCI DSS has a number of levels Of compliance which varies based on your involvement with transactional data – ISMSDEV May 29 '17 at 22:06
  • 2
    See my edit too. If you don't touch CHD (card number, name, expiration date, pin, cvv) you don't need to be compliant with the standard. You don't even need to fill SAQ. – Fis May 29 '17 at 22:09
  • 100% agree with @fis – ISMSDEV May 29 '17 at 22:20
0

In this situation each new domain has a static splash page that points to CMS content that can only be accessed after user authentication. We can serve up those static pages directly from the CMS as well, which is better - no need to break things up.

Thus, when we register a new domain, we could use stealth forwarding for each domain: www.ourcmsserver.com/SiteContent1, www.ourcmsserver.com/SiteContent2, www.ourcmsserver.com/SiteContent3, etc. or parameterized www.ourcmsserver.com?sitecontentID=1, etc.

Since users have to login, they shouldn't be bookmarking specific pages anyway, and the URL will never never show the site's directory/sub-structure, just www.mysite1.com, www.mysite2.com.

Any comments on this approach?

ElHaix
  • 161
  • 4