MQSeries.net :: View topic - MQ FTE and AMS for PCI/DSS and other compliancy

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » MQ FTE and AMS for PCI/DSS and other compliancy

MQ FTE and AMS for PCI/DSS and other compliancy

« View previous topic :: View next topic »

Author

Message

RCollett

Posted: Wed Oct 30, 2013 12:42 am Post subject: MQ FTE and AMS for PCI/DSS and other compliancy

Newbie

Joined: 30 Oct 2013
Posts: 6

I have a 4 QM FTE Network topology, One for Co-ordination , One for Command , One for Non Secure FTE Agents, and One for Secure FTE Agents.

The 2 agent QM's are registered to the Co-ord, and agents configured on both QM work fine and have been for over a year

The Secure QM Agent QM is on an encrytped server , tucked away in a PCI Network Zone - there are no channels between the non secure and secure agent QM's so no cross contamination of Secure Data to Unsecure agents can occur and vice versa.

Currently I am configuring our TEST FTE network - hence using Self Certified SSL Certificates, however Production will be CA signed.
I have successfully configured 4 agents using SSL , 3 of those agents are remote FTE Client's , and one on the local PCI server. - The Local PCI QM Server is v7.5.0.1 MQ.
To acheive the SSL I created an kdb SSL Store for the QM , using the "ibmebspheremq{qm}" label, exported that self signed cert into a JKS Truststore, and copied that trust store to the relevant FTE Clients , once the agent properties ,Cipersuites etc were all set, comms is all running as expected.
Now I need to AMS the SYSTEM.FTE.DATA.{agent} queues on the secure QM, so any data at rest is signed and encrypted. Any agent within the Secure FTE Agent QM can send to Any Agent within the secure fTE Network , so the policies need to allow this to happen. As stated above, I have no need for agents on the other Agent QM to send to the secure agents and vice versa.

How do I get this working ?
Do I have to create a kbd for each Remote FTE Agent, create and export Self Signed SSL's and import into the QM's SSL Store?
Any recommendations on how to set the policies , etc please?

thanks
Rich

JosephGramig

Posted: Wed Oct 30, 2013 4:58 am Post subject:

Grand Master

Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA

OK, so you should only use one (maybe two) Self Signed CA because you do not want to exchange a whole bunch of certificates. You can use the one CA to sign all the certificate requests and then the key stores only need that one CA certificate to trust one another. You should put something meaningful in the DN to help you identify the CA easily and so the Qmgr's certificate is not a good candidate for being the Self Signed CA. You should make a dedicated key store for only that purpose and keep it safe.

Doing it this way, if you have two Qmgrs and two clients (just for demo), each of these will:

Create a key store (I like CMS)
Create a certificate request and send that to the CA to be signed
CA signs cert requests and send them back with the extracted CA certificate
The client/Qmgr imports the CA certificate
The cert request is received into the key store where the request was made
If you need a JKS, convert the CMS to a JKS

Remember, for a client to trust the server, the client must have the CA that signed the servers certificate in its key store. For the server to trust the client, the server must have the CA that signed the client in its key store.

See why you want one CA? Well, maybe one more for PROD to keep these separate but that goes into a deep conversation.

fjb_saper

Posted: Wed Oct 30, 2013 10:20 am Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

You're taking the words out of my mouth Joseph. I'd have been a little bit more specific though and qualified the CA as internal CA (free and cheap) as opposed to the public CA (the ones you pay for)...

_________________
MQ & Broker admin

RCollett

Posted: Wed Oct 30, 2013 2:50 pm Post subject:

Newbie

Joined: 30 Oct 2013
Posts: 6

Thanks for the replies

So , I created an internal CA Root using openssl , then CSR'd the QM and received it and exported the QM cert

I then created the JKS need for the truststore , imported the QM Cert and CA Public

That sorted the FTE Agent to QM SSL Over the channel (which was all on Self Signed)

Then I created a second kdb , one for the FTE Agents, CSR's / imported . Added the CA Pub Cert and the qm Pub Cert

Imported the FTE Agents Pub Cert into the QM kdb

Agents still run fine

Then I applied the AMS Security policy

All went pearshaped

The DN for the certs is similar too :

CN=ibmwebspheremqfiletransferagent
O= MY COMPANY
OU= MY TEAM
S=Leicestershire

So I sent the policy to signed first (little steps, will apply encryption when signed works)

setmqspl -m LNSUXX05 -p SYSTEM.FTE.DATA.AGENT.SECURE.01 -s SHA1 -a "CN=*,O=MY COMPANY,OU=MY TEAM,S=Leicestershire,C=GB"

The agent fails to start with error :

[30/10/2013 22:46:05:339 GMT] 00000001 AgentRuntime I BFGAG0058I: The agent has successfully initialized.
[30/10/2013 22:46:06:103 GMT] 00000012 AgentRecovery E BFGAG0142E: The agent encountered a security error while attempting to open its data queue, SYSTEM.FTE.DATA.AGENT.SECURE.01. See the Explanation and User Action for this message in the WebSphere MQ Managed File Transfer product documentation.
[30/10/2013 22:46:06:129 GMT] 00000001 AgentRuntime E BFGAG0171E: The agent has ended abnormally with return code 70.

The Queue Manager log shows no errors
The mqm/errors log shows no errors

Any ideas please?

ta

Rich

Michael Dag

Posted: Thu Oct 31, 2013 2:10 am Post subject:

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

RCollett wrote:

Any ideas please?

Just curious why you are using AMS Queue encryption for FTE Agents?
the data the agents exchange is non-persistent and will never hit your logs,
agents will only send data when the other agent is active as well so no data in queue files either...
or do you see high curdepths in your environment and actual data on queue files on the file system?

unless I missed some other PCI/security requirement?
_________________
Michael

MQSystems Facebook page

RCollett

Posted: Thu Oct 31, 2013 3:11 am Post subject:

Newbie

Joined: 30 Oct 2013
Posts: 6

Michael Dag wrote:

RCollett wrote:

Any ideas please?

Thanks for the reply , I am running this past our IT Governance people right now - if this is the case (and I have checked my Queues and they are non persistant) , then you may of just saved me a world of pain

Michael Dag

Posted: Thu Oct 31, 2013 3:24 am Post subject:

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

RCollett wrote:

Michael Dag wrote:

RCollett wrote:

Any ideas please?

keep me posted on the response

in the meantime you can do a large transfer and see if you can 'catch' any data and read it while it is in the queue...
next interrupt the transfer and see if any data is left in the queue that can be 'seen' ...

while this is all 'MQ' / 'Transport' related...

if these files and data are subject to PCI...
how do you take care of that while they are on the file system itself?
there the files are accessible by sys admins as well...
_________________
Michael

MQSystems Facebook page

RCollett

Posted: Thu Oct 31, 2013 3:42 am Post subject:

Newbie

Joined: 30 Oct 2013
Posts: 6

Michael Dag wrote:

RCollett wrote:

Michael Dag wrote:

RCollett wrote:

Any ideas please?

keep me posted on the response

[Telfon Suit on]
The starting and endpoints are on servers inside PCI Zones, running Encrypted drives - though yes - if one enters the servers as sysadmin, root etc - you could read the files. But , and this is the important bit for me , I am only responsible for getting the file from Server 1 to Server 2 using FTE and the most secure way possible - how those servers comply to PCI regs etc is not in my remit - that is for IT Governance to sort with the server guys.
[Teflon Suit off]

Michael Dag

Posted: Thu Oct 31, 2013 3:50 am Post subject:

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

RCollett wrote:

Michael Dag wrote:

RCollett wrote:

Michael Dag wrote:

RCollett wrote:

Any ideas please?

keep me posted on the response

Let's see what your governance people come up with, in the meantime you can do your tests to see what is visible when it comes to theses transfers.
_________________
Michael

MQSystems Facebook page

JosephGramig

Posted: Thu Oct 31, 2013 5:15 am Post subject:

Grand Master

Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA

I find it curious that you use at least three IBM products that use GS Kit and you find it necessary to use Open SSL. If you have an SSL problem and open a PMR for help, what kind of support do you think you will get?

Why do you think Open SSL is more trustworthy than IBM GS Kit?
Last, you sure didn't follow the steps I laid out but it seems to work for you... Well, to a point. Why don't you secure the MQ Explorer access and verify your JKS construction is actually good.

One more last thing, if any part of the SSL works then it is all going to work (signing and encrypting). SSL is black or white, works or doesn't. If it doesn't, it is because it is configured incorrectly.

I will let others help you with AMS or FTE.

RCollett

Posted: Thu Oct 31, 2013 5:23 am Post subject:

Newbie

Joined: 30 Oct 2013
Posts: 6

JosephGramig wrote:

It was not a case of trusting GSK over SSL , I happened to have a home made CA Signer in openssl already - the rest was done via GSK , CSR's receiving etc, just the "Signer" was an openssl CA .

This allowed me to show IT Goverance a working "third party" CA Signed certificate type setup, ie pretending to be like Verisign etc.

In prod, the CA will be Verisign or Thwarte.

Rich

JosephGramig

Posted: Thu Oct 31, 2013 8:57 am Post subject:

Grand Master

Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA

OK, so the steps before my step 1 are:

Create a key store (CMS) for the Internal CA
In the Internal CA, create a self signed certificate (to be used to sign all other requests)

This way, nothing is stored in the Internal CA's key store but its own self signed certificate. Think real hard about what you put in the CN part of the DN so you can identify this CA easily. It gets real fun when another joker constructs a different CA but gives the same parts of your DN in their DN. Awesome confusion ensues!

Another good reason to remove all CAs that are not being used. Further, if you accept a CA from somebody else, that means you intend to trust anybody they sign... Another good reason to not self sign every end point.

RCollett

Posted: Fri Nov 01, 2013 12:06 pm Post subject:

Newbie

Joined: 30 Oct 2013
Posts: 6

Michael Dag wrote:

RCollett wrote:

Any ideas please?

IBM came back :

"Good question to ask about the need to secure WMQ FTE messages to support PCI Compliance. The PCI requirement we are addressing here is to protect credit card data that is at rest. While the data queues are non-persistent - and the data is not routinely written to disk - for performance reasons, there are a number of scenarios where that data is actually written to disk after all. The most common ones that come to mind are (1) where the memory buffer is at capacity - either on the data queue or the transmission queue - and so the messages overflow to disk; and (2) where the Queue Manager is quiesced - in which case even non-persistent messages can be stored to disk for recovery on re-start. "

Michael Dag

Posted: Sat Nov 02, 2013 1:05 am Post subject:

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

that makes sense.
Keep us posted on your progress!
_________________
Michael

MQSystems Facebook page

RogerLacroix

Posted: Mon Nov 04, 2013 4:49 pm Post subject:

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Hi,

I realize that you are going down the FTE path but sometimes a simpler solution is just not in your view. I'm referring to Universal File Mover (UFM) which is a free open source project. It has built-in support for end-to-end encryption of the data.

Here is a 'How-To' on End-To-End Encryption with UFM:
http://www.capitalware.biz/rl_blog/?p=2020

It is extremely straight-forward and easy to do.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter

Display posts from previous:

Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » MQ FTE and AMS for PCI/DSS and other compliancy

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Protected by Anti-Spam ACP