The enemy within

I happened to find myself in the couch this evening. Somehow I managed to get hold of the remote control and leisurely zapped through the available channels (there's a crapload of them, unbelievable).   I don't think I was really paying attention until I heard someone speak Chinese. While rusty, my Chinese is good enough to understand a normal conversation so my interest peaked. 

The documentary I ended up watching was about the (actually very recent) history of how companies have mushroomed in the GuangDong province, especially in the ShenZhen area. Their business model has always been as simple as it was genius. With the availability of huge numbers of unskilled workers, these companies were able to deliver quality work at prices that were unparallelled. 

As rumor got out that money was to be made, even more workers travelled from the rural areas to make money. Or rather, to make a living. The money they made was used to support their families back home. Thousands of kilometers away. It was used to feed and, more importantly, educate their kids. And with that, something interesting happened. The next generation, still willing to work but more than ever aware of their value and empowered by an improved education, in their turn traveled to the south. They did not have a family back home and their interest was to make an income that supports their desires. As labor became more expensive, companies in the Guangdong province struggled to stay competitive (in the end they all do much of the same) and inventive entrepreneurs found a new Guangdong in Cambodja. Cheap labor, not many questions asked, willingness to work.

Now this doesn't really go anywhere specifically related to infosec but it hit me like a brick that the people featured in this documentary were not unlike you and me. They were normal people, with families, with responsibilities, with ambitions and with dreams. Whether you are in the US, in Europe, in Africa or in Asia doesn't really matter. As a human being (with some outliers) you want the best for yourself, for your family.

This is most probably the biggest problem I have today with the whole "ZOMG China is hacking us and stealing our sekritz"  movement (you know who you are Tao).

Over the past centuries various regimes across the world have passed blame for their failure to innovate on to larger or smaller populations. This has happened in Europe, Africa, Asia, ... It is not new and it has never worked. Many people have died there, often under gruelsome circumstances. 

The fact that companies, individuals and politicians engage in the culpabilization of more than 1/6th of the world population is -to me- a disgusting realization. While I'm sure that there is little doubt that Chinese entities have used hacking methods to gather intelligence and knowledge (or a competitive edge), I don't see a reason why the other players in this game have not done exactly the same. 

We have become our own worst enemies but instead of admitting it, we look for the next country that we agree to demonize.

It utterly sucks.

Caveat emptor 101

I try to read as much as I can. Whether it's articles, books, journals, blogposts doesn't really matter. If it is infosec related I'll soak it up and if it's any good I'll probably blend it into a corpus of knowledge I've gathered over the year.

In the past half decade our industry and community has been finding out what it takes to be relevant. A lot of relevancy is to be customer focused. Note that "customer" does not always imply that you have a commercial relation with the group or person you categorize as that. Naming the entities you deliver for "customers" helps you realize that it is your sole obligation to deliver value instead of firewall rules or anti-virus or secure code.

Caveat emptor is a very old principle (that's why it's written in Latin right?) that boils down to "buyer beware". It basically means that whenever you are in a buying position, you have to be careful that the thing you are being sold is what you asked for and not something else or worse ... something incomplete.

With that said, I introduce you to this post on the HP Enterprise Security blog.

The post is constructed around the failed interpretation of an RFP process, that in the author's experience apparently goes a little something like this :

1. Customer issues RFP
2. Customer makes purchase decision
3. Customer buys just the widget
4. Customer attempts to implement the widget themselves
5. Customer fails to leverage full capability of widget, project falls to the wayside, considered a failure or abandoned.

From this he continues to pass blame for everything that goes wrong in corporate security programs to the customer ... obviously preparing us for the next ground-breaking offering that will wipe out all of our collective sins of the past. We shall be whole again.

I take issue with may things in that premise. I'll try to address them seperately.

1. This RFP process is overly simplified for the purpose of your post. It disregards the role that both vendors and integrators/resellers play in forming the opinion of a customer, often shoving their concerns under the rug with an extra discount or a shiny presentation. 
2. It's easy to put blame on the customer and their "buying" behaviour. In various roles at various organisations in the past I have spent time on all sides of the table in RFP processes. I've written them, I've answered them and I've evaluated them. If there is one thing vendors/resellers can do it is not jumping on any opportunity for the sole monetary benefit it will get them. Honesty goes a long way, even in business. 
3. If you have any experience in running such projects at scale you will recognize the occurences where scope was suddenly interpreted differently because the reseller found out they would not deliver on time if the real scope needed to be covered. In this case it is often the customer that doesn't grasp what is happening to them and they're actively being ripped off. No worry, the project was a success and nobody noticed. 
4. Lastly there is the issue of knowledge transfer. I haven't seen a single RFP where knowledge transfer was not an item. The answers at the beginning of the process promise a unique approach enabling the customer resources to develop themselves into experts. The reality a few months later is bleak, knowledge transfer exists of a 2 page admin manual and a stock preso about the awesome features of widgetX. Box checked, project delivered, let's get drunk!

The post further elaborates on specific experience from the author. The first example (Project ADD) is an example of failure that is rooted rather in a failed project management approach than a failed infosec program approach. This is not something a "reboot of your infosec program" can necessarily fix.  

Now back to "caveat emptor". 

As old as it is, the warning still stands. If you are looking to buy a widget to protect your infrastructure or a consultancy service "to reboot your infosec program", be suspicious of the promises made. 

"Data Honesty" and why IOCs are not (yet)

In the past half decade I've been working in incident response and data analysis extensively, working on projects that helped monitor security-related data on very large networks and helping to building Incident Response capabilities that were empowered rather than paralyzed by that data. It is no secret that I have always been a big proponent of data sharing among peers to improve data quality and more importantly to build what I have started to dub "data honesty". A term I can only hope will find some level of adoption sooner than later.

"Data honesty" is, in its simplest form, the level of maturity where anybody with access to a dataset and the methodology used to derive information from said dataset will arrive at the same conclusions as you did. It is this level where you are confident to publish both your dataset and the methodology used.

There is no doubt that the Verizon Risk Team as a whole has pushed the envelope in this field for our industry. The work they have done in developing VERIS ("Vocabulary for Event Recording and Incident Sharing") is a tremendous effort that I feel our community has largely ignored. It helps to understand that the V in the acronym stood for Verizon in a previous incarnation in order to realize that this is exactly the reason why widespread adoption of VERIS among Incident Response service providers has not occurred. As with any standard, commercial organizations are only interested in the standard if there is an opportunity to OWN the standard (and thus an opportunity to exploit it for profit). It is, unfortunately, a problem that almost any standard in our industry has suffered from since forever.

All this has resulted in report after report based on, undoubtedly, real data but without any structured methodology. This doesn't mean the reports were constructed in bad faith but one always wonders how the data conveniently correlated towards a need for more services/product/... conveniently provided by the publisher of the report (or the one sponsoring it). 

All jokes aside, there has never been more interest in security-related data. To a point where industries are waiting for any data that can help make them informed risk decisions. The latest data points being thrown at us are 'Indicators of Compromise' or IOCs. VERIS covers IOCs here:http://www.veriscommunity.net/doku.php?id=iocs and frankly, I love them. They're little nuggets of information that, when related to properly analyzed incidents can turn an incident response effort upside down. But caveat emptor!

IOCs lose a lot of their value when not related to properly analyzed incidents. There probably lies their biggest weakness. Anybody can publish IOCs these days without the need to link them to any active (or terminated) targeted attack campaign and attribute them to "Wim Remes' bad-ass Belgian Hacking Team extra-ordinaire". It is no longer the thorough methodology that supports the credibility of the IOCs but the commercial power and (perceived) familiarity with the "threat du jour" of the publisher.

When respected researchers and entrepreneurs start calling for "IOC Wednesday" I would urge you to take a step back and look at VERIS first. If you can analyze and categorize your incidents based on the data YOU can gather, you won't need to wait for others to be compromised to protect yourself better. 

IOCs are, at this moment, not by definition "honest data" but you can use them to streamline the processes you build based on your own "honest data".

For those companies with a stake in Incident Response services, now is the time to set aside your egotistical reasons for not using VERIS in your analysis or reports. Any methodology will always have weaknesses but this is the one we have RIGHT NOW and for a flawed methodology, it's a pretty darn good starting point if you ask me. The RISK team deserves that credit and the industry deserves that standard.