Message-ID: <e92364c304090204161d5d58d4@mail.gmail.com>
From: jftucker at gmail.com (James Tucker)
Subject: Response to comments on Security and Obscurity

On Thu, 2 Sep 2004 13:13:29 +0400, 3APA3A <3apa3a@...urity.nnov.ru> wrote:
> You  may  be  really  good specialist in IT security familiar with every
> law,  article  and  recommendation,  but  to  make  any real example for
> informational  security  problems you MUST understand difference between
> cracks, exploits, virii and backdoors you do not currently understand.

Well, I am not. I am a student of security as everyone is. To think
that one is familiar with everything, or even larger percentages of
the detail required simply contradicts good security. You can spend
your life at this and still be surprised. Open up your mind, when you
accept that any hole is bad, then ALL information is good, as it is
all thought provoking.
I do understand the differences in definition between cracks,
exploits, viruses and backdoors, but the home truth is that if any one
opens a hole in your security or compromises data on the system, the
effect is largely the same; as such when it comes to dealing with
them, they are equally as dangerous as each other.
Cracking software or algorithms has a simple home truth which should
also be realised, as with the way that you can always brute force an
algorithm, you can always crack a piece of software if it works. There
will always be code present which makes up the software component, if
this is extracted and all protections are removed, you have
successfully cracked your software. This is no different from
attempting to "encrypt HTML" - one of the silliest notions i have ever
heard. If the browser renders HTML to make what you see, then it has
at some point read plain HTML. If someone wants to capture this, they
will. Same thing with most all forms of crack at some point in the
cycle.
Exploiting bugs / errors in a system is a simple process, finding them
is not. The more sophisticated exploits are ones which never actually
break any protocol rules.
Viruses (the pleural BTW) do I really need to go into all of the
technologies involved?
Backdoors well, not actually as common as many people think, a virus
carrying the ability to turn a machine into a zombie is not carrying a
backdoor, in fact its a program which opens its own front door to the
world. Backdoors are supposed to be unknown to the user, well the user
of a trojan style virus is the person who sent it into the wild, and
their surrounding community. There was a backdoor discovered in one of
the common trojan client applications less than a year ago, and the
developer received a great deal of hassle for it.


> OK,  I  will  exploit  computer  in  Russia  by  first  researching open
> materials   (for   example   conferences  participants  lists),  finding
> appropriate  persons  with  interests in required fields who potentially
> may  have  access  to required network and trying to contact them. After
> researching  I  will  either try to attack their home computers (because
> it's  very  common  case really secret materials are kept in home PCs or
> notebooks  almost  unprotected)  or  simply hire them (money, blackmail,
> etc).  For  attack I will most probably use client application (browser,
> mail  reader, etc). Of cause my potential and knowledges for second case
> are very limited :)

heh, well we said it had no physical data path to the outside world
now didn't we. I don't suppose your client application will be of much
use as a browser or mail reader. Attention to detail is just as
important as RTFM.

> Even  more.  This  is  very  common  scenario  and this scenario must be
> covered  by security policy. You either unfamiliar with this problem our
> your information is out of date.

Security policies never "go out of date" and this scenario as you
agreed with me, is still common today. If it is still common then
please explain how is this "out of date"?
Even viri don't go "out of date", although many virus checkers
probably don't hold some of the really old DOS, amiga, apple and unix
virus definitions. As we have seen in another discussion on this list
there may well still be a risk of possible infection over RS232, no
mater how unlikely it is, I respect the author of that question for
asking about such possibilities. He was clearly trying to cover all
bases.


>   Simple,  but  unreliable  protection  for this problem is implementing
> policy  for automatic workstation lockout (well, in my network with very
> low  security  requirements  I  use  this  kind of protection). Reliable
> solutions  are:  use  same  cart  for access both terminal and room (Sun
> likes this kind of solutions - terminal locks automatically if smartcard
> is  removed)  or  to  use  event  correlation  (it's currently a part of
> Security  Information  Management  Systems).  If  event "user leaves the
> room"  comes  without  first "user logs off" or "user locks workstation"
> either  user access out of room is blocked or user's workstation is shut
> down remotely.

I am aware of this, however follow the same scenario through to
fruition and you will find the CEO doesn't bother to take out his
smart card, at least for the first 6 months of having one. Education
of the good sir is the only way to deal with this problem properly. I
agree that there are ways of making virtual security harder against
poor physical security, of course thats the case; however we could go
back and forth with examples of how they will fail against each other
for years. What we will end up with is a very elaborate virtual
solution involving much new physical infrastructure to provide the
virtual world with more information, it would have been more efficient
to pay a guard to stand at the door.

> Of   cause,  I  understand  you're  trying  to  catch  me  on  the  fact
> informational  security  is  impossible  without physical one. Currently
> information  security  and  physical security go together so close, that
> border  is  very  unclear.  But you're going aside from initial problem:
> examples and analogies from IT in your article are dummy.

As I have stated in another e-mail I sent this morning analogies are
not perfect, however do you really plan on spending a few years giving
each user the experience and thoughtfulness to achieve a high level of
security awareness?
It's not my article, and analogies aren't "dummy" for the above reason. 
Remember you can learn as much about life from listening to the life
story of a bum living on the streets as you can from a millionaire.
The opinions and stories are simply different, not less accurate or
less relevant.

Powered by blists - more mailing lists