Security is a big issue. There really are no short-cuts that can be taken with it at all. No magic bullet, no "if we focus on protecting x, then we're safe". The real idea is to balance the effort / reward ratio such that the business down the block is a more tempting target for miscreants.

In order to do this, you need to restrict the storage of user / client data to the absolute minimum amount essential to the running of your business. If this means customers have to enter credit card details more often, or have to setup direct debits for regular payments, so be it.

Once you've identified the bare minimum of information required, you need to ensure that you have done the basics to protect it. Things like multiple layers between your web gateway and your backend servers, using restricted accounts for everything (other than the very few individuals requiring root to maintain your systems and having company policies that very clearly state how and when those individuals should be using root access), firewalling the f**** out of your network (not just external interfaces, but internal (possibly departmental) segregation as well). Logging the heck out of anything and everything relating to security and access to sensitive infrastructure.

When you have everything locked down and logged, then you need to regularly review it. This might just mean internal reviews by appropriate staff, however if you are a large organisation, or hold particularly sensitive information, then you probably want to get external security specialists in to perform penetration testing and otherwise review your policies and procedures on a regular basis (we do this once a year, in addition to internal monitoring and reviews).

Beyond that, keep your eyes and ears open and try to learn from others mistakes.

EDIT: In response to your specific question about SQL, yes encrypting particularly sensitive data with an appropriate scheme is an absolute must (as it prevents attackers from simply copying out your DB and going their merry way - They have to take the time to figure out what you're doing, where keys are stored, etc). Designing security systems that take a long time to work out / hack into is a delaying tactic designed to give your monitoring team time to detect the intrusion.

In reply to Re: Effective database column level encryption? by SimonPratt
in thread Effective database column level encryption? by maruhige

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.