We're completely and totally owned

Reading this whole thing about NSA capabilities just make us realize the simple truth: we are completely owned.

Happy owned 2014.

PCI DSS v3.0

The new version of PCI DSS is finally out there.

Nothing Earth shattering, but it’s good to see some necessary clarifications making their way into the document. Things worth mentioning:

 

-          Integrating the content of “Navigating DSS” into the standard – Great!

-          Changing from “file integrity monitoring”  to “change detection monitoring”  - Yes, please!!

-          Rationalizing that craziness in the policy requirements (distributing 12.1.1 stuff into the other requirements) – Very good, that’ll make QSA lifes easier

-          Changes to the pentesting requirements – Good, now it specified what’s expected from a penetration test

The whole PCI thing stinks, but at least 3.0 stinks less than 2.0 :-)

From Mr. Geer's infinite wisdom

I managed again to finish reading a Dan Geer speech without my brain exploding. This one is his "Trade-Offs in Cyber Security" one (9 October 13, UNCC). As usual incredibly well written and dense, very dense. There's a specific point I liked because of stuff I was planning to right about:
 

 
"But only rarely do we ask our Legislatures to make mitigation effective.  Instead, over and over again we ask our Legislatures to make failure impossible.  When you embark on making failure impossible, and that includes delivering on statements like "Never again," you are forced into cost-benefit analyses where at least one of the variables is infinite.  It is not heartless to say that if every human life is actually priceless, then it follows that there will never be enough money.  One is not anti-government to say that doing a good job at preventing terrorism is better than doing a perfect job."

That's how we usually react to breaches, while simultaneously preaching there's no 100% security or "zero risk". This just doesn't make sense. As we're always talking about lessons learned exercises after incidents, how frequently have you seen one of those cases end up with this conclusion: "breach aligned to previously assessed residual risk, no further actions required"?
 
If that's not happening we are either not assessing risk correctly or we haven't done the appropriate job to ensure risk acceptance is well understood by decision makers. We are turning "small risk accepted" situations into "never again". This is how we end up with scenarios like the derivatives crisis (I was about to say Black S***, but I want to ensure no kittens are harmed during thi post writing). There's a big difference between almost impossible and impossible, even if they initially look the same. As Dan Geer also said in this same speech, "Proving a negative requires omniscience". Do you know absolutely everything that goes on your network?

More defense, and real meat

There was an interesting blog post from Rich Mogull a few months ago about the security community not putting enough effort on defense related research as we normally see for offense. As he quite rightly points out, "breaking things is, in many ways, far less challenging than protecting them. I am sick and tired of seeing researchers and pen testers on various mailing lists brag about how easy it is to get into their clients’ systems. I suspect the ones who understand the complexity of defending complex environments with limited resources keep their mouths shut".

 

Not that there isn't any defense related content being presented out there; you'll see plenty of defense content in the major security conferences agendas, but for some reason it's still hard to find stuff that is immediately implementable. Think about it, how many times have you been able to come back from a security conference with stuff ready to be used by your organization? I understand that we need to adapt things to the specifics of each environment and there are a lot of nice ideas that although not immediately applicable will still drive change to practices and move things forward by affecting the way people think about problems and solutions. But we are missing real meat, things that could help security professionals to justify their presence in those events.

 

Most of those events include the offense side. Defcon, for example, has a huge focus on that and I don't think it would make sense to try to change that, it's part of that conference identity. But, even on cases like RSA, where there are lots (I would say the majority) of defense content, we are still missing the part related to implementable content. I;m not saying those discussion panels, threat evolution assessments are not useful, but they serve a different purpose, keeping the minds of the security community aware of the changes and evolution of our world. That's very important. Still, there's still a gap between that and the offense piece that needs to be filled.

 

There are some forums and events with that kind of content. SANS conferences are probably a notable case. The things I've seen being presented on the different b-sides events are also interstingly more aligned to implementable content. Vendor conferences are also good with that; one of the major challenges is present content useful for organizations and vendors can show things closer to the implementation level by leveraging their own tools and showing how to use their cool features. But still, it's a very limited audience and content framework (they won't show stuff that can't be done with their products :-)).  

 

There are some good examples of online forums and resources with actionable defense content. The IDS signature databases started a trend of blacklists and crowdsourced resources that made a lot of good stuff for defenders to use in their day to day, but there's still room between tht kind of content and the more inspirational stuff from talks and panels at RSA. There's still so much to share out there. Imagine if we could go to a conference where the content is mostly stuff we can immediately start using in our organizations and generating immediate value. I'm talking about a security conference where the criteria for accepting content would be:

 

• D: Defense. This is the basic. The content should be related to defense techniques, not offense. If you want to break stuff go to Defcon and BlackHat.
• A: Actionable. Stuff that you can go back home and start using. It doesn't necessarily mean technology, it can be a risk assessment method or a new way to write security policies. Interesting technology pieces would be new open source security tools, SIEM rules and new ways to integrate existing tools.
• M: Measurable. And, by the way, how do we know if this stuff is actually working? This would force speakers to show how they concluded their stuff is worth trying. Have they found stuff that was previously unnoticed on their networks? Have they somehow managed to validate the magical numbers from their risk assessment?

 

I would call this new conference DAMSEC :-)

 

To better illustrate the idea, here are some talks from past conferences that would nicely fit into DAMSEC's track:

 

BUGALYZE.COM - Silvio Cesare - Black Hat 2013 - Free tool to help on static code analysis

 

 

Defending Networks with Incomplete Information: A Machine Learning Approach - Alexandre Pinto - Black Hat 2013 - ML Techniques that can be used by SecOps groups

 

Hunting the Shadows: In Depth Analysis of Escalated APT Attacks - F. Yarochkin, PK Tsung, MCJ Chiu, MWB Wu - Black Hat 2013 - Open source tools and techniques to be used for advanced malware detection

 

Extreme Cyber Scenario Planning & Fault Tree Analysis - Ian Green - RSA 2013 - Full process to be used for security planning and control selection

 

Patching Stupidity - Jack Jones - RSA 2013 - Down to earth approach to understand reasons and address security issues from "users stupidity"

 

 

So, is there anyone interested in putting together such event? :-)

This is not the Tomcat server you are looking for

It seems that VMWare has some hidden security magic power that we mere mortals are not aware of. Check this blurb from the ESXi documentation:
 
"The Tomcat Web service, used internally by ESXi to support access by Web clients, has been modified to run only those functions required for administration and monitoring by a Web client. As a result, ESXi is not vulnerable to the Tomcat security issues reported in broader use." 

Doesn't it sound like a "this is not the Tomcat you're looking for" Jedi trick? C'mon guys, good to know you're reducing the attack surface, but don't give false assurances to your clients. It's hard to convince the Ops guys to patching and other security hygiene, this stuff above will just make them resistant to patch (or even check/test) anything on their ESXi servers related to Tomcat. Not helpful at all.
 

Touch ID and Blackberry

Apart from the never ending transit debate in Toronto, the news dominating my twitter feed today are related to the Apple’s Touch ID hack and the Fairfax bid for Blackberry. My quick comments on those two:

-          Touch ID hack: of course it was only a matter of time, but let’s face the facts. There are far more expensive and complex fingerprint sensors that are also vulnerable to similar attacks (Gummy bear fingers, anyone?); just keep in mind that the threats Apple is considering for this technology (very good Threat Modeling blog post from Daniel Miessler – just keep in mind he is an Apple fanboy :-)) are opportunistic attackers, not determined ones (such as NSA…). Not only that, the main business goal for the technology might be more on making the life of the user easier than to make things more secure. And to introduce shiny “futuristic” gimmicks too, of course :-)

-          Blackberry: and here it finally goes private…it’s a sad thing to see a company with that lead blowing things up so miserably. The interesting perspective of this situation is that it increases the speed organizations will have to move towards (or at least consider) the BYOD model. But don’t completely write off Blackberry yet; it can very well rebrand itself as the go to options for the technology required for a good BYOD strategy – BES10 has a huge potential to be the killer MDM tool.

-          Blackberry (2): Until now BES and the Blackberry network were like those undersea cables: a very nice point to massive eavesdropping. Now it’s gone. I believe we can expect a heavy shift of research resources moving to find more effective ways for massive monitoring of mobile devices, now that those convenient choke points will no longer be used.

Ping!

Hi. I’m still here.
 

This is another attempt to revive this blog. If you’re still with me (i.e., you still have this blog on your RSS feed, you still use RSS feeds or you follow me on twitter and clicks on links from my twitter feed) you’ve probably noticed the I dramatically reduced my posting frequency here. I realized it happened for a multitude of reasons:

- Other channels – just like other security folks, I was also dragged to other communication channels, specially Twitter.

- Personal life – Yeah, I’ve got a kid now. That sucks all possible free time that eventually appears on my schedule. That’s not a bad thing, by the way; I rather play with him that writing about security on my free time :-)

- Security burn out – Never thought it would happen to me, but it did. Our field is a huge echo chamber and eventually our cynicism level is so high that we just can’t see any value on anything and nothing sparks interest enough to make us write about it. Ok, a few things are interesting, but there’s a point when the inertia is so big that the only thing we manage to do about it is to send a tweet.

- Work confidentiality – I cannot say that I don’t see anything exciting about security. If that was the case I would probably move to something else; unfortunately, a lot of those nice things are related to my current employer and I wouldn’t be able to write about it without putting to much information that is not supposed to be public. The effort to spin in a way to sanitize it is just too much and contributes to my current inertial state.

I’ve been thinking about all this and what I could do to come back. A had a few notes on my “ideas to pursue” list, but nothing exciting enough to make me write about. So I decided to try a different approach: I’ll try to write constantly, but with less structure and with no clear objectives. It would be almost like tweeting without working on the 140 chars limit. So, there will be a lot of incomplete thoughts, half baked ideas and ramblings. But I expect that the effort might be able to revive the habit of writing, putting me out of the inertial state. So, even if things look a bit odd, please, stay with me - I promise I’ll try to at least make it a little more than meaningless stuff :-)

Interesting: Summary: Here’s to the Defenders

From Securosis Highlights:

I was reading Roger Grimes’ interview with an offensive cybersecurity operator, and one key quote really stood out:

I wish we spent as much time defensively as we do offensively. We have these thousands and thousands of people in coordinate teams trying to exploit stuff. But we don’t have any large teams that I know of for defending ourselves. In the real world, armies spend as much time defending as they do preparing for attacks. We are pretty one-sided in the battle right now.

As much as I enjoy playing offensive security guy once a year at Defcon, I find defense to be a much more interesting challenge. Unfortunately many in our community don’t consider it as ‘sexy’ as penetration testing or vulnerability research. We need to change that.

Most of us started our exploration of technology as hackers. I am fully willing to admit I was fascinated by cracking systems, and engaged in activities as a kid that could land me in jail now. Nothing major – I always assumed it was much easier to catch hackers and phreaks than it really was. I mean seriously, it wouldn’t have been all that hard back then. It turns out no one was looking – who knew? That’s what I get for assessing national computer law enforcement capabilities based on repeated viewings of War Games.

But breaking things is, in many ways, far less challenging than protecting them. I am sick and tired of seeing researchers and pen testers on various mailing lists brag about how easy it is to get into their clients’ systems. I suspect the ones who understand the complexity of defending complex environments with limited resources keep their mouths shut. Breakers, with very few exceptions, aren’t accountable. Outside of movies, there are no consequences if they fail. Not yet, at least. No guns to the head as you sit in front of 32 widescreen monitors with 8 keyboards spread out in front of you and a coked- megelomaniac watching you waste part of your 60-second window on a visualization so your code looks good for the cameras. Nope.

Builders? Defenders? Our lives are nothing but accountability. We are the firefighters, doctors, cops, and engineers all wrapped into one. Without us who would keep the porn flowing? It is a far more complex challenge, with nowhere near enough disciples.

Many of our smartest focus on offensive security for obvious economic reasons. If you are good there is more money, less accountability, and more freedom. Smart defenders, even if they come up with a groundbreaking idea, need time and resources to build it – which often means productizing it and dealing with idiotic investors and bureaucracies. There are far fewer opportunities for smart defenders to perform research leading to practical tools and techniques.

The only thing that can change this is money. Sure, I’d love to lead a cultural revolution, but that is more my desire to send people to re-education camps than any inherent belief we will all suddenly focus on defense due to some higher calling. (I’m serious about the camps – I have some awesome ideas). We need some serious investment – and not in academic institutions who often fail to remember sh*t needs to work outside a lab.

Breaking and offensive research are important. Doing them well is hard. But defending? That is a challenge.

I suspect I will be talking about this at Defcon. But with more beer.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

• Adrian’s DR Post Why Database Assessment.


• Rich has another article at Macworld on security for switchers.


• Rich’s DR post: Security Needs More Designers.


• Mike’s article at Information Week.


• Dave Lewis on Disaster Recovery at CSO Online

Favorite Securosis Posts

• Mike Rothman: Using Amazon IAM Roles to Distribute Security Credentials (for Chef). Holy crap. A blog post from an analyst with code and screen shots! OMG… See, some analyst have some kung fu after all.


• David Mortman: Rich’s first post on security automation.


• Rich: Continuous Security Monitoring: Classification. This is a good series.

Other Securosis Posts

• The Endpoint Security Buyer’s Guide [New Series].


• Living to fight another day….


• Another Disclosure Debacle, with a Twist.


• Using cloud-init and s3cmd to Automatically Download Chef Credentials.


• Incite 7/10/2013: Selfies.


• Kudos: Microsoft’s App Store Security Policy.


• How Not to Handle a Malware Outbreak.


• RSA Acquires Aveksa.


• Multitenancy is the Least Interesting Security Property of Cloud Computing.


• Continuous Security Monitoring: Defining CSM.


• Calendar Bites Google Security in the Ass.


• Proactive WebAppSec.


• Why. Continuous. Security. Monitoring? [New Series].


• New Paper: Quick Wins with Website Protection Services.


• Database Denial of Service: Attacks.


• OpenStack Security Guide Released.

Favorite Outside Posts

• Mike Rothman: Proving the skeptics wrong. You can only achieve true success when you do things for the right reasons. Seth Godin reminds me that proving someone wrong isn’t one of them. At some point you run out of people to rail against…


• Adrian Lane: Data Leakage In A Google World. People forget that Google is a powerful tool and often finds data companies did not want exposed. It’s a tool to hack with, and yes, a tool to phish with.


• Chris Pepper: Solaris patching is broken because Oracle is dumb and irresponsible.


• David Mortman: Dear Speaker, I Loathe You. Sincerely, Your Event Planner. Funny.


• Rich: No, Hacker Really Does Mean Hacker. Yep. Get over it.

Research Reports and Presentations

• Quick Wins with Website Protection Services.


• Email-based Threat Intelligence: To Catch a Phish.


• Network-based Threat Intelligence: Searching for the Smoking Gun.


• Understanding and Selecting a Key Management Solution.


• Building an Early Warning System.


• Implementing and Managing Patch and Configuration Management.


• Defending Against Denial of Service (DoS) Attacks.


• Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments.


• Tokenization vs. Encryption: Options for Compliance.


• Pragmatic Key Management for Data Encryption.

Top News and Posts

• Google releases fix to OEMs for Blue Security Android security hole. This is seriously ugly.


• How the US (probably) spied on European allies’ encrypted faxes.


• Researcher finds way to commandeer any Facebook account from his mobile phone.


• Crimelords: Stolen credit cards… keep ‘em. It’s all about banking logins now.


• DEF CON to Feds.


• Aeroplan Provides Proactive Customer Alerting


• A Black Hat, DefCon and B-Sides survival guide


• Vermont and North Dakota Amend Breach-Notice Laws


• Judge Orders U.S. to Release Aaron Swartz’s Secret Service File


• Multi-platform Java RAT targeting government agencies

Blog Comment of the Week

This week’s best comment goes to Dwayne, in response to Incite 7/10/2013: Selfies.

I’m very interested in Adrian’s item under “No firewall for you” as I have heard a number of organizations discussing this. I really want to hear some post-facto analysis from companies who go this route, to find out what differences (positive and negative) they experience.

Along those lines, I have been in conversation with a couple of companies who want to get rid of antivirus because they feel it isn’t adding value (at least in the data center). Unfortunately, they both have to answer to PCI which explicitly requires AV so that is a bit of a problem.

In general, I think the more we can streamline the number of countermeasures and controls we have to manage, the better. But it is definitely a “look before you leap” problem.

BTW – I’m with you on the selfies – definitely fascinating. My daughter told me about “duck face” selfies, which are apparently a sub-class of the normal selfie. You can find a lot of them on Flickr, too.

- Rich (0) Comments Subscribe to our daily email digest

via Securosis Highlights https://securosis.com/blog/summary-heres-to-the-defenders

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.