Mainframe security

Still don’t understand why (or don’t believe) the security of apps that interface with old mainframe applications is none or just security by obscurity?

Here’s the level of understanding of networks of the average mainframe guy:

http://www.mainframegurukul.com/ibmmainframeforums/TSO-Command-retrive-Server-name-from-IP-Add-post5539.html

(via @mainframed767)

There’s a huge knowledge gap between mainframe and network/distributed systems guys. The mainframe guys don’t even understand the threat models from our systems (most of them don’t understand anyone can connect to an open port on an IP host, for example), and we don’t understand how things work inside big iron. I’ve been talking about this for years, it’s a recipe for disaster.

I wonder when we’ll see the first malware capable of probing those systems.

They are certainly shifting!

Loved that bog post from Jeremiah Grossman!

“the bad guys SHIFTED”

They’ve been doing that for a long time (here’s my post about it, from 2006), and it’s economics 101: they’ll always be looking for the path of least resistance and for higher pwn/effort ratio. I wrote about it again a few months ago.

Jeremiah insight about security tools is right on the spot. Does anyone remember some nice work from the Sensepost guys around XSS code created to be triggered on web interfaces of security tools, such as IDS and SIEM? That was a long time ago, but it confirms the feasibility of what Jeremiah is saying.

An indirect effect of it is how hard it becomes for us to run appropriate Risk Management programs. Some completely disregarded targets and threat vectors can become mainstream in just a few months, basically invalidating models and assumptions. As most risk assessment methodologies require you to map the threat vectors being considered, it’s hard to get reliable results when they are constantly changing. How to handle that?

A good option is to try to decompose the model as much as possible in smaller components, isolating the pieces that are always changing in a way that you can control how that uncertainty affects your model. FAIR is a good example about how to do that, as VERIS is a good way to make past data more usable even if it’s related to incidents occurred under a different reality. With those decomposing models it’s possible to identify the pieces of data we have with less uncertainty and leverage that to identify sources of risk and opportunities to reduce it. What does it mean? It means that vulnerabilities being exploited change all the time, initial compromise points too, but the actors are more or less the same (I mean, the change in the threat agent profile is slower than the other components) and they are usually trying to accomplish the same thing by reaching the same end targets. By knowing those pieces we can identify control opportunities that will affect less uncertain and less dynamic aspects of our risk, allowing us to get a more reliable and measurable result.  

bolt on vs. built in

So, for a Friday the Twitterverse has been quite busy with interesting security discussions. Mostly generated by Gunnar Peterson (@oneraindrop) and Rafal Los (@Wh1t3Rabbit), the discussions are floating around why others (business, developers) are not listening to security. As part of the discussion, the old absolute truth “security must be built in, not bolt on” was repeated over and over again. Of course, isn’t it obvious?

Is it?

Shouldn’t we’ve been trying to think out of the box, to question even the “absolute truths”? (That’s for @joshcorman)

So, can’t we stop and think for a while why we think security should be built in, and not bolt on? And why, even if everyone agrees with it, we are still bolting it on, over and over again?

Well, I think one of the things we should be doing is thinking about new and better ways to bolt on security! If it’s happening it’s certainly because the business wants to work this way. Ok, in ideal conditions we may never be able to achieve the same security level with it (or optimize the security/cost ratio), but if that’s the way all the other players involved want to deal with security, shouldn’t we try to optimize how to do this?

It’s just a small firestarter as I haven’t thought that through, but I think we can, in fact, do something like that. Just think about all the things that are being done based on the new virtualization technologies. Things like Fire Eye, commonIT virtual browser technology and other sandboxing products, they are all “bolt on” security. I can remember a couple of situations I dealt in the past where the best security solution found for a specific system was to encapsulate it in a security shell, something that is extremely easy to do with the current virtualization tools.

So, instead of trying to change the world, why can’t we also spend a few minutes thinking about how to improve the current “bolt security on” approaches? It may reveal being a better option than the pie in the sky we keep praising in this small and cozy echo chamber called security industry.