It's been a while since my last post. I hope to start posting somewhat regularly again in the near future. It's been a madhouse around here as we have been building a new data center from scratch; new hardware, more hardware, new O/S, more memory, new software, new, new, more, more, better-stronger-faster everything, etc., etc. In the last few weeks we've been migrating various services and customers to it; throw in our annual PCI audit and presto -- no time. You'll hear more about this entire project in the next few weeks. For now, suffice it to say it's been a busy time.
Over the years I have posted on several forums my belief that no operating system is inherently secure simply because it is not Windows. Many anti-Windows zealots tout that Linux or Mac or whatever is much more secure based on the number of reported hacks and vulnerabilities: "Hey, simply look at the number to prove my point." And this argument always has a reference to some vulnerability report showing Windows (some big number), their O/S of choice (some little number). I always point out a very similar report showing market share: Windows (some big number), their O/S of choice (some little number). My argument is that hackers go to where the money is -- the market leader.
Well an interesting read that just came out the other day: Coming soon to a Mac near you -- serious malware. When I read this article I had to check back to the author a few times to make sure it was not me as an alias. Give it a read if you have some time.
Tuesday, May 3, 2011
Monday, February 14, 2011
From Europe with Love
The Peoples Republic of California is looking more and more like Europe everyday. In case you missed it: California retailers can't ask patrons for ZIP Codes, court rules.
In reading the story, the courts ruling seems like a noble one -- protect consumer privacy. But I feel this blanket decision totally ignores the rates merchants are charged processing these transaction with vs. without address verification information and all but ignores the security aspect for merchants requiring a ZIP code. To me, a ruling that merchants could not use any information associated with the processing of the payment for marketing or purposes, then it would have been fine. When I saw the headline, it was screaming: "CALIFORNIA WELCOMES ALL SCAMMERS AND FRAUDSTERS WITH OPEN ARMS!"
As to the rate difference, California card-present merchants will need to decide what to do in the event a card cannot be swiped: Don't ask for the ZIP code and accept the higher cost and higher potential for a fraudulent transaction OR ask for another form of payment. My advice with be the latter, but this may not be the optimum advice for all merchants.
The court touched on the security aspect, but it does leave a big hole: "....allows ZIP Codes to be collected under certain circumstances, such as at gas station pumps where the information is requested for security reasons..." -- why wouldn't all merchants fall under this "certain circumstance?"
And then the biggest little line in the entire story: "The court said retailers may still ask consumers to produce a driver's license for identification purposes but may not record the personal information on it." This advice from the courts goes against most (maybe all) merchant agreements. I'm not sure if this was a simple oversight by the courts showing lack of knowledge in payment processing regulations, or if this was an intentional warning shot over the bow of the card brands?
In reading the story, the courts ruling seems like a noble one -- protect consumer privacy. But I feel this blanket decision totally ignores the rates merchants are charged processing these transaction with vs. without address verification information and all but ignores the security aspect for merchants requiring a ZIP code. To me, a ruling that merchants could not use any information associated with the processing of the payment for marketing or purposes, then it would have been fine. When I saw the headline, it was screaming: "CALIFORNIA WELCOMES ALL SCAMMERS AND FRAUDSTERS WITH OPEN ARMS!"
As to the rate difference, California card-present merchants will need to decide what to do in the event a card cannot be swiped: Don't ask for the ZIP code and accept the higher cost and higher potential for a fraudulent transaction OR ask for another form of payment. My advice with be the latter, but this may not be the optimum advice for all merchants.
The court touched on the security aspect, but it does leave a big hole: "....allows ZIP Codes to be collected under certain circumstances, such as at gas station pumps where the information is requested for security reasons..." -- why wouldn't all merchants fall under this "certain circumstance?"
And then the biggest little line in the entire story: "The court said retailers may still ask consumers to produce a driver's license for identification purposes but may not record the personal information on it." This advice from the courts goes against most (maybe all) merchant agreements. I'm not sure if this was a simple oversight by the courts showing lack of knowledge in payment processing regulations, or if this was an intentional warning shot over the bow of the card brands?
Wednesday, February 9, 2011
Forced Password Changes - good or bad?
For years now there has been a debate in the security community as to whether or not users should be forced to change password at regular intervals and if so, how often. On one side there is the argument that changing passwords frequently makes it harder for hackers to acquire a users password and limits the exposure if a hacker were to acquire a user's password. On the other side you have the argument that forcing users to change password increases the chances for forgotten passwords and more dangerous, the chance that users will write down passwords on paper or post-it notes stuck to their monitor or under their keyboard.
I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.
A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:
The 2005 OWASP best practice included the following:
The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:
But, these notes appear to have limitations, in the case of PCI DSS:
So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.
I welcome your thoughts.
I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.
A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:
“PCI DSS 8.5.9 Change user passwords at least every 90 days.
- 8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.
- 8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”
The 2005 OWASP best practice included the following:
“Passwords are trivially broken and are unsuitable for high value systems. Therefore, ...
This tells me that in 2005 the OWASP people were leaning to the side of the first argument. Now, the latest 2010 OWASP states:- Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.”
“Password Guidelines...
While “frequently” is somewhat vague, I interpret this as OWASP is leaning toward the latter argument now.- Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely...”
The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:
“However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.”
But, these notes appear to have limitations, in the case of PCI DSS:
“The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published...”
and in PA-DSS:
“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”
and in PA-DSS:
“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”
So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.
I welcome your thoughts.
Wednesday, December 15, 2010
Beware your inbox!
I just received the following highly sophisticated virus in my inbox:
Added humor: The originator is so techno challenged that they can't even spell technologically. Then again, maybe this was planned by the originator to make us think he was technologically challenged -- clever...
DEAR RECEIVER,
You have just received a Taliban virus. Since we are not so technologicaly advanced in Afghanistan, this is a MANUAL virus. Please delete all the files on your hard disk yourself and send this mail to everyone you know.
Thank you very much for helping us.
Thanks & Regards
Miss Helen
You have just received a Taliban virus. Since we are not so technologicaly advanced in Afghanistan, this is a MANUAL virus. Please delete all the files on your hard disk yourself and send this mail to everyone you know.
Thank you very much for helping us.
Thanks & Regards
Miss Helen
Added humor: The originator is so techno challenged that they can't even spell technologically. Then again, maybe this was planned by the originator to make us think he was technologically challenged -- clever...
Wednesday, November 10, 2010
Is Disco making a comeback?
I certainly hope not. But there are a few in the payments and POS industries attempting to bring back those glory days of the 80's, when Disco the dance and disco (as in abruptly disconnected) dialup terminals were all the rage. Since my blog primarily focuses on payments and POS related tidbits, I'll leave the return of Disco, as in the dance, to social bloggers.
Let's take a quick tour in history: I remember the 80's, the days when Tranz-330 was stat-of-the-art. The Tranz-380 was the future and bankers and ISOs were giddy -- the sky was the limit, no merchant was too big. (Yes, there were other terminal manufactures at the time, but my experience is in the US marketplace and Tranz represented probably about 80% of the marketplace, quite possibly more.) Then along comes the dreaded 90's, when POS integration corrupts this terminal Utopia. Then the turn of the century when hackers start corrupting the reputation of the POS integration market. To fix this, Visa launches CISP, MasterCard launches SDP, AMEX and Discover launch their programs (sorry, I'm drawing a blank on their acronyms). A few years later, along comes PCI to combine all these programs into a single program and now you're up to date (albeit Cleft Notes of a Reader's Digest version of the payments history).
Of late I have seen POS vendors and ISO's recommending to merchants to abandon integration and install dial-up terminals -- back to the 80's. Some assume that this route removes the merchant from the burdens of PCI compliance. This could not be farther from the truth. All merchants must comply with PCI DSS if they process, transmit or store credit card data -- via terminal or otherwise. My guess is that this misassumption stems from some PCI wording that excludes stand-alone terminals from specific portions of PCI. But it never excluded the merchant from PCI.
Some argue that these devices are not susceptible to viruses, keyboard loggers, Trojans, or other malware -- I argue they are. Malware requires a CPU, an operating system, and communication ports and stand-alone CC terminals have all these requirements. So far the only thing saving these devices from the headlines is the lack of a deviant programmer with nothing better to do from writing some malware.
Enough on malware, the scariest vulnerability with this retro alternative is that most (all that I'm aware of) dial-up modem traffic from these devices to the processor is unencrypted. Insert a sniffer in the mix or update a phone number in the terminal, and the hacker has free flowing unencrypted payment information. To me, a properly secured network transmitting encrypted card information to the processor is less vulnerable to hackers than a dial-up device transmitting unencrypted card information to the same processor (and I totally ignored the other cons of returning to the 80's and using a non-integrated solution).
Let's take a quick tour in history: I remember the 80's, the days when Tranz-330 was stat-of-the-art. The Tranz-380 was the future and bankers and ISOs were giddy -- the sky was the limit, no merchant was too big. (Yes, there were other terminal manufactures at the time, but my experience is in the US marketplace and Tranz represented probably about 80% of the marketplace, quite possibly more.) Then along comes the dreaded 90's, when POS integration corrupts this terminal Utopia. Then the turn of the century when hackers start corrupting the reputation of the POS integration market. To fix this, Visa launches CISP, MasterCard launches SDP, AMEX and Discover launch their programs (sorry, I'm drawing a blank on their acronyms). A few years later, along comes PCI to combine all these programs into a single program and now you're up to date (albeit Cleft Notes of a Reader's Digest version of the payments history).
Of late I have seen POS vendors and ISO's recommending to merchants to abandon integration and install dial-up terminals -- back to the 80's. Some assume that this route removes the merchant from the burdens of PCI compliance. This could not be farther from the truth. All merchants must comply with PCI DSS if they process, transmit or store credit card data -- via terminal or otherwise. My guess is that this misassumption stems from some PCI wording that excludes stand-alone terminals from specific portions of PCI. But it never excluded the merchant from PCI.
Some argue that these devices are not susceptible to viruses, keyboard loggers, Trojans, or other malware -- I argue they are. Malware requires a CPU, an operating system, and communication ports and stand-alone CC terminals have all these requirements. So far the only thing saving these devices from the headlines is the lack of a deviant programmer with nothing better to do from writing some malware.
Enough on malware, the scariest vulnerability with this retro alternative is that most (all that I'm aware of) dial-up modem traffic from these devices to the processor is unencrypted. Insert a sniffer in the mix or update a phone number in the terminal, and the hacker has free flowing unencrypted payment information. To me, a properly secured network transmitting encrypted card information to the processor is less vulnerable to hackers than a dial-up device transmitting unencrypted card information to the same processor (and I totally ignored the other cons of returning to the 80's and using a non-integrated solution).
Wednesday, October 20, 2010
Is it an Audit or Assessment?
From time-to-time I see or hear someone getting bent out of shape because another person makes a reference to "PCI audit." Many times the reference is made within a heated debate about the validity of something and this obvious total lack of education opens the door for incorporating into the debate the heredity of the poor sole that mentioned "audit." Well I beg to differ -- it is an audit, not an assessment.
The basis for this mislabeling of the audit process is the title the PCI SSC gave to the auditors -- Qualified Security Assessor (QSA). But as happens often in business, titles do not always match the role.
One of these poor misguided people tried to explain it to me this way: "Assessors do not make judgments as to the validity of something, they are simply documenting and reporting their findings to the PCI SSC whereas auditors make judgments." But QSAs are judging pass or fail for each line item in the PCI DSS or PA-DSS specification and once everything passes based on their opinion, they write up a ROC for PCI SSC's final approval. Based on this definition, QSAs are performing audits.
Then you have the definitions found on Dictionary.com:
Assessment deals with assessing or appraising the value of something. Audit, on the other hand, deals with official examination, inspection or verification of something. Based on these definitions, the Assessor is doing an audit as well.
I know that most people don't care what the "A" in QSA stands for and they care even less whether it's called an audit or assessment. I'm only writing this so I can easily reference my position when someone brings in my heredity into a heated debate.
The basis for this mislabeling of the audit process is the title the PCI SSC gave to the auditors -- Qualified Security Assessor (QSA). But as happens often in business, titles do not always match the role.
One of these poor misguided people tried to explain it to me this way: "Assessors do not make judgments as to the validity of something, they are simply documenting and reporting their findings to the PCI SSC whereas auditors make judgments." But QSAs are judging pass or fail for each line item in the PCI DSS or PA-DSS specification and once everything passes based on their opinion, they write up a ROC for PCI SSC's final approval. Based on this definition, QSAs are performing audits.
Then you have the definitions found on Dictionary.com:
Assessment deals with assessing or appraising the value of something. Audit, on the other hand, deals with official examination, inspection or verification of something. Based on these definitions, the Assessor is doing an audit as well.
I know that most people don't care what the "A" in QSA stands for and they care even less whether it's called an audit or assessment. I'm only writing this so I can easily reference my position when someone brings in my heredity into a heated debate.
Friday, October 8, 2010
Can Never Be Too Safe
This is totally off topic but very funny. Put this in the random thoughts category:
Subscribe to:
Posts (Atom)