PKF AvantEdge

Category: IT Audit (Page 11 of 13)

PCI-DSS and the Retailer Conundrum

October 18, 2016 / / 0 Comments

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

September 10, 2016 / / 0 Comments

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.

The Obfuscation of PCI Standards

August 14, 2016 / / 0 Comments

pci-compliance

When you go through the PCI-DSS standard, while in most part, the sections are clear, there are some that just annoys the heck out of me, for good reasons.

Stateful inspection and Anti-spoofing in firewalls – I know these are useful features, but it is extremely rare these days to encounter clients going for PCI-DSS that own firewalls without these capabilities inbuilt. Even the humble ScreenOS running on your tiny SGs (Juniper) are enabled by default. While this isn’t an issue, we’ve faced vexing times when our clients are sometimes asked by their QSA, to show the firewall rules that prove that Stateful inspection and anti-spoofing is turned on. We have to come in and explain to them that its already enabled by default, and they insist on us testing and showing them traffic captures. Sometimes, I just show them the manual and entitle my email “RTFM: Stateful Inspection was first introduced in 1994.” You would think that PCI would do something better than to ask this question.

AntiVirus and AntiMalware – the researchers at Imperva, a couple of years back, did a study of effectiveness of antiviruses.They collected 82 new computer viruses and ran the malware against antiviruses from some of the largest companies like Symantec, Kaspersky, McAfee. The results: initial threat detection rate was 5 percent. That’s detection. This means 95% of malware is undetected. I don’t know how strong this hypothesis is, but frankly, we have known for years antiviruses, while there are limited uses, presents to us a false sense of security. Just because the antivirus says, “ALL IS SECURED” doesn’t really mean anything. The annoyance here is not that PCI has antivirus as part of their controls, they dedicated an entire requirement to it. It’s not effective – move on!

Confusion of application testing – Requirement 6.6 states:

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

b) Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

Now, we need to clarify this because this is obfuscation. Note the nice caveat they put into 11.2. Now, if you go to 11.2, you get a whole bunch of requirements for vulnerability scans, quarterly ASV etc.This is understood, right

So the above, you would surmise this: if I have a WAF (web application firewall), I do not need to do any web applications review, correct? What IS a web application review anyway? In a lot of instance, QSA will interpret it as web application testing, covering OWASP top 10. In pentest world this is called WEB APP PENTEST. This tests issues like cross site scripting, validation etc. You can find more here

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

A web app PT can set you back around RM10 – 25K depending on your web app and the provider. I’ve seen web applications go into the RM50 – 80K regions before for massive applications, but in general for a web application payment system, you would get that range (unless the provider is looking to rip you off, in which case I suggest you give us a buzz).

So if you have 10 – 20 Web App, that would set you back a mile, so the suggestion is to “Let’s invest in WAF”, where you pay a license and every year you don’t have that WEB APPLICATION testing headache siting on your books. In the long run, it makes more sense if you have a lot of web applications to test.

Now, here is the PCI problem.

Requirement 11.3 – Implement a methodology for penetration testing that includes the following:

blah blah blah

 – Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

Unfortunately the presence of 11.3 renders the earlier requirement choice useless, because now QSA interprets at despite having invested in WAF, they are still insisting on getting 11.3 passed, which requires this application layer PT!

My question to the PCI-SSC, why don’t you include this 11.3 caveat in the earlier 6.6 requirement instead of the useless 11.2 caveat which anyone knows how to read? And if my interpretation is wrong, I am going to war against some of these QSAs because they basically said, it’s nice to have WAF, but you still need to do App PT. In fact, one of them actually said: “Well, the advantage is that you are more secure.” Yes – but our client’s goal was to pass PCI. If they wanted financial modelling and investment advise from you, they would ask it, if not, just do our job and interpret the standards properly! Will someone from PCI-SSC actually clarify this because I’ve talked to some QSAs on either side of this opinion – some say WAF OR APP PT, some say, APP PT regardless of WAF.

To be safe – get your QSA to interpret this before making a decision to invest in WAF, because this is a major roadblock in a lot of cases we are in.

PCI DSS and the Problem of Scoping

June 5, 2016 / / 0 Comments

pci-compliance

I recall in an actual case a few years back when I received a call from a company requesting us to do a certification for PCI for them. So I met them and drew out their PCI plan starting with a gap assessment, remediation and certification audit.

They said they have already done their own gap assessments internally by their ISMS guys. And they will be doing all their remediation on their own and they just needed me to quote for certification audit because “PCI is forcing us to be certified by a third party, which we believe we can do it better than you can”.

There was nothing much to talk to them about, but I did mention that if we find major NC (non compliances, in ISMS speak), we would then use that ‘certification audit’ as our own gap assessment and that we might be required to come back again to verify.

The company truly believed that PCI was a subset of ISMS and they handled it as such.

So we came in for the certification and found out that their entire scope was completely messed up. For instance, there was another out of scope network and systems connecting into their CDE for monitoring. Because card data wasn’t passing through, they marked it as out of scope. Unfortunately, PCI doesn’t see it that way. This would be considered an Non CDE In Scope, and systems within this network will need to be secured as well, and hardened as per PCI. The logic is that if these systems are compromised, there is a path into the CDE that can be exploited.

They made a huge fuss on this, claiming that they are willing to absorb the risk and that their management signs off on the risk assessment.

ISMS is a best practice/guideline at best – it’s a great marker for security, but PCI is a standard. If you can’t meet it, then you don’t meet it. Of course, there are ways around this particular issue, but they insisted we passed them simply because their management accepted the risk.

Here’s another idea: PCI-DSS generally doesn’t really care about your business. It’s not about you. It’s about card data. Visa/Mastercard and the Jedi PCI council are not concerned about your business – they are concerned about the confidentiality and integrity of card data. That’s why you will not find any BCM or DRP requirement in PCI. RTO and RPO? Pfft. They don’t care. Your business can go down for 10 weeks but as long as card data is safe, it’s good.

And that’s why, scoping is HUGELY important. Many people might think that a gap assessment is a waste of time. It is, if it’s done incorrectly. I recently witnessed a ‘gap assessment’ report that was a complete mess. It just detailed the PCI twelve requirements and in each requirement gave an overview of the company’s controls and what they should be doing: ripped off almost verbatim from the actual standard itself. That can be downloaded for free.

A gap assessment needs to bring you from one place to another and needs to provide these:

a) A clear understanding of your scope, including a writeup on your network, and processes that have been assessed. It should also be clear what is out of scope. This initial scope usually is not set in stone as remediation would sometimes change what is in scope and what is not in scope. But at least you have something concrete to start with.

b) If possible, an asset register. For PCI. If this is not possible (for many reasons, e.g they have not purchase some assets required for a control), then the asset inventory needs to be prioritised a quickly as possible to see what is scoped and not. Asset should be clear on: Public ips, internal devices, servers, network devices, people involved, desktops, databases etc.

c) Network in scope and out of scope. This is key as companies are required to identify segments scoped out, and do segmentation testing. Also, CDE is clearly marked, NON-CDE IN SCOPE (we call it NCIS) must also be identified. Systems in NCIS could be monitoring system, SIEM, AD etc. Any system that connects to the CDE, but does not store, transmit or process credit card data are considered NCIS. NCIS must be scoped for testing, quarterly scans, hardening and such.

d) Clear roadmap for remediation and recommendations to proceed, specific to the organisation. These ‘gaps’ should all have a corresponding solution(s).

If the gap assessment doesn’t give you any of these, then it’s pretty useless. If it doesn’t move you forward or provide you with the information to move forward, it’s not a gap assessment. It’s an expensive training session.

So back to the first example of a customer. It wasn’t possible for us to certify them no matter how they argued, because simply they were not compliant (there were also many issues that they did not comply, for instance storage of card data in text files and sending via emails).

As a lesson – don’t neglect the proper scoping. It’s hard work, but as I always say: Start wrongly, do wrongly, finish wrongly. And that’s 6 – 8 months down the drain, with thousands of ringgit gone in investing, and job on the line. The second example is pertinent also. There is always a chance to OVERSCOPE as there is to UNDERscope.

An overscoping example would be to purchase all sort of snazzy security systems worth thousands of ringgit only to find that these were not needed, or that current controls were sufficient. It’s nice to have – but most of our customers, no matter how big they are, always have a trigger on the budget and cost optimisation is the topmost in their priority.

If you want us to help you in your PCI-DSS scoping, drop us a note at avantedge@pkfmalaysia.com and we can get you started with the initial understanding straight away!

PCI-DSS v3.2 is officially published

April 29, 2016 / / 0 Comments

pci-compliance

After some back and forth on the draft versions, PCI v3.2 is now officially published. You can go ahead and download it here, and click on the nice little link saying 3.2 and agree to all sorts of terms and agreements nobody ever reads about.

Anyway, a little bit of background on this release. Usually, versions for PCI are released in the later stages of the year in November. In fact, even I mentioned this to a few clients that version updates were done in November, until PCI recently announced that v3.2 is to be released in March/April timeline due to a few factors as described in this article. So yeah, now I need to admit I was bamboozled. PA-DSS v3.2 is likewise to be released sometime in May or June.

So here’s how it works: 3.2 is now officially effective. PCI v3.1 will be retired end of October 2016 (basically to allow everyone to sort of complete the v3.1 if you are already in the final stage of completing it). So all assessments/audit that occurs AFTER October will be version 3.2. This is important to note, because if any gap assessments begin now, and has a timeline to complete AFTER October, you want to use 3.2. For ongoing projects, it is best we scurry and get it all done before October! Chop chop!

There is a bunch of ‘best practices’ that will become requirements by February 2018. Other dates you need to be aware of:

a) June 30, 2016 – for companies not migrated yet out of SSL/early TLS, you will need to have a secure service offering (meaning an alternative service utilising TLS.1.1 and above. I will go out on a limb here and suggest to use TLS1.2 knowing how volatile PCI guys are in changing stuff).

b) June 30, 2018 – SSL/early TLS becomes extinct as far as PCI is concerned. No more mitigation plan! The exception is on POS terminals that has no known exploits.

c) January 31, 2018 – This is the deadline where new requirements graduate from being ‘best practices’ to ‘mandatory requirements’.

OK, now that’s out of the way, here’s a snapshot on the main stuff of v3.2 and what we are facing:

a) New Appendix A3 covers the Designated Entities Supplemental Validation. This basically means that if any acquirer or VISA/Master deems that a service provider needs to go through ADDITIONAL requirements on top of the torture they have endured for PCI, they can. These victims could include companies making ridiculous amount of transactions, aggregators or companies that are constantly breached. So PCI has a whole bunch of extra stuff for you to do, mainly to deal with BAU activities, incident response, documentation and logical access controls.

b) Additional cryptographic documentation – Service providers are not going to enjoy this. We will now need to formally document the protocols, key strength, cryptoperiod, key usage for each key and HSM inventory. This should technically be done anyway in your key management procedure document, but now its a requirement. Take a look at NIST SP800-57 for the key concepts to get you started.

c) 8.3 is significant : Multifactor login. Whereby previous versions stated that 2 factor authentication is required for remote access from non-secure networks, now 3.2 shifted this requirement to “all personnel with non-console administrative access, and all personnel with remote access to the CDE”. Wait, what? This means, even if you are accessing an administrative UI or page (non-console) from a secure environment, multi-factor (2 factor is good enough) is required! I think there would be some pushback on this as this requires a fair bit of effort. We have until February 2018 to implement this.

d) Another big one is 11.3.4.1 – segmentation PT now needs to be done every SIX months as opposed to a year. This is not good news for some clients who have segments popping up like acne on a pubescent face. That’s quite a lot of work for them to do and this might give them more cause to think of a completely isolated network just for PCI-DSS with its own link and architecture, as opposed to sharing with multiple not in scope segments. Again, we have some grace period till Feb 2018.

e) New requirement 12.11 is interesting. I have always been an advocate to do constant checks with clients to make sure they are at least practicing PCI. We have this free healthcheck service every quarter for clients who take up our other services and we are checking exactly this: daily log reviews, firewall is clean, new systems are documented and hardened, incidents are responded, proper approval for changes etc. It’s nice to see that our efforts now have something formal tied to them. Feb 2018 is the deadline.

f) Here’s a downer. Appendix A2. We all know there was some sort of escape loop for those who were caught with SSL and early TLS in their applications. They created mitigation documents which may or may not be true. Just saying. Now, if you take this route, this is no longer a free pass for your ASV scans or vulnerability scans. If you have these protocols in place, your mitigation plan must fully address A2.2 requirements. If you are a service provider, take note of A2.3: YOU MUST have a secure service option in place by June 30, 2016! Not 2018. 2018 is when you stop using SSL/early TLS. So this timeline is slightly confusing. Like X-Men:Days of Future Past confusing.

Some main clarifications include:

a) Secure code training now officially needs to be done annually – you won’t want to guess how much push back I get on this when I tell clients it’s annual, and not something that is done when they have the budget for it (which is never).

b) Removing the need to interview developers to ‘demonstrate’ their knowledge – I do programming a bit, but I’ll be foolish to think I can go up against a senior developer who eats, breathes and … lives for coding. How awkward I’ve seen some younger QSAs struggle to do this (determining whether the senior dev guru is good enough), when its obviously not something they even know about. Let auditors audit and let developers code.

c) Finally, note added to Req 8 to say that authentication requirements are not required for cardholder accounts, but only to administrative or operational/support/third party accounts. We have always practiced this anyway but now its clear.

d) More clarifications on addressing vulnerabilities considered ‘high’ or ‘critical’. I am not a big fan of these. I think every vulnerability should eventually be addressed, just prioritised in terms of timing. Even if it’s low or medium, it’s still important to have a mitigating factor to it. There is a reason why it’s a vulnerability and not something you can sweep under the carpet.

e) A good note on pentesting in 11.3.4c – testing now needs to be done by qualified internal or external resource with independence. Again, we already practice this but it’s good that now it’s official.

So, that’s about it. Of course, there’s a fair bit more. I suggest you to poke through the summary of changes first and then go through the documentation itself.

Be aware of those dates! It’s all over the place (June 2016, June 2018, Jan 2018), and who knows these might change in the future. Have a happy compliance.

 

 

 

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑