[WEB SECURITY] SSL does not = a secure website

["Ryan Barnett" <rcbarnett@xxxxxxxxx>]

------=_Part_12060_29204303.1143510031736
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I need some feedback from the lists.  Does any have any verifiable proof
(new story, etc...) that documents where attackers successfully sniffed
Credit Card data off of the Internet for an eCommerce site???  Every story
that I have read about indicates that attackers mostly obtain this data by
breaking into the back-end DB to steal the CC data rather than sniffing.
Anyone with info to the contrary?

While I believe that we would all agree that the use of SSL for eCommerce i=
s
a good idea, I am interested in the actual THREAT.  It seems to me that the
real threat to CC data is a vulnerable webapp/backend and not the use of
SSL.  The PCI Data Security Standard document (
http://usa.visa.com/download/business/accepting_visa/ops_risk_management/ci=
sp_PCI_Data_Security_Standard.pdf)
lists this as Requirement 4 -
*

Protect Cardholder Data
*

Requirement 3: Protect stored data

Requirement 4: Encrypt transmission of cardholder data and sensitive
information across public networks

So, when an eCommerce website boasts "We are a secure website" - keep in
mind that they are referring to Requirement 4.  Who knows what they are
doing about Requirement 3...

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

------=_Part_12060_29204303.1143510031736
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>I need some feedback from the lists.&nbsp; Does any have any verifiabl=
e proof (new story, etc...) that documents where attackers successfully sni=
ffed Credit Card data off of the Internet for an eCommerce site???&nbsp; Ev=
ery story that I have read about indicates that attackers mostly obtain thi=
s data by breaking into the back-end DB to steal the CC data rather than sn=
iffing.&nbsp; Anyone with info to the contrary?
</div>
<div>&nbsp;</div>
<div>While I believe that we would all agree that the use of SSL for eComme=
rce is a good idea, I am interested in the actual THREAT.&nbsp; It seems to=
 me that the real threat to CC data is a vulnerable webapp/backend and not =
the use of SSL.&nbsp; The PCI Data Security Standard document (
<a href=3D"http://usa.visa.com/download/business/accepting_visa/ops_risk_ma=
nagement/cisp_PCI_Data_Security_Standard.pdf">http://usa.visa.com/download/=
business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard=
.pdf
</a>) lists this as Requirement 4 -</div>
<div><b><font face=3D"Arial,Bold" size=3D"4">
<blockquote dir=3D"ltr" style=3D"MARGIN-RIGHT: 0px">
<p align=3D"left">Protect Cardholder Data</p></blockquote></font></b><font =
face=3D"Arial" size=3D"3">
<p align=3D"left">Requirement 3: Protect stored data</p>
<p align=3D"left">Requirement 4: Encrypt transmission of cardholder data an=
d sensitive information across public networks</p></font>So, when an eComme=
rce website boasts &quot;We are a secure website&quot; - keep in mind that =
they are referring to Requirement 4.&nbsp; Who knows what they are doing ab=
out Requirement 3...
<br clear=3D"all"><br>-- <br>Ryan C. Barnett<br>Web Application Security Co=
nsortium (WASC) Member<br>CIS Apache Benchmark Project Lead<br>SANS Instruc=
tor: Securing Apache<br>GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>Author: Preve=
nting Web Attacks with Apache=20
</div>

------=_Part_12060_29204303.1143510031736--