locked
SOX 404 and PCI Compliance RRS feed

  • Question

  • If I am building a new application and this application is owned by a company that has SOX 404 (Sarbanes Oxley) requirements and PCI  (Payment Card Industry) requirements will SDS be a good choice for my application?

    Will elevated compliance and regulatory requirements cost more?

    When will realistic SLAs and assertions about security be made?

    If there were an infrastructure breach from the inside (it happens) who will be liable? 
    Tuesday, February 10, 2009 6:16 AM

Answers

  • DevilDog
    In addition to Evan's comments earlier, I want to ensure that the Compliance issues are critical and are work in progress.  It will be a few months when we can engage in a dialogue over the pricing and SLAa, since it is work in progress.  We shall answer your queries at the appropriate time.


    However I would be very interested to hear your thoughts on the questions that Evan has for you
    Regards

    Anil
    • Edited by Anilred Thursday, February 12, 2009 7:45 PM added more context
    • Marked as answer by Anilred Thursday, February 12, 2009 7:45 PM
    Thursday, February 12, 2009 7:44 PM

All replies

  • All of these questions are ones that we are trying to figure out ourselves, too.  :)

    That means that we unfortunately the only answer I can give you at this point is with questions redirected to you:

    1) Would you be willing to pay more for elevated compliance and the ability to meet regulatory requirements?  Any idea of a percentage more?

    2) What would you consider to be a realistic SLA and what kind of security assertions would you expect?

    Evan

    Tuesday, February 10, 2009 6:09 PM
  • DevilDog
    In addition to Evan's comments earlier, I want to ensure that the Compliance issues are critical and are work in progress.  It will be a few months when we can engage in a dialogue over the pricing and SLAa, since it is work in progress.  We shall answer your queries at the appropriate time.


    However I would be very interested to hear your thoughts on the questions that Evan has for you
    Regards

    Anil
    • Edited by Anilred Thursday, February 12, 2009 7:45 PM added more context
    • Marked as answer by Anilred Thursday, February 12, 2009 7:45 PM
    Thursday, February 12, 2009 7:44 PM
  • Elevated compliance by default means that we are forced to pay more.  Elevated compliance means that we are forced to choose TerraMark vs. GoDaddy.  We have to own, service, and manage access to these servers.  We have to pay for facilities, IT folks to watch the boxes, secure the doors to server rooms, etc.  Elevated compliance means that we may need to know when people enter the server room, when people touch our hardware, when people access the console from outside etc.  For the auditors, we have say how we are dealing with and tracking these types of things.  So if we are to be this compliant, we already pay for it.

    The bigger question to me is this... will SDS cost me more than it already does for the same compliance that I already have?  I would think that since its in the cloud and many people are splitting the cost, it would be cheaper.  Another rhetorical question that I am struggling with is: why do I want to spend 3 months re-engineer my existing database and data access technology, to shave 3% off of my annual operating cost?  On the other hand, if I could invest 3 months of engineering work, and save 15% on my annual operating cost, I would be forced to think long and hard.  (BTW these are just ficticious numbers) 

    Realistic SLAs.  Good question.  IMO realistic SLAs should (at a minimum) cover availability, response times, bandwidth usage, and data recovery time. 

    If I had to pay for building and maintaining a platform that provided 99.999% availability on a global scale, I would say this is unrealistic for me, but I am not Microsoft.  Your infrastructure is supposed to be tripple redundant (I think thats what I heard) and is also (at some point) is supposed to support GeoLocation and GeoReplication, so I dont see why 99.999% availability is outside of your reach? 

    Another reasonable SLA would be that I should not see more than a 5% increase in response time compared to my existing sql operations.  So if each request takes 500 milliseconds to get a connection from the connection pool, execute the query, and return the data, I would be concerned if this same type of operation took SDS more than 525 miliseconds.  A 5% increase in response time for 10,000 reads taking place in the period of 1 minute is a pretty big performance degredation IMO.  It may be worth the price if we can shave the cost off of other areas i.e. improved scalability, reduced maintenance costs, etc.  On the other hand, this 5% increase may lead to a higher abandonment rate, and we end up loosing revenue because transaction volume is going down.  If you told me that if I had a service running in the azure cloud AND that I could talk to SDS using TCPIP or NamedPipes (i.e. lets not bloat the data access with SOAP or REST) then I would be very excited.

    SLAs for data recovery.  If you told me that it would take me 7 days to do a point in time restore going back 8 hours, that is un-reasonable.  If your told me it would take 7 days to do a full restoration of the database that would be un-reasonable.  If you said that you could do a point in time restore of data, going back 8 hours, and that I would only be down for 1 hour, that would be acceptable, if it didnt cost me my first born child.  Right now, we dont even know if we can do a restore.  If you told me that there was no way for me to archive my data, i.e. I only want to store 3 years worth of data, and anything older then 3 years needs to be archived, if you said I couldnt do that, I would be concerned.

    Assertions regarding security.  In SQL 2005, we can control who can read fields, who can read tables, who can create objects in the DB, maybe Bob can read the Salary Field and Jane cannot.  We can control who can execute stored procedures, etc.  In other words, DBAs have full control over who can access what.  So far, we havent seen much in terms of how DBAs will manage security and how developers can expect to program for security.  Can we just fire all of our DBA's (that would be cool, just kidding).  Seriously though, pretty much all we have seen regarding security is "put your authority in this XML element, your user name in this xml element, and your password in this xml element", then write some Linq and POOF here is your data.  I would expect that we could create sql like accounts and assign permissions to these accounts maybe even assign them to "server" and "database" roles. 

    When I was asking about "assertions about security", it was more like "when will we know more of what to expect from the SDS Security Model or right now, what does your crystal ball say..."

    I really do beleive that you will be able to solve these really tough questions.  I am totally looking forward to see how this all washes out.  :)
    Regards
    Friday, February 20, 2009 12:47 AM