Re: [ekmi] Re: [Fwd: [user-support] Req #14348 - {redacted}- Cannotaccess issue]

[Allen <netsecurity@sound-by-design.com>]

Hi Arshad,

What you point out is why I posted the example. If we wait until 
an exploit has been found and publicized, we'll never keep up. 
What needs to happen is to see how we can anticipate potential 
risks and possible mitigations as we develop new standards like 
EKMI. EKMI is not an isolated standard, but one that 
inter-operates with other standards. Granted, we can not run all 
the shows to assure that they follow best practices, but what we 
can do is use cogent examples of how to use EKMI and illustrate 
operation with good, real world problems like I forwarded below.

Basically what I want to happen is to grease the wheels of 
thinking so they operate more smoothly.

In that vein I'll have a post shortly on a, as yet AFAIK, 
unexploited phishing vector that many professionals will likely 
fall prey to if we don't watch out. Again this is an exploit that 
uses common data that is sent in the clear and stored in the 
clear with no easy solutions that I can see, but I've only got 
four eyes, and two of them are glass. ;->

Allen

Arshad Noor wrote:
> I believe the pain point that everybody's focused on is SSN, CCN and the
> like, Allen; that's the low-hanging fruit for attackers.  However, once
> they've realized that that avenue is shut down through encryption or
> elimination, they will seek other avenues of attack.  Cookies, e-mail
> addresses, IP addresses, physical mailing addresses, etc. will be the
> tools by which they will attempt to compromise systems.
> 
> I personally know at least one e-commerce site that can be shut down by
> simply changing the e-mail address of customers through one SQL update
> query.  I have to believe that all e-commerce sites currently do not
> encrypt e-mail addresses (or maintain message digests on database
> records to indicate unauthorized changes) and thereby have the same
> vulnerability.
> 
> In time, businesses will learn that they need to encrypt more than just
> SSN, CCN, DOB, medical data, etc.  While browser cookies are generally
> encrypted today, the decryption algorithm/key is probably simple and
> well-known to internal engineering employees of those companies.
> 
> All the more reason why an enterprise key-management is critical for a
> company's data-protection strategy, and Application/Data architects
> need to start thinking about how they're going to deal with far more
> encrypted data than what PCI-DSS, HIPAA and Breach Disclosure laws
> demand.  Security practitioners can help them by getting them to start
> addressing the issue for new applications before the application gets
> implemented.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> Allen wrote:
>> Hi everyone,
>>
>> Got this message from a well known IT organization. What is 
>> particularly interesting is the very last line where they have 
>> attempted to grab cookies from my machine. I would think that this 
>> would be a vector for some sort of exploit, especially if the 
>> exploiter worked at the company and had access to the files collected 
>> for support.
>>
>> The other point of interest is that my IP address was included in 
>> plain text e-mails. I would think that there would be a better way to 
>> do support tickets. One would not normally think of this type of 
>> ticket as requiring cryptographic protection, I sure didn't, but it is 
>> clear that enough of this type of collection would make it open to 
>> exploitation in some, as yet unknown attack.
>>
>> What might you suggest?
>>
>> Allen
>>
>>
>> -------- Original Message --------
>> Subject:     FW: [user-support] Req #14348 - {redacted} -
>> Cannot access issue
>> Date:     Tue, 29 Apr 2008 16:18:01 -0400
>> From:      <{redacted}.org>
>> To:     <netsecurity@{redacted}.com>
>> References: <4F1DDD1C51793F4EB14A2C692FF934E102FAA255@I{redacted}.org>
>>
>> Not sure what the issue is with this, but we'll look into it. 
>> Meanwhile, please try this link:
>>
>> http://www.{redacted}.org/xxx.html
>>
>>
>>
>> -----Original Message-----
>> From: {redacted}
>> Sent: Monday, April 28, 2008 11:42 AM
>> To: {redacted}
>> Subject: Fwd: [user-support] Req #14348 - {redacted} -
>> Cannot access issue
>>
>> HI,
>> Here is another subscriber who has a problem with logging in.
>> {redacted}
>>
>> ----- Forwarded Message -----
>> From: "Digital Support Web Form" {redacted}
>> To: "User Support List" <user-support@{redacted}>
>> Sent: Friday, April 25, 2008 7:03:31 PM (GMT-0500) America/New_York
>> Subject: [user-support] Req #14348 - {redacted} - Cannot access issue
>>
>> Digital support request received:
>>
>> Request #: 14348
>> Name: {redacted}
>> Email: netsecurity@{redacted}.com
>> Phone:
>> Nature of problem: Cannot access issue
>> Details:
>> It keeps looping back to the login page.
>>
>> (BTW, captchas are *not* at all secure and should be avoided as they 
>> give a false sense of security.)
>>
>> Full subscriber url: http://www.{redacted}.com/{redacted}/2008spring/
>> Subscriber ID:
>> u1: {redacted}
>> Collection: {redacted}
>> Collection ID: 6692
>> Document: {redacted}
>> Document ID: 29222
>> Ticket Number: 49072
>> IP address: {redacted}
>> Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 
>> Gecko/20080404 Firefox/2.0.0.14
>> Cookies:
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>