A recent post tying segmented web browsing to DMZs by Daniel Miessler got me thinking more about the network segmentation that is lacking in most organizations. The concept behind that article is to establish a browser network in a DMZ, wherein nothing is trusted. When a user wants to browse the web, the article implies that the user fires up a connection into the browser network for some kind of proxy out onto the big, bad Internet. The transport for this connection is left to the user’s imagination, but it’s easy to envision something along the lines of
We’ve all heard the stories: employee gets upset, says something about their boss online, boss sees it, and BAM, fired. As information continues to stick around, people find it increasingly beneficial to think before launching a raging tweet. Here lies the opportunity: what if I can pay someone to gather that information and potentially get rid of it? Enter ReputationDefender. Their business consists of three key ideas: Search: Through search ReputationDefender will find and present information about you so it’s easy to understand.
Destroy: Remove (for a per-incident fee) information that you don’t care to have strewn
As you are already well aware (if not, see the announcement – we’ll wait), Google is now offering a free DNS resolver service. Before we get into the players, though, let’s first understand the reasons to use one of these free services. You’re obviously reading this blog post, and to get here your computer or upstream DNS cache resolved securosis.com to 209.240.81.67 – as long as that works, what’s the big deal? Why change anything? Most of you are probably reading this on a computer that dynamically obtains its IP address from the network you’re plugged into.
Let’s try this again. Obviously I didn’t do a very good job of defining what ‘clientless’ means, creating some confusion. In part, this is because there’s a lot of documentation that confuses ‘thin client’ with ‘clientless’. Cisco actually has a good set of definitions, but in case you don’t want to click through I’ll just reiterate them (with a little added detail): Clientless: All traffic goes through a standard browser SSL session – essentially, a simple proxy for web browsing. A remote client needs only an SSL-enabled web browser to access http – or https web servers
Good job! You paid tens of thousands of dollars for that shiny new name-brand VPN, and then decided to deploy its web VPN functionality because, well, it was just easier than deploying software clients. An underpinning of common web security that dates back to Netscape Navigator 2.0 is the “same origin” policy for JavaScript. Your clientless SSL VPN intentionally breaks this, and that’s considered a feature. What does this mean for you? If your implementation allows dynamic URL rewriting (i.e., end users can put in any URL and have the web VPN fetch it) it’s GAME OVER, since
A few weeks ago a new TLS and SSLv3 renegotiation vulnerability was disclosed, and there’s been a fair bit of confusion around it. When the first reports of the bug hit the wire, my initial impression was that the exploit was too complex to be practical, but as more information comes to light I’m starting to think it’s worth paying attention to. Since every web browser and most other kinds of encrypted Internet connections – such as between mail servers – use TLS or SSLv3 to protect traffic, the potential scope for this is massive. The problem is that
At lunch last week, location-based privacy came up. I actively opt in to a monitoring service, which gets me a discount on insurance for a vehicle I own. My counterpart stated that they would never agree to anything of the sort because of the inherent breach of personal privacy and security. I responded that the privacy statement explicitly reads that the device does not contain GPS, nor does the company track the vehicle’s location. But even if the privacy statement said the opposite – should I care? Is location directly tied to some aspect of my life that might negatively
It seems as though lately a lot of heated conversations revolve around X.509. Whether it’s implementations using IPsec or SSL/TLS certificates, someone always ends up frustrated. Why? Because it really does suck when you think about it. There are many facets one could rant on and on about, when the topic is X.509: the PKI that could have been but isn’t and never will be. It’s a losing argument and if I’ve already got your blood pressure on the rise (I’m lookin’ at you, registrars!) you know why it sucks but there’s zero
This story begins early last week with a phone call from a bank I hold accounts with. I didn’t actually answer the call but a polite voice mail informed me of possible fraudulent activity and stated I should call them back as soon as possible. First and foremost I thought this part of my story was a social engineering exercise, but I quickly validated the phone number as being legit, unless of course this was some fantastic setup that was either man-in-the-middling the bank’s site (which would allow them to publish the number as valid) or the number
Today you’d be hard pressed to find a decent sized network that doesn’t have some implementation of Security Event Management (SEM). It’s just a fact of modern regulation that a centralized system to collect all that logolicious information makes sense (and may be mandatory). Part of the problem with architecting and managing these systems is that one runs into the issue of securely collecting the information and subsequently verifying its authenticity. Almost every network-aware product you might buy today has a logging capability, generally based on syslog – RFC3164. Unfortunately, as defined, syslog doesn’t provide much security.
