PKF AvantEdge

Category: PKF Avant Edge (Page 1 of 17)

Trends for InfoSec moving into 2023

January 19, 2023 / / 0 Comments

When I was a kid, I used to watch this show called Beyond 2000 and imagined, if I lived to year 2000, I would be seeing flying cars and teleportation and space travel. Later on, I had to temper my expectation but was still filled with optimism when October 21, 2015 rolled around, at least, we would have a hoverboard to fool around with. At least.

We are now in 2023. No flying cars. No hoverboards or hovertrains and no flux capacitors to go back in time to make gambling bets. We do have a lot of information security issues, though, and while not really sexy enough to make a Hollywood movie around it, it’s still giving us enough to do as we ride into this new year on what trends we think may impact us moving forward.

To understand why information security has become increasingly important in recent years, we look at the sheer amount of sensitive information being stored and transmitted electronically, and shared in our everyday interaction. We share and give information without us knowing it, even. Everytime we browse the net, everytime we hover our mouse over a product, everytime we use our credit card to get your coffee or pay for Karaoke session, everytime we check our location on Waze:- the vast array of information and data is being transmitted and curated carefully by organisations intent on peering into our lives to make it “better”.

As information continues to grow, increasing amount of incidents follow. Some of the more high profile ones include

a) SingHealth – In July 2018, one of Singapore’s largest healthcare group, SingHealth, suffered a data breach where personal information of 1.5 million patients, including Prime Minister Lee Hsien Loong, was stolen. How was this achieved? The attackers had gained unauthorized access to the network and exfiltrated the data through a sophisticated method, which involved using a “well-planned and carefully orchestrated cyber attack” and a “spear-phishing” campaign in which the attackers sent targeted emails to specific individuals within the organization to gain access to the network. No matter how much investments we make in technology, the weakest link still remain the humans around it, especially those interested to click on links depicting a cat playing the piano furiously.

b) India’s National Payment Corporation of India (NPCI) – In January 2021, the NPCI, the company that manages India’s Unified Payments Interface (UPI) system, which enables inter-bank transactions, experienced a data breach. The breach was caused by a vulnerability in the UPI system that was exploited by hackers, who then used the stolen data to make fraudulent transactions. The incident resulted in a temporary suspension of the UPI system, causing inconvenience to millions of users.

c) Garmin – Back in 2021, Garmin, a leading provider of GPS navigation and fitness tracking devices, was targeted by a ransomware attack. The attackers used a variant of ransomware called WastedLocker, which encrypted the company’s data and demanded a ransom payment. The attack caused the company to shut down its operations, leading to widespread service disruptions.

d) SolarWinds – Ah, this was probably one of the largest profile cases of data breach in recent memory. It was discovered that a sophisticated cyber attack had breached multiple government agencies and private companies, including SolarWinds, that runs IT management software. The attackers used a vulnerability in SolarWinds’ software to gain access to the networks of the companies and organizations that used it, and used those accesses to steal sensitive information. The incident was attributed to a Russian cyber espionage group known as APT29 or “Cozy Bear”.

Many more information security issues will continue to occur well into this year and the next and the next. One of the burning question is how companies can keep up with this movement, and how we can remain vigilant.

One trend that is likely to continue into this year is the establishment of cloud computing. While previously we had AWS/Azure, we now see a larger array and options for cloud providers. Within the cloud itself, services being offered are replacing traditional needs for separate security functions like logging systems, authentication systems etc. As more and more organizations move their data and applications to the cloud, it will become increasingly important to ensure that this data is protected against unauthorized access and breaches. This will require more stringent security measures to improve encryption, multi-factor authentication, and continuous monitoring of cloud environments.

One of the more interesting ideas that has floated around is the use of blockchain technology for security. Blockchain is a decentralized, distributed ledger that can be used to securely store and transmit sensitive information. This can help in the C,I,A triad of security. Encryption for confidentiality, immutability in blockchain records to ensure integrity; decentralization of data to remove single points of failure to ensure availability. There could be many more uses, but it still remains an abstract for many organisations looking at this for their information technology. As such for basic implementation, this may be useful for applications such as supply chain management, where multiple parties need to share information in a secure and transparent way.

Another growing trend, as always, is the need for strong cybersecurity workforce. As the number of cyber threats continues to grow, it will be increasingly important to have a workforce that is trained and equipped to deal with these threats. This will require organizations to invest in employee training and development, as well as to recruit and retain highly skilled cybersecurity professionals. Professional training, a big industry in Malaysia, will continue to play a key role in enabling people to carry out their vital tasks within the information security landscape.

Another abstract trend we often hear, deals with the Internet of Things (IoT) devices. In short, IoT refers to the growing network of physical devices, vehicles, buildings, and other items that are embedded with sensors, software, and connectivity, allowing them to collect and exchange data with each other. The example we always see is that fridge telling us we are running short on milk and placing an order to get milk for us. But IoT is happening whether we like it or not. Healthcare will be heavily dependent on it as information is exchanged with digital systems across nationwide healthcare systems; manufacturing of course is putting more traditional systems onto the network to integrate with automated processing tools; transportation is getting more digitized than ever, car manufacturers now looking not just to hardware but to cloud enablement of software running in cars. Even wearables, fitness apps, smart homes etc are impacting end users in more ways than we can imagine. It’s coming. or it’s here – eitherway, we expect 75 billion devices to be connected over IoT by 2025.

Another trend we like to see more in 2023 is the use of artificial intelligence and machine learning for security. These technologies can be used to detect and respond to cyber threats in real-time, as well as to analyze large amounts of security data to identify patterns and anomalies that may indicate a potential attack. We traditionally have threat intelligence but the time to respond to threats were still lagging behind, dependence on human intervention and decisions. With automated systems, more advanced rules and correlation of multiple information points, actions can be orchestrated through a more meaningful, machine learnt manner as opposed to depending on manual rules and signatures.

While not the most sexy or interesting, where we want to see improvement and a trend to get better, would be to improve and make more effective incident response plans. With the increasing number of cyber threats and attacks, it is critical that organizations have the ability to quickly and effectively respond to security incidents. This will require organizations to have detailed incident response plans in place, as well as to regularly test and update these plans to ensure that they are current and effective.

One trend we want to see more, especially in our accounting and auditing industry, is the adoption of security automation. This will involve the use of software tools and technologies that can automate various security tasks, such as vulnerability management, incident response, and threat intelligence. Implementation of tools such as Ansible has been done in our organisation, providing at least a first layer of understanding configuration and management of systems. With more automation, this will help us to more efficiently and effectively protect and respond against cyber threats.

Finally, some of the things we hardly talk about in information security is how much more integrated infosec needs to be in the field of humanities. A lot of us approach info sec from a technical viewpoint, which is great but perhaps a more effective viewpoint should be from the views from humanities. The humanities can play several roles in information security, including providing a broader understanding of the social and cultural contexts in which security threats occur, assisting with the development of effective communication strategies for raising awareness and educating the public about security risks, and helping to design user-centered security systems that take into account the needs and behaviors of different groups of users. Additionally, the study of ethics in the humanities can be used to inform decision making and policy development in information security. An example would be how implementing more stringent security monitoring may impact the innate need for privacy within employees – where, though the technology is sound and good and the intent is well thought of, organisations may still end up pushing out policies and technology that people will revolt against as opposed to embracing. This is not a field we often think of, but moving forward, it’s worth dwelling on and indeed provides us a more holistic way on how infosec can be part of our lives.

This isn’t so much of our traditional compliance article, but it’s always interesting to try to peer into a crystal ball and see what’s ahead and then at the end of the year see what has been proven more correct or wrong in our trends prediction. Drop us a note at avantedge@pkfmalaysia.com and tell us what you think, or if you require any of our services. Have a great year ahead!

Recap on PCI v4.0: Changes in The 12 Requirements

January 12, 2023 / / 0 Comments

So here we are in 2023 and PCIv4.0 is on everyone’s thoughts. Most of our customers have finished their 2022 cycle; and some are going through their 2023 cycle. Anyone certifying this year in general, means that for the next cycle on 2024, they will be certified against v4.0. V3.2.1 will be sunset in March 2024, so as a general rule of thumb, anyone going for certification/recertification in 2024 – hop onto v4.0.

Take also special note of the requirements where statements are “Best practices until 31 March 2025, after which these requirements will be required and must be fully considered during a PCI DSS assessment “.

It doesn’t mean that you can actively ignore these requirements until 2025; rather, to use this period of around 2 years as a transition period for your business to move into these newer requirements. So, to put it short: start even now. One of the requirements that gets a lot of flak is 3.5.1.2 which is the disk level encryption; in other words, technology like TDE being used to address encryption requirements. This is no longer a get out of jail free card because after March 2025, you will need to implement (on top of TDE, if you still insist on using it), if you are not using it on removable media – the 4 horsemen of the apocalypse – Truncation, Tokenization, Encryption or Hashing. And before you get too smart and say yes, you are using Encryption already, i.e transparent or disk-level encryption; PCI is one step ahead of you, you Maestro of Maleficant Excuses, as they spell out “through truncation or a data-level encryption mechanism“.

So, for v4.0 it’s probably easier to just break it up into

a) SAQs v4.0 – Self assessment

This is straight forward – a lot of changes have occurred to some of the venerable SAQs out there, such as SAQ A. I’ll cover that in another article.

b) ROC v4.0 – from QSA/ISA

Most QSAs should be able to certify against v4.0. You can check on the PCI-DSS QSA lists, they have ” ** PCI DSS v4 Assessors  ” under their names. There also may be some shakeout that some underqualified QSAs may not go through the training to upgrade to v4 assessors. On another note, ISAs don’t generally have these requirements to upgrade to v4.0; although it’s recommended.

Now, perhaps is a good time to just go through a very big overview of V4.0 and explain why some of these changes had been effected.

Changes to Requirements

For this overview, we will first look at the 12 requirements statements and see where the changes are. In a big move, the council has updated the main requirements (not so subtly), getting rid of many of the tropes of previous incarnation of the standard. Let’s start here.

Requirement 1 is now changed to “Install and Maintain Network Security Controls” as opposed to “Install and maintain firewall configuration to protect CHD.”

This is a good change; even if the wordings are still a little clumsy. After all Network Security Controls are defined so broadly and may not just be a service or product like a firewall or a NAC or TACACs. It could be access controls, AAA policies, IAM practices, password policies, remote access controls etc. So how do you ‘install’ such policies or practices? A better word would be to “Implement” but I think that’s nitpicking. Install is an OK word here, but everytime I hear that, I think of someone installing a subwoofer in my car or installing an air-cond in my rental unit. But overall, it’s a lot better than just relying on the firewall word – since in today’s environment, a firewall may no longer just function as a firewall anymore; and integrated security systems are fairly common where multiple security functions are rolled into one.

Requirement 2 now reads as “Apply Secure Configurations to All System Components.” Which is a heck better than “Do not use vendor supplied defaults for system passwords and other security parameter.” The latter always sounded so off, as if it’s like a foster child that never belonged to the family. Because it reads more like a control objective or part of a smaller subset of control area as opposed to an overarching requirement. It just made PCI sounds juvenile compared to much better written standards like the ISO, or NIST or CIS.

Requirement 3 changes are subtle from “Protect stored cardholder data” to “Protect stored account data” – they removed cardholder data and replace it with “account” data. It generally means the same thing; but with account data, they possibly want to broaden the applicability of the standard. Afterall, it may be soon that cards may be obsolete; and it might be all information will be contained in the mobile device, or authenticated through virtual cloud services. Hence a traditional person ‘holding a card’ may no longer be a concept anymore.

Requirement 4 reverts back to cardholder data, with the new 4.0 stating “Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks”. Which is sometimes frustrating. If you have decided to call account data moving forward, just call it account data and not revert back to cardholder data. Also this requirement changed from the older “Encrypt transmission of cardholder data across open, public networks”. It may sound the same, but it’s different. It removes the age old confusion on, what if I encrypt my data first and then only transmit it? In the previous definition, it doesn’t matter. The transmission still needs to be encrypted by the way it is written. However, with the new definition, you are now able to encrypt the data and send it across an unencrypted channel (though not recommended) and still be in compliance. Ah, English.

“Requirement 5: Protect All Systems and Networks from Malicious Software” is a definite upgrade from the old “Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs”. This gives a better context from the anti-virus trope – where QSAs insist on every system having an antivirus even if its running on VAX or even if it brings down the database with its constant updates. Now, with a broader understanding that anti-virus is NOT the solution to malicious software threats; we are able to move to a myriad of end point security that serves a better purpose to the requirement. So long, CLAMAV for Linux and Unix!

Requirement 6 reads about the same except they changed the word ‘applications’ to software i.e “Develop and maintain secure systems and applications” to “Develop and Maintain Secure Systems and Software”. I am not sure why; but I suppose that many software that may serve as a vector of attack may not be classified as an application. It could be a middle ware, or an API etc.

By the way, just to meander away here. I noted that in V4.0 requirements, every word’s first letter is Capitalised, except for minor words like conjuctions, prepositions, articles. This seems to be in line with some of the published standards such as CIS (but not NIST), and its basically just an interesting way to write it. This style is called “Title Case”, and It Can Be Overused and Abused Quite a Lot if We Are Not Careful.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know vs previous version Requirement 7: Restrict access to cardholder data by business need to know. Again, this is more expansionary; as system components (we assume those in scope) may not just be containing cardholder data; but have influence over the security posture of the environment overall. Where previously you may say, well, it’s only access to the account data that requires ‘business need to know’ or least privvy; now, access to authentication devices; or SIEM, or any security based service that influences the security posture of the environment – all these accesses must be restricted to business need to know. Again – this is a good thing.

Requirement 8: Identify Users and Authenticate Access to System Components vs previous version “Identify and authenticate access to system components”. This seems like just an aesthetic fix. Since, yes, you probably want to identify USERS as opposed to identify ACCESS. It could mean the same thing, or it may not. A smart alec somewhere probably told the QSA, hey, we identified the access properly. It came from login 24601 from the bakery department at 6 am yesterday. Do we know the user? No, but PCI just needs us to identify the ‘access’ and not the user, right? OK, smart alec.

Requirement 9: Restrict Physical Access to Cardholder Data is the only one that does not have any changes, except for the aforementioned Title Case changes.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data vs Track and monitor all access to network resources and cardholder data. So two things changed here. “Log” vs “Track” and System Components vs Network Resources. I personally find the first change a bit limiting when you are saying to just log instead of ‘track’. But I know why they did it. Because Tracking is redundant, if you are already Monitoring it. So in another dimension somewhere, the same smart alec may state, no where did it tell us to ‘log’ or keep logs in this statement – they just want us to Track/Monitor users. So its just for clarity that from here on, you log and monitor, not just track/monitor. The second change is very good, because now, there is no ambiguity for non-network resources. It’s true when one day, we actually came across a client stating this does not apply to them because they do not put their critical systems on the network and they only use terminal access to it, therefore there’s no need to log or monitor. The creativity of these geniuses know no bounds when it comes to avoiding requirements.

Requirement 11: Test Security of Systems and Networks Regularly vs Regularly test security systems and processes. Switching the word regularly is done just for aesthetic reading, but the newer word strings better and again, removes ambiguity. I mean first thing, the older requirement tells us to test ‘security systems’. Now most of the workstations et al may not be defined as ‘security systems’. I would define security systems as a system that contributes to the security posture of a company – an authentication system, a logging system, the NAC, the firewall etc. Of course, this isn’t what PCI meant and they realised, snap, English is really a cruel language. “Security systems” does not equal to “Security of Systems”. That two letters there changed everything. Now, systems are defined as any system in scope – not just one that influences security. We need to test security of all systems in scope. The second change to remove processes and insert in Networks is better, I agree. I did have a client asking me, how do we ‘test processes’ for PCI. Do we need to audit and check the human process of doing something? While that is true in an audit, that’s not the spirit of this requirement. This is for technical testing, i.e scans, penetration testing etc. So rightly, they removed ‘processes’ and inserted Networks; which also clears the ambiguity of performance of a network penetration testing, as well as application penetration testing.

Again, I just want to add, all these are actually clarified in the sub controls in the both v3.2.1 and v4.0 but if someone were just to skate through PCI reading the main requirements titles – I can see where the misunderstanding may occur with the old titles.

Finally, Requirement 12 Support Information Security with Organizational Policies and Programs is an upgrade from the previous Maintain a policy that addresses information security for all personnel. The previous title was just clumsy. Many clients understood it to be a single policy, or information security policy that needs to be drawn up, because it states Maintain A Policy. One Policy to rule them all. And this policy governs information security for all humans. Which doesn’t make sense. Unless the ‘for’ here was to mean that this policy needs to be adhered by all personnel; not that the personnel were the subjects of the information security. Yikes. The newer route makes more sense. Have your policies and programs support information security overall. Not information security of your people; but information security, period.

So just by reading the titles (and not going deep dive yet), we can see the improvement in clarifying certain things. There is more function in the sentence; there is more of an overarching purpose to it and most of all, it looks and reads more professionally that puts PCI more into the stately tomes of ISO, CIS or NIST.

While waiting for the next deep dive article, drop us a note at pcidss@pkfmalaysia.com if you have any queries at all about PCI, ISO27001, NIST, SOC or any standard at all. Happy New Year, all!

Technical Session: Clearing NTFS Dirty Bit

May 17, 2022 / / 0 Comments

Every once in a while, we take a break from boring compliance articles and write what’s more interesting – fixing broken stuff or troubleshooting problems that has nothing to do with human beings. It’s far easier dealing with machines.

So, what happened was, we had a USB plugged into one of our servers and doing some file transfers. The server wasn’t hooked up onto our UPS, as this was a test system – ok, it was actually sitting under my desk and everytime I turned it on, everyone in the office thinks a helicopter is outside the window. It’s old and loud and totally unsuitable to be located outside of a server room. Ah well.

In any case, halfway through the transfer, the power tripped. The server was ok upon restart but not the USB external drive.

It demonstrated a few symptoms:

a) When plugged in, the drive does whir up and explorer recognises it. The problem was it was listed as ‘Local Drive’ and nothing else, no other information. When clicked, it just freezes up everything. Right click does eventually brings up the context menu but when ‘Properties’ is selected, it hangs and never proceeds. So trying to scan the drive for errors from the GUI is a no go.

b) Command line wise – when accessing G:, again it just hangs. Chkdsk /f also hangs from command line so trying to scan from command line = no go.

c) Going into disk management GUI, it takes a long time before it eventually pops up and the good news was that disk management actually saw the drive. However, right clicking on it and trying to reassign the drive letter (as suggested by some other articles to recover), we get this annoying message:

The operation failed to complete because the Disk Management console view is not up-to-date.  Refresh the view by using the refresh task.  If the problem persists close the Disk Management console, then restart Disk Management or restart the computer

Microsoft being cryptic and mysterious

So like Lemmings, we proceed to refresh the console with F5 and it just hangs indefinitely and nothing happens until we unplug the drive. Then a string of errors come out like Location of drive cannot be found etc. It seems the auto opening of the USB drive was activated but Windows just couldn’t read the drive. So disk management is a no-go.

d) We tried installing other software like Acronis, or Easeus but none of these managed to read the hard drive and simply hangs until we unplug it.

e) Changing laptops/desktops/cables (all running Windows) – all the same result. The drive was acknowledged but explorer or other programs couldn’t open anything on it. This is good news actually; it doesn’t seem there was a hardware issue or any dreaded clicking noise indicating the drive was a dead duck.

f) So it does point to a software layer issue, which should be handled with a scan disk or check disk by Windows. However the problem is, the disk couldn’t be read, so it couldn’t be scanned. Booting into safe mode doesn’t help anything. Reinstalling the USB drivers doesn’t help. The drive simply refuses to go to work, like all of us on a Monday morning after being smashed with a hangover from a Sunday night out.

g) Finally, on event viewer under Windows Logs -> System, this particular classic comes up: “An error was detected on device \Device\Harddisk2\DR21 during a paging operation.” So if you go to advanced under system properties -> Performance ->Settings ->Advanced. Under virtual memory, you could uncheck the box to automatically manage the paging file size if you can. But no, Windows doesn’t read the drive, so clicking on G: once more hangs the whole system.

At this point we have wasted an hour trying to sort this nonsense out. Nothing in Windows was able to indicate the issue. One suggested running fsutil from command line. This can check for the dirty bit on NTFS, which is an annoying feature that basically renders the drive useless until the bit is ‘cleared’.

The problem with this was – yes, you got it – you couldn’t run any command on that drive as it just hangs. Nothing, no programs in Windows was able to do anything for this drive.

The Dirty Bit

So some definitions first – the dirty bit is a modified bit. It refers to a bit in memory, which switches on when an update is made to a page by computer hardware. It is just a 1 hex value situated in some place hidden on the portable hard drive.

From Microsoft definition

A volume’s dirty bit indicates that the file system may be in an inconsistent state. The dirty bit can be set because:

  • The volume is online and it has outstanding changes.
  • Changes were made to the volume and the computer was shut down before the changes were committed to the disk.
  • Corruption was detected on the volume.

If the dirty bit is set when the computer restarts, chkdsk runs to verify the file system integrity and to attempt to fix any issues with the volume. (In our case, this didn’t happen, obviously).

Assuming that this was a dirty bit problem (at this point, we were just shooting in the dark due to the lack of diagnostics, logs or events and we were just working on with some black magic of guessing).

From some articles in the net, the options to remove the dirty bit as follows:

  • You have 3 options to remove dirty bits from your computer. The first option is to trust the Microsoft disk checking utility by finishing a disk check operation. [This didn’t work as Windows wasn’t able to read ANYTHING and we could not run any windows based operations or commands or programs on it.]
  • The second method is that you move the data from the volume and format the drive. After that, move the data back. [This is way too much work. Plus, Windows can’t even access it. So the only option is to do a clone such as through Clonezilla? That’s a lot of work. And a last resort.]
  • The third method to remove the dirty bit is by using a hex editor with disk editing supported. [We didn’t explore this as this seemed a bit extreme, and probably the last time we handled a hex editor was when we had to hack in some computer games like Football Manager to give unlimited funds or a 99 in dribbling skills]

There’s an easier way.

So this is where you just need to give up on Windows and figure another way to check this disk. If you have a standby Linux box or Mac, that would help. But if not, you could actually use this great little tool called SystemRescue which among other tools, have the delectable DDRescue and Ntfs3g which will be important.

Boot up to SystemRescue (you can make a boot disk with DDRescue which is very much recommended – just use Rufus or another program to make it bootable, and download the distribution https://www.system-rescue.org/) and you basically now have a nice little Linux distro running from your USB and you should be able to also see your USB mounted with the command lsusb or lsblk.

Using lsblk -o gives you a view to see the type, size, device and a few more details. The below is an example (not ours)

Just identify which is your USB drive.

Using a the nifty ntfsfix (assuming /dev/sda1 is the USB drive you want to fix)

ntfsfix -d /dev/sda1

This basically clears the dirty bit which Windows for whatever reason, finds it so difficult to do and makes us jumps through hoops. In fact, fsutils from Windows only tells you that you have a dirty bit but doesn’t clear it. That’s like paying a doctor to tell you that you have cancer and not providing you any healthcare to it. Come on, Microsoft.

So right after clearing the dirty bit, the external drive is once again accessible. There were still some errors on the drive, but we just ran the check for errors option via GUI (since now we are able to access the properties of the drive again by right clicking for the context menu), and fixed up the inaccessible files.

So now you know. The next time you have an outage during a file transfer, it could just be the dirty bit. The problem is the diagnosis (again, Windows could just put into the event that there is a dirty bit set instead of leading us to this paging file nonsense treasure hunt). And of course, if Windows cannot access, using the SystemRescue utility, it’s a great tool to solve this issue.

And finally, according to some, another even easier way is to just plug in this drive into a Mac and apparently, it resets the dirty bit for some reason. I never tried this, so perhaps others can give it a try first before going the SystemRescue way.

Contact us at avantedge@pkfmalaysia.com for more information on what services we can offer you.

Have a good week dealing with human beings!

PCI-DSS Card Data Discovery Scans

January 24, 2022 / / 0 Comments
pci-compliance

For PCI-DSS, there are some fairly obvious requirements that are set in stone in order for you to pass PCI-DSS. ASV scans quarterly. Internal vulnerability scans – quarterly. Annual penetration testing. Half yearly reviews of firewall config and policies. Annual training awareness. These are biblical principles of the gospel of PCI.

And then again, there are other areas where interpretation is a little more of a touch and go; up in the air; subjective to the wind; sort of the things where there are as much disagreements and controversies as whether Han shot first or Greedo was just an absolute tool who misses from two feet.

And while most arguments often stems from our clients and us as we try to explain some concepts to them, there comes once in a while a subject where we find ourselves against the explanation of QSAs. Now, not all QSAs are created equal. When I say QSAs here, I refer to the individual QSA, not the organisation QSA. As in the human being who are QSAs for the QSA-C (QSA Company). We’ve worked with some who are technically well versed; we’ve worked with some who are strong in documentation and theory, we’ve worked with some who can communicate well but not so technical, and those who are opposite. But every once in a while, we come across QSAs who think they know everything (they don’t), and they stubbornly stick to a point of argument even when we have exhausted all avenues to show them their point is flawed. The more we argue, the more adamant they take their stance even if their justifications seem to be plucked directly out of their …. posterior appendages.

One of the items you will often see coming up in PCI-DSS is this thing called the Credit Card Discovery Scanner (CDD). What is this? In PCI-DSS standard pg 10:

To confirm the accuracy of the defined CDE, perform the following:
The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE.

PCI DSS v3.2.1

The CDD process is basically just a process using a tool usually to identify whether card information is stored in the clear within the organisation. These are usually regular expressions based applications; where it can categorise the type of card based on BIN or the initial numbers. These tools are often quite useful as well to find other forms of information like personal information etc, as long as you can identify filters and regular expressions for them. Some tools out there are from Groundlabs, Managed Engine, ControlCase etc. We also have free CDD tools like Pan Buster, Credit Card Scanner etc. The free tools are a little bit more difficult to use in our opinion and there seems to be less support for database scans and more false positives overall, so you may spend a longer time cleaning up the results.

Whether commercial or free tools, what PCI has been fairly silent about is whether these are mandated in the standard to be done. Unlike ASV scans or penetration testing, the standard doesn’t specifically state the need to run these tools for a normal PCI-DSS standard. When I say ‘normal’; I refer to a set of additional requirements under Appendix A3: Designated Entities Supplemental Validation (DESV) . These are specially assigned entities that has large volume of card data or has suffered significant breaches. This is designated by payment brands or acquirers, and it’s not something a QSA or even the audited entity decides on.

So looking into the card data scan requirements; we only have the Pg 10 scoping requirement and in the DESV portion , A.3.2.5 – “Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder environment or processes”

In most cases, CDD scans are done on an annual basis for normal PCI-DSS (non DESV), or at times half-yearly as required by the QSA.

So along came another QSA who stoutly declares that all companies are required to do a quarterly CDD scan regardless of size for all systems in scope. When politely reminded that he seems to be mixing up the DESV quarterly scan requirements; he says no. He is highlighting requirement 3.1: “A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.”

When pressed to explain why this is a CDD scan, he states its obvious, that everyone needs to run the CDD scanner every quarter to address this requirement.

OK. We disagree. Completely. This is one of the instance, where QSA super-imposes requirements on each other just because it sounds the same.

Let’s break it down by looking at the PURPOSE of the CDD scan. And the best way is to go back to the standard and pick up the part where the standard states a ‘data-discovery’ method in DESV A3.2.5.

Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN

A3.2.5 PCI-DSS V3.2.1

It’s clear that the CDD purpose is to locate where CLEAR-TEXT PAN is found in the CDE (and non-CDE) environment. Why is this important? Because in the CDE, there should never be any clear-text PAN found in storage. All PANs must be protected by either of the Four Horsemen of the Apocalypse: Encryption, Truncation, Hashing or Tokenization. A failed CDD means there are card PAN found in clear text within the CDE.

So with that in mind, lets go back to requirement 3.1. This is nothing to do with identifying clear PAN. It talks about identifying AND deleting EXPIRED card data (based on retention policies). That’s it. If the PAN is encrypted or tokenized but its stored beyond its retention period; requirement 3.1 tells you to delete it. It talks about retention period and storage beyond it. Which part of it talks about doing a card data scan to identify clear text card information?

In the description, it further states: A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

So QSA, please RTFM; requirement 3.1 isn’t talking about the need to run CDD quarterly to identify clear-text PAN storage; it is to run something (script) or manual; to identify PAN storage that is already expired. It is to discover duration of storage; not security of storage. Running a shell script may be good enough to get the timestamp of files; or checking the timestamp on the database entries to ensure that all card data is removed or anonymized after a period of say, 7 years.

If you need assistance in PCI-DSS or any other compliance standards like the ISMS or ITSM, drop us a note at pcidss@pkfmalaysia.com. We can help clarify some of these annoying requirements that even QSAs (as experienced as they are) are plucking out of their rear appendages.

PCI-DSS and Card Storage

August 29, 2021 / / 0 Comments
pci-compliance

We had an interesting discussion a few weeks back about storage in PCI-DSS. We disagreed with an acquirer’s position in how PCI-DSS views storage and therefore opened a whole can of … interesting debate.

The problem the acquirer had with our position was simple. We have a client who is currently doing a data migration import from another service provider to their document management system. Amongst the terabytes of data were possible scanned copies of credit card information, either in forms or actual card photo-copies themselves. Now, we are talking about terabytes.

Our position was fairly straightforward. Do you need these card data? We asked. No, said our client. We don’t need the card data as we do recon and backoffice operations on other form of identification. Can these information be removed or redacted? Bemused, they said, possibly, but the problem is that there are going to be millions of records to be dealt with.

Well, is there a way we can sanitize the data before it enters into your environment?

Yes, possibly, we need to ask the acquirer to ask their current provider to do it for us.

The provider you are taking business away from?

Yes.

Good luck…

And sure enough, the acquirer responded and asked us, “Shouldn’t PCI-DSS allow the storage of these card information, and how your client is able to deal with it? Why do you insist on us redacting and removing the card information? What then is the purpose of PCI-DSS??”

Now, on the surface, that argument does make sense. After all PCI-DSS applies to entities who store, transmit and process credit card information right? Why then wouldn’t we want our client to store credit card information if they are going through PCI-DSS?

Unfortunately, this is a case of getting the solution (PCI-DSS) mixed up with the problem(storing card data). In other words, in a more current analogy, just because I got vaccinated doesn’t mean I would purposely go out and try to get infected so that the vaccine has something to do. The purpose of PCI isn’t for you to store credit card. It’s for you to manage the storage of credit card IF you store it. Storing credit card isn’t a PCI-DSS objective, its an issue that PCI-DSS tries to solve.

So back to this little kerfuffle; if they pass us terabytes of information with card data, our client will need to figure a way to protect this data. Likely encryption of any information that card data is present, which includes key management etc. If they can redact it and remove it before it enters into our client’s environment, then we avoid it. We are basically following the concept of PCI-DSS :

Requirement 3 addresses protection of stored cardholder data. Merchants who do not store any cardholder data automatically provide stronger protection by having eliminated a key target for data thieves. Remember if you don’t need it, don’t store it!

PCI-DSS Prioritized approach

If we don’t need it, don’t store it. In this case, we don’t need it, so we are trying to escape storing it. However, if this cannot be done (which likely it won’t be), then we just need to put controls in there. We’re trying to get our clients to do less and we are also trying to remove card footprints in other areas, thus reducing the risks to the card brands, and likely save the world from impending disaster and destruction.

However, we do have another issue.

Because there is potentially CVV storage (photocopy of cards front and back) and scanned into softcopies, we have a bit of a problem. CVV cannot be stored in any format or in any media post authorisation. So therefore, if this is being dumped into our client’s environment, it’s imperative someone removes this information. To us, its a lot easier to remove it at source; but unfortunately that means there is an effort to be spent on it, which no one is willing to do.

How the CVV got stored in the first place is a question that we don’t have an answer to. However, we do know that if CVV is present, we cannot just encrypt it and be done with it. We will need to remove these information one by one. There are a few solutions out there that can do auto redaction and be applied to a massive amount of files, provided that the files are in a sort of standard fashion. That could be a solution on this, but again, it’s beyond what we are discussing for this article.

The point is, having PCI-DSS doesn’t automatically mean we MUST store card data. It simply means IF we store card data we are applying PCI-DSS controls to that storage of card data.

Let us know if you need more information about PCI-DSS or any IT standard compliance like ISO27001 or CSA/SOC, we are ready to assist, just contact us here. Stay safe everyone!

« Older posts

© 2023 PKF AvantEdge

— Up ↑