RE: Cross-Platform Log Analysis and Microsoft
Eric Fitzgerald <[email protected]>
| Newsgroups | gmane.comp.sysutils.loganalysis |
|---|---|
| Message-ID | <74735BF202608043B11025A9FAA9438906CFE98A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> |
<ducking to avoid laser beams> mjr wrote: > But it doesn't suck as bad as an "enterprise operating > system" that is deployed on 99.99% of the computers on earth, which was > apparently designed by such retards that they couldn't have taken the time > to add such a trivial capability about 10 years ago. Hi Marcus, I know that many, perhaps a majority, in this forum would like Microsoft to drop eventlog and just put a syslog agent in Windows. Based on what I know of Microsoft's business interests, technology investments and decision making process I do not believe that is going to happen, but it's not my decision nor has it ever been. In the technologies with which I have been associated and with which syslog might have been appropriate, syslog was always considered- and rejected. It's not that it didn't occur to us- we're neither stupid nor ignorant of the industry- it's that it didn't meet our decision criteria, which primarily were based on our management strategy and secondarily on security. Regarding security, it doesn't matter if the whole rest of the world uses telnet, SNMP and syslog for management, Microsoft cannot afford to. In spite of having one of the best track records in the industry for the last several years we are still often the example held out for scorn, even by you (I read SANS NewsBites and your web site; my coworkers and I especially liked the commentary regarding the lack of an import function in Software Restriction Policy). Instead we use newer protocols with the security characteristics we desire designed in. It's simple- we are the ones wearing the bulls-eye on our t-shirts, well-deserved or not, because you and other security professionals put it there. To say that we are now risk-averse would be putting things mildly. Syslog has an attack surface we are unwilling to tolerate in a management protocol. Others (many others) may make that trade-off. We can't. Regarding management strategy, it's not exactly my idea of fun going into a meeting with my VP and trying to explain to them why they should spend dev resources on a feature whose sole purpose is to enable their Microsoft product to be managed by *nix systems. They tend to ask questions that make me uncomfortable, and that I don't have good answers to (surprisingly enough, *nix datacenter shops do *not* account for most of our revenue). My managers tend not to give me promotions and big bonuses when I have meetings like that. Oddly enough I don't recall ever hearing a "go ahead" answer out of a meeting like that either... We DO support standards-based event forwarding in the Windows platform. In Windows Vista and future releases we support WS-Eventing and WS-Management for event subscription management and event delivery to and from Windows systems. These are standards that we participated in but which we do not control, and which are publicly documented. Microsoft's published protocol interoperability strategy moving forward is primarily with web services protocols: http://www.microsoft.com/presspass/press/2005/feb05/02-08IndigoHighlight sPR.mspx http://msdn2.microsoft.com/en-us/library/ms731082.aspx You can find the WS-Management specification on the DMTF web site and the WS-Eventing specification on OASIS' XML/SOAP web site. http://www.dmtf.org/standards/wsman http://schemas.xmlsoap.org/ws/2004/08/eventing On Vista, you can set up event forwarding right in the Event Viewer tool: http://technet2.microsoft.com/WindowsVista/en/library/4aa6403f-d4b8-43a4 -a70d-ceb7f88c524e1033.mspx?mfr=true We do support syslog in our management products- Operations Manager (aka MOM) and Configuration Manager (aka SMS) Servers. http://support.microsoft.com/kb/555450 However, our support for syslog is not what you are looking for. Since Microsoft is in the management products business, we design our management products to manage devices which emit syslog, and since our platforms have adopted a non-syslog event technology strategy, we usually do not design our products to be managed by emitting syslog, although occasionally we do. Most of our products are designed to be managed by Microsoft platform management technologies and those technologies are all documented in MSDN, freely available on the Microsoft MSDN web site, open to any vendor who chooses to adopt them, so we're still open to being managed by third party products. Now there are other things that I'm much more sympathetic to- configuration options that don't work, events that don't occur when they should, events that are missing information that reasonably they should contain, lack of documentation on events, etc. I'm very willing to listen to and route feedback of that sort since we don't have a formal channel for that sort of thing. I can't do anything about lack of syslog support in Windows though. I agree completely with the principles behind the upcoming MITRE effort and I hope to have a productive discussion there. Best regards, Eric