PKF AvantEdge

Page 3 of 40

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.

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

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑