Tag: IT security (Page 1 of 2)

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.

Do or Do Not – ASV for SAQ A

pci-compliance

I would have thought this debate died out with the extinction of dinosaurs, but apparently, we are still at this subject in 2021. Still. Going. On.

So in the past weeks, there were some debate between us and some consultants as to whether the SAQ A requires an ASV scan or not. Our position was No. Their position was yes. So let’s look at it.

Now, keep in mind, we aren’t talking about best practice. We are talking about PCI-DSS v3.2.1 and what it says about ASV scans being mandatory for SAQ A. That’s it. That’s the statement. Now, debate.

There is actually no debate. This isn’t some sort of grey area, hard to explain, obscure rule in Sanskrit and written on the Sankara stones. This is just: Look at SAQ A, search for ASV, don’t find it. Thank you.

The ASV requirement is present in item 11.2.2 of PCI-DSS.

SAQ A does not have it.

So why do consultants still insist people do ASV scans for SAQ A?

There could be a lot of reasons, ranging from ‘guideline’, ‘best practice’ and so on. No doubt, having a scan (which isn’t expensive in any case) would be the least effort of security done by the merchant if they are hosting an e-commerce website that is redirecting customers to their payment processor once the “Click here to pay” is clicked. I mean, even if it has nothing to do with PCI, it may seem like common sense to have at least a scan done on your site to ensure it passes the very minimal requirement of security. So do we advocate an ASV scan to be done on any e-commerce site that deals with payment options (not necessarily payment data)? Yes, we do. There are many ways a site may get compromise. A coding error may allow data to be siphoned off, or passwords may be compromised. A re-direct may be vulnerable to man in the middle attacks; or even a total redirect to another page altogether where payment data is inadvertently entered. While the e-commerce site may be outsourcing the payment part to a processor, it still has the job of redirecting traffic to it.

Think of it as an usher (not the singer, but the job); where you enter into a dark auditorium, let’s say Royal Albert Hall to watch Ed Sheeran – and the usher takes you through this row of lights to what is supposedly your seat which you paid RM10,000 for.

When the lights come on, you find yourself in nice cosy room and in front of you someone who seemed to resemble Ed Sheeran but slightly off. His hair isn’t ginger and he isn’t as chubby as you see that guy on TV and he speaks with a slight Indian accent. And isn’t the Royal Albert Hall a HALL? Why are you in this room that resembles a glorified grandmother’s living room? You find out later that the usher had led you through the wrong Hall into a neighboring pub attached to the side of the hall and you are listening to the wonky music of Eddy Shiran.

The point is, the usher is pretty important in leading people to their seats. So as a redirect, even though you aren’t the main draw, you could end up leading your customers to Eddy Shiran instead.

But back to the main debate, whether it is required for SAQ A customers to go through ASV? No, it’s not.

However, there is always a but in everything. There are exceptions.

Some acquirers make it a point to state that they still require an ASV report even if merchants are going through SAQ A. That’s completely fine because the guidelines from Visa/Mastercard are just guidelines. At the end, the acquirer or payment brands may make individual decisions based on merchants, so it’s not written in stone. However, if there are no such requirement, we’re left to interpret the SAQ as it is, and it doesn’t state anything there.

Some may point out within the SAQ A under part 3a, there is a statement

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

Triumphantly being pointed out as proof of ASv requirement

Take note however, that above, under Part 3a, the instructions do state:

Signatory(s) confirms:
(Check all that apply)

the realisation that asv is still not needed for Saq A (or B)

Even under the title “PCI DSS Self-Assessment Completion Steps” of the SAQ:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand, or other requester.

It does seem to be grappling at straws if this sentence was used to justify the requirement for PCI-DSS. “Such as” generally denotes an example, which may or may not exist or is required.

In previous requirements of merchants from Visa, there used to be statements describing merchant levels such as

 * Merchant levels are based on Visa USA definitions
** The PCI DSS requires that all merchants perform external network scanning to achieve compliance. Acquirers may require submission of scan reports and/or questionnaires by level 4 merchants

And perhaps there is where the myth was perpetuated from. In recent times Visa has updated its site (https://www.visa.com.my/support/small-business/security-compliance.html) to reflect a better understanding, stating:

“Conduct a quarterly network scan by an Approved Scan Vendor (“ASV”) (if applicable)”

In conclusion, SAQ A and B do not require ASV scans. If it’s required by the acquirer then so be it. If it’s supposed to be done out of best practice requirements, so be it. But you don’t want to hear an ASV/QSA telling you that you need to do something that is above and beyond your PCI requirement without them pointing to something in the standards that states so.

Finally – for SAQ B, which usually applies to POS terminals dialing up to the bank for authorisation; we’ve even seen some consultants requiring the merchant’s website to undergo ASV, which has nothing to do with their POS Terminals. Why ASV the website? Don’t know. So the merchants go about scanning their website that hasn’t been updated since 2012 and wonder, what sort of nonsensical requirement is this from PCI-DSS that needs them to pay just to scan something that is built by an 18 year old intern who had left the company 10 years ago? You don’t need to. So don’t do it.

Anyway, that’s it for now. Let us know your thoughts or questions and send to us at pcidss@pkfmalaysia.com and we will get back to you ASAP. Now, back to listening to our Spotify for Eddy Shiran!

The Biggest (Real) Myths of PCI-DSS: Part 1

pci-compliance

Sometime back, PCI-DSS published the Top 10 Myths of PCI-DSS which we debunked in our series of Myths of the Top 10 Myths here. In this article, we are going to jump into the real actual Myths of PCI-DSS and we will explain it as we go along. We are not going to touch on the original myths published by PCI Council, but this is really very much based on our experience in PCI-DSS for more than a decade here in Malaysia, and what we often hear companies going about.

Often this misinformation is because the client facing PCI-DSS finds it hard to dissect all the information needed for the standard. Unlike standards like ISO27001, PCI-DSS is like a journey with different routes to the same destination: PCI Compliance. There are 3 separate destination for PCI – Level 1 Certified with QSA, Level 2 Self Assessment with QSA/ISA signoff, and Level 2 Self Assessment with Self Sign off (no QSA, no ISA signoff). Of course if you are a merchant, then you have level 3 and level 4, but those are the same as the third iteration where you signoff the SAQ on your own without involvement of QSA/ISA.

But while the destination itself can be clarified, the whole process to obtain PCI can be convoluted. Some clients are told by their banks, that because they do not store credit card, they are considered SAQ level 2. Or some are told because they have a website, they must do ASV scans. Or some are told that QSAs must be involved in everything. Some are even told, that local QSAs must be hired, and not any other QSAs. Some are of the opinion that PCI is a license they need to purchase, or a training they need to do. And some are of the opinion that the ASV scan will make them PCI compliant.

Hence, it’s easy with all the above misinformation and more, that customers get frustrated with the expectations of PCI. When they hear a level 1 certification may set them back 15 – 20K USD or more, or that it would take them 6 months or so, they balk at it. It’s funny because often I would start my sales pitch by saying: “At the end of our conversation, it would be goal to try to get you to avoid getting services from us if possible.” Because it’s essentially true. Our job at the beginning isn’t to peddle services or consulting or audit that our clients may not need. Our goal is to provide them with enough information of PCI-DSS so they can make informed decisions. And yes, even if those informed decisions would be that they can avoid PCI, or do their own SAQ without any consultation or ASV scans or certification, or get exemption from their banks/customers or anything else that can lower their requirements for PCI-DSS. And yes, many people who have called us actually just pay us by saying ‘thank you’ and we never hear from them again. Because as advisors, it’s better we start doing the right thing at the very beginning instead of focusing to sell services that customers do not need. This philosophy has been adopted from the start of our company – which is one of the reasons why I failed so miserably in my previous corporate role as regional head of professional service sales. Or also why I was once told off by a potential business partner that I was a poor sales person and that he preferred to work with an organisation with someone better handling sales. Ah well.

So here are some of the top REAL myths of PCI-DSS that needs to be debunked, burned, destroyed and thrown out of the window for the garbage that it is.

1) All PCI-DSS Projects Require ASV Scans

2) ASV scans makes you PCI compliant

3) All PCI-DSS requires (local) QSA

4) All PCI projects are the same (One Certificate to Rule them All)

5) All PCI-DSS services must be outsourced

6) All service providers MUST be certified to do implementation services

7) PCI scope and application of controls can be determined by the customer

8) PCI-DSS gets easier and cheaper every year

9) A company is considered PCI compliant even after the expiry of certification, due to 90 days grace period from the council

10) If the company is an ISMS certified company, they have already complied to 90% of PCI-DSS

So there is quite a bit of stuff – some may be half truths and other are utter nonsense – we need to uncover, likely will need to break this article up into two parts. Let’s jump into it.

Real Myth 1: All PCI-DSS projects require ASV scans

This myth is often peddled by those who are selling ASV scans as part of their service. Don’t get me wrong, we also do ASV scans through our ASV partners for sure, but you can’t go around town telling people that all PCI requires ASV scans when it doesn’t! Read SAQ A. Read SAQ B. You don’t see ASV being mentioned anywhere in the SAQ except for this portion in Part 3a:

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

And under “PCI DSS Self-Assessment Completion Steps”:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand or other requester.

The thing is, if you go through each control under the SAQ, the ASV control 11.2.2 isn’t mentioned, so therefore it’s not required. It’s highly frustrating to us, especially when travel agencies for instance who are just doing EDC terminal business (SAQ B) that connects directly via cellular or phone line to acquirer coming to us and asking us to quote for an ASV scan for their website. We tell them, you don’t need to do ASV scan for your website unless its in scope. You can force us to sell to you, but it’s against our moral code to sell you stuff you don’t need. We take a look at it, find its a simple site with only information and they tell us, “Well, their PCI advisor previously told them to scan their website.” No. You don’t need to. Don’t waste your money, and don’t do it unless you have a website in scope or you are doing an SAQ requiring ASV scan or you consciously make a decision to do it out of best practices and security requirement – NOT as a mandatory PCI-DSS activity.

So, please, take a look. Even SAQ A, usually adopted by e-commerce sites that redirects to a payment gateway for card input – where there is likely a website, the myth is that ASV needs to be done. Read SAQ A. Again, no requirement for ASV scan. You can still do an external scan for security purpose, but strictly for compliance? No. Not needed, unless requested specifically by the acquirer.

And yes, we do have ASV scans as part of our service. But that shouldn’t make us charlatans peddling services to customers when it isn’t mandatory. If the client still wants to pick it up, ok, fine – but don’t say it’s compulsory when it’s not!

Real Myth 2: ASV scans makes you PCI compliant

We have flogged this one half to death in our earlier article here: ASV scans=/ PCI Compliance

I won’t repeat what we have said there but by far, this is a myth that gets peddled a lot. One, sadly, is because the propagation of this nonsense seems to be acceptable by banks. I hear: “Oh, no problem, the bank says all we need to do is to run an ASV scan on our website.” I interject: “Wait sir, you aren’t doing that e-commerce business. You are doing a call center with virtual terminal payments..” <Click> <Dial tone due to hang up>

So there you have it : companies and merchants that have no business doing ASV scans , but using ASV scans as a means to ascertain PCI compliance. We get this even weirder ones when we are trying to obtain an AoC from one of our client’s service providers and they pass us their passed ASV scan report. We ask what the heck that is and they go – that’s our PCI compliance, so please shut up and stop bothering us. And it’s so difficult to go out and explain to them that whoever told them that, is wrong, and they have to go through the actual PCI compliance, which their wonderful ASV scan may (or may not) be part of that overall PCI Compliance.

Real Myth 3: The Auditor (QSA) must be Local

This is one of the strangest myths ever.

We get calls from customers going, “Is your QSA a Malaysian?” And I go, “No, we work with our partner QSA, from India, US or Singapore”. And they go, “Well we want a Malaysian QSA.” And I ask, “Why?”, and most of them are not able to ascertain why they need the QSA to be local, except that it may be a requirement checkbox in their document or policy.

Ok, I can’t argue with your policy, if you have nationalist preferences to your auditors for whatever reason. But it’s not logical for companies to have that requirement, that only local QSAs must be used. PCI-DSS never stated that. In fact, its preferable to have a QSA with regional/global experience as opposed to a local QSA. If PCI-DSS had this requirement for local QSAs to carry out audits, how can QSAs then say they have ‘regional experience’? You see the conundrum? You want an experienced QSA company, yet you want a QSA that is only local. If every enterprise in the world thinks that way, how would QSAs have regional/global experience? By that argument, then all QSAs would be local to that country – not just Malaysia – but each country would only have QSAs auditing in that country and nowhere else. And immediately you can see the fallacy and illogical argument attached to this myth. But this myth still prevails, for whatever reason (we sort of know the reason actually).

PCI-DSS requires a lot of experience. The last thing we need is a QSA with only a handful of experience and no operational idea of how to run things or recommend solutions and just rely on a checkbox and some cute marketing gimmicks. I’ve seen plenty of good auditors overseas, a whole lot better than the local ones I come across and vice versa. “Local QSA requirement?” It could be peddled by local auditors attempting to block off better equipped, or even cheaper auditors from overseas (better or worse) and really narrowing the options for their clients, who would be hemmed in by such requirement, thinking its a PCI-DSS requirement. It’s not.

If you mean by local support- that they can respond faster since they are local, then, yes, there is some sense in that. If you mean they are cheaper compared to a guy in US, then yes, but let that be a commercial decision and not a technical one. Sometimes even overseas (good) QSAs can be cheaper. Local support I agree, 100%. Nothing is more frustrating than sending a message to someone and them taking 24 hours to reply due to them being in another timezone. Local presence, local support – yes. But they technically don’t need to be a QSA. They could be consultants and there is a very good case in that. We noted it here in this article “PCI-DSS – So Why Aren’t We QSA?”. We consciously made a decision NOT to be a local QSA a few years ago to avoid possible conflict and to support our clients a lot easier and not to be bogged down by auditor responsibilities in PCI.
QSAs are a busy and itinerant lot. Aside from handling other audits, writing reports, they also need to be careful of overstepping their independent role by advising and implementing for their clients and then auditing this same control they devised.

There is really, if you come down to it, no perceivable value in saying having a “local QSA” is better or not. Having local support throughout the PCI-DSS compliance is important – and whoever is supporting should have at least the same or more knowledge than the QSA.

In some QSA Companies, they have a set up to differentiate the auditor and the consultant. Whereby the consultant is different from the auditor to ensure there is more independence. We have the same set up – PKF is the consulting arm and we deal mainly with implementation, testing and assistance of our client to get past PCI. The QSA is well, the QSA in this case, and they can do their audit without being too involved in the implementation. We know as much (and if not more, sometimes) than the QSA due to our operational experiences, and this puts us in a better position – conflict free- to get our clients certified.

So, no, in this opinion, there is no real value or even PCI requirement in having a local QSA, because that generally does not make sense and is counter-intuitive to peg a customer to only select local, less experienced auditors. Most QSAs can (and should) be able to do regional or even inter-regional work because a QSA Company, by its very nature is a regional or global company anyway (QSA pays to be auditors based on regions, and not country specific). Again, while our opinion may be biased because of the strategic decision we made years ago, we made that decision with all these considerations in mind.

Select the best QSA option based on experience, pricing and quality, not because they are local or non-local.

Real Myth 4: All PCI projects are the same (One Certificate to Rule them All)

A customer once said that we didn’t have much value and all we did was to forward their emails to the QSA for validation (not true). He said he had his team done PCI across other countries and we were just making it more complicated than necessary since they have already been experienced, implying that we hoodwinked them.

It’s very difficult to talk to people who are in this position because you can see from the onset, they do not support outsourcing advisory and consulting and they have a personal vendetta against this profession. So we don’t need to speak reason to them. In this case, we decided to pull out of the deal for advisory and all other works of implementation except for the ASV scans.

Two years from starting their PCI project on their own, and they are still in the wilderness. We ended up supporting them in any case, and perhaps their thought process had somewhat soften now because we are now finally seeing the end of the project, with us (ironically) leading them to it.

And their ‘experience’ from other PCI compliance projects? Different experience. Some were basically e-commerce SAQ A, A-EP type, some were their retail arm SAQ B or B-IP. But what they were doing in Malaysia was the outsourcing, call center and BPO – all of which involves credit card storage, processing and transmission.

Not all PCI-DSS projects are created equal.

Another company employed the ‘One Certificate to Rule Them All’ philosophy. They were providing warehouse storage facility to one of our clients, essentially storing physical copies of forms containing credit card information. So, this is a service provider, providing storage that needs to be assessed for their physical security.

They immediately told us they are already PCI compliant and they will send us the certificate. We insisted on AoC but they obliged us with their ‘certificate’ anyway, emblazoned with their QSA logo proudly, stating – SAQ C-VT Certified.

Huh? What has SAQ C-VT (merchant SAQ) got to do with the warehouse storage you are offering to my client?

Apparently that SAQ C-VT cert is from one of their parent companies overseas or something and has as much relation to our current project as me running to become the president of the United Sates. It means, One Certificate 100% does not rule them all. It’s a completely different business function and you can’t just use another SAQ or AoC from another parent/child company that is selling ice-cream cakes and had their call agent processes certified and say this applies to your warehouse storage facility half a world away!

Ok, we are halfway there, bear with us. Writing all these myths really can drag an article and you can probably read the frustration oozing out each paragraph. I’ll admit, we get extremely frustrated, but we also must remind ourselves – most of them (customers, banks – NOT QSAs, they don’t get any free passes for giving misinformation!) do not know better and they are just doing what they think it’s right or what they have been told by so called consultants or QSAs. That’s why we need to set their paths correctly so they know what options are there before them. So, we need to stop getting frustrated and blaming them for bad decisions, and get more involved in educating and providing information so they can make good decisions.

We will continue the next time once we catch our breath and go through the other wonderful misinformation on PCI-DSS we have heard over the years. Till then, drop us a note at pcidss@pkfmalaysia.com on anything to do with this standard or other standards like ISMS/ISO27001 etc.

PCI-DSS Full Disk Encryption Part 2

In our previous article we wrote on how Bitlocker can possibly be used as a full disk encryption solution for PCI-DSS.

One of the key things is for the following statement to be complied to:

If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

By enabling TPM itself doesn’t guarantee that the native authentication is separated from the logical access to the encrypted file system.

The below basically enables TPM with PIN to ensure that there is an additional logical access that is required to comply to PCI-DSS.

So overall, this means that Bitlocker needs an extra authentication when the server restarts. As the policy states, either a passphrase or USB will be required for the startup, and from PCI perspective, this addresses the separate authentication requirement.

Of course the major discussion here is what is compliance and what is practical security?

Because when was the last time you actually restarted your server? The fact is that full disk encryption is only as useful as it is to protect data on the disk when the system is not running. When the server is running, access to the disk remains open and therefore, we see unprotected PANs with their pants dropped (so to speak).

We are not saying that bitlocker cannot comply to 3.4.1 of PCI. We are saying probably PCI might be better off relooking at this 3.4.1 and clarify the ‘spirit’ of this requirement. At the end, we are concerned with loss of PAN. We are concerned with the fact that files may be taken away, siphoned away through a variety of means – either through the network, or USB, or photos on your phone etc.

The problem with Full Disk Encryption is that even if we do have separate authentication to boot up into the server, once it’s booted and once authenticated separately, the full disk encryption no longer does the job of ‘rendering PANs unreadable where they are stored’. The argument thus comes about that once that occurs, then whoever is reading those PANs are authorised users already with business requirements to view those PANs.

In our opinion, there needs to be much more security surrounding these servers with PANs that use full disk encryption. Access must be limited again to only those with business justification, and not be used for multiple purposes and especially not for non-PCI usage. Logical access, hardening, logging and monitoring obviously needs to be in place. Protection of the PIN must be in place, and changes of PINs based on PCI-DSS expiry policies.

The comfort level of FDE vs say, file encryption or even folder encryption is much less. Whether it meets 3.4.1, if done properly, it clearly does. But is it truly secure? Therein lies that discrepancy between compliance and security. It ticks the checkbox (for now, unless PCI alters it in 4.0), but from a security standpoint, there is a lot of risk surrounding it.

If you use FDE, don’t expect your QSA to just take it lying down. Most likely further queries will be made and some may deem it even insufficient in itself to address the risks of PAN being compromised and may request additional controls on top of it.

If you have further queries on FDE or any compliance programs like PCI, ISO etc, drop us an email at avantedge@pkfmalaysia.com and we will attend to it immediately!

PCI-DSS: The Art of Getting By

The Art of Getting By is a movie that wasn’t very good. I don’t recall much of it, except the title was appropriate for this article.

The general idea of PCI-DSS is that it’s easier to maintain the compliance than to first obtain it, and while there are nuggets of truth there, we would venture to turn that idea upside down: It’s much harder maintaining it that to obtain it. Maybe it’s like marriage, where after the wedding and honeymoon, the real work begins in ensuring you have 40-50 years left in the tank with your partner (depending on when you tie the knot of course, and in some cases, depending on how many kids you end up having. That’s added stress.). In some ways, it’s similar, and over 8 years of PCI experience had taught us that while we should always (again – ALWAYS) celebrate the success of first time compliance to PCI, we must not forget what lies ahead of us.

PCI Council realises this and in Appendix A3 of their PCI standard, lists out a few extra things for DESV (Designated Entities Supplemental Validation). It must be noted however, these are not automatically mandatory for PCI companies, but for companies designated by their card brands or acquirer based on risks and oftentimes, volume of transactions. If you are not required to go through DESV, don’t go searching for it.

DESV puts in a few extra components to the PCI standard. One of the requirements is to Implement a continuous PCI-DSS program in the organisation. What has been noted by the council is that while many companies do attain PCI-DSS, they treat the standard as an event they need to get by each year. This means companies, instead of practicing PCI in their daily work, seek to re-certify each year based on a series of checklist they need to do at that point in time. Which isn’t cool. But that’s how almost everyone approaches it. It’s like taking your semester exams in University. It’s not like in day to day living, we are thinking about the real value of x in a log2 equation or what are the prime numbers that are relevant to your life. We are just thinking about hanging out, cutting classes and kicking up dust. When the exams come, we mug, we eat ramen noodles for every single meal, we don’t go out, we don’t sleep and we generally try our darnest not to fail, and then the whole cycle of meaninglessness begins again. I don’t really recall much of my university days, as you can tell. And that’s how PCI is sometimes approached.

So how does one stay compliant, instead of just pass compliance?

Management Buy In

We hear this a lot from our management text books. Management Buy In. Unless we have a top down support and sponsor on compliance, PCI is going to be a drudgery faced every year. IT is going to be bombarded with all kinds of requests on top of their already busy day to day work. Most success comes if the business recognises the importance of PCI to their organisation. We have some rare instance where clients do PCI just “because they want to, and they want to look good”, but more often than not, those attempts fizzle out once they realise it’s a rabbit hole you can’t get out of. A cost benefit analysis is key here, and a business case needs to be built, because you are going to end up spending a lot in this compliance, and that spend should be backed up with sound revenue and business in the pipeline – directly generated because of your compliance.

Having a Compliance Team

You need a go-to guy, or a go-to group for this compliance. We have experience where PCI is dumped into an organisation and every week we are dealing with different people. We have one customer who named a project manager to lead the project and his appearance in our meetings is as rare as Yeti sightings. We sit in the meeting and we go, “Where’s so-and-so?”. Some wide eyed junior IT guy goes, “Oh he’s busy with another project, and I am asked to lead”. Anything we discuss, he just goes, “OK, I need to check with so-and-so and get back to you.” Without decision makers in the team, we end up going around in circles and before you know it, 6 months have passed and we are still on the same agenda. It’s like going 3 levels deep in an Inception dream. Get a team. You don’t need to bring in 20 people in the meeting where 18 people sit away from the table, typing furiously at their laptops as if they are writing the next War and Peace novel. 3 or 4 key guys: Person in charge, network and server team representatives, developer rep and if you have SOC/security team rep. Everyone should either be an influencer or a decision maker, and we are good to go.

Business As Usual

We call it BAU. Many have suggested PCI is asking ridiculous requirements which are too difficult to meet. In reality, PCI is basically asking for baselines. The very least organisations should be doing to secure themselves. Security needs to be practiced, and not just implemented as a checklist over a short period of time. For instance, the requirement for daily log monitoring. This is not something you can conjure up when the auditor comes and audit. If you are not practicing it, you are not practicing it. Or simple things like CCTV monitoring. We faced a client doing recertification and on a pre-audit check, we found their CCTV had not be recording for 8 months due to maintenance. I asked why was this not reported or checked, and they sheepishly told me they had no clue and they had never bothered to even check since they passed their cert. PCI requires a fair bit from organisations, for example:

Daily Monitoring of logs, and access to secure area, weekly checks on FIM logs

Monthly checks on critical patches

Quarterly – Wireless Scans, ASV, Internal Scans

Half Yearly – Firewall review, user deactivation

Annual – Pentest, application testing, Risk assessment, training, Inventory checks and review, policy review, service provider review, Incident response, segment checks etc

Those are just part of the listing. So unless you plan to have sleepless nights during the audit period, it’s best to get these done as part of your day to day. We need to note that in most cases, these should be practiced in any case, regardless of PCI or not!

Yes, a lot of these are easier said than done. We are aware teams are being pulled sixteen different directions and PCI is just one of it. It falls back to how critical this compliance is. To many, it’s required to continue their business as it is a contractual obligation. So it’s not just about getting by, although in some cases that might work – but for PCI, we would recommend to embed these practices as much as possible into your organisation, so that when audit season comes, you don’t end up overeating your Ramen noodles.

Get in touch with us through pcidss@pkfmalaysia.com for any enquiry on PCI-DSS!

« Older posts

© 2024 PKF AvantEdge

Up ↑