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.

Adsense

Running Adsense is more interesting than you would expect:

• I can speak freely, because I know that no-one -- literally nobody except me -- is reading this. That's not a gloomy observation based on absense of comments and feedback: It's hard fact taken from from the excellent hit records that Adsense provides. If I had a website (I don't), and I was lazy (I am) I'd put up an Adsense block just to get free analytics.
• The algorithm used to target ads is excellent. I know this because I keep wanting to click on them. In the same way that cannibalism ought to be the best diet, the adsense Ads on one's own blog ought to be consistently enticing, and they are (though I could do with a bit more hedging/forestry). It's really quite frustrating (Adsense subscribers know why).
  

That Google Account

Has anyone noticed how useful Google Docs has got lately? Obviously it's not Office 2003, nor Open Office 2, nor even Office 97. But I'm more and more finding it to be the natural home for my reference documents, drafts and other oddments. The collaboration features look interesting, and probably work well for all I know, but for me what counts is the accessibility from any of about half a dozen computers. Content search and tagging isn't a huge deal at the moment, but I know it'll save my bacon when the volume goes up, or when I upload all that stuff I used to keep on my Palm.

The limitations and problems are more and more obviously the consequence of hosting it in HTML. The tables reek (I do a lot of things in tables) but HTML tables do reek. Layout for paper is actually useless -- but I'm blaming the browsers.

And really, I find that there's a large slice of what I do where rough and ready is OK -- almost anything is OK -- if I can rely on getting at it from the computer I'm working on. That plan I'm working on in odd moments can only be a Google spreadsheet. I don't need a fair printable version of my CV, but I do need to be able to keep the copy up to date. And Blogger is a terrible place to hold draft articles like this one.

The security angle ought to be obvious. I set up my Google account so I could customise my searches, or something, and the password was some old joe job. (It isn't UMACF24, but you get the idea). By stages, stealthily, that same rotten password now defends:

• My email, calendar, and the management of my domain (Google Apps for Your Domain)
• A bunch of documents and plans (Google Docs)
• My Blog
• And probably other stuff I've forgotten.

I can change that. I'll have to allocate a "public site -- reputation/convenience" password now -- that's just one stage short of Paypal/banking. But, unfortunately, it's still just a password. And If I want to get the full benefit from Google, I'll have to use it on untrusted, bugged machines.

So, "Hey Google: It's time for a second factor!".

Christmas

Today I paid

UKL 50

to the cleaner

UKL 100

to the rat catcher

UKL 80

on a new gardening coat for Mrs U (Christmas present)

UKL 50

on Felco secateurs for Mrs U (Christmas present)

UKL 40

on petrol

UKL 20

as petty cash for Mrs U and a carer to take the darlings on an outing which they did not enjoy -- Mrs U will have paid a further UKL 60 to get in

Yesterday I paid UKL 600 for 1600 litres of heating oil.

The Rules

I turned down a system last month. It needed a user to be permanently logged on at the server console, which implies a password shared among the support team. The chances of that being tough and regularly changed are nil, so my vote was no.

We'll see if I can make that stick! But I'm content, because I've only applied a published policy. Project people think that security imposes strange and unnatural demands on system design, and I suppose it's true that the demands puzzle people. But they're not unnatural and they're not arbitrary -- just misunderstood. So as my contribution to public education, taken from the handout I send to project managers, support people and anyone I can find, here are the rules. They way I present them is a checklist -- tick every box and you're on the right track.

First we have the Exemption Checklist for changes and small implementations -- Tick every box here and I won't bother you:

• No file, folder, registry or mailbox permissions changed or created.
• System is explicitly permissioned by our standard groups and does not rely on “Everyone”, ”Authenticated Users”, ”All Users”, 0x??7, “Domain Admins” or ”Administrator” permissions to work.
• No Windows local or global or Unix security groups are created, deleted or changed in meaning.
• No impersonal domain user accounts (service accounts), or any local or Unix or special device user or admin accounts are a) created, b) get new group memberships or c) are admins.
• All human users and administrators use their regular personal Insight workstation or app/admin/Unix accounts, and there are no shared accounts, and no non-Insight users.
• No changes to external data transfers, network security configs (firewalls/acls) or external accessibility.

For larger changes, I need to hear about it earlier. Here's the standard advice for project managers contemplating a new system. Again, if you can't check every box, we need to talk:

First, how about Unattended Processing (UP)? That's any processing other than discontinuous console session on a user or administrator workstation.

• All UP is on a server platform?
  (Servers are physically inaccessible. Console access is only granted to IT support users.)
• All UP runs as a service or scheduled task?
  (Not on the console or in a terminal session.)
• All UP runs without administrative privilege?
  (Not as Domain admin member, nor as server local Administrators member, nor built-in administrator including Local System)
• All UP runs without a profile?
  (No requirement for logons using service a/c.)
• All UP credentials stored in Windows SC password store?

Then there's Authentication of Users and Administrators

• All work done with personal accounts?
  (No shared users)
• Users and administrators authenticate using Windows workstation domain logons?
• Users and administrators authorised by membership of domain global groups?
• No user or admin credentials stored?
  EG in scripts or config files. (DPAPI and SC list storage is permitted.)

And finally there's the Application Structure itself

• Admin privilege can be withheld from business users without impeding function?
  (Users are not admins -- we can keep admin functions on the support desk.)
• Conformable with our app access model?
  (Role/Environment groups allow us to manage permissions through the helpdesk, using standard tools)
• All resource access via application-specific group membership?
  (Excluding: Domain *, Everyone, Auth users…)
• Administrative and security events logged in a supported means?
  (syslog, ftp upload, Windows event log, text file)
• Will be supported on platforms kept patched up to date?
  (No vendor qualification of Windows patches)
• Documentation identifies all resource permissions, and sensitive locations
  (config files, private keys)?
• All Internet/external access via authenticated proxy?

Once every application can check off all these, we will be getting somewhere.

Hedging Strategies

This weekend, I have been mostly de-wiring.

The mad woman who lived here before us handled the increasing gappiness of the hedges by stapling stock fence on to the more solid stalks. Over time, the bark and wood grows over and through the wire, and new shoots tangle up in it. It becomes absolutely impossible to manage in the normal way: you can't lay the stalks over because they're tangled up in the wire, and you can't use the saw because it'll be blunted on wire or staple.

The only way out is to remove it and this is what I have been doing. You need to cut away the grown-through stalks (a terrible waste because they're the ones that would be easy and productive to lay) and lever out every staple and length of embedded wire.

I could have salvaged some of the stalks by cutting them out of the wire, but unfortunately the wire netting was in such good shape that my tightfistedness took over and I was determined to get it out intact. Which I did and in the process finally discovered how to use the staple remover on the fencing pliers. Instead of ineffectual whacking with the pliers in the hope of getting the hook under the staple, you position it carefully, and then smack the striking face of the pliers with a 3lb hammer. The hook leaps under the wire and you can lever the whole thing out.

Anyway, I've done a good old length, and while my arms are scratched up to buggery, I've salvaged some posts to weave into the lay, I'll be able to buy some chestnut pales to do the rest, and I can start laying next weekend. And I have the wire I'll need to keep the neigbour's horses from browsing on the new growth. (Why do horses prefer thorn bushes to lush grass? FIIK.)

Commuter 2

Today I found out how Champagne sales ladies sell lots of Champagne to restauranteurs.

The glamorous lady opposite me on the train home was working very hard and very loudly on her phone shifting cases of "Pol" and arranging visits. Normally I'm a bit irked by the louder sort of commuter, but she was charming: her blouse didn't even pretend to have any buttons above the bottom of her sternum, and her push-together bra was working as hard as she was. She leant forward every time she wrote down a sale or an appointment. Those visits must have been devastating.

Commuter 1

Today I popped out at lunchtime to buy a new raincoat. It was a bit cold, but I didn't really need it today.

During the afternoon it began to rain heavily. How splendid is that?

The Userid Con

Activity logs are good. We grant all sorts of access to staff "merely" because they can't do their jobs without it, and trust them not to abuse it. The way Ronald Reagan put this was "trust, but verify," and he was right. Audit logs are our verification. My first security effort here was to replace a shared admin userid with personal IDs, simply to make the logs mean something, and it's probably the most useful single thing I've done.

So, we configure the systems to generate logs, and we squirrel them away safely and the auditors and investigators are profoundly happy. But if we ever want to use them as evidence there's a little con trick we have to carry off first. That trick is called "User equals userID".

It's a con because it's untrue, and we depend on users not knowing it's untrue. Ask yourself, where you work, which has the worst career outcome a) "yes, I sent those emails" or b) "everyone knows I leave my password on a note under my keyboard"? If you're like my employers, admitting password sloppiness is going to go a lot better, especially if you've been doing the sort of thing people get investigated for. I sometimes wonder how many people have lost their jobs or reputation after assuming that logs with their name on were irrefutable evidence, when they could have hung on by saying that someone else was on their account. It must be a lot. I've seen this benign con work in environments where no-one even pretends to have a secret password.

Perhaps it's not totally grim. A single event may be deniable, but a pattern or a sequence of offending behaviours is much harder to walk away from. And a good evidence recovery can cause people to collapse when they are shown exact texts, pictures, times.

We can deal with this:

1. Let's look again at the rules on password sharing in the AUP. And,
2. I think it's time to dust off that plan for smartcard tokens -- they are hard to share accidentally.

But in the meantime, well now, I think we'd better keep this to ourselves. Otherwise, there'll be a password under every keyboard in your firm.

Authentically Spooky

Well, I was walking home along the lane last night -- I'd just passed a batch of trick-or-treaters -- when I heard a cat calling. I couldn't see it though, until we passed the neighbour's lamp.

I crouched down to stroke her and ask her name and she circled me, rubbing my legs and crooning. She was big, black and shiny, the blackest cat I ever saw, with yellow eyes and she liked me enough to follow me home.

She was through the door as soon as it opened and making herself at home nosing around the kitchen. Mrs U fed her but drew a line when she started to explore the beds updstairs. The kitten scarpered, the more mad cat maintained a glaring distance and Fleabag just kept out of the way. I canvassed the lane, but no-one knew where she came from. I made her a bed in the freezer room -- warmer than it sounds -- and put her in it so she knew where it was, but I don't know if she stayed.

For maximum Halloween effect, she ought to have vanished by morning, but at 05:10 she picked me up by the gate and follwed me down the lane and halfway across the field, calling all the way. I hope she goes back indoors.

Commuter

Just north of Sevenoaks this morning I was looking down to the southeast and I saw a rare sight: pre-dawn colours in a clear sky. The whole range from sodium orange at the horizon up to space-black in the zenith. I wanted to wake up the whole carriage, rip away their newspapers and tell them to look at the world. But then we went into the North Downs tunnel and when we came out the sky was was a rather tasteless cream and light blue, so I left it.

And anyway, it would have been eccentric.

Criminalise Your Enemies.

Is it strange that so much WAN traffic is unencrypted? That became a live issue for me when we were setting up a new recovery facility. Part of the project includes links between the machine rooms, and the service provider offered us a significant cost saving by using their network to replace a hop that would cost tens of thousands ordered from COLT. Everyone was happy except me. I saw it as a tap risk.

I hate taps. A network tap is one of the points where the balance tips in favour of the attacker. They are totally stealthy and very reliable. They can be serviced by a leave-behind -- a laptop running Ethereal or TCPdump with USB disks exchanged whenever the access can be had. The only real problem the attacker faces is getting access to a good network segment -- plugging in to a workstation LAN and risking an ARP spoof is going to get some user passwords, and that's not bad, but it's not the key to the domain.

But a trunk between machine rooms is another thing entirely. Modern domain traffic ought to be harmless if overheard, but console sessions on to the DCs, SNMP strings, enable passwords on switches ... One way or another, it's the place to be if you want passwords, not to mention seeing what the fileservers see.

So, OK, taps are bad. But is it any more risky to run our traffic over a service provider's network? The contract gives them a duty to keep our data confidential, and you won't find that in a service agreement from BT or COLT.

The short answer is the criminal law. Between the termination points of section 8 licensed telecoms providers like Colt and BT, special law applies: I think it's the Interception of Communications Act 1985, but anyway there are criminal penalties for tapping their systems without a warrant. They can't even do it themselves, and that's why there's no confidentiality in the contract.

The point here is not so much the penalties but the criminal liability. Evidence of a crime -- and an unexpected laptop stuffed with traffic logs is evidence -- lets the police investigate. Serious industrial spies always seek to operate below the radar of Babylon, and that makes for real protection.

IoCA is protection, but it's limited. It doesn't stretch beyond the endpoints. If we found a tap on the service provider's network, we could remove it, but no crime has been committed. To get any recourse we would have to mount our own surveillance and investigation, and that is a place I don't want to go.

We're sticking with the service provider's network, but some of the savings are going on hooking it through our firewalls with the encryption turned on.