how-to block ads
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
1 edit | SecSummit notes for Thursday
Today is Thursday, so the name of the thread is wrong, but I'll keep my realtime notes here.
Edit - it's clear that I can't tell the diff between "New thread" and "Post reply" in a pre-caffeine state. Duh.
"WCS and LUA in Longhorn"
A long-running topic/rant/whine has been "Why do we have to run as Admin?", and this goes on within Microsoft as well as from the outside. The LUA - Limited User Account - concept in Longhorn is designed specifically to address this. We've been waiting all week to hear about it.
He did ask for a show of hands: who is running as local admin right now, on our laptops. Almost all of the hands went up (including mine). It's just hard, and at this point we've heard all the reasons why this was the case. "Legacy of Win95", "Programmers were sloppy", "Customers didn't care", etc. Blah blah blah.
Longhorn is addressing this in a very, very big way, and it goes down to the WCS (Windows Core Security). Rather than just be "a user" (admin or not), most people will run as limited users with rights to elevate for specific purposes.
XP has SFP - System File Protection - which essentially makes it hard to remove a core OS file in the WIN32. If you try, it gets reloaded from a hidden area or from the CD. It's an after the fact protection.
Longhorn will provide WRP - Windows Resource Protection - that intercepts the calls in the first place: you can't replace a protected file, and this will be extended to other things like registry keys. It's much more proactive.
There looks to be a substantial hierarchy for application compatibility: some apps will be specifically designed for Longhorn, some are "almost" compliant, and so on. I'm a little fuzzy on the details, but it looks like they're really making some steps to get this right from a security perspective.
A Microsoft term that comes up now and then: "Customer Pain Point".•Viruses & Spyware wreck my machine.
•Line of business applications require Admin (Quickbooks)•Common OS configuration tasks require admin (install fonts) Ugly trivia
The calculator will not let you save "scientific mode" as a non-admin user. This legacy application saves its settings in WIN.INI (!), and this file lives in an SFP-protected directory. Hence, admin is required to save this change. Yuck.
Fonts require admin to install, but because they contain executable code, it's not quite so simple as to simply make the FONTS directory writable. Likewise with printer drivers.
One of the visions is to provide a "trusted font/driver store" that a limited user is allowed to install from, because the drivers/fonts are known to be "safe".
One of the "pain points" referred to some very large customers (> 100k workstations) that tried to go with XP but could not, because all of the work required to get the line-of-business applications working (file & registry permissions & the like) was just too hard. One gave up after spending many tens of millions of dollars.
Ouch.
They're trying to simplify the whole user hierarchy: they want "Admin" and "User" - no more "Power User".
A fair discussion took place on the control panel: the mere act of opening the control panel actually executes code (this is before you've actually opened one of the applets). The user interface should be separate from the code that does whatever is doing the controlling.
In Longhorn, all users run as NonAdmin by default, and real admins have a restricted token with a "elevation potential" bit set. So you're not running with admin permissions even if you're an admin.
Applications can be marked "runs elevated", which smells to me as kinda like the UNIX concept of "set-user-id". This should NOT be a hack to replace "writing the software correctly", but things like "add a user".
When a limited user wants to run this application, several things could happen:
1) it says "are you sure you want to do this as admin?"
2) demand admin password
3) it's not allowed
They are going to harden the UI (user interface) so the dialog boxes can't be gamed by badware that pretends to click on the user's behalf. This will break, for instance, "Visual Test", a GUI testing tool.
There are provisions to limit applications which can be launched:•Only run 'allowed' application" (defined in various ways)•Only run Longhorn applications•Run only software from trusted publisher Presumably, manipulation of this list is only done by an admin.
Side note: it seems that Canadians are dispropriately represented in Microsoft, at least those that have talked to us. Cool, eh?
They want to enable third-party trusts, so that you can have a "Good Housekeeping" seal on software, and allow all software like that. This seems like something particularly useful for parental controls - "My kid can install anything that {so and so} says doesn't contain age-inappropriate stuff" I hope Kazaa is not on the list 
Right now, people who are legitimate admins are still supposed to have a second, non-priv'd account to run from, but this is painful. Even putting aside login/logout issues, there are all kinds of cases where you install software as admin, but the preferences are stored in the Admin's per-user registry area, so running that application as "yourself" doesn't get your prefs.
With Longhorn, this will be (somehow) reconciled so that both of your accounts are "the same user" pointing to the same branch in the user registry area. This looks fantastic.
Much of this is still in development, but it's encouraging.
Next: Passwords
--
Stephen J. Friedl • Unix Wizard • Microsoft MVP • Tustin, California USA • my web site | |
Cudni
La Merma - Vigilado
Premium,MVM
join:2003-12-20
Someshire |  Thanks for taking time to summarise, rather well, what happens in a day. Good read
Cudni | |
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
"Windows Passwords"
This was done by Jesper Johansson, the really friggin' smart guy who gave us a great demo back at the Global Summit in April. It went very fast, and I could not possibly capture all of this.
Initially passwords were used really only to keep users apart, not so much for security (this is a long time ago!).
LM "Hash" generation: take a password, pad to 14 chars with NULs, convert to upper case, and split into two 7-character strings (e.g., "split a good long password into two crappy short ones".
Example: "Seattle1" -> "SEATTLE" + "1______"
Each is "hashed" independently, and this is really insecure for a long list of reasons.
NT Hash Generation
This is a better mechanism: the password is hashed directly and stored, and it doesn't have the same silly restrictions (it preserves case, doesn't limit to 14, etc.). It's still not hashed.
Number of up-to-14 char pass w/ limited chars: 4.6x10^25
Number of up-to-14 char pass w/ full charset: 2.7 x 10^67
Number of 127-char passwords: 4.9 x 10^611
The latter is technically known as "A really big number".
Cached Credentials Generation
When you logon to your domain controller, you get credentials that say what you are allowed to do on the dcmain. But when you take your laptop on the plane and want to logon, you probaby don't have access to the DC, so how does it let you login?
This is done with cached credentials: your successful logon is remembered:
( Unicode password + machine ID + username + domain ) -> MD5 hash
Then the next time, your input data runs through the same code, and if the hash matches, you must be that person even if the domain controller is not reachable.
I don't know of any attackes on a cached credential, because you'd have to reverse two hashes, and that's just going to be very difficult.
How Passwords are used
He went through just how password authentication is done in Windows over the wire, but it's just a little bit too much detail for me to reproduce here. There is a whole range of variations on LM authentication (many of them not very secure, but backward compatible), and it looks very confusing. The matrix of what is sent, what is accepted, and who supports what is in a big, confusing matrix.
Did I mention "confusing"? It was a good overview, but it moved right along.
He pretty much skipped by Kerberos authentication, which I don't really understand anyway, but did note that the whining about how Microsoft was not "RFC compliant" was bogus, and I believe he's right. I'm going to dig into this.
How passwords get broken
Bad passwords get broken, even when using good storage and authentication systems. The problem is the password, not the hash or whatever.
About passive, online attacks, such as network sniffing, but this is getting hard when you consider that many networks have switches, not hubs.
He showed how an "SMB Reflection Attack", which is very clever but requires diagrams that I cannot reproduce here. I think this presentation has been given at TechEd:
Active online attacks: where you try to guess passwords online, and it's much more difficult. Sitting at a login screen and manually trying things, you're only going to get somewhere if the user has picked really bad passwords. It's also easily detected by competent admins.
There was much more, and I just ran out of ability to capture this...
Next session: Wireless security
--
Stephen J. Friedl • Unix Wizard • Microsoft MVP • Tustin, California USA • my web site | |
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
"Wireless Security"
The same fellow that talked about social engineering gave a presentation about wireless security.
A few people are really satisfied with their wireless security, a few simply don't care, but most were really concerned about things.
First: "WEP" (Wired-Equivalent Privacy) is a euphamism, and it does a really terrible job. WEP uses RC4 for the stream cipher (which is OK), but the implementation uses XOR (exclusive OR) and this enables a whole raft of statistical attacks on sniffed traffic.
The "Integrity Check" really has nothing to do with security in the usual sense: it's just about detecting transmissions errors. It doesn't do anything useful.
The "IV" (Initialization Vector) is supposed to increase the complexity of the encryption, but it's too small, and the counter simply gets reused. It's just dumb.
Generally speaking, "WEP just really sucks".
Debunking wireless security myths:
1) "I should disable SSID broadcasting"
2) "I should implement MAC address filtering"
Neither of these really provides any security (especially #1): it's trivial to spoof MAC addresses. Some have suggested that there is no harm
802.1X: a port-based access-control mechanism defined by the IEEE, and it actually works with wired and wireless networks. It's all about authenticatni and and access control, and though it still uses WEP, it fixes many of the flaws.
During 802.1X over 801.11, the client ("supplicant") hits the access point ("authenticator"): this starts a negotiation with the access point only (no IP traffic passes yet). The access point talks to an authentication server to make sure your password or certificate is correct.
The access point can be thought of as having two ports: the controlled port is used by the unauthenticated supplication (during initial exchange), and the uncontrolled port (once authentication is completed). It's really quite an exchange, and only when everything passes does the supplicant get access outside the access point.
EAP is the "Extensible Authentication Protocol", and it's a framework for doing authentication. There are a lot of options here that I don't really understand in any detail. "Protected EAP", TLS-EAP, etc. Google is your friend here.
He gave a section on "How a wireless station authenticates itself to the network", and he started with a list of the requirements (bad things we want to avoid).
He walked through the whole transaction, bit by bit, and showed how each thing addressed each requirement. It's a lot to study, and you really gotta want to.
Next was WPA - Wifi Protected Access.
Side crypto note
Part of the whole wireless security picture is "which encryption is used?", and it's pretty clear that 56-bit DES is not good enough for anything. But when picking your algorithm, always pick a known one.
During the competition for the AES (Advanced Encryption Standard), one of the things that helped the winner (Rijndael) was "thermographic spoofing". It seems that if one is monitoring the heat used by various parts of the CPU during execution, one can figure out what the key is. (Wow!).
The Rijndael algorithm apparently goes out of its way to make sure that while they're doing one thing "for real", they do some other calculations to mess up the heat. It's all very cool.
The rest of the presentation was very of details, and my mind is overflowing, but we're about to take off for afternoon sessions.
Maybe more later.
Steve
--
Stephen J. Friedl • Unix Wizard • Microsoft MVP • Tustin, California USA • my web site | |
psloss
Premium
join:2002-02-24
Alpharetta, GA
| reply to Steve
Re: SecSummit notes for Thursday
said by Steve  :Longhorn is addressing this in a very, very big way, and it goes down to the WCS (Windows Core Security). Rather than just be "a user" (admin or not), most people will run as limited users with rights to elevate for specific purposes. Still cynically: what did they say about doing this for XP?
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org | |
ghost16825
Use security metrics
Premium
join:2003-08-26
| reply to Steve
Re: "Wireless Security"
said by Steve :
Side crypto note
Part of the whole wireless security picture is "which encryption is used?", and it's pretty clear that 56-bit DES is not good enough for anything. But when picking your algorithm, always pick a known one.
During the competition for the AES (Advanced Encryption Standard), one of the things that helped the winner (Rijndael) was "thermographic spoofing". It seems that if one is monitoring the heat used by various parts of the CPU during execution, one can figure out what the key is. (Wow!).
The Rijndael algorithm apparently goes out of its way to make sure that while they're doing one thing "for real", they do some other calculations to mess up the heat. It's all very cool.
Related to this is Acoustic Cryptanalysis. A technical link of this is available here:
»www.wisdom.weizmann.ac.il/~tromer/acoustic/ | |
jig
join:2001-01-05
Hacienda Heights, CA
| reply to Steve
Re: SecSummit notes for Thursday
said by Steve :They are going to harden the UI (user interface) so the dialog boxes can't be gamed by badware that pretends to click on the user's behalf. This will break, for instance, "Visual Test", a GUI testing tool. arg. so they will have some kind of proprietary way of scripting guis, one that i might not ever have access to. they'd have to have something, cause MS testers aren't going to grow extra arms and fingers. i suppose they could test internally with the hardening turned off..
i actually use the older 'scriptit.exe' tool to batch operations that don't have a good supporting cast of cli switches. it might make life hard without that option. | |
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| said by jig : arg. so they will have some kind of proprietary way of scripting guis, one that i might not ever have access to. they'd have to have something, cause MS testers aren't going to grow extra arms and fingers. i suppose they could test internally with the hardening turned off.. This is a fair question, one I don't know the answer to, but from what we saw at the presentation, in this very limited box, there will simply be no avenue for shenanigans. This smells like "famous last words" to me, but I think Microsoft knows that they don't get to keep APIs hidden for very long.
But we'll all be dead before Longhorn comes out anyway said by psloss :Still cynically: what did they say about doing this for XP? We all asked about this, and I think I'd characterize the plan for XP as "we really do wish you good luck on that". I just don't see any plan by Microsoft to make this easier before Longhorn.
One way that all of us wanted is what I would call "shame the vendors", but the look of the blood draining out of their faces suggests that this won't happen in our lifetime. Microsoft simply cannot beat up on third-party software vendors.
That's our job
Steve
--
Stephen J. Friedl • Unix Wizard • Microsoft MVP • Tustin, California USA • my web site | |
VirtualLarry
Premium
join:2003-08-01
| reply to Steve
Steve, thanks for the excellent summary and writeup. That actually does touch on a few issues that I've been thinking of off and on.
said by Steve :He did ask for a show of hands: who is running as local admin right now As much as running as a "normal" user is supposed to be a "best practice" for security, I have to admit that I run as Admin 100% of the time here on my W2K box, simply because it's too hard to "get anything done" without it, including some hardware-priviledged tasks like CD/DVD burning, and development work. I'm sure it's probably the same reason with you.
said by Steve :Longhorn is addressing this in a very, very big way, and it goes down to the WCS (Windows Core Security). Rather than just be "a user" (admin or not), most people will run as limited users with rights to elevate for specific purposes. It sounds like they are effectively indirecting how priviledges work, and requiring manual intervention/authentication before those priviledge elevations happen, in order to perform certain tasks. Will that get to be annoying though, if they require manual authentication by the physical user each time a requested priviledge needs to be elevated? For example - I recently tried setting my firewall to prompt for a password every time that it needs to add a rule, and by golly, it gets quite annoying. I had no idea that I often created lots of trivial rules during my workflow. The downside is, if they simply require the user to click "Yes" on a dialog (even under a "protected secure UI domain", then won't most users simply start clicking "Yes" to everything? Doesn't that effectively reduce real security back down to where it was before, when priviledge credentials were always 'active' by default? Or is this going to be a subtle push towards users adopting MS's biometric hardware technology for auth?
said by Steve :XP has SFP - System File Protection - which essentially makes it hard to remove a core OS file in the WIN32. If you try, it gets reloaded from a hidden area or from the CD. It's an after the fact protection. Longhorn will provide WRP - Windows Resource Protection - that intercepts the calls in the first place: you can't replace a protected file, and this will be extended to other things like registry keys. It's much more proactive. This I don't quite understand. Surely, MS supports the security APIs necessary to protect a file from getting deleted/replace already. I swear that I've seen some file-replacements prohibited by W2K, but I suppose I can't be sure that they weren't simply detected and then overwritten immediately with the SFP backup versions. The event-log message seems to suggest that the file wasn't modiied. However, it would only matter if the system was rebooted after the "rogue" file was copied over, before being "corrected" by SFP, because the actual version of that DLL that was in RAM or being executed wouldn't be touched, only the on-disk image, AFAIK. Granted, if a piece of malware could replace the file and then trigger an immediate shutdown, that could be an issue.
said by Steve :They're trying to simplify the whole user hierarchy: they want "Admin" and "User" - no more "Power User". That's kind of interesting, actually, as MS used to tout the differences between their highly-granular NT security model as superior to *nix's root/user model. I guess the problem with the complexity of MS's model, is that it tends to not get properly used simply because of its complexity, and the *nix model is much simpler to both implement and use. (Kind of like how forcing a high password complexity metric on users causes them to just tape their random password to their monitors instead of trying to remember it.)
said by Steve :Applications can be marked "runs elevated", which smells to me as kinda like the UNIX concept of "set-user-id". This should NOT be a hack to replace "writing the software correctly", but things like "add a user". See, that's what I don't get - doesn't the NT security model, actually already provide for these types of security measures? (NT 3.51's much-vaunted "C2-level" security, etc.)
If application developers refuse to conform to the rules of platform security currently, what will make them do so with these new rules? I don't see much change there with the ISVs. Really, the onus should be on the app developers - if the app requires Admin to run, it's basically sort of broken. OTOH, MS has a history of bending over backwards for app-compatibility for their larger 3rd-party products, that bring customers to their platform, so I can see why they might implement something like this. (I'm thinking of CD-burning apps like Nero here, for an example.) Btw, wasn't proper conformity to NT's security architecture, part of the requirements for "Windows Logo" certification, at least at some point in time?
IMHO, what really needs to happen, is a very thorough security-domain analysis, both at the application level, and how it interacts with the system. Much in the same way as Bernstein's QMail, for another example. In the case of Nero, there would be the application UI, logic, caching system, and then the actual hardware-access portion of the app. The only part of the app that should really need any "elevated priviledges", is the burning thread task itself. So in this case, you would (at a minimum) segregate the app into two domains, one for securely talking to the hardware, and another for unsecurely communicating with the user, and have a defined "interface firewall" between the two. (Also, specifically speaking of CD-burning - one of the things that I think that MS really dropped the ball on, was providing a higher-level driver-model for CD-burning. Applications don't normally talk to the HDs at a block level, and implement the filesystem-access themselves - why should CD-burning apps be any different? MS was just slow to react to this space, and the ISVs gained the lead, and MS just lets them directly access the hardware instead. At least the SPTI interface filters block-device accesses aimed at the HDs, so that much is safe, although ASPI can easily be used to crash a system or bypass HD filesystem protections.)
said by Steve :They are going to harden the UI (user interface) so the dialog boxes can't be gamed by badware that pretends to click on the user's behalf. This will break, for instance, "Visual Test", a GUI testing tool. This is definately a Good Thing. The lack of such is primarily why current "security" features like the Security Center in XP SP2 are such a joke, because there is no "secure channel" between the user and the security app's UI.
said by Steve :There are provisions to limit applications which can be launched: •Only run 'allowed' application" (defined in various ways)•Only run Longhorn applications•Run only software from trusted publisher Presumably, manipulation of this list is only done by an admin. That seems unsurprising to me. MS has given indications in the past that they have intentions to close-off the PC platform with Longhorn, or some future sucessor, ala the X-Box (Signed application binaries, refusal to run any 3rd-party ones, etc.)
While that might be a positive feature for both corporate desktops, and one effective protection against rogue malware, it also would tend to further enforce MS's desktop OS monopoly as well. (I personally think that MS envies Nintendo's business-model, being able to charge a royalty to 3rd-parties for every piece of software produced for their proprietary platform - whether or not that software even sells to the customer. Their X-Box was their first foray into this, and you can probably expect future protection schemes to be much stronger.)
As far as the LM hash/NT hash stuff, sounds much like the same sort of presentation that Mudge gave about it at DC5, just before unveiling L0phtcrack to the world. It was an amazingly-detailed presentation but it was also flying by. I tried to pick out the high-level points as best I could, since I'm no crypto guru.
I'm not sure what the "SMB reflection attack" is, but I'm guessing, some way to induce Windows' to attempt to authenticate someone over the network, in order to obtain their hashes, to try to crack them?
As far as wireless security, that's about the only way that I could concieve of to make 802.11 connections relatively secure - have an unsecured link to the AP, that can be spoofed/sniffed all you want, but with impunity, and then have the actual, routable data connection, be implemented by a heavily-encrypted VPN solution. I'm hopeful that the WRT54G and WRV54G firmware might be able to be combined in some way to facilitate this, allowing wireless clients to make VPN endpoints to the AP, using AES encryption. (AFAIK, there is hardware AES128 support on the WRT54Gv2.) | |
psloss
Premium
join:2002-02-24
Alpharetta, GA
| reply to Steve
Re: "Windows Passwords"
said by Steve :He showed how an "SMB Reflection Attack", which is very clever but requires diagrams that I cannot reproduce here. I think this presentation has been given at TechEd FYI, someone has posted Jesper's presentation slides...if you Google on the phrase quoted above, you'll find it...
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org | |
CalamityJane
Premium,VIP,MVM
join:2002-08-27
Eustis, FL
| reply to Steve
We speak
Photos are in
This was on the last day of the Summit after the "work sessions" where the MVPs presented our final *wish lists* of things we would like to see MS improve. This presentation on behalf of the two IE groups was summarized by Susan Bradley and Blake (user=Link Logger). We each chose 2 groups according to our interest from the sessions available:
Consumer (this mostly encompassed: Malware, Spam & Phishing, one of my groups)
IE (the other of my groups)
MS Perception
Guidance
Report Back
MVP Program
Each group got to meet for one hour to hash out the topic with one or more of the MS team members and main points were decided on as a group and then written up onto a large list and taped to the wall for final presentation and discussion with afterwards with the MS Executives representing the listening Panel.
--
It takes a disaster to make a woman out of a female
Gladiator Security Forum
Proud Member of ASAP (Alliance of Security Analysis Professionals) | |
CalamityJane
Premium,VIP,MVM
join:2002-08-27
Eustis, FL
| reply to Steve
MS Listens
This was the MS Executive Panel who listened to each of the final group presentations. Rich Kaplan is the gentleman on the left, Corporate Vice President of the Security Business & Technology Unit. The lady on the right was the delightful and energetic Susan Koehler, Senior Director, Security Mobilization, Security Business and Technology Unit (she was present throughout the entire summit). I'm afraid I didn't make note of the names of the middle two....hopefully someone else in attendance may have (Steve or Blake, did you?)
--
It takes a disaster to make a woman out of a female
Gladiator Security Forum
Proud Member of ASAP (Alliance of Security Analysis Professionals) | |
CalamityJane
Premium,VIP,MVM
join:2002-08-27
Eustis, FL
1 edit | reply to Steve
Group Shot
At the end of the last day, we tried for a group shot with several MS team members using our cameras. Susan Koehler took this one with my camera. A few of us on the right hand side got cut off but this is most of us
I'm wondering about the one taken using Blake's camera? Blake you got that? (I'm hoping it came out better since his is a better camera)
Countries represented included: USA, Canada, England, Japan, Australia, Germany, Sweden (I think?), France....among others I can't remember, but it was definitely a global group of geeks
--
It takes a disaster to make a woman out of a female
Gladiator Security Forum
Proud Member of ASAP (Alliance of Security Analysis Professionals) | |
CalamityJane
Premium,VIP,MVM
join:2002-08-27
Eustis, FL
| reply to Steve
Heh, my escorts
To dinner on the first night. We went to a nearby Mexican restaurant on foot for margueritas and some great mexican food (Yum). Notice, I got the most handsome bodyguards any girl could wish for  | |
bcastner
Premium,VIP,MVM
join:2002-09-25
Chevy Chase, MD
clubs:  | reply to Steve
Re: SecSummit notes for Thursday
Just a great set of notes by Steve, Blake and Jane.
Thank you! | |
Khaine
join:2003-03-03
Australia | reply to Steve
Thanks guys for keeping us informed
It appears that microsoft really is taking security seriously
| |
CalamityJane
Premium,VIP,MVM
join:2002-08-27
Eustis, FL
| said by Khaine :It appears that microsoft really is taking security seriously Bingo! MS paid all expenses to get us there and utilized every minute to listen to what we had to say. They are working overtime to bring the level of security up in a very broad way, from prevention to remediation and consumer awareness. The stated goal is a shared commitment with the entire industry to helping consumers become more secure. They found that over 1/3 of all XP crashes reported in were due to spyware - that's over a billion and a half machines  It is also a top support issue for their partners - ISPs and OEM support calls, are also burgeoning under the staggering numbers of infected PCs of their customers. In addition to emerging malware threats, they are also tackling the issues of spam and phishing which also downgrade the users experience. I was pleasantly surprised to see the depth and commitement to all of these areas - yes, they are taking security seriously is an accurate statement.
--
It takes a disaster to make a woman out of a female
Gladiator Security Forum
Proud Member of ASAP (Alliance of Security Analysis Professionals) | |
PA Bear1
Premium
join:2004-06-06
Elverson, PA
| reply to Steve
As Lawrence Welk was wont to say, "Thank you, boys [and cowgirl]" for these informative posts on the summit. These threads have been passed on to others fighting in the trenches.
--
Robear Dyer, MS MVP-Windows (IE/OE), AH-VSOP | |
CalamityJane
Premium,VIP,MVM
join:2002-08-27
Eustis, FL
| Hi Robear ~waves~
Steve really did an exceptional job of recording everything to report back here. {applause}
The two other threads covering the other days are here FYI (if you haven't found them already)
»Microsoft MVP SecuritySummit thread
»SecSummit notes for Wednesday
--
It takes a disaster to make a woman out of a female
Gladiator Security Forum
Proud Member of ASAP (Alliance of Security Analysis Professionals) | |
PA Bear1
Premium
join:2004-06-06
Elverson, PA
| said by CalamityJane :The two other threads covering the other days are here FYI (if you haven't found them already) BTDT & looking for a T-shirt
--
Robear Dyer, MS MVP-Windows (IE/OE), AH-VSOP | |
|
