Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday May 19 2019, @12:07AM   Printer-friendly
from the who-needs-QA-when-we-can-test-it-on-production dept.

At around 9:15 UTC [17 May] Salesforce pushed a database script update that was intended to add modify all permissions to a specific internal profile used by their Pardot service. Due to a scripting error View and Modify All Objects Permission was granted to all user profiles for all organizations that ever had the Pardot product, including public facing community instances. This was of course a security nightmare for customers, especially those in the Financial and Health sectors, and an emergency change was pushed around 10:00 UTC to revoke all permissions to all profiles except for administrators. No announcement was made on their status sites due to the potential for bad actors to take advantage of the security issue that was introduced until the databases could be locked down. Further action was taken around 11:00 UTC to take down PODS completely, likely to further mitigate access risk which effectively expanded the outage to customers that never used Pardot but shared an instance with customers who did.

Salesforce is holding hourly calls, and recently admitted that the script had run both in their production PODS and also in the Passive Disaster Recovery Instances, complicating the ability to recover from the issue. There is currently no ETA for recovery, though it is still their hope that they will not have any data loss. They are beginning to bring back up instances, but only administrators will have access initially and it will require additional time before administrators will be able to modify permissions and rebuild profiles and there will be a longer wait yet before profile settings can be restored from backup.

Coverage at: Geekwire, The Register, and reddit


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Informative) by JoeMerchant on Sunday May 19 2019, @01:15PM (1 child)

    by JoeMerchant (3937) on Sunday May 19 2019, @01:15PM (#845230)

    "move fast and break things" and even devops is bad.

    Only if they are deployed irresponsibly.

    "Move fast and break things" is an excellent, very productive, development philosophy - and perfectly safe and acceptable, as long as you make the additional investment of a robust sandbox deployment and test environment.

    Using your paying customers as a sandbox is, well, just like the housecat analogy would imply, and customers should react accordingly.

    --
    Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Informative=1, Total=2
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by Farkus888 on Monday May 20 2019, @04:21AM

    by Farkus888 (5159) on Monday May 20 2019, @04:21AM (#845412)

    Agreed. For example Agile like grandparent mentioned. Certainly calling a reckless approach to things Agile will still be a reckless approach with the expected outcome that brings. We use a modified Agile for chore and project tracking in my house, post-it's on the wall and all. It is awesome, the house is nicer and more gets done with fewer disputes.