PKF AvantEdge

Category: IT Audit (Page 7 of 13)

The Service Provider Challenge for PCI

August 12, 2018 / / 0 Comments

While it’s very tempting as consultants to just sometimes approach a customer requiring PCI-DSS and after identifying all their service providers, declare: “I need all your service providers to also be PCI-DSS compliant and certified!”, the truth of the matter here is, that you don’t need to. As in you (undergoing PCI) do not need to have all your service providers compliant and it will not affect your own compliance.

PCI SSC made it very clear with the publication found in their Third Party Assurance supplementary document. 

If you have time, it’s a very good read.

Service provider compliance comes in requirement 12.8. As per document:

 

When engaging with a service provider, the PCI DSS compliance must be verified with one of the following methods:

  • For providers that have undergone their own PCI DSS assessment: request and review the Attestation of compliance, scope, date
  • For providers that have not undergone their own PCI DSS assessment: include the provider’s environment as part of the entity PCI DSS assessment (increase your own assessment scope). You may need to request your own QSA to perform the provider’s review.

For the second part, it’s of course, a bit tough, seeing that you are actually paying a QSA to perform an audit for someone else, when you would think they should be paying for it.

Basically, we do need to ensure that PCI DSS clauses are present in all contracts, especially for ensuring compliance maintenance, liability, right to audit, and right to terminate in case of non-compliance to PCI-DSS. This might be a good time to call your contracts personnel and start drawing up another one. (Address 12.8.2)

It’s 12.8.4 that stuffs us up: Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. This generally means, it has to be either a level 1 or SAQ verification of the service provider.

The document above actually provides a guidance for different scenarios in section 6.2: Other Considerations. It’s certainly worth the read. We have a scenario where the service provider is compliant but refuses to provide information. In 6.2.2 we also have a scenario very relevant to many: Third-party Service Provider has not Validated PCI DSS Compliance.

This is quite troublesome, but unfortunately, this is much more common than you think. A lot of providers don’t even have a clue what PCI-DSS is all about.

So if you do end up with a provider without any PCI but its too difficult to change, there is still a way out:

  • “If the TPSP (Third Party Service Provider) has not yet completed PCI DSS compliance, ask for a detailed plan with deadlines for finalizing the PCI DSS compliance process; make sure the TPSP provides status checks on a regular frequency until it achieves PCI DSS compliance.”

It really doesn’t sound that great to be honest. It’s like babysitting a misbehaving child and you just want to get it over with and have other things to do later that night but this kid is just not wanting to sleep and you feel like getting some cough syrup to mix into his milk…that sort of feeling, not that we have any first hand experience on that kind of inhumane stuff. Pftt. Of course not. We all have perfect children.

But for these service providers, you do find yourself wondering if you ended up with the short end of the stick.Extract below:

  • “If an agreement exists between the entity and the TPSP, the entity may consider an examination of the contract or agreement with the TPSP to determine which party is responsible for mitigating the non-compliant data or process.
    • Consider whether the non-compliant service or process is essential and the impact of stopping it as soon as possible until a solution can be developed.”
    • For business-critical issues, the entity and TPSP should work together to determine who will be accountable for the cost and responsibility for correcting the issue, if necessary. Discuss with legal counsel to ensure the entity or the TPSP and any nested TPSP use appropriate agreement/contract change provisions or clauses to negotiate a fair and reasonable timeframe to remediate the non-compliance issue.
    • Discuss with the TPSP and agree on introducing compensating controls as soon as possible that mitigate the risk of continuing with the non-compliant process or data exchange—while work continues on its remediation.
    • Prepare a remediation plan that can be provided to the entity or the TPSP in a form that can be used as evidence (e.g., Compensating Controls Worksheet) to provide a QSA if a PCI DSS compliance review is due within the remediation timeframe.
    • Ensure any nested TPSPs meet the agreed obligations with regard to remediating the non-compliant issue and keeps the TPSPs informed of progress.”

That’s a lot of stuff. “Nested” TPSPs in the last point doesn’t mean they have the same nest, it simply means that if there are dependence on remediation of this TPSP (i.e the TPSP of the TPSP), these guys also need to understand they are pulled into scope. It’s very headache.

In conclusion, it’s probably better to start looking out for TPSPs who are already compliant or who understands their PCI compliance obligations, and for those who refuse to put in their effort on this compliance, well, be prepared to get left behind. Because once one or two of the same industry TPSP gets compliant, it will no longer be the norm to be NON-COMPLIANT and this TPSP will stand to lose out customers in the future.

For information on how to handle your PCI-DSS requirements, please drop us an email at pcidss@pkfmalaysia.com and we will get right back to you ASAP!

PCI-DSS: Business Not As Usual

June 21, 2018 / / 0 Comments

Have you heard the phrase Too Long, Didn’t Read? What if this applies to your PCI DSS compliance program, rephrased to “Too administrative, didn’t’ do?”.

We get this all the time in our meetings. Everyone mobilise for the big PCI project, everyone celebrates when they get certified and everyone suddenly gets collective amnesia and forgets about it. They forget there are daily requirements (like daily review of logs), weekly requirements (like FIM file comparisons), monthly (like critical patching), quarterly (ASV etc), half yearly (firewall reviews etc) and annual (testing etc). Yes, there are such requirements. We generally encourage our client to celebrate their success for first time certification but keeping in mind these obligations. Certain things you just can’t afford to miss out like your ASV scans and Internal VA scans.

PCI calls this Business As Usual (BAU). Being so long on the receiving end of these compliance requirements and now dishing it out in our advisory, I can safely say: PCI isn’t business as usual. In theory, yes, it should be, but theory and reality remains as far away as the possibility of Malaysia winning the next World Cup. A lot of our clients, after winning the PCI certification, find themselves completely overwhelmed with the so called Business As Usual theory that they wonder, whether after achieving PCI Business As Usual whether there will be any Business left to be usual about.

So what happens now that you are PCI compliant? When you are planning your PCI DSS compliance maintenance, you may want to setup a team to look into all the requirements, be it the technology, process and people. After you get your PCI DSS compliance, remember, the ‘maintenance’ clock starts. Yes. So if you take 2 months to celebrate your victory over this dastardly villain called PCI, you technically have one month left to do your Internal Scans and ASV scans. So don’t forget about what you need to do. Your PCI team needn’t be dedicated personnel (Very few companies can afford that), but there should be a lead person, relatively not bogged down by day to day operation works, and ideally independent from the operations as well. If you have a info sec team, it would be good, else a technical project manager to lead and the responsibilities to maintain, to go back to the process or system owners.

True, even before PCI arrives, you are probably already bogged down by other compliance requirements on top of your normal day to day. ISMS, customer audits, regulatory audits and assessments, internal audit, and now PCI. It’s like eating pancakes after pancakes except these are horrible tasting pancakes.  You might forget some of the administrative tasks that need to be maintained as part of your PCI DSS compliance process and we have had customers scrambling to complete their quarterly scans after missing them. Eventually, after a period of time, all these tasks will pile up on your plate and you are left with the prospect of being unable to be recertified. Your PCI DSS compliance will be at risk of becoming non-compliant and void and really, it’s not something the board will be too happy about, after taking 3 months of budget to celebrate the victory earlier. It’s like winning the English Premier League one season and getting relegated the next. The emotions are too much. We may think these maintenance tasks are petty but it is an important component in your PCI DSS compliance ecosystem.

Here are some insights to some examples of these administrative tasks that might be missed:

Changes on firewall/switch/router rules or configuration– it is highly critical that before a change is done, proper testing, approval and documentation are carried out. As these devices are critical components in the network infrastructure, any misconfiguration may result in security issues or in our observation, even bring down the whole network and have people scrambling over the weekend unnecessarily. Proper testing and approval process are any case required before changes can be made and this must be documented. Documentation provides an audit trail of changes and why these changes are required. So, don’t forget to document this process. Or risk the weekend being messed up.

Patching – There is this perception that if I’ve setup my systems to perform patching automatically, everything is well. Wrong! You need to review the patches and ensure that it is safe to be deployed and it will not like, I don’t know – crash your production systems? Next is to make sure the patching applied is being documented so that you have a history of updates on your system. A configuration information (CI) system can do that, or you can ensure you run your inventory checks regularly, as Windows would keep track of these applied patches. If the system is being patched up manually, you need to have the procedure of checking for updates on a regular basis. Make it a habit to check if your system is running with the latest patches regardless if the patching is automatic or manual by making it as a checking activity in your periodic task list. Remember, PCI would require a one month critical patch deadline and three months for non critical security patches.

Anti-malware – anti-malware will normally update automatically and periodically and we will assume that it will run as what it is being configured to do. As such we will not bother to check unless something bad occurs (which almost always does). As part of your administrative task, you should make it as a daily task to check the anti-malware system status, malware detected and the resolution of it and put this task in your checklist.

Logging and Monitoring – PCI DSS requirement 10.6.1 requires review of security events at least on daily basis. Most people stare blankly at me as if I’ve just told them elephants do wear tutus and can fly. Then they realise that I am not joking, they shake their head and invariably say (in variable tones, depending on how incredulous or stupefied they are): “WHAT?! DAILY?!?” .

Well, yes, in a way, although PCI in its supplementary document Effective-Daily-Log-Monitoring-Guidance.pdf, they have provided this little leeway for your ease:

“A reasonable timeline must be defined to allow less capable organizations to perform security log reviews while still enabling the organization to detect malicious or anomalous activity before it can likely escalate. In the case of Requirement 10.6.1, PCI DSS has determined that timeline to be a maximum of 24 hours or one calendar day.”

So when we refer to ‘daily”, it is with this definition in mind. Still a difficult one, but hey, OK.  In our advisory works, we have seen that clients often miss out the daily review and alert they receive (usually through email). It could be a SIEM (Security Information and Event Monitoring) system is deployed and configured to identify a threat and sends out an email to the person in charge. Instead of monitoring this email that might be a critical security issue, it is not reviewed. Not reviewing security alerts is a risk that may have adverse effect for obvious reason. In a recent retailer breach, for many months hackers were siphoning information from their POS systems to a spool server and removing that data file to an external system. If reviewed properly, such an abnormal data flow might have been spotted.

So, these are a few of the admin tasks. There are a lot more. Moving forward, be diligent, make it a habit to not miss any of these out and incorporate these administrative tasks as part of your daily routine tasks. Other tasks include ensuring quarterly testing such as ASV, annual penetration testing, etc as described in requirement 11 are carried out properly and given enough time to perform. Don’t expect your team or vendor to do a pentest on 50 systems and tell them to complete it by tomorrow. Failure to observe PCI timelines may result in you losing your compliance.

Don’t get relegated after winning the league!

Contact us at pcidss@pkfmalaysia.com for further queries on PCI-DSS and we will set up a meeting with you as soon as you are available.

PCI and the art of scoping

May 5, 2018 / / 0 Comments

A lot of people we have met had told us this: “Since we are ISO27001, PCI should be a piece of cake, right?”

The context of this is because ISO27001 and PCI are often seen as distant cousins. They are both very relevant in our country and region (unlike other compliance like HIPAA), both deal with information security, and the overlaps between the Annex A controls of ISMS and PCI are evident. Therefore, the natural conclusion is ISO27001 is either a superset or a subset of PCI-DSS.

The problem with this assumption begins right at the start. In ISO, the scoping is largely determined by information that matters to your business. Before the iteration of 2013, scoping was generally done in a cowboy sort of manner. We met a company who had tons of sensitive information and told us they were ISO27001 compliant – and their scope was the security of their printing documents. Yes. How they literally secured the hard copies of the printouts. That was their scope statement.

Now 2013 version of ISO27001 had tried to stem these shenanigans by introducing interfaces and dependencies. Basically now the scope needs to cover information that are deemed important enough to protect from business perspective. This would cover the products and services relevant to the context of the organisation. Overall, scope determination of the ISMS can be a prolonged matter if you have a large organisation, and is often subjected to the business side of the organisation.

PCI scope?

It’s determined by the information that matters to the payment card brands, not your organisation. Credit Card Information. Primary Account Number. That’s it.

If you store, transmit and process PAN, PCI applies. If you don’t do any of these, and you do not influence any transactions in the payment card flow, then PCI doesn’t apply.

Often, people express utter shock that PCI doesn’t have any business continuity requirements. In terms of the holy trinity of information security – Confidentiality, Integrity and Availability (CIA), PCI primarily focuses on Confidentiality. Integrity is only focused in terms of its relation to confidentiality (Integrity of logs, integrity of system changes, system files etc), and there is no concern on Availability. Which makes sense. Between you closing down your business for one week versus you losing credit card information of your customers, the latter is viewed as more critical to the payment brands than the former. Although from a business perspective, a loss of business for a merchant is a loss of business for the entire data flow, upstream or downstream, so PCI not really caring about your RTO or RPO may be counter productive – but that’s an argument for another day.

At the end PCI scope boils down to you storing, transmitting or processing card holder data (CHD). Even if you don’t do any of these 3, you might still be in scope if you influence the security – an example would be those SAQ A e-commerce merchants that redirects requests to another PCI service provider. Even though they don’t deal with the CHD, they influence the transaction through their redirects, therefore, some parts of the requirements need to be met.

So – before we start our PCI journey, it is  very important to know what is the scope that is covered in your PCI environment. We may not want to take the whole environment as IN SCOPE – for cost, quality and timeline purposes. Our normal practice here is to reduce the scope as much as we can, a process we consultants term as “Scope Optimisation” simply because it sounds grand. I mean it sounds better than “Reduce your scope” which generally is interpreted to “reduce your price”.

In general, there are six things that we have to compile before we truly initiate the PCI journey.

a) Location and Address of the PCI scope. This is simple enough. Usually your data center is in scope. Depending on whether you store, transmit or process card data in your other offices, those come in scope as well. A question here would be – what about HQ, where our administrators access the PCI systems in DC, via a VPN connection? Ah. The secret sauce of putting things out of scope in a remote location where there is no storage, transmission or processing (lets just shorten these to STP from here on) of card data but there is access from an admin systems – multi-factor authentication. As long as this is in place, while the admin system is in scope, the location itself is then put out of scope. So you can connect from Starbucks, your home, or Timbuktu, and you would not have these locations dragged into your precious scope.

b) Applications that STP CHD. Store, transmit or process card holder data. Many queries have been like – oh, do we need to use PA-DSS applications? Well, if you do use PA-DSS certified applications, it would be very useful. However, even if you do not, you can still access that application as part of your scope under Requirement 6. In fact, some applications may not even be able to be PA-DSS for many reasons, such as it not being part of the authorisation or settlement flow but still storing card data. A custom CRM for example would be one that cannot be PA-DSS but still in scope for card data application. OTC (off the counter) products that store card data are still in scope, however, they need to be assessed properly to determine if there are any security issues that may influence the confidentiality of card information.

c) Network Diagram – an updated network diagram is a must. And a network diagram needs to be detailed enough to be able to differentiate the PCI and non-PCI zones. The important thing we need to take note on the network diagram is the proper demarcation of PCI zones, so we know what are:

  1. Card data environment in scope (CDE-IN-SCOPE) – ZONE A
    1. Any system that store or process or transmit CHD
    2. For example, application server, Database server
  2. Non-Card data environment in scope (NON-CDE-INSCOPE) – ZONE B
    1. Any system that require to communicate with CHD
    2. For example, patch server, anti-virus server
  3. Out of Scope – ZONE C
    1. System not related and has no communication with CHD – but might communicate with NON CDE IN SCOPE.
    2. For example, CCTV server in your office environment

d) Asset List for PCI – the asset list is critical because this relates directly to the effort and remediation costs of your PCI program. There is a huge difference in doing pentest for 200 systems versus 20 systems. So in this case, we don’t care about your assets considered not in scope, we want to know the assets in CDE and in NON-CDE in scope (Zone A and B).

e) Public IP addresses – this is needed because of ASV scans required. ASV scans are security scans done by the ASV (Approved Scan Vendors) of PCI. You can’t do it yourself, you need to get an ASV to do this for you.

f) Data Flow Diagram – This shows the card data flow in your organisation. Basically every channel where credit card enters into your environment, stored and process and exits. This details the lifecycle of CHD in your organisation whether it ends up being stored in a database for seven years, or passed out to another service provider. It’s essential to understand this – and if you have multiple channels where card is being entered (e.g e-commerce, POS, MOTO, Call Centers, KIOSKS etc) you need to document each of these from start to end.

So there you have it. PCI scoping at your fingertips. Drop us an email at pcidss@pkfmalaysia.com and we can have a free session with your organisation on what could be your possible scope, which likely may not be just your printouts coming out of your printer!

Proxies in PCI

May 4, 2018 / / 0 Comments

A proxy server is a server that serves as an intermediary between the requester (a client PC for example) and the responder (typically the destination server). There are 3 types of proxy servers that are commonly implemented in many organisations:

  1. Forward proxy – this is the most common proxy server. A forward proxy is a proxy server that serves the request of the internal client and processes the request for the client by sending and receiving the response from the destination server. In the most common implementation, it is an ‘internet facing’ server that will retrieve internet resources and return it to the requesting client. How is this useful? For one, it serves as a single point for security access control. If you have hundreds of systems coming through your firewall asking for a thousand of requests per second, a proxy can do a few things. It can control who gets what access. Additionally, if implemented with caching capability, a thousand requests for the new Beyonce video don’t need to get that video downloaded a thousand times. I can cache within the proxy and serve it up internally. Cool!
  2. Reverse proxy – Reverse proxy is the opposite of a forward proxy in terms of traffic flow. It is allowing what can access your internal resources. Again, it is an external facing proxy server that accepts request from an external requester and sends the request to the internal servers (for instance, an FTP, HTTP or SMTP server). The response returned to the requester will be as if it was coming from the proxy server. There are few objectives for reverse proxy e.g. shielding the internal servers from the outsider, load balancing, security controls etc.  It’s fairly easy to set up as well.
  3. Transparent proxy – transparent proxy is a proxy server that sits between the requester (client) and responder (server) and there is no configuration required on the client side. A transparent proxy is generally deployed inline, meaning, between the client to whichever gateway it is going to . It intercepts the client request before forwarding it to the destination, without the knowledge of the client. This is useful if you have thousands of systems, and limited control, or you just don’t like group policies from AD. Transparent proxy normally is used as a content filtering,  Internet traffic control and web caching.

Is a proxy server useful when it comes to remediation for your PCI DSS compliance? Yes it is . There could be some cost saving scenarios where a proxy server is useful.

Where can proxy server applies? An example: a client is running MariaDB on a  Linux server and using clamAV  for malware protection and they have a database storing credit card number (FULL PAN). Obviously, this server will be in a CDE “in scope” segment (Card Holder Data Environment in-scope).

In PCI DSS 3.2   Requirements and Security Assessment Procedures requirement 1.2.1 and 1.3.4, while it states that the traffic coming and going out from the CDE must be restricted, it does not state that you cannot have an outbound traffic from a CDE to the Internet. Below is the reference to the PCI DSS for inbound and outbound traffic to/from CDE:

1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

Specifically INBOUND:

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.

And OUTBOUND:

1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

On proper reading, inbound traffic is a strict no-no for Internet to CDE. So either you tackle this with an intermediate server in the DMZ, or a reverse proxy can come in play.

Outbound is a little more flexible, whereby all traffic should be restricted

Restricted isn’t prohibited, but there is a good reason why proxies become useful here.

a) It’s better that organisations do not to expose their CDE systems to the Internet, even for outbound. This makes sense, even though in most cases you will likely NAT your outbound connections through your firewall. But try arguing this with your QSA and you will probably wish you had just implemented controls instead.

b) Firewall policy minimisation. Why? Because you need to do a firewall review. Imagine you have 50 systems in your CDE requiring patches or connectivity to external. You would need to have a policy that adds/removes these systems to specific ports, destination etc on your firewall. With a proxy, you deal with one IP going out.

So for the above example, if the client can’t expose their CDE segment to Internet, a forward proxy can be set up. Setup a proxy server (e.g. Apache, etc) in the DMZ (in scope) segment. Configure the database server to point to the proxy server. With this setup the database will be able to get the antivirus update through the proxy server but without connecting directly to the internet. The proxy server serves as the intermediary between the database server and the internet. The QSA is happy and everyone passes PCI.

In this example, implementing a proxy server is not the only method that can be used to connect to the internet and have antivrus getting the update. You can set up a ‘repository’ server in a non-CDE, in scope environment which will then download the antivirus updates and patterns and the CDE server pulls the updates from this server (like WSUS for Windows). As in many things PCI, or obtaining the latest Beyonce video online, there are a few ways to skin a cat.

Contact us on pcidss@pkfmalaysia.com for more information on how we can help your PCI-DSS program!

 

PCI-DSS: The Art of Getting By

April 6, 2018 / / 0 Comments

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 Newer posts »

© 2024 PKF AvantEdge

— Up ↑