The Modern Mainframe Architecture
The following is a reprint of an article that first appeared in IDG’s TECH(Talk) online community forum.
A Modern Mainframe Architecture to the Rescue!
Chapter 6
Thank you for staying the course through the preceding five chapters. After the first chapter I did not know that this series would materialize into six distinct chapters but, here we are! Thanks again.
At the end of chapter five we arrived at a true inflection point: the realization that it is possible to build an architecture and an API that reduced network discovery down to a single point. This essentially cuts off the ability for an intruder to discover and map your system’s architecture. This is a very powerful weapon against cybersecurity threats – the ability to build an architecture that is secure by design.
So…How did we get here?
The Modern Mainframe Architecture
In chapter one I put forth the proposition that we should adhere to an architectural design that places all of our data and business logic at the data-layer, connected to clients by an elastic middle tier that merely acts as a security isolation layer.
The first step in accomplishing this is to accept that we must pivot away from the legacy file system and embrace a more robust data management model for unstructured data and business logic. Advanced relational databases that encapsulate logic and with robust BLOB support are the natural candidates to fulfill this role. Furthermore the database must also support a mechanism that allows one to extend the logical capability of the data-layer programming language. It’s important to know that we can implement any logic required with the data that we now have at-hand.
JSON has become the lingua franca of the internet and it is a perfect medium to tie together the client layer, the middle-tier and the data-layer. Therefore, our choice of database must have native, built-in support for JSON. The database needs to not only recognize JSON data but must also be able turn normal SELECT sets into a JSON array-object.
With all of our business logic in the database, our application routing also lives there and that means we can implement our desired single-point API.
Recall that the traditional mainframe architecture was comprised of smart terminals, a network controller and the mainframe computer. The obvious modern equivalent is a web browser for your smart terminal, the elastic middle-tier isolation layer is the network controller and an advanced relational database is your mainframe. What’s old is new again!
Security Implications
Let’s take a look at the security implications of our proposed modern mainframe architecture.
Unstructured Data Migrated and Secured
Right off the top, we have a big security improvement: no more unstructured data files in directories. In fact, our new architecture generates dynamic filenames on the fly. These filenames convey no user information whatsoever. Generating filenames is a transaction which we can track, verify and audit. With no files in directories, ransomware is out of luck. We have also limited our exposure to hackers. They will not be able to freely harvest information from the file system.
Business Logic Migrated and Secured
Migrating business logic to the database allows us to extend its security apparatus to our programs. One of the ways I define being hacked is when your data is accessed by foreign logic – however that happens. In our new architecture, it will be a lot harder for foreign logic to embed itself and operate upon your data.
It is also important to remember that, in our new architecture, all SELECT statements have been migrated out of the middle-tier and embedded in the database.
Limited Network Discovery
Central to limiting network discovery, as pointed out previously, is the creation of a generic, single-point API. By having an API with one function in it, infiltrators will be unable to deduce or gain any insight into the operations of the system.
Minimally Provisioned Architecture
With our SELECT statements embedded in the database, and a generic middle-tier API that limits network discovery, we can now utilize a proxy user in the database with execute-only privileges on the API. This allows us to create a tiered, minimally provisioned architecture where the owner of the application logic and data is isolated from normal production use – meaning the user is prevented from connecting to the database.
With our proxy user in place, all they can ‘see’ is the single-point API. Following upon this concept, we can now organize our database so that the only password with any security relevance is the DBA password. We now have an architecture where:
The DBA will do all application and schema updates
The application owner can’t connect to the database
The proxy-user has limited insight and can only see our single-point API.
It’s also important to note that updates to the system via the DBA username and password is now an event that can be tracked and audited.
Granular Security
With our Generic API in front of everything, we now can ensure that ad-hoc access to data is prevented and our secure, audited business logic brokers all requests and transactions. I call this granular security. There is no way to get at the data with out going through the business logic. Contrast that to the random, and ad-hoc nature of accessing data; a common design practice today. In essence, if you can connect to your production system architecture as a user other than the DBA and ‘see’ the data or business logic, you have a problem and hackers have their advantage.
Generic Middle-Tier
With no data resources or business logic in the middle-tier, we can create cookie-cutter images that are easily materialized on an as-needed basis. This has tremendous value in regards to disaster recovery, elasticity and ease-of-use.
Intrusion Detection and Alerting
The centralized nature of our architecture makes it easy to build a self-alerting, proactive system that is able to respond intelligently to cybersecurity threats and intrusions. In fact, many of the techniques employed by hackers and ransomware become anti-patterns that quickly reveal the intrusion. This architecture drives down the threshold between intrusion and detection.
Promotion of Best Practices
With logic now brokering all requests for and modifications of data we can easily ensure that best practices are taken into account at all times. A great example of this is ensuring that credentials or session IDs are always checked.
It’s also easier to devise and refine patterns that can be applied throughout the code. This is always of great value when bringing in new developers to a project.
Operational Benefits
With all of these security benefits, surely there has to be some operational pluses as well. Here are a few:
Simplified audit and compliance
Unified backup, restore and disaster recovery procedures
Elimination of file system allocation and storage hierarchy planning
Reduced middle-tier footprint
Enhanced environment for sharing and coordinating unstructured data
Unification of cloud and on premises architectures
Simplified elasticity in four dimensions: Database performance, Database storage, Middle-tier performance, Network bandwidth
Reduced network utilization
Simplified implementation of redundant systems
There’s Gotta Be a Catch
This all sounds so good but, there’s gotta be a catch somewhere; everything can’t be roses and blue skies. Yes, there’s always a drawback. The most obvious is that you will be embracing a seemingly old and dated architecture – the monolith. This can not be avoided in a modern mainframe architecture. The database you choose will be central to your architecture.
Some favor today’s middle-tier heavy architecture specifically to avoid the drawbacks of a monolithic approach. The trade-off there is the obvious inability of a middle-tier oriented approach to deliver on any of the security and operational benefits of The Modern Mainframe Architecture.
Another drawback is that this is all rocket science to most. It’s also diametrically opposed to what the software industry is doing right now. If you try talking to people about these concepts, for most, their eyes will glaze over. But the ideas are solid and for some they will realize that what you are talking about is a game changer.
A Final Word
In conclusion, it is important to realize what The Modern Mainframe Architecture is capable of. I like to think of three levels of cybersecurity threats:
Somebody steals your credentials and gets your data
Somebody finds a hole in your API
Somebody infiltrates your architecture and gets access to all of your data
The Modern Mainframe Architecture can help solve your architectural vulnerability. This architecture also helps you to build secure APIs. Finally, the self alerting and resilient nature of The Modern Mainframe Architecture helps you to notice and recover from a breech of credentials
I’d like to thank you for accompanying me on this journey of discovery. A goal of finding a more secure, resilient architecture should be something we all strive for.
I welcome all that are interested in these concepts to reach out to me directly through my profile at LinkedIn. Thanks again.
