PKF AvantEdge

Category: IT Compliance (Page 2 of 17)

Introduction to ISO27001 (Information Security Management System)

January 16, 2023 / / 2 Comments

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

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!

ISO27001 Risk Assessment: Threats vs Vulnerabilities

November 23, 2022 / / 0 Comments

Some of the building blocks in a risk assessment is the identification of threats and vulnerabilities. A lot of times, many people do get mixed up between these two. In the context of ISO27005, a risk is typically defined as the potential that a given threat will exploit the vulnerabilities of an asset or group of assets, causing harm to the organisation. So, understanding both threats and vulnerabilities is crucial to effective risk management.

The above table provides a typical understanding of the difference between these two.

Now, let us provide a few examples of threats and vulnerabilities that you may find useful when you are deriving these for your risk assessment.

a) Database Threats and Vulnerabilities

b) Servers Threats and Vulnerabilities

c) Physical Environment Threats and Vulnerabilities

d) Documentation Threats and Vulnerabilities

e) Application Threats and Vulnerabilities

f) HR (Employee) Threats and Vulnerabilities

The above are samples and examples. There could be many many more different threats, categories and vulnerabilities that are identified in the context of your organisation. If you need any assistance, please let us know and drop us a note at avantedge@pkfmalaysia.com.

Risk Assessments in ISO27005 part 2

September 21, 2022 / / 0 Comments

In part 2 of our dissection of the ISO27005 risk assessment we will have a look at some controls recommended by ISO27005.

Setting the Stage

As usual, in this article series, we’re going to try to do one of our bad anologies to pretend that this isn’t a boring but necessary subject. Imagine you’re a chef preparing a gourmet meal in Nobu Kuala Lumpur. You’ve got your recipe (the ISO27005 standard), your ingredients (your information assets), and your kitchen (your organization). Now, you need to follow the recipe (which is the standard) to turn those ingredients (assets) into a delicious meal (your eventual certification and promotion). That’s where controls come in. They’re the steps you take to protect your information assets and manage your risks. Essentially, why ISO27005 is so attractive to many IT operator is that it is an asset based risk assessment. Let’s run with this chef analogy for this whole article and let’s see if we get hungry by the end of it.

The ISO27005 Control Menu

Now, ISO27005 doesn’t just give you a single recipe to follow. Oh no, it gives you a whole buffet of controls to choose from. It’s like walking into a gourmet restaurant and being handed a menu the size of a phone book. But don’t worry, we’re here to help you navigate this control buffet and pick the right dishes for your organization.

Appetizers: Preventive Controls

Let’s start with the appetizers – preventive controls. These are the controls you put in place to prevent a risk from occurring in the first place. It’s like washing your hands before you start cooking to prevent foodborne illnesses. Wearing a mask so you won’t get infected and so on.

For example, ISO27005 recommends implementing access controls to prevent unauthorized access to your information assets. This could involve things like user authentication (passwords, biometrics, etc.), access restrictions (who can access what), and user account management (creating, updating, and deleting user accounts).

Main Course: Detective Controls

Next up, we have the main course – detective controls. These are the controls you put in place to detect when a risk has occurred. It’s like having a smoke detector in your kitchen to alert you when your gourmet meal has turned into a gourmet disaster.

For instance, ISO27005 recommends implementing monitoring and logging controls to detect security incidents. This could involve things like network monitoring (keeping an eye on your network traffic), log management (collecting and analyzing log data), and intrusion detection systems (detecting unauthorized access attempts). A healthy SOC for instance, goes a long way in detecting issues when or before they occur, which is crucial, especially when events and incidents can happen so quickly. One moment you are settling down for your cup of coffee and the next you are neck deep in phone calls and yelling executives.

Dessert: Corrective Controls

Finally, we have the dessert – corrective controls. These are the controls you put in place to correct a risk that has occurred. It’s like having a fire extinguisher in your kitchen to put out a fire.

For example, ISO27005 recommends implementing incident response controls to respond to security incidents. This could involve things like incident response planning (having a plan in place for responding to incidents), incident response training (training your staff to respond to incidents), and incident recovery (recovering from an incident).

The Anatomy of a Risk Report

That being said, after everything is done and identified and analysed, one still needs to get down to writing the risk report. It doesn’t actually have to be a traditional report, whereby a pdf document, with standard margins, signoffs and such. While this may be the case for many; some organisations are already migrating to system based risk reviews with live dashboards or risks and organisational wide data analytics. With technology growing, there are many tools out there designed to manage risk for you and calculate the ever growing number of vulnerabilities introduced daily. However, if you do find yourself not having these dashboards handy and you need to provide your auditor with something resembling a risk report, here are some guidelines:

The Anatomy of a Risk Report

A risk report isn’t just a list of risks and controls. We have been chucked some pretty cryptic excel sheets that makes as much sense to us as Sanskrit pointing out the Sankara stones locations. As auditors, most of these excel sheets or five page documents may not be enough to pass the litmus test of a risk report. Here’s what a typical risk report might include:

  1. Executive Summary: This is a high-level overview of your risk assessment. It’s like the blurb on the back of a mystery novel, giving the reader a taste of what’s to come. Some throw in graphs or charts here – you never go wrong with a little bit of pictures.
  2. Risk Assessment Methodology: This is a detailed description of how you conducted your risk assessment. This is critical because the auditor will review your risk report based on your risk methodology. If these two does not sync – for instance you have a complex risk calculations in the methodology but in the report, you assess risk by sticking two fingers in your mouth and then holding it up against the cool air … well, that’s a recipe of the famous NC – non compliant.
  3. Risk Analysis: This is where you present your findings. It might be in the form of table, taken from your risk worksheet or excel, or in an asset by asset review; or category by category review. Which ever way , it should be fairly readable, because the audience for this report includes non technical people. So go easy on the jargons.
  4. Risk Treatment Plan: This is your plan of action for dealing with the risks. You should include a list of recommended controls, their expected effectiveness, and their implementation details. This is important. The plan should not just be: OK, we have WAF, that’s cool. And many people get mixed up with the risk treatment plan and the current controls in place. It needs to be clear, whether in the plan, these controls will be implemented, what timeline and by who.
  5. Conclusion and Recommendations: This is where you wrap up your report and make your recommendations. It’s like the detective’s closing argument, convincing the chief that they’ve got the right culprit.

A Sample Risk Analysis, Risk Treatment Plan and Risk Register

Now, let’s take a look at a sample risk analysis and risk treatment plan. Let’s say you’re running an online store, and one of your identified risks is a data breach.

Risk Analysis

  • Risk: Data breach
  • Impact: High (loss of customer trust, potential legal penalties)
  • Likelihood: High (due to lack of strong security measures)
  • Risk Level: High

Risk Treatment Plan

  • Control: Implement stronger security measures, such as encryption and two-factor authentication
  • Expected Effectiveness: High (these measures are proven to reduce the risk of data breaches)
  • Implementation Details: Purchase and install an encryption solution, implement two-factor authentication for all user accounts
  • PIC: Homer Simpson from the Nuclear control room
  • Time Frame: by end of Q4 2022
  • Residual Risk after treatment: 2.4

Risk Register

A typical risk register might include:

  • Risk ID: A unique identifier for each risk (optional for reference)
  • Risk Description: A brief description of the risk.
  • Threats: Threats are external, things that exist that may impact that asset
  • Vulnerabilities: Vulnerabilities are internal, the yin to the Threats’ yang. These are issues that exist within the asset itself.
  • Risk Likelihood: The likelihood of the risk occurring.
  • Risk Impact: The potential impact of the risk.
  • Risk Level/Rating: The overall risk level, based on the impact and likelihood.
  • Control ID: A unique identifier for each control (optional for reference)
  • Control Description: A brief description of the control currently existing
  • Risk Treatment: Implementation of controls to mitigate the risk
  • Risk Monitoring: The expected effectiveness of the control and risk being monitored, or the residual risk remaining

All the above can be monitored within a simple excel sheet, using basic columns and rows. Again, we are not expecting a report written by Leo Tolstoy with a smashing 500 pages to go through, with illustrations and exposition into the answer to the meaning of life, universe and everything. We need something concise, and something that we can go through and something that is implementable in the context of that organisation. That’s it.

If you have futher need for assistance in risk assessments based on ISO27005, drop us a note at avantedge@pkfmalaysia.com and we will get back to you. Happy assessing!

P/S – it’s 42. As in the meaning of life, universe and everything.

Let’s Talk v4: Overview

April 15, 2022 / / 0 Comments

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.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑