Security Bloggers Network

We started Untangle in 2005 believing that the way that security and compliance were being done in small business sucked. It was too expensive, too hard, and too inflexible. So we changed things:

• In 2007, we made free 95% of our code free and open-source;
• In 2008, we became a “pure” software vendor;
• In 2009, we embraced e-commerce and self-service, selling 85% of our software from our web site; and
• This year, we offered an ‘OEM package’ that allows our partners to instantiate their own version of Untangle.

But, most importantly, we have sponsored a huge and growing community. A community united around the concepts of freedom, enablement, and service to small business. In short, we all love the color green and drink lime kool-aid, especially if it’s free!

As a tribute to free-thinkers everywhere, here’s some inspiration from the master:

{ Comments on this entry are closed }

There have been some very interesting conversations circling the Web Application Security circles lately.  Many of these are currently dealing with how best to solve "the problem", with processes, procedures, risk models, tools and services but I am seeing an unfortunate trend in these conversations.  That trend is that many of these conversations are missing the forest for the proverbial trees, and mis-understanding even the nature of the problem of securing web applications.

{ Comments on this entry are closed }

We are happy to announce the availability of Data Encryption 101: A Pragmatic Approach to PCI Compliance.

It struck Rich and myself that data storage is a central topic for PCI compliance which has not gotten a lot of coverage. The security community spends a lot of time discussing the merits of end-to-end encryption, tokenization, and other topics, but meat and potatoes stuff like encryption for data storage is hardly ever mentioned. We feel there is enough ambiguity in the standard to warrant deeper inspection into what merchants are doing to meet the PCI DSS requirements. For those of you who followed along with the blog series, this is a compilation of that content, but it has been updated to reflect all the comments we received and additional research, and the entire report was professionally edited.

We especially want to thank our sponsor, Prime Factors, Inc., for stepping up and sponsoring this research! Without them, we couldn't produce free research like this. As with all our papers, the content was developed independently and completely out in the open using our Totally Transparent Research process. The white paper is licensed under Creative Commons Attribution-Noncommercial-No Derivative Works 3.0. And in keeping with our ideals on privacy, we don't require registration to download the paper so you don't need to think up some clever pseudonym, turn off JavaScript, or worry about tracking cookies.

Finally, we would like to thank Dan, Jay Jacobs, and Kevin Kenan; as well as those of you who emailed inquires and feedback; your participation helps us and the community.

- Adrian Lane (0) Comments

{ Comments on this entry are closed }

On a recent trip, a number of friends and I visited the local strip club in town. Sure it sounds really bad, but I promise, it was for research purposes only (alright, mostly). See, one thing that I realized while there was that those seedy, old-style joints teach a very valuable lesson -- how to sell and upsell, a lot.

Think about every product you've signed up for. Every social network and new Web 2.0 tool that's available had a way to sign up for free. Most of those sites didn't even have a way to pay them if you wanted to. Nope, they just wanted to build their user base. As soon as they decided they wanted to start charging, many times they're shocked to find out that people don't want to pay for their services. The problem isn't that people won't pay it's that they don't see enough of a value in paying for the product.

Step 1 - In the world of strippers, they start off up on the stage. They dance provocatively and slowly take each article of clothing off. This begins the hook. On the web, this is what people are thinking when they visit your home page. They might like what they see but that's about as far as it goes.

Step 2 - Next, the dancer may come closer to you and maybe even motions at you to come near her. This gets everyone a bit steamy. At this point, there is no way you're leaving until the dance is over. When it comes to your product, this is the point that you've invited them in. Maybe you offered them a free sign up or let them view a video some special content on your site.

Step 3 - This stage is critical. The wonderful performer knows her role and knows how this game is supposed to work. They'll get right up on your table, maybe even dance in your lap. Once she's made it to this point, she needs to know exactly what you need to be given in order to get you to the point of whipping out your wallet and paying for that private dance. In the world of your product, you need to show them how great you are and why they should pay for the last mile. Maybe they want more content (i.e. Hulu Plus), maybe they want ad-free content (like almost every iPhone demo app) or maybe they are in need of extra features or storage space (Google -> Google Premier). Whatever your customer is looking for, you need to know what it is and when they're willing to pull out their credit card (cash is still reserved for the strip club).

Once the girl has sealed the deal, it's all about getting repeat business. This is where the online world has a huge advantage. While the girl only gets the cash, you can ask for a credit card. A quick charge each pay cycle is way easier than going through the three steps above every time. At $9.95/month, you need to make sure your customer is happy and that they're still seeing value from your product and you should be golden.

{ Comments on this entry are closed }

:Event Information
The KC Infragard is hosting a two day cyber event pitting systems/security professionals against each other in a live cyber battle on a simulated commercial network. Systems administrators will be responsible for managing and protecting a "commercial" network from a live cyber attack, something they may not see on their own networks. Since the exercise is hosted on a private managed network that is not connected to the internet, production data and systems are not at any risk.

Not only will participants get a chance to test their knowledge and preparedness for securing an operational environment while under a live attack, they will also get the opportunity to see how other teams handled similar circumstances. This provides real world data and a solid understanding of best practices that can be implemented in their own organizations. At the end of the exercise participants will know the strengths and weaknesses of their people, processes, policies and technologies. This valuable exercise provides an outreach and education opportunity for our community to take home a greater understanding on how they should be protecting their own networks.

If you are interested in playing, there is still time to sign up, see more information at http://www.cyber-raid.com.


:Volunteer Positions
We have a few volunteer positions that we need help filling:
Registration - 2 People needed (2 hr shift the mornings of both Thursday and Friday)

• Responsible for checking in participants and handing out participant badge

Greeters - 3 People needed (2 hr shift the mornings of both Thursday and Friday

• Responsible for standing in conspicuous places in hotel, ensuring that guests can find their way to the event

Staffers - 4 People Needed (Full/Half day shifts)

• Responsible for event details, interacting with hotel, enforcing rules, answering general questions, etc

If you are interested in being a volunteer, please contact me via twitter, email (genesiswaveatgmaildotcom) or comment on the blog and I will get you on the list.

While we still have seats available, we have enough players to ensure a fun, engaging, and successful event. However if you have coworkers, friends or other contacts that you think would enjoy this event, please help spread the word.

:Security BSidesKC
The CyberRAID event will be held in concert with the B-Sides Security Conference. The B-Sides has finalized their speaker selection, If you have not already visited the BSidesKC page, I encourage you to do so.

:Follow us on Twitter
As the event approaches, the most current up-to-date information can be found on the CyberRAID Twitter feed. (@CyberRAIDKC)

{ Comments on this entry are closed }

Alert blog reader Marco F. sent us this one: Gmail account phishing. The email has all the clean look of Google’s communication style.

(click on graphic to enlarge)

Anyone foolish enough to bite on this and click on the attachment will see the following web page. If you check the attachment source code you can see that it sucks genuine Gmail page elements.

(click graphic to enlarge)

Genuine that is, except for this:


(click graphic to enlarge)

The information entered on the bogus page is snatched by a site registered to someone in Sremska Kamenica, Serbia.

A Google search shows that it’s a lovely little town on the Danube.

Thanks Marco.

Tom Kelchner

{ Comments on this entry are closed }

ihack ? iam has posted a highly amusing and detailed analysis of Web Laundry (In)Security

Ok, now we just need to guess the write 7 password. The password is 24 bits… That gives us 16,777,216 attempts to brute force it. At 4 attempts per card that will take 4,194,304 cards or 2,097,152 cards on average… There must be an easier way… My next idea was to sniff the traffic between the reader and card to get an idea of what kind of data is being passed back and forth, then after wading through the paper above, implement the algorithm to crack the cipher itself. Then I found this little diddy in the datasheet

[...]

Surely you would think the engineer(s) implementing this weren’t negligent enough to leave the default password… you would be wrong.

This is very much along the same lines as my presentation at The Next HOPE on Keypad Entry Systems. Start with the most basic tests and you will be surprised how quickly things fail, even things sold as “Unmatched Security and Cutting Edge Technology”.

{ Comments on this entry are closed }

I was at the CFET conference in Canterbury last week, then took a weekend off – quite a novelty… That's the city of Canterbury in the UK, by the way, not the region in New Zealand. (By the way, the papers I presented there will be available shortly.)

Coming back to the office after a few days without connectivity and trying to catch up with email and all that, I was initially confused to find an article in the New York Times by Randall Stross on "A Strong Password Isn’t the Strongest Security" which referred to a paper by Cormac Herley (and incidentally made some perfectly fair points about the shortcomings of passwording. Hadn't I seen this article before, and even blogged on it? Well, no. The article I'd seen before was in the Boston Globe and I blogged on it here.

As I've said before, I'm not fond of complex, hard-to-remember passwords that have to be changed at short intervals, forcing users into all sorts of potentially insecure evasion strategies. But the problem with both these articles (and Herley's original paper, which is actually well worth reading for its insight into the ergonomic shortcomings of many password systems) is that they don't really offer proven alternatives. They exist, of course, but static passwords are comparatively cheap to implement, which is why they've managed to survive so long.

Since never changing your password isn't generally a realistic option, and some sites actually prevent you from using good passwords and, even better, passphrases, we've produced a number of articles and papers on the topic to help make it easier to follow good practice, even when your provider seems set on preventing it. Here they are as a list, to make it easier to follow.

• http://blog.eset.com/2010/04/16/good-password-practice-not-the-golden-globe-award
• http://blog.eset.com/2010/04/16/please-do-not-change-your-password-the-boston-globe
• http://www.securingourecity.org/resources/pdf/choosing_your_password.pdf
• http://www.eset.com/blog/2009/08/23/user-education-education-education
• http://avien.net/blog/?p=484
• http://www.eset.com/resources/white-papers/EsetWP-KeepingSecrets20090814.pdf
• http://smallbluegreenblog.wordpress.com/2010/04/16/re-floating-the-titanic-social-engineering-paper/

David Harley CITP FBCS CISSP
ESET Senior Research fellow

{ Comments on this entry are closed }

In the first part of our blog series on Understanding and Selecting an Enterprise Firewall, we talked mostly about the use cases and new requirements (Introduction, Application Awareness Part 1 and Part 2) driving towards a fundamental re-architecting of the perimeter gateway.

Now we need to dig into the technical goodies that enable this enhanced functionality and that's what the next two posts are about. We aren't going to rehash the history of the firewall, that's what Wikipedia is for. Suffice it to say, the firewall world started with application proxies, which gave way to stateful inspection, which was supplemented with deep packet inspection. Now every vendor has a different way of talking about their ability to look into packet streams moving through the gateway, but fundamentally it's not all that different.

Our main contention is that application awareness (building policies and rules based on how users interact with applications) isn't something that fits well into the existing firewall architecture. Why? Basically, the current technology (stateful + deep packet inspection) still focused on ports and protocols. Yes, there are some things (like bolting an IPS onto the firewall) that can provide some rudimentary application support, but ultimately we believe the existing architecture of the firewall is on it's last legs.

Packet Processing Evolves

So what is the difference between what we see now and what we need? Basically it's about the number of steps to enforce an application-oriented rule. Current technology can identify the application, but then needs to map it to the existing hierarchy of ports/protocols. Although all of this happens behind the scenes, doing all of this mapping in real time at gigabit speeds is very resource intensive. Clearly it's possible to throw hardware at the problem, and at lower speeds that's fine. But that's not a long term answer.

The long term answer is a brain transplant for the firewall, and we are seeing numerous companies adopting a new architecture based not on ports/protocols, but on specific applications and identities. Thus once the application is identified, rules can be applied directly to the application or to the user/group for that application. State is now managed for the specific application (or user/group). No mapping, no performance hit.

Again, at lower speeds it'll be hard to decipher which architecture a specific vendor is using, but turn on a bunch of application rules and crank up the bandwidth and old architectures will come grinding to a stop. And the only way to figure it out for your specific traffic is to actually test it, but that's getting a bit ahead of ourselves here. We'll talk about that at the end of the series when we discuss the procurement process.

Application Profiles

For a long time, security research was the purview of the anti-virus vendors, vulnerability management folks, and the IDS/IPS guys. They had to worry about these "signatures," which were basically profiles of something bad. The devices enforce policies by looking for bad stuff. Right, your typical negative security model.

This new kind of firewall architecture allows rules to be set up to look only for the good applications and to block everything else. Yes, a positive security model makes a lot more sense strategically. We cannot continue looking for bad stuff because there is an infinite amount of that, yet a more manageable number of good things that are specifically authorized. We should mention this does overlap a bit with typical IPS behavior (in terms of blocking stuff that isn't good), and clearly there will be increasing rationalization of these functions on the perimeter gateway.

In order to make this architecture work, the application profiles (how you recognize application one vs. application two) must be right. If you thought bad IPS rules created havoc in your environment (false positives, blocked traffic, general chaos), wait until you implement a screwy application profile. Thus, as we've mentioned numerous times in Network Security Operations Quant series on Managing Firewalls, the criticality of testing these profiles and rules multiple times before deploying.

It also means firewall vendors need to make a significant and ongoing investment in application research since many of these applications are intentionally going to make it hard to identify. With a variety of port hopping and obfuscation techniques being used even by the good guys (to enhance performance mostly), digging deeply into a vendor's application research capabilities will be a big part of selecting these devices.

We'd also expect open interfaces from the vendors to allow enterprise customers to build their own application profiles. As much as we'd like to think all of our applications are all web-friendly and stuff, not so much. So in order to truly support all applications, customers will need to be able to build (and test) their own profiles.

Identity Integration

Take everything we just said about applications and apply it to Identity. Just as we need to be able to identify applications and apply certain rules to those application behaviors, we need to apply those rules to specific users and groups as well. That means integrating with the dominant identity stores (Active Directory, LDAP, RADIUS, etc.) becomes very important.

Do you really need real time identity sync? Probably not. Obviously if your organization has lots of moves/adds/changes and those activities need to impact real time access control, then the sync window should be minutes, not hours. But for most organizations, a couple of hours should suffice. Just keep in mind, syncing with the firewall is likely not the bottleneck in your identity management process. Most organizations have a significant lag (a day, if not multiple days) between when a personnel changes happens and when it filters through to the directories (and other application access control technologies).

Management Evolution

As we described in the Application Awareness posts, thinking in terms of applications and users (and not ports and protocols) can add significantly to the complexity of setting up and maintaining the rule base. Thus enterprise firewalls leveraging this new architecture need to bring forward enhanced management capabilities. It doesn't help to have cool application awareness capabilities if you can't configure it. That means built-in policy checking/testing capabilities, better audit and reporting, and preferably a means to check which rules are useful based on real traffic, not a simulation.

A cottage industry has emerged to provide enterprise firewall management, mostly in auditing and providing a workflow for configuration changes. But lets be clear, if the firewall vendors didn't suck at management, there wouldn't be a need for these tools. Thus a key aspect of looking at these updated firewalls is to make sure the management capabilities will make things easier for you -- not harder.

In the next post, we'll talk about some more nuances of this new architecture, like scaling, hardware vs. software considerations, and embedding firewall capabilities into other devices.

- Mike Rothman (0) Comments

{ Comments on this entry are closed }