For most people, security is a bit of a nuisance. No-one likes having to keep updating their password and then needing to remember the new one. And then there’s all the different passwords that need to be remembered for different things. It all just seems like an administrative nightmare. It just makes getting a day’s work done harder. That’s what most users think right up until the moment there’s a breach. And suddenly the mood has changed. Now everyone wants to know exactly what’s happened. They want to know who has done what, where they’ve done it, when it occurred, how they got in, and a million other questions. Your phone is ringing off the hook. Your e-mail is filling up faster than usual. What can you do? Where can you access the information you need? How do you respond to the incident?
Although you may have just discovered there’s been a breach, the big question is when did the breach actually occur? Was that just a few seconds ago, or did happen yesterday, or longer ago than that? A 2018 study by The Ponemon Institute on behalf of IBM (“Cost of a Data Breach Study”: https://www.ibm.com/security/data-breach) reported that the average time to detect a breach is an unacceptable 197 days, with a further 69 days taken to control the breach. Plenty of time for malicious hackers to cause mayhem AND cover their tracks. And it’s not just mainframes, this can happen on open systems where there are SIEMs and other advanced tools.
This 13th annual “Cost of a Data Breach Study” also reported that the global average cost of a data breach is US$3.86 million, while the average cost for each lost or stolen record containing sensitive and confidential information now stands at $148. Plus, there’s the cost of the damage to your brand/company’s reputation. And, of course, it may cost you your job!
Appreciating just how much a breach is going to cost makes finding out all the details about the breach even more pressing. So, what are you going to do? The great thing about a mainframe is that SMF (System Management Facility) data will tell you pretty much everything that has occurred. The only problem is that there are lots and lots of records to look through. Is it only one program that has been modified? How many things are you going to end up looking for? Just how long is this going to take you? All this while, senior management are breathing down your neck and everyone wants to know whether this is a real breach or just a false alarm.
We all remember A Christmas Carol, the 1843 novel by Charles Dickens that had Scrooge visited by three ghosts. The third ghost, the Ghost of Christmas Yet to Come, shows Scrooge the future, where he is dead and unmissed. You can think of this as the view of your systems programmers pouring over pages and pages of SMF data. When Scrooge wakes up, he determines to change his future and ends up sharing Christmas with Bob Cratchit, Tiny Tim, and their family. This could be you making the most of File Integrity Management (FIM) software, which is used on Windows and Unix platforms for this very purpose, is available on mainframes. FIM software provides a way of detecting changes by comparing the current contents of components to their trusted state. That way you have a lot of answers instead of just a lot of questions. And that trusted snapshot is safely stored in an encrypted vault.
FIM software can tell you who made the changes. They do that by accessing data in SMF and searching it to see what userid changed the files during the attack interval. It can then display the information in a 3270 or GUI interface so you can see all the information required, in one place, in seconds. Since FIM data can be sent to your SIEM or enterprise security console, like Splunk or QRadar, you could also look there and get all the information as well if you want to.
FIM software can tell you what has changed. FIM tools can identify every file that was modified, added, or deleted. FIM isn’t fooled. It shows you not just where the problem started (a suspicious update) but every component that was accessed. It can also identify altered log files that would cloak a hacker’s tracks. However, if the content matches the trusted state, then you very quickly know it was just a false alarm.
FIM software can tell you what LINE was changed. FIM tools can be instructed to keep a baseline copy of files and members. For config members, source, and text files that can be read by humans, state of the art FIM tools can automatically invoke your existing file comparison tool to show you a side-by-side picture. So not only do you know what components changed but can see the actual lines that are different.
FIM software can tell you when it changed. FIM software records every successful scan, it knows the last time each component was correct. Now it can give you the attack interval (from the last good date to incident time) so you can focus your research on the exact actions during the interval. Knowing the last good date will also be important in deciding when the recovery process should be started too.
FIM software can tell you why it changed. By querying change management products like Remedy and ServiceNow, advanced FIM products can determine whether the change was authorized or not. This can avoid many false alarms and ensure only validated alerts become an incident.
Modern tools can automate every step of this incident response process. So now, when the phone rings, you can confidently tell management when a situation started and that recovery steps are being implemented. Additionally, you know who should be on the recovery team because you already know all the systems and applications affected.
By simply knowing who, what, when where and even why changes took place, you can control an incident before things get out of hand. Clearly, with the size of a mainframe prize for would be hackers, you need to be ready to respond, to either individuals or nation states, before they attack.
