Re: Vulnerability? Or...not so much?

["SCHALIP, MICHAEL" <mschalip () CNM EDU>]

Most document imaging systems store the actual documents/data separately from the metadata - typically, the system just 
manages pointers to the images......thus, the database can be secured one way, (typically, username/password) and the 
images can be secured another way, (sometimes encrypted)....would it be worth asking the vendor if their system 
supports any kind of encryption for the image?

We also didn't assume that all documents were created equal - if a document were for open meeting minutes, no worries.  
But, if a document were for closed meeting minutes (sensitive stuff, budgets, etc.), then - we'd take the extra step to 
put the additional protections in place, (ie, encrypt - then file in the document imaging system).  Even if someone 
within the corporation searched for a restricted document, they might see the result in the search, but they couldn't 
get to the document.....

Does it hold that the criticality of the situation and the risk associated with the vulnerability is linked to the 
sensitivity of the documents/data at risk?  If a system is "vulnerable", but all they can get to is open meeting 
minutes - the protections that are in place may be deemed adequate by the user (*and* the vendor).  Maybe the vendor 
never designed, nor intended, the system to protect documents beyond a certain level of sensitivity.....which is why 
some vendors have their products "certified" to certain standards, and why others don't bother....

Just some thoughts.....

M



________________________________
From: The EDUCAUSE Security Constituent Group Listserv [SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Steve Werby 
[smwerby () VCU EDU]
Sent: Sunday, April 04, 2010 8:28 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Vulnerability? Or...not so much?

On 4/3/2010 9:35 PM, David Shettler wrote:

Unfortunately, the vendor refuses to acknowledge that the problem is a
security issue, and thus won't remedy it.  Their opinion is that the
URI randomization, and 60 minute temporary nature of the files is
sufficient 'security'.


Since the application's users can access the system via an untrusted network (per your follow-up email) and the URIs 
could be logged via a proxy or filtering system, there's a risk that unauthorized users (both internal and external) 
could acquire the URIs during the availability window.  And there are no controls beyond knowledge of the URI to 
restrict access.  And of course, there's the risk the URIs could be guessed, but unless it's mathematically feasible to 
brute force attack URIs in a 60 minute window without being detected, I wouldn't focus on that.


  1) decide that their obscurity is good enough, and re-open access to
it.  The URI/filename is not predictable at my skill level (portions
are, but others not), but I'm not exactly a hacker-adept.


Per above, I'd be less concerned with guessing if the random portion of the URI isn't easy to guess and more concerned 
that someone could intercept a valid URI and then access the associated sensitive data within the 60 minute window.  If 
you haven't already, you may want to walk the data owners through specific risk scenarios and explain the likelihood of 
exploitation of the vulnerability and the potential impact.  Who has the capacity to accept risk to sensitive data in 
your environment - you?  the data owner? someone else?

Is there every a situation where these files should ever be accessible during that 60 minute window from an IP address 
other than the IP address of the user who led to the files' creation?  If not (or that's infrequent), perhaps you could 
implement a system between the user and the scanning system that logs the relevant URIs and IPs and blocks access from 
unauthorized IPs.  I'm assuming the app's code can't be modified.  Even if there are no hooks into it and it doesn't 
have available logs, you should be able to get what's needed from the web server logs, at least after some 
configuration tweaks.  This would reduce the window from 60 minutes to something closer to 0 seconds and would limit it 
to attackers coming from the same IP address as the originator.

--
Steve Werby
Information Security Officer
Virginia Commonwealth University
VCU Information Security - http://infosecurity.vcu.edu/
News, Tips & More - http://www.twitter.com/vcuinfosec
Best Practices - http://infosecurity.vcu.edu/docs/infosecbp.pdf

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.