The pen test we do through Nessus is passive, our goal is to identify and report the vulnerabilities we find and allow you to close the holes and harden your systems. A majority of vendors find passive pen test results sufficient but some require active pen test results. We don’t do active pen testing because of the risk and liabilities involved. – Recent Communication From A Security Vendor
Who shall remain nameless. There is a difference between penetration tests and security vulnerability scans. The two do not meet. Neither does an admission of a passive pen test or an annual security vulnerability scan being acceptable to the majority. I’ve never heard those words in the same sentence.
This kind of misinformation to score the deal is ugly. Not only is it a risk to the organization writing the check, but it’s your reputation on the line for signing the deal. Only good security people will see through this…
“As Albert Einstein is often quoted as saying, ‘If I had 20 days to solve a problem, I would spend 19 days to define it.’ So the first question you need to be asking is, ‘are you asking the right questions’? – 137 Security Questions Every Leader Should Ask. (2013, September 9). In SecurityIntelligence
As we finish up our SOC2 audit, these security questions run concurrent with everything we do as a security practice and a security leader. This is one of those articles I refresh upon every now again because it’s exactly on message.
Check the link: https://securityintelligence.com/137-security-questions-every-leader-should-ask/
There are no laws preventing a bank or credit union of using the SS# as a bank ID. (The government remved the verbiage indicating that the SS# cannot be used as identification sometime in the 70’s.) It is just a bad idea… for a few reasons, based on a conversation I was in with legal experts. Here are those notes:
1) It is considered personal identifiable information (PII). PII could include:
- Name: full name, maiden name, mother’s maiden name or alias
- Personal identification numbers: social security number (SSN), passport number, driver’s license number, taxpayer identification number, patient identification number, financial account number or credit card number
- Personal address information: street address or email address
- Personal telephone numbers
- Personal characteristics: photographic images (particularly of face or other identifying characteristics), fingerprints, or handwriting
- Biometric data: retina scans, voice signatures, or facial geometry
- Information identifying personally owned property: VIN number or title number
- Asset information: Internet Protocol (IP) or Media Access Control (MAC) addresses that consistently link to a particular person
Using the SS# as the customer identifier makes this information more accessible to contractors, vendors, and others that require access to the account but not the PII. (Thin about how you are accessing your bill payment vendor. You will be passing the customer identification number. Hence you are now providing a SS# to a third party vendor.)
2) Speaking of third party vendors…you must consider how they use the customer identification number. Fiserv sometimes embeds the ID in the transaction number. Now the SS# is exposed elsewhere. I have seen other payments transfer vendors do similar things. Customers get a little sensitive about this sort of thing.
3) You now have the SS# is two places on your system. While you may contain your PII differently, the customer number is generally not considered PII. You will be forced to consider this with every interaction – printed reports, statements, etc.
4) It’s not unique, and its not even a very good identifier. The most infamous case of that was 078-05-1120, which was used on a sample Social Security card by a wallet manufacturer. At one point, more than 5,700 people were using that number as their SSN.