Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Royce Williams]

On Fri, Mar 17, 2017 at 4:21 PM, Bill Campbell  wrote:

> I've had PCI testers complain when they tried port scans on
> systems we monitor, and their IPs were blocked almost
> immediately.  They couldn't understand active measures that
> detect attacks and take actions to prevent damage.  They actually
> wanted me to remove the firewall so they could test.

If the testing team is competent, it is reasonable to suspend an outer
layer of controls in order to validate an inner layer.

If you want a safecracker to test your safe, it's OK to let them past
the guards and into the building first. :)

Royce

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Bill Campbell]

On Fri, Mar 17, 2017, Laura Atkins wrote:
>
>   On Mar 17, 2017, at 7:47 AM, John R Levine <[1]jo...@taugh.com> wrote:
>
>   On Fri, 17 Mar 2017, Eric Henson wrote:
>
> As a PCI compliant company, we have to go to great lengths to secure
> any system that stores, processes, or transacts credit card data. If
> that included our email servers, that would put every single mail
> server, every single mail client, including smart phones, in scope
> for our PCI audit. That would be a complete nightmare.
>
>   I believe you, but that's not the question -- when's the last time
>   something bad actually happened due to sending credit card info by
>   mail?
>   I used to have my own credit card account and my card processor
>   demanded PCI compliance.  About 1/4 of it was reasonable, 3/4 was cargo
>   cult stuff that mostly involved stuff like setting packet filters so
>   they couldn't probe ports that weren't going to answer anyway.
>
>   Oh. We had our PCI compliance "security vendor" tell us we should open
>   up ports on our NAT so they could probe the NAT for vulnerabilities to
>   test the security of our
>   only-turned-on-to-connect-to-virtual-terminal-VM that we used for
>   credit card processing (not many of our customers pay with credit
>   cards). We finally "passed" the security sweep by blackholing their
>   scanning IP addresses.

I've had PCI testers complain when they tried port scans on
systems we monitor, and their IPs were blocked almost
immediately.  They couldn't understand active measures that
detect attacks and take actions to prevent damage.  They actually
wanted me to remove the firewall so they could test.

Bill
-- 
INTERNET:   b...@celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:  (206) 236-1676  Mercer Island, WA 98040-0820
Fax:(206) 232-9186  Skype: jwccsllc (206) 855-5792

No nation can preserve its freedom in the midst of continual
warfare. -- James Madison

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[D'Arcy Cain]

On 2017-03-17 03:10 PM, Doug McIntyre wrote:

The funniest PCI audit request I've come across is a customer had
their PCI onsite auditor require the combination of their colo rack to be
reset to 000 at the end of every visit. Not doing so would be a violation
of their PCI security.


I suspect that they meant (and perhaps mis-stated) that the tumblers 
were to be set to zeros, not the the combination had to be reset.


Which reminds me of a security issue I came across recently although not 
tech related.  I rented a condo in New Orleans for our vacation.  The 
person renting to me gave me the code for a key safe like realtors use. 
When I got there I saw two of them.  I looked at one and saw that it was 
already set for the code I was given but it wouldn't open.  I then tried 
the other one and it worked.


The lesson - if you see two boxes like this make a note of the settings 
on them and try each on the other.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Royce Williams]

On Fri, Mar 17, 2017 at 9:42 AM,   wrote:
> On 17 Mar 2017 15:47:50 +0100, "John R Levine" said:
>
>> I used to have my own credit card account and my card processor demanded
>> PCI compliance.  About 1/4 of it was reasonable, 3/4 was cargo cult stuff
>> that mostly involved stuff like setting packet filters so they couldn't
>> probe ports that weren't going to answer anyway.
>
> I gave up on thinking that PCI was something other than an extortion racket a
> number of years ago, when somebody reported on the major breaches of the year
> and noted that 100% of them were in full PCI compliance at the time of the 
> breach.

This field study - from a real-world state-government-level experiment
that changed the incentives for auditing industrial plants in Gujarat
- is informative:

"Truth-telling by Third-party Auditors and the Response of Polluting
Firms: Experimental Evidence from India"

http://economics.mit.edu/files/10713

The auditing teams were compensated for *confirmed* findings.
Magically, significantly more findings were discovered. Magically,
compliance increased.

Full abstract:

In many regulated markets, private, third-party auditors are chosen
and paid by the firms that they audit, potentially creating a conflict
of interest. This article reports on a two-year field experiment in
the Indian state of Gujarat that sought to curb such a conflict by
altering the market structure for environmental audits of industrial
plants to incentivize accurate reporting. There are three main
results. First, the status quo system was largely corrupted, with
auditors systematically reporting plant emissions just below the
standard, although true emissions were typically higher. Second, the
treatment caused auditors to report more truthfully and very
significantly lowered the fraction of plants that were falsely
reported as compliant with pollution standards. Third, treatment
plants, in turn, reduced their pollution emissions. The results
suggest reformed incentives for third-party auditors can improve their
reporting and make regulation more effective. JEL Codes: Q56, M42,
D22.

[end abstract]

The "before" section of the paper will seem hauntingly familiar.

"Show me the incentives and I'll show you the outcome." - Charlie Munger

Royce

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Doug McIntyre]

On Fri, Mar 17, 2017 at 01:42:16PM -0400, valdis.kletni...@vt.edu wrote:
> I gave up on thinking that PCI was something other than an extortion racket a
> number of years ago, when somebody reported on the major breaches of the year
> and noted that 100% of them were in full PCI compliance at the time of the 
> breach.

Although some of the largest breaches clearly were not PCI compliant,
like TJX storing all pin/mag stripe info and credit card transactions 
for years and years before.  I seem to remember something about Target's
breach being equally jaw dropping in violation. If the largest players
can't even handle common sense.. 

The funniest PCI audit request I've come across is a customer had
their PCI onsite auditor require the combination of their colo rack to be
reset to 000 at the end of every visit. Not doing so would be a violation
of their PCI security.



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Dave Warren]

On Thu, Mar 16, 2017, at 17:38, John Levine wrote:
> In article
> <1489684655.3176120.913642288.0d732...@webmail.messagingengine.com> you
> write:
> >You can make a rule against sending credit cards by email, but if
> >customer service reps know it works they might still encourage a
> >customer to do it as it's faster and easier than other options (fax,
> >mail) and when Something Bad Happens, the customer will rightly blame
> >the company.
> 
> So just out of nosiness, when's the last time Something Bad Happened
> in real life due to sending credit card info by e-mail?

I've seen companies get their merchant account shut down for storing
credit cards in email based ticket systems, this made for a Really Bad
Day at said company and for their customers.

With that being said, I personally have no problem sending my credit
card via TLS secured email. Yes, I will take the time to check that
their server supports STARTTLS, no I don't check to see whether it's a
secure set of protocols and ciphers. 

As was mentioned, the real risks are the database, POS systems and other
places where bulk collection can happen. I also lock my doors despite
the fact that one could simply smash the glass, reach through and unlock
the door.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[valdis . kletnieks]

On 17 Mar 2017 15:47:50 +0100, "John R Levine" said:

> I used to have my own credit card account and my card processor demanded
> PCI compliance.  About 1/4 of it was reasonable, 3/4 was cargo cult stuff
> that mostly involved stuff like setting packet filters so they couldn't
> probe ports that weren't going to answer anyway.

I gave up on thinking that PCI was something other than an extortion racket a
number of years ago, when somebody reported on the major breaches of the year
and noted that 100% of them were in full PCI compliance at the time of the 
breach.


pgpFr_Mad6Rf1.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Laura Atkins]

> On Mar 17, 2017, at 7:47 AM, John R Levine  wrote:
> 
> On Fri, 17 Mar 2017, Eric Henson wrote:
> 
>> As a PCI compliant company, we have to go to great lengths to secure any 
>> system that stores, processes, or transacts credit card data. If that 
>> included our email servers, that would put every single mail server, every 
>> single mail client, including smart phones, in scope for our PCI audit. That 
>> would be a complete nightmare.
> 
> I believe you, but that's not the question -- when's the last time something 
> bad actually happened due to sending credit card info by mail?
> 
> I used to have my own credit card account and my card processor demanded PCI 
> compliance.  About 1/4 of it was reasonable, 3/4 was cargo cult stuff that 
> mostly involved stuff like setting packet filters so they couldn't probe 
> ports that weren't going to answer anyway.

Oh. We had our PCI compliance “security vendor” tell us we should open up ports 
on our NAT so they could probe the NAT for vulnerabilities to test the security 
of our only-turned-on-to-connect-to-virtual-terminal-VM that we used for credit 
card processing (not many of our customers pay with credit cards). We finally 
“passed” the security sweep by blackholing their scanning IP addresses. 

Happily, our processing vendor found a PCI security system that understood 
security and we’ve not had to deal with the stupid in many years. 

laura 

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: http://wordtothewise.com/blog  






___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[John R Levine]

On Fri, 17 Mar 2017, Eric Henson wrote:

As a PCI compliant company, we have to go to great lengths to secure any 
system that stores, processes, or transacts credit card data. If that 
included our email servers, that would put every single mail server, 
every single mail client, including smart phones, in scope for our PCI 
audit. That would be a complete nightmare.


I believe you, but that's not the question -- when's the last time 
something bad actually happened due to sending credit card info by mail?


I used to have my own credit card account and my card processor demanded 
PCI compliance.  About 1/4 of it was reasonable, 3/4 was cargo cult stuff 
that mostly involved stuff like setting packet filters so they couldn't 
probe ports that weren't going to answer anyway.


R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Paul Smith]

On 17/03/2017 14:18, Eric Henson wrote:

As a PCI compliant company, we have to go to great lengths to secure any system 
that stores, processes, or transacts credit card data. If that included our 
email servers, that would put every single mail server, every single mail 
client, including smart phones, in scope for our PCI audit. That would be a 
complete nightmare. So we have rules to prevent credit card numbers from 
entering our environment.


The problem is that that doesn't work.

PCI is broken this way - you can't control someone you have no control 
over.


I bet you anyone can send you an obfuscated credit card number, and 
it'll enter your mail server, and you won't know about it until/unless 
someone reads it. Then what do you do? I bet you'd just delete it, keep 
it quiet and hope for the best, or do you shred the mail server's hard 
disks, those of any users who may have had access to the message (and 
any message archives) and rebuild everything.


For instance, if I sent you a message saying four hundred and 
fifty-seven, 345 double eight, a dozen, 55 seventeen, Clickety-click, 
would your scanner prevent that message coming in? ;-)


Also, do you do OCR on any image attachments or Word documents/PDFs/etc 
you receive, to make sure the don't contain a scan of a credit card or 
similar? If not, then you're not 'preventing' anything. Or, do you just 
refuse any type of attachments at all, and any email containing any 
digits or number words (in various languages).


If PCI was adhered to as strictly as they'd want you to, it'd be a great 
DoS mechanism...









___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Vick Khera]

On Thu, Mar 16, 2017 at 8:38 PM, John Levine  wrote:

> So just out of nosiness, when's the last time Something Bad Happened
> in real life due to sending credit card info by e-mail?
>

One of my buddies does design and consulting of networks for industries
regulated by federal statutes. By refusing certain content at the gateway
it never enters their control so they are not responsible for securing it.
If they can detect the attachment is potentially in the class of "needs to
be securely handled" they can avoid the problems of having sensitive
information left in email where it is not considered securely stored. It is
not just about the transmission over the internet.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[Eric Henson]

As a PCI compliant company, we have to go to great lengths to secure any system 
that stores, processes, or transacts credit card data. If that included our 
email servers, that would put every single mail server, every single mail 
client, including smart phones, in scope for our PCI audit. That would be a 
complete nightmare. So we have rules to prevent credit card numbers from 
entering our environment.



Eric Henson
Server Team Manager
PFS
p: 972.881.2900  x 3104
m: 972.948.3424
www.pfsweb.com

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of John Levine
Sent: Thursday, March 16, 2017 7:38 PM
To: mailop@mailop.org
Cc: da...@hireahit.com
Subject: Re: [mailop] conventional wisdom, was Google rejects a TLS connection

In article <1489684655.3176120.913642288.0d732...@webmail.messagingengine.com> 
you write:
>You can make a rule against sending credit cards by email, but if 
>customer service reps know it works they might still encourage a 
>customer to do it as it's faster and easier than other options (fax,
>mail) and when Something Bad Happens, the customer will rightly blame 
>the company.

So just out of nosiness, when's the last time Something Bad Happened in real 
life due to sending credit card info by e-mail?

This strikes me as cargo cult security advice, like changing your password 
every month.  It might have made sense when people used shell accounts on vaxes 
with globally readable password files attached to thick ethernets that ran 
through unlocked janitors closets in student housing, but it makes little sense 
now.

R's,
John

PS: The actual credit card risks these days are bulk theft from poorly secured 
databases at businesses, and hacked ATMs and point of sale terminals.  See 
Brian Krebs's blog for endless examples.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

[John Levine]

In article <1489684655.3176120.913642288.0d732...@webmail.messagingengine.com> 
you write:
>You can make a rule against sending credit cards by email, but if
>customer service reps know it works they might still encourage a
>customer to do it as it's faster and easier than other options (fax,
>mail) and when Something Bad Happens, the customer will rightly blame
>the company.

So just out of nosiness, when's the last time Something Bad Happened
in real life due to sending credit card info by e-mail?

This strikes me as cargo cult security advice, like changing your
password every month.  It might have made sense when people used shell
accounts on vaxes with globally readable password files attached to
thick ethernets that ran through unlocked janitors closets in student
housing, but it makes little sense now.

R's,
John

PS: The actual credit card risks these days are bulk theft from poorly
secured databases at businesses, and hacked ATMs and point of sale
terminals.  See Brian Krebs's blog for endless examples.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop