JR already listed a few of the technical options, let me add eagle eye view:
.
Identify the threat as guesstimate possible cost to you / ROI of black hat:

logic found in your data (calculation tables)
customer data loss to competitor
customer data loss as in breached to darknet and risk from legal side

Local data (even if encrypted) are less secure, esp. to wholesale attacks
Internal bulk/query data from remote backend are in danger in all local exe
and even in web GUI if stored in array/cursor locally
(grids without storage of more data than seen +/- 1 Screen lessen danger, but need more backend calls)
Even web GUI can be screen scraped stepping single screen through available data

In addition to access rights you might think about quotas of data resulting from queries per time frame or similar protection against screen scraping. But as JR wrote, you can only make it harder for black hat.

Encryption always better when done remote in SQL backend or Data/Web server.
But with man-in-the-middle, keyb loggers and similar still possible to fish user for credentials locally.

>I am using a utility in Rick Strahl's classes to encrypt data strings. Works fine. The utility eventually calls .Net encryption routines.
>
>My question is: what would a person need for tools to be able to get the key for the encryption? My key is made up of a long "base" and then for each record in a table, it is unique. Of course, this key gets assembled right before each call into one string.
>
>Is there a way to capture this key even if it is in memory as a var just long enough to call the encryption/decryption routine? If so, what tool would do that? And does the hacker need my source code in order to step through the code to stop on the line that assembles the key? Or can someone just capture every line as it executes and look at the results with some low level debugger?
>
>Sorry, I just don't do this kind of low level work to know the answer.
>
>Thanks,
>Albert