December 12, 2015 at 11:35 am
Comments posted to this topic are about the item Security Decisions
December 13, 2015 at 12:21 pm
It might be helpful to know when we should be concerned about this. Presumably most everyone knows about SQL injection. But is writing an ordinary select statement stored procedure something to be concerned about? Are we just talking about authentication points?
It's hard to know about everything. Good articles that give specific examples can help.
December 14, 2015 at 3:37 am
My interpretation on this editorial is that it is about taking responsibility for those machines under our control (and perhaps highlighting the issue to the appropriate people when they are not).
I have been wary regarding using encryption on my personal laptop but I wouldn't be overly concerned with what they could access, however, I do believe that it has got to the point in time where there is no longer a reason not to as long as you have appropriate data backups external to the device being encrypted.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 14, 2015 at 4:09 am
My interpretation on this editorial is that it is about taking responsibility for those machines under our control
That's helpful. I've been experimenting with encryption on my personal machine and will soon experiment with encrypting the SQL server data at rest on my personal development machine. If this is the case, strong passwords and good password control are a part of it either.
December 14, 2015 at 9:00 am
Sadly it is on the job training at best.
When Windows was riddled with buffer overrun vulnerabilities I hunted high and low for a good article on "how not to write code that is vulnerable to buffer overruns". Sadly I never found one.
I'd love there to be something on how to be specific about the permissions required for an install of SQL Server, SSIS, SSAS, SSRS etc as separate machines.
I have not found security guys to be particularly helpful. They are good at pointing out the flaws but not so good at working towards a fix.
December 14, 2015 at 9:18 am
RonKyle (12/13/2015)
It might be helpful to know when we should be concerned about this. Presumably most everyone knows about SQL injection. But is writing an ordinary select statement stored procedure something to be concerned about? Are we just talking about authentication points?It's hard to know about everything. Good articles that give specific examples can help.
Many people don't know about SQL Injection,or their coding habits/framework doesn't prevent it.
However I think that we should question the way we implement security and post notes/have debates about how well our code is built.
A simple select includes multiple security points. I may miss some, but there are
- the network layer
- the authentication to SQL Server
- mapping the login to a user
- user rights to objects, perhaps from group membership
- data handling on the client
We should be careful in how we implement these, and ensure that we minimize risk. I'm not completely confident that I understand where I might make mistakes in these areas. I think I do well, but certainly as a codebase grows, database grows, and we enable greater access, we can introduce holes.
December 14, 2015 at 9:19 am
David.Poole (12/14/2015)
Sadly it is on the job training at best.When Windows was riddled with buffer overrun vulnerabilities I hunted high and low for a good article on "how not to write code that is vulnerable to buffer overruns". Sadly I never found one.
I'd love there to be something on how to be specific about the permissions required for an install of SQL Server, SSIS, SSAS, SSRS etc as separate machines.
I have not found security guys to be particularly helpful. They are good at pointing out the flaws but not so good at working towards a fix.
agree
December 14, 2015 at 9:26 am
We need more details on the cost of compliance versus the cost of non compliance. Hard and soft values.
There is risk all around, we need to know if the way we are handling those risks makes economic sense.
412-977-3526 call/text
December 14, 2015 at 9:42 am
RonKyle (12/13/2015)
... Presumably most everyone knows about SQL injection. ...
The children's toy maker VTech was hacked in November via SQL Injection. VTech had NO SSL on their site: aside from the ease of sucking everything through SQL Injection, you could also simply listen to their network traffic.
VTech recently posted this:"
In total 4,854,209 customer (parent) accounts and 6,368,509 related kid profiles worldwide are affected. Among those approximately 6.3 million kid profiles, approximately 1.2 million of them have Kid Connect app enabled. Kid profiles only include name, gender and birthdate.
6.3 MILLION KID PROFILES[/B] But don't worry, only their name, gender, and birthdate were compromised. Not important things like their parent's address. After all, how may kids live with their parents?
Yeah, I'd say it's a problem. For some reason I think that VTech toys may not be best sellers this Xmas season.
http://www.troyhunt.com/2015/11/when-children-are-breached-inside.html
https://www.vtech.com/en/press_release/2015/faq-about-data-breach-on-vtech-learning-lodge/
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
December 14, 2015 at 10:09 am
Wayne West (12/14/2015)
...Yeah, I'd say it's a problem. For some reason I think that VTech toys may not be best sellers this Xmas season...
Unfortunately, I believe that parents will keep on buying in their ignorance (not an accusation against parents).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 15, 2015 at 3:59 pm
Wayne West (12/14/2015)
VTech had NO SSL on their site: aside from the ease of sucking everything through SQL Injection, you could also simply listen to their network traffic.
......:angry: You'd hope that selective breeding would keep this sort of thing to a minimum.
Encryption algorithms are built into CPU cores so there is no valid argument for excluding SSL. Even if the information was in no way personal I would have thought the marketing value of a visible safe site icon in the browser of choice would be worth having for a kids company.
I've had to learn so much over the past few months about AWS, Network ACLS, Security Groups, Subnets, Routing tables, password safes, SSH Keys, LDAP, Active Directory. My head hurts but I've gained a lot from it.
I've also learnt that, just like DBA concerns, security isn't a shiny ball therefore gaining approval for investing in tooling and education is a tough sell.
Frankly that incompetence of Talk Talk and Vtech are a gift from the Gods for security guys. Finally a great big shitty stick to wield.
December 15, 2015 at 4:43 pm
They've arrested the apparent VTech hacker: a 21 year old Brit. Apparently he is a bit of a hacker who stumbled upon some information, started scratching, and got in a lot deeper than he expected. He claims he had no intention of releasing the information unfortunately one way or another it did get out in to the wild.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
December 15, 2015 at 10:10 pm
It is not only code we need to pay attention to. Language features we choose to employ and system administration choices can also lead to insecure environments. Cross-system risks are important especially when looking at combinations of entitlements or implicit rights via impersonation of service accounts.
Regarding the comments about security guys pointing out flaws but not solutions...I find it analog to expecting QA testers to write books on how to be better coders. The incentives are not there for most. The payoff is in finding flaws not in preventing them. It's a self-preservation and job-justification issue.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
December 16, 2015 at 8:20 am
Wayne West (12/15/2015)
They've arrested the apparent VTech hacker: a 21 year old Brit. Apparently he is a bit of a hacker who stumbled upon some information, started scratching, and got in a lot deeper than he expected. He claims he had no intention of releasing the information unfortunately one way or another it did get out in to the wild.
Apparently hackers don't think about protecting their data, either. 😛
December 30, 2015 at 11:45 am
David.Poole (12/14/2015)
Sadly it is on the job training at best.When Windows was riddled with buffer overrun vulnerabilities I hunted high and low for a good article on "how not to write code that is vulnerable to buffer overruns". Sadly I never found one.
It's remarkably easy to write such code: just use a language where it can't happen. On an Os that won't make it happen. On hardware that won't allow it to happen.
Such languages used to be popular, but then C happened and C++.
There were some operating systems that wouldn't do it to you - they wouldn't transfer a 1000 character input "into" a 32 byte buffer when you asked for the next 32 bytes from the teletype.
Hardware that directly supports bounded arrays (such as ICL's 2900 series and later, and Burroughs mainframes at the same time) used to be popular, but hardware without that protection was cheaper (fewer gates to fit into the chipset). It's also nice if the hardware makes executable code segments read only because that makes buffer overruns much less dangerous (both ICL and Burroughs were doing that by about 1970, so those two had both belt and braces, but no-one else was).
Ideally the hardware should assist the software with location randomisation for all segments (because that also tends to wreck buffer overrun attacks - so don't allow McAfee or Kapersky on your machine, as both are antagonistic to that randomisation and both insist on writable executable segments - or maybe they've fixed that since various experts confirmed Microsoft's calling them out on that). A lot of hardware today both assists location randomisation and provides read-only executable segments, but most operating systems ignore it (Microsoft's newer stuff uses it, but I'm not up to date enough to say who else does).
I'd love there to be something on how to be specific about the permissions required for an install of SQL Server, SSIS, SSAS, SSRS etc as separate machines.
I have not found security guys to be particularly helpful. They are good at pointing out the flaws but not so good at working towards a fix.
Maybe you can tell from my rant above that at most times in history advice to avoid buffer overflow (exept for the trivial advice to check the lengths before copying from buffer A to buffer B - and even doing that was often deprecated as a performance cost) had to be advice to use something other than the latest overhyped programming language (C or C++) running on something other that the latest overhyped OS (Únix, or IBM) and using something other than the most popular (because it saved money by leaving security out) hardware. Needless to say that advice would have been ignored - the accountants would see security as a cost, not as a benefit, and that would kill it.
I was never a security expert myself, but from the times when the security buck stopped at my desk, from my (very limited) security training, and from my fairly extensive training in error management (after all, buffer overflow is an error like any other erroe, its effects should be contained, there should be recovery from it, and it should be reported) I know exactly why the security experts appear to you to be unhelpful.
Tom
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply