Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Sqlexec from vfp fails
Message
From
08/06/2016 06:58:51
 
 
To
06/06/2016 19:48:24
John Ryan
Captain-Cooker Appreciation Society
Taumata Whakatangi ..., New Zealand
General information
Forum:
Microsoft SQL Server
Category:
SQL syntax
Miscellaneous
Thread ID:
01636625
Message ID:
01637117
Views:
78
>>>(with p[ad] and p[us] in best cases close to 0, but p[ad] probably still lower due to more security measures and habits server side, but more users than admins)
>for attack vectors like keylogging after having infected one machine able to send SQL to the backend. For most scenarios the probability (1="total difficulty", inaccessible) server side will be higher. Slashing a couple of possible attack vectors is IMO worth some developer ease IMO.
>
>Recent reviews in healthcare say that keyloggers and other crimeware causes 1.4% of data breaches and cyber espionage 0.3%. Almost 50% of breaches are lost or stolen data. Not via applications, but mostly misuse of super access rights to create illicit data caches that get stolen. The biggest culprits are sysops and data analysts with direct access to data. Crucially, theft of an encrypted dataset is not counted as a breach, meaning that the biggest issue is people with super access repeatedly creating un-encrypted caches that get stolen.
>
>20% of breaches involve misuse of application access, most often serial inappropriate accesses by non-clinicians, while "error" including faxing or emailing to wrong addresses or loss of a thumb drive with patient info, is another 20%
>
>In view of the above, seems to me that security improvement has little to do with how the app accesses data. Biggest bang per buck has to involve securing the SA password/locking down super access rights so that illicit unencrypted caches can't keep being made, followed by peer review audit of all privileged users to help spot abuse via applications, followed by automated electronic transfer to avoid accidental faxing or emailing to wrong addresses. Typically the sysops will want to focus on the minnow security issues while keeping their own super access, but in view of the stats, the whole "do as I say, not as I do" theme needs to be looked at.

How would leaked info of any person available to access the DB count, if it includes personal info, perhaps even "other" pwd hashes (sometimes not even salted)?
Good chance of finding one user/pwd combo employing dictionary attack plus perhaps some site specific info and crafting specialized try outs for currently unknown target site pwd (common dictionary result plus DB-site specific info) IMO...
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform