Eric Kavanagh: OK, ladies and gentlemen, hello and welcome back again. It's a Wednesday, it's four Eastern and in the world of enterprise technology that means it's time once again for Hot Technologies! Yes, indeed. Presented by the Bloor Group of course, powered by our friends at Techopedia. The topic for today is a really cool one: “Better to Ask Permission: Best Practices for Privacy and Security.” That's right, it's kind of a tough topic, a lot of people talk about it, but it's a pretty serious one, and it's really getting more serious every day, quite frankly. It's a grave issue in many ways for many organizations. We're going to talk about that and we're going to talk about what you can do to protect your organization from the nefarious characters that seem to be all over the place these days.
So today's presenter is Vicky Harp calling in from IDERA. You can see IDERA Software on LinkedIn – I love the new functionality on LinkedIn. Although I can tell they're pulling some strings in certain ways, not letting you access people, trying to get you to buy those premium memberships. There you go, we have our very own Robin Bloor, dialing in – he's actually in the San Diego area today. And yours truly as your moderator/analyst.
So what are we talking about? Data breaches. I just took this information from IdentityForce.com, it's already off to the races. We're in May of course of this year, and there's just a ton of data breaches, there are some really huge ones, of course, by Yahoo! was a big one, and we heard about of course the US government being hacked. We just had the French elections hacked.
This is happening all over the place, it's continuing and it's not going to stop, so it is a reality, it's the new reality, as they say. We really do need to think about ways to enforce the security of our systems and of our data. And it's an ongoing process, so it's just in time to think about all the different issues that come into play. This is just a partial list, but this gives you some perspective on just how precarious the situation is these days with enterprise systems. And before this show, in our pre-show banter we were talking about ransomware which has hit somebody I know, which is a very unpleasant experience, when someone takes over your iPhone and demands money for you to get back access to your phone. But it happens, it happens to computers, it happens to systems, I saw just the other day, it's happening to billionaires with their yachts. Imagine going to your yacht one day, trying to impress all your friends and you can't even turn it on, because some thief has stolen access to the controls, the control panel. I just said the other day in an interview to someone, always have the manual override. Like, I'm not a big fan of all the connected cars – even cars can be hacked. Anything that's connected to the internet, or connected to a network that can be penetrated can be hacked, anything.
So, here are just a few items to consider in terms of framing the context of how serious the situation is. Web-based systems are everywhere these days, they continue to proliferate. How many people buy stuff online? It's just through the roof these days, that's why Amazon is such a powerful force these days. It's because so many people are buying stuff online.
So, you remember back then, 15 years ago, people were pretty nervous about putting their credit card into a web form to get their information, and back then, the argument was, “Well, if you hand your credit card to a waiter at a restaurant, then that's the same thing.” So, our answer is yes, it is the same thing, there are all of these control points, or access points, same thing, different side of the same coin, where people can be put into jeopardy, where someone can take your money, or someone can steal from you.
Then IoT of course expands the threatscape – I love that word – by orders of magnitude. I mean, think about it – with all these new devices everywhere, if someone can hack into a system that controls them, they can turn all those bots against you and cause lots and lots of problems, so that's a very serious issue. We have a global economy these days, which expands the threatscape even more, and what's more, you have people in other countries who can access the web in the same way you and I can, and if you don't know how to speak Russian, or any number of other languages, you're going to have a hard time understanding what's going on when they hack into your system. So we have advances in networking and virtualization, well that's good.
But I have on the right-hand side of this picture here, a sword and the reason I have it there is because every sword cuts both ways. It's a double-edged sword, as they say, and it's an old cliché, but it means the sword I have can harm you or it can harm me. It can come back on me, either by bouncing back, or by someone taking it. It's actually one of Aesop's Fables – we often give our enemies the tools of our own destruction. It's really quite the compelling storyline and has to do with someone who used a bow and arrow and shot down a bird and the bird saw, as the arrow was coming up, that feather from one its fowl friends was on the edge of the arrow, on the back of the arrow to guide it, and he thought to himself, “Oh man, here it is, my own feathers, my own family are going to be used to take me down.” That happens all the time, you hear statistics about you have a gun in the house, the thief can take the gun. Well, this is all true. So, I'm throwing this out there as an analogy just to consider, all of these different developments have positive sides and negative sides.
And speaking of, containers for those of you who really follow the cutting edge of enterprise computing, containers are the latest thing, latest way to deliver functionality, it's really the marriage of virtualization in the service-oriented architecture, at least for microservices and it's very interesting stuff. You can certainly obfuscate your security protocols and your application protocols and your data and so forth, by using containers, and that gives you an advance for a period of time, but sooner or later, the bad guys are going to figure that out, and then it's going to be even harder to prevent them taking advantage of your systems. So, there's that, there's global workforce which complicates the network and security, and where people are logging in from.
We've got the browser wars which continue apace, and require constant work to update and stay on top of things. We keep hearing about the old Microsoft Explorer browsers, how they were hacked and available in there. So, there's more money to be made in hacking these days, there's a whole industry, this is something that my partner, Dr. Bloor, taught me eight years ago – I was wondering why are we seeing so much of it, and he reminded me, it's a whole industry involved in hacking. And in that sense, the narrative, which is one of my least favorite words about security, is really very dishonest, because the narrative shows you in all these videos and any kind of news coverage some hacking they show some guy in a hoodie, sitting in his basement in a dark lit room, that's not at all the case. That is not at all representative of reality. It's lone hackers, there are very few lone hackers, they're out there, they're causing some trouble – they’re not going to cause the big trouble, but they can make a whole lot of money. So what happens is the hackers come in, and penetrate your system and then sell that access to someone else, who turns around and sells it to someone else, and then somewhere down the line, somebody exploits that hack and takes advantage of you. And there are countless ways to take advantage of stolen data.
I've even been marveling to myself about how we've been glamorizing this concept. You see this term everywhere, “growth hacking” like it's a good thing. Growth hacking, you know, hacking can be a good thing, if you're trying to work for the good guys so to speak and hack into a system, like we keep hearing about with North Korea and their missile launches, potentially being hacked – that's good. But hacking is often a bad thing. So now we're glamorizing it, almost like Robin Hood, when we glamorized Robin Hood. And then there's the cashless society, something that's frankly concerns the daylights out of me. All I think every time I hear that is, “No, please don't do it! Please don't!” I don't want all of our money to disappear. So, these are just some issues to consider, and again, it's a cat-and-mouse game; it's never going to stop, there will always be a need for security protocols and for advancing security protocols. And for monitoring your systems for even knowing and sensing who's out there, with the understanding being it could even be an inside job. So, it's an ongoing issue, it's going to be an ongoing issue for quite some time – make no mistake about that.
And with that, I'm going to hand it over to Dr. Bloor, who can share with us some thoughts about securing databases. Robin, take it away.
Robin Bloor: OK, one of the interesting hacks, I think it occurred about five years ago, but basically it was a card processing company that was hacked. And a large number of card details were stolen. But the interesting thing about it, to me, was the fact that it was the test database that they actually got into, and it was probably the case that they had a great deal of difficulty getting into the actual, real database of processing cards. But you know how it is with developers, they just take a cut of a database, shove it in there. There would have had to have been far more vigilance to stop that. But there's lots of interesting hacking stories, it makes in one area, it makes a very interesting subject.
So I'm going to actually, in one way or another, repeat some of the things that Eric said, but it's easy to think of data security as a static target; it's easier just because it's easier to analyze static situations and then think of putting defenses in, defenses there, but it isn't. It's moving target and that's one of the things that kind of defines the whole of the security space. It's just in the way that all technology evolves, the technology of the bad guys evolves as well. So, brief overview: Data theft is nothing new, in actual fact, data espionage is data theft and that's been going on for thousands of years, I think.
The biggest data heist in those terms was the British breaking the German codes and the Americans breaking the Japanese codes, and pretty much in both instances they shortened the war very considerably. And they were just stealing useful and valuable data, it was very clever of course, but you know, what's going on right now is very clever in lots of ways. Cyber theft was born with the internet and exploded around 2005. I went and looked at all of the stats and when you started to get really serious and, in some way or other, remarkably high numbers starting in about 2005. It's just got worse since then. Many players, governments are involved, businesses are involved, hacker groups and individuals.
I went to Moscow – that must have been about five years – and I actually spent a lot of time with a guy from the UK, who's researching the whole of the hacking space. And he said that – and I have no idea whether this is true, I've only got his word for it, but it sounds very likely – that in Russia there's something called the Business Network, which is a group of hackers that are all, you know, they came out of the ruins of the KGB. And they sell themselves, not just, I mean, I'm sure the Russian government uses them, but they sell themselves to anyone, and it was rumored, or he said it was rumored, that various foreign governments were using the Business Network for plausible deniability. These guys had networks of millions of compromised PCs that they could attack from. And they had all the tools you can imagine.
So, the technology of attack and defense evolved. And businesses have a duty of care over their data, whether they own it or not. And that's starting to become much clearer in terms of the various pieces of regulation that are actually already in force, or coming into force. And likely to improve, somebody's in one way or another, somebody has got to bear the cost of hacking in such a way that they're incentived to close down the possibility. That's one of the things that I guess is necessary. So about the hackers, they can be located anywhere. Particularly within your organization – an awful lot of the ingenious hacks that I've heard of involved somebody opening the door. You know, the person, it's like the bank robber situation, nearly always they used to say in good bank robberies there's an insider. But the insider only needs to give out information, so it's difficult to get them, to know who it was, and so on and so forth.
And it may be difficult to bring them to justice, because if you've been hacked by a group of people in Moldova, even if you know it was that group, how are you going to make some kind of legal event happen around them? It's kind of, from one jurisdiction to another, it's just, there isn't a very good set of international arrangements to pin down the hackers. They share technology and information; a lot of it is open source. If you want to build your own virus, there's loads of virus kits out there – completely open source. And they have considerable resources, there have been a number that have had botnets in more than a million compromised devices in data centers and on PCs and so on. Some are profitable businesses that have been going for a long time, and then there's government groups, as I mentioned. It's unlikely, as Eric said, it's unlikely this phenomenon is ever going to end.
So, this is an interesting hack I just thought I'd mention it, 'cause it was a fairly recent hack; it happened last year. There was a vulnerability in the DAO contract associated with the Etherium crypto coin. And it was discussed on a forum, and within a day, the DAO contract was hacked, using that vulnerability precisely. $50 million in ether was siphoned off, causing an immediate crisis in the DAO project and closing it down. And the Etherium actually fought to try and keep the hacker from access to the money, and they kind of reduced his take. But it was also believed – not known for sure – that the hacker actually shorted the price of ether prior to his attack, knowing that the price of ether would collapse, and thus made a profit in another way.
And that's another, if you like, stratagem that the hackers can use. If they can damage your share price, and they know they'll do that, then it's only necessary for them to short the share price and do the hack, so it's kind of, these guys are smart, you know. And the price is outright theft of money, disruption and ransom, including investments, where you disrupt and short the stock, sabotage, identity theft, all sorts of scams, just for the sake of advertising. And it tends to be political, or obviously, information spying and there are even people that make a living out of the bug bounties that you can get by trying to hack Google, Apple, Facebook – even the Pentagon, actually gives bug bounties. And you just hack; if it's successful, then you just go and claim your prize, and no damage is done, so that's a nice thing, you know.
I might as well mention compliance and regulation. Aside from sector initiatives, there's loads of official regulations: HIPAA, SOX, FISMA, FERPA and GLBA are all US legislation. There are standards; PCI-DSS has become a fairly general standard. And then there's ISO 17799 about data ownership. National regulations differ country to country, even in Europe. And currently the GDPR – the Global Data, what does it stand for? Global Data Protection Regulation, I think it stands for – but that's coming into force next year, said to. And the interesting thing about it is that it applies across the world. If you've got 5,000 or more customers, who you've got personal information on and they live in Europe, then Europe will actually take you to task, no matter your corporation is actually headquartered, or where it operates. And the penalties, the maximum penalty is four percent of annual revenue, which is just huge, so that'll be an interesting twist on the world, when that comes into force.
Things to think about, well, DBMS vulnerabilities, most of the valuable data is actually sitting in databases. It's valuable because we've put an awful lot of time into making it available and organizing it well and that makes it more vulnerable, if you don't actually apply the right DBMS securities. Obviously, if you're going to plan for things like this, you need to identify what vulnerable data is throughout the organization, bearing in mind that data can be vulnerable for different reasons. It can be customer data, but it could equally be internal documents that would be valuable for espionage purposes and so on. The security policy, particularly in relation to access security – which in recent times has been in my opinion very weak, in the new open source stuff – encryption is coming more into use because it's pretty rock solid.
The cost of a security breach, most people didn't know, but if you actually look at what's happened with organizations that have suffered security breaches, it turns out that the cost of a security breach is often way higher than you think it would be. And then the other thing to think about is the attack surface, because any piece of software anywhere, running with your organizations presents an attack surface. So do any of the devices, so does the data, no matter how it's stored. It's all, the attack surface is growing with the internet of things, the attack surface is probably going to double.
So, finally, DBA and data security. Data security is usually part of the DBA's role. But it's collaborative, too. And it needs to be subject to corporate policy, otherwise it'll probably not be implemented well. Having said that, I think I can pass the ball.
Eric Kavanagh: All right, let me give the keys to Vicky. And you can share your screen or move to these slides, it's up to you, take it away.
Vicky Harp: No, I'll start with these slides, thank you so much. So, yeah, I just wanted to take a quick moment and introduce myself. I'm Vicky Harp. I'm a manager, product management for SQL products at IDERA software, and for those of you who might not be familiar with us, IDERA has a number of product lines, but I'm here speaking for the SQL Server side of things. And so, we do performance monitoring, security compliance, backup, administration tools – and it's just kind of a listing of them. And of course, what I'm here to talk about today is security and compliance.
The bulk of what I'm wanting to talk about today is not necessarily our products, though I do intend to show some examples of that later. I wanted to talk to you more about database security, some of the threats in the world of database security right now, some things to think about, and some of the introductory ideas of what you need to be looking at in order to secure your SQL Server databases and also to make sure that they are compliant with the regulatory framework that you may be subject to, as was mentioned. There are many different regulations in place; they go on different industries, different places around the world, and these are things to be thinking about.
So, I kind of want to take a moment and talk about the state of data breaches – and not to repeat too much of what has already been discussed here – I was looking over this Intel security research study recently, and across their – I think 1500 or so organizations they spoke with – they had an average of six security breaches, in terms of data loss breaches, and 68 percent of those had required disclosure in some sense, so they affected the stock price, or they had to do some credit monitoring for their customers or their employees, etc.
Some interesting other statistics is that internal actors who were responsible for 43 percent of those. So, a lot of people do think a great deal about hackers and these kind of shady quasi-governmental organizations or organized crime, etc., but internal actors are still directly taking action against their employers, in a pretty high proportion of the cases. And these are sometimes harder to protect against, because people may have legitimate reasons to have access to that data. About half of that, 43 percent was accidental loss in some sense. So, for example, in the case where somebody took data home, and then lost track of that data, which leads me to this third point, which is that stuff to physical media was still involved of 40 percent of the breaches. So, that's USB keys, that's people's laptops, that's actual media that was burned onto physical discs and taken out of the building.
If you think about, do you have a developer who has a dev copy of your production database on their laptop? Then they go get on a plane and they get off the plane, and they get the checked baggage and their laptop is stolen. You've now had a data breach. You may not necessarily think that that's why that laptop was taken, it might not ever show up in the wild. But that's still something that counts as a breach, it's going to require disclosure, you're going to have all of the downstream effects of having lost that data, just because of the loss of that physical media.
And the other interesting thing is that a lot of people are thinking about credit data, and credit card information as being the most valuable, but that's not really the case anymore. That data is valuable, credit card numbers are useful, but honestly, those numbers are changed very quickly, whereas people's personal data isn't changed very quickly. Something that recent news item, relatively recent, VTech, a toy maker had these toys that were designed for children. And people would, they'd have their kids' names, they'd have information about where the kids live, they had their parents' names, they had photographs of the children. None of that was encrypted, because it wasn't considered to be important. But their passwords were encrypted. Well, when the breach inevitably happened, you're saying, “OK, so I have a list of children's names, their parents' names, where they live – all of this information is out there, and you're thinking that the password was the most valuable part of that?” It wasn't; people can't change those aspects about their personal data, their address, etc. And so that information is actually very valuable and it needs to be protected.
So, wanted to talk about some of the things that are going on, to contribute to the way that data breaches are happening right now. One of the big hotspots, spaces right now is social engineering. So people call it phishing, there's impersonation, etc., where people are getting access to data, often through internal actors, by just convincing them that they're supposed to have access to it. So, just the other day, we had this Google Docs worm that was going around. And what it would happen – and I actually received a copy of it, though fortunately I didn't click on it – you were getting email from a colleague, saying, “Here's a Google Doc link; you need to click on this to view what I just shared with you.” Well, that in an organization that uses Google Docs, that's very conventional, you're going to get dozens of those requests a day. If you clicked on it, it would ask you for permission to access this document, and maybe you'd say, “Hey, that looks a little strange, but you know, it looks legit as well, so I'll go ahead and click on it,” and as soon as you did that, you were giving this third party access to all of your Google documents, and so, creating this link for this external actor to have access to all of your documents on Google Drive. This wormed all over the place. It hit hundreds of thousands of people in a matter of hours. And this was fundamentally a phishing attack that Google itself ended up having to shut down, because it was very well executed. People fell for it.
I mention here the SnapChat HR breach. This was just a simple matter of someone emailing, impersonating that they were the CEO, emailing to the HR department, saying, “I need you to send me this spreadsheet.” And they believed them, and they put a spreadsheet with 700 different employees' compensation information, their home addresses, etc., emailed it to this other party, it wasn't actually the CEO. Now, the data was out, and all of their employees' personal, private information was out there and available for exploitation. So, social engineering is something that I mention it in the world of databases, because this is something that you can try to defend against through education, but you have to also just remember that anywhere that you have a person interacting with your technology, and if you're relying on their good judgment to prevent an outage, you're asking a lot of them.
People make mistakes, people click on things that they shouldn't have, people fall for clever ruses. And you can try very hard to protect them against it, but it's not strong enough, you need to try to limit the ability for people to accidentally give out this information in your database systems. The other thing I wanted to mention that obviously we're talking about a lot is ransomware, botnets, viruses – all of these different automated ways. And so what I think is important to understand about ransomware is it really changes the profit model for attackers. In the case that you're talking about a breach, they have to, in some sense, extract data and have it for themselves and make use of it. And if your data is obscure, if it's encrypted, if it's industry specific, maybe they don't have any value for it.
Up until this point, people may have felt like that was a protection for them, “I don't need to protect myself from a data breach, because if they're going to get into my system, all they're going to have is, I'm a photography studio, I have a list of who's going to be coming on what days for the next year. Who cares about that?” Well, it turns out the answer is you care about that; you're storing that information, it's your business-critical information. So, using ransomware an attacker will say, “Well, nobody else is going to give me money for this, but you will.” So, they leverage the fact that they don't even have to get the data out, they don't even have to have a breach, they just need to use security tools offensively against you. They get into your database, they encrypt the contents of it, and then they say, “OK, we have the password, and you're going to have to pay us $5,000 to get that password, or else you just don't have this data anymore.”
And people do pay up; they find themselves having to do that. MongoDB had kind of a huge problem a couple of months ago, I guess it was in January, where ransomware hit, I think, over a million MongoDB databases they have in public to the internet, based on some default settings. And what made it even worse is that people were paying and so other organizations would come in and re-encrypt or claim to have been the ones who had originally encrypted it, so when you paid your money, and I think in that case they were asking for something like $500, people would say, “OK, I would pay more than that to pay a researcher to get in here to help me figure out what went wrong. I'll just pay the $500.” And they weren't even paying it to the right actor, so they'd get piled on with ten different organizations telling them, “We've got the password,” or “We've got the way for you to unlock your ransomed data.” And you'd have to pay all of them in order to possibly get it to work.
There's also been cases where the ransomware authors had bugs, I mean, we're not talking about it being a perfectly above-board situation, so even once it's been attacked, even once you've paid, there's no guarantee that you're going to get all of your data back, some of this is being complicated as well by weaponized InfoSec tools. So the Shadow Brokers is a group that's been leaking out tools that were from the NSA. They were tools designed by government entity for the purposes of espionage and actually working against other government entities. Some of these have been really high profile zero-day attacks, that basically make the known security protocols just fall aside. And so there was a major vulnerability in the SMB protocol for example, in one of the recent Shadow Brokers' dumps.
And so these tools that come out here can, in a matter of a couple of hours, really change the game on you, in terms of your attack surface. So whenever I'm thinking about this, it's something that at an organizational level, security InfoSec is its own function, it needs to be taken seriously. Whenever we're talking about databases, I can take it down a little bit, you don't necessarily have to have as a database administrator full understanding of what's going on with the Shadow Brokers this week, but you need to be aware that all of these are shifting, there are things going on, and so the degree to which you keep your own domain tight and secure, it's really going to help you in the case that things kind of get ripped out from under you.
So, I wanted to take a moment here, before moving onto talking about SQL Server specifically, to actually have a bit of an open discussion with our panelists on some of the considerations with database security. So, I've gotten to this point, some of the things we haven't mentioned, I wanted to talk about SQL injection as a vector. So, this is SQL injection, obviously it's the way in which people insert commands into a database system, by kind of malforming the inputs.
Eric Kavanagh: Yeah, I actually met a guy – I think it was at Andrews Air Force base – about five years ago, a consultant that I was talking to him in the hallway and we were just kind of sharing war stories – no pun intended – and he mentioned that he had been brought in by someone to consult with a fairly high ranking member of the military and the guy asked him, “Well, how do we know you're good at what you do?” and this and that. And as he was talking to them he used on his computer, he'd gotten into the network, he used SQL injection to get into the email registry for that base and for those people. And he found the person's email that he talking to and he just showed him his email on his machine! And the guy was like, “How did you do that?” He said, “Well, I used SQL injection.”
So, that's just five years ago, and it was at an Air Force base, right? So, I mean, in terms of context, this thing is still very real and it could be used with really terrifying effects. I mean, I'd be curious to know of any war stories that Robin has on the topic, but all of these techniques are still valid. They're still used in many cases, and it's a question of educating yourself, right?
Robin Bloor: Well, yes. Yeah, it's possible to defend against SQL injection by doing the work. It's easy to understand why when the idea was invented and first proliferated, it's easy to understand why it was so goddamned successful, because you could just stick it in an input field on a web page and get it to return data for you, or get it to delete data in the database, or anything – you could just inject SQL code to do that. But it's the thing that interested me, is that it is you know, you would have to do a little bit of parsing, of every piece of data that was entered, but it's quite possible to spot that someone's attempting to do that. And it's really, I think it's really the, 'cause people still get away with it, I mean it's just really strange that there hasn't been an easy way to combat that. You know, that everybody could easily use, I mean, as far as I know, there hasn't been, Vicky, has there?
Vicky Harp: Well, actually some of the hostage solutions, like SQL Azure, I think have some pretty good detection methods that are based on machine learning. That's probably what we're going to see in the future, is something that it's trying to come up with the one size fits all. I think the answer has been there isn't one size fits all, but we do have machines that can learn what your size is and make sure that you're fitting to it, right? And so that if you have a false positive, it's because you're actually doing something unusual, it's not because you've had to go through and painstakingly identify everything that your application might ever do.
I think one of the reasons that it's really still so prolific is that people do still rely on third-party applications, and applications from ISVs and those are smeared out over time. So, you talk about an organization which has bought an engineering application that was written in 2001. And they haven't updated it, because there hasn't been any major functional changes since then, and the original author of it was kind of, they weren't an engineer, they weren't database security expert, they didn't do things the right way in the application and they wind up being a vector. My understanding is that – I think it was the Target data breach, the really large one – the attack vector had been via one of their air conditioning suppliers, right? So, the problem with those third party, you can, if you own your own development shop you can maybe have some of these rules in place, doing it generically whenever. As an organization you may have hundreds or even thousands of applications running, with all the different profiles. I think that is where machine learning is going to come along and start helping us a lot.
My war story was educational living. I got to see a SQL injection attack, and something that had never occurred to me is that [inaudible] use plain readable SQL. I do these things called obfuscated P SQL holiday cards; I like to do, you make this SQL look as confusing as possible. There's obfuscated C++ code contest that's been going on for decades now, and it's kind of the same idea. So, what you actually got was the SQL injection that was in an open string field, it closed the string, it put in the semicolon, and then it put in exec command that then had a series of numbers and then it was basically using the casting command to cast those numbers into binary and then casting those, in turn, into character values and then executing that. So, it's not like you got to see something that said, “Delete startup from production table,” it was actually stuffed into numeric fields that made it much harder to see. And even once you did see it, to identify what was happening, it took some real SQL shots, to be able to figure what was happening, by which time of course the work had already been done.
Robin Bloor: And one of the things that's just a phenomenon in the whole of the hacking world is that if somebody finds a weakness and it happens to be in a piece of software that's been generally sold, you know, one of the early problems is the database password that you were given when a database was installed, a lot of databases in actual fact was just a default. And a lot of DBAs simply never changed it, and therefore you could manage to get into the network then; you could just try that password and if it worked, well, you just won the lottery. And the interesting thing is that all of that information is very efficiently and effectively circulated amongst the hacking communities on darknet websites. And they know. So, they can pretty much do a sweep of what's out there, find a few instances and just automatically throw some hacking exploit at it, and they're in. And that's, I think, that a lot of people who are at least on the periphery of all of this, don't actually understand how fast the hacking network responds to vulnerability.
Vicky Harp: Yeah, that actually brings up another thing I wanted to mention before I move on, which is this notion of credential stuffing, which is something that's been popping up a lot, which is that once your credentials have been stolen for somebody anywhere, at any site, those credentials are going to be attempted to be reused across the board. So, if you are using duplicate passwords, say, if your users are, even, let's put it that way, somebody might be able to get access via what appears to be a completely valid set of credentials. So, let's say that I've used my same password at Amazon and at my bank, and also at a forum and that forum software was hacked, well, they have my user name and my password. And they can then use that same user name at Amazon, or they use it over at the bank. And as far as the bank is concerned, it was a completely valid login. Now, you can take nefarious actions via the completely authorized access.
So, that kind of goes back again to what I was saying about the internal breaches and the internal usages. If you've got people in your organization that are using their same password for internal access that they do for external access, you've got the possibility that someone's going to come in and impersonate you via a breach at some other site that you don't even know about. And this data is disseminated very quickly. There are lists of, I think that the most recent load to “have I been pwned” by Troy Hunt, he said he had half a billion set of credentials, which is – if you consider the number of people on the planet – that's a really large number of credentials that have been made available for credential stuffing.
So, I'm going to step a little bit deeper and talk about SQL Server security. Now I want to say that I'm not going to try to give you everything you need to know to secure your SQL Server in the next 20 minutes; that seems a bit of a tall order. So, to even start out, I want to say that there are groups online and resources online that you can certainly Google, there are books, there are best practice documents on Microsoft, there's a security virtual chapter for the professional associates at SQL Server, they're at security.pass.org and they have, I believe, monthly webcasts and recordings of webcasts to kind of go over the real, in-depth how to do SQL Server security. But these are some of the things that me, speaking to you as data professionals, as IT professionals, as DBAs, I want you to know you need to know about with SQL Server security.
So the first one is physical security. So, like I said earlier, stealing physical media is still extremely common. And so the scenario that I gave with the dev machine, with a copy of your database on the dev machine which gets stolen – that's an extremely common vector, that's a vector you need to be aware of and try to take actions against. It's also true for backup security, so whenever you're backing up your data, you need to be backing it up encrypted, you need to be backing up to a secure location. A lot of times this data that was really protected in the database, as soon as it starts getting out into periphery locations, onto dev machines, onto test machines, we get a little bit less careful about the patching, we get a little bit less careful about the people who have access to it. The next thing you know, you've got unencrypted database backups stored on a public share in your organization available for exploitation from a lot of different people. So, think about physical security and just as simple as, can somebody walk up and just put a USB key into your server? You should not be allowing that.
Next item I want you to think about is platform security, so up-to-date OS, up-to-date patches. It's very tiresome to hear people talking about staying on older versions of Windows, older versions of SQL Server, thinking that the only cost in play is the cost of the licensing upgrade, which is not the case. We are with security, it's a stream that keeps going down the hill and as time goes on, more exploits are found. Microsoft in this case, and other groups as the case may be, they will update older systems to a point, and eventually they will fall out of support and they won't be updating them anymore, because it's just a never-ending process of maintenance.
And so, you need to be on a supported OS and you need to be up to date on your patches, and we've found recently like with Shadow Brokers, in some cases Microsoft may have insight into upcoming major security breaches, prior to them being made public, prior to disclosure, so don't let yourself get all twisted out of order. I'd rather not take the downtime, I'd rather wait and read each one of them and decide. You may not know what the value of it is until some weeks down the line after you find out why this patch occurred. So, stay on top of that.
You should have your firewall configured. It was shocking in the SNB breach how many people were running older versions of SQL Server with the firewall completely open to the internet, so anybody could get in and do whatever they wanted to with their servers. You should be using a firewall. The fact that you occasionally have to configure the rules or make specific exceptions for the way that you're doing your business is an OK price to pay. You need to control the surface area in your database systems – are you co-installing services or web servers like IIS on the same machine? Sharing the same disk space, sharing the same memory space as your databases and your private data? Try not to do that, try to isolate it, keep the surface area smaller, so that you're not having to worry so much about making sure all of that is secure on top of the database. You can kind of physically separate those, platform, separate them, give yourself a little bit of breathing room.
You should not be having super admins running around everywhere able to have access to all your data. The OS admin accounts may not necessarily need to have access to your database, or to the underlying data in the database via encryption, which we'll talk about in a minute. And the access to the database files, you need to restrict that as well. It's kind of silly if you were to say, well, somebody can't access these databases via the database; SQL Server itself won't allow them to access it, but if then they can go around, take a copy of the actual MDF file, move it over simply so, attach it to their own SQL Server, you haven't really accomplished very much.
Encryption, so encryption is that famous two-way sword. There's a lot of different levels of encryption that you can do at the OS level and the contemporary way of doing things for SQL and Windows is with BitLocker and at the database level it's called TDE or transparent data encryption. So, these are both ways to kind of keep your data encrypted at rest. If you want to keep your data encrypted more comprehensively, you can do encrypted – sorry, I've kind of stepped ahead. You can do encrypted connections so that whenever it's in transit, it's still encrypted so that if someone is listening in, or has a man in the middle of an attack, you've got some protection of that data over the wire. Your backups need to be encrypted, like I said, they might be accessible to others and then, if you want it to be encrypted in memory and during use, we've got column encryption and then, SQL 2016 has this notion of “always encrypted” where it's actually encrypted on disk, in memory, on the wire, all the way to the application that is actually making use of the data.
Now, all this encryption is not free: There's CPU overhead, there's sometimes for the column encryption and the always-encrypted case, there's implications on performance in terms of your ability to do seeks on that data. However, this encryption, if it's properly put together, then it means that if someone were to get access to your data, the damage is greatly lessened, because they were able to get it and then they are not able to do anything with it. However, this is also the way in which ransomware works, is that someone goes in and turns these items on, with their own certificate or their own password and you don't have access to it. So, that's why it's important to make sure that you're doing this, and you have access to it, but you're not giving it, open for others and attackers to do.
And then, security principles – I'm not going to belabor this point, but make sure that you don't have every user running in SQL Server as super admin. Your developers may want it, different users may want it – they're frustrated by having to ask for access for individual items – but you need to be diligent about that, and even though it might be more complicated, give access to the objects and the databases and the schemas that are valid for ongoing work, and there's a special case, maybe that means a special login, it doesn't necessarily mean an elevation of rights, for the average case user.
And then, there's regulatory compliance considerations which dovetail into this and some cases might actually kind of go off in their own way – so there's HIPAA, SOX, PCI – there's all these different considerations. And when you go through an audit, you're going to be expected to show that you are taking actions to remain in compliance with this. And so, this is a lot to keep track of, I would say as a DBA to-do list, you're trying to ensure the security physical encryption configuration, you're trying to make sure that access to that data is being audited for your compliance purposes, making sure that your sensitive columns, that you know what they are, where they are, which ones you should be encrypting and watching access to. And making sure that configurations are in alignment with the regulatory guidelines that you are subject to. And you have to keep this all up to date as things are changing.
So, it's a lot to do, and so if I were to leave it just there, I would say go do that. But there's a lot of different tools for that, and so, if I may in the last few minutes, I wanted to show you some of the tools we have at IDERA for that. And the two I wanted to speak about today are SQL Secure and SQL Compliance Manager. SQL Secure is our tool to help identify kind of the configuration vulnerabilities. Your security policies, your user permissions, your surface area configurations. And it has templates to help you comply with different regulatory frameworks. That by itself, that last line, might be the reason for people to consider it. Because reading through these different regulations and identifying what those mean, PCI and then taking that all the way down to my SQL Server in my shop, that's a lot of work. That's something that you could pay a lot of consulting money to do; we have gone and done that consulting, we've worked with the different auditing companies, etc., to come up with what those templates are – something that's likely to pass an audit if these are in place. And then you can use those templates and see them, in your environment.
We also have another, kind of sister tool in the form of SQL Compliance Manager, and this is where SQL Secure is about configuration settings. SQL Compliance Manager is about seeing what was done by whom, when. So, it's auditing, so it allows you to monitor activity as it's occurring and let you detect and track who is accessing things. Was somebody, the prototypical example being a celebrity checked into your hospital, was somebody going and looking up their information, just out of curiosity? Did they have a reason to do so? You can take a look at the audit history and see what was going on, who was accessing those records. And you can identify this has tools to help you identify sensitive columns, so you're not necessarily having to read through and do that all yourself.
So, if I may, I'm going to go ahead and show you some of those tools here in these last few minutes – and please don't consider it as an in-depth demo. I am a product manager, not a sales engineer, so I'm going to show you some of the things that I think are relevant to this discussion. So, this is our SQL Secure product. And as you can see here, I've got kind of this high-level report card. I ran this, I think, yesterday. And it shows me some of the things that are not set up correctly and some of the things that are set up correctly. So, you can see there's quite a number of over 100 different checks that we've done here. And I can see that my backup encryption on the backups I've been doing, I've not been using backup encryption. My SA account, explicitly named “SA account” is not disabled or renamed. The public server role has permission, so these are all things that I might want to look at changing.
I've got the policy set up here, so if I wanted to set up a new policy, to apply to my servers, we've got all of these built-in policies. So, I'll use an existing policy template and you can see I have CIS, HIPAA, PCI, SR and going on, and we actually are in the process of continuously adding additional policies, based on the things people need out in the field. And you can also create a new policy, so if you know what your auditor is looking for, you can create it yourself. And then, when you do so, you can choose amongst all of these different settings, which what you need to have set, in some cases, you have some— let me go back and find one of the pre-built ones. This is convenient, I can choose, say, HIPAA – I've already got HIPAA, my bad – PCI, and then, as I'm clicking around in here, I can actually see the external cross-reference to the section of the regulation that this is related to. So that will help you later, when you're trying to figure out why am I setting this? Why am I trying to look at this? What section is this related to?
This also has a nice tool in that it lets you go in and browse your users, so one of the tricky things about exploring your user roles, is that, actually, I'm going to take a look here. So, if I show permissions for my, let's see, let's pick a user here. Show permissions. I can see the assigned permissions for this server, but then I can click down here and calculate the effective permissions, and it'll give me the full list based on, so in this case this is admin, so it's not that exciting, but I could go through and pick the different users and see what their effective permissions are, based on all of the different groups that they might belong to. If you ever try to do this on your own, it can actually be a bit of a hassle, to figure out, OK this user is a member of these groups and therefore has access to these things via groups, etc.
So, the way that this product works, is it takes snapshots, so it's really not a very difficult process of taking a snapshot of the server on a regular basis and then it keeps those snapshots over time so that you can compare for changes. So, this is not a continuous monitoring in the traditional sense of like a performance monitoring tool; this is something that you might have set up to run once per night, once per week – however often you think is valid – so that then, whenever you're doing the analysis and you're doing a bit more, you're actually just working within our tool. You're not connecting back to your server so much, so this is a pretty nice little tool to work with, for getting in compliance with those kind of static settings.
The other tool I want to show you is our Compliance Manager tool. Compliance Manager is going to monitor in a more continuous way. And it's going to see who's doing what on your server and allow you to take a look at it. So, what I've done here, in the last couple hours or so, I've actually tried to create some little problems. So, here I've got whether it's a problem or not, I might know about it, somebody has actually created a login and added it to a server role. So, if I go in and take a look at that, I can see— I guess I can't right click there, I can see what's going on. So, this is my dashboard and I can see I had a number of failed logins a little earlier today. I had a bunch of security activity, DBL activity.
So, let me go over to my audit events and take a look. Here I've got my audit events grouped by category and target object, so if I take a look at that security from earlier, I can see DemoNewUser, this create server login occurred. And I can see that the login SA created this DemoNewUser account, here, at 2:42 p.m. And then, I can see that in turn, add login to server, this DemoNewUser was added to the server admin group, they were added to the setup admin group, they were added to the sysadmin group. So, that's something that I would want to know had happened. I've also got it set up so that the sensitive columns in my tables are being tracked, so I can see who has been accessing it.
So, here I've got a couple of selected that have occurred on my person table, from Adventure Works. And I can take a look and see that user SA on the Adventure Works table did a select top ten star from person dot person. So maybe in my organization I don't want people to do select stars from person dot person, or I'm expecting only certain users to do so, and so I'm going to see this in here. So, the— what you need in terms of your auditing, we can set that up based on the framework and this is a bit more of an intensive tool. It is using SQL Trace, or SQLX events, depending on the version. And it's something that you're going to have to have some headroom on your server to accommodate, but it's one of those things, kind of like insurance, which is nice if we didn't have to have car insurance – it would be a cost that we wouldn't have to take – but if you do have a server where you need to keep track of who's doing what, you might have to have a little bit extra headroom and a tool like this to do this. Whether you're using our tool or you're rolling it yourself, you're ultimately going to be responsible for having this information for regulatory compliance purposes.
So like I said, not an in-depth demo, just a quick, little summary. I also wanted to show you a quick, little free tool in the form of this SQL Column Search, which is something that you can use to identify what columns in your environment appear to be sensitive information. So, we have a number of search configurations where it's looking for the different names of columns that are commonly containing sensitive data, and then I've got this whole list of them that have been identified. I've got 120 of them, and then I exported them here, so that I can make use of them to say, let's go look and make sure that I'm tracking access to the middle name, one person dot person or sales tax rate, etc.
I know we're getting right at the end of our time here. And that is all that I actually had to show you, so any questions for me?
Eric Kavanagh: I do have a couple of good ones for you. Let me scroll this up here. One of the attendees was asking a really good question. One of which is asking about the performance tax, so I know it varies from solution to solution, but do you have any general idea of what the performance tax is for using IDERA security tools?
Vicky Harp: So, on the SQL Secure, like I said, it's very low, it's just going to take some occasional snapshots. And even if you have been running pretty often, it's getting static information about settings, and so it's very low, almost negligible. In terms of Compliance Manager, it is—
Eric Kavanagh: Like one percent?
Vicky Harp: If I had to give a percent number, yeah, it would be one percent or lower. It's basic information on the order of using SSMS and going into the security tab and expanding things. On the Compliance side, it's much higher – that's why I said it needs a little headroom – it's sort of like it's well beyond what you have in terms of performance monitoring. Now, I don't want to scare people away from it, the trick with Compliance monitoring, and if it's auditing is to make sure you're only auditing what you're going to be taking action on. So, once you filter down to say, “Hey, I want to know when people access these particular tables, and I want to know whenever people access, take these particular actions,” then it's going to be based on how often are these things happening and how much data are you generating. If you say, “I want the full SQL text of every select that ever happens on any of these tables,” that's just going to be possibly gigabytes and gigabytes of data that are having to be parsed by SQL Server stored moved to our product, etc.
If you keep it down to a— it's also going to be more information than you could probably deal with. If you could take it down to a smaller set, so that you're getting a couple hundred events per day, then that's obviously much lower. So, really, in some ways, the sky's the limit. If you turn on all settings on all monitoring for everything, then yes, it's going to be a 50 percent performance hit. But if you're going to turn it onto kind of more moderate, considered level, I would maybe eyeball 10 percent? It really, it's one of those things that it's going to be very dependent on your workload.
Eric Kavanagh: Yeah, right. There's another question about hardware. And then, there's hardware vendors getting into the game and really collaborating with software vendors and I answered through the Q&A window. I know of one particular case, of Cloudera working with Intel where Intel made that huge investment in them, and part of the calculus was that Cloudera would get early access to chip design, and thus be able to bake security into the chip level of the architecture, which is pretty impressive. But it's nonetheless, it's something that's going to get out there, and still can be exploited by both sides. Do you know of any trends or any tendencies of hardware vendors to collaborate with software vendors on security protocol?
Vicky Harp: Yeah, actually, I believe that Microsoft has collaborated in order to have some of, like, the memory space for some of the encryption work is actually happening on separate chips on motherboards that are separate from your main memory, so that some of that stuff is physically separated. And I believe that that actually was something that came from Microsoft in terms of going out to the vendors to say, “Can we come up with a way to make this, basically it's unaddressable memory, I can't through a buffer overflow get to this memory, because it's not even there, in some sense, so I do know that some of that is happening.”
Eric Kavanagh: Yeah.
Vicky Harp: That's going to be obviously the really big vendors, most likely.
Eric Kavanagh: Yeah. I'm curious to watch for that, and maybe Robin, if you have a quick second, I'd be curious to know your experience over the years, because again, in terms of hardware, in terms of the actual material science that goes into what you're putting together from the vendor side, that information could go to both sides, and theoretically we go to both sides fairly quickly, so is there some way to use the hardware more carefully, from a design perspective to bolster security? What do you think? Robin, are you on mute?
Robin Bloor: Yeah, yeah. I'm sorry, I'm here; I'm just pondering the question. To be honest, I haven't got an opinion, it's an area that I haven't looked at in significant depth, so I'm kind of, you know, I can invent an opinion, but I don't really know. I prefer things to be secure in software, it's just the way that I play, basically.
Eric Kavanagh: Yeah. Well, folks, we've burned through an hour and change here. Big thanks to Vicky Harp for her time and attention – for all of your time and attention; we appreciate you showing up for these things. It's a big deal; it's not going to go away anytime soon. It's a cat-and-mouse game that's going to keep on going and going and going. And so we're thankful that some companies are out there, focused on enabling security, but as Vicky even alluded to and talked about a bit in her presentation, at the end of the day, it's people in organizations who need to think very carefully about these phishing attacks, that kind of social engineering, and hold onto your laptops – don't leave it at the coffee shop! Change your password, do the basics, and you're going to get 80 percent of the way there.
So, with that, folks, we're going to bid you farewell, thank you once again for your time and attention. We'll catch up to you next time, take care. Bye bye.
Vicky Harp: Bye, thank you.