Category: IT Compliance (Page 1 of 16)

Zero Trust for 2024

As we enter into the new year, lets start off with a topic that most cybersecurity denizens would have heard of and let’s clarify it a little.

Zero Trust.

It seems a good place as any, to start 2024 off with the pessimism that accompanied the end of last year – the spate of cybersecurity attacks in 2023 had given us a taste of what is to come – insurance company – check, social security – check, the app with our vaccination information – check. While breaking down the attacks is meant for another article, what we are approaching now for the coming year is not just more of the same, but much more and more advanced attacks are bound to happen.

While Zero Trust is simply a concept – one of many – to increase resistance to attacks or breach, it’s by no means a silver bullet. There is NO silver bullet to this. We are in a constant siege of information warfare and the constant need to balance the need for sharing and the need for protection. It is as they say; the safest place would be in a cave. But that’s now living, that’s surviving. If you need to go somewhere, you need to fly, you have information with the airlines. If you need to do banking, you have information with the banks. If you need to conduct your daily shopping online, you are entrusting these guys like Lazada et al the information that otherwise you may not likely provide.

So Zero Trust isn’t the fact that you conduct zero transaction, its basically a simple principle: Trust no one, Verify everything. Compare it to the more traditional “trust but verify” approach, which assumed that everything inside an organisation’s network should be trusted, even if we do have verifications of it. Here’s a breakdown of the concept, in hopefully simpler terms.

The Basic Premise: Imagine a company as a fortified castle. In the old days, once you were inside the castle walls, it was assumed you belonged there and could roam freely. At least this is based on the limited studies we have done by binge watching Game of Thrones. All historical facts of the middle ages can be verified through Game of Thrones, including the correct anatomy of a dragon.

Back to the analogy, what if an enemy disguised as a friend managed to get inside? They would potentially have access to everything. Zero Trust Architecture operates on the assumption that threats can exist both outside and inside the walls. Therefore, it verifies everyone’s identity and privileges, no matter where they are, before granting access to the castle’s resources. The 3 keys you can remember can be:

  1. Never Trust, Always Verify: Zero Trust means no implicit trust is granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Basically, we are saying, I don’t care where you are or who you are, you are not having access to this system until I can verify who you are.
  2. Least Privilege Access: Individuals or systems are given the minimum levels of access — or permissions — needed to perform their tasks. This limits the potential damage from incidents such as breaches or employee mistakes. We see this issue a lot, whereby a C level person insist on having access to everything even if he doesn’t necessarily know how to navigate a system without a mouse. When asked why, they say, well, because I am the boss. No. In Zero Trust, in fact, because you are the boss, you shouldn’t have access into a system that does not require your meddling. Get more sales and let the tech guys do their job!
  3. Micro-Segmentation: The network is broken into smaller zones to maintain separate access for separate parts of the network. If a hacker breaches one segment, they won’t have access to the entire network.

The steps you can follow to implement the concept of Zero Trust:

Identify Sensitive Data: Know where your critical data is stored and who has access to it. You can’t protect everything. Or at least not with the budget you are given, which for most IT groups, usually is slightly more than they allocate to upkeep the company’s cat. So data identification is a must-have. Find out what is the data that you most want to protect and spend your shoe-string budget to protect it!

Verify Identity Rigorously: Use multi-factor authentication (MFA) and identity verification for anyone trying to access resources, especially important resources like logging systems, firewalls, external webservers etc. This could mean something you know (password), something you have (a smartphone or token), or something you are (biometrics). It used to cost a mortgage to implement things like this but over the years, cheaper solutions which are just as good are now available.

Contextual Access: Access decisions should consider the context. For example, accessing sensitive data from a company laptop in the office might be okay, but trying to access the same data from a personal device in a coffee shop might not be. This may not be easy, because now with mobile devices, you are basically accessing top secret information via the same device that you watch the cat playing the piano. Its a nightmare for IT security – but again, this has to have discipline. If you honestly need to access the server from Starbucks , then implement key controls like MFA, VPN, layered security and from a locked-down system.

Inspect and Log Traffic: Continuously monitor and log traffic for suspicious activity. If something unusual is detected, access can be automatically restricted. SOAR and SIEM products have advanced considerably over the years and today we have many solutions that do not require you to sell a kidney to use. This is beneficial as small companies are usually targeted for attacks, especially if these smaller companies services larger companies.

At the end, it all comes down to what are the benefits to adopt this approach.

Enhanced Security: By verifying everything, Zero Trust minimizes the chances of unauthorised access, thereby enhancing overall security. Hopefully. Of course, we may still have those authorised but have malicious intent, which would be much harder to protect from.

Data Protection: Sensitive data is better protected when access is tightly controlled and monitored. This equates to less quarter given to threat players out there.

Adaptability: Zero Trust is not tied to any one technology or platform and can adapt to the changing IT environment and emerging threats.

On the downside, there are still some challenges we need to surmount:

Complexity: Implementing Zero Trust can be complex, requiring changes in technology and culture. It’s not a single product but a security strategy that might involve various tools and technologies. This is not just a technical challenge as well, but a process and cultural change that may take time to adapt to.

User Experience: If not implemented thoughtfully, Zero Trust can lead to a cumbersome user experience with repeated authentication requests and restricted access. This is a problem we see a lot, especially in finance and insurance – user experience is key – but efficiency and security are like oil and water. Eternal enemies. Vader and Skywalker. Lex and Supes. United and Liverpool. Pineapple and Pizza.

Continuous Monitoring: Zero Trust requires continuous monitoring and adjustment of security policies and systems, which can be resource-intensive. We’ve seen implementation of SIEM and SOAR products which are basically producing so many alerts and alarms that it makes no sense anymore. These all become noise and the effects of monitoring is diluted.

In summary, an era where cyber threats are increasingly sophisticated and insiders can pose as much of a threat as external attackers, Zero Trust Architecture offers a robust framework for protecting an organisation’s critical assets. It’s about making our security proactive rather than reactive and ensuring that the right people have the right access at the right times, and under the right conditions. It’s culturally difficult, especially in Malaysia, where I will have to admit, our innate trust of people and our sense of bringing up means we always almost would open the door for the guy behind us to walk in, especially if he is dressed like the boss. We hardly would turn around and ask, “Who are you?” because we are such nice people in this country.

But, adopt we must. For any organisation looking to bolster its cybersecurity posture, Zero Trust isn’t just an option; it’s becoming a necessity. In PKF we have several services and products promoting Zero Trust – contact us at avantedge@pkfmalaysia.com and find out more. Happy New Year!

Gearing Up: How New Cybersecurity Guidelines Accelerate the Automotive Industry Security

So here you are, with your new spanking SUV that is fully EV and fully automated, with the most state of the art systems inbuilt. You get into the car, switch everything on, put in your favourite tune and head off to work. Suddenly, out of nowhere, your speakers go bonkers and suddenly says in an ominous voice, “Now I got you…” and your steering decides to turn despite your best effort to right it and the accelerator depresses despite you removing your feet off the pedal and your brakes don’t work anymore. You watch helplessly as your car flies over the embankment 120 km an hour.

Homicide by the car. Open your pod bay doors, Hal.

This seems far removed from current reality, but it might not be as far as we think.

Cyberattacks are on the rise in the traditional automotive industry in recent years, as cars become more dependent on circuits and electronics as opposed to mechanics and gaskets.

Connectivity defines the modern vehicle. With some cars containing over 100 million lines of code and processing nearly 25GB of data per hour, computerization radically reimagines mobility – enabling telematics, infotainment and autonomous drive capabilities that were unthinkable barely a decade ago. This software-ized transformation, securing IT components against cyber risks grows ever-more vital. As showcased by researchers commandeering functions like braking and steering via consumer Wi-Fi or compromised infotainment apps, hackers now have pathways into safety-critical vehicle controls. Highly automated models promise even larger attack surfaces.

In the future, mechanics will be phased out by electronic engineers to fix cars. You would go to an electronic shop instead of a mechanic shop. Say goodbye to the toothy uncle with the towel around his shoulder shaking his leg in his greasy shirt.

Bearing this in mind, the Japanese automotive industry is making serious efforts to improve cybersecurity. The Japan Automobile Manufacturers Association (JAMA) and the Japan Auto Parts Industries Association (JAPIA) both formed cybersecurity working groups. These two collaborated in 2019 to develop the JAMA/JAPIA Cybersecurity Guidelines, and on March 31, 2022, a second version was released to help steer the industry toward a more cyber-resilient course. Spanning 156 requirements aligned to internationally recognized standards, the guidelines furnish a sector-specific blueprint for fortifying defenses.

Who Do the Guidelines Target?

Given deepening connectivity between various players, the guidelines take broad aim across the mobility ecosystem:

  • Automobile manufacturers
  • Major Tier 1 parts suppliers
  • Software and semiconductor vendors tightly integrated into products
  • Telecommunications carriers facilitating connectivity
  • Fleet operations centers managing vehicle data
  • Components manufacturers farther down supply tiers
  • Aftermarket service providers accessing internal buses
  • Dealership networks bridging manufacturers and consumers
  • Academic partners feeding talent pipelines

Essentially, any entity handling sensitive intellectual property or providing critical products/services supporting vehicle R&D, manufacturing, sales, maintenance or communications should adhere to the prescribed cyber controls. This is fairly normal, like other standards out there, sub-contractors usually take the hit, as these standards are pushed down from the top.

While the guidelines focus on securing corporate IT environments, they spotlight risks from increasing convergence of enterprise and industrial assets. As connected platforms, analytics and cloud infrastructures provide gateway for adversaries into production systems, shoring up corporate IT protection grows imperative.

Three-Year Roadmap for Enhancing Cybersecurity Posture

Given the significant dedication for properly implementing comprehensive cybersecurity management programs, requirements are divided into three priority tiers reflecting basic, intermediate and advanced measures. The purpose of this is to demonstrate the minimum necessary countermeasures that must be used regardless of company size. This division allows organizations to methodically elevate security stature over a three-year adoption roadmap:

Level 1 – Basic Security Hygiene (Mandatory):

The 35+ non-negotiable Level 1 controls target universals like access management, malware defenses, monitoring fundamentals, compliance auditing, encryption, and security training. These form basic cyber hygiene mandatory across all auto sector entities. These requirements are intended to build a chain of security and trust between companies and their business partners and are also applicable to small and medium-sized enterprises. Non automative industry might do well to also use some of these as baseline cybersecurity practices. It’s basically cybersecurity hygiene. And we all know Japan has the best hygiene in the world, right?

Level 2 – Best Practices (2 Years):

An additional 60+ intermediate requirements call out data protection expansions, enhanced monitoring/logging, vulnerability management, security testing and supply chain risk management practices. Deeper employee training and executive awareness campaigns also feature.

Firms handling sensitive IP or high transaction volumes are expected to adopt Level 1 and 2 guidelines covering both foundational and sector-specific heightened risk areas within two years.

Companies should implement these controls, especially if they meet one of the following conditions:

1. Companies handling external confidential information (technical, customer information, etc.) within the supply chain.

2. Companies with significant internal technology/information relevant to the automotive industry.

3. Companies with a reasonable size/share that could have a significant impact on the industry supply chain due to unexpected disruptions.

Level 3 – Advanced Protections (3 Years):

Finally, over 50 sophisticated measures comprise the advanced tier targeting state-of-the-art safeguards. Encryption ubiquity, advanced behavioral monitoring, automated validation testing, penetration assessments and further elevation of risk management programs defined here help drive the industry’s cybermaturity.

These practices showcase leadership, with Level 3 representing an ultimate target for manufacturers expected to benchmark sector-wide security.

Built-in Flexibility Accounts for Organization Size

The tiered model acknowledges the varying cybersecurity investment capabilities across the industry landscape. This allows smaller players an achievable Level 1 entry point before working toward the expanded Layer 2 and 3 guidelines on a timeline proportional to organizational size and risk.

Again, in comparison to standards like PCI-DSS that also adopts similar tiered approach for compliance, this makes sense, given the number of different entities affected by this standard.

Checklist Format Provides Clear Milestones for Growth

To ease adoption, requirements trace to numbered checkpoints within a detailed appendix. This enumerated format lets companies definitively benchmark postures against guidelines and methodically strengthen defenses while tracking progress.

Shared criteria similarly help suppliers demonstrate security improvements to automaker customers through consistent maturity evaluations, facilitating trust in the supply chain.

Guidance Tuned to Automotive Sector Risk Landscape

Along with staging requirements by attainability, guidelines tailor controls and concepts to risks distinct from other industries. While mapping extensively to internationally recognized standards like NIST and ISO27K, authors customized content to the sector’s specialized threats and priorities.

For example, Level 1 mandates continuous monitoring for unauthorized access or malware activity. This acknowledges the havoc potential of a breach within an interconnected web of automakers, parts suppliers and assembly lines. Different secure zones and security focuses blur the lines on whether if (or when) a breach occurs, whose problem is that, how do we track it?

The repeated emphasis on supply chain oversight, information exchange standards and third-party security likewise reflects the complex hand-offs and trust relationships fundamental to mobility ecosystem operations.

Build Cyber Resilience Across Fragmented Environments

As vehicles evolve into software-defined platforms, cyber principles growing from these Japanese guidelines can shape sector-wide baseline resilience. Automotive IT interconnectivity will only intensify, making comprehensive, unified cybersecurity strategy essential. The scenario of the killer SUV may still be well into the future, but everything starts somewhere and as the world move more into the electronic and artificial, so too our dependence on everyday technology that we take for granted.

Whether global manufacturer or tiny niche parts maker, each player shares responsibility for hardening the greater environment. Just as drivetrains integrate thousands of precision components into harmonized mechanical systems, robust digital defenses emerge from many entities working in synch.

Implementing defined building blocks now allows the industry to preemptively navigate obstacles that could imperil revolutionary mobility pursuits ahead. For those seeking secure footing in the auto sector’s cyber journey, this three-year roadmap paves a straight path forward. This isn’t just for Japanese companies, but for any company whether in Malaysia or other regions that does business with Japanese automakers. This is a clarion call to the industry that cybersecurity should be foremost in the board’s agenda. Contact us at avantedge@pkfmalaysia.com and we will immediately get back to you. With our Japanese auditor and implementation partners, we can assist you in any way you want in navigating this standard.

Unless of course, you are in your Killer Suv. In that case, we can’t navigate that. Good luck!

An Ode to the Invalid Certificate

Once upon a time, in a not-so-faraway land of PeaCeEye, merchants, credit card transactions, online payments, payment gateways, POS terminals all lived in harmony. In this land, all citizens carry a trust symbol, held together by validation documents, called the Citizen Badge. However, PeaCeEye is now facing an existential threat. A threat shrouded in the cloak of validation, a false symbol of security and trust – called the Certificate. But, dear reader, beware! For this tale of caution and deception, and the Certificate, much like the elusive unicorn, while tangible, carries a false value – nothing more than a fabrication. A figment of imagination, conjured up by the minds of its idle creators, the Qessays.

You see, in the kingdom of PeaCeEye, there exists a council – a council of wise men and women who determine the rules and regulations that govern this realm. This council, known as the Secret Sorceror Council (SSC), has decreed that only three sacred documents hold the key to validation for the Citizen Badge – the Attestation of Compliance (AoC), the Report on Compliance (RoC), and the Self-Assessment Questionnaires (SAQs). Yet, despite the council’s resolute stance on this matter, a mysterious fourth document continues to emerge from the shadows – the Certificate.

Ah, the Certificate, a work of art crafted by the Qessays. You see, these Qessays were charged by the council to uphold what is truthful and right, and to ensure that all Citizens of PeaCeEye are identifiable by their Citizen Badges – The AoC, Roc and/or the SAQs. However, over the years, some of these noble Qessays have turned to the darkside and the sinister art of producing corrupted documentation, called the 4th deception, or the Certificate as it is now known. These dark Qessays have mastered the art of illusion, conjuring certificates out of thin air to dazzle their customers. They’ve become modern-day alchemists, turning mere paper and ink into a symbol of validation, which, in reality, is as weightless as a feather and as useful as a chocolate teapot. Or a fork and spoon when eating Chapati. It’s a thing of beauty, destined to hang on the walls of businesses, gracing them with its shimmering falsehoods.

But why do these Qessays continue to spin their webs of deception, offering their customers a document that has no merit in the eyes of the SSC? Something that even invalid citizens to PeaCeEye can procure? To unravel this mystery, we must dive into the murky depths of human nature. For, you see, people are drawn to shiny, pretty things, much like moths to a flame. A certificate, with its elegant calligraphy and embossed seal, is a testament to the allure of appearance over substance. It is a tangible representation of validation, regardless of its actual worth.

Moreover, the Certificate serves as a placebo, a sugar pill of sorts, which instills in businesses a false sense of security. It is a talisman that they cling to, convincing themselves that they are protected from the malicious forces of the World beyond PeaCeEye – the World called Cyberattacks. And, in the process, they become blind to the fact that the true power of validation lies in the sacred trio of documents – the AoC, RoC, and SAQs.

Now, one might argue that those who peddle these invalid certificates are merely fulfilling a demand. After all, the customer is always right, and if they desire a shiny piece of paper to adorn their walls, who are we to deny them? But, as the saying goes, “With great power comes great responsibility.” And these Qessays, as the gatekeepers of the citizenship of PeaCeEye, must hold themselves to a higher standard.

By offering these overvalued and useless certificates-that even the SSC had themselves admonished and had announced to the citizens to not place any value to them- these certificates not only betray the trust of customers but also undermine the very foundation of Citizen Badge. They turn the realm of PeaCeEye into a farce, a stage where pretenders masquerade as protectors, and businesses are lulled into a false sense of security. There are even Qessays who are not even involved in the process of validating an SAQ being answered; luring their customers to portals with questionnaires answered by the citizen themselves and then conjuring these certificates that look as if it has been validated by the Qessays, but instead are just self aggrandizing papers that has been only self validated by the person answering their own questions! In other words, the person becomes their own judge and jury and are able to produce a Certificate that looks as if they have been properly validated by a third-party Qessays. Amazing art! An ostentatious object of grandeur and magnificence, yet with all the actual value of a discarded banana peel withering in the Sahara sun.

But, dear reader, do not despair, for there is hope. You see, the truth has a funny way of revealing itself, much like the sun breaking through the clouds after a storm. And, as the truth about the invalidity of these Certificates spreads, businesses will begin to see through the veil of deception, and the demand for these counterfeit documents will wane. Qessays who persist in peddling these worthless certificates will find themselves exposed, their credibility crumbling like a house of cards.

In the meantime, we must not sit idly by, complacent in the face of falsehoods. Instead, we must raise our voices and spread the word, educating businesses on the true path to Citizen validation. We must sing the praises of the AoC, RoC, and SAQs, enlightening those who have been led astray by the allure of the invalid certificate. For it is only through knowledge that we can pierce the veil of deception and lay the mythical beast of the Certificate to rest.

So, let us embark on this crusade together, wielding the sword of truth and the shield of knowledge. As we march forward on this noble journey, let us remember the wise words of the SSC: “Trust, but verify.” Let us tear down the great wall of this Certificate, brick by brick, and replace it with a fortress built on the solid foundation of the council’s sacred trio of documents. And as we watch the last remnants of the Certificate crumble to dust, we will know that we have triumphed over the forces of deception.

We bid farewell to this Certificate, and to welcome a new era of transparency, security, and trust. An era where the mythical beast of the Certificate is relegated to the annals of history, and where the true power of validation is embraced, in all its glorious, council-approved forms. May the sacred trio of documents – the AoC, RoC, and SAQs – guide us on our path to a brighter, more secure future, and may the Certificate forever remain a cautionary tale of the perils of deception and the triumph of truth.*

** The above is written obviously in satire and tongue-in-cheek with absolute no journalistic value nor based on any real world reimagination and solely based on our absolute frustration at the continuous dependence and insistence from acquirers or banks to have our customers produce them ‘certificates’. In addition, some clients even go through self-service portals provided by QSAs and answer SAQ questions on their own, at the end of this process of self answering, a certificate is produced. Granted, the certificates do come with disclaimers in small prints stating that the certificate is actually based on self assessment and even admits that it isn’t recognised by the council.

But in reality, who actually reads the fine print?

In the end, anyone having gone through these ‘compliance’ portals, answering affirmative to everything would be able to procure these certificates and remarkably, some acquirers even accept them as proof of third party audit (which they are clearly NOT). Again, we are not stating that QSAs providing this service is doing anything wrong. There is nothing essentially wrong with certificates on its own, or QSAs providing these certificates as a simple means to show a company has undergone PCI-DSS compliance. But where it becomes a gray area is when there is too much dependence placed on these certificates to the point where even the AoC is rejected and acquirers insist on every company showing them these certificates. In this case, QSAs who are willing to provide so called certificates to companies without having undergone any assessment and only answering questions from the SAQ based on their own knowledge or whim – unless the QSA is willing to go through each question of each customer and validate these through evidence submission and review (the process called audit); then these creation of self signed certificates should be stopped. It’s akin to a banking website issuing a self-signed SSL cert on their own website and tell everyone to trust it. Does this happen in the world of e-commerce? No, it’s absurd. Then why is it different in the world of compliance? Why is this practice still allowed to prosper? How do we stop this practice?

We have been advocating removing certificates for years now from the PCI-DSS landscape and to have a more consistent and acceptable way to show PCI validation. Unfortunately, unlike the satirical tale above, this still eludes us. Drop us an email at pcidss@pkfmalaysia.com if you have any ideas and comments to this!

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!

« Older posts

© 2024 PKF AvantEdge

Up ↑