Forum Moderators: phranque
Passed two quarterly scans without a problem.
A new threat came up involving WebDAV which is a IIS problem. We're on Linux.
No problem, I figured out why and it was NOT a security issue, it had to do with the server headers. Basically if they sent a WebDAV attack string and it didn't return a 404, it "assumed" it was vulnerable. Pretty stupid that a security threat was positive based on a server header.
So we run another scan and it comes back with a blind SQL vulnerability . . . AGAIN. All input is filtered, no SQL strings reach the database.
However the script they are pointing it at, by default, displays all results if no search term is entered. So what I am guessing is happening is
- Attack string is entered in query string
- script kills it all, leaving "no input"
- Having no input, the script returns all results
- Scanner presumes because it's getting a result, it's a threat
To be fair the SM support is very helpful in assisting with things we can't figure out on my own, but I'm posting this because I'm *really* beginning to question the validity of the scans. See the first example - we're not even running WebDAV, but because the site returned a 200 OK when a webDAV attack string was thrown at it, it failed the scan.
So is anyone else seeing indications of false positives, that maybe . . . Security Metrics is not as accurate as it should be?
Or is the only way to beat these to just exit and throw a forbidden header for all malicious input? Currently it's just cleansing it.
It's like kicking the tires of a car and if they are flat, well, this means the head gasket is blown.
The 'questionnaire' portion I 'delegated' to the owner, so that I wouldn't be the one that lied, lied, and lied some more:)) If ever deposed I didn't make the statements.
As far as the scans, the owner is in love with one of the worst hosts one could possibly hook up with. It almost always failed horribly - and deservedly. I temporarily got us into actual full compliance (briefly), but the amount of energy/money wasted because of the owner his and host love affair was really bad for my morale.
My experience with the Security Metrics techs was always very positive and 'scam' is way too strong for me. If it is a scam, it is the bank's extra CYA to make sure that if anything happens that it is your fault and responsibility - which they are going to do you anyway. That's most of the point of this. SM is simply providing the service and, (last I dealt with them) very reputably.
There were items that flagged as false positive - that were demonstrated as such, and Security Metrics manually overrode the scan and manually okayed the flagged threat. They were always very good about working with me - and I tried hard to work with them.
It was my experience (because our servers also had genuine, serious, vulnerabilities) that SM would absolutely not sign off on items that really needed proper patches and updates - and they were right not to do so.
If you've established a rapport with anybody over there, I would think that you should be able to get an override because you have the technical skills and communication skills to 'work it out with them' on the non--issue issues. They know there stuff; though it has been a year since I have been involved with that company/situation.
BTW - The volume of business that you do makes a big difference, as does your reputation. We were severely out of compliance due to major security holes for months at a time for several years. In our situation, at under a million dollars a year, and extremely low fraud rate - nobody cared because there was no problem. It was entirely a bank CYA scam. SM did not report anything to the bank. We were required to be in compliance at all times - but were rarely in compliance at all. The bank's merchant account division had 'access' to anything they wanted from SM as far as reports and scans - but no fraud issues - no interest. No reports were ever forwarded or otherwise flagged for attention.
........................
My own current merchant account (with another bank) hires out a scan of our sites before allowing the merchant account to open for any new one. I have to got through the same hassle with every website. Not that big a deal, except that they always find something ridiculous that doesn't need fixing. My hosts are not Grade A (can't afford Rackspace), but grade B, so they tell me what the want, I tell the tech people what they want, and that's that.
The only thing that really upsets me is that on every website I use with this bank (technically a separate merchant account for each, but I can tie a whole slew together and run them through all through the 'parent company' and bank accounts) is that they require my users to physically check a box accepting my "Return and Refund Policy" during the checkout process. Our policy is clear and prominent on every website; easy to find. I do not want my users having to check the this box during the checkout process and I just want to scream. Had to go through a lot of hassle to get it set up to work, to not lose customers for a no good reason extra step..... But it was a take it or leave it condition. Once in while I thing about taking that thing out of one site or another - but I've got a very good deal on my accounts and don't need to get caught over something that I just have to make the best of - for myself and my customers.
We'd been working closely with SM and as said their support was helpful, but have not received a response on this last one . . . hoping I didn't hit a nerve. But it's like you say, this client is down the food chain a bit . . .
I never agreed to SM and told FD I use Mcafee, an approved vendor. SM continues to scan our site and we are deemed non-compliant due to the fact that our firewall does not allow SM into the site? Well that is what I want! So after many months with FD we finally get all our fines refunded and they agree that mcafee is fine.
Now, after months and months FD comes back and says "your questionairre is incorrect, you need to submit SAQ-D ... ummmm, no I dont! I am now fighting back on that one.
PCI, from the merchants standpoint, isnt a CYA I think it is a money maker. They know that many (most?) merchants have no clue and will willingly pay the $19.99 monthly fine. Only after we fight, and fight vigorously, do we get that refunded.
We scan secure with Mcafee .. occasional threats, we patch and rescan immediately.
from the merchants standpoint
This doesn't really count for much. If the merchant account provider has requirements, they don't have to be flexible, and, in my experience, the policy is the policy. Usually a take it or leave deal.
As referenced above, my experience with SM was always very positive and professional. However, I was also diligent and built a relationship as being somebody that wanted to be easy to work with. Our issues were not with getting irrelevant issues passed or manually okayed - but with the owner of the company that I was working for, his choice of host, and the complete lack of interest of both in maintaining a secure environment. We had real issues that deserved to fail and SM rightfully did not sign off.
Yes, the owner paid his quarterly fee for the service - and didn't learn anything.
The merchant account provider that I use for my websites (the merchant account arm of my bank) is pretty strict about getting a site setup correctly, but they handle the scans themselves or hire it out. They usually need a few minor adjustments, but then I'm set. No fees at all, just a part of the process of setting up a new merchant account. Every website has its own account and its own discount rate, keyed to average ticket.
No setup fees, no quarterly fees, no BS - and I'm getting a great deal. The company that I referenced does ten times the dollar volume but I have a better rate, better terms, and no real PCI compliance hassles.
Rating hosts/servers from A to F, I am with B grade hosts (because the Rackspaces are simply beyond what I can justify spending at this time), so most potential issues never arise, and they are very responsive to anything that I need. I spend a lot of money on my hostng/servers but live an easier life. Outside of big volume, big dollar companies, the average merchant, in my experience, is with a D grade host and deserves/needs the hassles that they get. I don't do much work outside of my own projects right now, but this was almost always the case when I did. Owners don't like to pay for solid, high quality hosting, and it is shocking how cheap some companies are with this mission critical decision; companies that are doing plenty of volume to solve/prevent major security issues with modest (but not cheap) investment. If it works and they haven't experienced trouble/crisis - they just do not care - which is why the rest of us get hassled on every trivial little point.
Good hosting/server setup and a good relationship with my bank - priceless.
Our "support guy" was gone for a week, then when he returned he said will first, re-scan it and see if it's still there. A scan takes over 2 hours and I just don't have a lot of time these days.
So, using my previous example, I thought, well let's try this. Instead of just cleansing the data and carrying on normally,
input ->
cleanse data = no input ->
if no input display all results
I set it to print a 403 (forbidden) and exit if any malicious input is found.
Passed the scan.
I'm not knocking SM here, or the importance of such a service, but I do question their methods. If you can "cheat" a scan by simply outputting different headers, or the existence of a particular threat relies on a header response, it's no indication of the security - or lack of it - of a server.
In my travels on this issue I found another workaround. There are vulnerable PHP versions, if found, it adds to your risk score. One workaround I found was to edit the PHP configuration so it broadcasts a different PHP version to get around this.
It's a bit like the search engines, it appears to be often inaccurate and can be gamed.
