"Scoopable?" Meaning copyable between computers that are both
on the "inside?"
Yes - IOW, I scoop the data files, plus the repository for the keys,
and then I "restore" them to an arbitrary PC.
I'm challenged to see how the system can facilitate restore on to an
arbitrary (replacement) PC while blocking the above scenario, and the
only solutions I can see is some part of the puzzle that has to be
kept out-of-band, e.g. on a USB stick locked up somewhere.
Won't work. The lockbox customization process builds uniquely-identifiable
lockboxes for each computer. If you try to copy the lockbox files from one
PC to another, the RMS client will sense this and the lockbox files will
self-destruct.
What if the PC is lost, i.e. destroyed or stolen?
On NT/2000/XP/2003 only local administrators have permission to adjust system
clocks. This can be a mitigator.
Well-phrased, as it's a band-aid, and an optional one at that. But as
we're talking about an off-by-default functionality that is to be used
within a properly-administered setting, it's not unreasonable.
I imagine many such installations will also be using Kerberos, which I
understand has even more rigorous timing sensitivities.
Perhaps all that needs to be done is to stress the need to manage RTC
rights, and perhaps re-visit the "time" dialog box so that only
changes committed by "OK" (perhaps through an "Are you sure/nuts?"
confirmation) have any effect at all.
As it is, and as posted, it seems as if that dialog box is "live";
changes may be undone if the user [x] or Cancels, but by that stage,
something that monitors RTC in real time could have pulled the pin.
That's an extension of the "scoopability" thing mentioned earlier.
I can see a pattern here - that if you deploy this technology, it's
crucial that related settings are sanity-checked and possibly
maintained on an ongoing basis. Else we may see reports of "holes"
that are just a mismatch of unrelated settings, but damaging press.
You can also store keys on a hardware storage module (HSM),
which is an effective form of key backup that also increases
security considerably.
Ah; that's the "out of band" thing I was thinking of earlier. That's
far better than to expect the user to be the HSM hardware, as a
"password" would do. Just as PCs fare badly at being human, so humans
fare badly at being reliable dumb hardware
I can see USB sticks playing new roles that may require some attention
at the raw driver code level, just as one extends other security deep
down into post-FATxx file systems.
Outside of Office there's no way to inspect the rights-protected (encrypted,
remember) files to see whether they contain macros.
That's a re-statement of the problem, which IMO is a serious one.
There might be a way to set a global no-execute within Office,
but I don't know about that... I'm a security guy, not an Office guru!
I'd be inclined to build it into Rights Management itself - i.e. a
hard setting that dumbs down file content to safe levels if it is to
be hidden from the system by encryption.
We've already seen how password-encrypted .zip, combined with quite
plausible SE, can be routinely used to bypass av. After all, it's
been how we've submitted malware samples to av vendors for a while now
(or for me, anyway... "the password is 'This is a VIRUS!!' " etc.).
Heh, I'm waiting for the first such malware to claim legitimate
software status by a password that is an EULA, e.g. "By opeing this
file I acknowledge the right of the software to..."
The thing is; these things may be intended to do such-and-such, but in
reality, code is neutral. A strong glove works just as well to keep
your assailant's hand warm and safe as it does yours.
We are in violent agreement here.
We've done a lot of testing of the lockbox
handling code, making sure that it rejects unexpected input rather than barfing
in some insecure way.
Glad to hear that. You'd also want to make sure your code is the only
code that touches the box, and that it's not extensible, and that the
next generation of devs to version it up maintain your prudence.
These are good points, and we're thinking about them.
I've wanted to pull a large mass of such concepts together as a
section at my site (
http://cquirke.mvps.org) but time etc.
Namely, "depth"...
- assume your defences will fail
- plan what to do when that happens
- don't trust even your own code
- be prepared to amputate subsystems at a moment's notice
- beware of inappropriate "feature sprawl" (e.g. RPC)
....and what I call "risk WYSIWYG"...
- abstract reality towards user's intuitive understanding
- give user clear risk information
- never exceed the risk information the user acted upon
- current risk order may change (e.g. is .jpg safer than .doc?)
....and how that comes down to common realities:
- if user wants to "view" or "read", never "run"
- if user wants to "list", don't delve *into* what is listed
- be bound by visible risk indicators, e.g. file name .ext
- don't auto-integrate newly-discovered drives, even HD (S-ATA?)
- provide safe maintenance tools ("Safe Mode" isn't)
remember that there are two definitions of "secure": private and inspected.
When some people mention "security" they mean knowing everything -- inspecting
all the content. Other people mean "privacy" -- keeping information confidential.
It's generally impossible to have both!
This is one of the deep and crucial differences between Home and Pro.
Home users lack pro infrastructure. Thier PCs evolve on an ad-hoc
basis, there's usually only one PC that is unique and must survive,
backups are poor, incomplete and may be absent, etc. The user in the
chair should have full and unfettered access to everything. Notional
"administrators" via the 'net or LAN should have no access at all.
Pro IT has strong infrastructure to manage backups and identities, and
is more concerned about unauthorised access than loss. Aside from the
servers, workstations are rarely unique and need not be preserved.
Physical access is extended to semi-trusted personnel that should be
overridden by "the admin", who may work remotely via the network.
The end point crunches down to: Who wins, the guy with physical access
i.e. at the keyboard, or the notional administrator? Because Home and
Pro answer that Q differently, they need to be different products.
...access controls that work regardless of where the object (file)
lives and complete privacy outside the access control system.
The trade-off is your ability to inspect.
It's a particular re-statement of: One admin's maintenance tools are
another "admin's" hacking tools
And this, perhaps, isn't as large of an issue as you might imagine. Since
document authors always first create clear-text files on their own computers,
any virus-scanning system that knows how to look for macro viruses will
still flag the existence before the file is saved.
Hooyyy... that's like de-bulking a tumour that's already spread
through the bloodstream. Yes, it's a best-case that will reduce the
tumour load, but... for starters; consider the author may be in the
field, working on a corporate laptop that depends upon daily network
access to have the av updated. By the time he's back on the LAN, he's
remembered to apply rights management to his data so it can be
uploaded to the LAN. Any malware will be encapsulated before his av
is up to speed; the opportunity is GFE (Gone For Ever).
This is an old issue for me, when I clean up active malware in the
field, because two sealed malware repositories already exist; System
Restore (which can be purged and rebuilt at the first clean point) and
email mailboxes in most email apps (Eudora's OK there).
What I do in such cases is import the email into Eudora, which causes
all attachments to be split out of the "messages". As long as I
disable "use MS Viewer", Eudora doesn't auto-run scripts of
IE-orientated exploits, so the messages are safe. I can then scan the
attachments, and either work back to delete and purge corresponding
messages in the other email app, or I can say:
"Clean system, or keep your old email. Pick one."
Because you can't rely on detecting exploiters (malware), you may
prefer to exclude risks (malware opportunities).
RMS does allow you to create document "templates" and enforce their use.
Again, this is more of an Office thing so I don't readily know the answer,
but maybe your templates could all be set to refuse the creation of macros.
Need to research this more, I guess.
It's worth looking at. The thing to remember is that it may appear
that a peculiar set of circumstances that are required to exploit a
risk may seldom occur, they can often be hard-coded into a malware or
library and become pervasive within hours.
-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
