Monthly Archives: September 2007

Information Security – experts vs process.

Computer Security is full of experts… Steve Riley, Jesper Johansson, Michael Howard, Bruce Schneier, Window Snyder, Thor Larholm, the list goes on and on. [Sorry if I didn’t include your favourite expert, or if you disagree with my list – there’s at least one name on there whose comments I frequently disagree with.]

Do you have experts in your security department? Good, because you do need them – but you can’t, shouldn’t, mustn’t, rely on them as your entire defence against the wide world of evil.

Your company’s IT security should operate largely without their involvement, because you should have processes in place to operate your company’s security.

Experts, even the really clever ones, make mistakes from time to time, they leave, they die, they get caught up in ego wars, and you should manage their contributions on the basis that they are transitory.

Use them while you have them, because they are the foundation of your security – they are the key human element that makes your IT security better than a simple installation of the latest 3-pack of firewall, anti-virus and anti-spyware that you pick up with a rebate at the small computer store that sprang up in the ashes of CompUSA.

But if you’re not using these experts to analyse your IT and design new processes, then you will gain no permanent benefit from their presence, and when they leave, you’ll have to find another to replace them as quickly as possible.

[The process I’m partial to is a direct feedback loop. The guy with the job – and ability – to fix the problem, is the guy who deals with those who experience the problem. It’s not always possible or appropriate, of course, because very often that results in fire-fighting exercises. At some point, you have to stop fighting fires long enough to build a fire engine, and to tell the engineers to stop building things out of wood.]

Build processes that last, and use your experienced staff to build them – but not to operate them. Your best process will be one that can be operated by someone the first day they’re on the job, and that will start that operator down the road to becoming more experienced. Eventually, he’ll be your expert.

Why complain about UAC prompts?

Jesper’s article in TechNet Magazine on the purpose and future of UAC in Windows Vista and beyond reminded me that there’s a whole slew of behaviours more annoying than UAC’s prompting (which, as Jesper points out, is only the most visible portion of a system-wide and company-wide approach to the future of Windows development), and which users apparently don’t hate enough for vendors and IT departments to cry for changes.


UAC elevation prompts from tools that shouldn’t need elevation.


Seriously, this is just a sign that the developer was an administrator, and the tester was an administrator, and nobody bothered to make the program work for non-administrators by removing requests for privileges that aren’t actually needed.


So, instead of fixing the product to remove the demands for administrative rights, the developers simply added a manifest to make the software insist on elevation.


If you’ve got non-administrative software that prompts for elevation as soon as it starts up, you should be asking your vendor whether this is their long-term fix, or whether this is just a temporary workaround while they engage in what can be a long process of removing elevation.


UAC elevation prompts for administrators running administrative tools


While performing their administration function, these users should be in an administrator session, and should have enabled silent elevation through Group Policy; while not performing their administration function, they should not be in an administrator session, and elevation should be disabled.


While that may have been awkward and cumbersome in Windows XP and before (although “runas” goes a long way towards providing this sort of separation), in Windows Vista, Fast User Switching is enabled for even domain-joined computers, allowing you to choose whether to be in a restricted user session or an administrative user session.


Spending most of your time as a non-admin means that when someone comes looking for the admin user who infected the company with an Outlook worm, you can point to the fact that your admin account isn’t set up to run Outlook, so it couldn’t possibly be you – phew!


Requests to re-identify myself


This is the big one for me, though – why aren’t people complaining the same way about applications that ask the users to authenticate themselves again?


Why haven’t these applications been fixed to use other methods of authentication?


When I fill in my time-sheet, I’m required to provide my user name and password. Again.


When I connect to the company training web page, I’m required to provide my user name and password. Again.


Every place I’ve worked, it’s the same thing – there’s a pile of applications that are necessary to, or related to your work – whether it’s training, time-sheets, benefits checking, prescription filling under the company-provided insurance plan, or whatever – they’ve all required that I identify myself to them – again – even though I’ve already identified myself to the domain on this computer.


Maybe this is acceptable and appropriate for those operations where you want to make sure that somebody hasn’t stepped in to the user’s cube while the user was away – but those operations should generally be limited to unlocking the locked workstation, changing the user’s password, starting up an elevated process – not routine operational work.


After all, if you start requiring the user to enter their password everywhere, you’re teaching the user that he should be blasé about repeatedly entering his password several times during the work day – then when the phishing email comes along, with a request to log on to an external web site, that user will happily give up his user account and password (which will most likely be the same as his password on every other system he’s used).


There are good alternatives.


A couple of obvious approaches for web-based applications are Windows Integrated Authentication (which, admittedly, does require IE and IIS), and SSL client certificates.


Thick-client applications are also usable, as long as they aren’t against your company’s religion.