[cap-talk] The Limits of POLA's Utility - Social Engineering

[Toby Murray]

Ka-Ping Yee wrote:

>On Wed, 7 Jun 2006, Toby Murray wrote:
>  
>
>>It's not so much that Alice's files got accessed. It's just the bigger
>>question of "Can POLA stop viruses?".
>>    
>>
>
>I think we need to be clearer about the definition of "virus."  The
>scenario you've described stretches the definition of "virus" so far
>that it seems it might also include, say, a chain letter or a blog
>"meme".  So what exactly are you calling a virus?
>
>  
>
The most loose definition is any self-propagating automata. So a chain 
letter or meme don't quite count because they don't execute. Consider an 
adware peer-to-peer client like KaaZaa that has a check-box saying 
"Recommend me to your friends" that then sends emails on to everyone in 
your address book to entice them to join the p2p network.
(The original paper goes on to discuss this sort of thing in later sections)
I'm not saying that all of this stuff is "bad", nor that POLA 
necessarily should be able to protect you against it. It's more a 
thought exercise imagining how dangerous their "Satan virus" might be in 
a full POLA environment and what (extra) precautions would help guard 
against it (other than POLA).

>>A system that prevented Bob from doing the illegal/immoral thing would
>>make him and Alice more secure. My original point was that POLA might
>>not be sufficient to do this sort of thing. But if not POLA, then what
>>could help protect Bob from himself?
>>    
>>
>
>Nothing, in the absolute.  I don't think this is a strong argument for
>the insufficiency of POLA. 
>
Just to be clear, I'm not saying that POLA is no good or otherwise 
trying to diminish it an any way. I reckon POLA is close to the best we 
can do, besides trying to do the things you point out below as well. I'm 
just trying to explore the boundaries of the sorts of problems that POLA 
can solve and those that it is less able to help you with.

> We can aim to make sure Bob is aware of the
>potential risks of his actions, in terms and in a context he understands.
>We can make more risky actions less probable than less risky actions.
>The goal is not to eliminate all risk; it's to align Bob's understanding
>of the risks with the actual risks.
>
>  
>
Cool, that seems like a good piece of wisdom in general. I guess this 
would apply equally well to all social engineering attacks. Thanks.

[the following is digressing a bit into a discussion of how we might do 
what Ping suggests above. If people feel this is too off-topic then 
please ignore this email and accept my apologies]

OK, if I may take this a bit further then, in this example, how can we 
make Bob aware of the risk of giving this virus the authority to access 
the network? One obvious risk Bob needs to be aware of is "Any entity 
that offers you a service can track your use of that service". Hence, if 
the service is illegal, then you are incriminating yourself to that 
entity. Is there other options besides user education?

I don't know if the following is too cute or what...
Bob has to install the virus (give it write access to some stable 
storage) if it is to persist. At this time, in a POLA environment, he 
would presumably grant it network access. This is a time when Bob could 
be warned by "the system". e.g. "You are about to install a networked 
service. Be aware that your use of this service can be tracked and that 
any evidence of illegitimate use may be used against you."

The other thing is to make Bob aware of the risk of running an unknown 
piece of software in the first place.
If all of Bob's social group are already infected, then judging the 
risky-ness of the software based on the trustworthiness of the 
introducer (which is likely to be one of Bob's friends) may not be all 
that helpful. This seems to be leading to an argument in favour of the 
current models of PKI signed code and software blacklists/whitelists. 
Having a "secondary introducer" (such as the PKI or a software whitelist 
controlled by an AV company perhaps) could guard against this threat 
(where Bob's normal trusted introducers have become compromised), 
allowing Bob to make a better judgement about the risks.


-- 
Toby Murray
Advanced Computer Capabilities Group
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.