ERP Security and Technical Debt with Saša Zdjelar, Part II

Facebooktwitterredditpinterestlinkedintumblrmail

Saša Zdjelar is Software Security Group (SSG) Supervisor and Software Security Design Lead at ExxonMobil Corporation. In the first installment of this two-part interview, Zdjelar discussed the vulnerabilities of Enterprise Resource Planning (ERP) systems and the resulting “technical debt” that constrains corrective actions. In this second installment, he discusses how those vulnerabilities might be addressed and the urgency of the issue.

Question: What’s preventing companies from securing their ERP systems?

Zdjelar: It’s very expensive, but not just measured in dollars per se. There’s so much complexity in regression testing and so much upfront engineering that you need to do to ensure that whatever you’re about to implement won’t break the existing system that the process becomes very complex and time-consuming and, therefore, expensive. The patches are free. Implementing them can be “expensive.” But not implementing them can be even more expensive if it leads to a breach. There’s even an example of a company that went out of business due to a breach that was determined to have originated through an ERP system.

This complexity is exacerbated by the fact that, when these systems were stood up, the prevailing notion was that they could be customized to your business’ specific needs, and many companies went very far down the path of customization. New versions of these systems are often only available in the cloud (vs. on-premise) which also may mean no customization or significantly reduced return-on-investment (ROI) from the cloud offering if expensive customization is to be supported. So if you want to upgrade, you may need to adapt your business processes to how the new system or module works. That might mean spending a couple of years reengineering how business processes work, which is very costly in terms of time, money, and the efficiency of business processes that are being transitioned, as well as the willingness of the business to make a change.

On the other hand, the competitive advantage often offered to the business by the new solutions can be the impetus for the upgrade as well, which can help accelerate it. In my opinion, it is our job as trusted advisors and stewards of the business’ systems to give them sound advice related to risk management.

Question: What are the options for companies that are caught between the costs of patching, operational risk and downtime, and the prospect of these wide-ranging business process changes that would be necessary to adopt securely designed new systems?

Zdjelar: The answer is to perform a cost-benefit analysis and take a balanced approach to risk management.

For instance, a mature organization might accelerate the rate at which they do service-pack upgrades. Rather than installing patches individually, which means a frequent risk of disruption to business activity, you could accelerate the rate of upgrades and each time implement a big bundle of patches. That brings some efficiency to automation and regression testing. Or you might focus only on implementing patches that remediate significant risk. What constitutes “significant risk” is up to each organization to determine based on its risk tolerance and policy.

You might implement additional, compensating controls, such as multifactor authentication, appropriate separation of duties, identity and access management policies, network isolation, enhanced monitoring, and revoking Internet access for users interacting with systems that are uniquely vulnerable. Ultimately, you devise a matrix of risk-reduction technical and administrative controls you can leverage that help bridge the gap between now and when that system will be upgraded to a much more resilient version. The concept of Defense-In-Depth still applies.

Question: What factors led to ERP vulnerabilities being overlooked? And what’s the urgency here?

Zdjelar: In my view,  the legacy divide between traditional IT support roles and the people placed in charge of ERP systems, due to the need for comprehensive understanding of the business, created a bit of an IT and infosec blind spot that has made this issue somewhat invisible. It has largely fallen through the cracks. So we need to promote awareness of the criticality of these systems and take a balanced, risk-based approach to risk management to address the issue.

There are a few consultancies specializing in security research on ERP systems but until this topic becomes mainstream and in the scope of most Application Security Managers/Directors, CISOs, security researchers and consultancies, and generally security practitioners, these systems will continue to represent a very attractive and valuable target to attackers.

The most significant risks in information security come from things we don’t know about, don’t understand well enough, and get attacked using vectors we haven’t yet seen.

ERP systems unfortunately meet all of those criteria at the moment. These systems hold some of our most critical business data, but they’re not well understood, they’re patched less often, and we don’t have enough infosec people who are experts with them. And we need to adjust accordingly before that rubber band snaps back into place.

If anyone who reads this interview feels that the urgency to address ERP vulnerabilities is being hyped here, I’d recommend that they read “SWIFT warns customers of multiple cyber fraud cases,” (Reuters, April 2016), in which cyber thieves attempted to steal $951 million from the Bangladesh central bank account at the New York Federal Reserve Bank, of which $81 million apparently remains missing. SWIFT – the Society for Worldwide Interbank Financial Telecommunication, a cooperative owned by 3,000 financial institutions – connects to and integrates with ERP systems in corporations.