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.

Great study on spear-phishing from TrendMicro

Trend Micro has published a great study about spear-phishing email. It’s available here.

Although I would also like to know the overall numbers (i.e. amount of samples that were used during the research, to ensure the findings are really meaningful), there is good data in the paper that can feed into a well established SecOps practice. Some interesting pieces:

“Monitoring revealed that 94% of targeted emails use malicious file attachments while the rest use alternative methods like installing malware by luring victims to click malicious links and to download malicious files and using webmail exploits”

“Spear-phishing emails can have attachments of varying file types. We found that the most commonly used and shared file types in organizations (e.g., .XLS, .PDF, .DOC, .DOCX, and .HWP) accounted for 70% of the total number of spear-phishing email attachments during our monitoring.”

I’ve been spending a lot of time looking at numbers that affect the ability to look for potential compromises. For example, how many email messages an organization usually receives (of course it varies a lot according to size/business)? How many of those have attachments? How many of those attachments could be considered potentially dangerous? Is this information useful to help on narrowing the focus of detection/investigation practices?

I believe our industry has spent a lot of time working on detection systems without necessarily leveraging evidence based guidance about what to look for, where to look for. Reports like this one from TrendMicro are really useful to change that and help organizations to maximize the return of their SecOps resources.

 

The grain of salt

As a non-native English speaker, I always like to learn new idiomatic expressions that give color to the language. One of my favorites is to tell someone to take some information “with a grain of salt”. According to Wikipedia,

The phrase comes from Pliny the Elder's Naturalis Historia, regarding the discovery of a recipe for an antidote to a poison.^[2] In the antidote, one of the ingredients was a grain of salt. Threats involving the poison were thus to be taken "with a grain of salt," and therefore less seriously.

An alternative account says that the Roman general Pompey believed he could make himself immune to poison by ingesting small amounts of various poisons, and he took this treatment with a grain of salt to help him swallow the poison. In this version, the salt is not the antidote. It was taken merely to assist in swallowing the poison.

The Latin word salis means both "salt" and "wit," so that the Latin phrase "cum grano salis" could be translated as both "with a grain of salt" and "with a grain (small amount) of wit."

The phrase cum grano salis is not what Pliny wrote. It is constructed according to the grammar of modern European languages rather than Classical Latin. Pliny's actual words were addito salis grano.^[3]

But why am I talking about this in a Information Security blog? Because I want to say that all security advice should be taken with a grain of salt!

When I’m reading security blogs and listening to security podcasts I’m always impressed how some of my colleagues present some advice as the ultimate truth. There are a lot of “MUSTs” (in fact, a lot of “MUST NOTs”), as a magical set of rules that will allow us to easily do everything we want in a secure manner. However, all of them forget about one of the most important pieces of solution design exercises: CONSTRAINTS.

Of course we don’t want to use FTP or TELNET. Yes, 4 digit only passwords is stupid. Oh, how come you still have Java installed?

It’s not because people are stupid (well…ok, sometimes). It’s because they have, in most cases, valid constraints to be considered when security is being assessed or designed. Sometimes the only software available in the market for a specific business process is that crappy screen scraper based on TELNET. Or that hardcoded password crap is provided by the vendor of a multi-million dollars medical device that you can’t just throw away because of a security vulnerability. We should always try to apply pressure and make people aware of how security unwise those things are, but let’s be honest, if we were in the place of an executive, would you really consider a huge change to your business because of things like that? No, you would tell your security team to “be creative” or, most probably, call one of  those big brand consultants to tell you what you want to hear.

So, let’s pick our battles. We’ll never be able to work under ideal conditions. We’ll have to deal with “stupid” things like FTP, Telnet, unpatched Windows boxes and unsupported software.  We should keep evangelizing the IT world that security should be built-in, but we have to be prepared to bolt-on.

Next time a security curmudgeon comes with his canned “you MUST NOT” advice, ask him back: “and what if I have to?”. That’s a good way to see who is just playing to the crowd and who deals with real world, full of constraints conditions.

Groupthinking

Very nice post from Dave Shackleford:

These days, I am very, very afraid for the future of CISOs. Over the past few years, and specifically the past 12 months, I have become increasingly alarmed at the level of “groupthink” and “synchronized nodding” going on with security executives. Here are some of the things I am seeing:

1.    Lots of talking about the same shit, with absolutely no innovation at all. Good examples include metrics (we need them! they’re IMPORTANT!) and talk about policy and governance that usually means absolutely nothing.

2.    A desperate need to find “the metrics” to report to “senior management” – there is no such thing. Your management, in all likelihood, does not want any tactical numbers on antivirus events, IDS alerts, or such blather. They want real risk advice on business goals and functions. Period.

3.    Managing by managing what everyone else is managing. You would not BELIEVE how many security products get purchased because other security executives are buying them.

[…]

That’s really the current picture of our field: people doing what the others are doing. I like his idea of treating the security program like a startup, but an interesting thing to consider is how many CISOs would have the opportunity to do that. Their bosses would expect something different, their peers, security committees and external consultants/auditors. It’s not easy to escape that rat wheel!

A CISO job where one have the opportunity to shake things up like Dave suggests is a dream opportunity for any security professional. Unfortunately a lot of  those in positions like that are too busy…groupthinking J

This is a test post

Sorry about this, but Posterous put some odd stuff on my LinkedIn profile for my last post's "autopost" feature. investigating what's going on...