I have nothing to add to the great work that @irldexter and @wadeis have done here.

Read Drazen’s post now.

There’s been a lot of talk in the media recently about different ways in which companies can deal with the Global Financial Crisis (GFC). Redundancies, capping recruitment, capping pay, or perhaps promoting the four-day week. This last option has been getting quite a lot of press here in Australia and the rest of the world. So does this work with info sec staff? I think it depends on the role and the current number of people filling that role.

Lets start with analysts/engineers/first-line-responders, the guys in the trenches who turn the gears and make sure our security technology is working and monitored. Depending on the business environment this is perhaps one of those roles that can’t easily be sliced down to 4 days. The conflict here is if your business requires 24/7 monitoring, or at least 24/7 on-call, either way you can’t easily make people redundant (how will you cover all your hours?) or ask people to work 4 days (to cover your time you will require more staff – which negates the 4 day working day). The risks here are if your monitoring area misses incidents or make mistakes managing your security infrastructure because of time constraints.

What if you employ security auditors or security testers? These types of roles, similar to security architects & designers, will often see their workload ebb and flow depending on the number of projects. If the current GFC hasn’t impacted upon your project portfolio then your testers would probably still be required full-time, but whether or not they’re required for a full 5 days would entirely depend on how many projects there are, and the degree of detail that is required for each project. The issue here is that with your testers only working 4 days, then either the time dedicated to testing or the time they can focus on keeping abreast of testing techniques, may be impacted. This is of course taking into account that you employ these resources, as opposed to using consultants. These types of roles could probably pull back to four days without too much detriment, and knowing the types of people who perform these roles it’s not like they would simply fill their 5th day with veging out, they’d still be monitoring their feed readers and working on tools or other security related projects. The risk with your testers either not keeping on top of trends in the industry, or not focusing enough time on testing your systems is that vulnerabilities may make their way into production.

Employees involved with security architecture and design fall into the same area as your security testers. Depending on the project load, these roles could potentially work only 4 days, but would have to monitor their time spent on enhancing their knowledge and not falling behind the game. Similar with the testers, the risk of not having enough time for your designers is that perhaps systems are designed to a lesser degree of quality, or perhaps they will take longer to complete.

Your information risk specialists or analysts, perhaps not technical resources but sitting within a consulting or shared-service type of area, will potentially have a difficult time pulling back to four days. Core responsibilities here are advising the business of business and technical risks in the context of business-as-usual activities or changes and projects. Whilst the potentially dwindling number of projects may indicate that these roles can easily go to four days, with business trying to do the same amount of work as before, but with less time, they may have a tendency to look at riskier solutions. If this is the case, now is possibly the time for your risk specialists to refocus their efforts to ensure that risks are being considered and reviewed appropriately. The risk here of course is that activities get performed without the appropriate rigour being applied and “slip past the keeper” into production.

If your environment is fortunate to have dedicated security policy roles it would be fairly safe to say that the impact to the organisation wouldn’t be too great if they were asked to work 4 days. This is taking into consideration that the primary responsibilities include the maintenance and reviewing of policies and standard documentation. Depending on the size of your policy/standard set, the risk in reducing time in this area may lead to some of your documentation falling behind.

Security managers fall into a 50/50 bucket, depending entirely on the amount of people management they are currently doing, and how much time they work looking at the strategy of the security organisation (or if they leave that to the architects?). If your security managers’ core responsibilities include just these two activities, then perhaps shifting to a four day week wouldn’t be too difficult. I’ve seen in a number of situations consultants acting as security managers at multiple locations. One of the key risks I see here is the impact of security management decisions not happening as fast as they should. Of course there are ways to deal with this situation.

Are any of you security professionals currently working four days? I would like to hear your feedback!

I recently had reason to examine some potentially malicious code at work and the safest way to perform this was to run the software within a VM. The problem was, how do you correctly configure a VM to limit how much network access it has, and thanks to LonnieOlsen’s blog on the topic it didn’t turn out to be too difficult. My requirements were fairly simple:

• The guest Windows XP machine must be able to resolve DNS names
• The guest Windows XP machine must NOT be able to access the local network (except for accessing the local DNS server)
• The guest Windows XP machine must be able to access the Internet using HTTP or HTTPS
• The guest Windows XP machine must be able to SSH to the host Ubuntu machine (to copy files if required)

As mentioned by Lonnie, the best way to do this is to configure the VM to use “Host Only” networking, then utilise the masquerading and other firewalling options of iptables on the Host Ubuntu system. This allows the Ubuntu system to limit, at the network layer, what the VM can access. My setup has the Ubuntu machine connecting to the network via wireless networking, the guest configured for “Host Only”, which uses the virtual interface vmnet1, and visually looks like this:

First up is configuring iptables. I’ve created a file called firewall and placed it in my /etc/init.d/ folder. The file has the following in it:

#!/bin/bash -e

The script is a bash script, not much to explain here.

echo 1 > /proc/sys/net/ipv4/ip_forward

Enable IP forwarding in the linux kernel – otherwise the IP traffic wouldn’t be routed through the Host Ubuntu system.

iptables -t nat -F POSTROUTING
iptables -F FORWARD

Flush the tables before we set them up.

iptables -t nat -A POSTROUTING -s 172.16.72.0/24 -o wlan0 -j MASQUERADE

Enable routing out the wireless interface where the traffic comes from the “Host Only” virtual nat interface’s subnet.

Next we start the firewalling:

iptables -A FORWARD -i vmnet1 -p UDP –dport 53 -j ACCEPT

1. Allow DNS from the virtual nat interface. (requirement #1)

iptables -A FORWARD -i vmnet1 -d 192.168.0.0/24 -j DROP

2. Disallow traffic to enter the wireless network. (requirement #2)

iptables -A FORWARD -i vmnet1 -p TCP –dport 80 -j ACCEPT

3. Allow HTTP traffic out. (requirement #3)

iptables -A FORWARD -i vmnet1 -p TCP –dport 443 -j ACCEPT

4. Allow HTTPS traffic out. (requirement #3)

itpables -A FORWARD -i vmnet1 -j DROP

5. Drop everything else.

And that’s it (download the file from here). Don’t forget to add a symlink to this file in your boot up scripts, because the Linux iptables rules do not return to their previous state after you reboot:

$ sudo ln -sf /etc/init.d/firewall /etc/rc2.d/S89firewall

This puts the bash script into your default runlevel (2) and runs it after all the interfaces should be up.

Due to the way in which the forwarding works, the above rules will not prevent the Windows XP VM from SSHing to the Host Ubuntu box (requirement #4). But before we start up the VM, we have to configure the DHCP daemon settings for that “Host Only” virtual nat interface, vmnet1. The file we want to modify is /etc/vmware/vmnet1/dhcpd/dhcpd.conf, which I believe by default is read only, so the first thing I had to do was make it writeable with a:

$ sudo chmod o+w /etc/vmware/vmnet1/dhcpd/dhcpd.conf

The only changes I made to this file were the addition or modification of the following lines in the subnet 172.16.72.0 netmask 255.255.255.0 block:

option domain-name-servers 192.168.0.254
option routers 172.16.72.1

This explicitly sets the DNS settings to the ADSL Router/DNS Server – as my Host Ubuntu server does not provide DNS resolution, and the second option sets up the gateway setting so the Windows XP VM will route traffic towards the Host Ubuntu server.

Next we adjust the Windows XP VM so it’s using “Host Only” networking and boot it up and voila. Your Windows XP VM should boot up and acquire its network settings from the vmnet1 DHCP daemon settings, it should be able to resolve internet hostnames and should be able to access Internet sites over HTTP and HTTPS but that’s it. If it tries to connect to any of the PCs on your wireless network it shouldn’t be able to.

(In the nature of always wanting to find better ways to do things, if anyone has any suggestions for how this could be done better, because I’m sure it could be, please leave me a comment!)

A few weeks ago, whilst trawling some interesting logs, I came across a bunch of HTTP traffic coming from f###-###.opera-mini.net. Performing a few more queries uncovered a bunch more traffic coming from other derivatives of this source. Until that point I hadn’t heard of Opera Mini, but according to their website, it’s “The world’s most popular mobile Web browser with over 20 million users”. So what is Opera Mini?

Opera Mini is a compact web browser released by Opera Software that is designed for mobile devices, in particular, mobile phones. One of the primary features of the browser is its incredible speed. Opera boast more than 30% speed improvements for users in the US. But how exactly is a web browser able to boast such an incredible speed enhancement? Flux capacitor? FTL drive? No. Opera Mini is able to improve the speed of accessing websites by pulling them to their servers first, that then compress the content, before sending the content onto your phone (see press release). This provides a few benefits:

1. Your browsing is faster over your traditionally slow mobile phone Internet connection
2. Your browsing is potentially cheaper, because instead of having to download a page that is 200KB in size, perhaps it’s only 100KB

Another “feature” of Opera Mini, in the never-ending quest to provide an awesome browsing experience on a mobile phone, is that their servers will keep track of your cookies set by websites. This is so that if you visit a site that uses cookies, the Opera Mini server will submit it again for you (see Privacy under the faq).

So does using this browser introduce any security or privacy risks to the user? I believe the simple answer is “yes”. Trying to expand on this to understand the potential impacts and likelihoods of these impacts is a little more complicated, and whilst I was going to take a FAIR approach to this, I don’t know enough of the internal controls to do it justice.

First of all what am I worried about, what assets are at risk? We all understand that your cookies, either in their short active lifetime or perhaps even beyond, hold some value to us users and generally we don’t want to share them with other people – so for this exercise I’m going to focus on cookies as the primary asset. Why is this? Primarily because cookies are often used as the mechanism to help provide state on an otherwise stateless protocol (thanks a lot HTTP). What this means is that, when you’re visiting facebook.com or yourbank.com, when you keep on hitting new pages the only way those web servers know who you are is because your requests often include a “session” identifier. Some web apps put that in the URL, but most will track your state through your cookies. I’m not going to put an actual dollar figure on what it would cost a user if those cookies are disclosed to a malicious, unauthorised third party, but let’s say it’s somewhere between all the personal information you store in your facebook profile and perhaps 10% of the money you have in your bank account. (this of course is entirely subjective – you may only ever use your Opera Mini browser to visit youtube.com?)

There are a handful of scenarios that may occur in which your cookies may be disclosed. Someone could compromise one of the multiple Opera Mini servers and milk them of their juicy, cookie information. Perhaps there’s a fault with the software running on those servers and Opera Mini users accidentally start seeing cookies from other users. Or perhaps an administrator of one of those servers has a bad day and decides to have a peek in their systems. To my knowledge (which I’m going to admit isn’t all that deep) none of these have occurred.

So what are Opera doing to prevent these sorts of issues? Well publicly they talk about encryption, and lots of it. According to the faq the current version of the software will always encrypt data sent between their servers and your browser. This is actually a step above normal browsing, which would only encrypt traffic if the website is configured to use SSL/TLS (HTTPS). Of course, they also put in their faq:
Can Opera Software see my passwords and credit card numbers in clear text? What is the encryption good for then?
The encryption is introduced to protect the communication from any third party between the client (the browser on your handset) and the Opera Mini transcoder server. If you do not trust Opera Software, make sure you do not use our application to enter any kind of sensitive information.
The last statement certainly got me worried. They aren’t making any assurances on ensuring that your data is protected, even whilst being processed or stored on their infrastructure.

So what can you do? Well, I believe there is a balance between the benefits and potential negative impacting risks of this kind of service. Sure, if you’re only using Opera Mini to search Google and look up the weather then perhaps the browser is fine and doesn’t pose any risk to you. If on the other hand you want to ensure that no third party has access to cookies which are used to maintain your state with yourbank.com then maybe you use a different browser for those situations. The decision is mostly personal. For example, regardless of how much I enjoy browsing with Chrome, I still find myself only ever performing online banking with Firefox+NoScript, and often clearing out all settings after I’m done.