PKF AvantEdge

Author: pkfavantedge (Page 20 of 37)

PCI-DSS Logging in MySQL Community Version with MariaDB Plugin

March 18, 2017 / / 0 Comments

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.

Alienvault Troubleshooting: The Missing Sensor

March 15, 2017 / / 0 Comments

avlogo

USM Sensor not displayed properly at “AlienVault Center” of the USM Server

We have recently been involved in a few deployments of Alienvault. Aside from the All In Ones, we have had a few projects where separate sensor, loggers and servers were deployed, as well as even deploying USM Anywhere, Alienvault’s new flagship cloud centric product that literally makes Alienvault USM works – well – anywhere.

While the USM Anywhere deserves its own piece of article, in this short article we will explore the often seen problem we call: The Case of the Missing Sensor.

So, you have setup the standard server and sensor properly and as per the deployment guide that you find here. The configuration was well configured and the sensor peacefully connects to the USM Server. So you break open the celebratory glasses and start relaxing. You let your customer go through the whole features, absolutely confident that they will be impressed with everything you have done so far and they will be signing off the implementation sheet, and you will be paid and you will ….

“Hold on. Where is the sensor?”

Startled, you look at the screen and even though you have configured the server IP address in the sensor, you do not see any sensor under the Server’s Alienvault Center section. This makes it look like the sensor wasn’t  deployed but in fact all has been configured and accepted. If it didn’t show under AlienVault Center, you won’t be able to manage and update the sensor properly. Plus, it makes it look like you sold them a sensor but then ran away without actually installing one. Which makes you a charlatan. Which isn’t good.

So, you try the well tested “alienvault-reconfig” and cross your fingers. Do it on both server and sensor. No luck.

If you hit a brick wall on this, one method around it is to add the sensor manually into the server.  The below is the command used to fix it:

To add sensor into Server

#alienvault-api add_system --system-ip=[sensor's ip] --password=[sensor's root password]

Once you run the command, that doggone sensor should show up properly under the AlienVault Center and you look like a king in front of your customer. However, like all CLI commands, you need to make sure that if this is done on production, proper backup and proper due diligence has been done.

There is not much detail found but there is similar issue found at the Alienvault forum and the thread is a couple years old.

AlienVault Forum: https://www.alienvault.com/forums/discussion/1322/adding-sensors-to-the-alienvault-centre-display

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

February 28, 2017 / / 0 Comments

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.

PCI-DSS Evidences: Your Type of Compliance

February 25, 2017 / / 0 Comments

pci-compliance

Since our last post, we have received some queries on how do we get PCI-DSS started. A majority of our clients are doing Level 1 Certification – this is where we come in and do a gap assessment, determine scope and then remediate and certify. However, lately we have been seeing more and more clients looking to do PCI-DSS on their own.

The question is: Can they?

Well – as with many questions for PCI-DSS, the answer is: it depends.

You see, the journey to PCI-DSS is different for different companies. Some need to go through the whole road. Some goes through just a little. Some need a third party to audit, some can do their own assessment…so while the standard is ONE, the ways to achieve it is MANY.

Now, enough of the philosophical babbling. Simply put: if you are doing PCI-DSS, you simply have 3 available options:

a) Third Party Certification

b) Validated Self Assessment Questionnaire (SAQ)

c) Self Signed Self Assessment Questionnaire (SAQ)

That’s it. You will fall into one of these buckets. If you fall under b) or c), you will then further have to wade through the types of SAQs: A, A-EP, B, B-IP, C, C-VT, D-SP, D-Mer, P2PE. Yes. They have a lot. But in general, your consultant or QSA should be able to tell you which one is right for your business.

Now back to the buckets. What’s a third party? No, it’s not literally a third party that you go to after your graduation and you are getting smashed. In audit terms, there are 3 kinds of audit – first party which is where internal auditors of the company audit themselves. Second Party which is where an external company with ties to the auditee company audits the auditee company – for whatever reason. It could be a supplier audit, it could be a due diligence audit before takeover, it could be a regulator auditing its regulatee etc. Finally a third party is a completely independent organisation auditing the company.

So the first bucket is a third party certification. This is where an external company called a Qualified Security Assessor (QSA) assesses your company and provide a Report on Compliance. This is where they will ask you to do a gap assessment, assist you through the ‘remediation’ period, and do the certification. What a lot of people don’t know is that actually, Merchant Level 1 also has an option to do a first party audit. This means they need an ISA (Internal Security Assessor) in their organisation who is able to sign off on the ROC. Of course, getting an ISA certified is another story, and in most cases, many just take the QSA route.

The second bucket is a Validated SAQ. This will not apply to Level 1 Merchants or Level 1 Service providers, and this is available for Service Providers Level 2 or Merchants Level 2 and below. Basically this means that theoretically, you can complete the SAQ that is applicable to your company and sign off and you are ‘compliant’. This also means any Tom, Dick and Harry who thinks that a firewall constitute setting an actual office wall on fire, can sign off on 1.1.4 (a) which asks if a firewall is implemented in your company. Seriously though. That’s why Mastercard has this caveat:

“Effective 30 June 2012, Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

Many, including myself, find this caveat extremely frustrating. To cut the long story short, Mastercard is simply saying for all Level 2 merchants you have 2 routes:

a) Do the Level 1 route. Get a QSA

b) Do your SAQ, but get the staff ‘engaged in the self assessment’ to be ISA certified. Now the first confusion is staff engaged in self assessment does not mean everyone involved in the audit. It basically means the one doing the assessment in behalf of the organisation and signing off at the AoC (Attestation of Compliance) of the SAQ. Whew! But still, now you need to get an ISA. It’s not cheap! And it’s also, to me, a really silly certification, but one that makes total Sen$e to the PCI-SSC.

In theory, option b) above is correctly still called ‘Self Assessment’ as it is still a first party audit in that sense.

Now the last bucket therefore is the truest first party audit. This usually applies to only Level 3 or Level 4 merchant, but sometimes we still find this existing in Level 2 Service Provider. Where the management say, “Screw it, let me sign it off and I don’t need any other signature on this” and the bank, customer or card scheme accepts it.

So this is the first step of your compliance – find out your type. Because you could be overdoing it (Level 3 Merchant doing a ROC Certification) or you could be underdoing it (Level 1 Service Provider doing an SAQ D). If you overdo it, it’s fine from PCI-SSC perspective, but your boss/stakeholders/board/customers might not be too happy when you have spent half the company’s budget and 8 months on the PCI program doing a full Level 1 RoC on all the 340++ subrequirements – and the vacation trainee points out that you only have to do a self signed SAQ A which takes about 1 day to complete. If you under-do it, likewise, you might be in an awkward position to explain to someone that your SAQ D-SP is not enough to convince your acquirer to start connecting to them, as they need a QSA signed ROC.

So how do we know?

Well – the easiest is to really, ask the ones who are pushing you for PCI? If you get the answer : “Ah, just get compliant!”, then you have more leeway to understand your business, and you might be tempted to just go for the easy way out. Don’t! Assess your business – if you are a merchant, then follow the number of transactions to determine which level you are at. Easy remembering:= 6 million and above for level 1, 1 – 6 million for level 2 and the rest level 3 and 4. I don’t differentiate 3 and 4 because there doesn’t seem to be a squat a difference to what you are supposed to do. It’s the same, they just classify it differently where level 3 is focused on e-commerce and level 4 is more on traditional transactions.

For service provider, it’s simpler. Level 1 is above 300,000 volume of card transactions and level 2 is below. There is no other levels for Service Providers. There is also only SAQ D available for Service Providers so you don’t need to think so much.

The next round, we will explore deeper into how do we get our scoping questions sorted out.

 

Passing PCI-DSS: Evidence Checklist – Brief History

January 29, 2017 / / 0 Comments

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.

« Older posts Newer posts »

© 2025 PKF AvantEdge

— Up ↑