• Microsoft Windows Vista
• Microsoft Windows XP SP2
• Red Hat Enterprise Linux Desktop (v. 5 client)
• Red Hat Enterprise Linux WS (V. 4)
• Ubuntu 6.06 LTS Desktop
• Apple Mac OS X 10.5 (Leopard)
• Apple Mac OS X 10.4 (Tiger)

For January through March of 2008, Mac OS X users experienced the highest number of vulnerabilities as well as the highest number of High severity vulnerabilities while Windows Vista users experienced the fewest and the fewest High severity vulnerabilities.

Here is the chart breaking down all of the OSes by NVD severity ratings:

Download the attached paper for full details.

Share this post :

So, what catches your eye first? Despite the fact that I was trying hard to list most of the tools that collect Windows logs known to humankind (and certainly, I thought I included ALL of the popular ones), response 'Other' is #1 by popularity. Now, the 'Other' option had a write-in field that is not visible online, but accessible to poll owner (i.e. me). What  dark and mysterious tool hides in there under the guise of 'Other'?  Well, this is where the controversy lies: out of 37 people who chose 'Other', 15 wrote in 'sp1unk.' Now, given that the Windows version was released only a couple of days before my poll, I refuse to believe that.

Second, as one can guess, using Snare agent for converting Windows event logs into syslog is the next popular (after 'Other'). This is definitely what I expected. Snare is a safe choice that everybody knows (but it is an agent)

Third, 'voting "no"' (i.e. 'We don't collect windows logs centrally') is next; in fact, it is not statistically different from the previous choice: Snare. This reflects the sad reality of Windows logging: people just do not collect them and then, when needed , they try to desperately reach for the logs stored on each server (and, obviously, often not finding them there). Will Windows 2008 (which does have its own WS-based log centralization system) change that? Probably!

Fourth, despite the fact that everybody hates agents, remote Windows collectors, such as ProjectLASSO, are less popular. In fact, most people who use a remote collector, use a commercial (WMI- or RPC-based) remote collector from their SIEM or log management vendor.

Fifth, OSSEC rises above the crowd of other remaining tools. This is definitely an interesting discovery as well.

Finally, on a somewhat humorous note, if one combines "We don't collect Windows logs centrally", "We ignore Windows logs" and "We are waiting for Windows to support syslog natively", the total count will reach 35% times and will exceed any other option, including 'Other', Snare, etc.

So, this poll reflects a sad state of affairs with Windows logging; let's hope that W2k8 will change that...

These are a rather concise set notes that I've taken while looking over his code more closely. I created a wiki page to quickly hack up this list. Here's what it looks like now:

• Fx helps you implement a custom STS
  • STS can issue managed cards (see below)
  • Fx provides a base class for your STS, (it's currently called SecurityTokenService)
  • You derive from this base class and supply a "ScopeProvider" implementation which answers (at least) two questions:
    • What type of claims your STS can issue (you have to generate a list of claim URIs that you will be issuing)
      • This is helpful for issuing managed cards, which need to specify which claims an IdP supplies
    • What claims should be issued for a given user request, which consists of:
      • Information about the target relying party (AppliesTo), which is not always known (an auditing STS will know this, for example)
      • The AuthorizationContext for the user requesting the token (this gives you the incoming set of claims from the user)
      • The actual RST if you want to look at it (this is a WS-Trust thing)
      • The issuer's credentials (you need this to generate the claim set)
  • User authentication methods (an STS needs to authenticate the user before issuing a token)
    • Kerberos
    • X509 Certificates
    • SAML from personal cards
    • Username/Password
• Fx helps you expose your STS using WCF
  • Fx supplies a custom ServiceHostFactory (currently called WindowsInformationCardServiceHostFactory)
  • This allows you to create a .SVC file for a WCF endpoint to expose your STS
• Fx supplies an HttpModule for the traditional ASP.NET authentiation pipeline
  • According to Vittorio, this "automates a lot of the validation work in the framework". It's called FederatedAuthenticationModule, which gives a hint as to its function. It probably sets up HttpContext.User like a traditional authn module would. It's probably not specific to building an STS (remember the Fx is also used to build relying parties)
  • There's a custom config section that configures this module. Vittorio uses it to say, "use my SSL cert as my relying party cert". This is probably required in case the client wants to authenticate using a card.
• Issuing managed cards
  • Fx provides a function to generate a managed card, as well as a class that represents it (it's currently called InformationCard)
    • You can specify the default name and image for the card you issue, controlling what the client sees when she installs your card
    • Fx provides an information card serializer: InformationCard<-->XML (this is what the user installs into her identity selector - an XML representation of the card)
• Fx provides a utility to generate a PPID, which is a pretty complicated task!
  • Currently takes three inputs to gen a PPID for the relying party to use:
    • Client's AuthorizationContext
    • The relying party (AppliesTo)
    • Issuer's credentials
• Fx provides some helpers for reading claims from an AuthorizationContext
  • I notice a ClaimsContext class that allows you to write code like I show below, although I'm not sure how it figures out how it deals with multiple ClaimSets.

string email = myClaimsContext[ClaimTypes.Email]

• Fx provides a set of ASP.NET login controls (three right now):
  • FederatedPassiveSignIn (I'm guessing this is for doing traditional ADFS v1 style logons)
  • InformationCard (login control that accepts information cards)
  • SignInStatus (probably similar features to ASP.NET's LoginStatus)
• Fx helps you build relying parties
  • InformationCard login control
    • You can specify whether you want to accept personal or managed cards
    • If you accept managed cards, a wizard will take a card file as input to automatically configure the control (great idea, guys!)
    • Wizard shows claims supported by the managed card, and you can select which ones you want (either optionally or required)
    • There appears to be a SignInMode that you can use to establish a session. I'm guessing that this issues an ASP.NET Forms logon cookie or something equivalent. This is probably one of the things that the HttpModule deals with (reading that cookie and using it to configure HttpContext.User).
    • Here are the control's identity-related events:
      • SecurityTokenReceived
      • SecurityTokenValidated
      • SignedIn
      • SignInError
    • Here's a picture Vittorio shows that shows a number of the properties of the control if you want to try to guess more about what it's going to do: