Category: IT Security (Page 1 of 14)

Trends for InfoSec moving into 2023

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!

Introduction to ISO27001 (Information Security Management System)

One of our goal for 2023 is to provide more content in our technical articles, not just on PCI-DSS (which we have been primarily writing on), but on other areas where we are focused on. In fact, customers often express a little surprise when we tell them that we also do a lot of consulting on ISO27001, SOC1, SOC2, CSA, ISO2000 and pretty much the main technology compliances, even extending to NIST 800-171 and lesser known standards out there. They primarily associate us with PCI-DSS, which, while it is true it still is our main business, serves as a reminder to them and to us that we often end up forgetting to market our other services.

The other branch where we are very active in is in ISO27001. Like PCI-DSS, we do not do the certification (we leave that to the certifying body), because we often find ourselves helping our customers implement the system itself, and are generally very much involved in building policies, framework and guiding them through the standard.

Before we jump too deep in, let’s wade a bit into the standard for this article.

ISO 27001 is an international standard that outlines the requirements for an information security management system (ISMS). A company can certify to ISO 27001 by implementing the standard and undergoing an audit by a third-party certifying body.

Here are the steps a company can take to certify to ISO 27001:

  1. Understand the standard: Familiarise yourself with the requirements of ISO 27001, including the management system and control objectives.
  2. Perform a gap analysis: Compare your current information security practices to the requirements of the standard to identify any gaps that need to be addressed.
  3. Develop an ISMS: Implement an ISMS that meets the requirements of the standard. This should include policies, procedures, and controls that cover all aspects of information security, including risk management, incident management, and compliance.
  4. Implement the ISMS: Put the ISMS into practice by training employees, updating procedures, and monitoring compliance.
  5. Conduct internal audits: Regularly conduct internal audits to ensure that the ISMS is being effectively implemented and to identify any areas for improvement.
  6. Seek certification: Once the ISMS is fully implemented and operational, seek certification from a third-party certifying body. The certifying body will conduct an audit to ensure that the ISMS meets the requirements of the standard.
  7. Maintain certification: Once certified, it is important to maintain compliance with the standard by regularly reviewing and updating the ISMS, and undergoing periodic surveillance audits.

Certifying to ISO 27001 demonstrates to customers, partners, and regulators that a company is committed to managing and protecting sensitive information, and that it has implemented best practices for information security.

Like all standards, you should go in with your eyes open, as there are several major challenges that companies may face when attempting to certify to ISO 27001, if we were to address it step-by-step in the process described above:

  1. Understanding the standard: The standard is quite comprehensive, and it can be difficult for companies to fully understand all of the requirements and how they apply to their specific organization. The standard doesn’t apply the same for all companies, so beware. It’s not a checklist, either or a cookie cutter standard where you just take lock, stock and two smoking barrels all the requirements and force it down your own throat. There is the risk assessment process, the selection of controls, the statement of applicability – all of which, you can do it on your own or we can help you navigate through the forest of information.
  2. Conducting a gap analysis: Identifying gaps in an organization’s current information security practices can be a challenging task, especially for larger companies with complex systems and processes. Additionally, multiple departments make it more formidable to define scope. Unlike PCI-DSS (which is very definite in terms of scope), the expansion and boundaries of the ISMS can be much less clear.
  3. Implementing an ISMS: Developing and implementing an ISMS that meets the requirements of the standard can be a significant undertaking. It may require significant changes to existing policies and procedures, as well as the implementation of new controls. Expectations, time-resources are often overlooked as well and we have experience where companies go half in and then decide the water is too cold and they back off. It’s always important to set the tone early, set it from the top, which brings us to the next point.
  4. Employee buy-in: Getting employees to understand and buy-in to the importance of information security and to follow the new policies and procedures can be a significant challenge. By far, like any other standard, it’s not really a technical hurdle that often foil a company seeking certification, but human hurdle. People are too busy, or too focused on other areas; they simply do not have time. Without a top-down push, you will find a significant impediment convincing people that this is important. It’s a cliché but it’s true: the project is not an IT project, but a business project.
  5. Cost: Implementing an ISMS and seeking certification can be costly, especially for small and medium-sized businesses. Many a times, potential customers go in with the idea that a budget of RM10k would be enough to go end to end. Now, I am not saying it’s impossible; but it would be very difficult to properly implement an ISMS without a proper budget. The range may vary, true, depending on how much work you can do on your own, but in general, like PCI-DSS, you probably would have to look at a fairly generous budget if this is your first time undertaking ISMS and you do not have an internal team to handle the compliance.
  6. Maintaining compliance: Once certified, it is important to maintain compliance with the standard by regularly reviewing and updating the ISMS, and undergoing periodic surveillance audits. This can be a significant ongoing effort, and it requires dedicated resources to ensure ongoing compliance. The cycle goes through surveillance audit 2 years after the initial certification and re-certification on the third cycle. Survelliance audit is still a fair bit of work as you need to demonstrate compliance to the ISMS standard over the period of the cycle (12 months).
  7. Finding qualified and experienced team: Identifying a qualified and experienced consultants who understand the process and how auditors work can be a big help. Understanding how the auditor conducts a thorough audit and provide valuable feedback on the ISMS can be a challenge, especially for companies that fairly unique in their process or have specific industry requirements.

By understanding these challenges and developing a plan to address them, companies can increase their chances of successfully certifying to ISO 27001. Contact us at avantedge@pkfmalaysia.com for more information on how we can help you begin your ISO27001 journey.

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

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!

Let’s Talk v4: Overview

So, on March 31st 2022, PCI-DSS v4.0 dropped on us.

The original timeline for v4.0 has already passed a long time back. Back in 2019, there had been talks that v4 would drop in late 2020. Then due to the global pandemic of unknown origins, it was moved to 2021 and now finally, they decide to release it in 2022. We all know PCI SSC loves deadlines. They love the whooshing noise deadlines make as they go by.

First of all, let’s start with another quote from the wisest sage of all generations:

Don’t Panic.

Douglas Adams

Because if we take a look at the timeline below, there’s a pretty long runway to adopt v4.0.

The above basically means this:

a) Entities undergoing PCI right now, whether it’s first time or renewals, if you are going to be certified in 2022, your current cycle and next renewal in 2023 can stay with v3.2.1.

b) Entities thinking to go through PCI-DSS, and will likely be certified in 2023, you can stay with v3.2.1 for this cycle, and then for the next renewal up in 2024, you will need to move to v4.0

Long story short, entities have 1.5 years to stay on PCIv3.2.1 and go v4.0 on your 2024 cycle. That doesn’t mean that you don’t do anything from now till then of course. Depending on your processes, there may be some changes. However, it’s not too crazy and it’s more incremental than anything else, including areas where we are already practicing , but was not noted in v3.2.1 (example being anti-phishing controls, which have been a staple for most of our FSI clients).

So we’re going to have a few breakdown of areas we think is fairly relevant to note in v4.0; a deeper dive into requirements that are added or changed, and more importantly how we think a company can move forward in preparation.

Of course that being said, the v4.0 is only 3 weeks old. A toddler in terms of its predecessors. Let’s put it into perspective. PCIv1 (and its sub versions 1.1 and 1.2) lasted almost 6 years from 2004 – 2010.

PCIv2 lasted half that time from 2010 – 2013.

PCIv3 and its sub-versions (3.1, 3.2, 3.2.1) lasted from 2013 to 2022. That’s 9 years old. So in retrospect, we are literally in the 0.6% timeline for v4 if it were to follow the v3 age. Meaning, there could be a lot of changes yet to come, or clarifications or explanations etc.

Over the life of v3, we’ve seen many supplementary documents (for scoping, logging, penetration testing, risk management etc) churned out in support to clarify v3 items. While not part of the standard itself, these supplementary documents and hundreds of FAQs are generally quoted or referenced by us to support our arguments for and against some of the decisions that QSAs put to our clients. These are extremely useful especially when QSAs put in some pretty daft interpretations of the requirements (see our previous post on CDD).

There has been some extremely subtle changes aside from the major ones and we want to note these items in page 4 of v4:

PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE).

Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account data – for example, entities that outsource payment operations or management of their CDE.

In accordance with those organizations that manage compliance programs (such as payment brands and acquirers); entities should contact the organizations of interest for more details.

pci v4.0 warning to those entities that scream i am out of scope because i don’t store, transmit or process stuff!

There’s a lot of things we dislike about v4.0. But there’s a lot of things we LIKE about it as well. So it’s like that family trip that you are taking with your entire extended family. There’s that cousin that you completely dislike that you wish you don’t need to make small conversations with – you know, the one that constantly name drops and questions whether you have achieve as much as he has in life. And tries to coach you to be a better person and live a better life, and have more than your currently unfulfilling, loveless marriage and a deadend, purposeless job as a PCI-DSS consultant. Yeah, you know it. But at the same time, you like these trips because it’s time with your family as well, and time to goof off with your kids, walk on the beach with your spouse and basically fantasize throwing your cousin into a pit full of vipers. v4.0 is like that trip.

The main takeaways from the above quote would be

a) No more free passes to those entities who claim they are out of scope simply because they don’t store, process or transmit card data. If you have impact on the security of the CDE, then you are in.

b) First time we are seeing the word “Organizations of Interest”. While this is nothing much, it’s like watching a movie in the cinema that’s based on a comic book and you see an obscure easter egg referencing to that comic and you get goosebumps because you know, you’re a nerd. And you like this kind of subtle references that no one else knows about. Basically OIs are the upstream customers, banks, FSI, organisations that are requesting your PCI-DSS compliance. It’s easier now to make this reference as it is now an official term in v4.0. Yay.

c) Organizations that ‘impact security’ is in. Previously the problem is that we had outsourced SOC/NOC, or outsourced providers that do not handle card data (e.g managed providers for firewalls etc) and even cloud services that handle the MFA or authentication generation, claiming that there is no card data, therefore they don’t need PCI. That’s fair enough, but we still need to assess that service as part of an on-demand assessment to ensure that that service is properly secured or at least has basic security functionality over it. While a majority of providers are fine with this, we have had antagonistic providers shouting to high heaven that we are idiots because of the very fact that they do not store, process or transmit card data; they should be completely disregarded from the PCI assessment. Um. No. You’re not and V4.0 is smacking you in the face for this.

Another item on v4.0 is the sheer amount of information they provide right at the beginning of the standard. They are talking about the scoping methods, segmentation, encryption and applicability on third party providers, use of third party providers and how to be compliant with them, BAU best practices, sampling methods, definition of timeframes, definition of words like significant changes, approaches to implementation of PCI-DSS, testing methods, assessment process, RoC writing and if you look carefully, there is also a recipe in there for Jamie Oliver’s Yorkshire Pudding.

In the previous v3.2.1, the requirements started on page 20. In v4.0 the requirements start on page 43. The total number of pages in v4.0 is 360, up 158% from the previous 139 pages. So, simply put, you are going from reading Enid Blyton’s Famous Five Goes to Finniston Farm to Leo Tolstoy’s War and Peace.

The requirements themselves remain as 12, so in essence, despite all the fluff at the beginning, the actual requirements are still intact. There’s quite a fair bit of items to look at, and here we provide a brief overview of it:

a) Customized implementation

So, we have this outcomes-based implementation of PCIv4. This is based on the purpose or the ‘spirit’ of the requirements and may not necessarily use the standards-defined controls to achieve it. So, for instance, the requirement to do quarterly internal scans – the objective is to identify vulnerabilities in a regular interval and to ensure that the organisation addresses this vulnerability. Instead of having an option for on-demand scanning, the organisation may opt to sign up for a continuous analysis and automated scanning that are available in cloud such as Google or AliCloud. So while the controls are different, it addresses the same objective.

It is noted that custom implementation should only be done by organisations with a mature risk management practice in place, as this requires more work for the organisation and the QSA to define tests of these controls.

On how this is implemented or samples of it, I am sure we will be seeing more examples as the standard starts maturing. Remember, v4.0 is still a baby, not even out of the maternity ward yet.

b) Multi-factor and Passwords

Multi factor is now needed for any access into the CDE. So, we call in Multi-Multi Factor – whereby, an MFA is required for remote users to get into the network, and from the non-cde network, to get into the CDE, it requires additional MFA. It would seem fairly straightforward, but companies now have to consider to implement a jump server in the CDE to act as a control aggregator to go to multiple systems in the CDE – or they could just deploy another MFA solution on the network .

Passwords are to be changed to 12 alphanumeric up from 7. There’s still a runway on this as it is only considered standard in 31 March 2025. A lot of things can happen from now till then and a lot of technology can change. We could be facing global climate crisis and end of the world, or world war 3 nuclear warfare, or an asteroid could hit earth, or the Rapture happens, you know, future stuff. But in case none of those things come to past, then yeah, make sure you move your passwords to 12 alphanumeric.

c) Group Accounts

8.2.2 gives a needed reprieve on this kerfuffle of having group accounts. In v3.2.1, this is disallowed, but v4.0 , it is allowed, based on the rule of common sense. Some systems do have group accounts for a purpose, or is unable to provide certain functionality to individual accounts. So while there is now more justifications etc needed, it’s no longer a hard no for group accounts.

d) Targeted risk analysis

Targeted risk analysis can now be done to determine the frequency of certain actions – such as password changes, POI device inspections, non-CDE log reviews, low vulnerabilities remediation, FIM review, frequency of training etc. Now while we want to believe that the PCI-SSC idea on having this is for organizations to change frequencies of controls to be MORE stringent (example to have the password changed every 30 days instead of 90 days), the reality is that most of us would stretch this requirement to make life a lot easier for us. I mean, what’s the point of having flexibility if you can’t make it as flexible (i.e as little work to be done) as possible, right?

e) Card data discovery (CDD)

Card Data Discovery Scans – CDD. There is finally some clarifications on Card Data scans to be done every 12 months and to clarify what we have already covered in our previous post in educating the QSA on how to interpret the particular CDD requirement. So yeah, kudos PCI-SSC for supporting us!

d) Misc – Anti Phishing and Full Disk Encryption

As mentioned previously, we now have references to Anti-Phishing requirements, which should have been there long before, to be honest.

We have clarifications which will have significant impact to some of our clients – the use (or abuse) of the full disk encryption requirement. V4.0 has basically blocked that way out for some of our customers utilising Bitlocker with TPM to get past Requirement 3. This is , to us, a fairly significant item of v4.0 which we will be dedicating a post later on it.

Well, so that’s it for the overview for now. We hope to get more articles out to do deeper dives into v4.0 but like I said, it’s still early days and there would be more clarifications ahead. Hopefully it will be more positive, and the experience of v4.0 will be less like that family outing with the cousin that should be thrown into a pit of vipers.

Contact us at pcidss@pkfmalaysia.com for any queries you have on PCI and we will get back to you immediately.

PCI-DSS 2022 and Version 4

pci-compliance

So we are now in 2022. PCI-DSS v4.0 is due to be out and one of the things we have been doing for the first two weeks of the year is to get over our holiday hangovers. That’s right. In our country (Malaysia), the slowest months are December, January and February. It’s like starting a car in the dead of winter. These 3 months are like the Amen Corner in Augusta for businesses. December hits like a ton of bricks due to the Christmas season; and then just when things start moving in January, it grinds to a halt for Chinese New Year, where the entire nation just flat out refuses to work. When we are back in the second week of Chinese New Year, we are once more in first gear climbing up the hill again of 2022.

So we did things a bit differently. We started the first two weeks with a series of training for clients and potential clients, to go through PCI-DSS v4.0 and create an awareness of what is there to expect.

The above is taken from the PCI website and immediately we see some interesting things here. Number one: PCI-DSS v3.2.1 only retires in 2024. This is interesting, because usually the transition period isn’t so long. It’s long now because – I don’t know, there may be an ongoing pandemic and such. So here we are Q1 2022, and our customers are asking when do we transition to v4.0?

Well, the answer would be: as soon as you can. But in theory, you can probably stick to v3.2.1 validation for 2022 and realistically move to v4.0 in 2023. In fact, for some of our clients whose PCI maintenance period follows the calendar year, they can even force 3.2.1 into their 2023 validation year.

As for the actual content in PCI v4, it’s still a well kept secret like the plot of Spiderman: No Way Home; but we have been reading a bit and also have joined last year’s PCI-DSS community meeting and learnt some interesting tid-bits of it.

No 1: Compensating Controls

The-get-out-of-jail-free card. Customers have been dangling this Compensating Controls card in front of our faces ever since the Mesopotamian times. When they can’t address a control – use compensating controls! When they cannot implement something due to budget – compensating controls! When they can’t make changes to an application because it was designed by a group of kindergarten kids and it would break the moment you touch it – Compensating Controls! When you don’t know what to say to your wife after a long night out at the pub with the mates and come back smelling like a keg of kerosene – Compensating Controls!

The problem with compensating controls is that they are a pain in the neck to implement and to document. And to justify. The compensating control worksheet, the justification documentation, the implementation of the control itself to be ‘above and beyond’ the scope of PCI-DSS etc. Everyone things this is a silver bullet only to find it the deepest rabbit hole you can ever fall into.

So, PCI v4 does away with compensating controls. Great.

And they introduce Customized Implementation.

A lot of people are saying this is a game changer.

Honestly? Until more information comes out, we only have this to go with:


Customized implementation considers the intent of the objective and allows entities to design their own security controls to meet it. Once an organization determines the security control for a given objective, it must provide full documentation to enable their Qualified Security Auditor (QSA) to make a final decision on the effectiveness of a control.

Cryptic PCI v4 DOCUMENTATION

Design their own security controls? Well, ok, isn’t this the same as compensating controls? I am thinking this just expands the interpretation to something a bit broader in which case the control may not even be a technical control. So instead of stating , ok, we can’t meet certain password controls due to the legacy application issue, and compensating controls were previously excessive logging and monitoring; isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc; are we stating now, a possible customized approach would be: instead of all these technical controls; we now have a customized security approach. Which includes isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc.

Until we see some examples of this, it may just be well that most companies will go along with the ‘normal’ approach; or adopt a wait and see approach and eke out the last remaining drop of v3.2.1. into 2024.

No 2: UP in the Clouds

Another item that has been long overdue? Cloud. It’s about time things get addressed and not just cloud, but how services and containers work as well. We have had auditors coming to our clients insisting on them doing testing, VA/PT on services from AWS, not recognizing there’s not even an IP address to start with. To be fair to the SSC, they do have a few Cloud Guidelines Supplementary documentation, which we actually find very useful especially in our projects on certifying cloud technologies. We can see this being incorporated more formally into v4.0 where the requirements will be designed around Cloud environment more organically than what we see right now (sort of force-fitting many of the traditional concepts like Network IDS, Patching etc into the cloud environment).

No 3: Not another MF-A!

I have a bad feeling about this.

MFA has been a constant pain for us. Firstly, where MFA is being implemented – not just on perimeter but now on every access to the CDE. At least it’s now still on admin accounts. We hear they plan to introduce for ALL users. We also hear the collective screams of the tormented from the nine hells of Dante. Secondly, a lot of customers are still depending on MFA via SMS. If PCI goes along the NIST route, we could see this being deprecated soon. Also, clarifications as well on whether client side certificate are acceptable as a ‘something you have’ factor would be most welcomed. We see different QSAs interpreting this so differently you’d think we’ve asked them to interpret some ancient Thuggee text. Multi-factor challenges are already there for us over the past years, with Bank Negara’s RMIT focus on ‘strong MFA’ for large financial institutions. A clear guidance also should be there on how to evaluate multi-factor that is dependent on a cloud provider; and whether common implementation like Google Authentication etc can still be considered as good enough for V4.0

No 4: Encrypting everything

We also hear now that the “Pocket Protector Trope” security may be implemented. Remember those movies we watch, where the hero gets shot in the chest and you think he dies but he reveals that the bullet is stopped by his pocket watch; his badge; a bible; or some other dang sentimental thing that was given to him like 40 scenes ago?

So in PCI, usually when data is traversing the internet or network, it states the transmission needs to be encrypted. It doesn’t technically state anything about encrypting the data package itself while in transmission. The data encryption almost exclusive occurs during data at rest. So in this case, they are doubling the protection: They are adding that pocket watch to catch the bullet; so if the transmission gets compromised, the data is still secured. The bullet doesn’t hit the hero!

No 5: Recovery and Continuity

Not so much as something coming, but more of what we’d like to see. One of the biggest criticism we see customers bemoaning at PCI (other than the cost and budget and the complexity and..ok, everything else) – is that PCI has little focus on business continuity and disaster recovery. It’s almost as if PCI is standing there saying, “OK, you have outage for a few days? Great, make sure your credit card information is safe.” It’s not really business focused, it’s more credit card confidentiality focus. What we would like to see is a little more focus on this area. Over the past 2 years, we have seen customers getting all sorts of attacks from cyberspace. Malware, ransomware, hacking, fraud, defacement — it’s like the world goes into a pandemic and everyone’s bored to bits at home and everyone is taking up hacking as a part time gig. Malware for instance – how prepared is a PCI compliant company against ransomware attack? Have they done their backups? Have they tested their systems to recover?

So, if you have any queries on PCIv4 for us, drop us an email at pcidss@pkfmalaysia.com and we will definitely get back to you. Have a great and safe year ahead for 2022!

« Older posts

© 2023 PKF AvantEdge

Up ↑