ActiveX is Satan's Execution Environment. From Hell.

I went live with a simple but rather marvellous little change -- all the groups which deliver bulk machine or account admin privilege have been dropped into the group that denies browsing on the proxies. That's a huge win -- a vital step forward now that so many legitimate sites have been perved up to push BadSrc exploits and the Dear knows what else. The admins have two accounts, and if they want to browse from their workstation, they have to make sure it's not a member of any of the privilege groups. We're not mandating how the support teams arrange accounts, we're not touching anyone's permissions -- we're just declining to accept the risk of admin browsing.

It's good. I trialled on it myself and -- for six months -- on the domain admins. I gave support six weeks notice and a pile of reminders. I engaged with anyone who asked for advice on the technicalities. (It mostly boils down to using runas and getting a second explorer instance.) I've written a page on the support wiki, and for those who can't handle my writing there's advice from Aaron Margosis. It seems there are no tasks that require admin privilege browsing. Everything should be good, and our vulnerability surface hugely reduced.

Except for ActiveX. One of the Desktop team's top-twenty calls is to install or update an ActiveX applet from an external web site. And there's no way round it -- you do need to browse and you do need to be an admin, because what you're doing is exactly what malware does -- it's just that you happen to trust the site.

There's no need for this. I don't see ActiveX giving any better user experience than JavaScript -- it's just bad design. But it has to work.

I'm not going back. But:

• It's pretty plain that this can't be handled with Windows permissions. ActiveX is too broken. And anyway the philosophy of this change has been to leave Windows access alone. 
• So we have to look at the other side. When we do this at the moment, why is it OK? It's because the admin, reassured by the user, trusts the site to be safe, and required for business.

Naturally the block imposed by the no-browsing group is right at the top of the proxy policy. So I'm going to go in with a rule immediately in front of the block. If the user is a desktop admin, and the site is in a static list of "Approved for ActiveX" then the browsing is allowed, and the blocking group won't get a chance to take effect. There's an extra step to get new sites into the list but I don't think that will be too much inconvenience, and like the rest of this change, it's the sort of control we should have had a long time ago.

We have to settle who will approve sites into this list, but that's easy: I will.

Next step: probably to enable fast user switching on the desktops, to make life easier all round.

Time for Tubby Bye-Bye, Meestair Bond

Well, the NMAAJS Daughter has been on Club Penguin for a month or so, and she's been enrolled as a secret agent. You get a tool to move around the site more easily, a range of mission games, a secret tunnel from the sports shop to the surveillance HQ and some fine clothing options like a bow tie and a tuxedo. (Why on earth would a penguin -- the world's most sophisticated bird -- need a dinner jacket?)

But the real meat is in the handbook. You have to report mean penguins and the ones who use bad words, so some harried moderator in Tucson or wherever can review the log and decide on an appropriate action.

Little do they know that the NMAAJSD has essentially no chance of spotting bad language -- we were watching two potty-mouthed puffins F Uing and F U 2ing and she had no idea what it meant. And this is the child who, on her fifth birthday, addressed the author of her being in these terms: "Just fuck off, Daddy."

Still, you have to give them credit. They're at least trying to make it fun to be a snitch, and that puts them a little ahead of the Staasi.

Naming Risks

Jerome Kerviel seems to be on the edge of getting a risk named after him. This is not the sort of distinction that will make his mummy proud, but it is a distinction nonetheless. About the only other named risk I can think of immortalises the otherwise obscure Herstatt Bank closed by regulators in 1974 before it had paid out on its forwards settling that day.
Kerviel's activities are set out in the Mission Green report, and if you were following the story at the time, it's interesting to see how wrong the initial spin was: He wasn't stealing passwords, he wasn't modifying control spreadsheets. He was exploiting his back office knowledge, but at a higher level: he knew how to use cancellations and corrections -- all the points where control can't be watertight because trading isn't -- to get his positions off the records, and he'd been doing it for some time. (It was only right at the end that he started to fake forwarded email -- nothing complicated, just editing a real forwarded email.) So this gives us a useful term: Kerviel risk is exploitable vulnerabilities -- uncompleted cycles of review and follow-up -- in a control system. A short name for a rather complicated concept, so maybe it'll stick.
No this definition means that Kerviel's name is not correct for authentication-abused-to-approve-fraudulent-actions risk. But Jagmeet Channa has come along just in time to help us out. He stole a couple of passwords to approve his multi-million pound transfers to his accomplices in N. Africa and Manchester.
The problem is figuring out what risk we're naming here. Channa's not talking so we can't tell if it's:

• Password stealing? -- he certainly did, but maybe that's not the point
• Inserted Insider?
• Coerced Insider?
• Criminal Mastermind who recruited outside help?

I'm going with the authentication, for the present. Channa Role Risk.....
And what makes this a security story? Well, the investigation started by interviewing the colleagues whose passwords Channa used. Don't fancy being in an interview like that? Then guard your password.

Wasted Time

I spent some time going through the security morning checks with Internal Audit.

Report on event logs every morning, examined every morning, security incidents found in three years: none. Firewall traffic logs, examined ad-hoc over four elapsed years, security incidents found: one - an agobot infection on a bad build.

Hours wasted -- hundreds.

We're doing the wrong thing.

What's the right thing? There's too much novelty and too few admins in our network for IDS to be worthwhile. Just retain the logs but stop looking for trouble? The trick will be to do that, but keep looking responsible.

Last Logon Time

I have discovered a fascinating little gobbet of truth about the Active Directory 2003 records of the time users last logged on. The summary is this:

• The Last Logon attribute tells us nothing useful. It's the time the user last logged on to the domain controller the query was run on. So if you run the query on a DC that doesn't do much authentication, you'll wonder why no-one has been logging on lately. Ignore this attribute unless you are gathering records from all DCs and selecting the latest...
• The Last Logon Timstamp is different. It's the time the user last logged on to any DC in the domain. Aha! Problem solved? Sort of -- because the attribute is replicated across the domain, you'll get the same answer, give or take replication time, regardless of the DC you query. The only little fly in the ointment, leaching dark fluids and tainted chitinaceous fragments into the smooth white emulsion, is that replication time. It's not a minute. Or an hour or a day or a week. It's a fortnight.

So the proper interpretation of this field is something like this:

• Blank: If the user has ever logged on, they must have done it in the last 14 days. Or perhaps they never have.
• Date: The user definitely logged on on that date, and may have logged on any time up to 14 days after.

In practical terms, that means your script purging not-used-lately or totally-unused accounts can't delete an account on the basis of a blank Last Logon Timstamp. If you want to delete accounts that have never been logged on, you'll have to find another way.

Insourcing Authentication

It's appraisal time and the focus is on the performance management system. That's outsourced -- Internet delivered and hosted somewhere in Florida.

The issue that was brought to me was concern that users might be saving their performance management password in the Internet Explorer credential cache. It's never something that's worried me very much -- if you lose control of your workstation session, you've lost a lot more than the right to express an opinion on that annoying support guy with the awkward questions....

But it tied up some ideas that have been rather weakly formed in my mind.

We're outsourcing more and more, and the result is that our users do their jobs with accounts on this system and accounts on that, and I have no real confidence that there's even a consistent list. I'm certain that there are some systems a leaver will retain indefinite access to, simply because the whole service was set up by the business with no IT involvement and the helpdesk will never know to cease the account. This is pretty galling when we've recently put so much work into the Joiners/Leavers/Absentees process and the unused account purge. We're actually getting on top of this, but it's slipping away though a side door. There's certainly no hope of enforcing a consistent account name or password complexity policy.

At the same time, to deal with the many sites like Blogger, Delicious and others that I use all the time from loads of PCs, I've been looking at OpenID, a public authentication system, that allows the administrators of an Internet hosted application to securely trust a logon completed at a different site. I've gone so far as to set up an OpenID on the Verisign test site, even though I've nothing to log in to it with.

So I've been toying with the idea that authentication was a service we could outsource -- to Verisign or perhaps a two-factor supplier. In fact, I had that exactly wrong. Authentication is the one service we can always do better than anyone else because no-one can know better than we do, who works for us. This is true even if we don't know very well ourselves....

So we shouldn't outsource -- we should insource. We should provide an OpenID service as part of our infrastructure support for application outsourcing. Then we become the authority on who works for us, and what tests they have to pass to prove it:

• Log on from inside, and you just need a logged-on Windows session; log on from the Internet and it'll ask for your RSA token.
• The helpdesk can cease your OpenID when you leave, so terminating access to services they don't even know exist.
• The authenticator could decline to recognise remote applications completely or on a per user basis.
• Choices about access to the dodgier stuff like the password reset tool, or remote access can all be made here.

So it would all be fabulous. Just a couple of problems:

• There doesn't seem to be OpenID software with the flexibility and convenience I need, and
• The chances that application hosts can be persuaded to recognise their customers' OpenIDs seems close to zero.

So this frankly rather wonderful approach, which ought by rights be standard, is dead. But I think I'll put OpenID support on the qualification form just to watch them squirm.

How policy suceeds, for once

I've been purging out a dying domain. Disabled accounts with a last logon more than three months ago are deleted; enabled accounts with a last logon more than one month ago are disabled with a note in the comment. Do that every week or so. Keep a safe list for genuine service accounts and the domain will be nicely compliant by the time it stops.

The reason I've had to do this myself is a bit sad: the helpdesk, who own all account administration, will go through any distortion to avoid account difficulties. An odd-looking account -- precisely what should be disabled -- won't be touched for fear of breaking something. The policy itself gets re-interpreted to be "disable after ninety days" with no-one able to trace where that decision came from.

It's understandable. The best outcome from good application of the policy is that no-one complains. The likely outcome is senior staff complaining that the helpdesk has broken their account -- and no-one wants to hear that.

So, I've been doing it myself, and that makes everything different. Everyone knows that I break stuff, but everyone also knows that challenging me on what I break can leave them on the wrong side of a clearly distributed policy that they didn't read or understand....

Yes, and in this case I did a blinding job: The account policy allows just two types -- owned, which are subject to the AUP, and service which have to be on my list. The AUP says that owners are responsible for owned accounts, have to log on more often than once a month, and log off after no more than a week. That was carefully chosen to update the last logon time, and to transfer blame.

And it works! Hundreds of users deleted, a few tactful explanations, and no trouble at all. This is the root of the security truism that you start with a policy. You can't act without it -- but it has to be a good'un.

Audits fall with autumn leaves

We've just been visited by one of the many audits to which a regulated firm is subject. We didn't come out as well as I would have hoped but the point for me was different and more worrying.

These were competent people. They were clear about their wants: Evidence that the controls we publish and claim to adhere to are actually working. And they knew what "working" meant -- that the circle is closed with human escalations and choices on exceptions. So that was good (and a lot of work for us) except for one teeny issue.

"Working" also means that the control environment will actually stop trouble. And these guys had essentially no interest in the technical effect of the controls. If I said "this is a report that shows yesterday's changes to all application admin groups", that was the truth. No test that we have the same reporting on all production DCs. No enquiry about alternative ways to get the privilege. No test that our installations actually adhere to the admin group conventions. If I listed a firewall policy, or handed over the perimeter network diagram, that was it. No enquiry about how often I checked the cable patching....

Now I know that they can't check everything. And I wouldn't want them to.... I know that they're at the wrong end of a crushing knowledge asymmetry. But all the same, it reminds me of the drunk searching for his keys under the lamp post: not because he lost them there, but because the light is so much better.

In the mean time, remember:

• A big four signature on a statement of controls -- SAS70 or whatever -- means less than you think.
• Somewhere in the big city, a security guy is neglecting controls that expose trouble in favour of those that'll audit well.

The Approver as a Conceptual Bottleneck

I'm looking at a list of domains groups which control access to removable devices and media through Pointsec Protector (which used to be Reflex Magnetics Disknet Pro). We've had groups for various types of devices and now I'm trying to simplify -- to operate a much cruder level of control.

I'd prefer to leave it as it is, but the membership of the current groups is a mess. The technology is fine, but the control environment stinks. At present we allow or deny access to the groups based on a managers approval: "he has a business need to use a USB key" -- and that makes a good deal of sense. Who else can make that choice?

Who else indeed? Because the managers aren't technical -- so they don't understand what they're approving -- and they don't see any downside from insecure access. Essentially every request gets approved. And in six months time when the the lists have to be recertified, it's probably a different manager, or the original justification is forgotten, and it's easier just to agree. We've got adequate technology, and a process that the auditors think is just fine, and there's no real control at all.

Of course, this isn't just a problem for USB devices. It very easy to fail at this last hurdle by asking approvers to use a discretion that they just can't understand.

I've thought about making these accesses part of the permissions attached to the job description global groups. But that doesn't reduce the problem unless IT security can engage with the role definition approvers, and we don't.

So this is my plan: I'm going to name the groups after the risk, with alarming group names and descriptions:
Risk In -- "Trusted to read data from unknown sources"
Risk Out -- "Trusted to send corporate data to unknown destinations"
Device Risk -- "Trusted to attach untrusted and untested devices"

Let's see whether that gets the message across.

Reporting Permissions

I've been spending the quiet period after Christmas working on some scripts. For some time now I've felt the need for a report of permissions, hierarchically by directories in the DFS, and also per trustee. Reports like that would let me see a lot of things I want to see:

• Permissions on users: no users should have direct permissions
• Permissions on uncontrolled groups: if it's not a ROLE group it shouldn't deliver any access in the departmental filing
• Everyone/all users permissions: almost never correct
• I could run them on servers as part of the compliance checks

They would also remind me that there are things I want to address:

• ACEs referring to deleted accounts and groups -- There's a handy subinacl option to remove this
• "Domain Admin" permissions -- one of the techs here solved admin file access problems that way -- when what he needed was local administrator permissions
• Permissions delivered by SID-historied groups that need to be dropped or replaced

A good thing all round. The only problem is that they are very hard to get. It seems like there would be tools to do this, but I can't find anything suitable. Only after spending days hunched over a hot interpreter have I found why: it's moderately difficult, and the semantics of the report are surprisingly tricky.

• The simple approach doesn't work. If you build a hierarchy and read and report the ACL masks for each file and directory, the output is unusably difficult to understand. Even on one object there can be multiple ACEs for each trustee.
• And there's just too much data. Even if people could understand the access options implied by mask bits and types, there are ten million objects on our file servers. No-one reads a ten-million-line report.

The approach I've come up with with pretty crude, but I'm hoping it's going to do something useful:

1. Don't try and represent the subtleties of permissions. Boil everything down to (none) Read, Write and Deny in that increasing order of priority. For any given trustee, only even think of reporting the highest priority. Fancy stuff like "deny execute, allow read" just shows up as the single "highest" permission: in this case it's Deny. (Oh yes, at this level, Deny is a permission, regardless of DACL type flags and ACE masks)
2. Don't distinguish between inherited access and directly granted. What matters for reporting is the actual access. When you come to rectify, you'll need to know how it got there, but the Windows tools are good for that.
3. Do use the concept of inheritance to trim down the report. The only permissions you need to report are where something changes. If a trustee gets a permission in the root of a ten-thousand-directory, 300-thousand-file volume, and every file and directory inherits it or has had it applied, then your report for that trustee is one line, not a third of a million lines.
4. Assemble your basic reports for each trustee -- it makes the purging much easier. If you want to report a single directory structure with entries for all trustees, you can mash that together later.
5. I've found three levels of interest in files (when they need a report at all)
   • Leave them off entirely -- seems brutal but it cuts the run-times and you don't lose much
   • Report them as a single aggregated pseudo-name "[one or more files]" for each directory -- this effectively raises a warning if any file is more permissive than the settings on its directory
   • Report each individually following the same rules as for directories
6. Expect to translate between the names you use to extract the permissions, and the names you report. Consider a DFS for example.

The down side of all this simplification is this: it's simple. That Everyone/Full permission that appears at the root and inherits all the way down is highly significant, but easy to miss. After all, it'll only be the one line. I think this means that we still need to apply automatic policy exception detection, but that is a project for the future.