Nine Ways to Maintain ERP Data Security

We’ve previously gone over the types of ERP cyberattacks as well as how attackers are exploiting these security risks to obtain access. But the question, of course, is how do you stop these attacks? Or better yet, how do we prevent them?

The following nine tactical strategies can be deployed by your IT department to help secure your ERP data and maintain that security.

Secure Your Authentication System

In our previous post, we discussed in great length how the compromise of a single employee account can give an attacker an ample foothold in your environment. Obviously password policies are vital to your organization, but they are collectively only one piece of the data security puzzle. Securing your entire authentication system goes beyond passwords.

Your ERP system is only going to be as secure as whatever authentication platform it uses. Sikich sees a lot of organizations integrate that authentication with Microsoft Active Directory on their local corporate network. If someone can take over that local Active Directory, they can the take over that ERP system. If your company uses this type of authentication, consider where the domain controllers are located. Is one located in a broom closet at a branch office somewhere to which anybody and everybody has access? Could someone physically go in there, gain access to that domain controller, and start breaking into your network?

Next, ask who the domain administrators are. Are there a lot of people who have administrative access on Active Directory who shouldn’t have any rights over the ERP system? It’s not even a question of if one such user might have ill intent. What if one of those unnecessary accounts is compromised? Now that attacker has access.

You need to also consider where the domain administrators typically sit down to type in their passwords. Those workstations are part of the ERP security perimeter.

Require 16-character Pass Phrases

When it comes to passwords, most people have been taught to create an eight-character password with a combination of uppercase and lowercase letters, numbers and special characters. Unfortunately, following those previous recommendations made passwords hard for people to remember. As a result, people used the same password over and over again, wrote it down, and/or used predictable patterns such as “Summer2019.” In addition to the password re-use issue such password requirements created, computers are now able to crack (i.e., guess) an eight-character password within 48 hours.

The new standard for passwords is to use a “passphrase” that’s at least 16 characters long. That may seem like even more work than the eight-character, complex password, but it’s actually not. When we say 16 characters, we’re not saying that you need to involve the complexity of uppercase letters, lowercase letters, numbers and symbols. We’re suggesting instead that you use a string of a few random words (e.g., correct horse battery staple). Industry bodies are even saying that, when you move to passphrases that are 16 characters or longer, you can reduce the rotation frequency.

People aren’t required to use 16-character passphrases for most other website accounts, such as their personal Amazon or LinkedIn account. Thus, that cycle of password re-use can be broken.

Utilize Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) requires a second step to confirm identity in addition to something like a password. Most of the time, this second step involves a one-time passcode that you can get on your phone, either via text message or an app. Imagine how much more secure your cloud ERP data will be by requiring MFA for all remote access.

Since attackers are guessing passwords on the Internet, stealing passwords through phishing attacks, etc., enabling MFA helps block many of those attacks. I recently worked with three companies with various types of ransomware breaches, and all three of them had remote access capabilities. None of them had MFA enabled. If they had, I’m quite confident that none of the three would have had experienced the cyber extortion ransomware events.

Prioritize Management of Configurations, Changes and Patches

How have you configured your systems? Are you using default accounts and passwords? Do you still have sample or test data from the original package? The following are simple actions you can take to reinforce your systems and prevent break ins:

• Remove or disable default accounts
• Get rid of sample and test data
• Disable applications, services and legacy protocols you aren’t using

Do you keep track of all of your assets? We see a lot of organizations that don’t know how many servers are on their network. Sometimes that’s because their IT staff turned on test servers and forgot to turn them off. Those test servers can present problems, especially if they aren’t patched regularly. Unpatched test servers can leave a wide-open door for attackers.

Tracking changes and formalizing change management processes, for example, so you can know if a server has been added to your environment, if the server was secured when it was added, and if the server was removed after testing was completed, can meaningfully impact your security posture.

It’s also important to keep patch management in mind, both for operating systems and web applications. Keep track of all of the patch releases and determine the best time to apply them, especially when it comes to your ERP system. For any critical patches, you’ll want to apply those as soon as possible, and no later than one month after they are released.

Lock Down Integration Points

For any integration you have, whether it’s via an application programming interface (API) or access to a vendor, make sure that each one utilizes a unique password, especially when it comes to vendors. If your vendor doles out passwords and gives you a generic or “default” customer password, an attacker who compromises just one of the vendor’s customer passwords, even if it’s not yours, will be able to access your account with that vendor. That access into your environment can in turn open up other doors for access.

With API integrations, make sure that a logging history is retained, and that this history DOES NOT include sensitive data. For example, if debugging is turned on in an API for troubleshooting, and that API accepts or transmits bank transactions, every single transaction will show up in the text log. All an attacker has to do then is break into the server and get a copy of the text log file. The same goes for APIs that handle batch file transfers.

Prepare a Backup and Recovery Strategy

Regularly assess and test both your backup process and your backup files. This isn’t just important if your organization is at a high risk for cyber extortion either. What if your servers fail? Most organizations could benefit from putting more energy into their backup strategy. Make sure you know where information is stored, check that backups are actually happening, periodically perform recovery tests, and occasionally set aside time to think about if your backup strategy is actually protecting your data against all of your relevant risks.

It’s a great idea to have backups online. However, it’s equally important to have backups saved offline as well. Offline backups are out of reach for any attackers who might be able to get on your network. So even if a virus hits your servers, or ransomware takes over your online backups, you know you have at least one offline backup available as a failsafe.

Implement Logging and Monitoring

Many organizations first become aware of gaps in logging when they are trying to respond to or research an incident. Before this happens to you, make sure logging is enabled, and configure logs so that they go to a central repository or offline backup so they are protected from loss or deletion.

If an organization uses Windows default logging settings, a lot of the most important logging details, like those related to successful and failed login attempts, are only stored for about two days. That doesn’t seem like that big of a deal until the Sikich Incident Response Team is called in to look into how someone broke into the network. We typically get these calls weeks after the breach, or at least weeks after the attacker first gained access. If the organization was using the default settings, learning when the attacker gained access or what they logged in to will be extremely difficult.

The default settings also don’t log important events, which means that details related to how the attacker broke in, such as by running PowerShell, won’t be available. Every administrator login event, every password change, every command run through PowerShell, etc., should be marked for logging.

Conduct Awareness Training

Going through awareness training may not be everyone’s favorite way to spend time, but this training is necessary for employees and, ultimately, the security of your organization and its data. To increase engagement and reduce apathy, keep the training simple. Focus on good password practices, enforce a policy of not using the same passwords outside of the office, examine email takeover risks, and discuss social engineering, especially phishing. Another good idea is to create your own phishing exercise to test company employees. You can set the training up so that if an employee clicks a phishing link, they are presented with information on why they shouldn’t have clicked the link and what to look for and do if they receive a similar email in the future. Many companies set up periodic phishing exercise for continuing education purposes.

Offer separate training for administrators and those with privileged access, since the risks associated with compromises of their accounts is often higher than the risk associated with other employee accounts.

Perform Periodic Vulnerability Scanning

We’ve mentioned several weaknesses a system might have, which is why it’s important to run periodic scans of your external and internal networks to proactively identify any potential vulnerabilities. Many services are available to scan your networks and will let you know which systems aren’t patched, which systems are using default settings, and which systems have weak settings. This is extremely valuable for finding potential footholds before attackers do.

However, vulnerability scanning is only useful if you actually follow up on the reports and remedy what the scans find. The reports can seem overwhelming with the number of items that need to be addressed. In most cases, the reports can be configured to prioritize the findings based on risk. Once you feel that you’ve adequately addressed the findings, it’s important to run a rescan to assess the effectiveness and configuration of the fixes you’ve implemented. For example, if you buy and install a new firewall, you’ll want to run a scan to make sure it was set up and configured appropriately.

Sikich thinks it’s important to keep this discussion going! Contact us with any security issues or questions you may have.