If you tell enough stories, perhaps the moral will show up.


The .Net Developer's Guide to Windows Security

Just a quick note to big up Keith Roberts and his book "The .Net Developer's Guide to Windows Security". Don't be foxed by the ".Net" bit -- it just means "Modern Windows". The whole text is online but it's well worth buying the book simply because it's broken down into five and ten minute chunks, so that a couple of month's toilet visits will have you knowing more than you want about every major topic in Windows Security.

It's not a management or policy text and knowing all of it is not obligatory, but this book has helped me deal with issues that ended up on me because apparently I know this stuff. I don't -- I stole it from Keith. Just as examples, check out How to Develop Code (and do other stuff) as a non-Admin or How to Store Secrets on a Machine

Serious, practical stuff.


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.


I saw the Comet!

Weather today is dreadful, wind and rain, but yesterday was totally clear and I saw comet McNaught.

17:10 in central Kent, bearing about SE, in the orange glow above the horizon. Tail subtending about 1/4 of the full moon, leaning slightly to the right and tighter toward the horizon. Could have been a cloud but it looked cometty to me. I've never seen a proper tail before.

As soon as I saw it I raced home to show the less mad son, but it had set by the time I got there.


I Want a Video Server

There's a device I want to buy:

  • On the input side, composite video and sound -- at least four inputs capable of handling the feed from security cameras. Not digital, not USB -- just cheap cameras.
  • Processing: Support for video motion detection would be good.
  • And output: a stream server for live-ish video and automatic upload of motion-detecting images to a remote SFTP server. Email/text alerting driven off the motion detection makes it useful.
One of these in the attic with some strategically placed cameras would provide some worthwhile security.

It's essentially just the works from an IP camera -- it should be a few hundred pounds at Maplin. But it doesn't seem to exist. Bummer.