Did you know that you ALREADY have an e-mail policy?


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.

Comments (7)

  1. Anonymous says:

    Is it my impression, or these lists are getting bigger? Setting Up Exchange 2007 Exchange Server 2007

  2. Dan Halford says:

    Providing remote access to Outlook via Citrix, especialy when combined with two-factor authentication, should help mitigate against cache browsing and malware infecting email messages. It doesn’t stop meat-layer vulnerabilities, of course, but it would provide another layer of security. Considering many large organisations already have Citrix in the enterprise, it’s another method of access that can help reduce risk.

  3. joshmaher says:

    The problem with the business being the sole decision maker without IT (or security) being involved is by the time they set their mind and budget on a policy, they usually have already overlooked the risks of their decision. I agree that the business needs should drive the decisions, although logical organization is not always the case and the lack of out of the box security leads to increased cost. This of course leads to frustration with the IT support function and ultimately leads to infrastructures that are not secure. (unfortunately that mess of a statement is not overstated)

    I think it is important to involve the technologists early enough to influence the budgeting and decision making process. Just like city planners involve the businesses they will affect and business leaders involve their accountants when making accounting changes. The  decision makers of these policies should involve technologists who know these types of answers.

  4. Paul Vincent says:

    It used to be the case that the Business used to ‘delegate’ the grey art of Risk Analysis to technologists, but to be fair, are those in technology really the best ones to judge risk?

    More and more I have seen examples recently where the Business has taken an active part in Risk Definition Workshops, in the IRAM process (Information Security Forum http://www.securityforum.org) and also many business partners are seeking professional accreditation such as the CISSP.

    For proper Risk Management to take place, only the Business can define what is an unnacceptable risk. For example;

    If a nefarious individual executes a DDOS against their customer facing web site, causing net losses of £25,000 is this an unnacceptable risk?

    To a small retailler of squeaky toys, that could result in the closure of their business, to a large financial organistation netting 22 billion a year, maybe it’s not such a big deal.

    Also it is important to quantify the damage that could be caused by various threats agents taking advantage of vulnerabilities. Only then can solid decisions be made regarding the amount of protection that it makes sense to deploy (would you spend £30,000 on a firewall protecting assets with a value of £4-5000?).

    Of course, there will always be occasions where technical staff will be able to offer their valuable experiance and knowledge. This is why it is always useful to have representation at Risk Workshops.

    To go back to Steve’s point initially, the appetite for risk a company is willing to take will be reflected in their overall security policy. Who signs off the policy? The business.

    There are some very good security products out there that address issues around CIA, and strong auth. Company standards will define the ones that best support the overarching policy.

    Of course if you don’t have a policy, then you need to get one, if only to document the ‘De-facto’ policy that may be in place as SR mentions above

  5. Sean Burgess says:

    But it can be even worse/better than you have described in your 2 rules.  My company is converting from having an email system that makes it’s employees more productive to one that keeps it’s data more secure.  Although they have a web interface available to our mail servers, you need to be logged in via VPN or on the LAN to use it.  And although our VPN is web based, you need to be on company hardware to get it to work.  So our company’s mail will now be extremely secure and basically unusable when you are not working in the office.  Guess it will keep me from checking my mail when I am on vacation.

    The one thing that you didn’t talk about as an impact on productivity is mail quotas.  How productive can a mail platform be if you are constantly having to move your mail from the server to a local archive?  Is the savings in storage costs worth the lost time that managing local archives requires?

    Sean—

  6. HiltonT says:

    Hi Steve,

    You may not be able to have both scenarios, but you can have certain people using one and others using the other.  For example, you could only allow external access to emails to those people who have signed that particular part of the company security policy and who need external access – salespeople, management, remote workers, etc.  They would be able to access this email from their laptop, PDA, home PC or whatever else is allowed for in the company security policy.  All others would be denied this ability.

    Also, as far as 2FA security options go, Dana Epp has released RWW Guard (http://www.scorpionsoft.com/products/rww-guard/) which allows for CryptoCard (and other) OTP devices to be used to help secure (yes, OK, authenticate) external RWW/OWA access.  He’s also working on an OEM-ed CryptoCard + RWW Guard + IAS product.

Skip to main content