Last week, we were discussing ransomware attacks on distributed systems and what could be done about them, and we ended with the sentences: “Often employees use the same password that’s stored in Active Directory to access the mainframe. So, watch out for hackers getting into that as well.” So, what can be done to protect your mainframe?
The scenario last time was that someone had got to your data and had read your list of Windows userids and passwords from Active Directory. If just one of those were the same as the login for the mainframe, then mainframe security was compromised – assuming you used userids and passwords to access the mainframe. But that’s not the only way to hack a mainframe.
Getting in
If you use CICS at your site, there are now automated tools that can be used to identify potential misconfigurations and bypass authentication. CICSpwn is one such tool that can retrieve the security settings running on the underlying z/OS operating system, read available files, enumerate system naming conventions, and even remotely execute code. And it’s available on GitHub for pen-testing. Alternatively, hackers, using the customer front end, can perform a brute force attack.
Another mainframe attack method is to use a TN3270 emulation software. They can then try password spraying, in which a single password is tried against every user on the system. This works better than trying a million passwords against one userid because repeated attempts will lead to that userid being locked out.
FTP attacks are used because FTP can submit commands from JCL. A systems programmer might be caught in a phishing attack and a keylogger put on their machine to capture their login and password. The hacker can then access the mainframe, issue commands, and anything else they want.
With NJE, one trusted mainframe can send a job to another mainframe its connected to. It’s possible to use NJE to spoof a mainframe or submit a job and gain access to that mainframe.
Clearly, the attack surface for a mainframe is quite big. One way of seeing whether a site is actually vulnerable is to use pen-testers. These are ‘good’ guys who try to penetrate your mainframe – and then tell you what they found. They will probably suggest ways to protect the mainframe as well.
The other, obvious, issue that mainframes are now running software that is commonly found on distributed systems, eg Java. It’s not unthinkable that any of the known vulnerabilities with the software will also exist on the mainframe – allowing hackers to gain access that way.
Unfortunately, it’s not just outsiders who can be attacking your mainframe – there can also be a problem with insiders too. Now, the majority of insiders won’t have any evil intention towards the data on the mainframe, and so the assumption is made that no-one has any bad intentions. This, quite often, isn’t the case. It may be that a trainee systems programmer can’t quite read his writing and makes an unfortunate change somewhere on the system, which may corrupt data or may lower the level of security that was being applied. The result was bad, but the intention was good.
But what about another employee who has run up serious gambling debts or has run out of money to pay for his drug habit. How hard would it be for criminals to target this person and ask them, just once, to make some change on the mainframe in exchange for all his current debts to be forgotten. Of course, he’s going to do it. He needs to get out from under his debts, and the chances of anyone spotting what he did, he thinks, is very unlikely.
Once they’re in
Once the hackers are inside the mainframe, their aims are the same as for a distributed system. They will try to increase their security level. They will look to see where data is stored. And the software on the mainframe will be dialling home for instructions. Once they have accomplished their goals, they will start exfiltrating (copying) the data, so that they can sell it on the dark web. They will corrupt the backups to stop the data being restored once it has been encrypted. They will encrypt the data. And they will leave a ransomware demand.
If you’re any kind of financial institution or large company, then losing your mainframe means that people will immediately notice that your service is no longer available. And, added to the cost of recovery or the ransom, will be the cost to your company’s reputation. Something that the company might never recover from.
What can be done?
The solution is simple – some piece of software that can identify changes being made and alert the security team as soon as they spot it. Some mainframers will heave a sigh of relief at this stage because everything on a mainframe is recorded in SMF records. But, have you ever tried to readd through yesterday’s SMF records to find what and when something happened?
File Integrity Monitoring (FIM) software, which is quite common on distributed systems and is available for mainframes, can take a snapshot of an application or configuration file and later (weekly, hourly, or whatever time interval is required) compares that snapshot with the current state of the application or configuration file. If they are different, an alert can be sent to appropriate staff. The first snapshot has to be carried out when the files are assumed to have been unhacked – perhaps straight after QA testing. The snapshot uses a hashing algorithm, and the results are stored in a virtual vault – so that hackers can’t modify those as well as the files under attack.
FIM tools allow regular scans to be carried out. This, as mentioned above, might be weekly, daily, or even hourly for some very sensitive files. In addition, scans can be carried out on an ad hoc basis. This will detect any changes that have been made to files, particularly where required for PCI compliance.
Using a FIM tool means that the breach can be detected and reported the next time a scan on the affected file is run. The alert, highlighting what’s been changed, can be sent as an email to a responsible person or to a SIEM (Security Information and Event Management) console, or both. The organization affected can then take the appropriate steps to deal with the breach – and this will be so much sooner than without having the FIM software installed.
In addition, some FIM products can gather the required forensic information, including file accesses, userids, event times, and scope of attack. They can then promptly initiate policy-managed actions such as quarantine or userid suspension. Because FIM tools know when each component was last correct, it can then initiate the appropriate actions to restore and verify that all systems are in their approved state.
What about those backups? Some FIM tools can regularly check those and notify appropriate staff as soon as any changes are detected.
Bottom line
Protecting the attack surface and regular pen-testing is vitally important to keep out bad actors, but something else is required to defend the mainframe against any that get through and any acts carried out by trusted members of staff. That something else is the use of FIM software, which can alert security staff as soon as changes are detected, and before the ransomware attack gets fully underway.
No comments:
Post a Comment