So you can be the one responsible to fix other vendor's software and web sites when they fail to run on other browsers. Have fun with that. Not everyone can switch and still function. It may not be the fault of the company using IE. Also, you have to look at organizations like Hospitals that are under regulations that may make it impossible or expensive to recertify equipment. A good example is the FDA regulating product certification systems. Changing out a system design can cost tens or hundreds of thousands of dollars to recertify a design.

I have my fun with Linux and use it in various ways, but it isn't always the easiest thing to just swap out in a workstation setting. You apparently have very limited knowledge of the various industries and exist in a world where your way is the only correct way. You can go have fun with your copy of Linux, but don't assume it fixes everyone's issue without understanding what they do. If they can switch and still function, great. For purely desktop/laptop environments, Microsoft still has ~90% market share.

I saw it show up on my WSUS server today for XP on up.

This response was supposed to be a general "what should I do" not "what can I do" type of question. I used the browser topic as a sample, but yes they have released the patch. If a vulnerability was published today, you cannot just assume tomorrow they will have a patch ready to ship and hence why the question was asked how to handle a situation of such.

It depends on the size of the shop and the IT staff. As a one man IT shop, I would be the one creating, testing, and implementing. Not saying everyone is bad at that, but I happen to know my scripts and GPO objects. In the workaround, they clearly gave instructions for running the fix at a command line. That part would not be difficult to do and if it were serious enough for a large organization, they would most likely already have a rapid test process in place for a vulnerability like this. You would still have to educate the users on a new browser should you push one out, but at least you can reduce the time needed for IT to go to every computer and manually install the software. You wouldn't have to instantly switch it to default.

As for the GPOs to manage the other browsers, it depends on how they store files. But to prove you wrong on Chrome not having them, here: https://support.google.com/chr...

EMET should have been a 3rd option, but I wouldn't recommend every shop immediately go out there and implement it without understanding it. There are many complicated things that it helps mitigate and improperly implemented could cause more headaches to the help desk. That being said, I have started to research it for other reasons so I won't knock it being a worthwhile investment.

Also, you better hope you are on the latest version of EMET, because 4.1 has been bypassed and it is only a matter of time for newer versions: http://bromiumlabs.files.wordp...

Now go back into your hole since you are too afraid to stand behind anything other than AC for your post name.

In the case of the browser, there are a couple of things I would have done:

1) IT should have selected a viable alternative. Whether it is Chrome, FireFox, etc... IT should be deciding on one to use. You are right in not wanting to bog down the help desk with these calls. By selecting one you can send a message out to your users stating that to improve security, reliability, and performance of your system, we will begin rolling out a new web browser for everyone to use. Be sure to include time for a quick training session. There are various methods for pushing software out behind the scenes as well to install it without bothering many of the workers.

2) Used something like Group Policy to push out the workaround and disable the DLL in question. This could have easily been done using a login script or GPO. Then you could sit tight waiting on a patch for your existing browser. You may still want to remind everyone to be on the lookout for anything suspicious and report it should something happen.

The sad fact is that nothing is bulletproof. It could just as easily be Chrome or Safari next week. Don't forget Safari had a nasty SSL flaw not too long ago too. You are right in not wanting to scare your users, but that is where I say you need to put effort into education on the basics of security. Let them know you have their back. And above all, be creative.

I would recommend the use of either Windows Software Update Services (WSUS) or in combination with System Center Configuration Manager (SCCM). WSUS allows you to approve/unapprove all the updates you want to allow in your network. You can group specific computers to a specific set of approved updates if you would like. You can also use SCCM to manage the change control, what was approved, and what was installed. SCCM can also be used to deploy updates in certain circumstances.

Of both of the options, WSUS is free and can be installed on Windows 2k3 or newer. SCCM is now licensed through the System Center package which may or may not be worth looking into if you want to look at the other built in components to it.

I completely agree. I should also mention there have been XP updates in the past (though not like a full service pack) that required you to run before any other update would show up. But alas, nobody probably remember the updates to Windows Update that did this.

The point Microsoft is making here is that 8.1 is going to be supported, but it requires this one update for any future updates. This is probably due to many of the new features and changes to the UI they have implemented. They also probably could have worded it better.

That being said, they need to fix the current issues with their patch first. Namely the TLS issue because if you do not have 2K8 R2 or higher for a WSUS server then you have to turn off SSL because lower versions cannot support TLS 1.2.

Probably not entirely true right now because most of their development has not touched the SDKs for these platforms. It is still a work in progress and their new Unified App framework will most likely make your desire a reality. The fact that they went from Windows CE during the Windows Phone 7.X and earlier days to an NT kernel for 8 shows this progress in the phone space for Microsoft. It also helps that they are migrating from XAP apps to Appx. The new Xbox One uses something based off Windows 8 components (At least kernel, not sure of anything else). Even the Windows for ARM called RT (Big fan of mine by the way for all the haters out there).

They are getting there, but it is not an overnight accomplishment. That would be like saying tomorrow PS3 games will work without recompiling on an Xbox. They have to update headers and references to SDKs they are using to make it work on another platform. This is where Microsoft is really wanting to head with the Unified Apps. They want to have their framework on everything so you do not have to recode. Even better that they are open sourcing good portions of the .NET framework. That would potentially mean that even Android/Linux could use the same app in some ways.

Just saw that. This will be interesting to see. I hope it means only the framework and not 3rd party libraries because that could make licensing or detecting 3rd party libraries interesting. I know I would want my library to still be separate unless I give you the code.

All code ends up at one point or another as native code running against the CPU. There may be several stages before it ends up in native code. Interpreters take the code and convert it into instructions the CPU understands on the fly. The fact that .NET gets converted into CIL means that it should be at least partially interpreted. The JIT compiler is the last step that compiles it into native code for the CPU, but this happens before the code block executes. Now, there are technically ways of using the .NET NGEN tool to pre-compile for the system the code sits on, but until it hits the JIT compiler it might as well be an interpreted language (i.e. C# to CIL). This is why they are just now announcing this native compilation tool where it takes out the CIL step completely. Because .NET currently needs to first be converted into byte code before hitting a compiler, I say that it makes perfect sense that it can be considered interpreted at least to the point of the JIT. If my definition of an interpreted language is wrong then I accept that I am wrong. Most of my beliefs on this stance I would base off of the ECMA-335 specification.

Not true. Native only means that there will be no IL (Intermediate Language) code. Right now .NET is more interpreted than it is compiled. This would mean it gets compiled like C or C++. You would still need the .NET redistributable for any libraries you reference just as you have done with C++ libraries or DLL libraries in traditional Windows development. Not having to compile the code before executing it (using the JIT compiler) means serious performance, but also paves the way to more native support on other devices. Especially since they released it into the open.

I use CrashPlan at home for my 18+TB Home Brew SAN. I have 1 VM running as my file server that has about 10TB of the total storage assigned. I switched from Carbonite to CrashPlan because CrashPlan does not limit bandwidth like Carbonite does (2Mbps for first 200GB and then 200Kbps thereafter). It would have taken me more than 11 years to backup 4TB to Carbonite, but with CrashPlan and my 35Mbps Upload, it took me about 1-2 months for the initial backup of 10TB. Now it only syncs the updated files and has no trouble keeping up. I should also add that you can use CrashPlan to backup to a friend or external hard drive from the same app for Free as well. As for the paid subscription, Business is $7 per PC for unlimited storage and home is like $7 per PC and $14 for a family plan of up to 10. Home edition does not limit installs to non-server systems (as I use mine for personal use). * I am not a paid representative of CrashPlan. Statements are based on personal opinion or experience.

Easier.

Windows 8:
Move mouse to bottom left corner and right click. Pick either command prompt or command prompt in admin mode

Windows 8.1:
Right click start logo. Pick either command prompt or command prompt in admin mode

From that same menu I have quick access to options that took more than a few clicks to get to before. Also in 8.1, you can use this to shutdown or restart.

Personally, I find using the Windows Server Certificate Authority to be great for internal sites. The reason is that it automatically pushes the root cert trust to all domain members. It is also very easy to do a CSR to the internal cert server from IIS. Since you have to still do a CSR no matter how you do your "trusted" cert, going this route can be fairly painless. The other benefit is you can then use your internal cert server for other purposes such as company email signing, encryption, etc... You can also use OpenSSL, but it may take a little more to configure, but it is free. If you have a domain controller, you can just tag on the cert authority too if you are limited on Windows Licensing or hardware.