Microsoft to Publish Blue Hat Findings
An anonymous reader wrote to mention an InfoWorld article about Microsoft's plan to publish some of the findings from last week's Blue Hat conference. From the article: "'Everything was fair game,' wrote SQL Server engineer Brad Sarsfield in a blog posting. 'Hearing senior executives say things like: 'I want the people responsible for those features in my office early next week; I want to get to the bottom of this' was at least one measure of success from my point of view for the event.' The Blue Hat name is a play on the Black Hat conferences, which have occasionally been criticized by IT vendors. The 'Blue' part comes from the color of badges that Microsoft staffers wear on campus." They have descriptions of some of the sessions up on the site for your perusal.
Could MS actually be taking security seriously?
/ 1750217&from=rss and other notables. I'm curious if MS will ever really look at what it is that causes so much to go wrong with their departmental OS.
Naaahh...
I'm sure this was a very interesting conference - nice to see names like Johnny Long there ( Google Hacking for Penetration Testers ) http://books.slashdot.org/article.pl?sid=05/04/11
All the same, I'm sure the findings will be taken back, discussed among those who know and forgotten or buried by marketing executives.
The Kai's Semi-Updated Website Thingy
And maybe they want to make sure when everyone thinks "$color hat" they *don't* think of "Red Hat".
MS plays that sort of game a lot.
This is a pretty standard way for companies to handle lynch mobs of unhappy people: Put an exec up on a stage and have everyone yell their guts out and promise to investigate it thoroughly. This is not done just for software security, but just about everything.
Undoubtedly one or two simple, yet highly visible, things (eg. the password check) will be fixed to show that some action was taken.
Engineering is the art of compromise.
I enjoy a good Microsoft bash (oh lololo m$ nevar innovates!!1!)
Good to know.
but your comment tells me you have probably no idea how commercial software works.
I'm not quite sure how this statement follows from your first. Do you like a joke or not? Maybe, just maybe, I was only joking?
The key is that it's an option that you (as the DB admin) can choose to turn off. The MySQL root account will also run with a blank password when you first install it from, say, Synaptic. It's up to you to tighten it down.
The reason why the root/sa passwords start blank is so you can configure the server immediately after installation. Using a default username/password of some sort (ala Oracle) wouldn't change the security situation to any appreciable degree, and only serves to force the DB administrator to look up the default every time he does an installation. (Which is likely to be rare enough to prevent him from memorizing it.)
Yeash. Way to spoil a joke.
Javascript + Nintendo DSi = DSiCade
Large company actually paying attention to what it's seeing
yes we can all feel cynical based on many other similar stories.
but every now and again a company will surprise it and attempt to actually <i>solve</i> problems.
A lot of Microsoft's problems date from interesting "for the user" support features. This could be interesting to follow...
(can you tell I've just been watching Red Vs Blue?
I do hope that nobody actually paid for this news.
guh.Free Software: Like love, it grows best when given away.
'I want the people responsible for those features in my office early next week'
I recall maybe 8-9 years ago at my large former employer. There were some screw-ups going on coming from an IT subdepartment at corporate headquarters. After trying in vain to work around things on my end I finally picked up the phone and called up the person in charge. Before I could launch into my tirade the person said, "I'm in charge, but I'm not responsible." Reminds me of what will happen Monday morning amidst the chair-littered corridors of Redmond. Lots of finger pointing and ducking...
Not that weird. Yes, every other browser/client/server supports it. IE still has comfortably more than half of the browser market, even though it's in decline. So, if the NSA can't break AES, they ask M$ not to put it in, and a large chunk of the traffic remains readily readable.
"But," you may say, "anyone who knows what they're doing will use something more secure." True. However on one hand, crooks and terrorists are often (albeit not always) stupid, and might not always do so; and on the other hand, the easily broken traffic can be quickly sorted out, leaving a smaller quantity of harder-to-break traffic where content analysis is neglected but traffic analysis approaches become profitable. Limiting the capabilities of the drooling-luser set is helpful, because it makes it easier to pick out the bad guys who hide by leaving a smaller set of both the good and the bad guys who can hide. Rather than struggling to separate all the good from the bad, they can first quickly separate the smart from the stoooopid.
Of course, there's no proof the AC's assertion is true... but it doesn't matter much for the sake of arguement.
//Information does not want to be free; it wants to breed.
People do things for reasons. Hammering them for things that turn out badly just produces CYA, fear and paralysis. Red in tooth-and-claw management always devours itself.
Process? When I think "process", I think IBM. Process stifles innovation. Yes, you need a balance between process and wrecklessness, but process isn't the answer. Seriously -- what talented, creative devs want to walk into a place where they have to produce 10 lines of documentation for every line of code? Nobody -- that's why startups are cool and MS, Google, and Amazon still try to retain a startup culture.
If Microsoft is so serious about security, could they please start by bringing their logging out of the dark ages and to what has been available on UNIX for some times. A UNIX system will log the difference between a bad username and a username with a bad password to the auth.error or auth.info facility, even if it delivers the same generic "Bad username or password" message to the user trying to log in. That's the information Windows actually logs, which makes realtime security monitoring a joke if you're looking to determine if someone is grinding through usernames or actually trying to brute force a password for a single account with a realtime security solution.
It would also be nice if MS SQL server actually logged the remote IP/hostname of failed SQL sessions for SQL standalone authentication. When some user tries to violate policy by attempting to log in as the Admin user in the DB and then fails, I can't go correct the problem. It makes auditing access impossible if shared accounts are used (they shouldn't, but it still happens, even when people should know better).
Remember the Alamo, and God Bless Texas...