PKF AvantEdge

Author: pkfavantedge (Page 4 of 37)

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.

Risk Assessments in ISO27005 part 1

August 18, 2022 / / 0 Comments

While most of our writings are in PCI-DSS and we hardly get a whiff of this phenomena called “Risk Assessment”, it’s a different story when it comes to ISO27001 or what we call ISMS or ISO27k. The 27k is a set of guidelines and standards, to which the ISO27001 is the certifiable standard – but there is plenty of cousins, sisters and brothers involved in the 27k family as well…like 73 of them! They are like rabbits! We are specifically looking, in this article at the venerable ISO27005 standard.

While the term risk assessment carries a little gravitas; especially when faced with stony faced board members after a significant breach – to most organisations, they would go – “Risk assessments? Aren’t those just a bunch of fancy words for ‘guessing what could go wrong’?” Well, yes and no. While risk assessments do involve a bit of crystal ball gazing, they’re a lot more structured and methodical, and there are plenty of methodology to go about it. And when it comes to structure and methodology, one that we constantly fall back on (as we are IT compliance practitioners) is this ISO27005.

Setting the Stage

Before we dive headfirst into the nitty-gritty of ISO27005, let’s set the stage a bit. Imagine you’re about to embark on a road trip from KL to Singapore. Oh wait, we don’t have a reason to go to Singapore since the currency is too strong now. Let’s head up to wonderful Penang. You’ve got your snacks, your playlist, and your destination all set. Luggage, hotel booked, sleeping pills for the kids – all set. But before you hit the road, you check the weather, the condition of your car, and maybe even the traffic situation. You check where is every stop where there is a toilet, since children has bladders the size of thimbles. In essence, as simple as it may sound, is a risk assessment in a nutshell. You’re identifying potential issues (risks) that could derail your trip (objective) and taking steps to mitigate them.

Risk Assessment: The ISO27005 Way

Now, let’s translate that to the business world. ISO27005 is like your road trip checklist, but for information security risks. It’s a standard that provides guidelines for information security risk management, or in simpler terms, it’s a roadmap for identifying, assessing, and managing risks to your information assets.

Step 1: Context Establishment

The first step in any risk assessment process is to establish the context. This is like deciding where you’re going on your road trip. In the ISO27005 world, this involves defining the scope and boundaries of your risk assessment. You need to identify what information assets you’re assessing, what the relevant threats and vulnerabilities are, and what the potential impacts could be.

Step 2: Risk Assessment

Once you’ve set the context, it’s time to assess the risks. This is where you identify potential events that could cause harm to your information assets, evaluate the risks associated with these events, and prioritize them based on their potential impact and likelihood.

Let’s say you’re running an online store. One of your information assets could be your customer database. A potential event could be a data breach, the impact could be loss of customer trust and potential legal penalties, and the likelihood could be high if you don’t have strong security measures in place.

Step 3: Risk Treatment

After assessing the risks, the next step is to decide how to treat them. This could involve accepting the risk (if it’s low), avoiding the risk (by not performing the activity that leads to the risk), transferring the risk (to another party), or mitigating the risk (by implementing controls).

In our online store example, you might decide to mitigate the risk of a data breach by implementing stronger security measures, such as encryption and two-factor authentication. Or simply outsource the payment to another PCI-DSS payment gateway thereby transferring part of the risk to them.

Step 4: Risk Acceptance

Once you’ve decided on a treatment, the next step is to accept the risk. This doesn’t mean you’re okay with the risk happening – it just means you’re aware of the risk and have a plan in place to deal with it. The risk after the treatment or controls are what we term as “Residual Risk”. Remember this when faced with stony-faced board members after a significant breach. Say that often.

Step 5: Risk Communication and Consultation

The final step in the ISO27005 process is to communicate and consult with stakeholders about the risk. This could involve informing employees about new security measures, consulting with experts about risk treatment options, or communicating with customers about potential risks.

The ISO27005 Steps

Now, you might be thinking, “That’s all well and good, but where does ISO27005 fit into all this?” Well, think of ISO27005 as the Ten Steps of risk assessments. Except instead of ten, you have a whole lot more. But don’t let that put you off – underneath the jargon, there’s a wealth of wisdom to be found.

Step 1: Identify your Risk!

ISO27005 is big on risk identification. It provides a structured approach to identifying risks, including a comprehensive list of potential threats and vulnerabilities. It’s like a treasure map, but instead of leading to buried gold, it leads to potential risks. Which obviously does not sound as sexy, but you know, risks are….nice, I guess?

Step 2: Analyse your Risk!

Once you’ve identified the risks, ISO27005 guides you through the process of analysing them. This involves evaluating the potential consequences and likelihood of each risk, and assigning a risk level based on these factors. It’s like a crystal ball, helping you see into the future of what could go wrong.

Step 3: Evaluate your Risk!

After analyzing the risks, ISO27005 helps you evaluate them. This involves comparing the risk levels against your risk criteria to determine which risks need to be treated. It’s like a sorting hat, but for risks. This is by far, one of the trickiest to manage and this is where a good risk manager gets paid to do the work. Because in a risk workshop, every stakeholder or process owner will say their risks are highest. Yes, the facilities guy is going to state that the HVAC malfunction will cause the end of the world. Yes, the IT head is going to say that the next breach due to a lack of WAF and SOAR components will bring upon the extermination of the multiverse. And even the guy in charge of the cleaning lady is going to state that if his risk is not looked into, the cleaning lady will likely be an MI6 operative who is sent to assassinate the entire board of directors. So risk manager, do your job!

Step 4: Treat Your Risk!

When it comes to risk treatment, ISO27005 offers a range of options. You can avoid the risk, take on the risk and its potential consequences, share the risk with another party, or implement controls to mitigate the risk. It’s like a choose-your-own-adventure book, but with less adventure and more risk mitigation. It is as bland as it sounds, but hey, do what you gotta do. How many times we have seen risk assessments carried out without any treatment plan? More than we can count. A lot of organisations simply think that identifying risks are good enough, and then accepts every single risk there is. So their risk treatment plan is ACCEPT everything.

Step 5: Monitor and Review Your Risk!

Finally, ISO27005 emphasizes the importance of ongoing risk monitoring and review. This involves keeping an eye on your risks, reviewing your risk assessments, and updating your risk treatments as necessary. It’s like a car’s rear-view mirror, helping you keep an eye on what’s behind you while you focus on the road ahead. A dashboard of risk will help on this, or for the more primitive, a slew of excel sheets can also be used. Whichever way, it needs to be communicated to the risk committee and be able to be updated and reviewed regularly.

Bringing It All Together

So, there you have it – an introduction into the world of ISO27005 risk assessments. It might seem a bit daunting at first, but once you get the hang of it, it’s a powerful tool for managing your information security risks.

Just remember – risk assessments aren’t a one-and-done deal. They’re an ongoing process that needs to be revisited regularly. So, keep your ISO27005 roadmap handy, and don’t be afraid to take a detour or two along the way.

And remember, if you ever feel lost in the wilderness of risk assessments, don’t hesitate to reach out for help. Whether it’s a question about ISO27005, a query about risk treatment options, or ISO in general, drop us a note at avantedge@pkfmalaysia.com and we’ll get back to you.

In the next article, we’ll take a closer look at some of the specific controls recommended by ISO27005, templates that may help you get started, and how they can help you mitigate your information security risks. Until then, happy risk assessing!

Breakdown of BNM RMIT 2023 Table of Contents Part 1

June 28, 2022 / / 0 Comments

TABLE OF CONTENTS
1 Introduction………………………………………………………………………………………….. 3
2 Applicability …………………………………………………………………………………………. 3
3 Legal provision …………………………………………………………………………………….. 3
4 Effective date ……………………………………………………………………………………….. 4
5 Interpretation ……………………………………………………………………………………….. 4
6 Related legal instruments and policy documents……………………………………. 6
7 Policy documents and circulars superseded ………………………………………….. 6
PART B POLICY REQUIREMENTS……………………………………………………………………… 8
8 Governance………………………………………………………………………………………….. 8
9 Technology Risk Management …………………………………………………………….. 10
10 Technology Operations Management …………………………………………………… 11
11 Cybersecurity Management …………………………………………………………………. 25
12 Technology Audit ……………………………………………………………………………….. 31
13 Internal Awareness and Training………………………………………………………….. 31
PART C REGULATORY PROCESS …………………………………………………………………… 32
14 Notification for Technology-Related Applications …………………………………. 32
15 Consultation and Notification related to Cloud Services………………………… 34
16 Assessment and Gap Analysis…………………………………………………………….. 35
APPENDICES ………………………………………………………………………………………………..36
Appendix 1 Storage and Transportation of Sensitive Data in Removable Media………. 36
Appendix 2 Control Measures on Self-service Terminals (SST) …………………………. 37
Appendix 3 Control Measures on Internet Banking …………………………………………. 40
Appendix 4 Control Measures on Mobile Application and Devices………………………. 41
Appendix 5 Control Measures on Cybersecurity …………………………………………….. 42
Appendix 6 Positive List for Enhancements to Electronic Banking, Internet
Insurance and Internet Takaful Services ……………………………………….. 43
Appendix 7 Risk Assessment Report…………………………………………………………… 47
Appendix 8 Format of Confirmation………………………………………………………………….. 49
Appendix 9 Supervisory Expectations on External Party Assurance ……………………. 50
Appendix 10 Key Risks and Control Measures for Cloud Services …………………….…52

Technical Session: Clearing NTFS Dirty Bit

May 17, 2022 / / 0 Comments

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

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

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

It demonstrated a few symptoms:

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

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

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

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

Microsoft being cryptic and mysterious

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

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

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

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

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

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

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

The Dirty Bit

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

From Microsoft definition

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

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

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

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

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

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

There’s an easier way.

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

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

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

Just identify which is your USB drive.

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

ntfsfix -d /dev/sda1

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

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

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

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

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

Have a good week dealing with human beings!

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 ↑