The solution-focused approach to mainframe security

Solution-focused techniques originated in the 1980s as a form of therapy that helped people to achieve their goals and live the kind of life they want. Since then, it has been used with many other aspects of people’s lives, and there is even a solution-focused manifesto that suggests “solution-focused practice can help people to cope with the world and function within it. Sometimes, though, it is the world that needs changing.” It goes on to talk about using the solution-focused approach in the pursuit of social justice. We’re going to use it to look at mainframe security.

Where did the solution-focused (SF) approach come from? In the late 1970s and early 1980s, at the Brief Family Therapy Center in Milwaukee, Steve de Shazer, Insoo Kim Berg, and their colleagues created the radical new approach of Solution Focused Brief Therapy (SFBT). Their core idea was that whatever problem a client had come to therapy with, there always seemed to be an exception to the problem, a time when it didn’t happen, or happened less or with less intensity. And this led them to believe that the client already had the seeds of a solution and didn’t need the therapist to get them to do something different – all they needed was to do more of what they were doing during these exceptional times. The therapist’s job was simply to find out what people were doing that was working, then help them to do more of it.

According to Steve de Shazer: although the “causes of problems may be extremely complex, their solutions do not necessarily need to be”. In fact, one of the great ‘discoveries’ of de Shazer and the Milwaukee team was that ‘solutions’ had more in common with each other than they do with ‘problems’.

When working in a solution-focused way, it’s all about the questions that you ask. All too often, people are focused on their problem, and can’t see a time in the future when they have the solution. Solution-focused therapy uses problem-free talk and lets the client focus on their desired outcome. In our case, that would be a ransomware-free mainframe. But hold on! That is couching the solution in terms of the problem. So, our goal must be a completely secure mainframe.

Let’s look at the main categories of solution-focused questions. They are:

• Exception questions – ie when doesn’t the problem happen or when is it less severe?
• Coping questions – given how bad things are at the moment, what strengths have you used to be able to cope?
• Scaling questions – on a scale of 1 to 10, where 1 is bad and 10 is brilliant, where would you say you are now in terms of x?
• Miracle question – if, while you’re asleep tonight, a miracle happens and your problems are gone, what would you be different; what would you be doing; where would you be doing it; who would notice; and how would they feel?

Let’s see how we can apply those to our mainframe security.

Firstly, is there ever a time when your mainframe and network aren’t likely to be attacked by bad actors or disgruntled staff. I think, realistically, the answer to that question is never. If you think your mainframe isn’t a potential target, you could be in for a nasty wake-up call very soon. For some sites, this is a very real wake-up call, but not a great start to our SF questions.

Let’s look at the coping question – how have you coped? There are probably three strands to this answer, software, hardware, and people. In terms of software, there’s good old SMF to record everything that’s happened. There are SIEMs like Splunk, QRadar, etc that can report about mainframe security. There are backups and restore software packages. And there’s Integrity Monitoring (IM) software like FIM+ that can keep a whitelist of permitted applications and can identify when critical files (eg parmlib etc) are altered without authorization. In terms of hardware, many people are looking at air-gapped drives storing immutable copies of files (snapsets or safeguarded copies). These can be used to restore the system. And in terms of people, there may well be a recovery team that has practiced recoveries in the event of files becoming corrupt. Because they practice regularly, the recovery can be quick and efficient.

For the scaling question, various groups within an organization need to be involved. It’s not just the IT team, it needs to include people from the teams responsible for the data. In the event of a ransomware attack, how quickly can the data be restored, and how recent is that data? Will an hour’s worth of updates be lost? Or six hours? Or a day? For some companies, one day’s worth a data loss may score 5, but for a bank, for example, that may be a 1. This leads nicely into the follow-up questions, such as, “what would have to happen for the score to be a 6 (or a 2 in the bank’s case). The strength of this question is that it begins to help the mainframers visualize the first steps they need to take in order to overcome the problem. These are the first small step in their journey towards a score of 10.

The miracle question may not seem like a very useful question for mainframe security. It may be nice to visualize a day in the future of world peace and harmony where no nation states, criminal gangs, or disgruntled employees want to steal/damage/encrypt your data. But it can be a useful question for the business team – what do they see as the future of the business, how will things look, what will they be doing, how will their customers feel about it?

For most sites at the moment, those first small steps will be to start using multi-factor authentication (MFA) if they are not already. The next small step might be to investigate the use of immutable copies as backups (again if they haven’t already). A third small step might be to get the recovery team to practice and practice their response to a data breach. The fourth step, as part of a bigger move to a zero-trust approach, is likely to be to use IM software to identify changes (such as backdoors and timebombs) being made in the early stages of an attack.

There’s more to solution-focused questioning than just these basic four questions. Using solution-focused questions can help move the discussion about mainframe security away from focusing on the problems, and help organizations start moving towards the solutions.

Updating an old COBOL program the easy way!

Mainframes are just full of COBOL programs. To a large extent, many large businesses are reliant on their COBOL programs to keep them in business. That’s not to say that mainframe technology is somehow locked into the 1980s or even earlier, it just shows how long successful coding lasts, and these applications may well have been in use for many years.

The fact is that there are estimated to be between 200 and 250 billion lines of COBOL code in production. It’s also been estimated that there are 1.5 billion new lines of COBOL written each year. And yet most educational establishments are teaching young people other languages, which will give them a job in the overcrowded and highly competitive world of gaming and mobile application.

As a consequence, there aren’t a lot of new people out there who can write COBOL programs quickly and easily. And the number of older programmers with COBOL skills is decreasing all the time as those programmers reach pensionable age and decide to pursue other interests, eg golf!

The good thing about COBOL is that it uses an English-like syntax to describe almost everything in the program, which means that it’s verbose, ie quite long compared to other languages, and it’s almost understandable, so it doesn’t need too many comments. However, that is only true if you can find the source code rather than the compiled code. And that might be more easily said than done!

So, what can you do, if you would like to make changes to a COBOL program that has, perhaps been running since 1992, but now doesn’t quite meet your needs? Let’s assume it’s not one of your absolute core business programs running in CICS or IMS, but let’s say that it is very useful to the organization. What are your choices?

If you do have the original source code, and if you can find a COBOL programmer, he might be able to rewrite it or add new functionality to it. Those are two big ‘ifs’.

An alternative is to use a software package that will translate the application into a modern language. Unfortunately, this all too often ends up with something that is almost impossible to maintain.

Or you can get your younger programmers to look at the application and write something in their language of choice that will do the same thing, plus they can add the updates that you require. Unfortunately, mainframe programs have any number of dependencies, and require certain entries in files to be treated in certain specific ways, which can make this rebuild very difficult.

And none of those ideas can be described as ‘the easy way’.

What is needed is an easy-to-use deterministic machine learning platform where knowledgeable personnel can teach the platform what they wish to achieve. The teaching approach also has the advantage of extracting tacit knowledge, thus filling in often missed but critical details.

This platform needs to be able to build a model of the existing system by obtaining specific relevant data samples from it. In addition, users should also be able to teach the system using real world examples.

Once the new program has all the information, it can be tested. Various scenarios can be set up and the results from the new program can be compared to the existing program. Where there are any differences, the platform needs to be able to be taught, so it can be changed to satisfy these new scenarios. It can also be tested to ensure that everything else is still running correctly.

Basically, you need a platform that uses Machine Learning (ML) to build the behaviour of the final system through a deterministic process of inductive reasoning. Consistency of logic and behaviour can always be maintained by letting the platform ‘argue’ back by flagging all logical inconsistencies. Alternatively, ‘bugs’ could optionally be added for testing purposes. Using machine learning would cut down greatly on the amount of testing that would otherwise be required.

In practice, the platform user (the application builder) has to ‘explain’ to the system what they want to occur at a PROCESS and DATA level. Data can be visualized as knowledge graphs. Wikipedia tells us that a knowledge graph is a “knowledge base that uses a graph-structured data model or topology to integrate data”. Concrete examples are used, which are usually derived from the real world, but could also be synthetic. These examples are remembered AS TESTS, at build time and for the future. This will reduce the risk of future maintenance, allowing future behaviour to be adapted whenever that is required. Once the new application has been created, it can be deployed.

An example of such as platform that I recently came across and you may not have heard of yet is RulEvolution. It uses a firewalled production environment so as not to interfere with any other work going on in the mainframe environment,

According to RulEvolution, its platform achieves a far greater ROI because it provides a much quicker time to market as a result of its speedier build time and because most testing is already done. It also has a much lower cost, much less than any traditional approach (or any other approach!) to custom software building. In addition, it does what you want it to from the start. Plus, the system can be continually refined, and the scenarios serve as a basis for documentation. They also say that it’s easy to safely make changes, allowing businesses to adapt quickly. Lastly, it also provides reduced longer-term maintenance.

The platform is taught what you want to achieve by example. The system remembers the learned scenarios, and system alterations are played back to check they’re not broken. These act as the tests (and are remembered). The system focuses on the data manipulation behaviour rather than using’ ‘rules’ (that are then interpreted). This is done as pattern matching to the data, and encapsulated as a model for quick and easy deployment

It certainly seems like an easy way to update those COBOL programs that are reaching their ‘best-before’ date.

Mainframe security in 2023

It requires effort to keep your network and your mainframe safe. Every year, the bad actors get better at what they do, and every year your IT team also needs to improve the techniques it uses. Your recovery team also needs to practice recovery in order to make sure that recovery can be carried out quickly and surgically in an atmosphere of panic with senior management running around trying to get answers and estimates of how long the recovery will take. Long gone are the days of security by obscurity – the mainframe now runs software that is very familiar to users (and hackers) of distributed systems.

The other things to remember is that hackers are no longer enthusiastic teenagers looking to increase their knowledge. We’re talking now about criminal gangs and nation states, who are using hacking as a way of making money or bringing down the economy of a foreign country. On top of that, it is now possible to rent Ransomware as a Service. If you’re not happy with an organization, you can rent the software to launch a ransomware attack.

The great thing about the September-October period each year is that many companies, including IBM, bring out reports on data breaches etc, and almost all of them highlight the fact that breaches are increasing, and the amount paid in ransoms is increasing.

The first line of defence for most organizations is still the password. And the top five passwords in use are: 123456, 123456789. Qwerty. Password, and 12345 – according to Lookout, a mobile security firm. Clearly, making sure your employees are using more secure passwords is the first step.

Phishing attacks are still the most successful way of getting information from an organization. Even if an employee suspects that an email looks too good to be true, a vishing attack (someone phones them shortly after they have seen the email) can increase the success of phishing attacks. Staff are more likely to fill in the form at the fake Apple, Google, Tesla, or whoever site and give away their security details. Or they are more likely to download that PDF from the headhunters offering them a much better paid job – and at the same time inadvertently install a key logger.

Once hackers get onto your mainframe, they want to install backdoors – so they can get back on again whenever they wish – and they leave time bombs of malware that will go off if they don’t receive a code from the bad actors. How do you know if malware has been left on your mainframe? How do you know whether your infrastructure has been modified by unauthorized individuals?

And that brings us on to disgruntled employees. It seems that somewhere around 10% of attacks are coming from trusted employees who are not happy and decide to get their own back on their company. Do you have anything in place to identify when people are accessing files that they don’t usually need to access in the course of their work? This is usually the first sign that they are planning or beginning to commit an attack.

Mainframe ‘modernization’ is the term often used to describe the migration of some mainframe workloads to the cloud or the creation of new workloads that make use of techniques, like data analysis that the cloud can do better than the mainframe. Unfortunately, hackers are usually very familiar with Linux and Windows, which is what most cloud systems run on. And that makes it easier for them to gain access to the mainframe from the cloud – particularly with so many proof-of-concept cloud projects that don’t quite follow all the security rules decided on for live systems.

Data poisoning is a new issue affecting companies using Artificial Intelligence in their business. Data poisoning is where a hacker injects corrupted data into an AI system. Any future queries will give erroneous and skewed results, which will be trusted by corporate decision makers. It’s important to continuously monitor AI results to identify any significant changes in new results compared to earlier results.

Internet of Things (IoT) devices are a growing risk. These are devices that have some (usually small) level of intelligence built into them. They may be sensors that are reporting back daytime temperatures or water quality. However, they rarely have very sophisticated security, and most are installed using the default password. Hackers can access the remote IoT device and send messages to the network and then on to the mainframe. It is important for organizations to raise the security levels of all IoT devices in use.

Many people think of their mainframe as an isolated silo of computing. This is rarely the truth these days. Mainframes are often connected to mobile devices, the Web, and the cloud. In addition, companies are often connected to other companies – suppliers and customers. If another organization can access your mainframe, then the hackers can get in that way. Your supplier’s site may not be as secure as yours and you are offering the bad actors a half-open door into your mainframe and your data. Supply-chain security is vital.

It cannot be stressed enough how important it is to stay aware of all new potential threats to the cybersecurity of your mainframe. It’s important to see the bigger picture to identify any new areas where security may not be as tight as you hope. It’s important to ensure recovery procedures are actually practiced so that they can be performed as quickly and efficiently as possible if that time ever comes. And it is important to have the right software in place to identify any changes to infrastructure as soon as they happen, or any changes in behaviour of individual accounts, because these are early warning signs of an impending attack. And make sure all your security software is up-to-date, and all your staff are trained to recognize phishing (or similar) attacks.

Guide Share Europe 2022 – my impressions part 3

This week, I want to conclude my impressions of the Guide Share Europe (#gseconf22 and #gseuk) conference, which took place at Whittlebury Manor on 1, 2, and 3 November. I’ll mainly focus on some more of the sessions that I attended. You can read my previous posts here and here.

On Thursday, I started the day with a swim in the pool at the hotel. It’s a very nice pool, and I even had time for five minutes in the jacuzzi. I did pop into the sauna, but didn’t stay very long. It was very hot! Then it was breakfast – listening to people saying how late they had stayed in the bar the previous night! Then it was on to the first session.

I hadn’t been to the CICS stream yet – there were so many good sessions at GSE – but I decided I had to see the always excellent Ezriel Gross give his presentation on “CICS resource definitions as part of a DevOps pipeline”. Ezriel is a Principal Solutions Advisor for Rocket Software. He started by showing the usual DevOps illustration of the stages in the DevOps process, and described how CICS tools could help. He said that CICS Configuration Manager was needed to: manage resource definitions on multiple repositories across diverse environments; make rapid and frequent updates to resource definitions to handle new business requirements; understand the impact of definition attributes on target environments; and identify duplicate, redundant, or inconsistent resource definitions. He went on to look at CICS administration problems and solutions. He discussed editing CICS System Definition (CSD) files and how CICS CM can help. He then demonstrated how to work with CSDs. The next issue that Ezriel looked at was delegating responsibility and how there are some things that application developers can do for themselves, and some that a junior CICS admin can do, and some only a senior CICS admin should do. The next problem that Ezriel looked at involved migrating changes between environments. Again, CICS CM can help. He followed that with a second demo. He looked at the changes across LPAR boundaries, and how to overcome those problems. He also described audit compliance problems and solutions, and problems with zFS support – and how to overcome them. Finally, he showed how all of these fitted in with the DevOps pipeline.

I finished the morning in the Storage stream watching a presentation entitled, “Ransomware recovery – It is more than just getting your data back”, given by MainTegrity’s Al Saurette. The main thrust of Al's presentation was that the focus for most sites is on recovering their data in the event of any problems with it – eg corruption or encryption. Al pointed out that a malicious attack on a mainframe will very likely include timebombs, multiple back doors, and other malicious attacks that occur long before the data is obviously attacked. So, restoring the data leaves these changes in the system, and makes it possible for the bad actors to get into the system again, re-encrypt the database, and you are back to recovering your data. What's needed is some way to determine which components have been affected, and be able to restore them to a trusted state before they were compromised. And to be able to do this quickly and surgically. Al went on to show how it was possible to implement automated prevention and restoration techniques that use browser-based tools to guide the recovery team through the required steps to recover. He looked at the importance of eliminating effort by integrating with immutable backups and existing security tools. Of course, in our ever-changing mainframe world, any software used needs to continuously stays up to date.

Unfortunately, I was called away and missed the afternoon sessions. In my calendar, I was hoping to go to “Using Ansible to accelerate your automation journey for CICS”, which was presented by Stewart Francis, a software engineer at IBM. He has spoken to the Virtual CICS user group, so I knew he would be good. And I was hoping to end the day of presentations with “How to start your CICS Modernisation journey”, presented by Phil Wakelin, a member of the CICS strategy and design team at IBM UK.

I thoroughly recommend the GSE conference. It’s very friendly, the presentations are excellent, it’s useful to talk to the vendors, and it’s great networking with old and new friends. However, if you did miss it, the good news is that there will be an online GSE conference in February on 7^th to 9th. At the moment the details are scarce, but more will be forthcoming soon. And being online, you don’t need to get your manager to pay for your travel and hotel accommodation etc. And people outside the UK and Europe can attend. So, see you there.