Re: Back on topic.... Re: [SECURITY] Universitycredentials used by third parties

[Eric Case <eric () ERICCASE COM>]

The two Blackberry options are BES and BIS.  BES (Blackberry Enterprise
Server) is housed locally (but could be hosted) so it is not a problem.  BIS
(Blackberry Internet Service) can be accessed from the device or the web.
In either case the user creates an email account "object" that has the user
name and password for the remote account.  BIS uses this info to pull the
email from the remote account and push it to the device.  So while the user
may believe the password it stored on the device it is not.
-Eric


Eric Case, CISSP
eric (at) ericcase (dot) com
http://www.linkedin.com/in/ericcase
(520) 344-CISO (2476)


> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of David Gillett
> Sent: Wednesday, August 25, 2010 9:26 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Back on topic.... Re: [SECURITY]
Universitycredentials
> used by third parties
>
>   I haven't looked closely at Blackberry -- perhaps I need to?  The
> scenarios I'm aware of are:
>
> 1.  User sets their institution email to forward to a remote address -- in
> this case their Blackberry address.  No exposure of credentials unless
they
> want to reply (or originate) on the device and have those messages go
> through our outbound servers....
>
> 2.  User configures personal device to download messages from their
> institution inbox.
>
>   Does either of these actually involve sharing the user's credentials
with
> the *service*, beyond their device?  I had assumed not, but now I'm not so
> sure....
>
> David Gillett
>
>
> -----Original Message-----
> From: Mike Porter [mailto:mike () UDEL EDU]
> Sent: Wednesday, August 25, 2010 08:55
> To: SECURITY () listserv educause edu
> Subject: Re: [SECURITY] Back on topic.... Re: [SECURITY]
> Universitycredentials used by third parties
>
> On Wed, 25 Aug 2010, Jesse Thompson wrote:
>
> > On 08/24/2010 11:08 AM, Joel Rosenblatt wrote:
> > > Just to thorough another thought into this mix, does anyone prevent
> > > their students (or other users) from turning over their credentials
> > > to Gmail or Blackberry?
> > >
> > > We see lots of authenticated logins from these services - and if I
> > > were to come down hard on this Ultrinsic using our sharing of
> > > password policy (which we do have) I'm sure that this would amount to
> > > having to change our policy to - you can't share your credentials -
> > > except with (gmail, Blackberry, etc.)
> > >
> > > I really hate inconsistent enforcement of policies, so it's either
> > > change the policy or cut off everyone.
> >
> > +1
> >
> > Our help desk created end-user instructions for IMAP-syncing email
> > accounts with Gmail, despite the fact that it completely violates
password
> policy.
> > They did this specifically because they get flooded with "how do I
> > save my email" requests when we deactivate email accounts, but other
> > users take advantage of it as well.
> >
> > Yet, when we propose the idea of officially embracing this
> > Gmail-IMAP-sync option as a more reliable alternative to forwarding  -
> > essentially treating Gmail the same as any other IMAP client - the
> > idea is immediately shot down because it violates password policy.
>
> What was the violation?  The problem that users woud need to store a
> password, likely the regular one, at gmail in order to use imap?
>
> We ended up with a convoluted system to avoid some of those issues.
>
>
> Mike
>
> Mike Porter
> Systems Programmer V
> IT/NSS
> University of Delaware
>
> > Jesse
> > (an email admin at Wisconsin)
>
> -
> Mike Porter
> PGP Fingerprint: F4 AE E1 9F 67 F7 DA EA  2F D2 37 F3 99 ED D1 C2

Attachment: smime.p7s
Description: