PCI QSA

Just a quick note to say I've just heard that I'm now PCI QSA certified. Nice :-)(the test is really easy, actually...open book :-O)

Black Hat, Defcon, the basics

So we are finally approaching the BH/Defcon weeks, when all the new stuff is presented to the security world and the sky starts to fall once more. I'm not going to Vegas this year (I'd love to), but as I came back to work on vulnerability assessments and penetration testing I noticed the main issue is still linked to the basics.There are so many low hanging fruits that someone that is completely unaware of vulnerabilities and attack techniques from the past 5 years will still be able to do a lot of bad stuff on a 'vanilla' corporate network.Ask yourself these 5 questions. If you can't say yes to all of them, don't sign the check for that new-miracle-black-box you are buying and do your homework to fix the basics:

• Can you promptly identify someone guessing passwords for administrative accounts on all your servers?


• Can you say for sure that there are no weak passwords for all administrative accounts on all your servers?


• Can you say for sure that you don't have a user/password on a test box that also exists on a production server?


• Can you say for sure that there are no shared folders on your servers with sensitive information and weak permissions settings?


• Do you know who knows the password for (and use) the root or Administrator account?

Maybe after that you can start thinking about some cool stuff from Black Hat :-)

PVLANs and DMZs

The PVLAN concept allows you to design a VLAN where the peers can communicate only with one (or more) specific peer, instead of full "n to n' connectivity.Now, why I'm not seeing people using that to deploy more secure DMZs (or simply zones)? I mean, if you'll place a web server, a SMTP server and a DNS server on your DMZ, why should they be able to talk to each other (assuming they don't have an specific need to do that)? If you do that, even with you web server compromised you still have the access restrictions from your firewall in place to protect the others, avoiding the old problem of stepping stones.Is there anybody out there that is doing that?

"Hanging on the wall" posting of the week

I really promised to myself that I would avoid "look at this post from X" posts here. But today is Friday and I've just read something that was so perfectly written and fun that I will break that promise:Read this, from Gunnar Peterson!

CISSP value

Congrats for Andrew Hay on getting his CISSP. He does a great job when describing the value of this certification:"Due to the scope of the exam I forced myself to learn aspects of security that I had neither the reason, nor the desire, to understand. I feel that I have grown as a security professional because of my studies and hope that I can help others with the things that I have learned."That's exactly what I think about it. It won't ensure that the certified person knows everything, but he(she) should have passed through a lot of different security subjects while studying for it. Personally it was an eye opener, I understood that Security is far wider than what I originally thought when I had to study to take the test.

VMWare vulnerability

Today I read about this VMWare vulnerability on Beaker's blog. It is related to the possibility of a non-admin user on the host OS to execute code on the guest OS. I read the details of the vulnerability and I understand why VMWare is saying that the described behavior is by design, and can also see why this could be a security issue. However, issues like this just confirm my point of view that it's not feasible to try to protect the Guest OS from the Host. It's a matter of layers, the guest OS is just a simple application on the host OS. We will see that the challenges on doing that are quite similar to those from the AV industry.IMHO, there are just a way to (partially) address those concerns. A single purpose Host OS, that will run only Guest OSes and no other software. Then a Guest OS under that can run the VM environment management tools, communicating with the other Guest Oses through regular (although virtualized) networking. A regular client server application with all the proper AAA and encryption controls can be used over that network (why not IPSEC communication?). Even exclusive virtual network adapters can be used on the Guest OSes to host the traffic of the management application. The client would be installed like a regular application on the Guest OSes (like VMWare Tools) and be subject to all the OS controls.That won't help against malicious code running on the Host OS, but will reduce the possibility of that code being executed there, just by reducing the roles of the Host.

Master dissertation test

I'm trying to finish my Master dissertation on the next months. In order to do that I need to test the log analysis methodology I'm proposing. The methodology is targeted to detect insider attacks, so I need to collect logs from internal resources, which include AD domain controllers, internal e-mail systems, file and folder access audit logs, firewalls and other network devices, http servers, applications, and everything else that can produce logs and indicate internal users behavior. I would need to collect one week of logs for the tunning phase and after that one week of logs that will include some "simulated attacks". If there is anybody out there that can help me by providing those logs (everything will be anonymized, of course), please drop me an e-mail at augusto (at) securitybalance.com.Thanks!

Kaminsky and the new vulnerability patching world

A few years ago, it would be impossible to imagine something like what Dan Kaminsky has done with the recently uncovered DNS cache poisoning vulnerability. Although the technical details of the issue are still not public (and are probably "wicked cool", 3117, etc), the mosr impressive fact of the whole story is that there was an joint effort from several companies (competitors included) and organizations to release the patch in a organized way. It is the best sample of responsible disclosure I've ever seen so far. I think this is a vey good example of how mature our field is comparing to old times.Congratulations (one more time) to Kaminsky. And to the participants of the joint effort too.  

Virtualization security, some thoughts about it

I was reading the post from Hoff where he writes about virtualization and the DMZ, based on a white paper from VMware. I've been reading Hoff's posts (and others with whom he discusses the subject) about virtualization and I thought it would be interesting to also right a little about it.There is a lot of research results being published regarding VM security. Some of those try to demonstrate security issues, like malicious hypervisors, systems trying to escape its VM and trying to reach other VMs or even the hypervisor, some are proposing ways to avoid and detect those threats, and so on. I firmly believe that we can reach a very high level of security to protect the hypervisor and its role from threats coming from the VMs. That's because of the difference of "security layers". There are lots of cases of success of code running in a higher privilege layer controlling code running under it, like VMS, Java VM and others. People are working with VM technology on the mainframes for years and it they were (the problem with the mainframe world is it lacks its own ShmooCon, DefCon, BlackHat, etc) able to reach a decent level of security on that.There are some features that are being virtualized that will demand us a little more care to ensure a good security level, like the network devices roles. I also believe that it's not that far either. We were able to produce fairly decent code to run on switches and routers, if we bring the same code to the VM world (would Cisco be bold enough to offer something like "VMIOS", to run several instances of its boxes on a single big box?) we can do that there too.The big issue that I think it will remain is the VM and Hypervisor environment security, I mean, the environment where that highest level VM software is running. Based on my understanding (and I think it's almost common sense), whoever controls the hypervisor rules the VM world. The VM servers are being assembled like a common server, but the VM software should be quite more protected than a common application. Can you imagine running your "Virtual DMZ" over a Windows 2000 server, knowing all the other software that is also running on that and can't be disabled or uninstalled? The attack surface of the server running the VMs needs to be VERY small. On mainframes the top layer (where the LPARs are running over) can usually be accessed only from a local console. No network access, terminal. Nothing. I know that on the distributed computing world this can't be a huge headache to manage, but we don't need to go that far. I believe that the Server Core option for Windows 2008 is a good example of where to place a VM environment over, or something like a YALD (Yet Another Linux Distribution) specially prepared from scratch to be a VM server. The kernel, the VM software and nothing else. Maybe SSH for (console) remote management, but that's all. Can anyone find a reason to have Gnome or KDE running on a VM Server? I can't.Maybe I'm being a little naive when analyzing the VM problem this way. But I'm looking at the "VM" experiences from the past and I can't see challenges that go beyond that. If you start thinking about very different communication between VMs besides common vanilla networking (like sharing memory areas), maybe it's time to think why you are trying to do that instead of placing the apps from those VMs under the same OS. And for securing basic vanilla networking on VMs, we are almost getting there.