PKF AvantEdge

Category: PCI-DSS (Page 11 of 20)

Alienvault: File Integrity Monitoring on Linux Part 2

November 6, 2017 / / 0 Comments

So based on our previous article you have so far set up OSSEC (or HIDS in Alien-speak) in your Linux host which you want to monitor. The next thing to do is to configure FIM to work.

To recap, we have a running CENTOS7 system running in our lab and we finally got our ossec to be communicating with the Alienvault server. You can verify connectivity either through the CLI logs, or using the USM Interface. Now the HIDS can be used for a lot of things – it’s obviously a Host IDS (hence the name), but it’s also a log forwarder as well, so for Linux systems, it doubles up as a security logger, so you don’t need to configure separate plugins to log, for instance SSH denied attempts. If you don’t have the HIDS, you have to forward logs from rsyslog then setup Alienvault plugin for SSH to normalise SSH logs and create those events. HIDS does this for you. Try it. You can attempt multiple logins with wrong password and you should see an event called “SSHD Authentication Failed.”

But for this article, we will be focusing on File Integrity Monitoring or FIM for short. FIM in Alienvault USM is utilising OSSEC inbuilt integrity checking process called Syscheck. Syscheck runs periodically and depending on how many files/directories it is checking can run from 10 minutes to much longer. By default, syscheck in Alienvault executes very 20 hours – if that’s too long for you , you can shorten it in the configuration.

Let’s jump straight in.

In Alienvault (Server if you are using Standard), go Environment -> Detection and on HIDS tab, click on Agent. In the lower tabs, click on SYSCHECKS.

Over here is where you configure the Syschecks on the Agents and you can modify the frequency.

Because we are using Linux, we are going to ignore the portion where Windows Registry is being configured and go straight to: ”

FILES/DIRECTORIES MONITORED

Under files/Directories, put in a sample directory you need to monitor, for instance

/etc/pkf

Don’t worry, out of the box, standard directories being monitored are

/etc

/usr/bin

/usr/sbin

/bin

/sbin

We have in some cases clients insisting on us putting in /var/log in there to inform them of changes occurring in this directory. According to them, log files are key and they need to know if these log files are being changed.

Um, yes. Agree on the first part. But /var/log changes almost every nanosecond. Syscheck is not going to be of much use here. They are probably thinking about log archives as opposed to the current log folder. Anyway, we digress.

So go ahead and put in your own directory in there under agents and then restart HIDS from Alienvault, and also for good measure restart the agent as well (you can go Agent Control -> Click on the clock symbol under the Agent Name to restart). To check, you can click on Agent.Conf tab and you will find something similar to:

<agent_config>
    <syscheck>
      <frequency>1200</frequency>
      <auto_ignore>no</auto_ignore>
      <alert_new_files>yes</alert_new_files>
      <scan_on_start>yes</scan_on_start>
<directories realtime="yes" report_changes="yes" check_all="yes">/etc/pkf</directories>
    </syscheck>
  </agent_config>

So it looks all set up. If you have restarted HIDS and also the agent, you should be able to verify on the agent itself if the configuration has been uploaded. On the client, go to

/var/ossec/etc/shared

Look into agent.conf file and you should be able to see the same thing as the configuration above. Also, you can go to

/var/ossec/logs

and look into ossec.log file and you should be able to see something like

ossec-syscheckd: INFO: Monitoring directory: '/etc/pkf'.
ossec-syscheckd: INFO: Directory set for real time monitoring: '/etc/pkf'.

So there you have it. You can do some testing now.

So we will go into the local directory of our CENTOS and go ahead to create a few random files. The first thing you notice is that even if in our config there was:

<alert_new_files>yes</alert_new_files>

We still do not get any alerts once we create new files in the directory. This is because OSSEC doesn’t check new files in realtime (just changes to files), and we will need to wait for our syscheck to run, or you can go ahead and restart the agent from the Alienvault GUI. For good measure, change a few things about the files as well.

You might notice a strange thing happening here.

Going into the SIEM, you might not find any events relating to integrity issues in your host. This doesn’t seem to be an isolated incident, if you head over to the Alienvault forum, you will see many people having the same issue: We have enabled FIM and we can’t find anything on the SIEM or any events!

If you check on the agent itself, and you click on the “modified files”

You will see a raw list of all the files modified and you will see that /etc/pkf/filename is there listed as well, so it means OSSEC is working and syscheck is working. Another way to verify is to head over to your Alienvault Server and go to

/var/ossec/logs/alerts 

grep pkf alerts.log

Basically I am doing a grep on anything that identifies the files or directories I am looking at to see if alerts are generated. You should change the grep to something related to your filename/directory name. You should be able to see that alerts are generated.

So what gives?

Plugins.

Apparently for some strange reason, some Alienvault setup by default does not have the proper plugins enabled to read the integrity alerts log of ossec. This is very strange, as FIM is touted as a feature for Alienvault, but we need to still work further to get it up and running. So go ahead to your Alienvault GUI:

Configuration -> Deployment

Click on System Detail of your Alienvault setup

Click on Sensor Configuration in the menu on the right side

Go to “Collection”

You notice you have Alienvault_HIDS and Alienvault_NIDS enabled. However, in some cases, Alienvault_HIDS-IDM plugin might be missing and can’t be found under “Plugins Available” column. IDM Is for identity management and it needs to be enabled for FIM to properly work.

The plugin that makes this happen is

ossec-idm-single-line.cfg

In our case, the plugin file was there in /etc/ossim/agent/plugins, but it wasn’t in the ossim database as a “Plugins Available” option. This generally means that it wasn’t (for some reason) written into the ossim-db. So head over to the directory in Alienvault:

/usr/share/doc/ossim-mysql/contrib/plugins

You will see that there is an ossec.sql.gz in there, so go ahead and unzip it and run

cat ossec.sql | ossim-db

alienvault-reconfig

Wait for the reconfig to occur then head back to the GUI of Alienvault, all the way back to the sensor configuration->collection and you will be able to see Alienvault_HIDS-IDM available for selection.

Go ahead and select it there, and then reconfig and now you can try to run the FIM test again.

a) Create a new file

b) Restart the agent (to simulate the syscheck being run)

c) Check SIEM , filter Data Sources to Alienvault HIDS, you should find

AlienVault HIDS: File added to the system.

d) Go to the host and edit the new file and change it

e) Go back and check SIEM and you will find

AlienVault HIDS: Integrity checksum changed.

The last event should be immediate and need not have any restart of the agent. Unless of course, we noticed if the change occurred during the time syscheck is running, if so the event will occur once syscheck finishes. It’s not perfect, but it will have to do.

Congratulations, you have FIM events up and running for Alienvault! If you need further assistance in any Alienvault matters, drop us an email at alienvault@pkfmalaysia.com and we will look into it.

 

Alienvault: File Integrity Monitoring on Linux Part 1

October 31, 2017 / / 0 Comments

If you have been deploying or troubleshooting Alienvault long enough, you would know a few things: Alienvault is one of the most flexible SIEMs in the market. It has the most varied security features, and covers almost the entire spectrum of our PCI-DSS needs – from IDS, to SIEM, to File Integrity Monitoring, to vulnerability scaring to a partridge in a pear tree.

One of the products working under the Alienvault hood is OSSEC, which is a opensorce host based IDS. Sometimes, its interchangeable to HIDS, which is Host IDS, but really, the latter is simply the type; while the former is the actual name itself. For the sake of this article, we will interchange both terms.

OSSEC runs well with Windows, where Alienvault can do an auto deployment given the correct setup and credentials. However, it’s on Linux boxes that sometimes we get a bit concerned. Not because the product doesn’t work, but simply because the setting up of the installation. There is no auto deployment, so we need to set it up manually, and this might mean downloading the correct packages in the first place.

After this, we are going to look at a specific function of HIDS – File Integrity Monitoring or FIM for short.

Firstly, let’s get started. We have set up a simple CentOS 7 box in our lab in the same network as Alienvault, and we are going to install HIDS on this box as an AGENT. This will then talk to the Alienvault USM which is the server.

So let’s assume you have your agent system network setup (please ensure your DNS is set properly, you should be able to work this out in CentOS 7 either through the network tools or editing resolv.conf).

 yum groupinstall "Development Tools" -y

The CentOS development tools are very useful tools which is a bundle, used primarily for building and compiling software from source code. “Yum” here while making you think of going for a teh tarik is a command found in almost all red-hat based distros to run installations. It’s used for update, installations etc. In the old days before YUM, we would use RPM (which is really what YUM is using), but we would have to manually track down dependencies and it really sucks because to install an RPM package might mean to install a whole bunch of stupid libraries or updating stuff and you are basically running around the internet looking for RPMs like Where’s Wally. It looks awful now, but back in the days, RPM was heavensent. We didn’t need to do “tar”, configure, make, “make install” anymore!

Anyway, the -y argument behind simply automates the command by answering yes to the prompts. So once you run that, fingers crossed, everything runs ok and you get

Complete!

Which means everything is ok.

The next is to get the kernel-devel package.

yum install kernel-devel -y

This is a package that allows us to install a kernel driver later. It’s not the full kernel source, so it shouldn’t take too long before you see the “complete!”.

At this point you are ready to install OSSEC. If there are any issues, then troubleshooting is obviously required.

First, we need to locate the version of HIDS that can work with Alienvault. You might think heading to the latest HIDS in https://ossec.github.io/downloads.html might be the answer, but for Alienvault, we would recommend to get the 2.8.3 version. You can find it here:

https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

So, go to a installation directory (optional) like /usr/src and run

curl -OL https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

We used curl here because for some reason wget wasn’t installed. the -OL is supposed to handle the redirected links for that particular site and supposedly to rename it to a proper remote file name. It doesn’t do the rename though (don’t know?) and we wind up with a file called “download_file?file_path=ossec-hids-2.8.3.tar.gz”. Just rename it if you are into aesthetics to ossec-hids-2.8.3.tar.gz.

So now lets do an extraction

tar –xzvf ossec-hids-2.8.3.tar.gz

We now have a folder called ossec-hids-2.8.3. Go into this folder and then run

./install.sh

Once you run, you will be given a series of questions. Default should be fine for most, and you should just select ‘agent’ and also key in the server (Alienvault) IP address. Now if you are running a separate Alienvault setup (non-AIO), then this IP address is actually the address of your SENSOR. Not Alienvault Server. So don’t get mixed up. The Sensor is the Server. Hm.

So everything ready, fingers crossed, just go ahead and install. There will be a lot of text filling your screen but the important thing is that there is no ERROR or WARNING (well warning ain’t bad), but at the end you should have a welcome note stating

 Thanks for using the OSSEC HIDS.
 If you have any question, suggestion or if you find any bug, contact us 
at contact@ossec.net or using our public maillist at ossec-list@ossec.net 
(http://www.ossec.net/main/support/ ).

Press enter and you should be out of the installation. Congratulations!

You are not done yet. You still need to get Alienvault to talk to your box. The steps are as follows:

a) Generate an Agent Key from Alienvault

Go to your Alienvault AIO or your Server (since a standard sensor has no GUI, remember?).

Environment->Detection->Agents

Click “Add Agent”

Select the host from the list (It should be there automatically, but if it’s not just add it there through the asset list).

So now the agent has been created but you should see it as “Disconnected” from the list. Click the little Key sign that says “Extract Key”.

You should see something like

Agent key information for '2' is:

MiBIb3N0LTE5Mi0xNjgtMC01MCAxOTIuMTY4LjAuNTAgMDBmYzI0MzUyNzg4N.....etc
The garbled message is the key. So go ahead and highlight and copy it.

b) Import the key into the agent system

Go back to your agent system and head over to /var/ossec/bin and run

./manage-agents

Type in ‘I’ to import

Paste the whole key into the screen and confirm adding it.

Quit and then restart by going

/var/ossec/bin

And

./ossec-control restart

c) Restarting HIDS on the server

On the server head over to

Environment->Detection->HIDS Control

On the right side, click “Restart” the HIDS and you should be fine.

d) Check the Agent Logs

Head back to the agent system and check the logs

cd /var/ossec/logs
more ossec.log

You should (hopefully!) see

INFO: Connected to the server (192.168.0.xxx:1514).

where xxx is your server IP address.

Back in the USM server you will be able to see that now the agent is “Active”.

In the next article we will see if we can get the FIM to work.

IATA PCI-DSS: Why your SAQs Matter

October 25, 2017 / / 0 Comments

We have had a few discussions among consultants as we progress further into this compliance for our Travel Agency clients. And very often (if not always), the matter always comes down to, “Can we just do an ASV scan and you certify us?”

We have touched this topic many times. ASV scans cannot certify you as PCI compliant. They are just one of the requirements. In fact for some of the SAQs (self Assessment questionnaire), ASV is not even needed.

SAQ A

We’ve gone through the famous SAQ A in our last post. This is basically where no card data is being entered in merchant environment and they basically forward everything over to the payment provider. There is no requirement for ASV. That doesn’t mean it makes it right though. Imagine this scenario: the developer makes a hopeless job at coding their web application. There are two ways SAQ A can be done: redirect or iframe. Let’s recap.

A redirect occurs when the merchant website sends a redirect instruction to the client browser when payment needs to be made. This instructs the client to connect directly to the payment gateway. This instruction could be a simple

onclick="location.href='https://payme.com';"

Or similarly through some javascript with window.location.

The iframe is similar, whereby a ‘child’ window is called directly from the payment gateway and has a window in the main merchant site. Although everytime this occurs, I have nightmares of those old websites with scrolling words, flashing lights and like 5 – 10 frames running at once. Netscape days.

iFrames are simple as well, with the site you want to call embedded within the <iframe src> tags.

So, anyway, back to ASV scans on these merchant sites. Although its not required, if the web application itself is poorly constructed and is compromised, there could be a high possibility that the redirect process itself gets hacked and redirected to another site that looks like the real payment site. You can imagine what happens next. The solution here is to ensure even on the merchant site, this site is developed with good secure coding practices. If ASV is not required, it does not mean you don’t need to run any scans. We would recommend vulnerability scans to still run against it, whether ASV or not. In fact, any web facing system out there should be tested – because if you are out there, it’s open season – anyone can attack it, and it’s up to you to secure it.

Conclusion: No need for ASV, but recommended – if not ASV, at least some security scans.

SAQ B 

Ah, the good old SAQ B. A lot of people misunderstand this for a good reason. Some of our retail clients, or F&B clients insists this is the correct one as they are using card terminals. However, they forget that most of them have their integrated POS systems – specifically because they need to charge an amount like food etc. So their POS systems sends these details to their EDC (Electronic data capture) terminals and the EDC accepts the DIP cards. What happens is that, these EDCs sends back the transaction data and in many cases, they still swipe our cards on the payment system. SAQ B doesn’t qualify here. SAQ B is specific for dialup EDCs directly to acquirer bank. For those using 3g/4g, then these can be considered as well. If you are using WIFI, or internal broadband link then you are out of luck. No SAQ.

Because of the direct point to point or cellular connectivity, ASV is not required (for a good reason!)

Conclusion: No Need ASV – IF you actually qualify for the SAQ that is.

SAQ C-VT

Another difficult SAQ to be eligible for. It has very specific requirements – whereby a web-based browser connectivity to a virtual payment provider who is PCI compliant. I think it really applies more to hospitality or travel agencies. In this case, the question is often asked – what about my broadband IP accessing the net? Because for sure, when I connect to my virtual terminal provider, I am using the internet right, and not leased line or any point to point? So for sure, my broadband has an IP. Just type “whats my ip” in google and it will show. Most of them have dynamic IP addresses as well. In SAQ C-VT there is no requirement to ASV scan.

However, having a dynamic IP and no ASV scan in SAQ C-VT doesn’t mean you still can’t do it. Many routers/firewalls are poorly implemented or poorly patched. We would recommend to do an internal scan on the firewall interface to ensure vulnerabilities are identified. Again, it’s a matter of securing the internet exposed system.

Conclsuion: No Need ASV, but we recommend an internal security scan on the firewall to ensure the box is properly hardened.

So, there you have it. It’s critical to know your SAQs so you know the extent of what NEEDS to be done and what is BETTER to be done than not.

If you need assistance with your PCI-DSS, drop us an email at pcidss@pkfmalaysia.com

PCI-DSS: SAQ A and SAQ A-EP differences in a nutshell

September 14, 2017 / / 0 Comments

OK, we are tackling this wonderful subject for the second time. We have last year touched on this through this post. Unfortunately there are still so many questions on this, that we feel that we need to re-tackle this matter again.

One response a company received regarding this issue from their payment processor was as follows (when merchant requested if they can do SAQ A-EP)

“No. SAQ A-EP you are still not allowed to transmit card data. Please have a look at below snippet taken from the SAQ A-EP AOC:

* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.

* Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

If you want customers to enter their card data on your website you require the
PCI SAQ D.”

And so, our lengthy reply was as follows:

Your payment processor could be correct (or incorrect) depending on how your page is set up. They are sort of correct in saying you are not allowed to ‘transmit card data’. Because in the SAQ A-EP example, you serve the payment page, and then the card data is transmitted from the user desktop directly to the Payment processor. It is the way the SAQ A-EP is worded that makes it so confusing. You can clearly see that these two statements may sound like they actually conflict each other:

* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.

* Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

If you read the above, it actually says that, all processing must be outsourced except the payment page (meaning the merchant can host the payment page). The below statement seems to shoot itself in the foot by putting in “The website does not receive cardholder data but controls how cardholder data is ‘redirected’ to a payment processor.” Unfortunately this is not the only place where PCI SSC mucks up its documentation. I can name like a dozen more times they read like its written in Hebrew and translated to English after that.

The only way to really explain is to refer to two documents I will refer to here – first, the “Understanding SAQ document” and the other is from VISA itself, the “Processing Ecommerce Payments Guide” which is what SAQ A vs SAQ A-EP is based on.

Read Page 4 of Understanding SAQ document and tell me how you interpret the table.

Its basically saying the payment page can come from EITHER the merchant website OR a PCI DSS website. As if that’s not enough to clarify, the next page, PCI even gives an example, whereby the “MERCHANT SITE CREATES THE PAYMENT FORM”. So this is clear. The payment form CAN BE IN YOUR WEBSITE.

Apparently they differentiate “receive cardholder data” and creating a payment form doing a direct post to the payment processor. Because in the form, you can send it directly to the processor to process the form posts and input, or you can process it on your own (I used for instance <form action=”PHP_SELF”> which was many years back to reprocess the form input in the same page). The latter example is what they mean by “receive cardholder data”. Not by creating the form itself, but by actually processing what the form is sending when user clicks submit.

You can process it, and then send it to the processor; or you can send it to the processor direct and have them process it.

The first one is SAQ D, the second one is SAQ A-EP. Both occasions the form is still residing on your merchant page. It is what happens after the ‘submit’ is clicked that is important.

If you want to read further, Visa has a better document, the “Processing Ecommerce Payments Guide”. In page 5, the bottom table clarifies a lot.

Basically if you are a merchant 3 and 4 doing either a direct post or javascript, with payment page sitting on your website, then you are eligible for SAQ A-EP.

Lets look at direct post in page 10 and tell me what you are interpreting.

  1. The merchant website CREATES a payment form and SENDS it to the customer computer
  2. The customer computer displays the payment form
  3. The customer enters their card data into the payment form and presses the OK button
  4. The customer computer SENDS the card data to the PSP

The red parts are all done IN YOUR ENVIRONMENT or your customer. Only in step 4 is the card data sent directly to the PSP. So yes, technically, your website is only “serving” the payment page. Once the page is ‘served’, it goes via direct post to the PSP when the submit button is clicked.

SO, in conclusion:  The key thing here is that if your website is directly processing the entries of the forms, then it falls under XML or ‘anything else’ and that’s SAQ D and your processor is correct. This is page 14 of the ecommerce payments guide from VISA. We sometimes see this in merchants who create the form, then for some reason or another prefer to process the information entered into the form and then only sends the information on its way to the processor. They don’t store it, but they process it first before shooting to the processor.

Once more, you can see this by your form. If you have a <form action=”to your own page” or current_page or whatever> then basically you are processing the form before sending to your processor. If your action is to direct to the processor site, then SAQ A-EP can be used.

Hopefully this matter is put to rest!

IATA PCI-DSS: Is GDS Client software a browser? Part 2

September 3, 2017 / / 0 Comments

Right, now that we are past the theory in Part 1 of this article, let’s jump straight into the dissection of the traffic flow.

First of all, we will not be looking at the entire traffic stream of the GDS application. We are not interested in its security for now, but rather whether it is establishing a typical web browser traffic. We need to assume that there is going to be some working knowledge on how networking works, else we will end up giving an entire lesson on it and not get to the point of this article. So, we are not going to explain TCP, HTTP(S) protocols, TLS, handshakes etc. Let’s just assume that we are beyond that and we just need to see if the GDS traffic is similar to the traffic we see on browsers.

In order to do that, we need to look at the basic communication over the internet – handshakes. Like its namesake, a handshake is between two systems – the client and the server and it’s a way of establishing communication. It’s a universally acceptable sign of friendship, although in some countries, it would be a hug, or kiss on the cheeks, or fistbumps. It’s the same thing. A TCP handshake is when your browser fistbumps the server.

However, in this case, because this is considered a “secure” channel we will be using what we know as a TLS (Transport Layer Security) Handshake.

This typically goes like:

a) Client Hello

b) Server Hello

c) Server Key Exchange

d) Client Key Exchange

e) Handshake

f) Let’s chat!

Now, again, this article is not to break down each item and explain every single packet details, but to make a comparison between GDS traffic vs an encrypted browser traffic, to say, Yahoo.com. So what we have done is to use a normal Chrome browser and go to mail.yahoo.com which throws us into the “HTTPS” page, which is the encrypted secure page and from there, we want to establish a connection by logging into Yahoo Mail and looking at the traffic. We are using Wireshark and here is the screenshot:

So as you can see, the beginning has a “Client Hello” packet from our system to Yahoo. This means we are saying, “Hey, here’s what I want from you and here are some information: my TLS version, my cipher suites, my compression method, the server name (so we know who we are talking to) etc. It’s like I give you a name card with all my information in it.

Next, we see a Server Hello. This is great so we know we are not talking to a brick wall. While the Client Hello has information in it, the Server Hello is not just courtesy, it also has piles of instruction on how to communicate. It’s like someone responding to us and saying, “OK, we will be talking in English, we will be using a phoneline at this number, at this time etc etc”. For internet connectivity, TLS versions, cipher suites are important to sync between Client and Server. We won’t go into details here as it is not the objective of this article.

If all goes well, the next step is the Certificate (remember, we are using a secure version of communication here). This certificate does a few things: It gives non-repudiation, meaning, the client knows that it is the server that is sending the information (instead of say, another server pretending to be the actual server). The certificate also provides the important “Public Key” of the server so encryption can occur and the server can decrypt using its own private key.

After this, there might be a Server Key Exchange, which is part of the negotiation flow. At the end of this packet, there is a “Server Hello Done” which is…what it says it is. The Hello is done. Likewise, a Client Key Exchange packet is followed if there is a Server Key Exchange, which in this case, there was. The client is basically encrypting the session with the public key of the server. After these, the TLS handshake is basically done and the transmission is considered secured, and you will see New Session Ticket.

At the end, you will see that “Application Data” packet is encrypted through TLS v1.2.

So this basically constitute a typical browser packet capture for secure communications.

Let’s compare what we get from Travelport:

So here you see the start of the conversation typically begins the same, except there is no Server Key Exchange, and basically the Travelport server sends the “Server Hello Done” message in the Certificate packet itself. This is no big deal, as this is an optional message and the server certificate has the required information.

The client key exchange here is sent to travelport based on the public key algorithm…for the sake of this discussion, this is perfectly normal to either have or not have this, as is the Change Cipher Spec. Finally a “Session Ticket” is also optional (it is missing here) , it’s based on RFC 5077, which basically is session caching on the client side which removes the tracking of each client session on the server side. It’s kind of like those special pass stamps you receive on your hand when you enter into a concert, when you need to take a leak and go outside, the bouncer recognises you on re-entry by the stamp on your hand and you don’t need to do a re-registration again. I really can’t think of another analogy here, so do forgive me if this flies over your head.

So from here, you can see Travelport Galileo Client is actually establishing the same sort of traffic that our Chrome established with Yahoo Mail on the browser. The only thing here we are not comfortable with is the fact that the protocol negotiated is TLS v1, which is not secure and broken. PCI-DSS would have some choice words to say to Travelport on this, as there is a requirement to migrate TLS v1 to v1.1 or v1.2 by June next year 2018.

So let’s look at Sabre:

Again, more or less the same as Travelport except here we have a “Encrypted Handshake Message” which usually occurs after “Change Cipher Spec” since now the messages are no longer unencrypted like the Client Hello, Server Hello etc. Again, it’s part of the normal handshake flow.

With the breakdown as such, we can see that the Travelport client and Sabre client are establishing the same sort of network flow as a browser authenticating to a website, and not doing any local authentication or getting local application data within the client application itself. This generally means, these are specialised “browsers” that are made for only one purpose: connecting to the GDS server. No Facebook access permitted here.

Again, we went through this because we needed some assurance that these GDS clients are functioning similar to browsers, as opposed to standalone payment systems, and from these packet capture, we can surmise (unless stated otherwise by the GDS, IATA or acquiring banks) that these clients are indeed “Internet Based Virtual Terminals”. This gives our travel agencies a measurable confidence to approach this channel with SAQ C-VT (as long as all the other eligibility requirements are met).

Thanks for reading this post, and as always, let us know if you have any queries regarding your PCI-DSS program, at pcidss@pkfmalaysia.com.

« Older posts Newer posts »

© 2025 PKF AvantEdge

— Up ↑