Tuesday, June 30, 2009

Understanding Svchost

Some relatively simple code helps us understand svchost processes. You will need a large screen to display the output:

$global:svchost = get-wmiObject win32_process -filter "name='svchost.exe'"
$global:win32_handle = $svchost | foreach { gwmi -query "Select * from win32_service where processID = $($_.handle)" }
$global:Sort_handle = $win32_handle | sort processID, Name
$global:Sort_svchost = $svchost | sort processID
$Sort_handle | format-table processID,name,state, startmode,Started,AcceptStop,Description -AutoSize
$Sort_svchost | format-table ProcessID,ThreadCount,HandleCount,WS,VM,KernelModeTime,ReadOperationCount,ReadTransferCount,OtherTransferCount -Autosize

[Output]:

:.\Get-SvcHost_005.ps1

processID name state startmode Started AcceptStop Description
--------- ---- ----- --------- ------- ---------- -----------
840 SSDPSRV Running Manual True True Enables discovery of UPnP devices on your home network.
1168 stisvc Running Auto True True Provides image acquisition services for scanners and cameras.
1204 DcomLaunch Running Auto True False Provides launch functionality for DCOM services.
1292 RpcSs Running Auto True False Provides the endpoint mapper and other miscellaneous RPC services.
.....


ProcessID ThreadCount HandleCount WS VM KernelModeTime ReadOperationCount ReadTransferCount OtherTransferCount
--------- ----------- ----------- -- -- -------------- ------------------ ----------------- ------------------
840 9 236 6078464 39940096 468750 369 48936 129130
1168 5 210 6574080 41291776 11093750 438 53831 32770
1204 5 209 6381568 43548672 3125000 383 53947 330048
1292 10 457 7004160 45506560 24375000 506 465380 63666
.....

Wednesday, June 17, 2009

Conflict and Confusion

For years, I didn't run DEP, Anti-Virus or other behavioral blocking software because I believed the hit on machine performance simply wasn't worth it. Additionally, I found most "protective software" bulky and and inelegant. Some noticeable exceptions were BlackICE (now defunct) and a PC host firewall now owned by CheckPoint. To rid myself of Viruses occassionally, I would use TrendMicro's housecall. In any event, after some years struggling to find a decent mail client that protected me from virus ridden junk mail...So recently I have installed two AV softwares and DEP. Sophos was working until I opened my mail box and tried to clean some junk mail. Very soon after, Sophos stopped working. I then installed PC Tools which found me riddled with adware,viruses and Trojans. Now neither is working quite right. I am unsure at this point if the problem is DEP or whether the AV software has become infected intself. The desktop disaster looks something like:








Sunday, June 14, 2009

Too Much, Too Fast...Part II

Above and far below might be the type of topology or map you may want to look at if you had a million or so Conficker machines and you were considering where to store your next payload so that it would remain:

(1) well-hidden
(2) ever-present

The first column (also the X axis above) is the count of the number of times this particular memory size is stored on my machine. The second column (in KB and Y axis above) is the memory size itself. The last print column are those Windows modules at that particular size. This is the type of topology that would help lay out the battlefield for the Botnet Generals. It would help answer questions like:

(1) Where should/could our armies live?
(2) How much space or resources will we have for them?
(3) Who will house them? What dll will be called the most frequently with what access?

Any administrative access to Win 7 or Win2008 would have Powershell/WinRM waiting to be configured. Thus this type of surveillance of Windows desktop could be done on a very large scale quickly and dynamically. And the analysis could be granular: per region, per industry, per subnet, etc.

[Powershell]
$Global:ps = ps
$ps_count = $ps.count
write "Process Count = $ps_count"
$Global:all_modules = 0..$ps_count |%{$ps[$_].Modules} | Select Size,ModuleName,FileName,FileVersion
$Global:all_modules_memory = $all_modules | Select -property ModuleName,Size | Sort -property Size
$all_modules_memory | sort -Descending -property Size | group -property Size
[partial dump]:
....
63 712 {@{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}
13 704 {@{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}...}
1 680 {@{ModuleName=xpsp3res.dll; Size=680}}
1 676 {@{ModuleName=TzShell.dll; Size=676}}
1 672 {@{ModuleName=swg.dll; Size=672}}
2 656 {@{ModuleName=RASDLG.dll; Size=656}, @{ModuleName=localedata_others.dll; Size=656}}
3 652 {@{ModuleName=MSVCR90.dll; Size=652}, @{ModuleName=MSVCR90.dll; Size=652}, @{ModuleName=MSVCR90.dll; Size=652}}
2 644 {@{ModuleName=chartmodelmi.dll; Size=644}, @{ModuleName=Microsoft.PowerShell.ConsoleHost.ni.dll; Size=644}}
1 636 {@{ModuleName=SavNeutralRes.dll; Size=636}}
1 632 {@{ModuleName=localedata_euro.dll; Size=632}}
1 624 {@{ModuleName=System.Transactions.ni.dll; Size=624}}
67 620 {@{ModuleName=ADVAPI32.dll; Size=620}, @{ModuleName=MSVCR80.dll; Size=620}, @{ModuleName=ADVAPI32.dll; Size=620}, @{ModuleName=ADVAPI32.dll
30 616 {@{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dl
2 604 {@{ModuleName=stlport_vc7145.dll; Size=604}, @{ModuleName=stlport_vc7145.dll; Size=604}}
21 596 {@{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; S
63 584 {@{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=
63 580 {@{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=
1 576 {@{ModuleName=QuickTimeMPEG4Authoring.qtx; Size=576}}
1 572 {@{ModuleName=QuickTimeEffects.qtx; Size=572}}
1 564 {@{ModuleName=diasymreader.dll; Size=564}}
2 560 {@{ModuleName=wzcsvc.dll; Size=560}, @{ModuleName=printui.dll; Size=560}}
46 556 {@{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dl
3 544 {@{ModuleName=shdoclc.dll; Size=544}, @{ModuleName=libdb42.dll; Size=544}, @{ModuleName=shdoclc.dll; Size=544}}
1 532 {@{ModuleName=wbemcore.dll; Size=532}}
2 528 {@{ModuleName=xcrmi.dll; Size=528}, @{ModuleName=dopdfui5.dll; Size=528}}
1 520 {@{ModuleName=HPQTOA~1.EXE; Size=520}}
2 516 {@{ModuleName=evtsys.exe; Size=516}, @{ModuleName=winlogon.exe; Size=516}}
4 512 {@{ModuleName=tlmi.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size
31 508 {@{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; S
....

Too Much, Too Fast

At some point, the software industry will have to come to terms with the fact that it grew too fast, created too many rapid application development vehicles and expanded code into Operating Systems that just cannot fundamentally withstand concerted attacks from hackers, organized crime, nation state terrrorists, etc. Ultimately, the best defense against intrusion, worms, buffer overflow attempts, etc will be to 'native sentinel' programs that can 'electric fence' every loaded feed, hook, interface, binary,library against suspicious behavior. Current processor memory/development may allow for such sentries. Indeed 'DEP' (Data Execution Protection) could be termed a 'native sentinel' program. However, in many ways there is just too much going on inside a modern OS to be well-protected.This is some Powershell output from my Windows laptop. Notice:
(1) How may modules are (2701) in use by a limited number of applications (64) and
(2) How many modules (515 unique out of 2701 total) are being shared in multiple applications

$ps = ps
$count = $ps.count
$count
64

$all_modules = 0..$count |%{$ps[$_].Modules} | Select BaseAddress,EntryPointAddress,Size,ModuleName,ModuleMemorySize,GetLifetimeService,FileName,FileVersion,Company,Description
$all_modules.count
2701

$unique_all_modules = $all_modules | Select -property ModuleName | Sort -Unique -property ModuleName
$unique_all_modules.count
515

We have a similar situation with Linux (no XWin running here), although notice the process to module count ratio (86:1583) is a little lower than my windows box(64:2701) [As if the two could be realistically compared ;-)]:
ps awx | wc -l
86
/usr/sbin/lsof | wc -l
1583
...

Now look at my OpenBSD box (no Xwin running here either):

# ps -la | wc -l
20
# fstat | wc -l
183
....

Part of "proactive security" employed by creators of OpenBSD are the careful decisions:

(1) to run as few default services as possible
(2) not to support every application on the planet

There's not too much more to say on this type of logic: "The smaller your garden, the more carefully you can attend to each plant." Albeit, one does have to grow enough to feed your family!

Friday, June 5, 2009

PolyMorphic Multifunctional Spyware/Malware/Distribution Ware...

I have been writing scripts like those (far) below to parse my Firewall's syslogd output and wondering if there is some other, better way to understand the significance of my logs. Ultimately, I would like a little more information like: What causes the Firewall to behave as it does? Perhaps I am requesting a Firewall application log. For example, unidirectional SIPs are obviously blocked, but how does it know to continue bi-directional conversations across the WAN initiated from the LAN?  Sometimes I see an immediate block, other times I see a one packet delay.  Watching my firewall work drives home the point that the classic "firewall as perimeter defense" relinquishes control over what data escapes my network, especially if I do not employ host firewalls with bidirectional blocking capacity. 

And maybe even not then. The persistence of the current breed of spyware/malware/distribution ware (e.g. Conficker) is such that it can initiate web conversations on hidden, broken or validated channels (e.g register new domains) and then plunder host information from 'command and control' nodes once an internal node has established a validated external connection. Later the spyware/malware/distribution ware engages in 'polymorphic mutation' and updates itself to protect against updates in security products designed to detect it. The most notorious of such spyware/malware/distribution ware to date would be Conficker C. This is from http://mtc.sri.com/Conficker/addendumC/index.html:

"We present an analysis of Conficker Variant C, which emerged on the Internet at roughly 6 p.m. (PST) on 4 March 2009.  This variant incorporates significant new functionality, including a new domain generation algorithm and a new peer-to-peer file sharing service.   Absent from our discussion has been any reference to the well-known attack propagation vectors (RCP buffer overflow, USB, and NetBios Scans) that have allowed C's predecessors to saturate so much of the Internet.  Although not present in C, these attack propagation services are but one peer upload away from any C infected host, and may appear at any time. C is, in fact, a robust and secure distribution utility for distributing malicious content and binaries to millions of computers across the Internet.   This utility incorporates a potent arsenal of methods to defend itself from security products, updates, and diagnosis tools.  It further demonstrates the rapid development pace at which Conficker's authors are maintaining their current foothold on a large number of Internet-connected hosts.  Further, if organized into a coordinated offensive weapon, this multimillion-node botnet poses a serious and dire threat to the Internet."

I really don't think anyone has a clue of what to do about polymorphic, multifunctional spyware/malware/distribution-ware like this in terms of either prevention, detection, and perhaps removal. In fact, Conficker and other malware present a unique set of conundrums: Not just how do we detect this type of malware or how do we secure what we have already lost but how do we keep a multimillion node botnet from destroying the rest of the internet?  While the spyware/malware/distribution ware designers have propagated their creation throughout the universe, the rest of us are twiddling our fingers writing ditzy shell scripts in hopes they will tell us something about our Firewall's behaviour:

# more NotBlockedUniqLocation.sh                                                                                   
grep Dest message* | awk -F":" '{print $2$3$4 ":" "DIP:"$7":"}' | grep -v -f not_search.txt | grep -v [localhost] | awk -F":" '{print $3}' > NotBlocked.txt
for i in `cat NotBlocked.txt | sort -nr | uniq`; do echo $i `geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $i | awk -F" " '{print $6 $7 $8 $9 }'`;done

# more BlockedUniqLocation.sh     
grep Blocked message* | awk -F":" '{print $2$3$4 ":" $6":"}' | grep -v -f not_search.txt | awk -F":" '{print $2}' > Blocked.txt
for i in `cat Blocked.txt | sort -nr | uniq`; do echo $i `geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $i | awk -F" " '{print $6 $7 $8 $9}'`;done


# ./NotBlockedUniqLocation.sh 
222.172.105.109 CN,07,Zhongshan,(null),
217.109.17.57 FR,A8,Paris,(null),
216.73.87.115 US,NY,NewYork,
216.34.207.74 US,CA,WestlakeVillage,
216.34.181.91 US,CA,MountainView,
216.34.181.71 US,CA,MountainView,
216.34.181.60 US,CA,MountainView,
216.34.181.59 US,CA,MountainView,
216.34.181.40 US,CA,MountainView,
216.168.46.76 US,WA,Seattle,98168,
216.168.46.72 US,WA,Seattle,98168,
212.58.226.143 GB,P9,Maidenhead,(null),
212.58.226.142 GB,P9,Maidenhead,(null),
212.58.226.139 GB,P9,Maidenhead,(null),
209.66.102.82 US,CA,Berkeley,94709,
209.66.102.50 US,CA,Berkeley,94709,
...

# ./BlockedUniqLocation.sh                                                                                         
222.172.105.109 CN,07,Zhongshan,(null),
217.109.17.57 FR,A8,Paris,(null),
216.34.181.71 US,CA,MountainView,
216.34.181.60 US,CA,MountainView,
216.168.46.76 US,WA,Seattle,98168,
209.66.102.82 US,CA,Berkeley,94709,
209.66.102.50 US,CA,Berkeley,94709,
206.51.224.187 US,FL,Tampa,33602,
204.121.6.51 US,NM,LosAlamos,
203.146.189.74 TH,40,Bangkok,(null),
202.99.11.99 CN,22,Beijing,(null),
202.12.29.13 AU,04,Brisbane,(null),
199.93.55.126 US,(null),(null),(null),
199.43.0.144 US,(null),(null),(null),
199.212.0.43 CA,ON,Toronto,(null),
195.97.20.4 GR,35,Athens,(null),
192.149.252.44 US,(null),(null),(null),
168.75.68.60 US,MA,Andover,01810,
...


Thursday, June 4, 2009

Viisualizing SIPs over time,port,IP range

Being able to quickly visualize Source IP Addresses over time and port and IP range is significant. The following utilities help:
  • mergecap
  • ipsumdump
  • pcregrep
  • gnuplot
Mergecap is part of the Wireshark distribution.  It merges pcap files quickly and with little fanfare. Ipsumdump is a brilliant piece of software by UCLA prof Eddie Kohler. It is based on his "Click" router development which provides functional replacement for pcap code. Gnuplot is indispensable as part of the *Nix toolkit.What I want to do here is:

(1) merge two weeks of tcpdump captures into one pcap file
(2) filter out some common ports (e.g. noise)
(3) meaningfully analyze SIP behavior

The examples below are simple and straightforward. I expect to explore this software more.
[Here I filter out some common 'noisy' internal traffic:]

more no_search.txt
 514
 520
 137
 138
 67

[Now I merge a couple weeks of pcap files and then columnize them with ipsumdump:]

mergecap -w May22-Jun4.cap May*2009 Jun012009
ipsumdump -r --no-headers -qtsSdDpO May22-Jun4.cap | pcregrep -v -f no_search.txt | sort -n -k 2  | more
....
1243564232.633833 110.8.212.14 3232 192.168.0.12 12712 U -
1243819790.146836 113.12.190.38 41300 192.168.0.12 1434 U -
1243962105.530513 113.12.190.38 40074 192.168.0.12 1434 U -
1243948162.113607 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok
1243948162.891020 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok
1243948163.661370 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok
1242915720.575869 114.45.61.61 4121 192.168.0.12 25 T mss1440;sackok
1242915727.208449 114.45.61.61 4121 192.168.0.12 25 T mss1440;sackok
1243948165.160091 115.150.202.176 1358 192.168.0.12 12712 U -
1243580800.176250 115.30.142.186 46453 192.168.0.12 1434 U -
.....

[Now I re-ordered one SIP I want to explore more closely:]

grep 121.15.245.215 out.dat 121.15.245.215.dat
sort -nr 121.15.245.215.dat > 121.15.245.215.graph.dat

1243935815.497855 121.15.245.215 12200 192.168.0.12 8000 T .
1243896403.852720 121.15.245.215 12200 192.168.0.12 3128 T .
1243786852.873342 121.15.245.215 12200 192.168.0.12 8000 T .
1243786749.219621 121.15.245.215 12200 192.168.0.12 3128 T .
1243751923.943017 121.15.245.215 12200 192.168.0.12 8000 T .
1243751811.136522 121.15.245.215 12200 192.168.0.12 3128 T .
1243702801.387269 121.15.245.215 12200 192.168.0.12 8000 T .
1243702687.231474 121.15.245.215 12200 192.168.0.12 3128 T .
1243678638.723457 121.15.245.215 12200 192.168.0.12 7212 T .
....

[Then I plot that SIP's activity over time:]

gnuplot> set terminal dumb
Terminal type set to 'dumb'
Options are 'feed  79 24'
gnuplot> plot "121.15.245.215.graph.dat" using 1 with lines


     1.244e+09 ++-------+-------+--------+--------+--------+-------+-------++
               **       +       + "121.15.245.215.graph.dat" using 1 ****** +
               | *                                                          |
    1.2438e+09 ++ *                                                        ++
               |  *******                                                   |
               |         *******                                            |
               |                *********                                   |
    1.2436e+09 ++                        ****                              ++
               |                             *******                        |
               |                                    *                       |
    1.2434e+09 ++                                   *                      ++
               |                                    *                       |
               |                                    *                       |
    1.2432e+09 ++                                    *                     ++
               |                                     *                      |
               |                                     *                      |
               |                                     **                     |
     1.243e+09 ++                                      *******             ++
               |                                              **            |
               +        +       +        +        +        +    **********  +
    1.2428e+09 ++-------+-------+--------+--------+--------+-------+-------++
               0        5       10       15       20       25      30       35


[Here, the SIPs behaviour makes me more interested in plotting per port...]

grep 218.103.62.150 out.dat > 218.103.62.150.dat
more 218.103.62.150.dat 

1242901282.013137 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok
1242901282.670295 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok
1242901283.342359 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok
1242901284.902925 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok
1242901285.542566 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok
1242901286.151354 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok
1242901287.088508 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok
1242901287.664895 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok
1242901288.291307 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok
...

gnuplot
gnuplot> set terminal dumb
gnuplot> plot "218.103.62.150.dat" using 5:1 with points

    1.2429e+09 ++------+------+-------+-------+------+-------+------+------++
               +       +      +       "218.103.62.150.dat" using 5:1+  A    +
               A                                                            |
    1.2429e+09 ++                                                          ++
               |                                                            |
               |                                                            |
               |                                                            |
    1.2429e+09 ++                                                          ++
               |                                                  A         |
               |                                                  A         |
    1.2429e+09 ++                          AA                              ++
               A          A                 A                               |
               | A                       AA                               A |
    1.2429e+09 ++A                                                        A++
               |       A A        A        A                                |
               |                                                            |
               |    A                                                       |
    1.2429e+09 A+                                                          ++
               |                                                            |
               +       +      +       +  AA  A+      +       +      +       +
    1.2429e+09 ++------+------+-------+------A+------+-------+------+------++
               0      5000  10000   15000   20000  25000   30000  35000   40000


Wednesday, June 3, 2009

National Cyber Security Review II

So I read as below from the 100 documents submitted for the National 60 day Cyber Security Review:

cat pdf.all.txt | wc
11596  327837 2232007

It took me two days - with copious breaks and diversions. The number of federal agencies that responded to, have something to do with, have developed cyber security standards, or assure compliance of those standards is mind-numbing. I hardly know where to start to discuss all the players and their efforts. And actually, I don't think the federal government does either. It was not untypical to read a line like this:

"There are currently several cyber collaboration centers that interact across the Federal Government space to help disseminate information on security threats, including the U.S. Computer Emergency Readiness Team (US-CERT), National Cybersecurity Center, Joint Task Force- Global Network Operations, the National Cyber Investigative Joint Task Force, the Intelligence Community Incident Response Center, the National Security Agency Threat Operations Center, and the Defense Cyber Crime Center. The exact interactions and roles of each, however, remain unclear."

I sensed confusion (even desperation), an overlap of responsibility, a lack of cohesion in development of cyber strategies and turf wars. In short, with exceptions, the only items not missing are $$$ and ideas. A lot of roadmaps  were proposed and a limited amount of security architecture was described with some interesting exceptions. I suspect that the outcome of this review will serve President Barack Obama's purposes exactly. We have the talent and the resources to become a cyber secure nation. Turf wars, in-fighting, lack of cohesive strategies and lack of prioritization of threat vectors has fragmented the national approach to cyber security.  The 60 day review puts all levels of bureacrats on watch.  What could shake out  of this is the predominance of the most brilliant and most resillient of the national cyber warrior agencies for a cohesive national cyber security strategy.  How this will happen,I do not know. But I would put a bet on NIST, NSA, DOD and CERT re-organization and leadership in this area based on what I read. There may need to be increased standards and federal scrutiny of private critical infrastructures.Occasionally, the documents contained something technically pragmatic and brilliant such as this comment:

Jeff Brown, CISO, Raytheon Company:    

"In today's cyber security environment there is one inescapable truth.  There is no way to  prevent a determined intruder from getting into a network so long as one allows email and  web surfing ­and no business today can long survive without these two bedrocks of the  information age.    The reasons for this are simple.  The vast majority of our Information Assurance  architectures rely on patching and configuration control for protection, the consistent  application of which has thus far proven elusive over large enterprises.  It also relies on  signatures for both protection and detection which, by definition, will not stop the first wave of  the increasing volume of zero day attacks we are seeing today.  Therefore, when you must let  the attack vector (an email or a web address) past your perimeter to the desktop, you are  virtually guaranteed to have successful penetrations. Raytheon believes the best way to address this new reality is to recognize that attackers  will get into your network and expand our defensive actions to detect, disrupt, and deny  attacker's command and control (C2) communications back out to the network.  It is an  acknowledgement of the fact that there are fewer, or perhaps relatively noisier, ways to get out  of a network than to get into it.  Such a strategy focuses on identifying the web sites and IP  addresses that attackers use to communicate with malicious code already infiltrated onto our  computers.  While some of these sites are legitimate sites which have been compromised, the  majority are usually new domains registered by attackers solely for the purposes of command  and control.  There is little danger of unintended consequences from blocking these web sites  and their associated IP addresses for outbound traffic.  Where they are legitimate sites, the  benefit of protecting the enterprise far outweighs any inconvenience there might be if an  employee needs to legitimately go to that site.  Raytheon has had success with this strategy,  but it requires a significant investment, unaffordable to most small and medium size entities  and many larger ones.  One of the corollaries of recognizing that networks can always be penetrated is a shift in  how we measure ourselves.  Measuring ourselves against how many intrusions occur becomes  a far less interesting.  What counts, instead is the intruder's dwell time in our network, or how  long an intruder has had access.  It's more important to recognize how successful the  penetrations were versus how many penetrations occurred."

So Raytheon is practically solving security with a novel approach - one that doesn't sacrifice utility for security. Based on a recent and comprehensive report from Verizon's business unit, Raytheon may be singular in its success. When we switched phone services to Verizon, I had no I idea I would be joining a phone network that boasts an incredibly talented cyber research division.  Verizon's 2009 Data Breach Investigations Report http://www.verizonbusiness.com/products/security/risk/databreach/ is a must read.  The book fits with Misha Glenny's (2008,2009) "McMafia: A Journey Through the Global Criminal Underworld".  Verizon found that "91% of all compromised records were attributed to organized criminal groups". 

Below are some significant quotes from this report (http://www.verizonbusiness.com/products/security/risk/databreach/):
[/STARTQUOTING]
"2008 will likely be remembered as a tumultuous year for corporations and consumers alike. Fear, uncertainty, and doubt seized global financial markets; corporate giants toppled with alarming regularity; and many who previously lived in abundance found providing for just the essentials to be difficult. Among the headlines of economic woes came reports of some of the largest data breaches in history. These events served as a reminder that, in addition to our markets, the safety and security of our information could not be assumed either.

The 2009 Data Breach Investigations Report (DBIR) covers this chaotic period in history from the viewpoint of our forensic investigators. The 90 confirmed breaches within our 2008 caseload encompass an astounding 285 million compromised records. These records have a compelling story to tell, and the pages of this report are dedicated to relaying it. As with last year, our goal is that the data and analysis presented in this report prove helpful to the planning and security efforts of our readers. Below are a few highlights from the report:
....
Some attackers simply repacked existing malware so as to make its signature undetectable by antivirus software (AV) scanners. Others leveraged existing malicious code, but modified it for additional functionality or tailored it to the victim’s environment. Most common in 2008, however, was malware that had (apparently) been created for the attack(s) entirely from scratch. In a rather sobering statistic, 85 percent of the 285 million records breached in the year were harvested by custom-created malware. It is possible that the code preexisted yet went unrecognized by the experts and tools at ICSA Labs, but this matters little to the overall point. More to the point is that, besides being more capable and better adapted, most malware used for the purpose of compromising data is not detectable by modern AV. Unfortunately, many organizations rely on AV as the primary means of malware prevention and detection. AV is certainly a foundational control, but the continuing evolution of malware leaves security programs built solely upon AV for combating malware unstable at best.
....
On the whole, organizations discovered breaches slightly quicker in 2008. However, lest we confuse “quicker” with “quickly,” this statement needs some additional context.Breaches still go undiscovered and uncontained for weeks or months in 75 percent of cases. It is doubtful that any chief security officer anywhere would call this “quick”. "
[/ENDQUOTING]

The report makes clear the general picture of what "cyberwarfare" is today: Organized crime systematically plundering finanicial records for profit without being noticed. A number of current articles confirm this:

http://www.wired.com/threatlevel/2009/04/pins/
http://www.washingtonpost.com/wp-dyn/content/article/2009/04/15/AR2009041501196.html?sid=ST2009041501334

Interesting commentary on Verizons findings can be found at their blog: http://securityblog.verizonbusiness.com/.  

I think I will spend tommorrow and the next day writing code....my capacity for integrating the amount of disparate federal offices concerned with cyber security has reached its limit.