Which compliance pill to take?

Anton Chuvakin wrote a very good piece about PCI and how regulations like that are usually written and interpreted. He is completely right on defining the problem as:

1. Mandate the tools (e.g. "must use a firewall") - and risk "checklist mentality", resulting in BOTH insecurity and "false sense" of security.
2. Mandate the results (e.g. "must be secure") -  and risk people saying "eh, but I dunno how" - and then not acting at all, again leading to insecurity.

About those options, he says:

"Take your poison now?! Isn't compliance fun? What is the practical
solution to this? I personally would take the pill #1 over pill #2 (and
that is why I like PCI that much), but with some pause to think, for sure."

Actually, I believe it may be possible to reach an intermediate alternative. By defining the rules and standards for Risk assessment and management we could set the standards on defining acceptable risk levels instead of saying "must be secure", and without the need to go as deep as "must use a firewall". Of course that this approach would cause several questions about how to achieve compliance, but it would give more freedom to organizations about how to approach the risks and avoid "checklist mentality".

The problem with risk management based compliance is that the organization can manipulate its risk assessments and downplay stuff that should be identified as "high risks". If the risk equation, impact and probability levels are standardized, however, it would be easy to compare apples to apples and say things like "risks above level X must be mitigated until level Y".

Even by taking that approach we would still have to deal with the control efficiency problem. Like the firewall that Anton mentioned, there are several controls (probably most of them) that the way that they were implemented and how they are managed are even more important than the control itself. Maybe the best way to solve that is defining appropriate ways to deploy and maintain each proposed control. Ok, we could go into a very deep (and inefficient) level of details by doing that. Seems to be a catch 22 situation. Personally, I don't know who is worse to point where the bar should be placed: auditors or standard writers. I don't trust both :-)

It is so obvious that it hurts

Just found it:

People a big security threat to virtualization, Interop speaker says - Network World

People a big threat to virtualization?? Woo!!!

If you replace "virtualization" by any other hot technology you will see it will also be true.

Security is always designed and deployed in a way that it relies on people's decisions. Security is often a minor priority for people, so they'll make decisions based on other aspects, like time and budget constraints.

That is, you can expect people to make bad security decisions. If security controls are based on people's decisions...there's your "big security threat".

Wordpress security

I wrote in a rush about testing the blog "desktop clients" last week and I think I didn't make it clear about why I was doing all that testing and the results from them. OK, I'll try to summarize it.

My blogs are running on Wordpress on a regular hosting service. I have my own domain names, but I don't have and I don't want to spend money on digital certificates for them. So, if I want to access my websites over SSL I need to use a "generic" domain name from the service provider, like mydomain.sslpowered.com or something like that. The problem with that is the way that Wordpress handles the URLs you are using. If my website is on www.securitybalance.com I can try to access the admin part of wordpress by another URL, like securitybalance.sslpowered.com. So, how can I post to my blog over a protected connection?

I was reading a lot about some plugins for Wordpress, some mod_rewrite stuff, and other magic stuff. I wasn't feeling very confident about any of those. Then I learned about the XML-RPC interface for Wordpress. It is a webservice used by several platforms as an standard API for blogging. I noticed that the "blogging desktop clients", applications used for those that want to write their posts off-line to upload them later, usually access the blog using that API. What if I tried to call that webservice (wordpress_blog/xmlrpc.php) using my SSL URL? Well, it turns out that it works! I just had to find a good desktop blogging client that could satisfy some personal requirements (running from my portableapps thumb drive), and I end up with ScribeFire. It goes into Firefox as an add-in, what makes it even easier to use. I tried Zoundry first, but it is vulnerable to a man-in-the-middle attack, as it can't recognize a bogus certificate.

So, the tip for wordpress bloggers is: Use ScribeFire with a SSL protected URL for your XML-RPC API instead of posting through the regular wp-admin interface.

Good tip to fight laptop theft

Today I was in the office of a company where almost all the employees work on laptops. Everybody receive a security cable to secure the laptop on their desks to prevent theft. There is that old problem, "how to educate the users on using the security cable?". They found an interesting way to educate the users there. The IT support personal "steal" the laptops they find unprotected and leave a note on its place, something like that:

"Your laptop has not been stolen.

It has been removed from your desk to illustrate how easily it can go missing when not properly secured. [...]

Your laptop can new be picked up from [...]"

OK, I know it can cause some squeals from those I-don't-have-time-even-to-get-the-laptop-there people, but it's a nice way to make people see the risk. I like it.

And now, ScribeFire!

I've tried ScribeFire before and I was not impressed by the idea of blogging from Firefox. If had to use the browser, why not connect to wp-admin directly? Well, with my new quest for "Blogging clients" that can use my xmlrpc SSL-protected URL I end up by trying it again. Here I am, trying ScribeFire. It accepted well the https URL, so it seems to be a good option for "secure blogging" on Wordpress blogs.

You may wonder, if you saw my last post, why I didn't stay with Zoundry. Well, for two main reasons. One is that Zoundry seems to be a bit bloated, being too slow to run from a Portable Apps environment (anothet of my requirements). But the death blow on that tool came when I was checking if it was using the HTTPS xmlrpc properly by putting it behind a Paros Proxy. It used the HTTPS URL and it didn't mention the fact that the ssl certificate was not valid for that site! Yes, Zoundry Raven is vulnerable to a simple SSL man-in-the-middle attack.

So, until now, ScribeFire seems to be the choice.

Zoundry Raven test

I'm testing Zoundry Raven calling the XML-RPC interface of Wordpress on a SSL URL. It's maybe an alternative to secure posting, as I can use the "shared certificate" URL for this, what can't be done with the regular wp-admin Wordpress interface. I just need to check if this thing doesn't "escape" from the specified URL to do other stuff.

Security by economic obfuscation

This is how Chris Hoff is calling the fact that vulnerability researchers don't spend time looking for holes in commercial (and expensive) software products, like virtualization platforms.I think we are living with this for a long time. I can mention mainframe software (even without buying hardware researchers could run it on emulators like Hercules), ERP systems (SAP) and Application Servers, like Oracle and IBM, as software that is not receiving the proper attention from vulnerability researchers. I'm pretty sure that a lot of interesting vulnerabilities would arise with more research was focused at them, but their licenses prices are too aggressive to allow more people to install and test them.

Simple but dreadful, part 2 - Network shares

It would be impossible to write about low hanging fruits without mentioning network shares. I say it because they are usually my favorite path to elevate privileges when I'm performing a penetration test. Among stuff that I've already found on unprotected (I mean, Everyone - Full Control) shares are:- Source code for critical applications- Configuration files of applications containing database credentials (VERY COMMON)- Configuration files of applications containing Administrator level credentials for servers (service passwords!)- Debug logs containing a lot of sensitive information and even user credentials (SMS logs!)- Network and systems documentation (Lot's of Visio diagrams)- Personal private information (Human Resources stuff)Network shares appear and grow on the network like tribbles. The problem starts with weak policies regulating the subject, but it grows when the infrastructure needed as an alternative for non-authorized shares is not available. If you compare companies that have a good file server infrastructure with those that are trying to save some bucks by saving file server megabytes you will notice that the last has a higher occurance of non-authorized file shares. Non-authorized network shares fall in that "Shadow IT" category and are an easy bet for unprotected sensitive information. I can tell from experience that just by browsing network shares you can own an entire network. No need for leet exploits.If you are just starting as a security manager, include it as one of your first steps: map and control your network shares. You need to know where they are, what is inside and who can access them.

NAC and DLP

I was reading a comment from Shimel mentioning that NAC technology is becoming more mature every day, as we can see more 3rd party products integration. He mentions the integration of a IPS system, what promptly made me wonder about another kind of security product: DLP.Have anybody tried to integrate DLP and/or e-Discovery products with NAC? Can you imagine the possibilities? You can build a policy where workstations with protected/sensitive information stored have their connectivity restricted to reduce the chances of data loss. Your computer is free from protected information, you can browse the Internet with more freedom than that guy with sensitive files in his hard disk. I wonder if anyone from Symantec is trying to do that with Vontu and their Endpoint Protection suite.

Best Practices - Even Dilbert know what they mean

You can see it here.So what are the quick wins you can do on security to go beyond best practices? Feedback would be nice.