SQLServerCentral.com / Editorials / SQLServerCentral.com / More Data Security Issues / Latest PostsInstantForum.NET v2.9.0SQLServerCentral.comhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 31 Mar 2015 15:23:24 GMT20RE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]djackson 22568 (6/26/2013)[/b][hr][quote][b]Eric M Russell (6/26/2013)[/b][hr]I don't think that Microsoft can be faulted for insecure data. The database, network, and operating system framework that Microsoft has provided us is solid when it comes to security. For example, I've heard from security experts that SQL Server is much easier to lock down and has had fewer security holes when compared to Oracle and other products. Data security is also not about decisions made by the board of directors at the organzation. Really, if you look at news stories about data breaches, the plot is the same: 1. Some guy who couldn't be trusted had unrestricted access to the database2. SQL injection3. Some developer copied down the database to their laptop and then lost it. These things can be prevented using role based security, properly coded SQL in the application, and enforcing restriction policies on the windows workstations. Microsoft has given is the tools we need. I hate to say it, but it's mostly about ignorance on the part of IT staff, primarily the developers and DBA.[/quote]Not what I said. What I said was Microsoft changed the game. Developers are partly at fault, but Microsoft changes their design requirements as often as some people change shoes! I do feel for the developers who have to completely redesign something because some idiot in Marketing at Microsoft thinks they can make more money by doing something different. I also feel for them when changes are made to make products more secure. I hate to say it, but the fact remains that Microsoft originally left out any thoughts about making things secure, and only recently made progress on that front, so yes, they are partly to blame. I am by no means a hater of Microsoft, but I am not going to sugar coat things either.There are many reasons behind these issues, not just lazy developers.[/quote]SQL injection, user accounts with SYSADMIN access to production, lost laptops containing social security numbers: I don't think that the marketing department of Microsoft, an organization's board of directors, or even the organization's executive management are responsible for that. There is also little they can do to mitigate that, becuase the proper solutions have been around for decades. It all boils down to developers and DBAs making bad choices, not following widely accepted best practices.Thu, 27 Jun 2013 06:54:07 GMTEric M RussellRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]djackson 22568 (6/26/2013)[/b][hr][quote][b]Eric M Russell (6/26/2013)[/b][hr]I don't think that Microsoft can be faulted for insecure data. The database, network, and operating system framework that Microsoft has provided us is solid when it comes to security. For example, I've heard from security experts that SQL Server is much easier to lock down and has had fewer security holes when compared to Oracle and other products. Data security is also not about decisions made by the board of directors at the organzation. Really, if you look at news stories about data breaches, the plot is the same: 1. Some guy who couldn't be trusted had unrestricted access to the database2. SQL injection3. Some developer copied down the database to their laptop and then lost it. These things can be prevented using role based security, properly coded SQL in the application, and enforcing restriction policies on the windows workstations. Microsoft has given is the tools we need. I hate to say it, but it's mostly about ignorance on the part of IT staff, primarily the developers and DBA.[/quote]Not what I said. What I said was Microsoft changed the game. Developers are partly at fault, but Microsoft changes their design requirements as often as some people change shoes! I do feel for the developers who have to completely redesign something because some idiot in Marketing at Microsoft thinks they can make more money by doing something different. I also feel for them when changes are made to make products more secure. I hate to say it, but the fact remains that Microsoft originally left out any thoughts about making things secure, and only recently made progress on that front, so yes, they are partly to blame. I am by no means a hater of Microsoft, but I am not going to sugar coat things either.There are many reasons behind these issues, not just lazy developers.[/quote]I guess we all have to accept that the industry, in general, was somewhat lax regarding security (myself included). I feel that once the Internet became prevalent in use and that more and more valuable data was collected that suddenly it was easy to get something worthwhile.Thu, 27 Jun 2013 06:24:03 GMTGary VargaRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]Eric M Russell (6/26/2013)[/b][hr]I don't think that Microsoft can be faulted for insecure data. The database, network, and operating system framework that Microsoft has provided us is solid when it comes to security. For example, I've heard from security experts that SQL Server is much easier to lock down and has had fewer security holes when compared to Oracle and other products. Data security is also not about decisions made by the board of directors at the organzation. Really, if you look at news stories about data breaches, the plot is the same: 1. Some guy who couldn't be trusted had unrestricted access to the database2. SQL injection3. Some developer copied down the database to their laptop and then lost it. These things can be prevented using role based security, properly coded SQL in the application, and enforcing restriction policies on the windows workstations. Microsoft has given is the tools we need. I hate to say it, but it's mostly about ignorance on the part of IT staff, primarily the developers and DBA.[/quote]Not what I said. What I said was Microsoft changed the game. Developers are partly at fault, but Microsoft changes their design requirements as often as some people change shoes! I do feel for the developers who have to completely redesign something because some idiot in Marketing at Microsoft thinks they can make more money by doing something different. I also feel for them when changes are made to make products more secure. I hate to say it, but the fact remains that Microsoft originally left out any thoughts about making things secure, and only recently made progress on that front, so yes, they are partly to blame. I am by no means a hater of Microsoft, but I am not going to sugar coat things either.There are many reasons behind these issues, not just lazy developers.Wed, 26 Jun 2013 13:17:19 GMTdjackson 22568RE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxI don't think that Microsoft can be faulted for insecure data. The database, network, and operating system framework that Microsoft has provided us is solid when it comes to security. For example, I've heard from security experts that SQL Server is much easier to lock down and has had fewer security holes when compared to Oracle and other products. Data security is also not about decisions made by the board of directors at the organzation. Really, if you look at news stories about data breaches, the plot is the same: 1. Some guy who couldn't be trusted had unrestricted access to the database2. SQL injection3. Some developer copied down the database to their laptop and then lost it. These things can be prevented using role based security, properly coded SQL in the application, and enforcing restriction policies on the windows workstations. Microsoft has given is the tools we need. I hate to say it, but it's mostly about ignorance on the part of IT staff, primarily the developers and DBA.Wed, 26 Jun 2013 12:25:02 GMTEric M RussellRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]mtucker-732014 (6/25/2013)[/b][hr]This is a problem in many businesses and I believe stems from the near universal idea that a business should maximise shareholder value ahead of value generated for other stakeholders (customers, employees, the community). This is justified by the mistaken idea that shareholders are the only stakeholders who are exposed to any risk in the enterprise.Too many people have experienced (either directly, or having seen it happen to people they know) a company saying 'we value loyalty' at the interview and then forcing redundancy on employees at the first sign of difficulty.[/quote]Much of this is definitional. Improving stakeholder value can often improve shareholder value, or it cannot. Using one statement without the other, and without context is where we get into issues.Also, do we want to improve value today (this quarter, this year), or the long term? Some of what David noted above is that people look to short term value more than long term value. Long term you develop more robustly and realize that security decisions can affect you later. Short term, do what MS says and eff it if it's wrong.Wed, 26 Jun 2013 10:44:02 GMTSteve Jones - SSC EditorRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]Eric M Russell (6/25/2013)[/b][hr][quote][b]djackson 22568 (6/25/2013)[/b][hr]I agree that developers need to get better at using proper techniques.That said, companies are the real root cause of poor software. The opposition to allowing time to code, test and validate is the largest issue. I know a lot of developers that WANT TO write better code, but are not allowed to.[/quote]Developers may be a members of DBO or even SYSADMIN when they login to development database using their domain account. They need that for creating tables, procedures, etc. However, when unit testing or performing QA, they should login using a seperate account that has the same name and least privillages as the application account (should have) in production. If testing is not done under a least privillage account like this, then many organization will punt and grant full DBO or SYSADMIN rights to the application account.[/quote]Yep.My organization is engaged in upgrading to Windows 7 due to XP support ending next year. (Note the guy in charge was not even aware of this until I brought it up!) The majority of our applications were built and sold to us requiring the end user be a local admin on the PC. They will not support us if there are issues unless the user is an admin, and in most cases, the app will not function without those rights.We can blame the vendors, and they do have some responsibility for the poor design, but we also need to look at Microsoft recomendations over time. Back in the 3.1 days, INI files stored user preferences. Microsoft changed to recommend using the registry. As security became more of a front line issue, they changed recommendations again. Basically there are a number of reasons why things are so bad.Wed, 26 Jun 2013 10:11:58 GMTdjackson 22568RE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxThis is a problem in many businesses and I believe stems from the near universal idea that a business should maximise shareholder value ahead of value generated for other stakeholders (customers, employees, the community). This is justified by the mistaken idea that shareholders are the only stakeholders who are exposed to any risk in the enterprise.Too many people have experienced (either directly, or having seen it happen to people they know) a company saying 'we value loyalty' at the interview and then forcing redundancy on employees at the first sign of difficulty.Tue, 25 Jun 2013 20:19:21 GMTmtucker-732014RE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]djackson 22568 (6/25/2013)[/b][hr]I agree that developers need to get better at using proper techniques.That said, companies are the real root cause of poor software. The opposition to allowing time to code, test and validate is the largest issue. I know a lot of developers that WANT TO write better code, but are not allowed to.[/quote]Developers may be a members of DBO or even SYSADMIN when they login to development database using their domain account. They need that for creating tables, procedures, etc. However, when unit testing or performing QA, they should login using a seperate account that has the same name and least privillages as the application account (should have) in production. If testing is not done under a least privillage account like this, then many organization will punt and grant full DBO or SYSADMIN rights to the application account.Tue, 25 Jun 2013 14:52:53 GMTEric M RussellRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxI agree that developers need to get better at using proper techniques.That said, companies are the real root cause of poor software. The opposition to allowing time to code, test and validate is the largest issue. I know a lot of developers that WANT TO write better code, but are not allowed to.Tue, 25 Jun 2013 13:22:51 GMTdjackson 22568RE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]Gary Varga (6/25/2013)[/b][hr][quote][b]Eric M Russell (6/25/2013)[/b][hr]By and large, employees are granted more access to data than they really need to perform their job functions. I'm surprised when people talk about a database with dozens or hundreds of users. Do individual users really need access to the database?All you need are a handful of service accounts, one for each security role. Users should access data via the application, and auditing is used to keep track of what requests users make.[/quote]This is another cost of the departmental Access/Excel application.Also a cost of the lack of ethics in business from top to bottom. I particularly see people being forced (or pressured is probably more fair) to stay longer than both necessary to perform their job and longer than agreed (by employment contract). This results in people using some of their time at their desks for their own purposes, if only training.[/quote]It's late in the evening, an employee is disgruntled about being asked to work overtime, and they have an open query window with select permission on every table in the database, if not full sysadmin privillage. It's a bad scenario, and employee training won't fix it. It's management and sysadmins who need to be trained on how to avoid this.Tue, 25 Jun 2013 10:44:28 GMTEric M RussellRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]Eric M Russell (6/25/2013)[/b][hr]By and large, employees are granted more access to data than they really need to perform their job functions. I'm surprised when people talk about a database with dozens or hundreds of users. Do individual users really need access to the database?All you need are a handful of service accounts, one for each security role. Users should access data via the application, and auditing is used to keep track of what requests users make.[/quote]This is another cost of the departmental Access/Excel application.Also a cost of the lack of ethics in business from top to bottom. I particularly see people being forced (or pressured is probably more fair) to stay longer than both necessary to perform their job and longer than agreed (by employment contract). This results in people using some of their time at their desks for their own purposes, if only training.Tue, 25 Jun 2013 10:16:36 GMTGary VargaRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxBy and large, employees are granted more access to data than they really need to perform their job functions. I'm surprised when people talk about a database with dozens or hundreds of users. Do individual users really need access to the database?All you need are a handful of service accounts, one for each security role. Users should access data via the application, and auditing is used to keep track of what requests users make.Tue, 25 Jun 2013 08:43:00 GMTEric M RussellRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspx[quote][b]IMHO (6/25/2013)[/b][hr]I'd be interested to know what the main motivation is for insider data breaches. Is it random vandalism, retaliation, greed, a sense that something the company is doing is wrong and needs to be exposed. Something else? I would also like to know how much data is secured that doesn't really need to be secured. I've met many people who seem to have a fixation on securing things that don't really need to be. Some DBAs tend to have a warrior mentality when there may not be any actual war.[/quote]I doubt it's one thing. In the restaurant business, we'd see lots of inside issues, and it ranged from vandalism (throwing things away) to theft/greed (stealing money or alcohol), but the latter might be because someone needs money (not making enough), or they feel entitled (they're not paying me enough) to fun (my friends and I want free drinks).Tue, 25 Jun 2013 07:58:46 GMTSteve Jones - SSC EditorRE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxI'd be interested to know what the main motivation is for insider data breaches. Is it random vandalism, retaliation, greed, a sense that something the company is doing is wrong and needs to be exposed. Something else? I would also like to know how much data is secured that doesn't really need to be secured. I've met many people who seem to have a fixation on securing things that don't really need to be. Some DBAs tend to have a warrior mentality when there may not be any actual war.Tue, 25 Jun 2013 07:55:10 GMTIMHORE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxThere has been a large decline in ethical leadership worldwide and a growing lack of loyalty towards employees and citizens. Considering this environment, it's pretty much a given that theft and breaches will happen. It doesn't help that our government discourages accountability and massively funds data theft. The problem with encryption and other measures is that people are lazy and management doesn't want to spend money on tools and training. When a large percentage of technical professionals I met don't even understand the basics of PKI and topics of that ilk, it's evident that the industry as a whole is only pay lip service to security and is cargo-culting on a minimal as needed basis.Tue, 25 Jun 2013 06:45:03 GMTchrisn-585491RE: More Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxIts a sad fact that a percentage of any population will be morally challenged.Another percentage will be opportunistic. If you had a piece of software and a licence key would you install it on your home kit. How about an illicit MP3, CD or DVD? For those of you who are legitimately outraged and indignant at the aspersion you are in a worrying small minority.Then there is the behaviour that manifests when a relationship breaks down.Years back I did a module on employee relations and a story (hopefully an urban legend/myth) was told about a dispute at a steel works. Apparently cyanide is routinely used in some processes and because of the dangers involved flasks of a liquid to counteract the effects of cyanide poisoning were within easy reach.In the event of cyanide poisoning speed is of the essence so the idea was that the liquid was drunk but the inevitable consequence was that the human body would expel whatever it could by whatever method it could via every pore and orrifice it could. During an acrimonious industrial dispute management learnt to fear the coffee urn, canteen food and the drinking fountain.Tue, 25 Jun 2013 01:33:57 GMTDavid.PooleMore Data Security Issueshttp://www.sqlservercentral.com/Forums/Topic1466488-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/100031/">More Data Security Issues</A>[/B]Sat, 22 Jun 2013 14:45:15 GMTSteve Jones - SSC Editor