This week, our office came across an article by Roger A. Grimes entitled “Why you don’t need a firewall”. As a security professional working for a company whose responsibilities include firewall management, I found the article to be extremely shortsighted, and borderline offensive. Normally, I’d encourage you to read the article in question, but your time is most certainly better spent doing nearly anything else. I would highly recommend learning home dentistry as a suitable alternative activity.

Grimes argues that firewalls are becoming increasingly less relevant, due to their inability to protect against attacks, the difficulty associated with managing the devices, and the availability of more effective defenses and solutions. The sheer number of logical fallacies spawning hasty generalizations in the article leads me to believe that it is intentionally written to provoke this type of discussion. With this in mind, I would like to address several of the author’s arguments from the perspective of a security engineer.

Network boundaries are amongst the most sensitive areas of any network. Although attacks can be targeted towards any area of a network, the majority of intruders will utilize a WAN connection as their primary attack vector. Such a connection provides much more viability and availability than a localized connection, such as a wireless network. Any traffic utilizing this connection should encounter a firewall. This firewall should be configured to only allow traffic that is absolutely necessary. Any unnecessary or unrecognized traffic should be immediately dropped at the border.

A firewall is by no means a cure-all. Effective security is built on a series of well-placed, layered defenses. Such an approach forces a would-be attacker to penetrate multiple barriers and systems in order to reach his target. A given system could be vulnerable to any number of attacks. However, a system globally accessible from the Internet with minimal defenses is a significantly more attractive (and likely) target than a well-protected one. An attacker forced to defeat a border firewall, evade an intrusion detection and prevention system, bypass access control lists (since these can serve as a pseudo-firewall as well), and successfully circumvent both an application layer and host-based firewall in order to exploit a specific vulnerability (which they would have to discover using similar methods) all while not drawing any attention to the attack in progress represents a much less likely scenario. As a security professional, what approach would you prefer to protect your critical services and information?

Part of my security experience stems from the National Collegiate Cyber Defense Competition (CCDC), where I was a member of the Rochester Institute of Technology team for several years. This competition is intended to simulate the experience of managing and defending a corporate network from a talented team of motivated attackers and penetration testers (the red team) while still allowing the business to function effectively. Essentially, the competition represents the day-to-day operations of an information security and information technology department condensed into a three day window. Year after year, some of the most successful teams were those whose strategy involved a solid perimeter defense. By restricting incoming (and to a lesser extent, outgoing) traffic to only services that were required, the vulnerabilities available for exploit by the red team significantly decreased. Teams with weak perimeter defenses frequently went out with a blaze of red team glory, unable to reassemble the broken bits of their infrastructure into any semblance of a functional network.

It may be true that the computing paradigm is moving away from the traditional fat client approach of full desktops and laptops to one where mobile devices such as tablets, smartphones, and other embedded devices rule our lives. Although these devices may have a smaller attack surface, they can and will be subject to the same level of malicious activity as any client machine in use today. Eventually, we will see many more targeted attacks exploiting vulnerabilities in our mobile phones and tablets. Even though these devices are currently considered to be more secure than a desktop running a full blown Windows installation, we cannot hide these devices under a veil of supposed security. Vulnerabilities exist in these devices, and they will be exploited. You don’t believe me? Windows 2000 was advertised as being secure when it was released as well.

The author’s comments concerning the solution to MS12-020 are incredibly shortsighted. Yes, applying the Microsoft hotfix is the ultimate solution to the underlying vulnerability that was addressed in the security bulletin. However, his approach requires that patches be deployed immediately once they become available. Even the most vigilant organization experiences a lag period between the release of a patch and its deployment to vulnerable systems. In some cases, patching cycles can be months behind the original release dates. Fortunately, security patches have never been known to cause system failures or malfunctions. Additionally, security patches never need to be tested to ensure compatibility with the systems and software deployed on an organization’s network. Furthermore, any problems that might be caused by the installation of a security patch (I know these don’t happen, but bear with me for a moment here) are easily remedied by simply uninstalling the patch, with little to no administrative oversight or troubleshooting required. Contrast this to an emergency firewall block, which omits the brain-dead simple software side of things with the painstakingly difficult modification of a few configuration lines. Consider the incredible challenge of troubleshooting any associated problems of this firewall block, since firewalls do not provide any mechanism for selectively enabling or disabling rules for isolating problems. You might even have to manually weed through log files (since there aren’t any tools for managing these sorts of things) that will tell you exactly what the problem is. The point stands as written, firewalls are unnecessary.

Like any computing device, a firewall is incredibly good at doing exactly what it is told to do. Some administrators have a tendency to configure their firewalls to work as routers, moving traffic between networks with little to no interference. If you need routing functionality, there’s a device for that – it’s called a router! If you are putting ANY-ANY rules in your firewall policies, you are doing it wrong. Yes, connectivity issues can be more challenging to troubleshoot when a firewall is involved, and it is tempting to completely eliminate the firewall as a source of interference when struggling to meet a deadline. However, applications can be made to work through a firewall. In the end, you might even end up understanding more about the application’s operation and communication than the original developers know themselves.

I sincerely hope that my colleagues are misinterpreting the intent of this article. Perhaps Grimes is writing as a present-day Jonathan Swift, drafting a modern Modest Proposal. If that is the case, he has certainly accomplished his goal.

If not, God help us all.

In one of the more short-sighted, narrow-minded, and just downright inane articles that I’ve read in quite sometime Roger Grimes told us all about “Why you don’t need a firewall.“

His premise is that exploits and attacks are developing at a level as to surpass the capabilities of a conventional firewall and that firewalls aren’t used properly so why bother. We’ve all heard that before and I won’t even get into the muddled waters of the next-generation firewall concept, though I could. The worse part about the idea of the firewall being dead is the rationale he gives for the death of the firewall.

First he talks about how remote buffer overflows have decreased since 2003 and how Microsoft has improved the code to the point where protections on the host have rendered the firewall useless. Clearly I’m behind the times, apparently the success of the firewall is now measured by how many buffer overflows are stopped. Now the rest of the garbage that is stopped by the firewall is irrelevant? Good to know.

Next he goes on to talk about the management of the firewall:

I’m almost unsure of how to respond to that. As someone whose job it was to manage firewalls for over 30 different organizations, I’m offended. A competent firewall administrator is doing all of those things. Firewall logs are an extremely valuable resource for both analysis and troubleshooting purposes. Just because Roger (or any of the people he worked with) aren’t doing these things does not mean that others aren’t. He also talks about poorly written firewall policies being another reason why firewalls are ineffective. I would agree with him, a loose firewall policy is inviting attack vectors that you could easily close up by doing it right but just because someone was less than thoughtful or lazy does NOT mean that the technology itself is inherently flawed. Using that logic you can blame the gun and not the gunman for the crime.

Lastly, Mr. Grimes blames the fact that most applications now run over ports 80 and 443 for the ineffectiveness of the firewall. Okay, I guess I will get into the next-gen firewall concept. Most firewalls today can inspect and profile both 80 and 443 traffic and determine what is malicious and what is not. Is it always fool-proof? No, but the next-gen firewall will provide some of the protections that he claims are lacking in firewall technology.

I think my biggest issue isn’t that he’s trying to make an argument for getting rid of the firewall – it’s that as a security professional he’s forgetting one of the basic tenets of security: Defense-in-Depth. Let’s just agree with him for one minute and say that the firewall isn’t doing as good a job as it was 10 years ago, does that mean that we should take that layer of protection out of the equation? By no means am I saying that the firewall is the be-all/end-all of your company’s security posture but remove it completely because it isn’t being administered properly? I think I’ll go home and take the locks off my doors because someone could kick it down if they really wanted to. I almost blame InfoWorld for this since they published this piece and either didn’t read it or worse, didn’t find anything wrong with it.

I spend most of my day typing arcane things into black windows with green text, as such I spend some time looking for ways to eliminate keystrokes. I’ve been using bash and vim for more that 10 years and I continue to learn more features that I can use on a daily basis. I’ll give you some tips at the end, but the moral of the story is learn how to make better use of your tools.

How to Get Better

1) Anytime you’re typing the same thing more than once, ask yourself if there’s a better way to do it. If you don’t know, stop what you’re doing and ask Google. Maybe you should be using awk or sed to do some search and replace job. Maybe you can just do it in vim. If you’re in vim already, do you know how to work on more than one file at a time?

2) Anytime you want to do something you’ve done before (ok, that’s the same as typing it again, right?) think about how to do it faster. You can use ^R to search your bash history, you could write a shell routine, you could write a script, that script could be parametrized.

3) When you want to do something involving multiple files, use find. Really, read the man page for find. It’ll chmod, chown, rm and more all the files you can find with it.

4) Keybindings! Start learning how to do fancy things with single keystrokes. If you’re holding down the arrow keys (or Delete/Backspace), or pounding them repeatedly, there’s probably a better way to get where you’re going. Start of the line, end of the line, delete a word, delete through the end of the line. There are keystrokes for all of these and more in both your shell and editor.

5) Know how to navigate and customize your environment. This is all personal preference, but I keep certain tasks on certain spaces (virtual desktops), user shells in one tabbed window, root shells in another. All of my shells now run screen. And my latest bit of learning was tabs for vim to edit multiple files, this lets me stay organized and move between tasks quickly. You’ll need to figure something out for yourself, but always think about how your environment could be better or faster. Most of these settings will happen in dot files, so you’ll probably want to have an easy way to deploy them to new machines. I use a skel.tgz that I keep on one of my servers, using GitHub or Bitbucket might be another good idea.

Ok now here’s some tips and tools I frequently use:

bash
1) Keybindings:
* ^R – search your history
* ^A – start of the line
* ^E – end of the line
* ^K – delete through the end of the line
* esc-D – delete through the end of a word
* esc-backspace – delete back to the start of a word

2) .bashrc collected from who knows where, some of this may be standard in your distro:
"""
export VISUAL=vim
# Screen needs this
alias vi=vim

"""

3) .dircolors (this looks good on a black screen, mostly it subs cyan for the usual dark blue)

"""
# Configuration file for dircolors, a utility to help you set the
# LS_COLORS environment variable used by GNU ls with the --color option.

# audio formats
.ogg 01;35
.mp3 01;35
.wav 01;35
"""

What’s in my ~bin?
1) django_bash_completion – from extras/django_bash_completion in the django distribution

2) user@host:~/bin$ cat pep8_check.sh
# I don't like the line length errors
find ./ -name \*py | xargs pep8 --show-source -r --ignore=E501

3) Other scripts of little use to anyone else

vim
1) Installed plugins:
* Supertab – http://www.vim.org/scripts/script.php?script_id=1643
* desert color theme (looks good on a black terminal)

2) .virmrc I particularly like the mappings for dealing with tabs, as that is the newest addition:

"""
"The default leader is '\', but many people prefer ',' as it's in a
standard location
let mapleader = ','

"""

Amazon Studios
- Create a television series
- Amazon will fund and produce

IT Security Basics
- Matt isn’t buying it
- People have been saying this for years
- Matt and Tom debate

Apple Legacy FileVault Hole
- OSX 10.7.3 shipped with a debug flag
- Passwords stored in plaintext in secure.log
- Fixed in 10.7.4

Google vs Oracle
- Google made their own Java clone for Android
- Jury ruled Google infringed on copyrights
- Google calls for mistrial

Linux Torvalds Wins Millennium Technology Award
- Good for him!

Hack of the Week
Flashback (again)

App of the Week
New Studio
Google Drive
Spotify for iPad

Recently (well, last night) I had the opportunity to take the Certificate of Cloud Security Knowledge exam and just wanted to put out some of my thoughts while they were fresh in my head. I always like to take a random sampling of certifications. It’s fun to challenge myself (some are more challenging than others) and it gives me a good idea of what sorts of training and certificates I’d like my guys to have (if any). I’ve never been the biggest fan of some of the bigger ones out there, but we’ll save that for another post.

The bulk of the CCSK covers the Cloud Security Alliance’s guidance document and the rest can be found on their exam FAQ. They break down “cloud security knowledge” into 13 so-called domains and two areas – one focused on a ENISA report and one based on applied knowledge. Don’t let the ENISA stuff steer you off though as the principles are perfectly applicable here in the US (where I am based anyway). The domains are general enough so they include some very good guidelines, but they’re not too in-depth in any one area, which is okay, they’re not supposed to be. It really is just a guided tour of things you need to know before going “cloud.” The price is a little steep ($295 US) but is reasonable when compared to a few others and includes two attempts (in case you fail). The test is web-based so of course you could cheat but then what would your conscience think of you?

Overall I actually liked the exam. It asked some good questions that will steer folks who are just getting into “cloud stuff” in the right direction. They do have a couple of courses that go more in-depth into the various domains and probably provides a lot more detail than their guidance report does. I didn’t take the class because, well, I just didn’t and probably won’t since I’ve been doing cloud stuff for a while and was already familiar with the ENISA report. I loved the noticeable lack of any vendor “spin” or marketing and the focus on actual implementation issues. If I were training someone to build out more cloud security or just deploying a cloud project I would recommend the training and certification. Just my $.02, but I almost never have anything good to say about certifications or infosec training programs. So I wanted to put some positive things out there while I had one.

A few months ago, we released a tool called check_splunk_license to the world (under the GPL at the time, but as of 4/19/2012, alternatively available under the MIT license). Since then, the check was adopted by Luke Harris for use in the Splunk for Nagios app for Splunk. We promised way back when that we’d add additional checking for the expiration of licenses, and now I’m here to tell you we’ve made good on that promise. But there’s more to the update than just expiration monitoring…

The reason we originally released check_splunk_license, you may recall, was in direct response to a problem we were having – we kept violating our license, and not getting a notification about it. Well, the additional check in this update came from a similar problem. A customer of ours was experiencing an issue where random events (roughly 28 days old, if I’m not mistaken) were being deleted from their index. Upon investigation, we discovered that their ‘main’ index (the default index for things in Splunk) had reached and exceeded the configured max size (the default, 500000MB or ~500GB — that’s a lot of logs!) And so, we created an additional monitoring check to alert when an index is approaching its max size.

All three of the checks have been integrated into a single check_splunk.py file, which you can use to execute the checks. In addition, three wrapper scripts have been included, one for each of the individual checks we provided (check_splunk_license, check_splunk_index, and check_splunk_license_expiration). However, we’ve added an important dependency — we now require that pynagios be installed. This python module makes writing Nagios/Icinga plugins a walk in the park, including performance data! We’re slowly moving all of our checks to using this module, and encourage everyone to use it in anything they write.

If you’re interested in checking out the latest version of the checks, head over to BitBucket, where the repository is hosted. If you have feedback, please let us know at blog@hurricanelabs.com.

I’m not sure how many of your listen to our podcast, but in Episode 023, we talked a little about open source licensing. Ian had gone on a mini-rant during the soundcheck about how there are too many different open source licenses, and they basically all say the same thing. So why complicate open source by having so many? I thought about this a lot over the next few days and did a lot of reading into open source licenses of my own. The results are interesting, to say the least.

To start, there are a couple really good resources for reading about open source licenses. The first is on the GNU website. It lists licenses for software, documentation, and even fonts. It also goes on to sort the licenses into GPL-compatible, GPL-Incompatible, and Non-Free Licenses. The thing to keep in mind while reading this website is that it tends to be a little biased. GNU, and the Free Software Foundation who supports them, very strongly believe in something called “copyleft”. According to Wikipedia, a “copyleft” is “a general method for making a program (or other work) free (libre), and requiring all modified and extended versions of the program to be free as well”. This is a philosophical decision above all else. In fact, Richard Stallman (the founder of the FSF) writes that copyleft is a form of “pragmatic idealism”, and that’s the reason GNU’s own license, the GPL, is written the way it is (see his whole article on the GNU website).

Anyways, the other site I found useful for comparing open source licenses is the Open Source Initiative. The OSI is a non-profit organization tasked with maintaining the “official” definition of Open Source, and they are recognized throughout the community for approving licenses as compliant with this definition. The OSI follows a much less idealistic philosophy, having roots in the business community. One of their original goals was to avoid the idealism inherent in the “Free Software” movement. Therefore, their site provides little philosophical commentary on the licenses. What they do provide is an arena to communicate with open source developers regarding the various licenses.

As part of my reading, I began to develop a sort of distaste for copyleft. Not only is it forcing your open source ideals on other people, but I’ve seen throughout my experience many problems created by the strong copyleft that some licenses (GPL v2) creates. Copyleft doesn’t only force your ideals on your own software — this in and of itself is not a problem, after all, its YOUR software. However, when the license you apply to your code prevents me from using someone else’s code with your code because they didn’t agree with your ideals, you’re forcing your ideals on that other software, and on whatever software I’m writing, too. It saddens me every time I think of this to know that the open source community, which in my opinion creates superior software 9 out of 10 times, feels it has to resort to something like this.

Until now, anytime Hurricane Labs has released software to the open source community, it has exclusively been under the GPL. However, after some careful consideration, we’ve decided to make a change. From this point forward, any software we release will be licensed under the license commonly referred to as the “MIT License” or the “Expat License” (you can view the license at the OSI website). In addition, we are retroactively applying this license to anything we’ve released in the past as a dual-license model. If you’ve already chosen to license our existing software under the GPL, you are free to continue doing so. However, you may choose in the future to license it under the terms of the MIT license instead.

The MIT license has many advantages, in our opinion, over the GPL. First and foremost, the MIT license is significantly shorter and simpler. The laymen’s summary of the MIT license (and please don’t take this as legal advice) is “use the software as you see fit, but if you redistribute it you must maintain this copyright license. Also, there is no warranty of any kind”. In addition, the MIT license does not enforce any sort of copyleft on the code. This means that if you have a commercial use for it, you can use our code in your closed source project, and the only condition is you must maintain the notice that the code is copyrighted by Hurricane Labs. There is no requirement that you maintain a method of obtaining the source code, no requirement that you open source your changes, etc. This should make using any code we’ve developed as simple as possible.

Licensing is a complex topic, be it Open Source licensing, commercial software licensing, or any other kind of licensing. There is a lot of legal jargon to it, and the big, long, “EULA”-esque licenses are difficult to understand. Open source licensing also brings with it a heated debate, as with almost any topic in open source it seems, with both sides of the argument feeling that their opinion is right. But not only that, but that the other side’s argument is as wrong as wrong can be. We chose a license based on what best fit all of the goals we were trying to achieve by releasing our code, and we feel the MIT license does this for us. It is not really a statement of philosophical beliefs. Instead, think of it as the result of applying the old “is this good for the company” to our open source licensing. I encourage you to look at licensing in terms of what achieves your goals, and not what people try to convince you are your goals. If the GPL, or any other license, fits your code the best, then by all means, that’s what you should be using. And don’t be afraid to change someday either. We weren’t.

Before you read any further in this post please take five minutes to read this article:
Why I Am Leaving Goldman Sachs

As an IT security consultant/MSSP/whatever you want to call third-party security provider, the second I started reading that article I immediately began drawing comparisons to the current landscape of IT security companies. Too many times I’m brought into a company to discuss a need that they have that relates to security and I’m confronted with “Well Company X told us to purchase this technology and that would solve our issue”. A good majority of the time that technology is overpriced, bloated, and the times that it is actually the right fit it is so over-scoped that the client is paying for way more than they need to be.

When did it go out of fashion to do the right thing for the client? I understand that a sales rep is paid and evaluated based on how much they sell, it’s the nature of the business. It is the job of the sales rep to grow the business, but at the cost of what the client actually needs? As security professionals, we often have a unique perspective that most IT people do not. They don’t understand the intricacies of security, it’s not necessarily their job. That’s why they have us and they should be able to trust us (and when I say “us” I mean that as security professionals as a whole).

There are many security companies out there that can sell a hundred different security products and if one doesn’t stick they have ninety-nine more that are guaranteed to solve your problem. Keep in mind, your problem doesn’t mean anything to the sales rep sitting across from you. Most likely they have no idea what the root of your problem actually is, they are just listening for five or six buzzwords that equate to a product on their line card. They don’t know what security best practices actually are, nor are they keeping up with trends and equating them to your business and how you can be affected. In the rare case that they actually are knowledgeable, are they going to tell you A) That some well built firewall rules, the existing technology that you have in place, and some patches will mitigate an issue or B) That need to buy the latest and greatest web-app malware-fighting endpoint-protecting thing on the market?

Do I sound a little cynical? Yes, I recognize that. Am I actually being cynical? I don’t think so. Far too often security companies misuse the trust placed in them for their own financial gain. I know this isn’t new and I’m not surprising anyone, but it gets a little tiring going into company after company and hearing how they’ve been raked over the coals by another security vendor. It’s unnecessary.

If you’re a client and reading this – I hope you keep us at Hurricane Labs, and any other security vendor you deal with, accountable to the standards I’ve talked about. If you’re one of the security vendors I’ve mentioned above, I hope you feel sufficiently ashamed of yourself (though I know you won’t be).

If there is one tenant that rings especially true with me from Greg Smith’s article it is this: Do what is right for the client and both companies will benefit in the long run.

20 Questions for an Intrusion Analyst
- All security professionals should answer them
- “Describe your analytics biases”

Military finds IT security certification difficulties
- Certifications do not necessarily mean skill
- “A giant circle of ineptitude”

Code Not Physical Property
- Some sort of loop hole?
- Upcoming blog post on this

Foxconn
- Walkthrough of factory
- Consumer disconnect between conditions in factory and final product
- Much like food processing

Tips for Better Joomla CMS Security
- Keep it up to date, strong passwords, etc.
- They missed some steps
- Keep admin interface away from the public
- Add Two-factor Authentication

Facebook Buys Instagram
- $1 Billion
- Facebook moving into the mobile space?

Hack of the Week
Flashback (again)
Apple developing Flashback remover
“Security Whack-a-Mole”

App of the Week
Instagram is dead, long live Instagram? This is actually a great knock against these closed service, if they were open source someone could just fork this version and carry on.

Zero Day attacks – you know, the ones that almost EVERY signature in your IPS claim to protect you against? Yep those guys, nasty little things. Basically, if IPS vendors are to be believed, those are the things that don’t have a patch yet and have active exploits against them. You update your IPS signatures and BOOM protection from zero day! The problem we always run into, and this is with almost every IPS vendor so I’m not just picking on Check Point here, is how do you know when an update is available? As much as most vendors would like it we are simply not logged into their console all day long so their automated “hey you have an update” thingy is not useful. This was a big problem for us because we manage a lot of firewalls so what to do, what to do. We turned to a combination of something old (RSS) something a little new (Splunk), and something really> old (email alerts.) Here was the issue and how we solved it:

ISSUE
Updates come out, an email goes to only one person (subscribing everyone is impractical), updates are scheduled as needed. The process is slow, too “people heavy”, and has a lot of built-in delay. This is no good when dealing with zero days.

SOLUTION
I took Check Point’s RSS feed that announces their IPS updates and fed it into Splunk. This allowed me to index the feed and break it apart a little so I could build a dashboard around it (dashboards in Splunk are basically a collection of searches and reports.) By itself this would allow us to search across IPS updates and figure out which ones we needed, but I wanted to dig a little deeper and make the process a bit less painful. This is where Check Point helped me out a bit (and possibly other vendors do this too but I don’t know for sure), they actually have a severity tag in their RSS feed so I know how important a given new protection is (Critical, High, Medium, Low) and I could organize my dashboard accordingly.

This dashboard gives me a neat layout of my IPS protections and how important they are. This was a great jumping off point to automate my process a bit more. Next I created a Splunk alert that allows me to alert our engineers of Critical or High protections that should be pushed with some urgency while allowing for a smaller alert for protections to be analyzed a bit more before pushing. The biggest benefit to this was unknown to me at the time, but the RSS feed is updated a full 24 hours or so before that update email is sent out so we were able to get updates out a full day faster, this is huge in this allegedly zero day world.

Some future improvements might be pushing the alerts out to SMS or via our Nagzilla system. I also have, in the back of my head, an idea for relating these things to relevant hosts via Splunk’s inventory module. All in all just one way to use technology for the betterment of all mankind or something like that.