Are Apple Products Really More Secure?

I found this article today published on Beta News: http://betanews.com/2011/09/26/are-apple-products-really-more-secure/

It’s a pretty interesting read.  As most know Apple products are not virus-free, however they have nowhere near the same amount of viruses, worms and Trojans than have been created for the PC.  The simple explanation of this is that PCs are simply sold more often than Apple computers.  However, the author has cited an increasing trend in the sale of Apple computers and more importantly Apple devices like the iPhone.  He suggests that the iPhone provides the larger target for the bad guys as those sales are through the roof.  I would also argue that Android is also in the crosshairs, especially with a product whose source code can be found online.

Thoughts on the matter?

Brent

Windows 8 loaded on ASUS EP121

2011-09-15_12-53-58

I downloaded the Windows 8 Developer Preview bits last night and thought I would give it a try on my ASUS EP121 tablet.  The tablet works pretty well with Windows 7 and has enough power to really do it justice.

Needless to say getting it installed was easy as pie and getting it setup was even easier.  The overall interface is very easy to use.  I’m still a little unsure about how the new UI is the focal point when you look at the business market but hopefully the betas and release candidates flesh that all out.  For the time being I’m excited to give it a shot.  I’ll try out Office and Skype on it over the next few weeks just to see how that all works.

The best part for me was all of the drivers for the Wacom input as well as the touch screen just worked, nothing extra I had to do.  So far I’m liking at least the integration of components and the ease of use.

Brent

Office 365 & FOPE File Extension Exclusion Dictionary

I'm attempting to lock down our SPAM and Firewall settings with Office 365 and FOPE. One of the key things we want to do is prevent certain file formats from both entering and leaving our organization. This is often a common request among E-Mail security people. FOPE allows you to define all sorts of rules using Regular Expressions (RegEx) or using Dictionaries. Dictionaries are simply large CSV (Comma Separated Value) files that contain all of the extensions to be blocked.

The FOPE Admin guide provides a good starting list to build a dictionary. It's pretty hard to use RegEx for file extensions, if not impossible. I'm providing the CSV file we used to secure the system. It's a pretty good starting point and covers most files that can execute on a Windows box. We also included some of the OSX extensions that can execute as well, although this was not our primary goal since we have 1 Mac using the service.

For more details on uploading and defining policies take a look at the FOPE Best Practice Guide: http://technet.microsoft.com/en-us/library/ff715282.aspx

Brent

Click here to download:
File Extension Dictionary.csv (0 Bytes)

Active Directory Federation Services and Office 365, a Simple Setup

Background

I recently went through the motions of setting up Active Directory Federation Services (ADFS v2) for Kreisler to allow us to begin using Office 365 with federated authentication. We have some other potential uses for federation coming later on as well. This post is not meant to dive into how we set everything up because for the most part it was relatively simple. The Office 365 documentation is very helpful and if you follow it step by step you can accomplish what you want. However, a few parts in particular were confusing for me and took a couple of tries to get right. They are:

  1. SSL Requirements
  2. Domain Name Forwarding and Requirements

For those not familiar ADFS does require SSL certificates and in a production environment you need to purchase at least 1 certificate and possibly 2 depending on how security conscious you are. In addition if your network is similar to ours you need to work some DNS trickery to get the desired end-user behavior.

Our ADFS Design

We don't have a large user base so having a large server farm is not required and even for small businesses (400 or less employees) this farm will support the load just fine! Our farm is composed of the following:

  1. One ADFS Server
  2. One ADFS Proxy

It should be noted that we decided to utilize our existing MSSQL infrastructure to host the ADFS databases and not the Windows Internal Database.

SSL for ADFS

So the documentation in Office 365 in regards to the SSL setup is somewhat confusing. Here is what it boils down to. You MUST generate the initial certificate request from your ADFS Server, even if this server is not going to be publicly facing! In addition for each certificate you generate make sure the Common Name is identical for each certificate you request. In our design we requested a single certificate. Once you get the certificate loaded life should be good, but then you have to install the Proxy. You have two options here:

  1. Export the certificate from the ADFS Server, or 
  2. Request a new certificate

Security Experts will say to use number two because if the public facing certificate is compromised so is your internal certificate. Then again if you don't have hundreds to throw at SSL certificates number one becomes very appetizing. You can follow standard IIS help and instructions for exporting and importing a certificate from one server to another. Once we got passed the certificate problems we were able to get the system up and running properly.

DNS for ADFS

The idea with ADFS in a Server and Proxy configuration is that internal clients will utilize Windows Integrated Authentication to login to the federation server while external clients will be redirected to a form to attempt to login. Here's the problem with this:

  1. The Common Name from your SSL certificate should match the publicly accessible DNS A/AAAA record for your Federation Service. 
  2. The proxy by default receives all public requests, which is normal. 
  3. Internal users will still make a call to "fs.mydomain.com" which points them to the Proxy as opposed to the Server, this causes internal users to have to login.

The documentation again is somewhat light in this area. There is lots of talk about setting up HOST file definitions, which if you ask me is somewhat archaic. We took a different approach, DNS. We setup a new forward lookup zone in our Active Directory enabled DNS servers for "fs.mydomain.com" which meant that the server now becomes authoritative for our Federation Services sub-domain, so any internal requests will now get processes by our internal DNS servers and not get forwarded to external servers. The last step was to simply create an A/AAAA record for ".fs.mydomain.com" to point to the Federation Server. Now any request for "fs.mydomain.com" gets sent to our Federation Server.

Ta-Da

Again, these are just some of the larger problems we had getting things up and running but it appears to be working like a champ at this point. I'll have another post in the future to help customize your Federation Forms Login page to brand it and customize the behavior.

-Brent