Tokenization as a service

I mentioned a few months ago in a previous post that there was an opportunity for tokenization being offered as a service by big players (I mentioned Visa at that time).Well, it turns out that it's finally coming. Akamai is offering it, and it makes complete sense.

BP spill a Black Swan?

It's really old news, in fact the well is finally closed at this time, but it's interesting to follow the discussion about the BP spill and if it could be considered a "Black Swan".Alex is right to complain about the abuse of the concept. But I like to point to another aspect. People will usually relate the Black Swan concept to the probability of the event ocurring only. A very important aspect of those events is the impact. In fact, the higher than expected impact. As Alex, I also believe that BP was aware of the chances of a spill ocurring at Deepwater. But did they expect the results of the spill? The billions of losses? What I think makes the spill a good example of Black Swan is the fact that the consequences were far higher than the expected. And this aspect generates even more interesting considerations for our infosec discussions.Most of the time spend in risk assessments is over the likelihood of an incident. I don't know why the Impact aspect does not get the same amount of thought...maybe a careful consideration of the outcome of an incident will be seen as FUD? "Are you saying that an accident in a single platform can cause billions of losses for the company? C'mon! That's FUD!!"The Black Swan card is often seen as an excuse when the likelihood of an event was underestimated. Even if sometimes that's true, we should also see it as an indication of lack of resilience, a single incident causing catastrophic results. As someone said one of these days on Twitter, the "failed miserably" expression is too common now. So, instead of trying to reduce the likelihood of those failures, what about working to make then less miserable?

Not using "Risk Management" doesn't mean "no decision making"

I found an old bookmark in my "to blog" folder related to a New School post from David Mortman, "Decision Making Not Analysis Paralysis". I am one of those with second thoughts about our risk management tools. If you're still confident that you can use risk assessments as base of security decisions, I suggest reading "The Drunkard's Walk", by Leonard Mlodinow.I cannot say that I'm 100% sure that risk management is useless. I just don't feel enough confidence that it gives us what we need during the decision making process. So, David is saying that executives usually have only a small fraction of the information about an issue when deciding. He also says "Personally, I like to have some data based rationale for how those decisions get made". The point here is that we, the risk management skepticals, are not arguing against decision making. We are arguing against the illusion of a "data based rationale". If you are deciding something over 10% of the overall data, that's not a lot more than a gut feeling decision. There's the even more negative aspect of believing the decision is fact based when it's just slightly more than guessing.So, let's not throw away the baby with the bath water. Decision making is crucial. What I expect is a method to do that better and without the illusion that it's a fact based rational decision. At this time I don't see risk management as that method.

Twitter Updates for 2010-09-23

• Do we really need a firewall on our desktops? / Don't go that way. Every device should be able to defend itself. #


• unless, off course, you have a totally down-to-port-level-easily-manageable network. Then, maybe. Just maybe. #

Powered by Twitter Tools

Facebook and security economics

Studies about security economics are always interesting, and Ross Anderson is probably the biggest name on that. He just wrote a small but very nice piece for the New York Times about Facebook. You can read it here. I love this part:"Finally, Facebook might lock in its users even more tightly than Microsoft. People want to use the sites their friends use. As one of my students put it, "All the party invitations in Cambridge come through Facebook. If you don't use Facebook you don't get to any parties, so you'll never meet any girls, you won't have any kids and your genes will die out."

Twitter Updates for 2010-09-22

• Alright, and here we are testing the tweets at the blog sidebar ;-) #


• Very nice piece from Cory Doctorow "Promoting statistical literacy" - Useful not only for security, but for life #

Powered by Twitter Tools

EMET

Funny how sometimes, due to the information overload, we just miss
very interesting stuff being released. Today I was reading an article from the Microsoft Security Research & Defense blog
about how to mitigate the new Adobe exploit with a tool called EMET.
WTF?!?!? I was amazed when I read what EMET is the idea behind it:

Enhanced Mitigation Experience Toolkit

"For those who may be unfamiliar with the tool, EMET provides users
with the ability to deploy security mitigation technologies to
arbitrary applications.  This helps prevent vulnerabilities in those
applications (especially line of business and 3rd party apps) from
successfully being exploited.  By deploying these mitigation
technologies on legacy products, the tool can also help customers
manage risk while they are in the process of transitioning over to
modern, more secure products.  In addition, it makes it easy for
customers to test mitigations against any software and provide
feedback on their experience to the vendor."

Microsoft has developed a series of defenses against the most common
code execution methods used in exploits, such as DEP and ALSR.
However, some of those defenses require that software is recompiled
with new compatible compilers. It seems that some pieces (DLLs) of
Adobe Reader still haven't been recompiled to use ASLR, keeping some
doors open to the exploit writers. So, EMET can be used to force ASLR
to that software even if it was not prepared for that. Of course it
can be deployed by default on everything, as there's a small chance of
breaking stuff, but it is a nice tool for those who want to add some
protection while accepting to have an eventual issue here and there.

Next step from Microsoft could be an automatic assessment on software
installation to verify if EMET is necessary and, if so, keep control
of what is using it so users can try to disable it when an error
occurs. That would be almost transparent while adding a pretty much
amount of security.

Going into the same line, FX announced a great tool to add a layer of
protection for Flash files in Defcon, Blitzableiter. Take a
look at that one too, it can be integrated with Firefox and NoScript,
pretty nice approach.

Does anyone still think about honeytokens?

Honeypot technologies are always relegated to a second place or to experimental environments only. However, I was reading about the most common attacks in the Verizon DBIR report: malware stealing data - memory scrappers, etc. All automated stuff searching for "valuable" data! This is exactly the kind of threat that can be easily identified by honeytokens. And it doesn't have to be extremely complicated. A quick and dirty solution that could help a lot:

1. Create a text file with a bunch (10? 100?) fake credit numbers, all of them with, let's say the same first 10 numbers. There are thousands of credit card number generators out there that can do it. Distribute the file using your regular software distribution tool to all your desktops.


2. Install a custom signature in your perimeter IDSes searching for those initial numbers.


3. Run periodically (monthly? weekly? daily?) a job with something like "cat file > /dev/null" that will be enough to bring the contents of the file to memory. Something that could keep the contents in memory for a couple of hours would be best.


4. Monitor for anything triggering that signature. If anything hits it there is a high chance you have malware like those mentioned in the report running on your desktops.

I know it is very targeted to a specific type of malware, but as it looks like this type of malware is responsible for the majority of the incidents and records in the report, it might be worth the (small) effort.

Exceptions can taint assumptions

Exceptions can taint assumptionsThis phrase came suddenly in my head when I heard someone mentioning something as an assumption that I knew it wasn't in place. That's something that happens quite often with security controls. Someone decides stuff such as "no unapproved software will be allowed to run on the corporate desktops", and from that moment it stops being a goal and starts to be an assumption to remove threat vectors. That's a very good example of threat modelling and risk assessment going wrong, "we don't need to worry about this threat because non-authorized software does not run in our desktops". They often forget about those dozen exceptions filled and approved the week after that rule was instated. So, next time you hear someone mentioning a control as an assumption to disregard a threat vector, consider the exceptions for that control. How many exceptions are necessary to invalidate that assumption?

Create and Share Labs!

This is a very nice alternative for the full Amazon EC2 prices! If you need to bring up some VMs for testing, try LabSlice. It's a very nice way to get VMs up for a good price when we need them only momentarily.