Please RSVP to this Meetup using the link above, then use the online event URL to join (note: you MUST RSVP for the URL to be visible). We will send out a meeting password as we get closer to the event.
Thanks to our sponsor, Datto, for making this event possible!
I wrote a while back that, while digital documentation dominates the world today, paper isn’t necessarily dead. That said, my friend, Greg Moore, notes an issue with printed material that didn’t occur to me, and it has to do with data security. Read on for more.
About 35 years ago in the fall, a housemate of mine got a phone call, “hey, I’m a caver who’s passing through your area this weekend and found your name in the NSS Members’ Manual, I was hoping maybe you could hook me up with a caving trip.” Well it just so turns out that the RPI Outing Club traditionally does Friday night caving. (Why night you might ask? Well it’s always dark in the caves, so going at night leaves time on Saturday and Sunday to hike, rock-climbing, canoe, etc.) My housemate invited the guy along and he joined us caving (I think in Knox Cave).
I mention this story because it’s an example of how the NSS Members’ Manual has often been used over the years. Talk to enough old-time caves (especially those who recognize the smell of carbide in the morning) and many will mention how they’ve…
I don’t think there’s an experienced web developer or DBA who isn’t familiar with the classic “Bobby Tables” XKCD cartoon above. Just about any time you mention “Bobby Tables” to most experienced IT people, (s)he will immediately know to whom you are referring. Most experienced web developers and DBAs are aware of SQL injection and will take steps to ensure that it’s addressed. Grant Fritchey has a presentation about SQL injection (you can view and download his slide deck here) in which he’s not shy about his desire to “kill Bobby Tables.” I’ve seen him present it at SQL Saturday, and I highly recommend it.
Of course, the keyword here is “experienced.” For people who don’t have that experience, and who build websites that connect to databases, I think it should be lesson #1. Today, I had an experience that reminded me of that.
Earlier today, my sister texted me, asking for help with editing SQL code. She asked me what I use to edit SQL. I told her I generally use SSMS, although you can edit SQL code with a straight-up text editor, if necessary (she is not a DBA, so I felt somewhat comfortable telling her this). She told me she had to clean up spam comments in her data.
That last comment immediately grabbed my attention. I then asked her, how are your security settings, and do you have data backups.
She told me: that IS her data backup.
If her earlier comment had gotten my attention, this one immediately set off alarm klaxons in my head.
I started thinking about what could have corrupted her data to this extent. I started asking questions about her admin setup (I should’ve asked her to make sure she wasn’t using “sa” or “admin” as her admin login — Sis, if you’re reading this, make sure you check this!), including her passwords. Her admin password was pretty secure (thankfully).
She then mentioned her website. I asked if her website was accessing her data. She said yes.
I asked her about Bobby Tables (admittedly, in my advancing age, the term “SQL injection” didn’t immediately come to my mind). Her response: “who?”
At this point, I was convinced that I had my answer. Her database had been corrupted through SQL injection attacks. I told her to make sure you address your SQL injection issue before you even think about your data backups. Worrying about your data backups before addressing your SQL injection issue is like trying to rebuild your house before you’ve put out the fire.
I’ve been talking about SQL injection all throughout this article. For a brand-new web or database developer who has no idea what SQL injection is, here’s a quick primer: it’s a data security attack in which a hacker breaches your database by sending SQL commands through your web interface. I won’t get too much into how it works; instead, here are a few links that explain what it is.
So consider this a warning to any fledgling developers who are interested in web or data development: data security issues, such as SQL injection (and there are many others) are a big deal and need to be considered when building your setup; it’s not as simple as just setting up your website and connecting it to a database. By not considering this when you first assemble your system, you might be setting yourself up for major issues down the road.
There’s a message on your voicemail saying “we’ve been trying to reach you about your warranty” or “we’ve detected problems with your computer.” They’re full of crap, and you know it. You figure that they’re mere annoyances. You don’t answer the phone anymore, or you’ve installed a spam filter on your phone (disclosure: I’ve done both of these). If it’s important, let them leave a message. Just ignore them. Not a big deal.
I’ve personally discovered that it is a big deal. They are not only disruptive, they are potentially dangerous. And I have some stories to explain how they’re dangerous.
I’ll start with one that’s not necessarily dangerous, but it did disrupt something important. I recently had an email exchange from someone asking me for my personal info for tax reasons. This was a legitimate exchange; this was NOT spam. I called and left her a message. A couple of weeks later, I received an email saying, “I’m still waiting to hear back from you.” I responded with, “did you not get my message?” It turned out that she did not recognize my phone number and deleted the message. This was an important, time-sensitive message that could have caused problems if we had not resolved it.
Another incident happened a few months ago (and unlike the above story, this one was dangerous). I’m purposely keeping this vague for privacy reasons, but here’s the gist of it: one day, I received multiple phone calls from a number I did not recognize. Of course, I ignored them as spam. They did not leave a message. I later received a phone call from the hospital. It turned out that those calls were from EMS regarding someone who had me listed as the emergency contact, informing me that this person had to go to the hospital. Unlike the previous story, this was a situation that was dangerous and could have had disastrous consequences. (As it turned out, it ended well, and the crisis was averted, but it could have ended up much worse. I could argue that EMS should have left messages, but I digress.)
I could list several more stories, but by now, I think you have the idea.
The bottom line is that spam phone calls are NOT inane and harmless. They’re the little boy who cried wolf, and they need to be dealt with. I don’t know what the statistics are (if any exist), but it wouldn’t surprise me if spammers were responsible for millions of dollars of losses, and possibly even hundreds of deaths. I realize that trying to track down the criminals who are responsible for spam is nearly an impossible task, but it needs to be done, and they need to be prosecuted. I realize that communication companies and cybercrime units are doing the best they can, but it’s a tall order.
When (not if) you receive a spam call, try to take steps to report it, if you are able to do so (and yes, I realize that it can be a pain). The sooner we put these criminals behind bars, the sooner we can start picking up the phone again.
IMPORTANT! If you are attending SQL Saturday, you MUST register on the SQL Saturday website (NOT Meetup or Facebook) at https://www.sqlsaturday.com/961!
This is a reminder that tomorrow, July 25, CASSUG will host Albany SQL Saturday for the seventh time! And for the first time, Albany SQL Saturday is going virtual!
We will have a full day of great presentations that cover a variety of topics that include, but aren’t limited to, business intelligence, data science, database development, data architecture, and professional development!
We will also have our usual wrap-up and raffles at the end of the day!
To register, go to https://www.sqlsaturday.com/961. It is important that you register at this site; RSVPs to Meetup or Facebook do not register you for SQL Saturday!!!
SQL Saturday is always a good time! We hope to see you (virtually) on Saturday, July 25!
Let me make one thing clear. I am not talking about using data or statistics in and of itself to back up any assertions that I make. Rather, I am talking about illustrating a concept that just happens to include data as part of the picture. In this scenario, the illustration is the important part; the data itself is irrelevant. In other words, the information within the data isn’t the example; the data is the example. Take a moment to let that sink in, then read on. Once you grasp that, you’ll understand the point of this article.
I need to strike a type of balance as to what kind of examples I use. Since I work in a multi-client data application environment, I need to take extra steps to ensure that any data examples I use are client agnostic. Clients should not see — nor is it appropriate to use — data examples that are specific to, or identifies, a client.
There’s also a matter of data security. I needn’t explain how big of a deal data security is these days. We are governed by laws such as HIPAA, GDPR, and a number of other data protection laws. Lawsuits and criminal charges have come about because of the unauthorized release of data.
For me, being mindful of what data I use for examples is a part of my daily professional life. Whenever I need data examples, I’ll go through the data to make sure that I’m not using any live or customer data. If I don’t have any other source, I’ll make sure I alter the data to make it appear generic and untraceable, sometimes even going as far as to alter screen captures pixel by pixel to change the data. I’ll often go through great pains to ensure the data I display is agnostic.
I remember a situation years ago when a person asking a question on the SQLServerCentral forums posted live data as an example. I called him out on it, telling him, “you just broke the law.” He insisted that it wasn’t a big deal because he “mixed up names so they didn’t match the data.” I, along with other forum posters, kept trying to tell him that what he was doing was illegal and unethical, and to cease and desist, but he just didn’t get it. Eventually, one of the system moderators removed his post. I don’t know what happened to the original poster, but it wouldn’t surprise me if, at a minimum, he lost his job over that post.
Whenever I need to display data examples, there are a number of sources I’ll employ to generate the data that I need.
Data sources that are public domain or publically available — Data that is considered public domain is pretty much fair game. Baseball (and other sports) statistics come to mind off the top of my head.
Premanufactured example data — If you use SQL Server, no doubt you’re familiar with sample data sets such as AdventureWorks or Northwind Traders. Other sample data sources use similar fictitious data sources (e.g. Contoso).
Roll your own — I’ll often make up names (e.g. John Doe, Wile E. Coyote, etc.) and data wherever I need to do so. As an added bonus, I often have fun while I’m doing it!
Are there any other examples I missed? If you have any others, feel free to comment below.
So if you’re writing documentation in which you’re using an illustration that includes data, be mindful of the data in your illustration. Don’t be the person who is inadvertently responsible for a data breach in your organization because you exposed live data in your illustration.
I arrived home last night around 9:15, after driving four hours (including an hour-long dinner break) from Providence, RI. As usual, it was another great SQL Saturday! As always, I had a blast! And as always, I was wiped out after it was over! Even as I write this, on this Sunday afternoon, I had intended to take care of some work around the house, and ended up taking a nap instead. C’est la vie.
So as seems to be tradition lately, here’s my most recent writeup of my most recent SQL Saturday.
I’ll start with something I did before I even left on Friday. I was getting my things organized and packed for my trip. While going through my briefcase, I came across my laptop dongle. I told myself, “most places these days use HDMI video inputs for their projectors. I haven’t needed it yet. So I’ll just leave it here.” I tossed it back in my briefcase, and packed my laptop without the dongle.
I didn’t know it yet, but I had just shot myself in the foot. (Read on, McDuff.)
SQL Saturday speakers at dinner (photo courtesy of Paresh Motiwala)
I checked into my B&B (a cute New England cape house in North Kingstown, RI) and headed to the speaker’s dinner. One of the B&B’s co-owners told me that the restaurant was a former train station. It sat by some very active railroad tracks. Not only was I able to see trains as they went by, I could feel them. Several Amtrak, Acela, and MBTA commuter trains passed by during dinner.
Of course, it isn’t a SQL Saturday unless Paresh and I go out for ice cream!
My session was scheduled for 10:00 on Saturday. Unfortunately, it didn’t go as smoothly as I would have liked. For starters, I found out that the wrong room was listed on the schedule. I went to an empty room, which surprised me, because I was expecting to walk into the previous session already in progress. It turned out that it was down the hall.
Remember how I said that I shot myself in the foot when I didn’t bring my dongle? Here’s where it raised its ugly head. It turned out that the only projector connections were VGA, which I didn’t have on my laptop. I was not able to find an HDMI adapter. That’s when I resorted to Plan B.
Before every SQL Saturday, I always make it a point to upload my slides to the website. They’re there so that attendees can download them. However, they also serve a secondary purpose: my backup, in case something happens with my laptop. Sure enough, I had to resort to it. I used the desktop computer in the classroom, downloaded my slides, and used that for my presentation. (A thought popped into my head while they were downloading: does the desktop have PowerPoint installed?)
I was angry with myself, because I usually take pride in that I’m always prepared — and on this day, I wasn’t. Note to self: always bring the dongle with you. I made a mistake, and I paid for it by losing ten minutes of my presentation time. I suppose I’ll chalk it up as a learning experience, and remember to pack my dongle for next time.
The presentation otherwise went without a hitch. I did tweak it a bit, per the feedback I received the previous time I’d presented it.
I’ve conversed with this gentleman online for years — and finally met him in person for the first time at SQL Saturday!
I was in for a surprise (a pleasant one, this time!) after my presentation. One of the attendees (the gentleman you see in this picture) introduced himself to me after I was done — and when I saw his name tag, I realized immediately who it was! (For privacy reasons, I’m withholding his name.)
I often peruse the forums on SQLServerCentral.com. It’s my go-to forum whenever I have database-related questions. There are a number of people whom I see regularly on the forum, and I interact with them often enough that I consider them friends. The fantasy football league in which I play came from these forums. There is one person with whom I interact regularly on the forums, including fantasy football. He is our league’s defending champion, and as the only two people in the league who have multiple titles, we are rivals. I’ve been conversing with him for year and years. I consider this man a friend.
This weekend, we met face-to-face for the first time! He attended my presentation, and I had no idea that it was him! His attendance totally blew my mind, and it made my day!
Grant Fritchey gave a great presentation about SQL injection. It blew my mind — and not in a good way. Although SQL injection was identified as a security problem in 1997, it still persists as a problem now in 2019. If nothing else, Grant’s presentation reminded me that we still need to be vigilant about fighting code injection, even with all the safeguards we have in place now.
Probably one of my favorite sessions was the last one of the day. Linda Groszyk, who is a relative newcomer to speaking for SQL Saturday, gave a great presentation called Breaking the Social Code: How to be Socially Intelligent at Work. It was a fantastic session about human psychological dynamics that, I think, everyone should be aware of. I was impressed enough by her presentation that I encouraged her to apply to speak at our SQL Saturday in Albany when it rolls around next July, as well as our user group, if she is able to arrange it! (Greg Moore, if you’re reading this, consider this a heads-up!)
Another weekend, another great SQL Saturday in the books! If you are able to make it to one near you, I encourage you to do so!
A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.
This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped…
For those of you who are not regular readers of my ‘blog, SQL Saturday is a daylong conference centered mostly (but not entirely) around data topics related to SQL Server. It’s also a great networking event, and an opportunity to hook up with a number of data professionals! Check out the schedule to see what sessions interest you!
Additionally, there are three pre-con sessions on Friday, July 19. Unlike SQL Saturday, these sessions are not free, but they provide quality daylong training for specific topics at a decent price. Information about these pre-cons can also be found on the web site!
For more information and to register for the event, visit our website! Upstate New York is a great place to visit during the summertime! Hope to see you there!
Welcome to Ray Kim's 'blog 