Category: Penetration Testing (Page 2 of 2)

IPAY88 is now PCI-DSS Level 1 Certified

ipaylogo

Congratulations to IPAY88 for getting certified under PCI-DSS Level 1!

The PCI journey had been an interesting one. We did the gap assessment back in late 2013 and had to chase the compliance for 2014. The major roadblock was that first time PCI-DSS companies often underestimate the amount of work and type of audit required. A lot of companies make the mistake of treating PCI as how they treat ISO27001 (ISMS). These are vastly different animals.

For ISO27001, in general,  a lot of risks can be justified by management. The idea is to sense that there is a ‘management system’ in place. Not so much of a standard. If the management system claims that counting lima beans for customers in their data centre is an acceptable risk, then it is an acceptable risk. Of course, that’s an extreme example – the ISMS auditor still have a say in that obviously.

However, for PCI-DSS, its 300+ controls, in which if you decide that you want to store credit card data, then all of which will apply to you. There is no “Wait, my management accepts the risk of non encryption and storing PAN in a text file.”.

Precisely, the data here is not the company’s. It belongs to the card brands. From PCI perspective, its a standard that benefits only the card brands – VISA, Mastercard, Amex, Discover and JCB. This is the reason why we don’t have Business Continuity in PCI. PCI does not care whether your business can continue or not, it just cares that the credit card data is safe.

To IPAY88’s credit, they adjusted very quickly. They called us in midway into their remediation and we did a sweep of their infrastructure again and started to put their remediation program in place. Policies and procedures is one thing – but you have a whole lot of other things to do as well – penetration test, VA, firewall reviews, training, risk assessments, log reviews, HR review etc. We chased those down within 2 months and managed to hit the onsite audit in October, and successfully navigated the compliance by December.

A special thanks to IPAY88 management and PCI team for such a collaborative and great experience together! For more information of our PCI-DSS program, please email us at pcidss@pkfmalaysia.com.

Penetration Testing: What to Expect?

After a relatively quiet 2012 on the penetration testing (PenTest) front, we’ve got quite a number of requests on our penetration testing services in the first month. A lot of clients we speak to don’t really have an idea of what a penetration testing exercise should be. Many of them expect us to do stress testing, load testing and basically all the scope that a QA/QC group should be doing for their software development. We do that as well, but that’s slightly different from a penetration test. Slightly here means, related, but with different objectives. Some pentest scope does have stress test elements, such as breaking the system with DDOS. In other words, the objective is to expose weaknesses and vulnerabilities, as well as to create exploitations, either through a conceptual or practical standpoint on these vulnerabilities.

The first thing to do is to define the objectives and scope. Most companies we’ve dealt with prefers a quick assessment to see immediate weaknesses. While there is nothing wrong with this, as pentesters, we must make our clients realise that this is simply a snapshot vulnerability and it’s not a catch-all. Scoping is usually done with a meeting with the business owners. IT infrastructure can be very large and complex. To pentest the entire infrastructure is obviously not practical, so we need to define a narrower scope based on risks and sensitivity of data. It’s a lot like our IT audits. We establish our audit universe and our incoming points, and then run our pentest exercise against it. Another scope is to establish the type of pentest. We’ve done pentest emulating disgruntled employee with authorised access looking to escalate privileges or remove data. We’ve simulated as script kiddies aiming for a take down on resources and DOS attacks. We’ve simulated concentrated attacks on a group of IP addresses, utilising OSSTMM methodology. Recently we just completed an OWASP Top Ten Web app penetration testing. We’ve had another where multiple attack vectors were looked into, such as HR weaknesses, process weaknesses and a vulnerable FTP server where other attacks can be launched from.

Mostly, the scope will be determined by cost and time. Due to the non-regulated world we live in, most companies won’t want to spend too much on a penetration testing exercise. This is unfortunate, because usually, only after we give our presentation of report, do people realise, “Man, we have all these problems??”

Another point is to define the rules of engagement. Unlike other engagements, penetration test is high risk. It’s controlled, but it’s still simulating an attack. In many apps we’ve tested, we’ve found that they have NEVER gone through any QA/QC testing in the first place. In one engagement, our benign scan brought down the whole HA cluster. Luckily, our Rules of Engagement was already in place, to do testing in a non-peak hour and had a standby team, and we brought back up the systems with no significant impact. Still, it highlights the criticality of treating the pentest exercise with utmost seriousness. We cannot determine how systems will react to our exercise 100%, but we can draw boundaries. For instance, in one project, we were only allowed to create a benign file to demonstrate compromised access. In another, we were permitted to put in a keylog software to demonstrate the ineffectiveness of both host controls and network controls. Most of all COMMUNICATION is the most important thing. We are not a bunch of dark-cloaked hackers out to destroy our client’s credibility. We inform our clients on progress daily, and in some instance, as we go through a critical exercise, step by step, through Skype of Gtalk. The client must feel secure and the only way is through properly diseminated information.

I spoke to a client before who had hired someone from the net to do a pentest. Not only was the pentest successful, but he suspects some data was even taken. Because there was no communication or rules of engagement, he couldn’t get a proper report out and because he did not know what has been compromised, he had to completely change his security passwords and such.

We’re not saying we’re the best in the world. We’re saying that in whatever we do, our best interest must be the client’s best interest. As a company, there is absolutely very little benefit in us destroying our reputation by doing a shoddy job or stealing information, and putting our business at risk.

If you want to know more about what we do, drop us a line at avantedge@pkfmalaysia.com and we will get one of our consultants to get back to you directly.

In the meantime, here’s to a great 2013 ahead to all!

 

Stopping Insider Scans

I’ll admit it. I’ve knocked on doors before, while sitting at Starbucks.

“Knocking on doors” here means running port scanners like Nmap, or vulnerability scanners like Nessus or Nexpose, to see if that guy in the suit across the room is using a laptop that’s vulnerable to exploits. I was much younger then. WiFi was just introduced, and to a guy born with a curious mind like mine, this was exciting stuff. I wasn’t a hacker or cracker by any means, neither did I dwell too much in doing malicious scripts, but it was just curiosity that got me going.

I did find myself on the good side of the law soon, running DHL’s global security group in Asia, and there faced monumental challenges like random denial of services,and naughty scans from external.

However, it is usually the insiders that do us in.

I’m sure you heard before, a secured perimeter is only as strong as its weakest link. And the weakest link is usually inside. A disgruntled employee. A corporate spy. A curious, idle employee with too much time on his hands, and reading too much Network Security Online articles. Whatever the case, every company will have its day in the sun. It’s just a matter of when.

For instance, we ran our penetration testing services for a network. We usually don’t have too much issues in the scanning phase, where we enumerate services and probe a little for vulnerabilities. Our standard process was to inform our client when we were doing exploits. One thing we’ve learnt in almost every project we’ve done.

Not everything goes according to plan.

It was an internal penetration testing, but we weren’t given much details on the network or servers as agreed and we ran several IPs scan at once. Soon, our technical client came back to inform that their servers were not doing too well, and one of the virtual servers running HA has rebooted. We immediately stopped the scans and realised that the IPs given were all running on VM. Nessus and VM does not play nice. Do a search on nessus on communities.vmware.com and pick your poison.

Thankfully, nothing serious occurred, which shows us again how important it was to have people ready and standby especially in PenTest and to follow certain set procedures and standards. We continued the pentest exercise with greater care, taking into account the vulnerabilities of Nessus and VM, and using alternative scanners.

Which shows, how simple it is for someone to DOS (Denial of Service) a network, with just a vanilla Nessus running. What can a company do about it?

Well several options are there:

1) IPS/IDS (Intrusion Prevention/Detection System). These babies usually run on the network points and works wonders to detect scans and stop them, among other thing. We used to run Tipping Point a lot in my previous companies. The problem here is that for a flat network, how do we want to run this? The server needs to be segregated into its own server segment, and an IPS laid out in front of the network point. In a flat network where everything is plugged into a single IP address space, it still can be done, I suppose, but probably not the best way.

2) HIPS/HIDS (Host IPS/IDS). It’s like a mini gun compared to a gatling gun. It runs on critical servers and works about the same way, except that the network interface gets hit before the intrusion prevention services kicks in. It’s pretty effective and we ran a lot of Symantec previously.

3) If those don’t do the trick, then we could probably secure every end point. If we want to secure internal attacks, the best way is to properly guard your asset. Control all your laptops through proper asset management, no administrative capability to install Nessus and an asset scan to ensure nothing naughty has been somehow installed on by enterprising employees. You might want to control/choke up the USB ports as well.

4) Finally, set corporate policies. Many companies fail to do this and we don’t know why. Document what will happen if activities like scanning is done. Make sure employees understand their obligations to the company and sign acceptable use policies before giving them corporate-owned assets, bought by corporate owned money. Sometimes a little awareness works better at prevention.

There are probably other ways I’ve missed out, but generally this would be how we’d deal with idle employees with too much time on their hands scanning our network. That, and putting them on a cold-storage project to wash out their curiosity, maybe.

Newer posts »

© 2021 PKF AvantEdge

Up ↑