Category: IT Compliance (Page 14 of 17)

PCI-DSS Logging in MySQL Community Version with MariaDB Plugin

pci-compliance

PCI-DSS is a standard that brings to mind the famous sayings of Jimmy Dugan, the coach of an all-girls baseball team in the movie A League of their own (Played by Tom Hanks):

“It’s supposed to be hard. If it wasn’t hard, everyone would do it. The hard… is what makes it great.”

Well, at least the first part. Whether the banter of it making it ‘great’ is a different story. Most PCI-DSS sufferers will add the word ‘pain’ after the word ‘great’. And, one of the main pains for PCI-DSS is logging and monitoring. That’s requirement 10 for you. So much so that PCI-DSS recently released a document specifically addressing this issue here. So you will be faced with myriads of issues – from the simple to the hard: no we cannot centralise log anything, we do not have logging function in our application, we do not know how to do daily monitoring of our logs, we do not know what to log or how to log, we are all running on DEC VAX from 1974. So many reasons.

One of the challenge we recently faced with the client was that they were using MySQL community version. The challenge was how they can log administrator actions and security INSERTS, UPDATES etc in mysql community version? Logging is totally available in Enterprise, but not the free one – or at least not in its limited form.

Enter Maria-DB Plugin. Now before we go into semantics, MariaDB is an opensource database created by guys who created MySQL. It’s a fork, because MySQL was acquired by Oracle some time back and everyone was afraid that Larry Ellison might gobble MySQL up the way Galactus ate planets. The cutest story here is that MySQL was named after the founder’s daughter – My. And yes, MariaDB is named after his other daughter! But the first daughter’s name is “My”…so it’s like, “Yeah, this is My, My Daughter.”

Anyway. So what we are talking about here is not for them to install MariaDB, but to use it’s ‘plugin’ for MySQL. Make sure the QSA doesn’t get confused on this because ours did and we entered into the twilight zone of communications for a while where nothing made sense.

The Advantages of using MARIA DB AUDIT PLUGINS are:

So this article, we are going to explain on how we install the plugins in MySQL version 5.6.35 that is based on CentOS 7.

  1. Download the latest plugin from the links given above and you should see the download directory as below. Choose the latest version. We used server_audit-1.4.0.tar.gz. in centOS. We can use the wget command that is:
    wget https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/server_audit-1.4.0.tar.gz
  2. Extract the tar file by using the command
    tar -xvzf <file name>
  3.  Login into MySQL and locate the Plugin Directory of MY SQL using the command below
    SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
  4. Copy the plugin to plugin directory in MySQL based on your linux server (64 bit/32 bit).
    • cp server_audit-1.4.0/linux-x86-64/server_audit.so /usr/lib64/mysql/plugin/
    • chown -R mysql.mysql /usr/lib64/mysql/plugin/server_audit.so

     

  5. Install the MariaDB Audit Plugin into the MySQL Server by this command inside MySQL
    • INSTALL PLUGIN ‘plugin name’ SONAME ‘filename.so’;
  6. Once Installation is complete, we’ll start the daemon with the following command in the command line:
    sudo systemctl start mariadb
  7. The command systemctl doesn’t display the outcome of all service management commands, so to be sure we succeed, we’ll use the following command:
    sudo systemctl status mariadb

    If MariaDB has successfully started, the output should contain “Active: active (running)”

  8. Next, let's take a moment to ensure that MariaDB starts at boot, using the systemctl enable command, which will create the necessary symlinks: sudo systemctl enable mariadb
  9. Next, we’ll turn our attention in configuring the syslog FormatSet the Type of Action that will be log (within MySQL)
  • Connect: connecting and disconnecting to/from the server will be added to the log. An unsuccessful connect will be logged as a failed connect including the error code.
  • Query: full statement including the values will be logged
  • Table: Any operation on a table triggered by query will result in an event the MariaDB Audit Plugin can catch to log it directly
SET GLOBAL server_audit_events='CONNECT, QUERY,TABLE';

You need to have root privilege to be able to change the Audit Plugin variables.  With this changed we are ready to enable the auditing, which we now will do by using the following command within MySQL:

SET GLOBAL server_audit_logging=ON;

The full set of variables is found on this page: https://mariadb.com/kb/en/mariadb/server_audit-system-variables/

To make the changes to the configuration of the MariaDB Audit Plugin permanent, we now need to add these settings to my.cnf. This ensures that the same configuration will be used after server restart.

Under [mysqld] in my.cnf, add in

server_audit_events=CONNECT, QUERY, TABLE
server_audit_logging=On

There you go, now your MySQL is ready to face the scrutiny of the QSAs in your PCI-DSS compliance program!

Email us at avantedge@pkfmalaysia.com for any enquiries regarding this plugin or PCI-DSS in general and we will get back to you as soon as we can.

We ratted on Amazon Web Services (and made them change!)

Just a funny post to include and which I was reminded of by a few of my clients asking this question:

“Can I put a logo on my website or in my marketing material to state I am PCI-DSS Certifed?”

Something similar to this, which we see all the time. It’s nice, it’s beautiful, it’s stately – it basically tells everyone that I have gone through hell and back.

PCI-DSS

Except. You can’t do that.

That is correct – you cannot put a logo like that on your website. Doing so will get you in trouble with the PCI-SSC, it’s basically infringing their copyright of their logo and they disallow it. Here is an article we wrote a while back that talks about this.

So what happened was, one of our clients insisted they can use it because they have seen it in AWS website. We took a snapshot of it and here it is

PCIAWS

You can see they have proudly displayed the Level 1 Service Provider logo of PCI-DSS ‘Compliant’ along with the nice and thoroughly aggrandizing ‘tick’ and an altogether unnecessary picture of a lock at the bottom. The only problem is that this logo is not endorsed by PCI-SSC and was probably created by their summer intern.

So we asked politely to PCI-SSC, why are you allowing AWS to use it and not our client? Is it because a certain Jeff Bezos is the most powerful man in the internet?

Their response was classic:

They are not allowed to use that logo. Unfortunately, we cannot police the entire internet, so we contact these firms as we learn of the logo use.

You are correct in your understanding of the article. We encourage you to refer your clients to this article when they question you.  And let them know we will be contacting this firm to have this logo removed.

We appreciate you bringing this to our attention.

Wow. That’s nice. The largest cloud provider in the entire known universe uses that logo and you cannot police it. This generally means, they don’t do any policing. At All.

I like the fact that they refer Amazon as ‘this firm’ as if AWS is some useless junk company in the outer fringes of Elbonia. I like that. It’s powerful.

So what happened? PCI-SSC like a chihuahua took on a T-rex and guess what? The T-Rex changed.

PCIAWS2

You can see now that the ugly ticked lock, illegal, summer intern designed logo is gone, replaced by another PCI logo. This time, this is a logo they can actually use because they are registered as a ‘participating organisation’. But nowhere in the logo does it state they are Level 1 certified Service provider.

We like to think, in our small and narrow mind, that we, an unknown security firm in the fringes of Malaysia AKA Elbonia to most of the world – made the mighty AWS change something on their website.

Such feeling of worthiness.

Passing PCI-DSS: Evidence Checklist – Brief History

pci-compliance
We have been working on PCI-DSS since 2010. We started out as project managers for an offshore bank in Brunei that approached us asking for PCI-DSS compliance. At that point, we had invested a lot on training and getting our guys ISO27001 lead auditor certified because we saw a stable demand for compliance. We just banked on ISO and ISMS to kick off because of the directive of our government that all Critical National Information Infrastructure (CNII) needs to be ISMS certified. The reality though was slightly different. We pitched for jobs and saw precious few coming to us. Mostly, it went to agencies already incumbent, or agencies that knew how to get projects from government. We didn’t. We were new boys on the block and I remembered we were so desperate for business we drove all the way to Penang for a half hour meeting with a potential company only for them to say, Sorry we have already given the project away. Well, we did market that we had an office in Penang, so they probably thought we came to meet them from down the street. And not down the country.

In any case, in the middle of this desperate look for ISMS business, our customer in Brunei asked us for PCI-DSS. We didn’t really know anything about it, but we said, sure, let’s do it.

We called up some big QSA-Companies – Trustwave, Verizon being some of them. Verizon didn’t even bother responding to emails and calls. Trustwave did respond to my email – 5 months later. The only one that responded was a company called Control Case International. They called around 4 hours after I sent an email, and I was contacted not by their sales, but their founder, Kishor. He called me directly from the US and told me, let’s do this.

PCI is already a tough journey to begin with. We hear some QSA-C touting that it’s as simple as ABC. It’s not. And it’s not fair to say that it is because if it’s easy, everyone will be doing it. That’s not to say it’s impossible. With proper scoping, proper guidance, all companies can get certified with hopefully minimum fuss, stress and cost. Having local support and a responsive QSA is key. Local support doesn’t have to be a QSA. In fact, if possible, it might be even better to have non-QSAs and project specialists handling the local support. In our experience, QSAs are a busy lot and are often flying around on audits and working out other projects. Having a QSA handle your PCI initiative and remediation might not be the most efficient way as most meetings will be conducted either on a call or webex. PCI consultants are more than able to handle the remediation support because they are less caught up with ROC (Report on Compliance) writing and QA processes – which eat a significant amount of time for QSAs.

We successfully managed the Brunei project to certification and from there on, Control Case wanted to work with PKF for more Malaysian business. We started from zero clients to more than 30 plus clients today. Our goal is to push 50 by the end of this year. While we do work with Control Case, we remain independent as PKF does not have any influence over any report or opinion that Control Case has, and in almost all our projects, we work as project managers and technical advisors for our clients, not for Control Case.  In that way, we are not part of Control Case, or in any way represent or partner with them and even in some cases, we work with other QSAs to achieve the same results.

One of the key areas we work with the QSA and customer on is the evidence collection. Evidence is a key ingredient to your PCI success. We call it audit artefacts – proof that controls are in place. It might be a simple sample of change management tickets, or a more complex sample of 12 month logging of your database – in any case, these are the bedrock of your PCI journey. Without solid evidences that key controls are in place, passing the QSA’s Quality Assurance is going to be very difficult.

In the next few articles on PCI, we will share our evidence collection methodology, our 95 checklist of evidence and sampling on how to get these evidences sorted out for you to succeed in your PCI certification journey.

PCI-DSS and the Retailer Conundrum

pci-compliance

Over the past six years, we have had our share of PCI-DSS experiences across different verticals. Unlike other standards, companies each have their own unique PCI journey to compliance, due to the type of business they have in regards to storing, processing and transmitting credit card information.

Payment gateways usually have a challenge in securing stored credit card information. Here we identify the areas and types of storage and the option for securing this data – usually with encryption. The good news is that most payment gateways do not have many physical locations in scope, so we are generally looking at maybe one main site and one DR site, or two at most. This helps significantly.

BPOs or outsourced companies are another animal altogether. These are generally multi site projects, with various types of interactions with credit card information – usually phone, or MOTO (mail order, telephone order).

Banks are probably the top of the food chain in terms of complexity. Not only do they have hundreds of sites which are in scope, they also have storage of card data all over, as well as ATMs in scope in different branches.

Somewhere in between, we have the retailers. Not the e-commerce only retailers but traditional retailers. And here, in this layer of retailers, choke full of credit card and personal information, the hackers ply their trade.

Target (ironically the target of one of the largest information heist in history), Neiman Marcus, Home Depot, PF Chang’s, even Wendy’s – these were all hit with credit card breaches, resulting in millions upon millions of credit card information siphoned off into the jungles of the Dark Web. Why?

In general, hackers view Retailers (and hospitals) as easy targets. One example is where hackers ship a box full of new POS (point of sales) devices to the retailer outlets with a note from the Chief Operating Officer that these are devices to be installed and used from here on due to security or upgrade concerns – and once installed, these POS devices start hijacking credit card information in behalf of the hackers. A similar vector of attack is to infect the POS updates with malware and once the malware (like BlackPOS) is installed, it’s open season.

For the Target case, 40 million credit/debit cards were lost through POS. The reality was that the hackers breached Target’s main network first and accessed the database. Thanks to PCI, their database were encrypted and instead of hacking the keys, the hackers decided to go to the source (the POS devices). If the data in the databases was not encrypted, the damage would have been much, much more (we are looking at 70+ million).

PCI has stringent considerations for the security of POS, including software and hardware checks, as well as physical location checks. This is why retailers going through PCI is facing such a hard time. Some of the main issues are:

a) Retailers are underfitted for security. I am not sure if there is such a word underfitted – but in most cases, budgetary concerns are usually the reason why there is so little investments in security systems for retailers. The focus is on efficient transactions, and often efficiency and security are strange bedfellows. While millions are spent on customer relationship management tools, and systems to predict customer buying habits and big data solution, the backend hardware are outdated – we have seen XP and its variants still going strong in some retailers.

b) Inventory is haphazard. Some retailers grow, and in growing they do not keep stock of their internal inventory of systems. Some customers we go into have a very rudimentary excel sheet dated back to 2009 for their systems inventory, that is inherited several times by different IT administrators who seem to be going in and out of the company.

c) Like b, IT admin staff in retailers generally do not stay long. While some of the have good intentions in implementing certain structures and projects, these get lost along the way as new staff replaces them.

d) Location, location, location. In security, more locations, more problems. We see main branches carrying out good security practices but replicating along 85 branches in the country is a different story. In most attacks, hackers might infiltrate through a smaller branch with less focus on security and less education on preventing breaches.

e) Technical considerations. Most retailers we see have rudimentary effort in securing the network. Perimeter wise, we have seen a conglomerate of firewalls from yesteryears that no longer have any updates – and a plethora of free security software that does not have any auto-updates on signatures and in some cases, are spyware themselves. The network itself is usually flat (because of efficiency) and this brings in a huge amount of scope when your database is next to your ERP and accounting system that is being connected by a 100 of junior staffs with their desktops running XP.

There are many reasons why retailers are now prime target for PCI breaches. How do we avoid these breaches?

Well, you can’t. You can deter, but you cannot fully remove the risk of breaches. PCI helps a lot but as of now, there is no silver bullet to resolve security completely, except to unplug everything and set up a pen and paper store like back in the Wild West. But where PCI comes in – physical location security, POS security, network and database security – these are all critical areas where retailers can start with. Some first steps for retailers:

Set up a proper inventory of systems: In my University in Western Australia, there is a huge engraving on one of the main halls: KNOW THYSELF. We generally use that advice a fair bit especially when we have had a fair bit of alcohol in the Beer Parties, while stumbling back to our dorms. But in order to know what we are up against, we need a proper inventory of what we have and set about securing these systems.

– Secure the perimeter: Firewalls and IDS/IPS are important here to ensure that attacks are sorted out and abnormal traffic behaviour is properly caught.

Segment the network: While Segmenting is not for everyone, the security benefit here is considerable. Databases which are critical systems should not reside on the same network as your junior associate’s desktop, especially one who spends half his/her time downloading music or watching youtube. An analogy here is simple: when you put a healthy person in a room with a sick person, the sick person doesn’t get well, the healthy person gets sick.

–  Eyes on everything: We can’t iterate enough how important monitoring is in retailers. A good security information and event monitoring (SIEM) system is KEY to their security. Because of the lack of security personnel, the SIEM takes away a lot of these manual responsibility in tracking down strange and abnormal events. If a SIEM was set up properly in the Target case, they would have realised that one of their printer spooler device was sending out FTP packets out from the network into another system in the internet.

– Test, test and retest: Test your systems for vulnerabilities. You don’t need to spend truckloads on penetration testing if you don’t want to. Scanning using a Nessus scanner or even OpenVas will be useful as a first step. If a system is not patched, patch it. If you are still using Windows XP, seriously consider upgrading it.

– Finally, educate the users: While this has become a mantra for consultants and trainers, it’s still true. The weakest link in the security killchain is between the keyboard and chair. That’s the person. Security awareness training is key. While firewalls, email filters and Intrusion detection systems can go a long way, the security infrastructure is compromised by one executive clicking on an email attachment with the word: “Watch this Cat play the piano!”. Boom. Welcome malware, welcome ransomware, welcome sleepless nights for IT.

In summary, PCI-DSS establishes good and practical security practices for retailers. It might not be cheap, but once you have been hit by a ransomware or have your data pilfered, the fallout costs would be even more significant. For retailers looking to start off your PCI journey, or who need assistance on your ongoing one, please email us at pcidss@pkfmalaysia.com and we will get back to you immediately.

The Long Road of PCI Recertification

pci-compliance

We have been in PCI-DSS for six years.

When we began back in 2010, we were tasked by one of our offshore customers in Brunei to get them “PCI” certified. Honestly, back then, early 2010, we were mainly doing IT audits under COBIT, a lot of penetration testing, some IT forensics and bogged down with piles of ISO27001 ISMS opportunities.Back then PCI was more known as Peripheral Card Interconnect, which are those add-on cards that you slot into your motherboard back in the days when you wanted to extend your network interfaces, graphics accelerators etc. I used to build computers in those dodgy computer shops back in the days, so I kind know that very well.

Fast forward six years, and now we are getting more and more queries for PCI-DSS. So much so that we have dedicated an entire team from our company to work only on PCI-DSS projects.

In earlier years, we brought our PCI clients through their first year certification, and many of them are now going through their 2nd, 3rd year recertification etc.You would think that most companies will find re-certification easy compared to the first time certification.

Don’t be fooled.

The thing about PCI is, during the re-certification, there is a lot more expectations on your organisation for compliance. An example – PCI requires logs to be retained 3 months online, 12 months offline. It also requires daily log reviews, as well as quarterly internal and external vulnerability scans.

Now for the first time certification, some of these requirements get a free pass: meaning, if our client had just installed a SIEM and only has 2 – 3 months logging set up, we verify those controls and based on those controls, we can pass their PCI. We don’t need to wait for 12 months to get the offline requirement passed. Likewise, if our client provides us with one internal and external scan, we can pass them for first time, we do not need a 4 quarterly scan before we sign off on the initial AoC.

However – once the re-certification arrives, these become MUSTs. Some of our clients want to undertake internal scans themselves and missed one quarter and expects us to still pass them. Or they have a SIEM, but no action done on daily reviews, or their SIEM was not set up properly and no logs were sent there. They get upset when we say we can’t pass them on those basis because their response was “We did this last year!”

Also, evidences.

Whenever we conduct our audits, we conduct it onsite. Onsite, the QSA will verify these controls if they are in place or not. On top of that, we require audit evidences. This is normal even out of PCI – in our governance audit or ITGC we often rely on audit artefacts (we call it), to supplement our opinion on whether certain controls are in place. In PCI, these evidences might come in forms of documents, policies, screenshots, configs etc – anything that can prove controls are in place, and effective, and accordingly used as per PCI requirements.

The onsite audit confirms these controls. The evidences supplement the QA process. Each QSA needs to go through a stringent QA (quality assurance) process internally, whereby, the QA requires supplementary evidences to prove why the QSA arrives to such and such an opinion. Therefore,  there is always that post-audit work of compiling audit evidences.

Some clients are of the opinion that the onsite audit should end the process and the auditor passes PCI then and there. Unfortunately it’s not so simple as there is a check and balance involved. An example is this: one of our clients recently added in a few out of scope devices into the CDE. During the onsite audit, we referred these and requested these systems removed or resettled in another segment. They said, OK, we will put it in another VLAN. So, if they do that, is that ok? We said OK.

Fast forward to the post-audit work, we asked “Hey, have you done your VLAN yet?”

“Yes, we have. Can you pass us?”

“OK, can you give a screenshot of the new configuration in your firewall or switch to prove that you have done this action?”

“WHAT??! Why??!”

You see – as auditors, we simply cannot trust you for your word. It’s not personal. It’s not that because we find you are a shifty trader looking to spin some yarn and fleece us of our money. It’s simply because it’s part of our job. Evidences provide us with some measure of assurance that these controls are done correctly and in place. It’s not that we question your integrity. It’s strange that even at this stage, many people find this difficult to accept, and we have gone through many, many strange situations whereby I have faced a red-faced, yelling executive thinking that I am personally insulting him and his family name by not trusting what he is saying.

Audit evidences. It’s part of PCI.

There are of course some exceptions, such as certain private and confidential documents or config that cannot be shared – even in that case, we generally ask these information to be anonymized, but evidences to be submitted all the same: for instance, evidence of VLAN config, you can screenshot the config, and remove elements deemed sensitive (IP Address, versions, other information etc).

In summary – the second year onwards, this is where the real PCI battles begin. Your recertification efforts will be a whole lot more than the first time, so get started early. We will be posting more articles on tips and actions that will make your PCI certification successful.

In the meantime, drop us a note at pcidss@pkfmalaysia.com and we will attend to any queries you have.

« Older posts Newer posts »

© 2025 PKF AvantEdge

Up ↑