Incident Detection Paradigms

This is the second in a series of "mindset" posts where I'd like to outline how I've been thinking of various aspects of incident detection and response. My primary focus for these discussions will be intrusions.

I'd like to discuss incident detection paradigms. These are ways that security people tend to think when they are trying to identify intrusions. I'm going to list the three attitudes I've encountered.

1. Detection is futile. This school of thought says that some intruders are so crafty that it is not possible to detect them. I consider this paradigm short-sighted and defeatist. If you read the intruder's dilemma you'll know that it is generally not possible for intruders to hide themselves perfectly, continuously, perpetually. True, as the intruder's persistence time decreases, and as the amount of data exfiltrated decreases, it becomes more difficult to detect the intruder. However, both conditions are good for the defense. The question for the intruder is how persistent and successful he can be without alerting the defender to his presence.


2. Sufficient knowledge. This school of thought says that it is possible for a defender to know so much about an intruder's actions that one can apply that understanding to automated systems to detect the intruder. This is essentially the opposite of the futility school. Unfortunately, this paradigm is unrealistic too. As I mentioned in Security Event Correlation: Looking Back, Part 3, the natural question to ask if one believes the sufficient knowledge paradigm is this: if you can detect it, why can't you prevent it?
   
   As I explained in Why is the Snort IDS still alive and thriving?, that question supposedly made "IDS dead" at the expense of IPS. Users and vendors who believe the sufficient knowledge school expect security people to be satisfied when they receive an alert that something bad happened, but the analyst is not given sufficient evidence to validate that claim.


3. Indicators plus retrospective security analysis. In good debating style I save the best approach for last. I wish I had a better name but this phrase captures the essence of this paradigm. Here the analyst recognizes that any alert or other input one collects and analyzes is simply an indicator. Indicators may have various levels of confidence associated with them, but the importance of an indicator is that it should signal the start of the analysis process. Validating the indicator to produce a warning that can be escalated to perform incident response is accomplished by analyzing sufficient evidence. This evidence can be network traffic or data about network traffic, system logs, host information, and so on.
   
   As I discussed in Black Hat Briefings Justify Retrospective Security Analysis, once an analyst has learned of new indicators to detect advanced intruders, he can apply them to stored evidence. Retrospective security analyst finds the crafty intruders missed by traditional approaches, but it requires sufficient digital situational awareness to know how to proceed.

I'll discuss different digital situational awareness paradigms in a later post.

---

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Read More

Incident Phases of Compromise

This is the first in a series of "mindset" posts where I'd like to outline how I've been thinking of various aspects of incident detection and response. My primary focus for these discussions will be intrusions.

First I'd like to discuss phases of compromise, again primarily designed for intrusions. They can be extended to other scenarios, but as with other recent posts I'm focusing on advanced persistent threats who operate beyond the norms of regular intruders. I've listed the phases elsewhere but they are relevant here; I've also expanded the last phase. I list the information security incident classification for each where appropriate.

1. Reconnaissance. Identify target assets and vulnerabilities, indirectly or directly. Cat 6.


2. Exploitation. Abuse, subvert, or break a system by attacking vulnerabilities or exposures. If the intruder does not seek to maintain persistence, then this could be the end of the compromise. Cat 2 or 1.


3. Reinforcement. The intruder deploys his persistence and stealth techniques to the target. Still Cat 2 or 1, leading to Breach 3.


4. Consolidation. The intruder ensures continued access to the target by establishing remote command-and-control. Breach 3.


5. Pillage. The intruder executes his mission. Here we assume data theft and persistence are the goals.




• Propagation. Intruders usually expand their influence before stealing data, but this is not strictly necessary. At this point the incident classifications should be applied to the new victims.


• Exfiltration. The intruder steals data. Depending on the type of data, Breach 2 or 1.


• Maintenance. The intruder ensures continued access to the victim until deciding to execute another mission.

With these phases of compromise outlined I'll have them ready for later reference.

---

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Read More

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,

...

Read More

Information Security Incident Classification

Thank you to those who commented on my previous post on this subject. I've had a few people ask to use this chart, but I wanted to clarify a few items now that there has been some good public and private discussion about it.

My intention with this chart is to help classify an incident involving compromise of an individual system. There are plenty of other sorts of information security incidents, but at the moment this is the biggest problem I deal with on a daily basis. I need a way to talk about the state of an individual compromised asset. I found the traditional DoD Category system wasn't sufficient, especially in the post-Cat 1 world. I still like those Categories but I needed to go further (post-exploitation) and for one of my constituents, backwards (to when a system is just vulnerable, but no one is yet interested in it -- as far as we can tell).

I decided to call this updated chart a "classification" rather than a "rating," and to remove the label "impact." The words rating and impact imply "risk" and asset value to some degree, and I'm not talking about either here. This is a little bit like assigning a CVE number; it says nothing about the seriousness of the vulnerability, but at least we can all reference the same vulnerability. With my chart I can now build service expectation timelines around the incident type. I can also quickly understand where we are with any incident when one of our team says "we have a Cat 1, but our perimeter defenses appear to have contained the incident so it has not reached Breach 3 status."

I think it is important to keep in mind that having anything remotely approaching a valid understanding of "risk" requires a great deal of understanding about the assets in question. Not only must you understand the nature of the compromised asset (its function, normal usage patterns, its inputs, its processes, its outputs), but you must understand the means by which the asset interacts with the network, any trust relationships, and many other factors. In most cases the only way to gain a real appreciation of these real-world conditions is to either 1) observe the intruder in action, seeing what he can do or get, or 2) red-team the system yourself to see what you can do or get. Modern systems and enterprises are far too complex for anyone to sit back like Mycroft Holmes and truly understand the "risk" of a compromise.

I should also say that I would never expect to tell a manager that we have discovered a Breach 2 and then walk away. The natural next question involves the issues of the previous paragraph, and answering them takes far longer than the process of detecting and validating the incident. If you doubt me, try talking to the office in the DoD that does nothing but computer incident damage assessment all day long.

Incidentally, please feel free to use this diagram, providing you cite the source. I am encouraged when others seek to adopt this sort of language for their own programs, because it moves us closer to having common ways to discuss operational problems. Thank you.

---

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Read More

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

Read More

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.

Read More

Cyber Security Coordinator

The article Obama's likely pick for cybersecurity head remains murky by Doug Beizer and Alice Lipowicz in FCW caught me off guard:

There is surprisingly little buzz circulating about who President Barack Obama might choose to lead cybersecurity policy. Although a number of analysts have ideas about the qualities the person filling the position might need, no one is naming names of likely contenders yet — partly because it remains unclear what the eventual appointee will actually do...

Rohyt Belani, co-founder and managing partner of computer security firm Intrepidus Group, said the ideal candidate would combine qualities from three people: security consultant Bruce Schneier; Richard Bejtlich, director of incident response at General Electric; and Chris Eagle, a senior lecturer and associate chairman of the Computer Science Department at the Naval Postgraduate School.

Belani said Schneier has “an ability to focus on what matters and call out silly bureaucratic processes that do little to help security.” Bejtlich’s strength is a passion for digital security, and Eagle knows where the needs are for offensive capabilities, Belani added.

I have not received any phone calls, but if need be I am sure the right people can find me. :)

---

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Read More