Hmmm, hadn't thought of that... Not sure why, just hadn't. -----Original Message----- From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Monday, March 09, 2009 11:14 AM To: MS-Exchange Admin Issues Subject: RE: OWA
You could also only allow OWA over the VPN.... > -----Original Message----- > From: Fogarty, Richard R CTR USA USASOC > [mailto:rick.foga...@us.army.mil] > Sent: Monday, March 09, 2009 11:15 AM > To: MS-Exchange Admin Issues > Subject: RE: OWA > > Exactly to the point. I don't think using an RSA SecureID fob will fix > the > overarching security issue (as I see it.) So, I guess OWA is probably > not > the answer at this point as most users will still need to see the > attachments. > > So, for our area, I'm going to recommend using a hybrid approach to > start - > use RPC/HTTP over the VPN and dig deeper into OWA in our test > environment. > > Appreciate it. > > -----Original Message----- > From: Ben Scott [mailto:mailvor...@gmail.com] > Sent: Monday, March 09, 2009 10:26 AM > To: MS-Exchange Admin Issues > Subject: Re: OWA > > On Mon, Mar 9, 2009 at 9:31 AM, Fogarty, Richard R CTR USA USASOC > <rick.foga...@us.army.mil> wrote: > > Since our customers have the ability to work with some sensitive > > documents, OWA has always been discounted due to the possibility of a > > customer opening up a sensitive document on a public computer. > > Disabling OWA attachments, as MBS suggests, might fix that, but > then, I'm guessing the reason people want OWA is to open those > sensitive attachments, right? :) > > SSL doesn't protect "leftovers" as some suggest. For one, by > default, MSIE still caches SSL content in the plaintext "Temporary > Internet Files". You can enable "Do not save encrypted pages to > disk", but we've found that causes some sites to malfunction. Plus, > to open an attachment, the attachment *must* be saved as plaintext to > disk, so the application can open the file. SSL protects the > transport over the wire, nothing more. > > But the biggest issue with OWA (and things like it) is that you're > allowing any computer in the world to access your systems. That > includes computers without updates, with poorly chosen security > settings, with no firewall, full of spyware, including keystroke > loggers to sniff your OWA password, etc., etc. > > Using a OTP device like the RSA SecurID fobs will counter the > password sniffing attack, so bad guys won't be able to get into OWA > from elsewhere. But they can still sniff content from the OWA session > itself. > > And nothing will protect against lusers saving sensitive content > from an email body to the untrusted computer. > > Frankly, in an environment where security is of overriding concern, > I recommend against allowing *any* untrusted computer to connect to > trusted resources in any way, shape, or form. If they need remote > access, user is provisioned with a trusted laptop (configured by > company IT, without admin rights for the user) and they can use that > to connect to OWA or full Outlook via some kind of secure tunnel > (i.e., VPN). This is the only way to ensure the trust chain isn't > broken. > > This is all based on risk assessment, of course. In many > organizations (especially smaller ones), email and in-company desktops > are already pretty insecure, and there's nothing overly sensitive in > email in the first place. OWA's not much of a risk, then. But given > that your email address ends in <.mil>, I'm guessing you're not one of > those. :) > > -- Ben > > ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ > ~ http://www.sunbeltsoftware.com/Ninja ~ > > > ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ > ~ http://www.sunbeltsoftware.com/Ninja ~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
