The news that up to 7 million Dropbox usernames and passwords may have been compromised is a good opportunity for businesses to review their use of multi-factor authentication for the online services that they rely on.
At this stage the Dropbox leak appears to be a result of re-use of passwords on multiple sites, not a direct hack of Dropbox itself. It is unfortunately quite common for individuals to sign up to different online services using the same email address and password.
The Threat Prevention feature of Palo Alto Networks firewalls protects your network in several ways. One of these is an Intrusion Prevention System (IPS) that enables you to block known vulnerabilities at the network gateway.
This approach to intrusion prevention helps to protect your network by detecting and blocking known attack signatures for security vulnerabilities. A recent example of an exploitable security vulnerability is Shellshock, the name given to a vulnerability in Bash that allows remote code execution.
As software vendors work to release security patches (in some cases several patches as the first ones did not fully address the security flaws) Palo Alto Networks is able to rapidly release an IPS signature update to block the attack.
A new security vulnerability called Shellshock has been discovered. Security experts are already calling it one of the most serious vulnerabilities of all time, even more serious than Heartbleed.
The Shellshock vulnerability is present in Bash, a remote shell commonly used to remotely administer Linux-based systems. This includes many Linux distributions that are used for internet-facing web servers, as well as Mac OSX systems and other “internet of things” devices such as web-enabled video cameras and home automation systems.
The Shellshock vulnerability allows remote code to be injected into environment variables in a Bash session, which is then executed by the target machine.
One thing I’ve realised from working with Palo Alto Networks firewalls is how much network traffic runs over HTTPS/SSL these days.
Having your web traffic secured with SSL encryption is great for when you’re using your banking website, but it also means that malicious traffic can be masked from your network’s security devices and pass straight through.
Quite the double edged sword.
Palo Alto Networks firewalls include App-ID technology, which allows you to identify network traffic no matter which protocol or port it is operating on. With App-ID you have an extremely detailed view of what is going on with your network traffic.
Here are some great examples of how SSL decryption of web traffic at the network gateway can help.
Setting up SSL correctly is not as simple as it looks. The basics: install the certificate and check it works. But out of the box, it might not work in all browsers, and your server might not be as secure as you think.
Qualys SSL Labs is a great (free) tool to check that your SSL certificate is installed and your server configured correctly. As well as checking the basics, it checks intermediate chaining issues, browser compatibility, and whether you are using any insecure ciphers on your server. For example, did you know that you should turn SSL off, and only use TLS?
It’s worth checking your web server encryption is encrypting properly, and not just providing the illusion of security.
Let’s dive into building systems that build themselves.
Sound complicated? It’s not. And making the switch can unlock some huge efficiency and flexibility improvements in your environment.
Too much secret sauce
Traditionally you build a system by gathering the recommended specifications from your software vendor or dev team, perform some sizing and then install your servers. You would go through all the common steps of configuring the operating system, getting the right version of java or .NET installed and setting up your application servers. At this point you bring in your application specialist and they finish installing the app, usually iterating through a number of changes to get the system tuned just right. This tuning often extends right through TEST and UAT.
Since the introduction of Windows 2000, IT departments have used group policies to control and configure workstations.
A corporate workstation build will typically contain the operating system, service packs and hotfixes and core applications common to all user groups – Microsoft Office, Adobe Reader, and the like. Whilst some configuration of the base build is common, the majority of the configuration is performed via group policy. Not only do group policies provide the flexibility to change configuration of a workstation after it has been deployed, filtering and loopback policies allow different configurations to be applied to different user groups or workstations. Reconfiguration of workstations can be achieved simply by changing a policy, adding the user to a different group or changing the OU the workstation computer account is in. Windows Server 2008 introduced group policy preferences, which further extended the configurational scope of group policies. Group policy preferences allow for registry values to be written, shortcuts created, network drives mapped and connections to network printers established.
Yesterday there was an article in the Australian about Suncorp allowing staff to BYO their own computers and tablets. This isn’t an anomaly – it’s part of a growing trend within corporate IT. There is more focus on end user experience and less on rigid control.
Enterprise IT is being consumerised. Executives are buying iPads and
insisting that they be able to use them on the corporate network.
Marketing people require access to Twitter and Facebook. Training is
being delivered via web-based flash video. Web-based software is being
used for critical line of business applications. If a user can’t access
YouTube on the corporate network, they will fire it up on their iPhone
over 3G.
The Microsoft Deployment Toolkit (MDT) is an excellent – and free – tool for automated desktop and server builds. We use it all the time.
Sometimes, for whatever reason, installing a PXE server or using a boot CD ISO isn’t desirable. Using a boot USB flash drive is the best bet in these situations. The problem: the guide to create a bootable USB drive in the MDT documentation doesn’t work. There is plenty of confusing information out there on the web for painful, slow ways to create a boot USB. And most of those don’t work either.
So what’s the easiest way?
This is the easiest, most pain-free way we’ve found for what is usually a cumbersome task.