SecurityCertified

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Sunday, June 28, 2009

Simpler IP Range Matching with Tshark Display Filters

Posted on 1:23 PM by Unknown
In today's SANS ISC journal, the story IP Address Range Search with libpcap wonders how to accomplish the following:

...how to find SYN packets directed to natted addresses where an attempt was made to connect or scan a service natted to an internal resource. I used this filter for addresses located in the range 192.168.25.6 to 192.168.25.35.

The proposed answer is this:

tcpdump -nr file '((ip[16:2] = 0xc0a8 and ip[18] = 0x19 and ip[19] > 0x06)\
and (ip[16:2] = 0xc0a8 and ip[18] = 0x19 and ip[19] < 0x23) and tcp[13] = 0x02)'

I am sure it's clear to everyone what that means!

Given my low success rate in getting comments posted to the SANS ISC blog, I figured I would reply here.

Last fall I wrote Using Wireshark and Tshark display filters for troubleshooting. Wireshark display filters make writing such complex Berkeley Packet Filter syntax a thing of the past.

Using Wireshark display filters, a mere mortal could write the following:

tshark -nr file 'tcp.flags.syn and (ip.dst > 192.168.25.6 and ip.dst < 192.168.25.35)'

Note that if you want to be inclusive, change the > to >= and the < to <= .

To show that my filter works, I ran the filter against a file with traffic on my own 192.168.2.0/24 network, so I altered the last two octets to match my own traffic.

$ tshark -nr test.pcap 'tcp.flags.syn and (ip.dst > 192.168.2.103 and ip.dst < 192.168.2.106)'

137 2009-06-28 16:21:44.195504 74.125.115.100 -> 192.168.2.104 HTTP Continuation or non-HTTP traffic

You have plenty of other options, such as ip.src and ip.addr.

Which one do you think is faster to write and easier to understand?


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in | No comments

Effective Digital Security Preserves Long-Term Competitiveness

Posted on 11:14 AM by Unknown
Yesterday I mentioned a speech by my CEO, Jeff Immelt. Charlie Rose also interviewed Mr Immelt last week. In both scenarios Mr Immelt talked about preserving long-term competitiveness. Two of his themes were funding research and development and ensuring the native capability to perform technical tasks.

It occurred to me that digital security is reflected in both themes. In Crisis 0: Game Over I asked I'm sure some savvy reader knows of some corporate espionage case that ended badly for the victim, i.e., bankruptcy or the like? I got a few interesting cases, but I believe the net result is that it is difficult to find examples where an intrusion or breach was so devastating that it ended up destroying the victim organization.

This makes sense once you reflect on it. Why would a mature, thoughtful intruder seek to destroy his victim, if the purpose of his mission is to conduct espionage on behalf of a competitor or intelligence service? Destroying the victim renders it useless as a source for stealing intellectual property gained by the victim's research and development. In the foreign intelligence case, almost all operators prefer to keep a source active, even in wartime when you might think that destruction is the ultimate goal.

Taking this line of reasoning to its natural conclusion, we can see that digital security can be considered a means to preserve long-term competitiveness, particularly for organizations that seek to drive internal growth via investing in research and development. Such an organization is a natural target for competitors who find it immensely cheaper to steal intellectual property, rather than fund their own.

The problem is showing those who make budgetary and management decisions that digital security has a real role in loss prevention. I've written a lot about intellectual property and digital security, but it is exceptionally difficult to tie individual intrusions to real impact. How does pervasive theft of intellectual property (IP) manifest itself? In commercial cases, perhaps it would appear as a loss of sales to rivals who make similar or duplicate products based on stolen IP. Would the victim organization even know these lost or declining sales were the result of IP theft?

Even if the victim identified the stolen IP, could it be traced back to one or more intrusions, or would it be considered the consequences of product reverse engineering by competitors? The bottom line could be that the victim is still in business, but the double-digit growth and expanding market share it craves are reduced to single-digit growth and eroding market share.

It's a waste of time to use terms like "ROI" or "ROSI" when talking to managers or business people. It is usually impossible to fully explain, from loss to impact, the IP theft cases like the one I described in Intellectual Property: Develop or Steal, i.e., spend $10 million over 10 years on a product, then watch the Chinese duplicate it for $1.4 million in 6 months after stealing the IP. More often than not, the victim of IP theft simple whithers, wondering why its competitive advantage is not what it expected it to be. It's time to get managers and business people to think in terms of long-term competitiveness.

Clearly Mr Immelt has determined that it is not in his company's best interest, nor in the interests of the country, for the US to be underfunding R&D or outsourcing everything overseas. We security professionals need to adopt this line of reasoning to emphasize how effective digital security preserves long-term competitiveness.

By the way, you might be wondering if I can prove there is an impact to IP theft. I look at the question this way. If there were no impact to IP theft, why would economic and national competitors fund teams to steal IP? You might argue that IP thieves can duplicate and sell products at prices lower than the IP owner could afford, thereby serving a new market. If that were true, why would IP owners file patents? Clearly there is value in IP, so stealing it lessens the value available to the IP owner.

I use a variant of this argument when I encounter asset owners who claim there is no impact associated with an intrusion. My reply is usually this: If there is no impact, then why operate the asset? Retire it.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in | No comments

Saturday, June 27, 2009

Posts to Read Elsewhere

Posted on 6:58 PM by Unknown
I'm not a big fan of just publishing links to other people's stories, but there's a few that I really like this week. Please consider checking these out:

  • Nate Richmond wrote Building an IR Team: People and Building an IR Team: Organization. These posts are gold for anyone trying to build an IR team on their own, or trying to benchmark against an expert's recommendation. Keep writing Nate!

  • Alec Waters caught my attention with his post Prevention Eventually Fails, part one. Anyone who read my first book recognizes my catchphrase "Prevention eventually fails." Alec's posts look interesting!

  • My CEO delivered a great speech this week, viewable at American Renewal: Immelt addresses Detroit Econ Club and readable at Text of Immelt's Speech. This caught my eye:

    In some areas, we have outsourced too much. We plan to "insource" capabilities like aviation component manufacturing and software development. These are the things we will be working on in Michigan. This will make us faster and more competitive over the long term.

    I totally agree -- internal security staff matters.




Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in | No comments

Black Hat Budgeting

Posted on 6:08 PM by Unknown
Earlier this month I wondered How much to spend on digital security. I'd like to put that question in a different light by imagining what a black hat could do with a $1 million budget.

The ideas in this post are rough approximations. They certainly aren't a black hat business plan. I don't recommend anyone follow through on this, although I am sure there are shops our there who do this work already.

Let's start by defining the mission of this organization, called Project Intrusion (PI). PI is in "business" to steal intellectual property from organizations and sell it to the highest bidders. In the course of accomplishing that mission, PI may develop tools and techniques that it could sell down the food chain, once PI determines their utility to PI has sufficiently decreased.

With $1 million in funding, let's allocate some resources.

  • Staff. Without people, this business goes nowhere. We allocate $750,000 of our budget to salaries and benefits to hire the following people.


    • The team leader should have experience as a vulnerability researcher, exploit developer, penetration tester, enterprise defender, and preferably an intelligence operative. The leader can be very skilled in at least one speciality (say Web apps or Windows services) but should be familiar with all of the team's roles. The team leader needs a vision for the team while delivering value to clients. $120,000.

    • The team needs at least one attack tool and technique developer for each target platform or technology that PI intends to exploit. PI hires three. One focuses on Windows OS and client apps, one on Web apps, and one on Unix and network infrastructure. $330,000.

    • The team hires two penetration operators who execute the team leader's mission directives by using the attack tools and techniques supplied by the developers. The operators penetrate the target and establish the persistence required to acquire the desired intellectual property. $180,000.

    • The team hires one intelligence operative to direct the penetration operators attention toward information of value, and then assess the value of exfiltrated data. The intel operative interfaces with clients to make deals. $120,000.


  • Technology. The team will need the following, for a total of $200,000.


    • Lab computers running the software likely to be attacked during operations.

    • Operations computers from which the penetration operators run attacks.

    • Network connectivity and hosting for the lab computers and operations computers, dispersed around the world.

    • Software required by the team, since many good attack tools are commercial. MSDN licenses are needed too. There's no need to steal these; we have the budget!


  • Miscellaneous. The last $50,000 could be spent on incidentals, bribes, team awards, travel, or whatever else the group might require in start-up mode.


If the attack developers manage to make enough extra money by selling original exploits, I would direct the funds to additional penetration operators. It would take about six of them to support a sustainable 24x7 operation. With only two they would need to be careful and operate within certain time windows.

So what is the point of this exercise? I submit that for $1 million per year an adversary could fund a Western-salaried black hat team that could penetrate and persist in roughly any target it chose to attack. This team has the structure and expertise to develop its own attack methods, execute them, and sell the results of its efforts to the highest bidders.

This should be a fairly scary concept to my readers. Why? Think about what $1 million buys in your security organization. If your company is small, $1 million could go a long way. However, when you factor in all of the defensive technology you buy, and the salaries of your staff, and the scope of your responsibilities, and so on, quickly you realize you are probably out-gunned by Project Intrusion. PI has the in-house expertise to develop its own exploits, keep intruders on station, and assess and sell the information it steals.

Worse, PI can reap economies of scale by attacking multiple targets for that same $1 million. Why? Everyone runs Windows. Everyone uses the same client software. Everyone's enterprise tends to have the same misconfigurations, missing patches, overworked staff, and other problems. The tools and techniques that penetrate company A are likely to work against company B.

This is why I've always considered it folly to praise the Air Force for standardizing its Windows deployment with supposedly secure configurations. If PI looks at its targets and sees Windows, Windows, some other OS that might be Linux or BSD or who knows what, Windows, Windows, who do you think PI will avoid?

It's all about cost, on the part of the attacker or defender. Unfortunately for defenders, it's only intruders who can achieve "return on investment" when it comes to exploiting digital security.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in | No comments

Being a Critic Is Easy, So What Would I Do?

Posted on 5:10 PM by Unknown
After my last post, some of you are probably thinking that it's easy to be a critic, but what would I suggest instead? The answer is simple to name but difficult to implement.

  1. Operate a defensible network architecture. Hardly anyone does. I don't need to explain all of the reasons why here; they could occupy a series of posts, or maybe even a book.

  2. Once the DNA is operating, detect and respond to failures. The nice aspect of operating a DNA is that the number of failures should be lower but of higher complexity. Unfortunately at the moment almost all of the world's detection and response teams have to deal with the entire spectrum of security incidents. These range from the most mundane to the most complex. Too often the mundane hide the complex, or at the very least divert resources and attention.

  3. Use the knowledge learned from failures (either caused by adversaries or adversary simulation) to guide the next version of the DNA. Since most enterprises are not operating a DNA, they never get to work on the next version anyway.


I know other people think this way too. Harlan Carvey is one. He is also an incident responder and he finds so many clients that are not doing the basics anywhere remotely right.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in | No comments

Ugly Security

Posted on 2:21 PM by Unknown
I read Anton Chuvakin's post MUST READ: Best Chapter From “Beautiful Security” Downloadable! with some interest. He linked to a post by Mark Curphey pointing out that Mark's chapter from O'Reilly's new book Beautiful Security was available free for download in .pdf format. O'Reilly had been kind enough to send me a copy of the book, so I decided to read Mark's chapter today.

I found the following excerpts interesting.

Builders Versus Breakers

Security people fall into two main categories:

  • Builders usually represent the glass as half full. While recognizing the seriousness of vulnerabilities and dangers in current practice, they are generally optimistic people who believe that by advancing the state they can change the world for the better.

  • Breakers usually represent the glass as half empty, and are often so pessimistic that you wonder, when listening to some of them, why the Internet hasn’t totally collapsed already and why any of us have money left unpilfered in our bank accounts. Their pessimism leads them to apply the current state of the art to exposing weaknesses and failures in current approaches.


I remembered I had seen something like this before and wrote On Breakership in response. However, back then the debate seemed to center around calling people who helped create and defend systems as "builders, while labeling people who exploited or at least tested systems as "breakers." Mark seems to have dismissed people who "break" systems in order to improve security, while praising builders as people who stay "optimistic." I don't think this is fair. My post Response to Is Vulnerability Research Ethical? explains my position, which is essentially that Offense and Defense Inform Each Other.

Next, in a section titled Clouds and Web Services to the Rescue, Mark describes how centralized data storage for his 6 home PCs at Amazon S3 is great for security. Unfortunately, all he is really showing is that there is value in offsite storage. Storing data at Amazon S3 doesn't help much when those 6 systems are part of Calin's botnet in Romania. This is an example of focusing on one aspect of security (availability) while ignoring the other parts (confidentiality and integrity). Don't get me wrong -- I think cloud storage is great and I use a variety of services myself. However, it only helps with one aspect of the security landscape, and if not properly utilized introduces other vulnerabilities and exposures not found in other models.

Next Mark talks about using cloud services for data analysis.

Event logs can provide an incredible amount of forensic information, allowing us to reconstruct an event. The question may be as simple as which user reset a specific account password or as complex as which system process read a user’s token. Today there are, of course, log analysis tools and even a whole category of security tools called Security Event Managers (SEMs), but these don’t even begin to approach the capabilities of supercrunching. Current tools run on standard servers with pretty much standard hardware performing relatively crude analysis...

[T]he power and storage that is now available to us all if we embrace the new connected computing model will let us store vast amounts of security monitoring data for analysis and use the vast amounts of processing power to perform complex analysis. We will then be able to look for patterns and derive meaning from large data sets to predict security events rather than react to them. You read that correctly: we will be able to predict from a certain event the probability of a tertiary event taking place. This will allow us to provide context-sensitive security or make informed decisions about measures to head off trouble.


Does Mark mean that the real problem we've had with detecting and responding to security events is a lack of processing power? Good grief. I hear thoughts like this quite often from people who don't actually detect and respond to security incidents. Even academic security researchers in their ivory towers are probably laughing at Mark's angle. "Oh, you're right -- we've just been waiting for a supercomputer to run our algorithms!"

Mark then talks about using Business Process Management (BPM) software to improve security:

When security BPM software (and a global network to support it) emerges, companies will be able to outsource this step not just to a single company, in the hope that it has the necessary skills to provide the appropriate analysis, but to a global network of analysts. The BPM software will be able to route a task to an analyst who has a track record in a specific obscure technology (the best guy in the world at hacking system X or understanding language Y) or a company that can return an analysis within a specific time period. The analysts may be in a shack on a beach in the Maldives or in an office in London; it’s largely irrelevant, unless working hours and time zones are decision criteria...

This same fundamental change to the business process of security research will likely be extended to the intelligence feeds powering security technology, such as anti-virus engines, intrusion detection systems, and code review scanners. BPM software will be able to facilitate new business models, microchunking business processes to deliver the end solution faster, better, or more cheaply. This is potentially a major paradigm shift in many of the security technologies we have come to accept, decoupling the content from the delivery mechanism. In the future, thanks to BPM software security, analysts will be able to select the best anti-virus engine and the best analysis feed to fuel it — but they will probably not come from the same vendor.


Again, this is so detached from reality, I am curious how anyone could think this is possible. Mark works for Microsoft. Would you ever imagine Microsoft pivoting on a dime to "select the best anti-virus engine and the best analysis feed" -- or would they stick to their own product, because it's their own product? What about your company -- have you witnessed the organizational inertia associated with any IT product or system?

How about trust factors? What if "the best guy in the world at hacking system X or understanding language Y" works in a country with a reputation for industrial espionage? What if that guy was just hired by a competitor, or is working for a competitor now? How long does it take outside help to become familiar with the aspects of your business that eventually determine success? There's a reason why companies are not collections of free agents working independently.

Mark's last section talks about social networking for the security industry, talking about how people should share what they know. There are indeed certain collaborative forums where this works, but you are seldom if ever going to find any serious company telling other companies how their security defenses work, how they fail, and what is lost as a result of that failure. Individual collaboration occurs, but there could be severe consequences for a security staff member who unloads specific technical security information to a social network. The most productive associations that currently exist are found in certain private mailing lists, associations of peer companies that sign mutual nondisclosure agreements, and individual exchanges among peers.

Mark is a smart guy but I think his prognosis for the security industry in his Beautiful Security chapter are largely incomplete and unrealistic.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in breakers | No comments

Thursday, June 25, 2009

SANS Forensics and Incident Response 2009

Posted on 4:39 AM by Unknown
The agenda for the second SANS WhatWorks Summit in Forensics and Incident Response has been posted. I am really happy to see I am speaking on Tuesday, because I will not be available Wednesday. Day 1 appears mainly technical, and day 2 is mainly legal. Please consider registering for the two-day conference. It's the best incident response event in the US this year!


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.
Read More
Posted in | No comments
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • Practice of Network Security Monitoring Table of Contents
    Since many of you have asked, I wanted to provide an updated Table of Contents for my upcoming book, The Practice of Network Security Monito...
  • Review of Intelligence, 4th Ed Posted
    Amazon.com just posted my five star review of Intelligence: From Secrets to Policy, 4th Ed by Mark Lowenthall . From the review : I was a...
  • Review of Robust Control System Networks Posted
    Amazon.com just posted my five star review of Robust Control System Networks by Ralph Langner . From the review : I am not an industrial ...
  • Happy 7th Birthday TaoSecurity Blog
    Today, 8 January 2010, is the 7th birthday of TaoSecurity Blog . I wrote my first post on 8 January 2003 while working as an incident resp...
  • Bejtlich's Thoughts on "Why Our Best Officers Are Leaving"
    Twenty-two years ago today I flew to Colorado Springs, CO and reported for Basic Cadet Training with the class of 1994 at the United States ...
  • Mandiant APT1 Report: 25 Best Commentaries of the Last 12 Days
    Two weeks ago today our team at Mandiant was feverishly preparing the release of our APT1 report . In the twelve days that followed public...
  • Bejtlich Teaching at Black Hat West Coast Trainings
    I'm pleased to announce that I will be teaching at  Black Hat West Coast Trainings  9-10 December 2013 in Seattle, Washington. This is a...
  • Bejtlich Teaching at Black Hat DC 2011
    Over the holiday break I've been putting the finishing touches on TCP/IP Weapons School 3.0 , to be presented first at Black Hat DC 2011...
  • Risk Modeling, not "Threat Modeling"
    Thanks to the great new book Metasploit (review pending), I learned of the Penetration Testing Execution Standard . According to the site,...
  • Tort Law on Negligence
    If any lawyers want to contribute to this, please do. In my post Shodan: Another Step Towards Intrusion as a Service , some comments claim ...

Categories

  • afcert
  • Air Force
  • analysis
  • announcement
  • apt
  • attribution
  • bestbook
  • blackhat
  • books
  • breakers
  • bro
  • bruins
  • certification
  • china
  • cisco
  • cissp
  • cloud
  • clowns
  • commodore
  • conferences
  • controls
  • correlation
  • counterintelligence
  • cybercommand
  • cyberwar
  • dfm
  • education
  • engineering
  • feds
  • fisma
  • freebsd
  • GE
  • ge-cirt
  • hakin9
  • history
  • impressions
  • information warfare
  • ipv6
  • law
  • leadership
  • malware
  • mandiant
  • microsoft
  • mssp
  • nsm
  • offense
  • oisf
  • packetstash
  • philosophy
  • pirates
  • powerpoint
  • press
  • psirt
  • reading
  • redteam
  • reviews
  • russia
  • sans
  • sec
  • sguil
  • snorby
  • spying
  • threat model
  • threats
  • Traffic Talk
  • training
  • tufte
  • tv
  • ubuntu
  • usenix
  • verizon
  • vulnerabilities
  • wisdom
  • writing

Blog Archive

  • ▼  2013 (16)
    • ▼  September (1)
      • Bejtlich Teaching at Black Hat West Coast Trainings
    • ►  August (1)
    • ►  June (2)
    • ►  April (2)
    • ►  March (1)
    • ►  February (3)
    • ►  January (6)
  • ►  2012 (60)
    • ►  December (4)
    • ►  November (5)
    • ►  October (3)
    • ►  September (10)
    • ►  August (2)
    • ►  July (6)
    • ►  June (6)
    • ►  May (4)
    • ►  April (2)
    • ►  March (9)
    • ►  February (6)
    • ►  January (3)
  • ►  2011 (108)
    • ►  December (3)
    • ►  November (7)
    • ►  October (11)
    • ►  September (9)
    • ►  August (18)
    • ►  July (10)
    • ►  June (5)
    • ►  May (4)
    • ►  April (13)
    • ►  March (17)
    • ►  February (2)
    • ►  January (9)
  • ►  2010 (193)
    • ►  December (14)
    • ►  November (11)
    • ►  October (6)
    • ►  September (16)
    • ►  August (15)
    • ►  July (26)
    • ►  June (15)
    • ►  May (15)
    • ►  April (15)
    • ►  March (16)
    • ►  February (19)
    • ►  January (25)
  • ►  2009 (123)
    • ►  December (10)
    • ►  November (17)
    • ►  October (21)
    • ►  September (13)
    • ►  August (20)
    • ►  July (21)
    • ►  June (21)
Powered by Blogger.

About Me

Unknown
View my complete profile