Tag: malaysia (Page 3 of 4)

PCI DSS and the Problem of Scoping

pci-compliance

I recall in an actual case a few years back when I received a call from a company requesting us to do a certification for PCI for them. So I met them and drew out their PCI plan starting with a gap assessment, remediation and certification audit.

They said they have already done their own gap assessments internally by their ISMS guys. And they will be doing all their remediation on their own and they just needed me to quote for certification audit because “PCI is forcing us to be certified by a third party, which we believe we can do it better than you can”.

There was nothing much to talk to them about, but I did mention that if we find major NC (non compliances, in ISMS speak), we would then use that ‘certification audit’ as our own gap assessment and that we might be required to come back again to verify.

The company truly believed that PCI was a subset of ISMS and they handled it as such.

So we came in for the certification and found out that their entire scope was completely messed up. For instance, there was another out of scope network and systems connecting into their CDE for monitoring. Because card data wasn’t passing through, they marked it as out of scope. Unfortunately, PCI doesn’t see it that way. This would be considered an Non CDE In Scope, and systems within this network will need to be secured as well, and hardened as per PCI. The logic is that if these systems are compromised, there is a path into the CDE that can be exploited.

They made a huge fuss on this, claiming that they are willing to absorb the risk and that their management signs off on the risk assessment.

ISMS is a best practice/guideline at best – it’s a great marker for security, but PCI is a standard. If you can’t meet it, then you don’t meet it. Of course, there are ways around this particular issue, but they insisted we passed them simply because their management accepted the risk.

Here’s another idea: PCI-DSS generally doesn’t really care about your business. It’s not about you. It’s about card data. Visa/Mastercard and the Jedi PCI council are not concerned about your business – they are concerned about the confidentiality and integrity of card data. That’s why you will not find any BCM or DRP requirement in PCI. RTO and RPO? Pfft. They don’t care. Your business can go down for 10 weeks but as long as card data is safe, it’s good.

And that’s why, scoping is HUGELY important. Many people might think that a gap assessment is a waste of time. It is, if it’s done incorrectly. I recently witnessed a ‘gap assessment’ report that was a complete mess. It just detailed the PCI twelve requirements and in each requirement gave an overview of the company’s controls and what they should be doing: ripped off almost verbatim from the actual standard itself. That can be downloaded for free.

A gap assessment needs to bring you from one place to another and needs to provide these:

a) A clear understanding of your scope, including a writeup on your network, and processes that have been assessed. It should also be clear what is out of scope. This initial scope usually is not set in stone as remediation would sometimes change what is in scope and what is not in scope. But at least you have something concrete to start with.

b) If possible, an asset register. For PCI. If this is not possible (for many reasons, e.g they have not purchase some assets required for a control), then the asset inventory needs to be prioritised a quickly as possible to see what is scoped and not. Asset should be clear on: Public ips, internal devices, servers, network devices, people involved, desktops, databases etc.

c) Network in scope and out of scope. This is key as companies are required to identify segments scoped out, and do segmentation testing. Also, CDE is clearly marked, NON-CDE IN SCOPE (we call it NCIS) must also be identified. Systems in NCIS could be monitoring system, SIEM, AD etc. Any system that connects to the CDE, but does not store, transmit or process credit card data are considered NCIS. NCIS must be scoped for testing, quarterly scans, hardening and such.

d) Clear roadmap for remediation and recommendations to proceed, specific to the organisation. These ‘gaps’ should all have a corresponding solution(s).

If the gap assessment doesn’t give you any of these, then it’s pretty useless. If it doesn’t move you forward or provide you with the information to move forward, it’s not a gap assessment. It’s an expensive training session.

So back to the first example of a customer. It wasn’t possible for us to certify them no matter how they argued, because simply they were not compliant (there were also many issues that they did not comply, for instance storage of card data in text files and sending via emails).

As a lesson – don’t neglect the proper scoping. It’s hard work, but as I always say: Start wrongly, do wrongly, finish wrongly. And that’s 6 – 8 months down the drain, with thousands of ringgit gone in investing, and job on the line. The second example is pertinent also. There is always a chance to OVERSCOPE as there is to UNDERscope.

An overscoping example would be to purchase all sort of snazzy security systems worth thousands of ringgit only to find that these were not needed, or that current controls were sufficient. It’s nice to have – but most of our customers, no matter how big they are, always have a trigger on the budget and cost optimisation is the topmost in their priority.

If you want us to help you in your PCI-DSS scoping, drop us a note at avantedge@pkfmalaysia.com and we can get you started with the initial understanding straight away!

The Myths of the Top 10 Myths of PCI-DSS

pci-compliance

A while back, the PCI council published a good article called the Ten Common Myths of PCI-DSS, to basically debunk a few conclusions people (or so they think) might have on PCI-DSS.

After wading deep into this standard for the past 6 years, I am taking a look again at these myths and I am like, Wait a minute, this isn’t exactly correct.

Myth 1 – One vendor and product will make us compliant

This myth is hard to beat. It’s obvious that one vendor and one product doesn’t make anybody compliant since PCI-DSS is so much more than a product or an implementation. It’s the practice of security within an organisation itself. But wait. Not all PCI projects are created equal, and here’s where we call ‘scope reduction’ comes into play. It is possible that a product can significantly reduce scope so much so that it’s almost easy to become compliant. For instance, tokenization. This is a solution created to remove the need of dealing and storing actual card data in a merchant environment. Instead a token is used and is mapped in the token vault provided by a service provider. Hence, the merchant does not have the key or means to decrypt. Of course, they still handle the first time card data is transmitted through, but it removes the need of the merchant to completely fill the dreaded SAQ D-MER as they no longer need to store card data. Or P2PE for instance. When it started, the solution was to provide a point to point encryption so that merchants need not have the means to manage the keys or decrypt the data. Of course, P2PE bombed and they had to revise the standard to make it more realistic.

Myth 2 – Outsourcing card processing makes us compliant

Again – if you outsource card processing, it might not immediately make you compliant but it sure as heck make it a lot easier to be compliant! With the new revisions of SAQ, we have the nicely flavoured SAQ-A and SAQ A-EP for ecommerce merchants to deal with, to avoid the death knell of SAQ D-MER. There are like 9 flavours of SAQ (self assessment questionaire if you are wondering), and merchants might differ in their journey of PCI depending on their business. Outsourcing to a PCI compliant card processor or payment gateway is a great way to reduce your scope. So while this myth is correct, outsourcing is still a great strategy if payment processing is not your core business.

Myth 3 – PCI compliance is an IT project

Everyone will nod their head in the board room and steering com and agree to this one sagely. But from experience, I will tell you, whether it’s business or IT project – IT guys will be significantly involved in it. If you think you can breeze through this sucker the way you championed through ISO27001, you are in for a little surprise. A large part of the 12 requirements deal with technical requirements, from firewall configuration to antivirus to logical access controls. Logging and key management are significant challenges we find, and an entire requirement 6 deals with patch management and secure coding practices. So, if you are not familiar with terms like OWASP, KEK, DEK, WSUS, TACACS/ACS/LDAP, XSS, CSRF,CVE and all these, it’s time to get cracking. Having done both ISO27001 and PCI, we can say the ISO is more of a best practice/guideline on security while PCI is a standard. It’s either you do or do not. There is no try.

Myth 4 – PCI will make us secure

I know what this myth is trying to say, but technically, if you are practicing PCI, you are a heck lot more secure than someone that’s not. Besides, being ‘secure’ isn’t a final state to be – it’s not possible, but rather it should be a constant practice of a hundred different activities to contribute to ‘being secure’. It’s like when people talk about ‘enlightenment’ or ‘world peace’ – it’s not actually achievable – and even if it is – it’s not sustainable. So yes, PCI will make you secure , relative to the company that has their server under a marketing director’s desk and the password “PASSWORD”.

Myth 5 – PCI is unreasonable; it requires too much

Obviously, PCI Council wants you to think this (again, they are saying these are myths, so whatever you read, PCI Council is asking you to think opposite). They are saying, PCI is reasonable, it doesn’t require much.

I disagree.

It requires a lot.

I mean, OK, if you say SAQ A or A-EP, fine, agreed, it’s a breeze.  But if you are talking about SAQ D or a full cert?

Unless you have unlimited resources, money, time or already practicing some Level 5 Maturity of security, then you need to really look into managing PCI. Most of our clients aren’t in that state, so when you talk to them about the amount of work needed? Oh boy.

Let’s say they have 40 devices in scope. Multiple applications, running on multiple servers. Several layers of firewalls. Firewall rules need to be clean. Sounds easier than it is. The amount of legacy rules we see in some clients would make you think that firewall has been around since the internet was invented. Server upgrades due to EOL. Network changes because the database is accessing the internet directly. Applications not patched. Devices not updated. Logging not centralised. No correlation of logs or event management. No incident management. No central management of passwords and users. Applications developed eons ago and developers have since left the company with the only document being a note saying, “Goodbye and thanks for all the fish!”. You get the drift.

Myth 5 and Myth 10 (PCI is too hard) is the same. When you put the word “TOO” in there, its brings in relativity. What is “TOO” to some companies? When you have a single administrator running the whole thing and he is dividing his time between this and a thousand other things, “TOO” might be the key phrase there. So, I won’t say it’s not possible for a full certification – it obviously is, since we have certified a number – but what we don’t want is our clients walking into PCI with expectations of breezing through and then get slammed like a deer in headlights. It will take effort. It will take resources. It will take money and it will take time. Yeah, time. Around 3 – 4 months if you are lucky for a full certifications. I often get a stunned look of disbelief and a general retort that goes like: “<insert invectives here>, I thought it would only take 2 – 4 weeks, man.”

Look – PCI is really useful and it’s not the intention to discourage people from going for it – but it would be great to be better informed so that expectations can be synced to reality. In the next article, we will cover the remaining myths of PCI.

AlienVault Update and Some Tricks

It’s been a while since we updated on AV, and that’s because we’ve been busy with some POCs and Installations.

Since the last post, quite a lot has changed about AV – and all to make it a lot easier to set it up. Before we go into a detail post on it, here are some extra tricks in creating some helpful shortcuts:

Create in /etc/bash.bashrc

alias avsql='cd /usr/share/doc/ossim-mysql/contrib/plugins'
alias avplugins='cd /etc/ossim/agent/plugins'
alias avdevicelog='cd /var/log/alienvault/devices'
alias avagentlog='cd /var/log/alienvault/agent'
alias avhidslog='cd /var/ossec/logs/alerts/'
alias ossimlog='cd /var/ossim/logs/'
alias configyml='more /etc/ossim/agent/config.yml'
alias ossecdecoder='cd /var/ossec/alienvault/decoders/'
alias ossecrule='cd /var/ossec/alienvault/rules/'
alias avarchivelog='cd /var/ossec/logs/archives/'

Each of these basically will have a lot of use, and you will be going back and forth if you are implementing AV or troubleshooting it – so its best we set these aliases early.

What these mean is that instead of typing cd etc etc, we just type in avsql, avplugins etc to go to their respective directories.

AVSQL = this leads to the sql directory for the plugins, where you will need to go when you implement a plugin and put in the cfg and sql file..

AVPLUGINS = this is where you need to go for the cfg file for the plugin

AVDEVICELOG = very useful directory. Basically any log devices (devices sending logs to AV), will appear here. This is big move away from the traditional rsyslog setup whereby we need to go through all the crazy set up = over here, we just enable the plugin on the asset detail page -> Plugins and voila, it’s auto set up for you. I must say, this is well done, AV for making it less painful.

AVAGENTLOG = this is for troubleshooting the HIDS or even plugins. Agent.log should show whether your plugins are working or not. Just cat agent.log | grep <pluginid> for an idea whether the plugin is correctly loading.

Now, this is a quick one, but the new version 5.2 is out already and it really solves some issues.

Here is a snapshot!

  • Underlying OS upgrade
  • AlienVault USM and OSSIM v5.2 include an update to the underlying operating system to improve general performance, stability, and reliability. The AlienVault OS is based on Debian, which will update from Debian 6 ‘Squeeze’ to Debian 8 ‘Jessie’. All libraries, kernel, and software will be updated; therefore the update option is only available from the AlienVault Setup menu (both online and offline), not from the web interface. Note: Please read the instructions prior to upgrading


Improvements for USM only: 

  • Rapid report delivery
    • Updates to existing reports will now be delivered separately from platform updates. The new reporting framework will allow for more frequent updates and improvements to report used to prove compliance and measure security status.
  • Reporting improvements
    • Simplified user interface in reports list and report module list
    • Enhanced visual design of PDF and HTML report output
    • Ability to “print” pages in the UI for customers so that customers can share information with other team members without giving them access to the system
  • Audit-ready compliance reports
    • Based on feedback from auditors and compliance experts, AlienVault delivers over 30 new audit-ready reports for PCI-DSS 3.1 and HIPAA to answer the most common questions from auditors.
  • OTX reports
    • Identify emerging threats targeting you environment by reporting on events that contain suspicious IP addresses from the OTX IP Reputation database and report on events generated from IOC’s that have been identified in OTX pulses.

MSC status for Rakuten Malaysia

rakuten

Congratulations, Rakuten Malaysia for attaining your MSC Status!

One of our services is to provide consultancy and program management for MSC application and attainment. It helps that we have gone through the MSC status approval ourselves, but in general, any company intending for MSC needs to be aware that there is some work involved.

In general, you need to understand that you can do this on your own. There is no requirement whereby an independent third party is needed. That being said, in order to smoothen out the process, usually, someone who has gone through the process should be able to assist in a lot of areas. We are pretty flexible in how we work with our clients. For some, our involvement is very heavy, from writing business cases to financial projections etc. For others, we basically advise and manage the communications between MDEC and the company – which is less hectic, but more work for the client. Mostly, our clients come to us because they want MSC due to the tax breaks, and they have better things to do than to go back and forth with MDEC to iron out the business plan and stuff. For us, this IS our ‘better thing to do’, so you get a complete focus and a guarantee success fee attached to our quote.

Once you have decided to go for MSC, we will sit with you to decide on which is the best sector to go in for. Infotech, Creative Multimedia, Global Outsourcing, with each breaking up into subsets of their own. It’s easier said than done actually, because (strangely) sometimes the MSC activities might not be your core focus activities. For instance if you are a reseller, then trading cannot be part of your activities. If you are training, you cannot put that into your activities. However, if you have a branch out R&D or software development, you could technically park those as MSC.

After the decision, we fill in a pre-application form, then follow up with the business analyst. Not all BAs are created equal. We know because we have dealt with a whole train of them. Some are better than others – and we generally jostle to get the better ones for our client.

From there the bulk of the work is in defining the business and financial plan. There is more work than meets the eye here, because there will be a lot of back and forth with the BA before he/she is comfortable to present it. You generally will face some issues – we have faced more than our share – and having a good BA and a good rapport with MDEC is key to get things done here, both of which we will attain.

Once the BA is more or less ready – in general you are fine. However, like in this case, there were still a lot of clarifications to be done. I had to meet with the strategists and head of programs for MDEC in order to push our approval through, in terms of explaining to them our viewpoint. Where MDEC needs to improve is in how they view different business models and revenue models, especially in dynamic environments like cloud applications and such.

Overall, we give up to 75% of our fees as success based (means, no payment until certification). In some special cases, it’s even 100%, means there is no outlay (except for the RM2000 application fee direct to MDEC), until you get your cert.

If you need more information, feel free to contact us at avantedge@pkfmalaysia.com.

Personal Data Protection Act Products

It took us a while to work this out. We started developing a suite of products to address PDPA concerns of our clients back in late 2012. Aside from developing with our colleagues in UK and India (who have experience with personal data protection acts of their own for years), we have also engaged discussions with agencies like Cybersecurity. Of course, we have also had legal firms partnering with us over the course of the development, but we wanted our products to be practical and operational, not catered to legal department, but to whichever department that needed to implement these.

Over the past months, we have met with the Personal Data Protection Department to find additional clarity, culminating in a public joint awareness workshop between PKF and PDP Department on the 25th of February 2014.

Over 2013 and early 2014, we have refined these and decided to roll out different packages to cater to different requirements of our clients. PKF, in reality, isn’t the big 4. We don’t have multi billion dollar clients (well, we do, but not many), and in this reality, most of our clients, even the bigger ones are extremely cost conscious. Hence, all our awareness talks including the one we jointly organised with the Personal Data Protection Department, are free of charge.

Hence, I was sitting at a meeting with a customer back in 2013, and she mentioned that I should think of a tiered product: Basic, Intermediate and Advanced when it came to PDPA. As this was a fairly new Act, it would be best to try to get everyone on board at the lowest cost possible.

Hence, starting last week, we’ve launched our PDPA suite of services:

1) Starter Package

This is for customers to “do it themselves”, with the basic document templates required based on the Personal Data Protection Act 2010 and the current subregulations. All that is required is to edit these templates. Implementation guidance is only from the policies, and the organisation will have to implement on their own and the responsibility of providing evidence of implementation of controls is entirely from the organisation. We won’t be verifying or validating any of the controls, as this is only on documentary level. This is a good starter package to immediately address the key PDPA issues from a documentation perspective. This will include any updates of code of practices we will get from time to time from the PDP Department.

2) Checklist Package

This includes everything in Starter, as well as our Checklist, which had been developed and discussed with government agencies. The Checklist, which covers all 7 principles in easy to understand explanations also maps to the current ISMS/PCI/COBIT standards, for the ones more inclined to technical audit. Using the checklist as implementation guidance, we expect most of our customers to be able to address most of the PDPA concerns in this package. Again, we cannot verify or validate the implementation or take any responsibility in the results, but in this instance, the roadmap for PDPA compliance is provided, and organisations to follow the checklist. Offsite support provided.

3) Assessment Package

This includes everything in Checklist, and also onsite gap assessment; scope definitions; implementation advisory, training and follow up assessment.This would be for customers looking for a comprehensive solution to address all of PDPA principles. Using this baseline, this could further launch the organisation into other compliance projects such as ISO27001 etc.

4) Custom package

This typically is for organisations who want us to do the implementation, instead of just assessment and advisory. This could be to locate resources onsite for the period of the project, to do project management; to do technical implementation etc.

The current packages are priced as follows:

We’ve purposedly priced Starter as such so that all our clients will take up at least to do the policies addressing PDPA. That itself is reasonable enough to get started and to have something. Even our assessment package is almost 50% lower than our typical IT Audits, again to hopefully have more clients consider addressing PDPA as opposed to just ignoring it.

We will be publishing the products more formally through the official website, but for now, do contact us at avantedge@pkfmalaysia.com or call +603 6203 1888 for questions or samples of PDPA policies.

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑