An email access policy can be expressed in one of two ways:
- E-mail is mission critical to our business. Therefore, we permit employees to read and compose e-mail from any location in the world where employees can access the Internet, using either company-issued devices or public Internet terminals. This allows our employees to be maximally productive.
- E-mail is mission critical to our business. Therefore, we permit employees to read and compose e-mail only from company-owned computers built and maintained according to IT standards. This ensures the security and integrity of our e-mail systems and data.
Which policy is yours? You can't have both, of course.
Selecting a policy should never be a technical exercise, and the decision isn't up to the IT department or even the security group. It's a decision the business makes. The decision begins with the answer to the question, "What does mission critical mean to our business?"
For some, mission critical means maximum access -- that no matter where an employee is, or what the employee might be doing, if there's a device with an Internet connection, the employee should do some mail. Timeliness is of utmost importance; the organization will accept the risks associated with using public terminals (and deal with any exposure caused by potential threats that materialize).
For others, mission critical means absolute integrity -- that the organization simply can't tolerate the risks associated with access from unknown computers and will therefore permit access only to those on the corporate network (or maybe connecting via a VPN, but even that can be too much for some).
Which definition of mission critical is yours? It can't be both, of course.
Outlook Web Access = your email policy
If your organization uses Outlook Web Access, then it's already selected its policy: the first one. An organization who uses OWA values anytime, anywhere, any-device access as being necessarily critical to the success of its business that it's willing to accept the risks associated with such access. Let's consider some of the risks of using public terminals:
- Malware infects an e-mail message
- Keystroke logging software steals credentials
- Evil person reads and writes e-mail after a user walks away without logging out
- Evil person reads left-over attachments sitting in the browser's cache
- Someone shoulder-surfs (an employee at a competing organization, for example)
But yet, for many organizations, the benefits of OWA outweigh the risks -- and there's nothing inherently wrong with that. In some cases, it's possible to mitigate the risks. Returning to our list, consider:
- Malware scanners on the e-mail gateway
- Two-factor authentication like RSA SecurID or VeriSign Unified Authentication (note: while 2FA helps guard against credential theft, it's powerless to stop malware)
- The folks at CryptoCard have some interesting products, including a software token that you can run on a Windows Mobile device or a Blackberry for generating the token that you then enter into the OWA login page -- however, I've got no experience with their stuff
- Forms-based logon with a timeout (using a browser cookie)
- Attachment conversion like Messageware AttachView -- converts to non-cached HTML
- Not being stupid
Risk awareness and mitigation: the security group's job
Our job, as security experts, is never to say "no." Rather, our job is to enable the business to succeed as safely and securely as possible. We do that by staying close the business, understanding (perhaps even anticipating) its needs, and making it aware of any associated risks. It's up to the business to make the decision. Then the work returns to us, and now we select and deploy appropriate processes and technologies to mitigate the risks we can, while perhaps simply ignoring or transferring (by buying insurance) the remainder.
I know of few organizations who choose the second e-mail policy: prohibiting remote access to e-mail. Indeed, I would wonder if that kind of organization really knows what e-mail is for. Work in the modern age is rarely limited to daylight hours in traditional offices. If your organization is among the majority that expects its employees to work for free (ha ha), then it's your job to make sure the business understands the risks and deploy appropriate processes and technology to mitigate those risks.
And this is only the beginning. Done right, an OWA architecture can be extended into a general access model that's simpler to design, build, and maintain; its simplicity results in cost savings and greater security. I'll have more to say about the "web-enabled data center" in a future blog post. My goal is to shove all DMZ-laden complex network beasts into the dustbin of history.