First Response from...
 
Notifications
Clear all

First Response from Mandiant

10 Posts
4 Users
0 Likes
493 Views
(@jsawyer)
Posts: 35
Eminent Member
Topic starter
 

First Response will be released on Feb 28, 2005. It is designed to allow you to get volative information remotely from potential compromised hosts. Unlike tools such as WFT and FRU/FSP, First Response can run as a service so it could be deployed throughout your entire organization before an incident occurs (yes, the others _could_ be deployed but they aren't centrally manageable). I have seen Kevin Mandia's presentations from DoD and Shmoocon about his companies methodologies and expectations of the tool. It looks good so far, but we will find out for sure on Feb 28.

I am wondering a couple of things, though How will it handle rootkits? Will it succumb to the typical issues that tools have with rootkits hiding files and ports from it? Will they have a feature to dump memory? What is the authentication like between the console and agent so the agent isn't exploited? And, how long before viruses and rootkits start adding in detection for the agent?

That's a lot of questions, but I am very excited about the tool and hope it is actively developed my Mandiant.

 
Posted : 23/02/2006 12:22 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

I dropped by the new Mandiant.com site and took a look…it looks interesting. I especially like the new tool, First Response, but I also think that mentioning WFT and FSP is an apples-to-oranges comparison.

In addition to your questions (which are all good ones, btw), one has to consider the deployment issue…if it's installed as a centrally managed service, then it must be either pre-installed, or one has to take into account that files need to be written to the drive and updates made to the Registry (if installation is performed post-incident).

Not a criticism, b/c I haven't seen the tool yet, but just something to keep in mind.

 
Posted : 23/02/2006 3:55 am
hogfly
(@hogfly)
Posts: 287
Reputable Member
 

Hrm, windows only incident response. I'll reserve judgement for later, but that seems a little limited right out of the gate.

 
Posted : 23/02/2006 6:59 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

How is providing a product for Windows-only IR "limited"?

FYI…the FSP isn't limited by os at all…

Harlan

 
Posted : 23/02/2006 8:30 pm
(@jsawyer)
Posts: 35
Eminent Member
Topic starter
 

Hrm, windows only incident response. I'll reserve judgement for later, but that seems a little limited right out of the gate.

Can you elaborate on that comment? If you look at the incident response field, 90+% of it is geared toward Windows because of market share. It's what end users use and get infected/compomised while using it. I bet if you were to look at the statistics of OS's and software discussed in this forum, Windows would dominate it.

I especially like the new tool, First Response, but I also think that mentioning WFT and FSP is an apples-to-oranges comparison.

I disagree as to them being apples and oranges. They all are designed for incident response. First Response just takes what WFT and FSP do a little further by making it a pull technology instead a push when installed as a service. Fundamentally, they do the same things.

HOWEVER, First Response looks like it is not as configurable and extensible as WFT and FSP. If they could make it super customizable like the other two tools, then it would probably win my vote. Unfortunately, it looks like it is going to fall into the corporate help desk category where you end up with monkeys pushing buttons and gathering information for a incident handler to analyze.

In addition to your questions (which are all good ones, btw), one has to consider the deployment issue…if it's installed as a centrally managed service, then it must be either pre-installed, or one has to take into account that files need to be written to the drive and updates made to the Registry (if installation is performed post-incident).

From what I have seen, you can install it before as a service or run it when you get to the scene. Note, that I said "run it" and not "install it" when arriving on the scene much like WFT and FSP. In the pre-installation scenario, it could be deployed via AD and be ready to tap for information in case an incident arises. In the crime scene scenario, you run it and either push/pull information to the IR/forensics console.

I think the tool will be useful and effective for quite a few people but I don't expect it to be to the caliber that we, on the forum, expect or really desire. Huge thanks go out to Harlan and Marty McDougal for developing FSP and WFT.

 
Posted : 24/02/2006 12:20 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

While I completely agree that the vast majority of the desktop operating system market share goes to Windows, I don't think that the incident response field is really all that geared toward addressing the issue of Windows.

Let's look at a couple of things…and these are purely my own opinion…

- Most security-minded folks seem to come from a *nix background.

- The default behaviour for Windows admins when a potential incident/problem is discovered is to wipe the o/s and reinstall from clean media.

- There are very few resources that discuss in any detail how to retrieve information from a Windows system (live or post-mortem), or how to analyze the data once you've retrieved it. On the other hand, there seems to be a great deal of documentation (primarily open source) with regards to *nix platforms, and in particular, Linux.

With regards to the FSP in particular…the thing I like most about it is that it isn't platform-specific. The source is Perl, which means that it can run on any platform that supports Perl. I do need to create modules for the components, but as it is now, the FSP code will run on any platform (with minor mods for file path separators, etc). The FRU is not platform-specific either…once I create the necessary Perl modules, I'll incorporate writing to a thumb or mapped drive instead of to a socket.

Harlan

 
Posted : 24/02/2006 2:44 am
(@jsawyer)
Posts: 35
Eminent Member
Topic starter
 

There are very few resources that discuss in any detail how to retrieve information from a Windows system (live or post-mortem), or how to analyze the data once you've retrieved it. On the other hand, there seems to be a great deal of documentation (primarily open source) with regards to *nix platforms, and in particular, Linux.

Agreed, but I think it is because
- *nix machines have been getting owned much longer than Windows systems
- *nix admins want to fix things while Windows admins are content to rebuild
- *nix always had the great scripting languages to write open source tools for incident response with. Hardly anyone released anything to do IR on Windows before Perl was available and you started releasing things as carvdawg
- in my experience, *nix people just document things better than Windows people
- Windows programmers and companies tend to want to make money when they write software. *nix people do it because they are hackers at heart and want to give back to the community.

*nix people and Widnows people are simply different and that is what has led to the difference in content between the operating systems. *nix people say, "It's acting weird. Why? Let me tinker around and figure it out." Windows people say, "It's acting weird. Reboot. It's acting weird. Reboot. It's acting weird. Rebuild."

 
Posted : 24/02/2006 3:27 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

Well, for whatever reason, the fact remains that this is how things are…

 
Posted : 25/02/2006 1:40 am
(@mtpepe)
Posts: 2
New Member
 

HOWEVER, First Response looks like it is not as configurable and extensible as WFT and FSP. If they could make it super customizable like the other two tools, then it would probably win my vote. Unfortunately, it looks like it is going to fall into the corporate help desk category where you end up with monkeys pushing buttons and gathering information for a incident handler to analyze.

Hello! I can tell you that FR is exceedingly customizable due to the manner in which the framework was developed. The difficult element is that to take advantage of the latitude that is given, one must create objects from a compiled language - a slightly higher barrier to entry than Python/Perl/etc. I believe that more information will become available later on this topic, but you are welcome to ask about it over at forums.mandiant.com.

As a side note to your 'monkeys' comment, the vast majority of the audience that this tool is aimed at are looking to do exactly that. You may be surprised to see those survey numbers! )
On the other hand, it is extensible enough to make me happy - and I'm an old-school batch/shell scripting type.

– Matt

 
Posted : 06/03/2006 4:48 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

Matt,

> …it is extensible enough to make me happy…

Would that have anything to do with your employment? 😉 Just kidding. Good to see you on the board, and I hope to see more.

Harlan

 
Posted : 06/03/2006 5:14 pm
Share: