What I'm Reading

What the hell's goin' on here?
something's surely a mess,
our BGP is announcing
the wrong damned AS

See, I announce with this prefix,
it's a slash 24,
here to there should take 3 hops,
not 18 or more

I'm pinging the next hop and
that works just fine,
ping a host, subnet over,
slows like a POTS line

That Defcon session,
when we IM'd all night,
that shit's all encrypted
you told me that, right?

My telnet shell's cleartext!
DONE! Stabbed it with a FIN fork
So why do these Pcap's
show SYN's to New York!?

Somethin' sure does look fishy,
TTLs all askew
are the ISPs tapping traffic
'tween me and you?

I'm just paranoid, man,
I'm sure it's all fine.
These ping-pong effects?
BGP's grand design

I mean really, why worry?
Even though, I confess,
it's not like we're vulnerable
like with DNS

BGP must be foolproof
auth'd and encrypted
there's no way they've gamed it,
redirected or sniffed it

It would be quite stupid
if AS routes, you could twiddle,
intercept all my traffic
with a man-in-the-middle

Nah, I'll sit here, use torrents,
my bits are secure,
close my eyes and imagine
that the Internet's pure

What's next though, I wonder,
what protocol hack
will cause Internet chaos
and make the tubes crack?

Introduction

The Domain Name System (DNS) is vital to the Internet, providing a mechanism for resolving host names into Internet Protocol (IP) addresses. Insecure underlying protocols and lack of authentication and integrity checking of the information within the DNS threaten the proper functionality of the DNS.

The DNS plays a critical role in supporting the Internet infrastructure by providing a distributed and fairly robust mechanism that resolves Internet host names into IP addresses and IP addresses back into host names. The DNS also supports other Internet directory-like lookup capabilities to retrieve information pertaining to DNS Name Servers, Canonical Names, Mail Exchangers, etc. Unfortunately many security weaknesses surround IP and the protocols carried by IP. The DNS is not immune to these security weaknesses. The accuracy of the information contained within the DNS is vital to many aspects of IP based communications.

DNS Functions

The DNS not only supports host name to network address resolution, known as forward resolution, but it also supports network address to host name resolution, known as inverse resolution. Due to its ability to map human memorable system names into computer network numerical addresses, its distributed nature, and its robustness, the DNS has evolved into a critical component of the Internet. Without it, the only way to reach other computers on the Internet is to use the numerical network address. Using IP addresses to connect to remote computer systems is not a very user-friendly representation of a system’s location on the Internet and thus the DNS is heavily relied upon to retrieve an IP address by just referencing a computer system's Fully Qualified Domain Name (FQDN). A FQDN is basically a DNS host name and it represents where to resolve this host name within the DNS hierarchy.

 

Threats to DNS Servers

The original DNS specifications did not include security based on the fact that the information that it contains, namely host names and IP addresses, is used as a means of communicating data. As more and more IP based applications developed, the trend for using IP addresses and host names as a basis for allowing or disallowing access (i.e., system based authentication) grew.

Another contributing factor to the vulnerabilities in the DNS is that the DNS is designed to be a public database in which the concept of restricting access to information within the DNS name space is purposely not part of the protocol. Later versions of the BIND implementation allow access controls for such things as zone transfers, but all in all, the concept of restricting who can query the DNS for RRs is considered outside the scope of the protocol.

The existence and widespread use of such protocols as the r-commands put demands on the accuracy of information contained in the DNS. False information within the DNS can lead to unexpected and potentially dangerous exposures. The majority of the weaknesses within the DNS fall into one of the following categories: Cache poisoning, client flooding, dynamic update vulnerability, information leakage, and compromise of the DNS server’s authoritative database.

· Cache Poisoning

Whenever a DNS server does not have the answer to a query within its cache, the DNS server can pass the query onto another DNS server on behalf of the client. If the server passes the query onto another DNS server that has incorrect information, whether placed there intentionally or unintentionally, then cache poisoning can occur. Malicious cache poisoning is commonly referred to as DNS spoofing.

· Rogue servers

Rogue DNS servers pose a threat to the Internet community because the information these servers contain may not be trustworthy. They facilitate attack techniques such as host name spoofing and DNS spoofing. Host name spoofing is a specific technique used with PTR records. It differs slightly from most DNS spoofing techniques in that all the transactions that transpire are legitimate according to the DNS protocol while this is not necessarily the case for other types of DNS spoofing. With host name spoofing, the DNS server legitimately attempts to resolve a PTR query using a legitimate DNS server for the zone belonging to that PTR. It’s the PTR record in the zone’s data file on the primary server that is purposely configured to point somewhere else, typically a trusted host for another site. Host name spoofing can have a TTL of 0 resulting in no caching of the misleading information, even though the host name is being spoofed.

· Denial of Service

DoS is accomplished in several ways. One takes advantage of negative responses (i.e., responses that indicate the DNS name in the query cannot be resolved). By sending back the negative response for a DNS name that could otherwise be resolved, results in a DoS for the client wishing to communicate in some manner with the DNS name in the query. The other way DoS is accomplished is for the rogue server to send a response that redirects the client to a different system that does not contain the service the client desires.

Another attack is to flood the DNS farm with requests (valid or not) with the intent to cause downtime to valid users trying to access these servers.

· Application Vulnerabilities

Needles to say that vulnerabilities to Operational Systems (Linux, Windows, Solaris, etc) or services (Windows DNS, Bind, etc) when exploited can cause DNS service disruption.

How to secure DNS Infrastructures

In this topics we’ll cover some ways that companies can increase the overall security for their DNS Infrastructures

· Segregate DNS Servers

This refers to the practice of separating DNS into an external and internal view. This provides a logical separation between the DNS information available to internal network clients/subscribers and what is made publicly available to the internet at large. DNS stores a wealth of information regarding the configuration of a network. Being able to enumerate this information is an invaluable resource for would-be attackers. By separating the publicly available information from that required by internal clients, adds a very critical layer of protection. This segregation can be accomplished in several methods, but separation on physical devices is the preferred.

It’s also recommend to a company to deploy servers to accommodate different functions. Authoritative servers, cache server, resolvers, forwarders. All of this functions should be splited in order to increase security/performance.

At last, deploy DNS services on dedicated servers or appliances.

· Recursion

In simple terms is the ability of a DNS server to answer client requests for domains which it is not authoritative for. Using a Segragate DNS deployment model, there are two primary sets of DNS servers, internal and external. Internal servers should be configured to perform recursion to service the requests of the internal network clients. However, external DNS servers should be explicitly configured to deny recursion. External DNS servers should solely answer requests for the domains for which they are the authoritative for. Public DNS servers which allow recursion have been recently exploited in as amplification machines in Distributed Denial of Service (DDoS) attacks. Not only does this consume valuable machine and bandwidth resources, but there also could be legal ramifications for an organization whose servers were exploited.

In simple terms, always configure your servers to answer only requests for valid users/networks

· Redundancy

As well all agree that DNS is a critical service it’s also certain that DNS can’t be allowed to be a single point of failure. It’s wise if possible to deploy multiple DNS farms with two or more primary DNS servers. These devices should be both geographic and carrier diverse. Having multiple DNS servers in the same physical location on the same internet connection provides very limited redundancy. A single carrier outage or fiber cut can instantly isolate all of your DNS servers. Instead, these should be distributed in across different geographical regions utilizing different internet providers. The use of load balancers/multiple DNS Servers can reduce the possibility of failure and increase the DNS Server Performance.

· NS records

The NS records for an organization's domain name provide public DNS servers with the information needed to find the authoritative name servers for that domain. These records are uploaded from your domain registrar to the Top Level Domain (TLD) DNS servers. As changes are made to your DNS infrastructure, its imperative that your NS records updated to reflect these changes.

· Zone transfers

Zone transfers are the ability for a slave DNS server to pull records from a master server to a slave. This allows you to host all of your zonefiles on a master machine and have them automatically propagate to slave machines after a change is made. The ability to transfer an entire zonefile for a domain also provides a easy way for would-be attackers to enumerate an organizations network. Because of this DNS servers should be configured to limit zone transfer requested to the IP addresses of designated slave machines.

· Deploy DNS Cache Servers

On loaded DNS farms, it’s wise to make use of DNS Caches in order to reduce the number of queries answered by your DNS. Normally this is done deploying a L2 (invisible) device in front of your DNS farm with the ability to identify and answer the most common queries. The overall results can be great if you think that a lot of requests are done against the same domains (google, yahoo, msn, etc). These queries will be answered by the DNS Cache reducing the number of servers need and increasing the performance.

· All MX records should have a corresponding PTR record

RFC1912 dictates that all mail gateways should have Reverse DNS entries configured. Many mail servers are configured to not accept email from gateways which don't have proper Reverse DNS entries. 

· DNS server versions

To allow external users to actually identify running software versions often provide a would-be attacker with valuable information about the DNS application running on that machine. Published exploits corresponding to that specific version of the application can quickly be located and launched. For this reason, DNS server versions should be modified to obfuscate the actual running version number. Also, try to keep you OS and DNS Server application updated with the most recent version (stable) and patches.

· Deploy firewalls with appropriated rules

It’s very important to deploy a dedicated firewall solution to control who/whom can access the DNS servers and with what purposes. Take attention to the order where you’ll create the DNS control rules, try to fit these rules in the beginning of the chain (to improve firewall performance if you have a non “Best fit” firewall). Again when planning the rules, think about to use a “least privilege” approach. It’s always good.

It’s also important to design the system in order to support all traffic. Looks basic but many companies face serious performance issues in theirs DNS infrastructures and many times a overloaded firewall is the bottleneck.

· Deploy IPS systems

A Intrusion Prevention System can also increase DNS Security protecting the infrastructure against L7 attacks. I always recommend companies to try to deploy IPS systems dedicated to protect the DNS Infrastructure. Doing this you can select only DNS and OS related signatures improving detection and performance, and reducing false-positives.

· Deploy Specific DNS Protection Mechanisms

If per example a DNS server only answers A and MX type records, why allow NS records to reach this server? There are solutions in market that help to increase DNS Security protecting against DNS Protocol flaws and blocking non allowed queries to be made. It’s a very good way to increase security.

· DNSSEC

DNSSEC was designed to protect the Internet from certain attacks, such as DNS cache poisoning . It is a set of extensions to DNS, which provide:

a) origin authentication of DNS data, b) data integrity, and c) authenticated denial of existence.

These mechanisms require changes to the DNS protocol. DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). These new RRs are described in detail in RFC 4034.

It also adds two new DNS header flags: Checking Disabled (CD) and Authenticated Data (AD). In order to support the larger DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 support (RFC 2671).

Finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit (RFC 3225) so that a security-aware resolver can indicate in its queries that it wishes to receive DNSSEC RRs in response messages. By checking the signature, a DNS resolver is able to check if the information is identical (correct and complete) to the info on the authoritative DNS server.

DNSSEC services protect against most of the threats to the Domain Name System. There are several distinct classes of threats to the Domain Name System, most of which are DNS-related instances of more general problems, but a few of which are specific to peculiarities of the DNS protocol.

Note that DNSSEC does not provide confidentiality of data. Also, DNSSEC does not protect against DDoS Attacks.

DNS offers good security but can be almost impossible to deploy on carriers scenario. Actually we see some DNSSEC deployments on companies but none in carriers (at least I don’t see!!)

Conclusion

This paper is focused to present a overview about the DNS protocol, related threats and some ways to protect DNS Infrastructures against attacks. You can take all of this in order to increase your security (which is good) or choose some that you believe is more appropriated for your environment.

The important here is to understand that DNS is a critical service and must be treated as it.

OMB sneaked this one in on me:  OMB Memo 08-23 requires secure DNS (standard .pdf caveat).  Agencies need to submit a plan by September 5th on how they should accomplish this.  The whole switchover should occur by December 2009.

The interesting thing to me is that OMB is getting bolder in specifying technical solutions.  Part of me wants to scream because public policy people have no business dictating technical solutions–that’s what we have standards boards and RFCs for.

From what I hear, some of this is because OMB is starting to be a really bad lame duck.  Think about it, what are the odds that anybody at OMB is going to be around in December 2009?  Completely unofficial word on the street is that OMB is pushing last-minute initiatives because of politicals–trying to accomplish things in time for the elections.

Also, I think that OMB is getting tired of NIST’s nonpspecificity in their guidance.  NIST’s approach to being generic in nature is necessary because of their role as a research organization and the producers of methodologies.

The solution to all this?  Well, the way it happens in the rational world is organic standards boards.  Yes, they have their problems (*cough* WAFs anyone? *cough*) but overall, they fill a place.  Inside Government, we don’t have much of that happening–we have the CIO council and the Enterprise Architecture folks, but nothing security-specific.

Lock Up Your Data photo by psd.

Description of the picture, it’s great and needs to be repeated:

The road passes the temptations of Flash and AIR. Those who succumb or who are unfortunate enough to be lured by Silverlight’s Siren find themselves sold down the river of Rich User Experiences and hurled towards lock-in weir. The TiddlyWiki steps may rescue some, who can then join those who stuck to the main path of Javascript and AJAX for their interactions.

The URI scheme is based on DNS, a registry which has weaknesses, meanwhile the ICANN Fracture results from their greedily adding spurious new Top Level Domains such as .mobi, .jobs, .xxx and even .tel, which whilst generating more revenue (for them) causes mass confusion and threatens to break the opacity of URIs.

Bookmark to:

Because current hard disk encryption tools don't delete entered passwords from memory, attackers can retrieve the passwords in plain text. However, physical access to a computer is required to do so - unless a trojan does the work.(author unknown)

In today’s economy, we are all looking to save some money. This applies even to our security training budgets. The last three SANS certifications I obtained were made possible by the SANS Work Study Program. The program allows the volunteer to pay a fee of $700, which is applied towards tuition and certification costs. The volunteer works the selected event and in exchange they can attend the course and all other events at the conference (SANS@Night events, BoFs, Lunch & Learns, etc.). So it was with great interest that I read about the Community of Interest in Network Security (COINS) program. Stephen Northcutt wrote:
Please note that if you are a member of an OWASP chapter, ISSA, ISACA, InfraGard, HTCIA, ECTF or other local security organization, the COINS program offers you a 50% tuition discount for this or any other SANS @Home course.

Being very interested, I contacted Steve Peterson, director of mentor programs. Steve explained that COINS is a fairly new program at SANS. To quote Steve:
The goal of COINS is to work with local security organizations to strengthen the security community by offering SANS discounts to chapter members and free content to chapter meetings. COINS typically will run an event at our conferences as well. If you attend a conference, keep an eye out for the COINS event.

I used the COINS program to signed up for the SANS® +S™ Training Program for the CISSP® Certification Exam (Management 414). While I tend to prefer more technically focused courses, the DoD directive 8570 convinced me that having the Certified Information Systems Security Professional (CISSP) certification would be useful. To quote the 8570 FAQ:
DoD Directive 8570.1 provides the basis for an enterprise-wide solution to train, certify, and manage the DoD Information Assurance (IA) workforce. The policy requires Information Assurance technicians, managers, and members of IA specialties to be trained and certified to a DoD baseline requirement. The Directive’s accompanying Manual identifies the specific certifications mandated by the Directive’s enterprise-wide certification program.

Agencies covered by 8570 include:

• Office of the Secretary of Defense
• Military Departments
• Chairman of the Joint Chiefs of Staff
• Combatant Commands
• Office of the Inspector General of the DoD
• Defense Agencies
• DoD Field Activities
• All other organizational entities in the DoD

Any full or part time military service member, contractor, or local nationals with privileged access to a DoD information system performing information assurance functions — regardless of job or occupational series is affected by 8570. For fiscal year 2008, the goal was to fill a total of 70 percent of the Information Assurance positions with certified personnel.

The tables below describe the DoD Approved Baseline Certifications, according to DoD 8570.01-M. This includes requirements for Information Assurance Technical (IAT), IA Management (IAM), IA System Architect and Engineers (IASAE), and Computer Network Defense-Service Providers (CND-SP). All must be be fully trained and certified to baseline requirements to perform their IA duties.

IAT workforce members consists of anyone with privileged information system access performing IA functions. IAT Level certifications are cumulative. Higher level certifications qualify for lower level requirements. Certifications listed in Level II or III cells can be used to qualify for Level I. However, Level I certifications cannot be used for Level II or III unless the certification is also listed in the Level II or III cell.

IAT Level I IAT Level II IAT Level III A+
Network+
SSCP GSEC
Security+
SCNP
SSCP CISA
CISSP
GSE
SCNA

IAM personnel are responsible for secure implementation and operation of a DoD information system (IS). IAMs perform IS security management functions for DoD operational systems. Management certifications corresponding to the position level do not cascade down. Each position requires the individual to meet one of the specific certifications associated with that Management Level. An IAM I must obtain one of certifications shown in the IAM I box, such as the GISF. The IAM I should not take the CISSP unless already qualified in one of the certifications listed in the IAM I box (e.g., GISF).

IAM Level I IAM Level II IAM Level III GISF
GSLC
Security+ GSLC
CISM
CISSP GSLC
CISM
CISSP

The CND-SP personnel are members of “Accredited” CND-SP teams performing the functions listed.

CND Analyst CND Infrastructure Support CND Incident Responder CND Auditor CND-SP Manager GCIA SSCP GCIH
CSIH CISA
GSNA CISSP-ISSMP
CISM

IASAE personnel perform system design functions, such as requirements gathering.

IASAE I IASAE II IASAE III CISSP CISSP ISSEP
ISSAP

In the above table, I put CISSP in bold, along with a few other certifications I currently possess, as an example of how a few certifications can help cover requirements for many of the DoD Information Assurance positions. With the CISSP certification, IAT Level I, II and II are covered along with IASAE I and II. It is easy enough to pick up one of the IAM Level I certification, depending on that you are managing, and the CISSP will cover you for IAM Level II and III.

Now if you are not directly affected by 8570, why should you care? There are a large number of military service member, contractor, and local nationals with privileged access to DoD information systems. These folks are performing information assurance functions and DoD 8570 will eventually require them to have various security certifications. At some point, there is a good chance that these certified individuals are going to be competing with you for a job. Management often does not know how to tell the difference between candidates. Obtaining these certifications will help level the playing field so you can get past human resources, obtain management approval, and have the opportunity to impress the security folks. Of course, obtaining training and taking certification exams can get expensive. Thankfully there are programs like the SANS Work Study and COINS program providing great options for those with financially disadvantaged training budgets.

A new security system devised by Carnegie Mellon researchers uses a distributed network of "notary" servers to independently validate public keys. This could protect users from man-in-the-middle attacks when they visit web sites with self-signed certificates.

Read More...

segphault@arstechnica.com (Ryan Paul)

One of the coolest newer features of Wireshark is the ability to automatically generate firewall ACL rules based upon a packet you may be viewing. As an example of this, take a look at the following packet:

If you look at the data portion of this packet you can see that this is packet generated by the infamous blaster worm. Notice the destination port is 4444 which is the standard port used by blaster. In the case, let’s say we want to create a firewall ACL rule that blocks anything with a destination port of 4444 on an iptables firewall. If we select this packet, go to Analyze > Firewall ACL Rules on the standard toolbar, we will get a dialog that will let us build custom firewall rules based upon the contents of this packet. In our scenario here, we would select Netfilter (IPTABLES) from the vendor drop down box, and select TCP Port 4444 in the filter box. This will output the exact command you need to enter in your iptables configuration to enact this firewall rule. If you play around with this feature you will see that there is quite a bit you can do with it.

This feature is very new and doesn’t support a lot of different vendors, but this should develop over time.

Category: Firewalls & Perimeter Protection

Paper Added: August 20, 2008

(author unknown)

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.

As I have written about previously, this method of user activity tracking is unreliable.  It works in trivial cases (e.g. single machine where the user doesn't have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection.  If the user has physical access to the machine-- for example, can pull out the network or power cables or push the reset button-- and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user's presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).

There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away.  The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement.  Yes, if you know the SS delay then you could just work that into your calculations.  However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed).  And the events don't tell you whether the workstation was locked or auto-locked so you don't really know whether to add in the screen saver delay factor.  Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.

So the bottom line is, I don't advocate or recommend this method for tracking the time a user spends at the keyboard.  If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented.  You have been warned, I've beaten that dead horse enough I guess.

Given that you are disregarding all my contrary advice, how are you going to accomplish this?

First, we need a general algorithm.

Use time (for a given logon session) = Logoff time - logon time

Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.?  We can use the BEGIN_LOGOFF event to handle token leak cases.  We can use the shutdown event in cases where the user does not log off.  And in case of crashes, the only event we can use is the startup event.  Note that each of these introduces increasing levels of uncertainty.

Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)

This is good, but what about the time the workstation was locked?

Workstation lock time = unlock time - lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)

How about remote desktop & terminal server sessions, and fast user switching?  You can connect and disconnect from logon sessions, during which time the user technically isn't using the computer.

Session idle time = session connect time - session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)

How about times when the machine was idle?  We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.

Console idle time = (screen saver dismiss time - screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)

Putting all of this together and modifying our original formula, we get:

Use time (for a given logon session) =
   Logoff time - logon time
      - SUM(workstation lock time)
      - SUM(session idle time)
      - SUM(console idle time)

When we expand it, it is not quite so pretty: 

Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) - logon time )
      - SUM(unlock time - lock time)
      - SUM(session connect time - session disconnect time)
      - SUM(screen saver dismiss time - screen saver invoke time + screen saver delay)

You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session.  The best correlation field is the Logon ID field, the next best are timestamp and user name.  At various times you need to examine all of these fields.

Now, which event IDs correspond to all of these real-world events?

They are all found in the Security event log.  The pre-Vista events (ID=5xx) all have event source=Security.  The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.

512 / 4608  STARTUP
513 / 4609  SHUTDOWN
528 / 4624  LOGON
538 / 4634  LOGOFF
551 / 4647  BEGIN_LOGOFF
N/A / 4778  SESSION_RECONNECTED
N/A / 4779  SESSION_DISCONNECTED
N/A / 4800  WORKSTATION_LOCKED
* / 4801    WORKSTATION_UNLOCKED
N/A / 4802  SCREENSAVER_INVOKED
N/A / 4803  SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation.  Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7.  These events had the same user name as the "original" logon session and were completely enclosed chronologically by the logon/logoff events for the "real" logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator.  This makes correlation of these events difficult.

All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category.  The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.

Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven't worked on a project that required this.

Eric

Interesting: Preface The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them. While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed... (author unknown)

Tim Greene's NAC column today goes back to the recent Gartner IT Security Conference. At Lawrence Oran's session on NAC, using the handheld voting machines he asked the audience if and when they planned on deploying an 892.1x capable network.  Of course answers are always dependant on how the question is framed.  But in this session about 50% of respondents said they were going to go .1x by 2011.  You know what they say, once you go .1x you don't go back.  That bodes well for NAC deployments.  802.1x remains the most secure and powerful way of implementing NAC.  However, .1x is also useful for other security and network functionality.  If you want to read more about .1x my friend JJ has a ton of good .1x stuff up on her blog.

A couple of interesting points though.  Gartner themselves as Tim points out estimates that .1x adoption will be closer to 70% by 2011.  The difference between the 50% in the survey and Gartner's estimates will be realized due to increasing ease of implementation of .1x networks. Perhaps, I know at StillSecure we are always looking for ways to make it easier to implement .1x and NAC.  However, lets be clear. Installing new supplicants because Cisco and Juniper say the Microsoft supplicant is not good enough is a red herring. Yes the Odyssey client is cool, but it is a nice to have in the .1x equation, not a must have.  The same goes for the Cisco/Meetinghouse supplicant. Also, not all .1x is created equal.  There are still enough differences between switch vendors in how and what they support in .1x to make it maddening.

Finally, like I have said before if you are going to do 802.1x just for NAC, don't bother.  But if you are going to go to 802.1x you should give NAC a good look.

whitehartstag writes "Black Hat 08 disclosed several SSL VPN and DNS vulnerabilities that caused several people to sit up and take notice. Some of these new exploits performed a brilliant Man-In-The-Middle attack on SSL VPN tunnels. This article walks you through how using certificates, instead of OTP tokens, for second-factor authentication can increase the security of your SSL VPN against these new types of attacks."

Read more of this story at Slashdot.

CmdrTaco

Perusing my blogs this morning I caught a post by Anton on DLP and compliance. That’s the blogging equivalent of chaining a nice fat bunny to a stake in the middle of coyote territory here in Phoenix (in other words, the park behind our house). I, as the rabid coyote of DLP-ness, am compelled to respond.

Anton starts by wondering why he doesn’t see compliance more in DLP vendor literature:

Today I was thinking about DLP again :-) (yes, I know that “content monitoring and protection” - CMF - is a better description) Specifically, I was thinking about DLP and compliance. At first, it was truly amazing to me that DLP vendors “under-utilize” compliance in their messaging. In other words, they don’t push the “C-word” as strongly as many other security companies. Compliance dog doesn’t snarl at you from their front pages and it doesn’t bite you in you ass when you read the whitepapers, etc. Sure, it is mentioned there, but, seemingly, as an after-thought.

Then, he nails the answer:

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)! You know, DLP is newer than most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn’t mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!).

Also, PCI DSS directly and explicitly says “get a firewall”, “deploy log management”, “get scanned”, “install and update AV” - but where is DLP? Ain’t there…

I’ve spent a heck of a lot of time working with DLP vendors and users, and this is a problem that affects technologies beyond just DLP. Early on, the DLP vendors all talked about how they’d make you SOX, HIPAA, or XXX compliant. Problem was, there isn’t a regulation out there that requires DLP. The customer conversations went like this:

Vendor: PCI compliance is bad. Buy DLP.

User: Okay, is that section 3.1 or 3.2 that requires DLP?

Vendor: It’s not in there yet, but… {sales guy monkey dance}

User: Ah. I see. Can you come back after we finish remediating our audit deficiencies? Say in 2012? Q3?

The truth is that DLP can help significantly with compliance with a variety of regulations, but none of them require it. As a result, vendors have softened their message and the good ones adjust it to show this value. I don’t know if I really influenced this, but it’s something I’ve spent a lot of time working on with my vendor clients over the years.

Other markets face this same challenge, and if you look back they almost always start by hitting compliance for the apparently easy cash, and are then forced to adjust messaging unless they are explicitly required. Users also face the same problem:

User: We need to do X for compliance with Y.

Money Guy/Boss: Okay, where is that on the audit report?

User: It’s not, but {monkey dance}.

Money Guy/Boss: Ah. I see. Maybe we can discuss this during your annual review.

Be it a vendor or an end user, the compliance sell is either the easiest or hardest you’ll ever face. If the regulation (or your auditor) explicitly requires something, there’s an immediate business justification. While there’s a *lot* more to compliance, if it isn’t on that list you can’t sell it with merely the C word.

Instead, evaluate the tool or process in the context of compliance and show the business benefits. Does it reduce compliance costs? Does it reduce your risk of an exposure? For example, DLP content discovery, by identifying where credit card data is stored, can reduce both audit costs and the risk of non-compliance. Database Activity Monitoring can reduce SOX audit costs and the cost of maintaining appropriate logging on financial databases. There are a ton of internal process changes that improve audit efficiency and reduce the burden of generating compliance reports last minute every year or quarter.

When something is on the checklist, sell it as compliance. When it’s off that list, sell it as cost or risk reduction. If it doesn’t hit those categories, buy a monkey to do the dance- it’s cuter than you are and more likely to get the banana.

Perusing my blogs this morning I caught a post by Anton on DLP and compliance. That’s the blogging equivalent of chaining a nice fat bunny to a stake in the middle of coyote territory here in Phoenix (in other words, the park behind our house). I, as the rabid coyote of DLP-ness, am compelled to respond.

Anton starts by wondering why he doesn’t see compliance more in DLP vendor literature:

Today I was thinking about DLP again :-) (yes, I know that “content monitoring and protection” - CMF - is a better description) Specifically, I was thinking about DLP and compliance. At first, it was truly amazing to me that DLP vendors “under-utilize” compliance in their messaging. In other words, they don’t push the “C-word” as strongly as many other security companies. Compliance dog doesn’t snarl at you from their front pages and it doesn’t bite you in you ass when you read the whitepapers, etc. Sure, it is mentioned there, but, seemingly, as an after-thought.

Then, he nails the answer:

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)! You know, DLP is newer than most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn’t mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!).

Also, PCI DSS directly and explicitly says “get a firewall”, “deploy log management”, “get scanned”, “install and update AV” - but where is DLP? Ain’t there…

I’ve spent a heck of a lot of time working with DLP vendors and users, and this is a problem that affects technologies beyond just DLP. Early on, the DLP vendors all talked about how they’d make you SOX, HIPAA, or XXX compliant. Problem was, there isn’t a regulation out there that requires DLP. The customer conversations went like this:

Vendor: PCI compliance is bad. Buy DLP.

User: Okay, is that section 3.1 or 3.2 that requires DLP?

Vendor: It’s not in there yet, but… {sales guy monkey dance}

User: Ah. I see. Can you come back after we finish remediating our audit deficiencies? Say in 2012? Q3?

The truth is that DLP can help significantly with compliance with a variety of regulations, but none of them require it. As a result, vendors have softened their message and the good ones adjust it to show this value. I don’t know if I really influenced this, but it’s something I’ve spent a lot of time working on with my vendor clients over the years.

Other markets face this same challenge, and if you look back they almost always start by hitting compliance for the apparently easy cash, and are then forced to adjust messaging unless they are explicitly required. Users also face the same problem:

User: We need to do X for compliance with Y.

Money Guy/Boss: Okay, where is that on the audit report?

User: It’s not, but {monkey dance}.

Money Guy/Boss: Ah. I see. Maybe we can discuss this during your annual review.

Be it a vendor or an end user, the compliance sell is either the easiest or hardest you’ll ever face. If the regulation (or your auditor) explicitly requires something, there’s an immediate business justification. While there’s a *lot* more to compliance, if it isn’t on that list you can’t sell it with merely the C word.

Instead, evaluate the tool or process in the context of compliance and show the business benefits. Does it reduce compliance costs? Does it reduce your risk of an exposure? For example, DLP content discovery, by identifying where credit card data is stored, can reduce both audit costs and the risk of non-compliance. Database Activity Monitoring can reduce SOX audit costs and the cost of maintaining appropriate logging on financial databases. There are a ton of internal process changes that improve audit efficiency and reduce the burden of generating compliance reports last minute every year or quarter.

When something is on the checklist, sell it as compliance. When it’s off that list, sell it as cost or risk reduction. If it doesn’t hit those categories, buy a monkey to do the dance- it’s cuter than you are and more likely to get the banana.

An ActiveX control (atucfobj.dll) that is used by the Cisco WebEx Meeting Manager contains a buffer overflow vulnerability that may result in a denial of service or remote code execution. The WebEx Meeting Manager is a client-side program that is provided by the Cisco WebEx meeting service. The Cisco WebEx meeting service automatically downloads, installs, and configures Meeting Manager the first time a user begins or joins a meeting.(author unknown)

As you all probably known since version 3 Nessus turned to a proprietary model and started charging for the latest plugins locking most of us out. Now we finally have a new, properly organised forked development with the name of OpenVAS - at last a decent and free Vulnerability Scanner! OpenVAS stands for Open Vulnerability Assessment [...]

Read the full post at darknet.org.uk

As of this blog posting, exactly 900 days remain until the end of the Internet, or at least the exhaustion of IPv4 registry allocations. And you don’t have to take my word for it, even the normally staid London Times and Fox News proclaimed, “Internet meltdown… The world is heading for a digital doomsday”.

Heady stuff.

Of course, IPv6 (or the new IPv4) was supposed to take care of all of this — billions of billions of new IP addresses, hardened security built in from the start, and an elegant new architecture to replace all of IPv4’s hacks.

So what happened to IPv6?

Well, it has been a strange, long year…

The year began with fears over the “end of the Internet” (due to lack of IPv6 adoption) and ends this month with renewed IPv6 enthusiasm centered around the Olympics and a successful US government IPv6 mandate. In between these two extremes of IPv6 despair and enthusiasm, IPv6 generated a surge of news coverage (see graph below). At its peak this past June, print media around the world published nearly 3,000 articles a month on IPv6 (almost twice as much as the comparatively uninteresting IPv4).

Much of the recent coverage has focused on the summer Olympics this week. Chinese organizers have planned the summer Olympics game as a showcase for IPv6 technology. From a recent article, “… IPv6 will herald the arrival of China as a major center for technological and scientific advancement in a way that will overshadow its own unbeatable record as a world leader…”. Through China’s Next Generation Internet (CNGI) initiative, China has reportedly spent several billion dollars making sure they got a national IPv6 backbone right.

In the US, the recent government deadline for IPv6 compliance also generated a flurry of IPv6 activity: All major vendors publicly declared their IPv6 readiness. Popular press and industry magazines filed thousands of stories on IPv6. US Federal Departments officially declared success and the Internet IPv6-ready this past June 30th.

So has imminent collapse of the Internet has been avoided?

Is the Internet moving full steam ahead towards IPv6?

Maybe.

The truth is that as an industry we don’t have a good measure on the relative adoption success of IPv6 with respect to Internet traffic.

No idea really.

We do have some anecdotal measurements on IPv6 registry allocation and BGP announcements. But, very little data on actual IPv6 usage.

As our small effort to fill this gap, we spent much of the last year looking for IPv6 traffic in the Internet. In cooperation with the University of Michigan and close to 100 Internet providers, we leveraged commercial traffic probes across the world to measure inter-domain IPv6 traffic in the Internet. We believe this is the largest study of IPv6 and Internet traffic in general to date (by several orders of magnitude).

Our dataset covered 87 ISPs including one quarter of the tier1 ISPs and a sizable percentage of the regional / PTT providers in North America and EMEA. In all, we monitored 2,389 peering and backbone routers, 278,268 customer and peering interfaces, and an aggregate 15 exabytes of Internet inter-domain traffic at an average daily rate of 4 terabits per second (we spoke about some of this measurement infrastructure at a recent NANOG). We believe this gave us a pretty good view of overall IPv6 traffic trends in the Internet.

You can view the full technical report at http://www.arbornetworks.com/IPv6research.

What did we find?

Not much. In fact, less than not much — very, very little.

The below shows the percentage of IPv6, both native and tunneled, as a percentage of all Internet traffic. At its peak, IPv6 represented less than one hundredth of 1% of Internet traffic. This is somewhat equivalent to the allowed parts of contaminants in drinking water (my household water comes from the Detroit river).

Now the above graph may not be completely fair since many of the ISPs do not have infrastructure to monitor native IPv6 (more about this later). But our numbers seem to agree with data from a variety of other sources on IPv6 adoption rates.

Some related IPv6 statistics:

Percentage of ASN with IPv6 BGP announcements 3% Percentage of Internet2 sites with passing IPv6 grade 1% Percentage of Alexa Top 500 websites using IPv6 0.4% IPv6 DNS queries as percentage of IPv4 DNS load 0.2% IPv6 as a percentage of all Internet traffic 0.002%

We are not the first to raise concern over the small amount of IPv6 traffic (see Geoff’s slides last month) — just the first to have Internet wide IPv6 traffic usage measurements.

And the lack of IPv6 traffic is not for lack of trying. Many organizations and individuals offer a range of lures to encourage IPv6 adoption. For example, the next generation research and education backbone in the US, Internet2, offers free transit for IPv6 traffic. And unlike IPv4, many large ISPs have very liberal IPv6 peering policies.

The single greatest lure? For ISPs or large multi-homed enterprises struggling to justify just one more tiny, little IPv4 /16 allocation, the minimum IPv6 allocation is /32 or a staggering 2^64 larger than the entire IPv4 Internet today.

On the less pragmatic side, other IPv6 proponents offer free high quality IPv6 porn. Others yet provide ASCII animation of Star Wars movies (IPv4 users get only black & white — make sure you watch the “Return of the Jedi” version). And, of course, the dancing turtle. Several web sites provide more listings of exotic IPv6 only Internet content.

But none of these efforts have been enough to generate any significant IPv6 traffic.

So, why so little IPv6 traffic?

Well, the biggest issue is money. Specifically, the department of commerce estimates it will cost $25 billion for ISPs to upgrade to native IPv6.

And this massive expense comes without the lure of additional revenue since IPv6 offers diminishingly few incentives nor new competitive features to attract or upsell customers. In many ways, IPv6 in the United States is much like the high definition television federal mandate (but without the mandate or the really crisp looking football games).

The harsh logic of the Metcalfe Effect also applies. With so few web sites and end users currently supporting IPv6, the incremental value to any single new IPv6 end site is limited. For many end users, v6 is an IP version all dressed up but with nowhere to go.

The third major issue is technical. While most vendors passed the OMB IPv6 requirements, it kind of depends on what you mean by “IPv6″ and “requirement”.

For example, some backbone routers “support” IPv6 forwarding, but not in hardware (at least not at line rate). Or IPv6 “support” does not include ACLs nor other critical security features. An ICANN survey of security vendors found that less than one in three commercial firewalls support IPv6.

Maybe you want an IPv6 MPLS VPN backbone? Sorry, not supported.

And even if your router supports IPv6, you might not be able to test or monitor it. Few vendors offer complete IPv6 SNMP / MIB support and even fewer support IPv6 Flow export (in fairness, V9 flow support is included on many Cisco cards today and Juniper has announced IPFIX support sometime in the next year). We blogged about many of these deployment issue earlier this year and Randy gave a presentation on the topic at a recent NANOG. The CAIDA and ARIN IPv6 Survey also has a nice summary on market / business forces limiting ISP IPv6 adoption.

Perhaps the biggest problem is that IPv4 works. And works well.

While IPv4 addresses are still relatively plentiful and cheap, ISPs and end customers have few incentives to migrate to IPv6. Some recent research even suggests IPv4 addresses may be more plentiful than previously believed. This tech report found that less than 4% of allocated addresses are actually occupied by visible end hosts. The authors concluded that most Internet space is likely, in fact, unused (though allocated).

All of this lack of IPv6 adoption has lead to quite a bit of hand wringing in the ISP technical community. While not declaring IPv6 a failure, discussions do wander into questions about “premature extinction of IPv6″ or whether “IPv6 is an exercise in futility”.

Imminent Collapse

Predicting the imminent collapses of the Internet has a long and storied history over the last twenty years. But despite all of these predictions, the Internet has survived. Sure we crashed a few routers, announced some bogus routes, and dropped a few bits here and there. But the Internet survived — even grew a bit and gained some new users. I saw Bob Metcalfe eat a tie.

And the Internet will undoubtedly change and evolve past the impending IPv4 exhaustion.

But how?

Well, the questions is more about market forces than technology. IPv4 address allocations already have a minimal cost ($18,000 for ARIN large allocation). And growing registry management justification requirements and shrinking allocation size have steadily increased the overall cost of address space to ISPs over the last ten years. During the heady Internet technology bubble days, several companies made acquisitions in significant part based on the valuation of large legacy IP allocations.

Many think the price of IPv4 and scarcity will lead to open or if not sanctioned, black markets for address space. And debates continue whether an open market for IPv4 would be good or bad thing for Internet policy. Personally, I think an IPv4 market is inevitable.

The Future of IPv6

It is now clear the original optimistic IPv6 deployment plans have failed.

While the end of the Internet is not near, neither is IPv6. At the current rate of adoption, we are a decade or more away from pervasive adoption of dual stack support for IPv6. As Alain correctly notes in a recent IETF draft, “The IANA free pool of IPv4 addresses will be depleted soon, way before any significant IPv6 deployment will have occurred”.

So IPv6 adoption will take far longer and will look far different than most of us expected back in 1994 when the IAB announced the selection of IPv6. Clearly things need to change, including IETF and vendor exploration of other technologies to facilitate IPv6 adoption such as better NAT interoperability or lighter weight dual stack.

Still, despite some of the rather anemic IPv6 traffic statistics above, IPv6 is growing. The graph above shows the number of print media articles per month mentioning IPv6 and IPv4 in the first 30 words (source MetaNews). Note that IPv6 is running almost two to one against IPv4. If judged purely by public interest, IPv6 is a winning (by comparison, DNSSEC averages only 50 articles per month and barely peaked at 150 during the DNS crisis. BGPSEC fared even worse).

The below graph shows the aggregate average daily IPv6 (tunneled and native) traffic across 87 ISPs over the last year. Since July 2007, IPv6 traffic has grown by nearly a factor of 5 to an average of 100 Mbps per day. BGP tables show an even larger proportional growth. Though not a landslide of adoption, it is still something.

While it is easy to poke fun at predictions of the “Imminent Collapse of the Internet”, the eventual exhaustion of IPv4 allocations is real. We need to do something. And IPv6 is our best bet.

So, I’ll end with my top four predictions on IPv6 growth:

1. Islands are beautiful too.
   IPv6 may succeed in the same way multicast failed. And by multicast failing, I really mean multicast succeeded. Though multicast never evolved a business model to justify its originally envisioned Internet wide inter-domain deployment, multicast has been astonishingly successful within the enterprise and ISP service infrastructure. Almost all Fortune 500 enterprises use multicast in some form to broadcast company video or update applications. Similarly, multicast is at the core of most ISP IPTV infrastructure.Like multicast, we are seeing rapid adoption of IPv6 within consumer, IPTV and 3G / 4G mobile providers for management of their internal infrastructure. You can pick your favorite market driver: 3G / 4G Mobile IP, Digital Radio, RFID, Control Networks, etc. But the numbers for globally unique end devices is staggering no matter which trend you choose.

   For example, Comcast has migrated all of their internal control network to IPv6 with plans to manage 100 million cable modems.

   Various estimates place number of network devices that will need to be managed at 12 billion by 2012. Note that these devices may not need global visibility, but providers will need to at least internally provision and manage (and RFC1918 space is not a reasonable option).

2. Market trumps technology. And politics trumps markets.
   The future of the Internet is not fixed line devices. Nor is it users in the United States.The future of the Internet is likely both mobile devices and emerging Internet countries like China which reportedly surpassed the number of US web users at 253 million last month.While politics and government mandates do not always drive technology (see GOSIP or metric system in the United States), sometimes they do (see metric system in United Kingdom).

   Throughout the world, government mandates are spurring IPv6 adoption. China’s CNGI initiative and billions in spending uses IPv6 as the centerpiece. Similarly, Japan, Korea all have major IPv6 initiatives. The EU called for mass migration to IPv6 by 2010.

   The important bit to realize about governmental focus on IPv6 is that it is not about technology nor is it even really about IPv6. Many governments view IPv6 through the prism of politics. These countries, rightly or wrongly, view ICANN and the large US centric legacy IPv4 allocations as instruments of US control. For China, Japan and many EU nations, IPv6 is really about no less than who will control the future of the Internet.

3. IPv6 has already succeed.
   You can now get native IPv6 from many providers, including Verizon, Tata (formerly VSNL/Teleglobe), Global Crossing and others. Over half of surveyed providers say they have plans to roll out commercial IPv6 offerings in the next year. As more vendors integrate IPv6 into their products lines, the ISP IPv6 tax has correspondingly dropped. For many, IPv6 comes with latest refresh of hardware which ISPs generally amortize over 5-8 year periods. While it will be many years before the millions of embedded end devices support IPv6, your backbone routers likely already do.Most encouraging of all, there is finally the beginning of real IPv6 content. Or at least you can now use IPv6 to search content (as long as the indexed content is IPv4). At the Philadelphia IETF this year, Google announced support for production quality IPv6 search at ipv6.google.com.

 

4. And the final reason IPv6 will succeed?
   No one has the stomach to spend another twenty years replacing IPv6 with something else.

Personally though, I just configured our local router for IPv6 so I can watch Michael Phelps (former University of Michigan athlete) win eight golds this week at http://2001:252:0:1::2008:6.

Full disclosure — I worked on the failed TUBA counter-proposal to IPv6 and still harbor a grudge.

As an Air Force Academy cadet I was taught a training philosophy for developing subordinates. It used a framework of Expectations - Skills - Feedback - Consequences - Growth. This model appears in documents like the AFOATS Training Guide. In that material, and in my training, I was taught that any problem a team member might encounter could be summarized as a skill problem or a will problem. In the years since I learned those terms, and especially while working in the corporate sector, I've learned those two limitations are definitely not enough to describe challenges to getting the job done. I'd like to flesh out the model here.

The four challenges to getting the job done can be summarized thus:

1. Will problem. The party doesn't want to accomplish the task. This is a motivation problem.


2. Skill problem. The party doesn't know how to accomplish the task. This is a methods problem.


3. Bill problem. The party doesn't have the resources to accomplish the task. This is a money problem.


4. Nil problem. The party doesn't have the authority to accomplish the task. This is a mojo problem.

I have encountered plenty of roles where I am motivated and technically equipped, but without resources and power. I think that is the standard situation for incident responders, i.e., you don't have the evidence needed to determine scope and impact, and you don't have the authority to change the situation in your favor. What do you think?Copyright 2003-2008 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)noreply@blogger.com (Richard Bejtlich)

On good authority I was told to take a good hard look at the newly proposed HTML 5.0 spec that’s floating around the WHATWG. Firstly my eyes went to the new video and audio tags which are meant to help users deal with the apparently confusing nature of the fact that we have img tags instead of just using embed for everything. Personally I think that’s just a horrible idea that’s going to break a lot of blacklists out there and potentially open more security holes depending if the scriptable video objects are allowed, but there you have it.

Anyway, so then my eyes glanced across the new iframe spec and lo and behold I saw a miracle. Someone over at the WHATWG was really paying attention. Firstly, there’s a new parameter called sandbox which is similar in many respects to IE’s proprietary security=”restricted” parameter but with more granular controls. That’s not necessarily a good thing if you don’t like being framed, but it does give websites more control over what happens to their site once they frame a site that turns out to be bad.

But more importantly there is another new parameter called seamless which will allow a page of the same origin domain to iframe a page without having all the usability issues (double scroll bars, _self targets and so on) of the original iframe model. That’s great news for websites that want to frame and control a page on their own domain (a la content restrictions) without all the crazy usability issues with iframes. There’s some other security concerns with allowing content to be accessible on your site - there needs to be some tag to disallow rendering unless it’s embedded within an iframe to prevent someone from calling the malicious child frame directly. However, this is a big step forward in the right direction.

Volatility 1.3 is out! Volatile Systems (AAron, et al.) improves upon their venerable open-source memory analysis tool with this latest version, adding capabilities for extracting executables and a process's addressable memory, support for formats other than a dd-style memory dump (such as via mdd). Volatility 1.3 supports memory dumps from Windows XP SP2 & 3, and in addition, there is preliminary support for Linux memory dumps, as well.

The world of incident response is seeing changes. Incident responders have known for some time that particularly in the face of state notification laws and compliance standards from regulatory bodies, a new dimension has been added to what we do. Simple containment and eradication...get the bad guy or malware out...is no longer sufficient, as traditional first response obviates an organizations ability to answer questions about data exfiltration. Its long been known that new procedures and methodologies are needed, and in many cases, new tools. Well, folks, Volatility is one of those tools. When combined with tools like F-Response, the speed of response is maximized, allowing for greater data protection and business preservation. With F-Response increasing a responder's ability to collect data, and Volatility increasing the breadth and depth of analysis that can be performed on the memory dumps, a brave new world is opened up for incident responders!

The need for speed (without sacrificing a thorough and accurate response) is further illustrated in this SecurityFocus article, which illustrates something that incident responders and forensic analysts see all the time...AV doesn't always work the way we think it should.

Not only that, Volatility adds to a forensic analyst's toolkit, as well. The latest version has the ability to parse crash dumps, as well as hibernation files. Thanks to Moyix for all of his current and up-coming contributions, as well as folks such as Matthieu, Jesse, and all of those who put effort into the framework. Forensic analysts now have the capability to parse through and analyze additional historic remnants on a system.

Volatility requires Python, which for Windows systems is freely available from ActiveState.


Addendum: Yesterday, Matthieu updated both win32dd and the Sandman Framework. I tried out win32dd, and it worked like a champ! My first attempt resulted in some issues as a result of operator error...if you hit Ctrl-C while win32dd is running, you will get an error during every consecutive attempt to run the tool again, until you reboot. However, one of my tests as to run mdd and win32dd consecutively, and the result was files of identical size. The next step is to run Volatility 1.3 against each of them and see if there are any differences in results.