Author: pkfavantedge (Page 21 of 37)

Personal Data Protection Act for Dong Zong

dongzong

To kickstart the New Year, we spent two full days with The United School Committees Associations of Malaysia for the Personal Data Protection Act training. Which is really a mouthful to say, so we will go by its more well known alias, Dong Zong.

Now, this is a rather unique engagement, for the simple fact that both our lead trainers in PDPA do not speak a lick of Mandarin. The first is proficient in Malay (as he is Malay), the second (which is me) is proficient in English – although he is technically a Chinese. While I am Chinese by birth, my proficiency in language is as follows: English, Malay, Cantonese, German, Minionese, Mandarin. That is to say, I can talk in German and Minionese far better than I can talk in Mandarin. For those who are wondering, Minionese is the official language used by the Minions, the yellow, annoying creatures that so love bananas and my sons so love watching.

Thankfully, we had another colleague who was proficient in Mandarin, but needed a bit of update on the subject, as he was from our technical deployment team for SIEM. So we had a bit of crash course for both. I had to do the introductions, demo and clarifications in broken mando-canto-eng-nese, and he had to crash course the updated PDPA training.

We can usually do the training quite comfortably, including the technical demonstrations (which consist of us actually searching for personal information on the internet during the training itself, demonstrating how easy it is if you know which tools and how/where to look). But this was made infinitely harder because of my lack of command in the language. To put it simply, it was like wrestling with a 300 pound catfish or a giant python. You know what to say in English, but the translation facility in your brain is broken and you just can’t get it out of your mouth and what ends up coming up is meaningless dribble, which my 2 year old son would probably appreciate, but not a roomful of teachers and educationists…who are championing the Mandarin language and the progressive advancement of the Chinese community as a whole. It would be great if I told them I was actually Middle Eastern or Eskimo, then they won’t expect so much from me – but I look like a total Chinese, so there’s no hiding the complete embarrassment of not being able to speak in Mandarin.

To Dong Zong’s credit, they did take it in stride, and our Mandarin-speaking colleague performed admirably (I think, since I did not understand him) and at the end of the two days, we were very well appreciated because somehow between the both of us, we got the job not just done, but done with great feedback and participation from the group. There were some really excellent Q and A time, which I had to answer in English/broken Cantonese and got translated properly. We even had a chance to go through Dong Zong’s implementation of PDPA and did a impromptu, live commentary on the areas to improve in privacy notice and other policies.

For a non-legal, practical way to implement and assess your company on PDPA, please drop us an email at avantedge@pkfmalaysia.com. We have done a lot of practical training on compliance to PDPA, and taken a lot of good info from the PDPA Commission itself. Our content is based on the one we developed with the deputy commissioner of PDPA during the time when we worked together to deliver our training to companies in Cyberjaya. Over the years we have enhanced it with demonstrations, as well as updated with the latest development of Malaysia’s Personal Data Protection Act.

Alienvault Deployment Checklist

avlogo

A while ago we were asked to share an Alienvault Deployment checklist. So here it is (by no means comprehensive but just to give you an idea of what you need to have)

a) All data sources listed and PIC (person in charge ready)

You have no idea how much time is actually wasted getting logs into Alienvault. As I said, as an AV implementer, we have no obligations to sort out why or how to configure data sources to send logs over to our system.

From Alienvault side, easiest way to determine if they are actually sending us stuff:

#tcpdump -Xni eth0 port 514

Assuming eth0 is your logging interface and you are sending using rsyslog. If OSSEC, then it would be 1514. If you don’t get anything, then stuff is not being sent to you.

Invariably we always end up troubleshooting for our client and its always one of these:

– routing issue

– network firewall issue

– host IDS/host firewall problem

b) VM should be set up properly

Sometimes our client expects us to troubleshoot their VMWare setup and install ESXi for them as well. This is not part of our scope of works, but again, when we go onsite, we find out that their VM environment is no where ready and we have to prep it up for them. Usually its either under resourced or not even created. Sometimes we find that they are running on a host machine that belongs in the museum rather than a DC and they insist that its good enough. Umm. 500GB hard disk and 4GB RAM? Come on.

c) IP Addresses allocation

Remember, you need to allocate the appropriate IP addresses

– Host IP address (for the VM host if you are starting scratch)

– Logging interface IP – this is where data sources send logs to

– Management Interface IP – lots of people gets confused with this and thinks this is required. You can use the logging interface as management interface. Unless you have another interface sitting in another management network, I would suggest to use the same interface as management. The problem with setting up two interfaces on the same network is that routing might get screwed up at times.

– Network Monitoring interface IP – you don’t need one. However you need to assign an interface to monitoring if you want to use IDS. By default the management interface is assigned.

d) Installation Key

If you are ready to install, make sure you have the installation key. For setup on CLI you won’t be able to copy and paste so you need to type the whole thing in. True story, we have gone to onsite before and set everything up and when it was time to enter the license key and we looked to the client, they went like “What license key?”

e) All equipment accessible

You would think this is a no-brainer, but you have no idea how many times we tried to install and client tells us, oh, we don’t have any internet access on this box yet. Doh!

f) Technical Checklist

– Before deployment, we should have the inventory list or BOM – how many servers, loggers, sensors and their locations. If its a small setup, then AIOs will do.

– List of network segments to be monitored – ensure span ports are set up and confirm how these are connected to sensors

– Full list of assets to be monitored by Alienvault. We need this and need to be careful. If there are a whole bunch of gateway proxies in that list and you have an AIO running, keep in mind that AIO processes up to 1000 EPS and I have seen proxies bunch together and get a lot more than 1000 EPS.

– Diagram of how AV is setup and distributed across networks. If they are all in the same network, then well and good. Are they traversing the internet to communicate, is VPN required between components?

– HIDS – how many, and how many on Linux and Windows?

– Vulnerability scans – are you running authenticated scans and if so do you have the correct credentials?

– Netflow – how many netflow sources are going to be integrated if you are using netflow?

– File Integrity Monitoring – do you have list of servers and directories/files to monitor?

– Baseline – do you have an idea of what baseline securities are there. For instance, your baseline for normal traffic could be “Access to critical server A is from 7 am to 7 pm Monday to Friday”. Therefore any access out of these hours are abnormal and considered an incident.

In summary, setting up a SIEM (at least for now), isn’t just plug and play and it does all the machine learning it needs to do. Alienvault has threat intelligence to assist in identifying attacks – but for fine tuning and filtering of logs, you would still need to work on it pretty much. But with a checklist in mind, hopefully you start the deployment on the right note.

 

PCI-DSS and the Retailer Conundrum

pci-compliance

Over the past six years, we have had our share of PCI-DSS experiences across different verticals. Unlike other standards, companies each have their own unique PCI journey to compliance, due to the type of business they have in regards to storing, processing and transmitting credit card information.

Payment gateways usually have a challenge in securing stored credit card information. Here we identify the areas and types of storage and the option for securing this data – usually with encryption. The good news is that most payment gateways do not have many physical locations in scope, so we are generally looking at maybe one main site and one DR site, or two at most. This helps significantly.

BPOs or outsourced companies are another animal altogether. These are generally multi site projects, with various types of interactions with credit card information – usually phone, or MOTO (mail order, telephone order).

Banks are probably the top of the food chain in terms of complexity. Not only do they have hundreds of sites which are in scope, they also have storage of card data all over, as well as ATMs in scope in different branches.

Somewhere in between, we have the retailers. Not the e-commerce only retailers but traditional retailers. And here, in this layer of retailers, choke full of credit card and personal information, the hackers ply their trade.

Target (ironically the target of one of the largest information heist in history), Neiman Marcus, Home Depot, PF Chang’s, even Wendy’s – these were all hit with credit card breaches, resulting in millions upon millions of credit card information siphoned off into the jungles of the Dark Web. Why?

In general, hackers view Retailers (and hospitals) as easy targets. One example is where hackers ship a box full of new POS (point of sales) devices to the retailer outlets with a note from the Chief Operating Officer that these are devices to be installed and used from here on due to security or upgrade concerns – and once installed, these POS devices start hijacking credit card information in behalf of the hackers. A similar vector of attack is to infect the POS updates with malware and once the malware (like BlackPOS) is installed, it’s open season.

For the Target case, 40 million credit/debit cards were lost through POS. The reality was that the hackers breached Target’s main network first and accessed the database. Thanks to PCI, their database were encrypted and instead of hacking the keys, the hackers decided to go to the source (the POS devices). If the data in the databases was not encrypted, the damage would have been much, much more (we are looking at 70+ million).

PCI has stringent considerations for the security of POS, including software and hardware checks, as well as physical location checks. This is why retailers going through PCI is facing such a hard time. Some of the main issues are:

a) Retailers are underfitted for security. I am not sure if there is such a word underfitted – but in most cases, budgetary concerns are usually the reason why there is so little investments in security systems for retailers. The focus is on efficient transactions, and often efficiency and security are strange bedfellows. While millions are spent on customer relationship management tools, and systems to predict customer buying habits and big data solution, the backend hardware are outdated – we have seen XP and its variants still going strong in some retailers.

b) Inventory is haphazard. Some retailers grow, and in growing they do not keep stock of their internal inventory of systems. Some customers we go into have a very rudimentary excel sheet dated back to 2009 for their systems inventory, that is inherited several times by different IT administrators who seem to be going in and out of the company.

c) Like b, IT admin staff in retailers generally do not stay long. While some of the have good intentions in implementing certain structures and projects, these get lost along the way as new staff replaces them.

d) Location, location, location. In security, more locations, more problems. We see main branches carrying out good security practices but replicating along 85 branches in the country is a different story. In most attacks, hackers might infiltrate through a smaller branch with less focus on security and less education on preventing breaches.

e) Technical considerations. Most retailers we see have rudimentary effort in securing the network. Perimeter wise, we have seen a conglomerate of firewalls from yesteryears that no longer have any updates – and a plethora of free security software that does not have any auto-updates on signatures and in some cases, are spyware themselves. The network itself is usually flat (because of efficiency) and this brings in a huge amount of scope when your database is next to your ERP and accounting system that is being connected by a 100 of junior staffs with their desktops running XP.

There are many reasons why retailers are now prime target for PCI breaches. How do we avoid these breaches?

Well, you can’t. You can deter, but you cannot fully remove the risk of breaches. PCI helps a lot but as of now, there is no silver bullet to resolve security completely, except to unplug everything and set up a pen and paper store like back in the Wild West. But where PCI comes in – physical location security, POS security, network and database security – these are all critical areas where retailers can start with. Some first steps for retailers:

Set up a proper inventory of systems: In my University in Western Australia, there is a huge engraving on one of the main halls: KNOW THYSELF. We generally use that advice a fair bit especially when we have had a fair bit of alcohol in the Beer Parties, while stumbling back to our dorms. But in order to know what we are up against, we need a proper inventory of what we have and set about securing these systems.

– Secure the perimeter: Firewalls and IDS/IPS are important here to ensure that attacks are sorted out and abnormal traffic behaviour is properly caught.

Segment the network: While Segmenting is not for everyone, the security benefit here is considerable. Databases which are critical systems should not reside on the same network as your junior associate’s desktop, especially one who spends half his/her time downloading music or watching youtube. An analogy here is simple: when you put a healthy person in a room with a sick person, the sick person doesn’t get well, the healthy person gets sick.

–  Eyes on everything: We can’t iterate enough how important monitoring is in retailers. A good security information and event monitoring (SIEM) system is KEY to their security. Because of the lack of security personnel, the SIEM takes away a lot of these manual responsibility in tracking down strange and abnormal events. If a SIEM was set up properly in the Target case, they would have realised that one of their printer spooler device was sending out FTP packets out from the network into another system in the internet.

– Test, test and retest: Test your systems for vulnerabilities. You don’t need to spend truckloads on penetration testing if you don’t want to. Scanning using a Nessus scanner or even OpenVas will be useful as a first step. If a system is not patched, patch it. If you are still using Windows XP, seriously consider upgrading it.

– Finally, educate the users: While this has become a mantra for consultants and trainers, it’s still true. The weakest link in the security killchain is between the keyboard and chair. That’s the person. Security awareness training is key. While firewalls, email filters and Intrusion detection systems can go a long way, the security infrastructure is compromised by one executive clicking on an email attachment with the word: “Watch this Cat play the piano!”. Boom. Welcome malware, welcome ransomware, welcome sleepless nights for IT.

In summary, PCI-DSS establishes good and practical security practices for retailers. It might not be cheap, but once you have been hit by a ransomware or have your data pilfered, the fallout costs would be even more significant. For retailers looking to start off your PCI journey, or who need assistance on your ongoing one, please email us at pcidss@pkfmalaysia.com and we will get back to you immediately.

The Long Road of PCI Recertification

pci-compliance

We have been in PCI-DSS for six years.

When we began back in 2010, we were tasked by one of our offshore customers in Brunei to get them “PCI” certified. Honestly, back then, early 2010, we were mainly doing IT audits under COBIT, a lot of penetration testing, some IT forensics and bogged down with piles of ISO27001 ISMS opportunities.Back then PCI was more known as Peripheral Card Interconnect, which are those add-on cards that you slot into your motherboard back in the days when you wanted to extend your network interfaces, graphics accelerators etc. I used to build computers in those dodgy computer shops back in the days, so I kind know that very well.

Fast forward six years, and now we are getting more and more queries for PCI-DSS. So much so that we have dedicated an entire team from our company to work only on PCI-DSS projects.

In earlier years, we brought our PCI clients through their first year certification, and many of them are now going through their 2nd, 3rd year recertification etc.You would think that most companies will find re-certification easy compared to the first time certification.

Don’t be fooled.

The thing about PCI is, during the re-certification, there is a lot more expectations on your organisation for compliance. An example – PCI requires logs to be retained 3 months online, 12 months offline. It also requires daily log reviews, as well as quarterly internal and external vulnerability scans.

Now for the first time certification, some of these requirements get a free pass: meaning, if our client had just installed a SIEM and only has 2 – 3 months logging set up, we verify those controls and based on those controls, we can pass their PCI. We don’t need to wait for 12 months to get the offline requirement passed. Likewise, if our client provides us with one internal and external scan, we can pass them for first time, we do not need a 4 quarterly scan before we sign off on the initial AoC.

However – once the re-certification arrives, these become MUSTs. Some of our clients want to undertake internal scans themselves and missed one quarter and expects us to still pass them. Or they have a SIEM, but no action done on daily reviews, or their SIEM was not set up properly and no logs were sent there. They get upset when we say we can’t pass them on those basis because their response was “We did this last year!”

Also, evidences.

Whenever we conduct our audits, we conduct it onsite. Onsite, the QSA will verify these controls if they are in place or not. On top of that, we require audit evidences. This is normal even out of PCI – in our governance audit or ITGC we often rely on audit artefacts (we call it), to supplement our opinion on whether certain controls are in place. In PCI, these evidences might come in forms of documents, policies, screenshots, configs etc – anything that can prove controls are in place, and effective, and accordingly used as per PCI requirements.

The onsite audit confirms these controls. The evidences supplement the QA process. Each QSA needs to go through a stringent QA (quality assurance) process internally, whereby, the QA requires supplementary evidences to prove why the QSA arrives to such and such an opinion. Therefore,  there is always that post-audit work of compiling audit evidences.

Some clients are of the opinion that the onsite audit should end the process and the auditor passes PCI then and there. Unfortunately it’s not so simple as there is a check and balance involved. An example is this: one of our clients recently added in a few out of scope devices into the CDE. During the onsite audit, we referred these and requested these systems removed or resettled in another segment. They said, OK, we will put it in another VLAN. So, if they do that, is that ok? We said OK.

Fast forward to the post-audit work, we asked “Hey, have you done your VLAN yet?”

“Yes, we have. Can you pass us?”

“OK, can you give a screenshot of the new configuration in your firewall or switch to prove that you have done this action?”

“WHAT??! Why??!”

You see – as auditors, we simply cannot trust you for your word. It’s not personal. It’s not that because we find you are a shifty trader looking to spin some yarn and fleece us of our money. It’s simply because it’s part of our job. Evidences provide us with some measure of assurance that these controls are done correctly and in place. It’s not that we question your integrity. It’s strange that even at this stage, many people find this difficult to accept, and we have gone through many, many strange situations whereby I have faced a red-faced, yelling executive thinking that I am personally insulting him and his family name by not trusting what he is saying.

Audit evidences. It’s part of PCI.

There are of course some exceptions, such as certain private and confidential documents or config that cannot be shared – even in that case, we generally ask these information to be anonymized, but evidences to be submitted all the same: for instance, evidence of VLAN config, you can screenshot the config, and remove elements deemed sensitive (IP Address, versions, other information etc).

In summary – the second year onwards, this is where the real PCI battles begin. Your recertification efforts will be a whole lot more than the first time, so get started early. We will be posting more articles on tips and actions that will make your PCI certification successful.

In the meantime, drop us a note at pcidss@pkfmalaysia.com and we will attend to any queries you have.

The Obfuscation of PCI Standards

pci-compliance

When you go through the PCI-DSS standard, while in most part, the sections are clear, there are some that just annoys the heck out of me, for good reasons.

Stateful inspection and Anti-spoofing in firewalls – I know these are useful features, but it is extremely rare these days to encounter clients going for PCI-DSS that own firewalls without these capabilities inbuilt. Even the humble ScreenOS running on your tiny SGs (Juniper) are enabled by default. While this isn’t an issue, we’ve faced vexing times when our clients are sometimes asked by their QSA, to show the firewall rules that prove that Stateful inspection and anti-spoofing is turned on. We have to come in and explain to them that its already enabled by default, and they insist on us testing and showing them traffic captures. Sometimes, I just show them the manual and entitle my email “RTFM: Stateful Inspection was first introduced in 1994.” You would think that PCI would do something better than to ask this question.

AntiVirus and AntiMalware – the researchers at Imperva, a couple of years back, did a study of effectiveness of antiviruses.They collected 82 new computer viruses and ran the malware against antiviruses from some of the largest companies like Symantec, Kaspersky, McAfee. The results: initial threat detection rate was 5 percent. That’s detection. This means 95% of malware is undetected. I don’t know how strong this hypothesis is, but frankly, we have known for years antiviruses, while there are limited uses, presents to us a false sense of security. Just because the antivirus says, “ALL IS SECURED” doesn’t really mean anything. The annoyance here is not that PCI has antivirus as part of their controls, they dedicated an entire requirement to it. It’s not effective – move on!

Confusion of application testing – Requirement 6.6 states:

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

b) Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

Now, we need to clarify this because this is obfuscation. Note the nice caveat they put into 11.2. Now, if you go to 11.2, you get a whole bunch of requirements for vulnerability scans, quarterly ASV etc.This is understood, right

So the above, you would surmise this: if I have a WAF (web application firewall), I do not need to do any web applications review, correct? What IS a web application review anyway? In a lot of instance, QSA will interpret it as web application testing, covering OWASP top 10. In pentest world this is called WEB APP PENTEST. This tests issues like cross site scripting, validation etc. You can find more here

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

A web app PT can set you back around RM10 – 25K depending on your web app and the provider. I’ve seen web applications go into the RM50 – 80K regions before for massive applications, but in general for a web application payment system, you would get that range (unless the provider is looking to rip you off, in which case I suggest you give us a buzz).

So if you have 10 – 20 Web App, that would set you back a mile, so the suggestion is to “Let’s invest in WAF”, where you pay a license and every year you don’t have that WEB APPLICATION testing headache siting on your books. In the long run, it makes more sense if you have a lot of web applications to test.

Now, here is the PCI problem.

Requirement 11.3 – Implement a methodology for penetration testing that includes the following:

blah blah blah

 – Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

Unfortunately the presence of 11.3 renders the earlier requirement choice useless, because now QSA interprets at despite having invested in WAF, they are still insisting on getting 11.3 passed, which requires this application layer PT!

My question to the PCI-SSC, why don’t you include this 11.3 caveat in the earlier 6.6 requirement instead of the useless 11.2 caveat which anyone knows how to read? And if my interpretation is wrong, I am going to war against some of these QSAs because they basically said, it’s nice to have WAF, but you still need to do App PT. In fact, one of them actually said: “Well, the advantage is that you are more secure.” Yes – but our client’s goal was to pass PCI. If they wanted financial modelling and investment advise from you, they would ask it, if not, just do our job and interpret the standards properly! Will someone from PCI-SSC actually clarify this because I’ve talked to some QSAs on either side of this opinion – some say WAF OR APP PT, some say, APP PT regardless of WAF.

To be safe – get your QSA to interpret this before making a decision to invest in WAF, because this is a major roadblock in a lot of cases we are in.

« Older posts Newer posts »

© 2025 PKF AvantEdge

Up ↑