Security Balance

This blog has been quite silent lately as I haven’t been finding anything interesting to write about. Even the Verizon report, there’s certainly interesting stuff there, but so many people have talked about it that I don’t even feel compelled to do it.

Anyway, there’s at least one thing to mention. I’ve just changed to a new role on my job. This week I’ve started as a “Security Architect”. I believe it will be a very interesting job, as I was getting a little tired of having to deal with project implementation details. I really like to work on roadmaps and long term planning for security services, and that’s exactly what I’ll be doing now. I hope my day job now can bring me new ideas about things to write here. Let’s see

I was trying to find words to add to this post from Anton Chuvakin about the current state of log analysis, caused by the numbers in the last Verizon report. I simply can’t find anything to add. He’s dead right about everything. If you are interested in log analysis / log management, that’s something to read and think (AND DO SOMETHING) about.

I was reading about the new framework from SourceFire, Razorback, and I realized it has a lot of similarities with TCG’s  IF-MAP. There is a lot of vendors mentioning things go beyond the simple correlation so common in the SIEM tools. It is a drive from CORRELATION to COOPERATION between security tools. That’s awesome. Instead of having several tools waiting to receive data from different places, we need a security metadata bus that can be used by other tools. In that way a lot of things that make security hard to do will become far more easy. Firewall rules won’t be “10.2.3.0/24 to 172.16.32.99 using TCP4567″ anymore, but “users from Finance going to the Finance App”. We can build blocking and response rules using definitions such as “users infected with malware”, “servers containing sensitive information”, and far more interesting stuff. What’s most important is to have those things following standards, in a way that the infrastructure will become less important, making it easier to apply security independently if things are running in your data center or in the cloud.

But, again, only if initiatives like Razorback start working with standards like IF-MAP…

Here I am going to Las Vegas for Black Hat and DefCON again! It’s funny that this time I have really lower expectations for the event. My feeling from the last news in the field is that it’s too much the 0-day of the week and buzzword contest (APT/Cloud). Anyway, it’s always the place to be when talking about information security, and I hope to be wrong about it. It will also be a great opportunity to meet friends and colleagues. If you are there, please feel free to drop a tweet (@apbarros), I’ll be tweeting live there.

And let’s see that B-Sides stuff. Honestly, from what I’ve seen from the last editions and the current schedule, it may become the A-Side quite soon.

As everybody in the field had predicted, malware targetting SCADA system has finally come true. The lucky thing is this one is looking for information to steal only, not actually doing anything. I wonder what outcome could we have if this nasty little thing was designed to force systems to fail.

SCADA systems are one of the most critical blind spots in organizations Today. Few people have access to then and know how they work, so there is a false perception of security about them. Specialized systems, such as SCADA and ATMs, often rely on obscurity as their main security strategy. It’s not even something done intentionally, but as result of a neverending vicious cycle. Internal security resources don’t know about security on those systems and the specialists in that technology don’t understand security. You can think about hiring external consultants to check the systems, but the consultants also don’t have much contact with that technology. Of course they won’t tell you that, they will run their off-the-shelf tools anyway. The results will tell you nothing, what you will interpret as “secure”, perpetuating the notion that there are no security issues with that technology. As there are no security concerns there, the security team won’t spend time learning that technology and the specialists will keep saying that this security thing is for those Internet-web-2.0-cloud-stuff guys. Until the next Black Hat briefings or sexy malware.

I wonder when this is going to hit the old mainframe. I must say it will be fun to watch.

I was reading Schneier’s blog Today as he posted an old text he published on Dark Reading back in 2006, about Cryptography usage. It’s interesting how an article of four years ago is still very relevant. I’ve been seeing some cases where people considers encryption as the most appropriate control to implement, when access control is really the key.

“Much of the Internet’s infrastructure happens automatically, without human intervention. This means that any encryption keys need to reside in software on the network, making them vulnerable to attack. In many cases, the databases are queried so often that they are simply left in plaintext, because doing otherwise would cause significant performance degradation. Real security in these contexts comes from traditional computer security techniques, not from cryptography.”

Those cases show how frequently controls are implemented in a checklist-based approach, without any attempt to do a threat based assessment first. As Einstein said once, “things should be made as simple as possible, but not any simpler”. Although I am among those that think that PCI DSS is a step in the right direction, there are clear misconceptions that come from the heavy push towards encryption in that standard. Applying the wrong control for a threat is as bad as an inefficient or non-existent control, or even worse, due to the false sense of security, added complexity and cost. I’m sure that checklists can help us with the most basic stuff, but when we start touching things such as database encryption, I don’t believe we can apply a checklist-based approach.

I left this awesome post from this SANS blog pass without saying anything here. It has 10 tips for IT auditors, and in my opinion it nailed down the key issues that I generally have with auditors. Some of the best pieces:

Interesting piece from The Register regarding the new tool published by Google that shows how many requests they receive from governments to access and/or remove private data from their systems. According to the tool, the Brazilian government is one of the top requestors.

But there is an issue with the article from The Register that I immediately noticed and that is even confirmed in the by Google. What happens is that Orkut, the first social network attempt from Google, is extremely popular in Brazil, much more than Facebook. So, the numbers from the Brazilian authorities would more likely be comparable to numbers related to Google AND Facebook requests in other countries. I bet the difference is not that big or doesn’t exist at all if the numbers are compared in that way. The confirmation as from their FAQ:

“For Brazil and India, government requests for content removal are high relative to other countries in part because of the popularity of our social networking website, orkut. The majority of the Brazilian and Indian requests for removal of content from orkut relate to alleged impersonation or defamation.”

An interesting discussion has been produced by the blog post from HD Moore related to the value of learning assembly for penetration testing. It was intensively discussed on the cisspbr forum, but mostly because of other reasons.

As HD said, almost all additional knowledge is useful. I agree with that, but I think we should differentiate between “valuable” and “required”. I know people that performed very good penetration tests without executing a single exploit. For those, assembly skills were not necessary at all. But to properly answer that question it is also important to define the real goal of a pentest.

First, it is important to differentiate between Risk and vulnerability assessments, Pentests and vulnerability research. The assessments are usually performed with a “white box” perspective, with total collaboration of members of the organization to identify vulnerabilities (and risks). If the organization wants a more complete study of its own security issues, that’s the way to go. At the other extreme it is the vulnerability research. On that kind of job you look for vulnerabilities that are still not known (or not publicly disclosed) by the security community. It can be done either in white box or in black box approaches. Usually the organizations that benefit from vulnerability research are those that create technology products (hardware and software), not those that buy them.

Pentests, in my opinion, are a mix of these two. As it tries to reproduce the situation of real attacks, it normally uses a black box approach. The organization being tested cannot expect a complete assessment of its vulnerabilities, as some of those will be masked by controls from different layers.  The pentest will be useful to validate the security approach of the organization and that the combination of controls works to prevent compromises. It may use some vulnerability research on custom applications, but usually it won’t benefit from researching vulnerabilities in COTS products such as Operating Systems and routers.

Probably one of the reasons why the role of each of those activities is so often misunderstood is because pentests are marketed differently by the service providers. Executives always have the impression that someone trying to hack into their networks is the best way to find issues to be fixed. The vendors use that perception to sell their services, and this misunderstanding goes on forever. A good way to break this cycle would be to standardize the pentesting delivery.

When you buy a physical safe, for example, you can refer to the UL certification classes. A TL-15 class safe will “resist abuse for 15 minutes from tools such as hand tools, picking tools, mechanical or electric tools, grinding points, carbide drills and devices that apply pressure”. What if you could hire a pentest and get a similar classification for your test scope (you external perimeter, for example)?  The time scale would not be the only component, adding to it the attack techniques applied during the test. Those techniques can be lined up in terms of complexity, cost and pre-requisites, and in the end you could get the results that your network was able to “resist to attacks up to techniques class X”. Vendors could sell their pentests with different prices and according to their competence level (“we offer pentests up to class Y techniques), so the services (and the results) could be properly compared. It would even give more space to those that want to add vulnerability research to their pentests, as this would probably be one of the highest test levels to be tried against a network.

.