The more highly skilled the adversary, the more likely the client
will be to permit you to perform a comprehensive bug sweep, and in
turn (as perverse as this sounds) you are more likely to find the
more sophisticated device because the search is driven by the
requirement to neutralize the eavesdropping, not just figure out to
figure out "if ", but more of how. In these higher threat situations
the client knows that espionage is going on, and may actually have
evidence that it is afoot, but they can't quite figure out how the
information is getting into the spies hands.
It could be a bug, or a computer virus, a web-cam, manipulation of
the phone system, or something as simple as acoustic leakage, lock
manipulation, recycle bin pilferage, or even low tech bribes,
kickbacks, and payoffs. The point of bringing a TSCM specialist to
the find the weak points of a technical nature that a spy may have
introduced, or one which the spy may be exploiting but not to have
actual inserted (ie: VOIP exploit over a cable modem).
If you deal with a higher threat clients you may find the problem
80+% of the time, and by "problem" I do not necessary mean an actual
bug, but rather the technical mechanism the spy is using for the
operation. If the target is of extremely high interest to the spy
(bulk crypto gear on a classified network) you will likely find a
technical penetration or attempted penetration closer to 100% of the
time. You may find that the firm wire in the encryption gear has been
backdoor'ed like the Swiss firm was doing, you may find that the
crypto was modified to help it leak encrypted data over the power
lines, or you may have a deliberately damaged ground (my favorite),
or even a good old fashion RF transmitter. The noise diodes may have
been disabled, or you may be getting packet diversion, or packet
duplication to the eavesdropper.
In a typical corporate situation (not involving classified
information) you are likely to see technical exploitation or
eavesdropping being used in less then 18-20% of the time, with a
"find rate" less then 5%, and more likely closer to 3% where
eavesdropping is quasi-legal.
The fact that you do not find a bug on a cursory sweep does not mean
that one is not present, nor does the complete absence of a bug mean
that eavesdropping is not taking place. Does the customer use a
cordless phone? can you pick up the IF scanner that tracks the 900
MHz signal you use to fake out the eavesdropper? Is there a bridge on
the phone lines, and if so is there anything attached to the bridge?
Doe the huge volume of damage to the latch mechanism of the door to
your client office tell you anything, and why is there a 1/4 hole in
the gasket on the outside of the window, or a brick with loose or
discolored mortar. Does the executive who hired you, and who has the
super expensive lock and panic room built also let his secretary keep
a copy of the key in her unlocked desk drawer? How about the recycle
or shredder bins? are they locked?
Yes, yes... it is nice that the corporate server farm is protected
behind a vault door made of solid unicorn horn, and protected by 7
foot trolls, and so forth, but when you can enter the server room
from the loading lock area, and just plug in your own RAID drives so
that you can come back an retrieve at a later date.
A good rule, is that you should be finding a bug 3-5% of the time for
a legitimate corporate (not government) sweep, but only if the client
is not suffering from medical "issues" and being delusionary. If you
have a client who is in the high dollar sports and entertainment
industry you can safely increase these number three fold (9-15%), in
a domestic situation you can frequently find evidence of tape
recorders being used, wrappers from tapes on the ground, or even long
play DVR systems with 16 cameras and batteries to run the system for
3 weeks at a time.
-jma
At 08:00 PM 1/17/2008, Michael Dever wrote:
>James
>
>Not disputing anything you have said in your 'rant', however I jut
>wanted to say that I think 'hit' rate (or discovery) statistics are
>a crock... there are so many variables to make simplistic
>comparisons between sweeps problematic. I know you qualified your
>statements by breaking down your stats into low, medium, high threat
>situations, but most sweep teams will lump all jobs into one group.
>As you well know, it is unlikely that any two sites are physically
>the same, or are exposed to the same threats, or have the
>same vulnerabilities....
>
>I get asked all the time by clients and prospective clients 'how
>many bugs do you fine?'... I find this question a little irritating
>actually. Some clients ask for a sweep because they have some other
>evidence that they may be compromised, some ask for a sweep as a
>preventative activity... If you are dealing with a site that is
>relatively secure (both physically and administratively) then it
>will require a skilled adversary to penetrate. This would represent
>a high threat situation but not necessarily a high risk because the
>site may not be vulnerable to a low skilled adversary. A low skilled
>adversary is not going to have the skills or equipment to penetrate
>a relatively secure facility.... therefore, IMHO the most important
>first step in sweep is an accurate threat assessment (who are your
>adversaries, what is their capability, intent and motivation).
>
>Regards
>Mike
>
>
>On 18 Jan 2008, at 10:43, James M. Atkinson wrote:
>
>>
>># rant2008v2.0.c
>>include rant2007.h
>[snip]
>
>
>Michael J. Dever CPP PSP
>
>Dever Clark + Associates
>GPO Box 1163
>Canberra ACT 2601
>Australia
>
>Voice: +612 6254 5337
>Mobile: +61419 252 839
>Email: <mailto:d..._at_bigpond.net.au>d..._at_bigpond.net.au
>
>This message is sent in strict confidence for the addressee(s) only.
>It may contain legally privileged information. The contents are not
>to be disclosed to anyone other than the addressee.
>Unauthorised recipients are requested to preserve this
>confidentiality and to advise the sender immediately of any error in
>transmission.
>
----------------------------------------------------------------------------------------------------
World Class, Professional, Ethical, and Competent Bug Sweeps, and
Wiretap Detection using Sophisticated Laboratory Grade Test Equipment.
----------------------------------------------------------------------------------------------------
James M. Atkinson Phone: (978) 546-3803
Granite Island Group Fax: (978) 546-9467
127 Eastern Avenue #291 Web:
http://www.tscm.com/
Gloucester, MA 01931-8008 E-mail: mailto:jm..._at_tscm.com
----------------------------------------------------------------------------------------------------
We perform bug sweeps like it's a full contact sport, we take no prisoners,
and we give no quarter. Our goal is to simply, and completely stop the spy.
----------------------------------------------------------------------------------------------------
--=====================_312462453==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
<br>
The more highly skilled the adversary, the more likely the client will be
to permit you to perform a comprehensive bug sweep, and in turn (as
perverse as this sounds) you are more likely to find the more
sophisticated device because the search is driven by the requirement to
neutralize the eavesdropping, not just figure out to figure out "if
", but more of how. In these higher threat situations the client
knows that espionage is going on, and may actually have evidence that it
is afoot, but they can't quite figure out how the information is getting
into the spies hands.<br><br>
It could be a bug, or a computer virus, a web-cam, manipulation of the
phone system, or something as simple as acoustic leakage, lock
manipulation, recycle bin pilferage, or even low tech bribes, kickbacks,
and payoffs. The point of bringing a TSCM specialist to the find the weak
points of a technical nature that a spy may have introduced, or one which
the spy may be exploiting but not to have actual inserted (ie: VOIP
exploit over a cable modem).<br><br>
If you deal with a higher threat clients you may find the problem 80+% of
the time, and by "problem" I do not necessary mean an actual
bug, but rather the technical mechanism the spy is using for the
operation. If the target is of extremely high interest to the spy (bulk
crypto gear on a classified network) you will likely find a technical
penetration or attempted penetration closer to 100% of the time. You may
find that the firm wire in the encryption gear has been backdoor'ed like
the Swiss firm was doing, you may find that the crypto was modified to
help it leak encrypted data over the power lines, or you may have a
deliberately damaged ground (my favorite), or even a good old fashion RF
transmitter. The noise diodes may have been disabled, or you may be
getting packet diversion, or packet duplication to the
eavesdropper.<br><br>
In a typical corporate situation (not involving classified information)
you are likely to see technical exploitation or eavesdropping being used
in less then 18-20% of the time, with a "find rate" less then
5%, and more likely closer to 3% where eavesdropping is
quasi-legal.<br><br>
The fact that you do not find a bug on a cursory sweep does not mean that
one is not present, nor does the complete absence of a bug mean that
eavesdropping is not taking place. Does the customer use a cordless
phone? can you pick up the IF scanner that tracks the 900 MHz signal you
use to fake out the eavesdropper? Is there a bridge on the phone lines,
and if so is there anything attached to the bridge? Doe the huge volume
of damage to the latch mechanism of the door to your client office tell
you anything, and why is there a 1/4 hole in the gasket on the outside of
the window, or a brick with loose or discolored mortar. Does the
executive who hired you, and who has the super expensive lock and panic
room built also let his secretary keep a copy of the key in her unlocked
desk drawer? How about the recycle or shredder bins? are they
locked?<br><br>
Yes, yes... it is nice that the corporate server farm is protected behind
a vault door made of solid unicorn horn, and protected by 7 foot trolls,
and so forth, but when you can enter the server room from the loading
lock area, and just plug in your own RAID drives so that you can come
back an retrieve at a later date.<br><br>
A good rule, is that you should be finding a bug 3-5% of the time for a
legitimate corporate (not government) sweep, but only if the client is
not suffering from medical "issues" and being delusionary. If
you have a client who is in the high dollar sports and entertainment
industry you can safely increase these number three fold (9-15%), in a
domestic situation you can frequently find evidence of tape recorders
being used, wrappers from tapes on the ground, or even long play DVR
systems with 16 cameras and batteries to run the system for 3 weeks at a
time.<br><br>
-jma<br><br>
<br><br>
<br><br>
At 08:00 PM 1/17/2008, Michael Dever wrote:<br>
<blockquote type=cite class=cite cite="">James<br><br>
Not disputing anything you have said in your 'rant', however I jut wanted
to say that I think 'hit' rate (or discovery) statistics are a crock...
there are so many variables to make simplistic comparisons between sweeps
problematic. I know you qualified your statements by breaking down your
stats into low, medium, high threat situations, but most sweep teams will
lump all jobs into one group.<br>
As you well know, it is unlikely that any two sites are physically the
same, or are exposed to the same threats, or have the same
vulnerabilities....<br><br>
I get asked all the time by clients and prospective clients 'how many
bugs do you fine?'... I find this question a little irritating actually.
Some clients ask for a sweep because they have some other evidence that
they may be compromised, some ask for a sweep as a preventative
activity... If you are dealing with a site that is relatively secure
(both physically and administratively) then it will require a skilled
adversary to penetrate. This would represent a high threat situation but
not necessarily a high risk because the site may not be vulnerable to a
low skilled adversary. A low skilled adversary is not going to have the
skills or equipment to penetrate a relatively secure facility....
therefore, IMHO the most important first step in sweep is an accurate
threat assessment (who are your adversaries, what is their capability,
intent and motivation).<br><br>
Regards<br>
Mike<br><br>
<br>
On 18 Jan 2008, at 10:43, James M. Atkinson wrote:<br><br>
<blockquote type=cite class=cite cite=""><br>
# rant2008v2.0.c<br>
include rant2007.h<br>
</blockquote>[snip]<br><br>
<br>
Michael J. Dever CPP PSP<br><br>
Dever Clark + Associates<br>
GPO Box 1163<br>
Canberra ACT 2601<br>
Australia<br><br>
Voice: +612 6254 5337<br>
Mobile: +61419 252 839<br>
Email:
<a href="mailto:d..._at_bigpond.net.au">d..._at_bigpond.net.au</a><br><br>
This message is sent in strict confidence for the addressee(s)
only. <br>
It may contain legally privileged information. The contents are not to be
disclosed to anyone other than the addressee. <br>
Unauthorised recipients are requested to preserve this confidentiality
and to advise the sender immediately of any error in
transmission.<br><br>
</blockquote>
<x-sigsep><p></x-sigsep>
----------------------------------------------------------------------------------------------------<br>
World Class, Professional, Ethical, and Competent Bug Sweeps,
and<br>
Wiretap Detection using Sophisticated Laboratory Grade Test
Equipment.<br>
----------------------------------------------------------------------------------------------------<br>
James M.
Atkinson
Phone: (978) 546-3803<br>
Granite Island
Group
Fax: (978) 546-9467<br>
127 Eastern Avenue
#291
Web:
<a href="
http://www.tscm.com/" eudora="autourl">
http://www.tscm.com/<br>
</a> Gloucester, MA
01931-8008
E-mail:
<a href="mailto:jm..._at_tscm.com" eudora="autourl">mailto:jm..._at_tscm.com<br>
</a>
----------------------------------------------------------------------------------------------------<br>
We perform bug sweeps like it's a full contact sport, we take no
prisoners, <br>
and we give no quarter. Our goal is to simply, and completely stop the
spy.<br>
----------------------------------------------------------------------------------------------------<br>
<br>
</body>
</html>
--=====================_312462453==.ALT--
Received on Sat Mar 02 2024 - 00:57:20 CST