Let’s talk mainframes for a bit. Part 1: Background and AuthC

In larger organizations, the back end of a web application is a mainframe. The mainframe is the final frontier of application security:

1. Uses a platform few if any in the application security industry know about
2. Those who do know mainframe security rarely interact with the outside
3. IBM trains young devs in how to program COBOL, RPG, or PL/1 for its large institutional clients, but they rarely – if ever – get taught the fundamentals of security, risk management, or even the basic security features of their platform and language
4. Most of the security features of the mainframe’s core languages simply don’t exist. For example, standard COBOL does not support SHA512. It has to call out to do that.

This is a shame as the mainframe is actually a damn fine security platform:

• One authC/authZ framework to rule them all. And it’s actually pretty good.
• A transactional model which is inherently thread safe
• Mandatory access control to data if you desire 
• Logical partitioning of hardware and resources in water tight sandboxes that Dinis Cruz wishes was in .NET 🙂 (sorry, Dinis, couldn’t resist)
• All modern IBM mainframes come with a hardware security module (HSM, a crypto card which can store keys and do safe crypto processing)
• and on, and on, and on… 

The problem is that most mainframe code does very little to protect itself. The original risk model is a 3270 green screen dumb terminal running in a locked down environment with fairly hardcore presentation layer access control (generally a menu system) being used by trusted staff members who liked their jobs. That same code is now not only well past the age of consent, it’s done the binge drinking thing, grown a goatee, moved out of home, shaved the goatee, and is thinking seriously about starting a family. And suddenly, it’s being hooked up on a blind date with code of negotiable value who likes to party by picking up all the keys in the bucket. Metaphorically speaking. You know where this is going. In a typical web application scenario, we have the following architecture:The usual problems we have here include:Authentication We talk to MQ via… one single connection. So does the database. So what’s the big deal? Well, in many systems, database queries are designed with this in mind. If you don’t, we have direct object reference attacks which result in loss of fine grained authorization. But let’s assume our data architect was clued in, and we see SQL like this:

SELECT * FROM orders WHERE orderID = ... AND userID = ...

or

SELECT * FROM orders WHERE orderID = ... AND roleID in (SALES_ROLE, MANAGER_ROLE, ...)

This prevents the attacker from seeing records which are not owned by the user, or in the latter case within the correct role. Mix and match to suit your requirements.Back the mainframe. We talk to the mainframe through something like MQ or SNA Server. The mainframe is running a piece of code written explicitly for a 3270 or 5250 terminal using menu level security or even better with a proper protection profile from RACF. Back in the day, each of these semi-smart terminals had their own logical address (LU) telling the sys prog who was logged in, where it was, and way more importantly… that a trusted staff member was doing stuff.When exposing mainframe transactions to the enterprise, the industry’s first shot at SOA was the Enterprise Message Bus, later renamed Enterprise Service Bus and lately seen down in the docks sporting the SOA name tag now that we’re doing exactly the same stuff as we were doing in the early 90s … using unreliable web protocols instead of reliable mechanisms like MQ, Biztalk or SNA Server.Next week, we start to see why it’s important to not only impersonate the correct user, but not to give the transaction more privileges than you need.