Bejtlich - versions

I really enjoyed reading this post from Richard Bejtlich. There is one piece that makes it almost perfect:

"Web 2.0: this is what is here, with more on the way -- essentially indefensible applications all running over port 80 TCP (or at least HTTP) that no developer really understands and for which no one takes responsibility"

I saw once a perfect example of this "no developer really understands". I was called on a weekend by a developer who was trying to deploy his new application into production. Obviously, the usual suspect for the problems he was facing was the firewall.

I spent almost an hour to understand not only where the application was running, but also its architecture. It end up that he wasn't aware that his web service needed a HTTP server! :-) After solving that specific problem, I scheduled some basic networking classes with that group of developers the next week. I noticed how deep they knew about Java, and other programming stuff, but they didn't have a clue about the data flow of their applications in a network perspective. Nice context to work with, specially if you you're trying to control the information flow on your network.

Phrack

like the phoenix, it's back again from the ashes. Cool.

Stration worm

There are news about the Stration Worm, which spreads itself using Skype and can migrate to other networks, like MSN and ICQ. That's very interesting, specially because it's quite aligned to what I presented on Black Hat Europe this year. Although I was talking about botnets, some of the trends apply to all kinds of malware. Now, using several communication channes is not a theoretical thing only, it's fact.

CC numbers are everywhere

This article from slashdot is very good. It's funny to see how easy it is to obtain credit card numbers. PCI still have a long way on securing this information, if this can be done after all. From the article:

"Some "script kiddie" tricks still work after all: Take the first 8 digits of a standard 16-digit credit card number. Search for them on Google in "nnnn nnnn" form. Since the 8-digit prefix of a given card number is often shared with many other cards, about 1/4 of credit card numbers in my random test, turned up pages that included other credit card numbers, and about 1 in 10 turned up a "treasure trove" of card numbers that were exposed through someone's sloppily written Web app. If the numbers were displayed along with people's names and phone numbers, sometimes I would call the users to tell them that I'd found their cards on the Internet, and many of them said that the cards were still active and that this was the first they'd heard that the numbers had been compromised."

Risk Management - measuring all components of the equation

OK, just like when you start talking about the Relativity Theory and mention E=mc^2, we always mention RISK = Impact x Probability when talking about Risk management. And it's interesting to see how the Probability is measured. A good thread on this subject is here.

People usually calculate the probability by looking at what can be done with an specific vulnerability. However, threats need to be considered too. How many people are out there with Motives, Means and Opportunites (MMO) to explore that vulnerability?

It's interesting to see that most companies are evaluating their enviroments to check how exposed they are to specific vulnerabilities, but they are not checking in a reliable way the threat levels related to their business. Perhaps banks are the kind of companies that are closer on doing that properly, but the others seem to be a little behind.

Two things make this matter interesting for me. One is that there aren't many choices in the market if you choose to hire someone to aid you about it. The second is that too few think that they need to worry about it. What people are using out there to calculate their exposure to certain kinds of threats? Are they doing that at all? It would nice to hear from those that are doing something about it.

HotBot papers

I've just read two papers from the HotBots conference from Usenix. One, from Grizzard, Sharma, Nunnery, Kang and Dagon, shows an overview about p2p botnets. It's interesting to see that the authors identified exactly the same issues that we tried to solve during on our Black Hat presentation, specially the hard coded information needed by the bot to start the communication with its herder.

Another very good paper is the one from Wang, Sparks and Zou, that present the design of an advances hybrid p2p botnet. They included in their design the use of digitally signed commands, exactly like we mentioned. They minimized the problem of the hard coded bootstrap information, but it wasn't solved. With our proposed OTP scheme the botnet design from them would be a really hard thing to put down. I think we will see more developements on this subject, specially merging the concepts from all these papers. It will be something very hard to fight against.

Power

While reading the well written "Intro to hackernomics" from Herbert Thompson on Network World, I noticed something quite interesting about threats motivation.

Thompson first law states that "most attackers aren't evil or insane; they just want something. ". Money is the natural choice for that something.

However, we can list several incidents that didn't generate any profit to the attacker. Is the first law of hackernomics wrong?

No. The mistake is thinking that the "something" wanted is always money. There is something that is pursued by Men even before the creation of currency: Power.

"Information is Power", said Robin Morgan. Nothing can be more precise than this concept today. The ubiquitous presence of information systems on today's world makes information like passwords and encryption keys huge power repositories. Can you imagine the power of those who have keys for military communication systems?

Sometimes (almost always) Power can be converted into money. Because of that some attacks motivations can be mistakenly interpreted as monetary. This possibility, however, can't be assumed as a rule. Several people are not directly interested in money, but eagerly pursue power. Terrorists and politicians are good examples.

Through this point of view we can understand why some apparently pointless things happen, like virus creation, denial of services attacks and website defacements. Script kiddies and teenage hackers are usually trying to show to their friends how powerful they are.

Acknowledging Power as a valid motivation for attackers makes several threats more feasible and understandable. It will allow better threat modelling and improve risk assessments. Different countermeasures can also be applied, focusing on reducing the power related to the target information instead of reducing the possibility of vulnerability exploitation.

Security Architecture Blueprint

Gunnar Peterson published a few days ago what he called "Security Architecture Blueprint". It is a blueprint of the Security Services needed to deploy a security architecture, from processes to technologies. Together with P-CSO from Mike Rothman I believe it's one of the best support materials to a CSO to use when developing a Security Plan. P-CSO will enable you to create a roadmap on a business perspective, while the blueprint from Peterson will cover all aspects on the technical side. I was happy to see that the plan that I developed a few months ago is quite aligned to it.

The Blueprint is designed in a somewhat layered approach, what really makes sense when you are trying to map high level risk management goals to processes, procedures and technology controls. The blueprint enables you to build an effective Information Security Management System without all that burden from ISO17799/27001, but in a way that you can use all the processes and tools developed to pass through a certification process on that standard, if needed.

The document is also very rich on information about security metrics, including a very good sample of an Enterprise Security Dashboard. I recommend Peterson's blueprint for all CSOs developing a security strategy and for consultants that are trying to build a comprehensive product and services portfolio.

SSL FTP on Longhorn

Fernando Cima posted on his blog about new features on Windows Longhorn, the client and server for FTP over SSL.

That's a very important feature for those fighting to improve the security of file transfers on their networks (specially those dealing with PCI-DSS). The fact of having this as native resources will make it easier to convince network and systems administrators to deploy it. Another very good improvement from MS.

Enabling business

Sometimes I catch myself defending "less secure" solutions for specific situations. It feels a little strange, but it usually happens when someone with "canned" knowledge about security tries do discuss the risks for some kind of technology, usually trying to use it as an excuse to avoid needing to work to make that thing happen. These situations would be fun if they wouldn't cause to others watching the discussion an impression that the security guy (me) doesn't know as much as the other guy about the issues he raised.

Today I saw this on the SecurityBuddha.com:

Stop Disabling and Start Enabling

If information security is to ever have an ounce of credibility in a corporate world it has to stop disabling and start enabling. The days of hiding behind thick piles of self-scribed doctrine and exercising personal dogma laced with stupid egotistical power trips based on technology religion must end. If you talk to most (yes most) folks outside of information security in an environment where this culture is allowed to exist they will usually raise an eyebrow, get their heckles up or even laugh in your face. The locker-room conversation discuss the “thought police” and ways to not tell or involve security about what’s really happening: and quite frankly I don’t blame them. Why?

Because sadly some so called security folks are nothing short of dinosaurs and I suspect exhibit many of the traits above. This article in CSOOnline prove it.

Kill instant messaging. Stop it at the desktop via security and group policies. Stop it at the gateway. Stop it at the firewall. Death to IM. My opinion: This is the best way to go if you can get away with it. If you’re running e-mail and a working phone system in a general office environment, IM is a geek-toy luxury. Simple as that.

Can you blame people? I often read things and laugh, sometimes I read them and get angry and occasionally I read things and don’t know what to say apart from “what “wibbly wobbly” planet do you live on?”

Maybe you would like to kill all cell phones as well? Lets face it they are really annoying. All those people talking and doing business while you try and read your newspaper with your drip coffee and Krispy Kreme.

Maybe that new fangled Internet thing should be shut off period? After all what’s wrong with paper and carrier pigeons?

I hope the author doesn’t work for a publicly traded company. If he does I am calling Kramer for a sell recommendation and I am serious.

As Dilbert once said ” I am not anti-business, I am anti-idiot”.

Yes, he is quite right about it! Another funny thing about blocking IM is that the request usually comes from managers that don't want their team spending time chatting. So they try to make Security block it, avoiding the direct conflict with the team. When I say that I'll do it only if the reasons are clearly stated to the users, they usually give up.

Mark Curphey raises a very important issue on the post above. When you start to be a problem and overreact on some threats people will start to avoid putting Security together in their projects, as they expect the same behavior (disabling). Try to show to the company that your role is not disabling things. Even when writing reports or providing feedback, try to replace the "can't be used" with a "can be used with security improvements". I know that sometimes even that is impossible, but don't discard it until you really sees that there is no other option.

Joanna and Mr. Chuvakin

Today I read a post in Anton Chuvakin's blog about a post from Joanna Rutkowska. He was caught by the "risk assessment pseudo-science", what also caught my eye on those posts. She reminds us that even if you could solve the "human factor", you still can be compromised by technical issues, like zero days.

Some might say that this is just FUD. I partially agree with that. However, I think it's extremely important to make people remember to avoid focusing on only one side of the triangle (Process, People, Technology). You should try to reduce risk from all of them. Ok, maybe you can't avoid zero days, but you must be prepared to deal with them. Reduces user privileges, network with firewalls and ACLs with a good "deny by default" approach and a good monitoring and detection process/infrastructure. Richard Bejtlich and Chuvakin are very good sources of information about that, even if each uses a different approach (Network monitoring / Logs). They are complementary.

If you still don't do that, start reading Anton Chuvakin's blog. He wasn't posting a lot for a long time, but he's back to the blogosphere with full throttle. The posts from my blogroll on the last weeks have come from him.