If or When?

  • Comments posted to this topic are about the item If or When?

  • Added "security" is a mixed blessing. I've found that instead taking the time and expense of hardening features, some folks sometimes just make them go away.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Security is like insurance. It is more likely that it will not occur to you but you cover yourself regardless because the cost of not doing it when are attacked outweighs the cost of doing it even if it is never required.

    Also, it is like being chased by a bear: you don't have to be faster than the bear, just faster than at least one other person running with you.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Trust in god, but tie your camel first

    Everyone working in software should have long since learned the danger of assumptions. The preparations in that article, as pessimistic as they sound, simply reflect a conscious choice not to assume that some other element of the system will keep everything safe.

  • I'm not sure IT is all that effective in addressing security. I'd like to see the accountants involved more.

  • I believe that SQL Server already has the required features to implement auditing (SQL Server Audit and extended events), granular controls (permissions), and seperation of duties (database and server roles). There is also a tool Best Practices Analyzer that includes advice about security related configuration settings. I'm not sure if it's possible to add custom rules though. Virtually all DBAs know the features are there, but few put it into practice.

    So, what's really lacking is an IT industry accepted set of best practices, education about why it's a necessity, and top-down compliance. For the standards, the IT industry itself can drive this, and for the oversight and compliance, I (hate to) say that the government needs a bigger role.

    The government regulates how much weight can be stacked on a commercial truck, it regulates the temperature that restraunts and grocery stores maintain their frozen food, how surgical instruments should be cleaned, and 10,000 other things across most every industry, so why not personal data? I'm not saying that the government should hook into the network and look over people's shoulders or that they should make surprise onsite inspections. What I'm advocating is that the government mandate that:

    "This is the minimum standard by which specific types of data should be secured in a database or network, and if we find out you're not meeting the minimum standard, then there will be fines, or even jail, if we discover that you deliberately exposed or shared protected information."

    We already have this to an extent, but it could be broader, not just healthcare and financial organizations, and it could include requirements for specific best practices.

    If an organization collects data like credit card numers or person information about customers and then claims that they don't have the resources to properly secure that data, I mean basic stuff like secure connections and role based security, then... screw you. That right, I said screw you. You are menace to society.

    If a doctor or chef can take the time to clean and maintain the tools of their trade, then why not a DBA?

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Hackers are not going to try to hack all severs. They look for the easiest path. This is one area where it's best to be the ugly duckling at the dance. Make it as difficult as you can for hackers and they will leave you alone for someone easier and more attractive.

    As Eric said, it would be great to have industry standards for DBAs and developers. Who would set the standards? I don't know that the government would be the best choice. Do you want different standards for each vendor; Microsoft, IBM, Oracle, open source, etc."

    Tom

  • OCTom (4/10/2014)


    Hackers are not going to try to hack all severs. They look for the easiest path. This is one area where it's best to be the ugly duckling at the dance. Make it as difficult as you can for hackers and they will leave you alone for someone easier and more attractive.

    As Eric said, it would be great to have industry standards for DBAs and developers. Who would set the standards? I don't know that the government would be the best choice. Do you want different standards for each vendor; Microsoft, IBM, Oracle, open source, etc."

    Tom

    The standards would not have to be very technical. Dedicated sysadmin accounts, removal of service accounts from sysadmin role, seperation duties, application accounts with minimal privilege (ie: no ad-hoc sql and access only to required tables), encryption at rest for columns containing sensitive data, encrypted backups, encrypted connections between application and database layer: these basic best practices would apply to any enterprise database platform. If a database platform doesn't provide support, then the organization has simply chosen the wrong platform.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Just define legal requirements to be best endeavours. I think that most sectors where it counts there are further standards, for example in the UK we have the Data Protection Act (personal data), PCI (financial transaction aka payments) and we all seem to follow Sarbanes-Oxley. By legislating only the demand for best endeavours then we rely on the courts to apply it reasonably e.g. if I have a Solitaire scoreboard score that isn't encrypted then I would not expect any liability but medical records, bank account details etc. and I would expect protection by the law for any slackers.

    The grey area is the dumping grounds of data like DropBox or OneDrive which are just buckets.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (4/10/2014)


    Just define legal requirements to be best endeavours. I think that most sectors where it counts there are further standards, for example in the UK we have the Data Protection Act (personal data), PCI (financial transaction aka payments) and we all seem to follow Sarbanes-Oxley. By legislating only the demand for best endeavours then we rely on the courts to apply it reasonably e.g. if I have a Solitaire scoreboard score that isn't encrypted then I would not expect any liability but medical records, bank account details etc. and I would expect protection by the law for any slackers.

    The grey area is the dumping grounds of data like DropBox or OneDrive which are just buckets.

    I believe that major financial, healthcare, and government organizations stay on top of data security. Where it's still the wild west are data aggregators, small online retailers, and fly-by-night startups. Not only do I not trust their technical expertise, but many of them have a business model where they swap or sell data dumps with reckless disregard for the privacy. The government and media have their attention focussed on the larger corporations, but there are a lot of small companies collecting big data. God only knows who's running these outfits, what their business model or agenda is, and what best practices (if any) they follow. We need laws that provide blanket coverage of any organization, regardless of size or industry, that aggregates sensitive personal data.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • OCTom (4/10/2014)


    Hackers are not going to try to hack all severs. They look for the easiest or most rewarding path.

    fixed in bold.

    You can be really hard to get into, but if there is a strong incentive to hit you for either direct gain or the notoriety gained based on your name, not being easy isn't good enough.

  • I'm pro-"when".

    The reasoning is that if you propose security to the business as an "if" case, the answer is always, "no, that will never happen, because we're not a target - we don't have any enemies". Management doesn't understand that it's not a personal issue, that hackers can run automated attacks against anonymous targets, and desire either information or resources.

    Meanwhile, the IT approach is "if we firewall it, then there's no hope". Except things end up not being firewalled. Or the firewall goes down. Or the firewall gets hacked. Or whatever port is opened for the firewall gets hacked. Or someone VPNs in. Or a third party integrated data source is hacked.

    So, forget "if". Make it "when". What did we have in place to show that we did what we could to detect the intrusion quickly and minimize what could be siphoned out (with development, duh!) What do our contracts / policies entitle our clients to? Where's our backups if things get serious? What are we going to do?

    Of course. Few ever do. Though Australia just released new privacy policy legislation so that companies who didn't make any effort to secure their data are going to be in BIG trouble. Of course, it's going to take a few to go down in flames before the rest start investing in fixing all of the past hacks they've done to get around doing things properly.

  • In my humble opinion you should always prefer "when' over "if", that should be true for security as much as for recovery. With recovery the "when" scenario makes you practice bare metal restores to be prepared "when" disaster strikes, even "if" the changes are quite small that it will happen to you any time in the near future. In fact, you may be making backup copies of every data asset for years without a single occasion where you could not proceed without them.

    The same approach might become common for security breaches. You should take measures to minimize the risk, but also prepare for the event and set up proper procedures to act upon a breach. But the big difference with recovery is that it is not just a technical issue. For recovery you only need to convince the management that you need the resources (time being one of them) to be prepared, and the rest can be handled completely by the technical staff preferably without any interference of those non-technical-schooled managers. If you give us enough hardware, software and time, we'll ensure that everything can be recovered when disaster strikes. At least to a certain extend ...

    Security breaches require much broader attention. After putting a plug in the hole, you need to asses the risks of further attacks from hackers using the information they have collected about your technical infrastructure, like accounts and maybe even passwords. You might stumble upon a sieve instead of a single hole, and need additional measures to secure your data from a technical point of view. But there are so many other aspects involved, from communicating the effects to your customers up to changing the policies on access from mobile devices, or even hiring a specialist or ethical hacker to investigate how secure your data is actually.

    We can olny inform our managers of the threats and risks and of the available countermeasures, but unlike recovery getting the resources to do something about it is not enough. There are no 'set and forget' solutions, but every one should know what to do "when" a data breach has occured and all of a sudden valuable data has become public property. Never say "if" when it comes to security, just like you should never say "if" with recovery measures. Just hope (and pray) that all your preparations turn out to be superfluous for a very long time.

  • There are many circumstances in life where we prepare for relatively unlikely events. We install sprinklers and fire extinguishers in buildings,

    air bags in cars, pilots train for engine failures and forced landings and many other emergencies. We back up our computer systems.

    When these things happen, it is better that we have thought about how we respond to them, and put facilities in place to mitigate the consequences.

    I am sure many of us have participated in Disaster Recovery exercises. Sorry, it is called Business Continuity these days. Data breaches are just

    one of the scenarios you cater for in BC planning.

  • john.riley-1111039 (4/11/2014)


    There are many circumstances in life where we prepare for relatively unlikely events. We install sprinklers and fire extinguishers in buildings,

    air bags in cars, pilots train for engine failures and forced landings and many other emergencies. We back up our computer systems.

    When these things happen, it is better that we have thought about how we respond to them, and put facilities in place to mitigate the consequences.

    I am sure many of us have participated in Disaster Recovery exercises. Sorry, it is called Business Continuity these days. Data breaches are just

    one of the scenarios you cater for in BC planning.

    I suppose just like the security procedures air stewards and stewardesses go through with each flight. They never do it because they believe that there is a risk for that particular flight but because in the unlikely situation that there is a problem then everyone is best prepared.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 15 posts - 1 through 15 (of 19 total)

You must be logged in to reply to this topic. Login to reply