Tag: security

We know that the online world is dangerous, with the number and variety of threats constantly increasing. For years, phishing with email has been a favorite tactic of hackers. Most of these emails are poorly written, and IT professionals often spot the fake ones, but there are times when the creativity of nefarious individuals is quite surprising.

There was an attack on utility companies recently, which targeted engineers and purported to have some results for professional examinations. Since there is likely always someone taking an engineering exam as a professional at a utility company, this attack has a chance of succeeding. A Word doc included had a number of macros that installed a trojan for the employee. Hopefully few people allowed macro execution, but I’m sure someone was distracted, busy, and perhaps stressed about their exam results and didn’t think. Or clicked too fast.

What is scary here is that the attack is suspected to be the work of a nation-state, which could mean substantial resources went into the attack. There are certainly potential issues if someone gets access to a privileged workstation, which is always a concern. This is why few people should have privileged access, and a privileged account should never be used for email software. A low-access account is the best way to work through emails and attachments.

Many of us have privileged accounts, but imagine that someone gets a trojan on our laptop. When we use sudo or runas, we might find our credentials compromised. Think it can’t happen? What if all your IT staff got a note about an MS examination result? Or what if they got a free offer to take a certification test? I’m sure someone would click on it, and it only takes one.

Security is hard, with education and caution being the most important tools at our disposal. Spread the word about stories like this and ensure all your staff, especially junior staff, is especially cautious about how and where they open any potential email attachments, click links, or even allow pictures. Security remains a challenge for all our organizations and we need to continually work at maintaining a vigilant environment.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Not too long ago I wrote about a security failure from an AI company, Evisort, that had a development database exposed on the Internet. There were reports of customer information being exposed and initially it appeared the Evisort was being negligent by putting an  ElasticSearch database with no password on the Internet. They were, but this might not have been a problem for customers.

In an update, Evisorts dispute any customer data was exposed and they’ve updated security. They’ve hired consultants to help them and they are investigating and reviewing all documents that were exposed. They’ve offered to talk with any customers, and it appears they are taking this event seriously.

So, was there really a breach? I don’t know. I have no firsthand knowledge of the actual data, and I haven’t seen anything that indicates Evisort is covering up data loss. Perhaps they are, but perhaps someone was just seeking to imply there was a breach. Doing so is an attack on Evisort, not with data, but with information.

This might have been sent to a reporter to cause Evisort issues. Perhaps the issue was publicized to win a deal for a competitor that was near completion by making Evisort appear negligent. Perhaps this was an attempt to prevent Evisort from getting any more funding or reduce the value of the company.

There are all sorts of attacks that occur on companies. Some of these are to get data to sell. Some might be to create bad press. Some might be to influence the value of the company or perhaps cost them customers. The attacks are often aimed to accomplish some secondary goal: reduce share price, interrupt funding, influence customers to stop doing business, or even to make competitors look more valuable or desirable.

These are attacks on a company using some sort of other attack, like a hack of some sort.

The world is becoming more and more scary for data professionals. We have to be increasingly diligent, and not only be able to protect data, but prove we are protecting it. With the swift and strong reaction of many in social media, it behooves us to take extra precautions and ensure we have evidence of our taking precautions ready to dispute any misleading account. More importantly, we ought to know how to react if we do actually lose data. Think about this ahead of time, as you might not have time to so once an event actually occurs.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

I think Troy Hunt is an incredible thinker. His view and work to improve security in infrastructure and applications is incredible and valuable. I think the focus on better passwords and the implications of data breaches has grown in the world, perhaps due to Troy’s work with https://haveibeenpwned.com/. Plenty of non technical people know about the site, and more than a few government officials.

Recently I read a piece from Mr. Hunt on passwords and why they will continue to exist for some time. I agree that the understanding and convenience of passwords makes them a tool that will remain widely deployed for some time. I like the additional verification from Google and other sites with a text or message on a phone for MFA (multi-factor authentication), and would love to see that in SQL Server, but this doesn’t eliminate the need for passwords. It just adds to them.

The idea of password has a parallel in database development as well. One of the most basic things that we do as data professionals is fix problems on our systems. We do this in various ways, but I’d bet almost every organization has an individual that has made a change in a live, production database. Why? Because it’s easy and it needs to be done sometimes to fix code, data, or something else quickly. We know it’s not ideal, but it works.

I try to talk about compliant Database DevOps, about having a process, the need for evaluating code and data changes, about limiting access to production, about ensuring every statement is tested elsewhere, about even masking/anonymizing/generating data in dev/test environments. Most of us know these are good ideas, and likely quite a few of us would like to adopt them. Why don’t we? Part of it is the ease with which we get things done. Another part is the success that we have with our current process.

We fix things, we add indexes, we correct typos in code, we adjust our deployment to succeed, even though the scripts had problems. We roll forward constantly, coding by the seat of our pants, and for the most part our organizations continue to function well. Brent Ozar’s recent survey on production data in development shows that in some cases there isn’t a security risk, but quite a few times expediency and troubleshooting mean we work in production or copy data.

I still think DevOps is the better way to move development forward. At Redgate, we have a suite of tools that help you smooth database development to reduce mistakes and problems. Not because you can’t be successful the way you are, but because you can go faster, make more experiments and changes, and deploy on demand rather than as a special event. We help you save time, which should translate into your highly paid staff spending time on creative new solutions, not fixing tedious problems. We even expect you’ll do things in production, which is why DLM Dashboard was built.

We’re not the only vendor doing this. Plenty of others are trying to help you build a smoother database DevOps process, including Microsoft. Most expert software developers know that DevOps is a better way to build software that focuses and takes advantage of the creativity of your developers, while reducing the time spent on non-creative work. I, and many others, feel that the database needs to be a part of this to be as successful as we can be.