OnQ : Security

iPhone OS 3.1 Breaks Exchange Connectivity

eriq — Mon, 14 Sep 2009 21:05:00 GMT

CIO.com broke a story last week about issues relating to Exchange connectivity with the iPhone 3.1 OS update. Essentially, older iPhone models will lose their ability to connect with Exchange 2007 when they install the iPhone OS 3.1 update, the current iPhone models will work fine. According to the Apple KB on this issue, the iPhone 3GS supports device encryption, while the earlier iPhone models do not, and their recommendation is to have the Exchange administrator change the mailbox security policy to stop requiring device encryption.

Right now, there is no good solution other than not updating to iPhone OS 3.1 on older phones if Exchange 2007 (i.e., SBS 2008) is in the mix. While I'm hoping that Apple will do the right thing and figure out how to support device encryption on the older iPhone OS models, the other options of disabling device encryption (*shudder*) or updating the iPhone hardware to the 3GS model (*cough*) aren't necessarily viable.

If you have customers who are running older iPhones against Exchange 2007, please get the word out that they need to hold off on the iPhone OS 3.1 update until there is a better solution for the Exchange connectivity issue.

On Security

eriq — Wed, 15 Apr 2009 16:39:00 GMT

A pair of security-related activities happening tomorrow, April 16. Just in time for CPAs across the US to start breathing normally again, there are a pair of webcasts that you may well be interested in. First, the April 2009 edition of the Third Tier Third Thursday webcast focuses on SSL Certificates in SBS 2008. I will be presenting a live demo of how SSL certificates work in SBS 2008 (surprise, it's different from SBS 2003) and discuss the pros and cons of using third-party SSL certs versus the self-generated cert that SBS 2008 provides. Following that, Dana Epp is hosting a security round-table discussion on selling security in the SMB space. Amy Babinchak, Susan Bradley, and Ben Yarbrough join Dana for the round-table discussion.

But if just knowing about those two events wasn't enough, let me entice you a little more. Dana is offering to give away a copy of the SBS 2008 Unleashed book to one person who attends both sessions. If you don't have your very own copy of the book yet, here's one way you could possibly end up with a free copy.

Third Thursday Webinar: https://www.livemeeting.com/cc/mvp/meetingICS?id=F2FGNW&role=attend&pw=w%242S%3BM%60Wx&i=i.ics

Selling Security to the SMB Space: https://www2.gotomeeting.com/register/733132802

See you there tomorrow!

On Securing RDP

eriq — Fri, 21 Mar 2008 01:26:00 GMT

Last December, I worked out an arrangement to better protect our clients for whom we provide primary support. This involved finding ways to tighten access their severs via RDP (the infamous port 3389). There are a lot of different takes on controlling access to port 3389 out there, from simply not allowing it at all through the firewall (which works for SBS boxes running Remote Web Workplace, provided there's not a problem with IIS on the box at the time you want to access it) to configuring the firewal to allow inbound port 3389 connections only from specific IP addresses. For our purposes, neither of these options, nor the other similar variations, really worked for the way we conduct our business.

Enter Dana Epp and Scorption Software. Dana is a Security MVP from Vancouver whose software development company has been developing security products designed fo the SMB market for a couple of years.

After working with two of his tools, AuthAnvil and RWW Guard, we finally developed an approach that mitigates the risks of opening port 3389 to the internet, yet still allowing our opration a reasonable level of access for support and maintenance. Here's the approach we're taking.

Create a secondary administrative account with the same name across all of our supported servers.
Change the password on the Administrator account to be a really, really secure password.
Modify the local security policy to deny the Administrator account the ability to log in via terminal services, effectively limiting the Administrator account to a local console login only (which also does not affect any services running with that account).
Install the WinLogon Agent component of AuthAnvil on each client system and point it back to the AuthAnvil system running on our servers.
Configure AuthAnvil on our servers to have a grouped account, whose name matches the secondary administrative account we created on our supported servers, and add local users to that grouped account who are allowed to log in to the remote server.
Add the Administrator account to the AuthAnvil Override security group on the local server so that the Administrator account does not require a token to log in to the server.

We have started rolling out this configuration this month, and so far it is working according to plan. The benefits of this arrangement include:

Local access to the sever is still possible with the Administrator account and no security token.
Remote access to the server is limited to the secondary administrative account, which also requires the use of a security token to successfully log in.
The access logging in AuthAnvil gives me an accurate accounting of hich of my staff accessed one of our support servers and when.
When staff turnover occurs, access to remote systems is denied in a single step by disabling the employees token in the main AuthAnvil system.

So for the cost of equipping my staff with the security tokens, we are able to increase the security of our supported systems with two-factor authentication, while blocking remote access to the Administrator account at the same time.

None of this would have been possible without Dana's efforts to bring quality security products to the SMB space at an affordable price. It's a very small price to pay for the enhanced security benefits our client base is receiving.

On Protection

eriq — Wed, 20 Feb 2008 16:36:00 GMT

I've already seen several questions floating around following the announcement today about SBS 2008 and some of the product details. SBS 2008 will include a one year trial subscription for both the Forefront Security for Exchange (anti-virus, anti-spam protection for e-mail) and Windows Live One Care for Server. Does that mean you have to use these products to protect your SBS 2008 deployments?

The answer is NO. Just because they're included in a "trial" version does not mean that you're locked into using these products. You will be able to remove both Forefront and One Care if you choose and use your own preferred protection software. For businesses who will be "upgrading" from SBS 2003 to SBS 2008, this will likely be the case.

But for new businesses, or businesses who are deploying SBS 2008 as their first server, the inclusion of both Forefront and One Care gives that business, or the consultant who deploys for that business, the opportunity to have protection right out of the box, either while making the decision about an appropriate product for the client, or while waiting for the preferred vendor to release a version of the protection suite that is compatible with SBS 2008, and those may not be ready at the time the product ships.

Bottom line, if you're not comfortable or familiar with Forefront or One Care and want to use your own protection tools, you will be able to.

On Sydney and Security

eriq — Thu, 29 Nov 2007 18:36:00 GMT

I’m finally getting back in the swing of things following the week I spent in Sydney with my wife and friends. We headed down to Australia for the SMB Security Summit put on my Trend Micro and SBSFAQ.com, and a bit of sightseeing as well. It was a long trip, and I have a renewed respect for the efforts our Australian counterparts to come to the US as often as they do. I certainly couldn’t imagine making another trip like that for quite a while, despite my issues with flying in general.

But I gladly went to the conference, not only to help out my friend Wayne Small, who offered me an opportunity to speak and share my expertise in the forum, but also to learn. Every chance I have to participate in an event like this is more than just an opportunity to give back to the community, but it’s a great chance for me to listen to other experts and either get reminded of issues that have slipped to the back of my mind, or to acquire new information that I didn’t have before. Being able to mix and mingle with the likes of Dana Epp, Amy Babinchak, Susan Bradley, Wayne Small, Dean Calvert, and many, many others and pick their brains about issues I’m facing with my company or my clients was a fabulous opportunity.

There were several common themes that prevailed during the myriad of discussions both in and out of conference that week. Two of the key ones were the importance of least privilege and improving authentication. Clearly, Dana’s AuthAnvil offering from Scorpion Software was a big point of discussion for bringing affordable and easy-to-manage two-factor authentication into the micro and small business arena. But more than just a sales pitch, Dana makes a clear case for the importance of two-factor authentication and how implementation of such a system can significantly improve security for even the smallest operations.

The interesting take on least use privilege, however, was not from the user perspective, but from an administration perspective. Amy and I discussed in our session on security and remote support the importance of realizing that as more and more IT shops begin to provide remote support to their widening client base, those shops cannot and should not increase the security risk to their clients in order to make it easier for them to support those clients. There was a lot of good discussion during our session stemming from some very insightful questions, and I think we all came away from the day with a good sense of things to think about within our own firms as we move forward.

One practical point that I’m starting to implement in my operation is the use of AuthAnvil to help protect those servers we support who have port 3389 open to the Internet, even temporarily. With a combination of an additional administrator-equivalent account on the network, installation of the AuthAnvil software, and a requirement that access to the server be protected by two-factor authentication, we can significantly reduce the risk of having port 3389 open to the Internet as well as increase the level of documentation when these sites are accessed. That, and it gives us an “in” to discuss two-factor authentication with our clients and work to really help them reduce their own security vulnerabilities.

Thanks to everyone who participated in the conference and helped make it a real benefit to those who were able to attend. Thanks for the insightful questions that got us all thinking, and thanks for the opportunities to not only help others improve their own operations, but to help me bring my own ship in a little tighter as well.

On Follow-Up

eriq — Tue, 13 Nov 2007 12:25:00 GMT

In yesterday's post, I covered the problems being seen in the community regarding the unexpected behavior on SBS 2003 R2 boxes because of a problem with a WSUS definition update. Given the volume of traffic that post generated (more hits in the first 4 hours of that post than any other single post on this blog, period), there were a lot of people impacted by this issue, and apparently not a lot of information out there. Yes, i found a number of threads in other discussion foums, but most hinted at the behavior an didn't document the full code of the errors, etc. So there was a lot of internet traffic and human effort expended over this issue yesterday.

Late yesterday afternoon (well, my time anyway) the Official WSUS Blog finally put up a post about the issue and detailed the causes behind it. A few hours earlier, the folks at the Official SBS Blog put up a post detailing the resolution, specifically noting that the normal course of updates for the WSUS services on the server would fix the problem so that today everyone's SBS boxes should be back to normal.

I checked on the last of my managed servers this morning, the one I left untouched to test this theory for myself, and sure enough, it updated and WSUS and the Performance Reports are back to "normal" on the servers.

So, all's well that ends well, right? Ah, not exactly.

This event has raised some concern in the community about the WSUS product and the SBS R2 implementation of WSUS. For the remainder of this post, I'm not speaking for the community, but from my own personal concerns about the topic.

Hindsight allows us to look back and see that, in the grand scheme of things, this was not a major catastrophe. In fact, the server that I left completely untouched yesterday to test the automatic update fix had no performance issues at all. The customer who uses this server didn't lose a piece of e-mail, didn't lose access to the server, didn't lose any productivity, in fact, they were never aware that there was even an issue that we were looking at. That's good, because that's one less client I have to explain this to, and that makes my life a little easier today.

But at the time we were dealing with this yesterday, we didn't have that insight. What initially looked like a Performance monitor issue quicky became a WSUS issue, and in the midst of it, we had no idea if WSUS was completely broken or what it might take to get it back or what other functionality might be affected. To be honest, when something affects a class of devices across the world, I'm a litlte more apt to spend time to figure out how this could be impacting my own client base, who I am ultimately responsible for. The lack of information was frustrating (one of the reasons I put the post up yesterday, so that hopefully someone who was seeing the issue could get concrete evidence that there was a larger problem and someone was looking into it, even if it wasn't an official Microsoft source) and I really, really hate operating in a vacuum. In total, our operation lost 75% of our business day identifying the problem, diagnosing the problem, communicating with others about the problem, and ultimately implementing the workaround for a few of our clients to get them back on track, given that we still didn't know the breadth of the problem. And I know we were not the only business impacted in this way.

Ultimately, I'm concerned that given the nature of the problem and the "fix," the community has absolutely no way to ensure that this issue won't happen again. By the very nature of the way WSUS operates, and specifically the way SBS R2 implements WSUS, the exact type of mistake made by Microsoft yesterday could happen again and bring down thousands of WSUS processes again. This fact is what is giving me serious pause about WSUS in general and the SBS R2 implementation of WSUS.

In the interest of full disclosure, I am NOT a WSUS guru by any stretch of the imagination. The extent of my understanding of the R2 implementation of WSUS is to make sure that I leave the default settings enabled so that I can see the Green Check of Health and not the Blue Check of Misconfiguration, which should help me better identify when my R2 installations are out of compliance. Reports say that those who manually installed WSUS, specifically configuing it to only identify updates that are needed by that particular installation, were not affected by the problem yesterday. In fact, since the problematic update was for a BETA build of a product that I do not have installed at ANY of my client sites since I am not participating in that particular beta, I should not have had any system pull down the dictionary for that particular product. But somehow, an SBS R2 box with a single NIC card (i.e., could never run ISA to begin with, much less one that was not participating in the ISA Nitro beta) got the definition update for this beta program and lived with a crashed WSUS for a full 24 hours. At least, that's the way I understand it, given my relative inexperience with WSUS.

This simply should not have happened.

For the next few days, I now get to spend time learning about WSUS and see how I can modify the configuration of WSUS on the servers I manage to minimize the risk of this happening again. This means I have to reprioritize my workload so that I can try to make sure my clients have a lower risk of being affected by a problem that, quite frankly, may never appear again. But given Murphy's Law, if I take the road that it won't happen again so I don't need to do anything, as soon as I leave the country (which is happening in less than a week) another mistake will happen that will impact these boxes, and the rest of my operation will be left scrambling to deal with the issue while I'm stuck in a plane. Thanks a lot, Microsoft, for recalibrating my work week for me.

Understand, I don't specifically fault Microsoft for making a mistake. Who among us hasn't made mistakes? Though some have said that this type of mistake shoudl never have occured, well, stuff happens, you know. What I do fault Microsoft for is the design of the system which allowed this particular mistake to have such a widespread impact on systems that should never have seen this specific update, ever. How did a server that's not even capable of running ISA get a definition update for a product that's not even a released product? This is what I have to spend time on now, getting a better understanding of how WSUS works so that I better understand the risks I am putting on my clients by using this tool.

Wait, did I just say that running WSUS increases the risk vector for my clients? I thought the entire purpose of WSUS was to help reduce the risk vector for my clients. Ironic.

On iPhone, Secure E-mail, and other things

eriq — Fri, 14 Sep 2007 11:23:00 GMT

I've mentioned the iPhone in previous posts and how I don't think it's really ready for prime time in the business community. Again, don't get me wrong, I think it's an amazing device, but for the folks that I consult with on a regular basis,it's just not going to be "all that" for them as a business communication tool. I do have a couple of clients running the iPhone, and one of them even tried to return it because it wasn't really doing what he wanted (I should also note that he purchased his iPhone prior to consulting with me about it).

Still, there are ways to get some level of e-mail communication set up with a Small Business Server or other Exchange server, but it requires some configuration changes on the back end of the mail server, and I've put up a couple of posts about doing just that (one for SBS Standard, one for SBS Premium with ISA 2004 to be precise).

I really should have put together something like this a long time ago, because as much as I like IMAP, it has the same core problem that POP3 e-mail does - the entire transaction is done over the Internet in clear text. No only are your username and password clearly visible to anyone who happens to be sniffing your network transaction, but all your e-mail contents are transmitted in the clear as well. By setting up IMAP communications over SSL, the entire transaction is encrypted, thereby protecting your account credentials. Unfortunately, the body of the message, unless it was an internal to internal communication, has already been sent in clear text across the internet when it was sent to you in the first place.

And I guess that's really my core point here - e-mail is NOT a secure communication medium. If you have confidential information you need to transmit to someone else, sending that information via e-mail is not going to get it there securely. Sure you can take steps to secure e-mail communications. You can read and compose your e-mail using Outlook Web Access over SSL (note that not all Outlook Web Access servers communicate via SSL). You can set up your remote e-mail client to use IMAP over SSL, or Outlook over SSL, if your back end mail server supports it. You can get an e-mail certificate that can be used to encrypt individual e-mail messages. But these are all extra steps an will not guarantee secure communications every time. If you mail server does not support IMAP over SSL, Outlook Web Access over SSL, Outlook over SSL, or another secure communications interface (how many web-based mail services actually have you both log in and compose/read e-mail over a secure web interface) then at least one portion of your e-mail communications will be sent across the wire in clear text. If you have an e-mail certificate, but the person you want to send to does not, you will not be able to encrypt an e-mail message to that person.

Yes, there are ways to secure e-mail. It will take some effort. Last year, I had reason to have secure communications with a local vendor that I worked with. My side was secure (Outlook over SSL, Outlook Web Access over SSL, etc.) and we both had e-mail certificates so that I could encrypt messages to him, and he to me. I feel fairly certain that those encrypted messages we exchanged were as secure as reasonably possible. But one he received and decrypted the message, Ihave no idea if or how it stayed secure afterward.

So if you've been thinking that e-mail is a nice, convenient, and SECURE way to communicate with business or other associates, please clear this myth from your mind. If you haven't had to jump through a few hoops to set up secure e-mail, you don't have it.

This sounds like a good topic for a radio show. I'll probably work that in for next week's eOnCall episode.