Oops I did it again: Placing blame on ERP data security failures
Last week there was story about a newly hired junior developer who managed to accidently delete their company's production database. The developer was setting up their environment and instead of entering a URL/User Name/Password specific to them, they used the example in the documentation which was tied to production. This overwrote the production database with test data. Apparently, the backups weren't restoring either. The junior developer was fired. You can read more of the story here.
Don't think that this can only happen with developers. I've seen plenty of cases where users with excessive ERP access accidently deleted data. Wiping out something like vendors or receivable data can ruin a career. There are lots of lessons here. A few that stand out for me are:
- Access matters. When thinking about security, companies can't be one dimensional. Focusing solely on compliance or fraud prevention isn't enough. Excessive user access is still way too common in organizations. New users simply shouldn't be able to delete or damage data. Ultimately, organizations have a responsibility to understand and control their ERP system.
- Backups matter. Untested backups are like everything else that people collect. They might be worth something someday, but until you check, assume they are worthless. We've previously covered using backups to update test environments. This is a great, low-risk way to make sure that backups work.
matters. How companies explain tasks
is important. If users need to perform SQL commands or follow a series of
complex steps to perform a task, the risk of error increases significantly. This
should be obvious, ...
FREE Membership Required to View Full Content:
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here