Reminder: Webinar today

This is a reminder that I’ll be giving a webinar today on managing SQL Server Agents jobs in a SQL Server Farm. Here are the details:

Webinar: Managing SQL Server Agent Jobs Across Your SQL Server Farm

On Thursday, September 8, at 3 PM EDT, I’ll be doing a webinar with MSSQLTips.com on handling SQL Server Agent jobs across your SQL Server Farm. This presentation is born out of my recent experience auditing shops that are using SQL Server Agent heavily and the clutter and confusion that can occur when proper management standards are not in place and enforced.

Register here for the webinar (free)

Reminder: #SQLChat at lunch today

This is a reminder that we’ll having a #SQLChat this afternoon at 12 PM EDT. Here are the details:

SQLChat: Do You Manage Multiple Servers?

On Wednesday, September 7, at 12 PM EDT (11AM CDT), we’ll be doing a #SQLChat covering managing multiple SQL Servers and how people handle dealing with a SQL Server farm. Everyone is welcome to participate. More information is here:

Do you Manage Multiple Servers? Participate in our September #SQLChat!

SQLChat on Wednesday, Webinar on Thursday!

I’m participating in two community activities this week. One is a #SQLCchat on Twitter and the other is a webinar through MSSQLTips.

SQLChat: Do You Manage Multiple Servers?

On Wednesday, September 7, at 12 PM EDT (11AM CDT), we’ll be doing a #SQLChat covering managing multiple SQL Servers and how people handle dealing with a SQL Server farm. Everyone is welcome to participate. More information is here:

Do you Manage Multiple Servers? Participate in our September #SQLChat!

 

Webinar: Managing SQL Server Agent Jobs Across Your SQL Server Farm

On Thursday, September 8, at 3 PM EDT, I’ll be doing a webinar with MSSQLTips.com on handling SQL Server Agent jobs across your SQL Server Farm. This presentation is born out of my recent experience auditing shops that are using SQL Server Agent heavily and the clutter and confusion that can occur when proper management standards are not in place and enforced.

Register here for the webinar (free)

 

I wrote a SQL Server auditing whitepaper!

I recently collaborated with Idera to produce a short whitepaper on the top 5 things to audit in SQL Server (database engine). You can grab it for free here (registration required):

Whitepaper: Top 5 Items to Audit in SQL Server

None of this is earth shattering. The whitepaper contains the the first set of things I look at when auditing the internal security of SQL Server. Part of what spurred this effort was a series of conversations I had with friends of mine who are internal auditors, developers, and system administrators who had been audited by an outside firm recently. The results provided by the outside auditors were less than satisfactory.

If you have an auditor come into your organization and he or she doesn’t cover these items, you probably aren’t getting your money’s worth. Really, these are the starting point and a good audit should cover much more. However, grab the whitepaper, audit yourself, and take care of the “low hanging fruit.”

Not More Than 16 Characters?!?

Microsoft, you’re killing me. This is the warning I received when typing in a password for Office 365:

More More Than 16 Characters

I blinked when I saw the warning, “Your password can’t be longer than 16 characters.” I couldn’t believe that I had gotten that warning, so I erased what I had typed for a password and started typing 1, 2, 3, etc., to see if this warning did trip at 17 characters. It did. Why in the world is there a limitation on password length if you’re going to do a hash my password? And if you had to pick a limit, why 16 characters? Why not 50 or 100 or 255?

I’ll give Microsoft credit for password complexity requirements:

  • Require uppercase
  • Require lowercase
  • Require number
  • Require a special character from a select list

However, we know that password length tends to be more important as long as you stay away from dictionary words. Therefore, if you’re building a system that takes passwords, don’t limit password length and use secure hashing algorithms and store the hash.

Protecting Against Delete without Where

If I’m doing any manual work with T-SQL, I always begin every set of data change operations with BEGIN TRAN and I have the COMMIT TRAN commented out at the end of my script. Why?

Quite simply, because I’m wary of having a DELETE clause without a proper WHERE clause. I’ve made that mistake in my career and it’s easy to do if you are tired, pressed for time, or both. This allows me to verify I’ve only changed what I intended and then I highlight and execute the COMMIT TRAN to finish the operation. However, there have been times when I neglect this habit. 

Which is why seeing Steve Jones’ post about a new feature in SQL Prompt made me smile. If you have it installed and are about to execute a DELETE without a WHERE clause, it prompts you to verify this was your intent. As Steve writes, sometimes it is. But when it isn’t, that warning can be a life saver. 

I won’t abandon my BEGIN TRAN habit, but I will certainly take advantage of this new feature in SQL Prompt. 

A Different Type of Currency

Recently, a member of the community lamented that folks weren’t willing to provide an email address for free training. This reminds me of an old saying popularized by Heinlein, but one that was used a lot in the Perl community: TANSTAAFL (There Ain’t No Such Thing As A Free Lunch). While the training was advertised as “free,” it really wasn’t. After all, the person had to pay up something: his or her email address.

Once upon a time, we didn’t think anything of this. However, then SPAM became more than a nuisance. And despite increasingly advanced mail filters, SPAM still gets through. SPAM campaigns are still effective. While percentage wise they seem not to be, converting at far less than 1%, the upside for spammers is sending out a bunch of emails doesn’t cost very much. So it doesn’t take much to turn a profit. Those conversion rates are stil good enough to keep the spammers happily in business. That’s why folks are still at it. 

Worse than that, now we’re seeing phishing and spear phishing attacks, where adversaries are trying to have you click on malware or a MitM (Man-in-the-Middle) site or just a mock-up of a legitimate site that doesn’t actually take you to the original site (it usually just throws an error indicating the site s unavailable and to try again later), the latter two to capture legitimate credentials to use at the sites they pretend to be.

And that brings me to my final thought about providing email addresses: they are increasingly becoming the username to log on to various sites, such as the PASS site. So giving up your email means giving up your login unless you’re a paranoid type that has multiple email adresses just to serve to split things up. Not many fall into this category as it’s a real chore trying to keep up with a lot of email addresses.  So if you give up your email, then someone who wants to be malicious now has part of the information he/she needs to log on to those sites as you. 

Therefore, I can’t fault folks when they don’t want to provide email information for something described as free. Whe you give up your email address, you don’t know what the person or organization is going to do with it. A lot of organizations resell email addresses to other organizations. This is legitimate business, even if we personally disagree with the practive. There’s also the black market where individual email addresses aren’t worth much, but if you can sell them in bulk, then the multiplier means a tidy profit. It’s even better if you are selling validated email addresses, which are obviously worth more, because spammers know they will be able to reach a legitimate person.

I also can’t fault folks who ask for the email address when they provide resources to the community. After all, they’ve worked hard (hopefully) to be able to make those resources worthwhile to whomever wants to use them. However, if you ask for an email address, what you’re providing isn’t free. You’re just asking for a different form of currency.  You are asking for both information and identity. So don’t be surprised if someone (especially folks like me) chooses to forego accessing a resource instead of providing the email. At the end of the day I have to make a decision on a value proposition: is what you are providing worth what I am giving up? Some folks win, other folks lose. That’s just the way it is.

Previous Older Entries