Schneier on Security
A blog covering security and security technology.
« Comparing al Qaeda and the IRA |
| Friday Squid Blogging: Giant Squid Egg »
July 8, 2011
Organized Crime in Ireland Evolves As Security Increases
The whole article is interesting, but here's just one bit:
The favoured quick-fix money-making exercise of the average Irish organised crime gang had, for decades, been bank robberies. But a massive investment by banks in branch security has made the traditional armed hold-up raids increasingly difficult.
The presence of CCTV cameras in most banks means any raider would need to be masked to avoid being identified. But security measures at the entrances to many branches, where customers are admitted by staff operating a buzzer, say, means masked men can now not even get through the door.
By the middle of the last decade, cash-in-transit vans delivering money to ATMs were identified by gangs as the weak link in the banks’ operations. This gave rise to a huge number of armed hold-ups on the vans.
However, in recent years the cash-in-transit companies have followed the example of the banks and invested heavily in security technology. Most vans carrying money are now heavily protected by timing devices on safes in the back of the vans, with staff having access to only limited amounts of cash at specific times to facilitate their deliveries.
These security measures have led to a steady decline in robberies on such vans in the past five years.
But having turned from bank robberies to armed hold-ups on cash vans, organised crime gangs have once again changed tack and are now engaging in robberies with hostage-taking.
Known as “tiger raids”, the robberies involve an organised crime gang kidnapping a family member or loved one of a person who has access to cash because of their work in a bank or post office.
Family members are normally taken away at gunpoint, threatened with being shot and or held until the bank or post-office worker goes to their work place, takes a ransom sum and leaves it for the gang at a prearranged drop-off point.
The Garda has worked closely with the main banks in agreeing protocols for such incidents. The main element of that agreement is that banks will not let money leave a branch, no matter how serious the hostage situation, until gardaí have been notified. A reaction operation can then be put in place to try and catch the gang as they collect the ransom.
These protocols have been relatively successful and seem to be deterring tiger raids targeting bank workers.
However, gangs are now increasingly targeting post offices in the belief that security protocols and equipment such as safes are not as robust as in the banking sector.
Most of the tiger raids now occurring are targeting post-office staff, usually in rural areas.
The latest raid occurred just last week, when more than €100,000 was taken from a post office in Newcastle West, Co Limerick, when the post mistress’s adult son was kidnapped at gunpoint and released unharmed when the ransom was paid.
Posted on July 8, 2011 at 6:19 AM
• 47 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Just remember Ireland is the place where millions was stolen in freshly printed notes, driven away in a white van, and mysteriously started turning up in wheelie bins in peoples gardens...
Is the island of Ireland the topic of the week?
@: "released unharmed when the ransom was paid."
This is where it gets tricky. Obviously, anyone with a heart wants victims released unharmed. On the flip side, it is often a policy not to pay ransoms, not because one doesn't care about a specific victim, but because one wants to reduce the number of future victims by rendering kidnapping an ineffective tactic.
Interesting to see how crime evolves if (when) invisibility cloaks and laser guns become available.
Note sure if naming this type of behavior "tiger raids" is the right thing to do. Why can't it be named "stupid raids" or something like that?
"Stupid" can be said to be a descriptive characteristics of the behavior just as much as "tiger".
OK, I'm not from Ireland, but am I the only one who wonders why a post office has 100,000 euros hanging around?
"am I the only one who wonders why a post office has 100,000 euros hanging around?"
Yeah, seriously... What post office would have to hand out lots of cash? If they're not handing out cash, why don't they have a drop safe like every urban quickie mart in America?
Executive summary: host evolves, causes parasites to evolve.
That said, it's very interesting to see it in action.
Re: Post offices with a lot of cash -- In other countries post offices handle many more financial transactions than in the US. Notably wire transfers and money orders.
"but am I the only one who wonders why a post office has 100,000 euros hanging around?"
You don't say where you are from so...
Some parts of Europe don't use credit cards very much or at all. There was once a statistic thad said that in Germany there where more people with mobile phones than credit cards.
In some rural areas everything is done with cash, and also there may be no bank which makes the postoffice the replacment. Also some rural areas have markets for selling live stock and the like and these might happen weekly or only monthly. It would not take much live stock to make 100,000 Euro.
So the amount of money "on hand" could be very large just for one or two days and quite small the rest of the time.
As a robber you would make your plans based around the time when most money was likely to be in the place you were planing to rob.
Planning a trip to Ireland?
What if they lower taxes on fuel and cigarettes?
@accs: RE: "Militants may try bomb implants to attack - US"
You might see it eventually, but the reason you haven't is because it is a "so what" kind of statement. It is equivalent to: "Militants may disguise themselves as the Easter bunny."
Militants MAY do anything anyone can think of. So what? Without credible evidence of an actual plot there is nothing in that statement that merits a response.
It's not surprising. Economic principles apply to crime too. They want the greatest return for the work and risk. Each time risk goes way up or rewards go way down, they change their plans. To be honest, im more impressed by the maturity of the malware markets. Specialization and competion drove prices down and value up for both products and services.
Unsurprising, really. It's almost a malicious version of Linus' Law "Given enough eyeballs, all bugs are shallow".
Given enough criminals, all security vulnerabilities are exploited.
In the UK and Ireland - the post office is not only a bank, but is also where people can collect their pensions in cash.
Amusing phrase "fuel laundering". I read a fair bit before realizing they were talking of actually washing the fuel, not just obfuscating the transactions. So if the gangs start importing cheap Asian garments without paying the tax, will it be clothes laundering?
A lot of the hostage bank raids are in inside job - the hostage is in on it.
Since it's difficult to prove at the time, and under fire, if the hostage is genuine or not the police need a bit more time.
In the Northern Bank raid, where the IRA stole 20M in new sequential bills, which had to be dumped, the hostage was in on the scheme. Without proof the police had to hint about this to the media - the code was that he was wearing a celtic shirt when released.
Celtic is the catholic Glasgow football club and so the hostage was presumed to be on the IRA's side.
So that's why Fiona Glenallen left the IRA for the US, to work with Michael Westen in the TV series, "Burn Notice". ;)
Seriously, this can be applied to computer security as well. It's been discussed on various threads here, I think, and in e-mail with Nick P., that no matter how secure the system, you can always extort the person who has the privileges you need, although not quite so remotely. But if the payoff is big enough, gangs could attack banks in their own country, or if they have people who aren't on no-fly lists, come to, say, the US, and do this. Getting back home might be a bit trickier, but there are ways...
Physical security and IT security are not two different things.
OFF-TOPIC, @ Nick P. and Anyone Interested - It's Good Stuff:
Re: Nick P.'s comment to me at
"DJB Paper if you missed it
"Small quam on with his paper: I think reducing privilege isn't a distraction. If we *all* did secure development, it would be a distraction. However, third party and legacy code, especially w/out source, might be very buggy. Privilege reduction and isolation technologies help to counter this issue."
My comments after reviewing the paper:
"Engineering a secure software system is easier than engineering a bug-free software system."
Good, let's focus on that. Nice insight.
"Reduce total code, but also reduce trusted code. It's then possible to try for no bugs in the trusted part, and bugs in the untrusted part can't violate security."
Riight up my alley, as Nick knew it would be. As per our previous discussions of the Poly2 paper to which he had pointed me,
I've cut Windows code by about 95%, and if there's any Windows code that isn't "trusted" by the system, I can't think of it at the moment. So that means that I've reduced total trusted code as well. But applying that to all programming - OS, apps, etc.-- the lessons of the Qmail writer's own e-mail program should apply to *all* designs. Great point and great principle.
What programmers wrongly focus on: "Fixing yesterday's holes, chasing attackers - 100 emergency patches in Ubuntu one year... "
Actually, that's much worse than Windows, when the number of sytems deployed, and hence, target attractiveness, is factored in.
Agree with you, Nick: "Least privilege" is not a distraction, nor an enemy of his approach; rather, it complements his approach. The two can be additive towards security, and are not mutually exclusive, nor should developers stop trying to minimize privilege.
"Security is much more important than speed. We need invulnerable software systems, and we need them today, even if they are ten times slower than our current systems. Tomorrow, we can start working on making them faster."
Fits in perfectly with our e-mail conversation a few days ago about the performance hit from removing DMA, etc. Make it secure first, then work on making it faster.
"To this very day, idiot software managers measure programmer productivity in terms of 'lines of code produced', whereas the notion of‘ 'lines of code spent' is much more appropriate.
Now we're on my turf, economics, and how incentives influence everything. You get whatever you pay for or reward. If you pay people to be unemployed, there will be more people unemployed than there would be in the absence of "unemployment insurance", because the incentives have been altered. The car salesman tries to sell you the model with the biggest commission or bonus - and so does the stockbroker, regardless of what might actually be better for *you*.
If you pay people, or do their performance evals, on lines of code written, they'll TRY to bloat things as much as posssible.
Which explains a lot.
Evaluating programmers on how FEW lines of code they need to accomplish an assigned task, meet design benchmarks, etc. would be a huge improvement. Evaluating them on bugs found, both by internal review and by marketplace experience, would also change incentives for the better. Etc.
"The mail-reading code and browsing code are part of the TCB."
Ah, here's where I may stir up some discussion. I don't have a local e-mail client at all. That cuts the TCB even more.
I like webmail, namely, Yahoo for ordinary stuff and Hushmail for sensitive stuff: no extra ports open; less code on my machine; less access to OS and other components; just viewing an HTML picture of the message. If I were to install, say, Thunderbird and Enigmail, I've just added lots more local code, more trusted code, more chances for flaws and expolits, more need for patches and updates; more ports open through the firewall, a connection running in the b/g.
For me, webmail, like all other browsing, is read inside the sandbox anyway. Contents can be pasted to a .txt file, generally a pretty safe form of content (I use the "Copy as Plain Text" option from a Firefox add-on, to save that step) and saved to disk as needed. Attachments are scanned before and after d/l, and opened in the sandbox if at all unsure of source or safety.
Security? Hushmail has been vetted by far better eyes than mine. A digitally-signed Java applet is loaded via https, after Firefox duly tells me that the digital signature has been verified, and is it OK to run this thing? It encrypts things before they leave the box, so even Hush can't read them on their server. The advantages of PGP without the disadvantages noted above.
But my results have been 0 infections, by whatever means they could be known, without the headaches. Your mileage may vary, and your opinion almost certainly will.
Thanks for another excellent read, Nick.
"gangs could attack banks in their own country,"
That's what they're doing in the OP. I meant, "attack the bank's (or corporation's) //network//, by extorting the admin. Sorry.
(off topic tSA madness)When I saw the implant plot, I thought "oh great, they've see The Dark Knight. I have to wonder, assuming you could surgically implant a substantial quantity of explosives, a detonator, and a power source that could last a few days (try lighting a fuse or using a mechanical detonator inside you), without killing the patient, how will you keep it stable long enough to recover from surgery? And seal it well enough so it doesn't leak inside the terrorist? I'm sure most of these explosive compounds would kill the terrorist or make him deathly ill if it got into his bloodstream. I just don't picture it being effective.
What's the TSA going to do next? Full xray and/or total dissection of all passengers?
Agreed, although power supply, timer and detonator wouldn't take up much room. Doing a major surgical operation in Yemen and having the patient survive to get on the plane might be more difficult.
What about the drug mule model? Swallow lots of little sealed packages of HE plus a few packages of timer/detonator for redundancy. Some drug mules are carrying 800g to 1kg of cocaine. that weight of explosive would be enough to take down a plane.
Thanks for the reply. I figured you'd mostly agree with his points and principles, minus privilege reduction as a distraction.
"Evaluating programmers on how FEW lines of code they need to accomplish an assigned task, meet design benchmarks, etc. would be a huge improvement. Evaluating them on bugs found, both by internal review and by marketplace experience, would also change incentives for the better."
Definitely. To support your point, certification processes like DO-178B and Common Criteria EAL6/7 require such rigorous analysis that analyses can cost $10,000 per line of code and up. Any defects they find must be rewritten and re-checked, further driving up costs. This incentive has led these groups to use as little and as simple code as possible. The groups are also using things like formal methods and certified code generators even though the standards don't mandate them. The costs associated with these assurance technologies make sense compared to the cost of re-evaluation. Right incentives = right thing produced. In this case, tight, robust applications.
"Ah, here's where I may stir up some discussion. I don't have a local e-mail client at all. That cuts the TCB even more. "
It actually doesn't. Remember that the TCB is the sum of everything an app depends on to function security (and anything that can directly influence it). A web browser has all kinds of functionality it depends on, hooking into many different libraries, kernel calls, etc. It's also usually very privileged with regard to filesystem access. It takes clever sandboxing to reduce the built-in attack surface. A dedicated email application could run almost totally deprivileged, with only networking and one folder an absolute necessity.
Of course, in a system like Windows, one could use my definition above to argue that the whole Windows platform and all privileged apps are TCB due to how easy it is to escalate privileges by exploiting any one app. This is a very defensible position. If true, then webmail's TCB would only be marginally greater than a dedicated email application. So far, so good.
So, a dedicated email application can have a smaller TCB *and* be made harder to exploit. So, a robust email application on a hardened OS appears to be the more trustworthy solution.
"Security? Hushmail has been vetted by far better eyes than mine."
The company is located in Canada & that country works closely with US. So, it shouldn't be used if the email concerns those governments enough for them to pay a few hundred dollars for a subpoena request. They are a decent choice for basic, easy-to-use encrypted mail for residential and commercial use. If the assets are medium to high value, different methods should be used.
(I'd also recommend anyone looking into these kinds of solutions to check out ZixCorp. They've always had many more services than Hush and others.)
"Thanks for another excellent read, Nick. "
You're welcome. Always glad to help equip new players in the field, even if they only end up being evangelists for the cause.
>OK, I'm not from Ireland, but am I the only one who wonders why a post
>office has 100,000 euros hanging around?
There was a report that Bed Linen had been spotted in a nearby department store, the cash was part of the USG's reward to be paid for the apprehension.
Tommy: "'00 emergency patches in Ubuntu one year... ' Actually, that's much worse than Windows, when the number of sytems deployed, and hence, target attractiveness, is factored in."
Not really. People forget that Linux distro patches frequently include many other sections of the distro other than the kernel or even the desktop, such as included applications.
Also, how many bugs needing to be patched in an OS is irrelevant to the number of copies of the OS in circulation. Linux distros are pretty good at keeping up with needed patches, probably more so than Microsoft who has been known to leave serious bugs unpatched for months. Most time-to-fix studies show Linux developers - and OSS developers in general - to be more responsive than commercial entities.
As for Ireland's armed robbers, my take:
"The presence of CCTV cameras in most banks means any raider would need to be masked to avoid being identified."
Duh! Only morons rob banks with their faces hanging out. And there are a lot of bank robbers in the US in jail because of that. A balaclava or stocking mask is the minimum, and a hard mask would better since it's possible to analyze facial contours these days even though a tight mask. Of course, establishing such in court is a bit harder.
"where customers are admitted by staff operating a buzzer, say, means masked men can now not even get through the door."
That is a problem, particularly if you don't want to blow the front door up because you're trying not to attract attention. I don't think any US banks (other than possibly private banks) do anything like that.
Of course, it's likely that an enterprising group of bank robbers could penetrate the building through another door or windows, but that complicates things. You want to be able to get in and out of the target within four minutes (average police response time in the US, no idea what it is in Ireland.) Climbing through windows might be an issue.
"Most vans carrying money are now heavily protected by timing devices on safes in the back of the vans"
So, steal the safe! Or the whole vehicle! Do an "Italian Job" on it! It's just a matter of going in prepared with the necessary tools to get the job done in minimum time and noise. They'll figure it out eventually.
"Known as “tiger raids”, the robberies involve an organised crime gang kidnapping a family member or loved one of a person who has access to cash because of their work in a bank or post office."
This is a good approach, but again, it's complicated, likely to fail due to unanticipated events, and leads to a higher sentence if you get caught.
"The main element of that agreement is that banks will not let money leave a branch, no matter how serious the hostage situation, until gardaí have been notified."
In other words, the bank's money is more important than the kidnap victim.
"A reaction operation can then be put in place to try and catch the gang as they collect the ransom."
This is the fundamental problem with any kidnapping - and a bank robbery involving kidnapping has the same problem: collecting the goods. In the US, kidnappings invariably fail at that point because the police or FBI can track the money and ambush the retriever.
Smart kidnappers set it up so that the ransom collection team does not know where the kidnappers or the victim are. Then if they are interfered with, the victim can be killed as a warning to the next.
Of course, you need a third team keeping the ransom team under surveillance so you can detect the police surveillance. It's a difficult proposition but probably can be defeated with a lot of thought. The key to a successful kidnapping is always managing to defeat the tracking of the ransom by sleight of hand and technology. It's better if you can convince the ransom payers not to bring in the police or FBI, but in the US frequently that doesn't work as the victim's own bank may alert the FBI if a large cash withdrawal is made for the ransom.
"it is often a policy not to pay ransoms, not because one doesn't care about a specific victim, but because one wants to reduce the number of future victims by rendering kidnapping an ineffective tactic."
Kill enough victims - or the right victims - and that policy will change quick, at least for a non-governmental entity. Governments don't give a rat's ass about their population, so it doesn't work with governments - unless of course you kidnap someone really important. If Obama, or say, his wife, got kidnapped, you can rest assured ransom WOULD be paid and damn fast.
Again, the biggest problem with kidnapping is figuring out how to get hold of the ransom without getting caught. Absent some clever strategies along the lines of Three-Card Monte, the most effective is to simply kill one victim so the next will obey the order not to involve the police.
@ Richard Steven Hack,
"So, steal the safe! Or the whole vehicle! Do an"Italian Job" on it! It's just a matter of going in prepared with the necessary tools to get the job done in minimum time and noise. They'll figure it out eventually"
Well I can tell your not a bank vehicle robber 8)
This Irish crime is mirroring what happened in the mainland UK back in the 80's.
The bank trucks do indead have multiple "safes" in them but not the sort of safe you might think (otherwise the vehical would be to heavy)
These days there are two basic types of safe, those that delay an attacker and those that destroy the contents when the safe is attacked.
The safes concerned are of the latter type, they are money boxes with anti tamper devices that put dye on the money so it is unusable and many are made of only thin sheet metal (as the guard has to carry it from the vehical into the bank, and most don't even have wrist straps any more).
If the bank truck is attacked in some cases an automated system triggers all the safes to coat the money in dye, long before an attacker could get to them even by "blowwing the bl**dy doors off" (apparently M.Cain never made the statment).
And for those thinking the bank loses the money that's dyed they don't, they or their insurers simply return it to the "printers" along with appropriate proof of the crime and pay a small fee to have the money replaced.
If the article is correct then the Irish banks concerned are well behind the times, or the robbers have got at the guards, or have some new technique which is unknown outside of Ireland.
And if you think about it kidnapping the guards family might be what is actually happening, in which case any anti-tamper device could be negated.
@ Nick P.:
"So, a dedicated email application can have a smaller TCB *and* be made harder to exploit. So, a robust email application on a hardened OS appears to be the more trustworthy solution."
And which one would that be? I was referring to OTS, proprietary or open-source. (the ref to "Thunderbird/Enigmail). Outlook/OExpress have miserable records. Thunderbird's is probably better, but their security bulletin list has tons of critical vulns and patches. Look it up some time.
and browse the various Thunderbird releases.
"A web browser has all kinds of functionality it depends on, hooking into many different libraries, kernel calls, etc. It's also usually very privileged with regard to filesystem access. It takes clever sandboxing to reduce the built-in attack surface."
... and I'm still hoping that you'll one day find the time to look at Sandboxie, which renders the entire HD read-only to the app being sandboxed, in this case, the browser. Mischief can happen inside the browser, of course (but see below), but can't be written to the HD. In other words, can't install malware, can't change system files (or BIOS or MBR, etc.) Malware inside the sandbox is dumped when the sandbox is closed.
"Of course, in a system like Windows, one could use my definition above to argue that the whole Windows platform and all privileged apps are TCB due to how easy it is to escalate privileges by exploiting any one app. This is a very defensible position. If true, then webmail's TCB would only be marginally greater than a dedicated email application."
No, it's less. Sandboxing in effect causes the rest of the system to distrust sandboxed content. One could also sandbox Outlook/Thunderbird, etc. I suppose, but it's still more code and more open ports (I'm going to have a browser anyway), and more vulns on my machine. E-mail viruses can live on Yahoo's server, not mine.
I thought that of everyone here, you would certainly assume the use of NoScript, as you've mentioned it yourself ... and probably not quite up-to-date on the extent of protection added since its origination. I can allow scripts from mail.yahoo.com, while disallowing yahoo.com and *all* third parties. All those things you mentioned, and more -- Flash, iFrame, audio/video tags, Silverlight -- are blocked by default. XSS and clickjack protection built in. Etc.
"The company (Hush) is located in Canada & that country works closely with US. So, it shouldn't be used if the email concerns those governments enough for them to pay a few hundred dollars for a subpoena request."
Hush claims that Canada does not honor US warrants, and certainly not warrantless taps per the unPatriotIc Act. But no, I have nothing to interest the feebies anyway. Zix is headquarterd in Dallas, Texas, and therefore subject to the same PatAct as AOL, etc. Saves the "few hundred dollars", plus whatever else.
"They are a decent choice for basic, easy-to-use encrypted mail for residential and commercial use."
"(I'd also recommend anyone looking into these kinds of solutions to check out ZixCorp. They've always had many more services than Hush and others.)"
I just did. Yuk.
"ZixGateway is a //content-aware//, policy-based email encryption appliance that automatically scans emails for sensitive information." ... Um, no thank you, Gmail already does that. Hush can't, as noted in my first post.
Zix appears to be far less friendly to non-Zix users, requiring various registrations, logins, passwords, etc., and apparently the e-mail is decrypted on the server. As noted in our e-mail discussions, you (or anyone else) can send me a public key and any email address on any server in the world that is associated with that key, including your own company or your own hardened, robust email client, and we have secure, end-to-end PGP that no intermediary can read.
"ZixAccess automatically decrypts inbound email from ZixCorp users (Nick, are you sh*tting me?) and provides transparent communication for recipients who are not ZixCorp customers"
I never did find out how to d/l it or buy it, or what the cost is. Hush offers free accounts, with minimal strorage space. "Free" means that even they don't have direct access to your real name, home or business address, credit card #, and credit history, which pretty much gives them all the rest of the details of your life.
"If the assets are medium to high value, different methods should be used."
Someone in possession of such assets shouldn't be running COTS or commodity stuff anyway, wouldn't you say?
@ Richard Steven Hack:
>>> "Tommy: "'00 emergency patches in Ubuntu one year... ' Actually, that's much worse than Windows, when the number of sytems deployed, and hence, target attractiveness, is factored in."
> "Not really. People forget that Linux distro patches frequently include many other sections of the distro other than the kernel or even the desktop, such as included applications."
And MS Update includes updates for Office products, Outlook, etc. If you want to compare OS to OS only, can you isolate out how many are in the Linux OS portion alone? I'd be glad to know, thanks.
"Also, how many bugs needing to be patched in an OS is irrelevant to the number of copies of the OS in circulation."
Quite true. But how many are FOUND and exploited is definitely relevant. Conisder the rude awakening that Mac users are getting after being so smug for all these years. Windows was the target of choice because Mac's market share was minimal. With the flop of Vista, growth of Mac market share, etc., crackers are starting to target Mac, and finding - surprise - lots of vulns.
"Linux distros are pretty good at keeping up with needed patches, probably more so than Microsoft who has been known to leave serious bugs unpatched for months. Most time-to-fix studies show Linux developers - and OSS developers in general - to be more responsive than commercial entities."
Preaching to the choir here, Richard. But as Clive and you have told us, *all* commodity OSs are crap.
I suppose I shouldn't have raised the Ubuntu issue, because we've all agreed with the above sentence. But it was a quote from the paper Nick sent me, illustrating the futility of the catch-up-and-patch-up approach, and I suppose I used it out of context for a point not relevant to the main issue. My bad.
I had the impression that kidnapping for ransom ended at the same time that airplane hijacking for ransom did (with the "D.B. Cooper" case in 1971), and for the same reasons: there is no longer any country unwilling to (1) turn over suspects in kidnapping and hijacking cases, even to countries they are in "Cold Wars" against, and (2) trace the flow of ransom money through banks, even where bank secrecy laws would otherwise apply.
It would be interesting to know how these new Irish kidnappers are getting paid without the money being traced, even if they're sophisticated enough to check that no dye-bomb is present before turning the victim loose.
Maybe banks will need to resume making records of the serial numbers of bills in an armored-car shipment before the shipment goes out the door. Then at least when some of the bills reach another bank, the bad guys can be found.
If even that isn't sufficient, then it may be necessary to outlaw cash.
@tommy: Why the completely unrelated post about operating system bugs?
"And which one would that be? I was referring to OTS, proprietary or open-source. (the ref to "Thunderbird/Enigmail). Outlook/OExpress have miserable records. Thunderbird's is probably better, but their security bulletin list has tons of critical vulns and patches."
I'm aware of that. I'd never recommend those. There are a few options here. One can use a mail client designed for security, like the old PGP clients. A robust terminal mail program from one of the OpenBSD or NetBSD tree's would have been thoroughly audited, reducing risk. The last, hardest, and best option is to design a new one with security baked in from the ground up, like Qmail.
"... and I'm still hoping that you'll one day find the time to look at Sandboxie, which renders the entire HD read-only to the app being sandboxed, in this case, the browser. "
I've been aware of SandboxIE for years. I stumbled on it when reading a long series of tests done on live malware comparing these three products: DefenseWall; AppGuard (was that the name?); SandboxIE (Wilder's security forums had the review, i think). DefenseWall stopped the most attacks & was about as easy to use as SandboxIE. Even so, many malware slipped through and managed to do damage. I know it's tempting to say that it reduces TCB because it eliminates TCB issues, but that's only true when it works (and still only true to a degree). Leading to..
The bigger point is that the browser depends on a component that depends on the TCB. If the component fails, the security of the system fails. That's almost the definition of being "trusted" in a security scheme. The component also manages security-critical functionality, meaning it's DEFINITELY in the TCB & even a reference monitor of sorts. I haven't looked at the internal design, as the tests made me recommend DefenseWall instead. ($30 for near immunity to zero-days with almost no performance loss and ease of use? heck yeah!)
So, SandboxIE actually increases the TCB: Windows platform + Browser + SandboxIE. Of course, so do Mandatory Access Controls like SELinux & the "safe" C libraries. Must always ask the question, "Does increasing the TCB make sense in this example?" If we can do it with PGP or a secure email client, then it doesn't. If (1) that's unavailable/unusable, (2) the user must use windows, and (3) user can't afford DefenseWall or AppGuard, then (4) SandboxIE is a justifiable addition to the TCB size because it reduces risk & has a decent security track record.
Like a wise man once said: "It's not the size that counts, it's how you use it." Well, mostly...
"I'd also recommend anyone looking into these kinds of solutions to check out ZixCorp. They've always had many more services than Hush and others" (me)
"I just did. Yuk." (tommy)
"ZixAccess automatically decrypts inbound email from ZixCorp users (Nick, are you sh*tting me?)" (tommy)
Nah, I had no idea. I haven't given their service more than a casual glance in in years. That's why I said "check out ZixCorp." I appreciate you giving us the 411 on it. :)
"Someone in possession of such assets shouldn't be running COTS or commodity stuff anyway, wouldn't you say? "
They might not have a choice. IT security budgets and business priorities set by lay people aren't that great. So, I was just saying different methods should be used. I kind of left it open due to lack of context, except for one specific: trust third party service providers less for operational security, except maybe a reputable firm to set it internal processes initially and/or manage them (security updates, hardening ,etc.). Use an app like PGP, not Hushmail. When certifying documents' content & existence, just hash it with one or two algorithms and let an online notary sign *that*.
It's all COTS but different methods that require less trust & can make use of high quality COTS stuff, like OpenBSD or INTEGRITY. It's risk reduction. Of course, if the assets value is high enough & security is flexible, we'd use more robust approaches like those we've discussed. The operational burdens will prevent that from happening in most cases, which is why I focused on risk reduction rather than mitigation. Was just focusing on a different side of it than usual, I guess.
"What about the drug mule model? Swallow lots of little sealed packages of HE plus a few packages of timer/detonator for redundancy. Some drug mules are carrying 800g to 1kg of cocaine. that weight of explosive would be enough to take down a plane."
There are a few very big unknowns in that argument, and for obvious reasons I don't want to test to find out (nor I suspect do others).
The first is "explosive disruption of explosive devices" sometimes called "controled explosions".
Most "comercial High Explosives" (HE) are very very insensitive and thus actually quite difficult to set off. That is they don't suffer easily from "sympathetic explosions" unless the distances between parts of the HE are very small.
[This however is not true of primary explosives which are the sort that Internet and other recipes make. In general they are very unstable and can detonate if you just give the a little mechanical shock, so the bomber would probably not make it to the target using non comercial explosives]
The conciquence of this is that if you have a big bomb made of comercial HE that you cannot easily defuse, putting a small bomb next to it will blow the big bomb into little pieces without it going off.
So the question becomes are these little packets of HE actually going to explode on mass are just one or two of them?
The second problem is of absorbtion and direction of the explosion caused by the body surrounding the explosives.
We have some information on this from the terrorist. Abdullah Hassan al Asiri, an Al Qaeda operative from Yemen, who attempted to assassinate the head of Saudi intelligence, and counter terrorism, Prince Muhammad bin Nayef with what was first claimed to be a bomb implanted in a body cavity.
[Apparently after investigation it was believed to have actually been sewen into Abdullah Hassan al Asiri's underwear or atleast that is what Prince bin Nayef told advisor John Brennan in a briefing he gave at the White House,
Abdullah Hassan al Asiri stumbled before reaching his target and the bomb went off, and his body caused the explosion to be significantly absorbed and importantly directed downwards not outwards. Thus the damage was significantly less than it might otherwise have been for the quantity of explosive.
Again without carrying out tests (which I'm reasonably certain the DHS/TSA have either not carried out or ignored the results of before releasing thier current scare story) it is difficult to say exactly what would happen. However it would be a reasonable bet that a significant part of the kinetic energy of the explosion would be absorbed by the soft body tissues and it is quite likly that the result would be to release the energy in a manner much more akin to the use of non high explosives (ie subsonicaly). That is the energy of the explosion goes down by volume ie as the cube root of distance not as surface area or the square root of distance from the center of the explosion.
Why is this a reasonable bet, well one method of dealing with small suspect packages is to put them in an open plastic barrel of water. Not to stop the explosion by shorting out electrical timers nor to stop other types of fuses, but simply to transfer the energy of the bomb blast to the water and thereby significantly reducing any blast effects.
Which brings us onto the third problem. Yes small amounts of explosive can cause structural failure of an aircraft but they have to be carefully shaped and positioned, and in intimate contact with the main structural members or leading surfaces of the aircraft. As has been seen small explosions on aircraft don't always bring them down even when they put a hole in the aircraft side, or even cause significant death of pasengers in the cabin.
With the explosion being inside a body it would not be in close let alone intimate contact with the aircraft main structure, the body would absorb and slow down the potential blast of the explosion as would the chair they are sitting in and the other pasengers and seats around them.
So all in all I would expect there to be some damage by a body implant/mule bomb but for it to be mainly messy.
However we will only know if either it is independantly tested, or somebody does it for real.
Is it really necessary to have a discussion about OSS in the middle of a thread about Irish crime? Please. Stop.
@ tommy, Nick P,
Sometimes some of the documents you need to look at are Patent's but this has significant problems in the US (tripple damages etc).
However sometimes you do get to hear about Patents that are making waves in the security arena.
One such is the little spat going on between Google and Oracle.
Oracle are flexing their muscles of (java) patents they aquired from taking over Sun.
Well it looks like the judge is going to through out many of the claims in a Sun pattent because of "prior art" and US Patent 5311591 granted 10th May 1994.
I understand from sources other than looking at the patent that if you were to read it you would find it covers most asspects not just of sandbox's but nearly all resource limiting methods for security including capability lists on computers.
I also understand that there is a body of prior art that might invalidate this patent and that the US Pattent Office is currently looking into it.
As a person living and working outside of the US I used to be glad that "Software Patents" did not apply outside of the US, but sadly the EU has crooked that one.
@ Nick P.:
I hadn't heard of Defense Wall, and will check it out. If you still have the link to those comparative studies, that would be great. If not, no worries; don't make a special effort.
@ Anon Bruce Poster:
O/T posts are not at all uncommon here, although this one was intended to be only a comment on a single paper, viz: the retrospective by the designer of QMail. It wandered a bit, agreed, but that's because IT security can't be compartmentalized into e-mail, OS, etc. -- as Nick P. quite correctly stated. It's still all about IT security.
And as I said in my first post,
"Physical security and IT security are not two different things."
Most readers here find *any* discussion of security interesting, or at least not offensive. And as the world shrinks, a discussion of "Irish Crime" can't possibly have implications only on Irish Crime (or Irish Cream, lol) or Irish LE. It affects us all, ultimately.
Nick and I had been using another thread that since slipped off the home page, so I thought to continue it here, in case others were interested in the QMail paper //and its lessons for today and tomorrow//. Check it out yourself.
I'm sorry you were offended. If the Moderator deletes the posts as O/T, so be it. But I don't remember ever seeing that happen, absent outright spam.
Nick P. may some day offer a re-design of this blog to a more forum-like model, where there could be separate threads for O/T posts.
@ Clive Robinson:
The entire body of patent law, which did *not* evolve in time to address whether sequences of 0s and 1s are patentable (because they had no value 100 years ago), is going to need a complete rethinking, I agree. It's going to be a long and arduous process.
@Clive: You're very welcome, from the US, for software patents. Now pay up, you're infringing something.
I long for the day I will see patent reform, which will probably be someday after my great-great-great grandchildren retire (I'm in my early 30's, so don't hold out hope). Congress won't dare touch it, because the folks paying them don't want patents to go away. The Supreme Court has refused to do anything, instead deferring to the Congress. The Executive, well, as you're aware, they are too busy trying to shove our repressive IP laws down Europe's, Russia's, and everyone else's throats. And if you won't comply, then we will find some way to sanction you (and maybe drop a few bombs on you as well). Because we will forever be the only large market in the world, and no one will ever supersede us, or decide to sell their uber-cool (but potentially infringing on some obvious catch-all patent) device elsewhere besides the great ole USA. Heck, our IP laws will be so strong globally, we are cutting education for our future generations, since we will never need to invent anything again. God forbid we ever had to become competitive again. Now, i just hope those foreign companies don't get sneaky and start using our own patent laws against us.
"Is it really necessary to have a discussion about OSS in the middle of a thread about Irish crime? Please. Stop."
Is it really necessary to link to Bruce Schneier jokes during a serious discussion? As opposed to an informative, on-topic web page?
Regardless, the blog encourages these kinds of flowering of ideas. Moderator normally takes corrective action in these situations: flame war; spam; trolling. So long as it's beneficial to readers, the moderator & Schneier tend to let tangent discussions continue. This is especially the case when plenty has been said on-topic, like in the majority of the comments on this article.
If anything, the number of unmoderated tangent discussions that Clive, RSH, BF Skinner, tommy and I've had over the years shows a strong support for free speech and exchange of ideas on this blog. That model allows for moments of serendipity where important security, privacy, etc. issues are spontaneously addressed and needs met during a tangent exchange between members. This, combined with proper moderation & civilized regulars, makes the creative output of this blog's comment section better than most blogs' articles.
In conclusion, restricting the exchange of beneficial ideas on this blog is a very bad idea. It brings no real benefits & causes real detriment. Not quite a good cost-benefit analysis, ya think?
@ Nick P.:
>>>>"Is it really necessary to have a discussion about OSS in the middle of a thread about Irish crime? Please. Stop."
"Is it really necessary to link to Bruce Schneier jokes during a serious discussion? As opposed to an informative, on-topic web page?"
ROFLMAO! Fight fire with fire ... +10.
"the blog encourages these kinds of flowering of ideas."
I should have mentioned the many discussions that started ON-topic, then flowered -- nice choice of words, but would "fractalized" be more accurate? -- nahh, they follow chaos theory more closely -- into various other related topics, each with separate branches, and a huge output of brainstorms.
"... restricting the exchange of beneficial ideas on this blog is a very bad idea. It brings no real benefits & causes real detriment. Not quite a good cost-benefit analysis..."
You said it much better than I did. Well done.
@ Anon Bruce Poster:
One last point to make: A frequent topic here is how as IT defenses have improved, malware has adapted accordingly, and morphed into new forms not yet defended against. Here, banks and cash couriers improved their defenses, so malpeople adapted accordingly, to new forms not yet defended against.
Not only is the analogy perfect, but since malware is created by malpeople, it's actually the same topic. At the risk of repeating myself, physical and electronic security are not two different things. The malpeople are adapting, whether in physical attacks or electronic ones.
btw, I hereby claim copyright, trademark, and patent-pending rights to "malpeople™". ©® 2011 by tommy. All rights reserved. Please contact the author (through the sig-link) for written permission to use this term, and the address to which to send royalty checks. Your cooperation is greatly appreciated.
@ Nick P. re: Defense Wall
Gave it an eye-blink. Very different approach. Saw a few possible pros and cons. When time permits, will examine more thoroughly (esp. for usefulness by non-tech users), and possibly give it the 30-day test drive. Thanks for yet another good, on-topic (coughsecuritycough) link.
Poetic but although Evolution is an analogy, 'selective breeding' is a better one because the former is blind, the latter is directed.
Clive: Re dye-spraying safes. Not a problem. Just get the specs from whoever makes them, figure out how to defeat them. It's not rocket science - it's a safe with a trigger and a dye sprayer! Not bloody nanotech!
Tommy: "If you want to compare OS to OS only, can you isolate out how many are in the Linux OS portion alone? I'd be glad to know, thanks."
It's been done. Google for the reports that compare Windows and Linux vulnerabilities by OS vs applications.
If I'm not mistaken, the Linux OS and OSS in general (at least those OSS projects with a major number of developers, not those with only a few developers) generally have fewer bugs of all kinds than commercial software of equivalent size. Which should mean fewer security holes as well. Google for the studies.
"how many [bugs] are FOUND and exploited is definitely relevant. Consider the rude awakening that Mac users are getting after being so smug for all these years. "
True. But compared to Windows, where there are HOW many millions of malware vs the Mac where there are HOW many single digits of malware? It will take a generation until Macs are as exploited as Windows - and another generation until Linux is so afflicted. Up to a couple years ago, there were approximately a dozen or so malware for Linux - most of which were user space only laboratory proofs of concept, almost none in the wild.
Linux is STILL almost completely secure against malware (if not an active hacker) compared to Windows or even Macs. I go to porn sites with great confidence using openSUSE 11.4 - as long as I'm using NoScript in the Firefox browser to avoid browser hijacks.
OTOH, I have a client who can't resist screwing his Windows XP machine just about weekly by using IE on porn sites despite my telling him emphatically not to run IE for ANY reason.
As for your copyrighted "malpeople", I suspect the term "malefactor" constitutes "prior art" - and in any event I just uploaded it via Bittorrent, so good luck... :-)
Mr Schneier & Moderator,
Given the traffic that this blog enjoys and the fact that the comments that each post generates is usually just as worthy of one's attention as the original blog post, would you give consideration to building a forum so discussion of various security topics could be achieved in a manner that is easily followed, searched and continued? There's enough traffic through here of like-minded souls to turn www.schneier.com into a hub for sober minded discussion among those who truly know their stuff. Seems a shame to have so much good information buried in a comments format that discourages a community from growing.
Thanks for the consideration.
N.B. Hope you get well soon, Mr. Robinson.
@Richard Steven Hack: "Re dye-spraying safes. Not a problem. Just get the specs from whoever makes them, figure out how to defeat them."
I am of the opinion that such things can be make reasonably safe (i.e., it is infeasible to defeat them under realistic circumstances) - especially if the designers opt to risk some false positives in exchange for a reduced false negative rate.
Mind you that a robbery is not a laboratory situation, but rather a quite time-constrained (if not to say, hectic) scenario with quite limited available equipment (even apart from other considerations, the whole thing must be cost-effective, too).
I have an almost unlimited tolerance for security discussion when it arises through natural digression and drift. I like seeing where things lead. But transplanting a discussion from a different thread is different -- more like threadjacking -- and I'm not surprised there were complaints about it.
I do see the problem that old threads are hard to keep track of, so I'm going to add comment feeds to entries. It will probably take about an hour before feed links show up on every entry. After that, please keep conversations in the thread where they start. That will also be a lot easier for people who find the conversation later through search or Bruce's archives and want to read it to the end.
I doubt Bruce would be interested in running a forum. Someone could start an unofficial one offsite. But *this* is a blog comment section, so Bruce is the one who starts threads and chooses topics. The topicality requirements are obviously very loose -- on purpose -- but not nonexistent; starting off-topic conversations in random threads is still frowned on. Less so in the squid threads, since there's usually not a lot to disrupt there.
I appreciate your clarification.
Paeniteo: "but rather a quite time-constrained (if not to say, hectic) scenario with quite limited available equipment (even apart from other considerations, the whole thing must be cost-effective, too)."
I agree completely. And especially for the average armored car robber. I've known a couple here in the US during my incarceration and they didn't look like the kind of guys who could defeat a system like that.
But criminal ingenuity can also surprise you. Also, vis-a-vis cost effective, the method needs to be developed once and the equipment used needs to be purchased once. Since armored cars are usually good for $50K-100K or more, I'd say it is likely cost-effective to do so. Bank robberies generally pay off on average MUCH less than an armored car job. Which is good because the risk is much higher for an armored car job.
I think we can predict that someone will figure out how to defeat the system - and then armored car jobs will go back up statistically until some new defense is deployed.
@ Richard Steven Hack
"Since armored cars are usually good for $50K-100K or more, I'd say it is likely cost-effective to do so. "
I'm inclined to agree with you. We already see skimmers developing to defeat ATM security measures, reduce risk via use of bluetooth/SMS, and then selling for thousands of dollars. The crooks make the investment because they think it will pay off.
Now, getting the specs for such a safe might be hard. Specifically, for the tamper-resistant portion. Even so, sophisticated crooks might just buy one, analyze it carefully while trying not to set it off, and then analyze it after setting it off. They might find a way to deal with it. For instance, they might find that the dye pack is in a vulnerable spot whereby it can be penetrated and siphoned out before the safe is cracked, rendering the defense mechanism useless.
I think a good design would still make many attacks impractical, but bad designs abound in commercial security.
Tiger raid at Newcastle West Post Office - how come Postmaster, Tom Kelleher is suspended from running the office even though he was on holidays abroad at the time of the robbery.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.