Alright, time to really, really, really get back on the blogging horse. This time for real or something but most folks should probably know better. Must be too content as things are largely good :)
Anyway, still owe a longer post on the previous topic with regards to how academia and research views security versus the real world. Various events interspersed since that post have really only reinforced that view but I'll withhold judgment until the process makes it way to completion. Once it works its way to completion, I promise a scathing rant.
On a secondary note, I've been doing a bit more pondering with regards to the principles of admission control and in particular systems in general. I am hoping but perhaps being naively optimistic to spend some serious time trying to sketch out a paper for HotNets this summer on the topic. The basic crux of the paper is pretty simple, we are wrongly focusing on minutia when in reality, we should really be focusing on dynamics. In my humble opinion, dynamics are what we should really be thinking about when it comes to scale. How do we keep the dynamics under control, i.e. avoid rapid change? My intuition is that we can use this as a guiding principle for system design in that things should be limited to change within a certain bound, thus limiting the emergent dynamics that can occur that we typically fail to understand.
Not sure exactly how I will go about crafting this paper but HotNets tends to align nicely with it. Worst case is that I write a nice screed that gets rejected but is ultimately quite cathartic. The public / private firewall paper seemed to go quite well along those lines despite its rocky road to publication. The paper still brings a smile to my face even almost a year after publication.
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Monday, May 31, 2010
Sunday, April 25, 2010
Back, this time for real (I hope)
With summer coming up, time to get the old blog posts a rolling again.
I have a nice, lengthy post coming up, courtesy of a review we just got from a journal (a good one too which makes it even more sad). The single review was in response to our paper examining public versus private firewall rules which asked the simple question, do you really gain that much by keeping your firewall rules private. Hint: the answer is way less than one would think.
Anyone, onto the money quote from the reviewer:
Wow, just wow. One would be hard pressed to come up with a better example as to why industry ignores the security community.
I have a nice, lengthy post coming up, courtesy of a review we just got from a journal (a good one too which makes it even more sad). The single review was in response to our paper examining public versus private firewall rules which asked the simple question, do you really gain that much by keeping your firewall rules private. Hint: the answer is way less than one would think.
Anyone, onto the money quote from the reviewer:
Firewalls are generally considered a hack, not any real guarantee of security. A backstop. Do we need to analyze this hack with such loving care?
Wow, just wow. One would be hard pressed to come up with a better example as to why industry ignores the security community.
Wednesday, February 25, 2009
Firewall Complexity
It appears that our work looking at firewall complexity in the most recent ISSA Journal is nicely coinciding with work being done in industry. Secure Passage just released a survey coming to roughly the same conclusions that we did albeit focusing primarily on Fortune 1000 companies whereas our survey was more broadly based.
Of particular note, the top two most shocking findings from the Secure Passage report:
Living firmly in the land of academia and hence being able to speak from the ivory tower, these works should be a huge wake up call for how security research should proceed. All too often in security research, the perfect becomes the enemy of the good but I think researchers forget that easy to use security (yes, Virginia there is such a thing) offers a huge benefit to the overall health of the Internet ecosystem. Certainly, there is a need for high end, complex systems such as for DARPA / etc. but by in large, complexity is not a friend of security.
Moreover, I do not think the problem is one of building a better interface for the existing tools. It is a general philosophy where complexity is viewed as an informal indicator of correctness or completeness. Unfortunately as my students can attest, try publishing something novel but not terribly complex and the results are often less than heartening. Perhaps that is best left to industry but certainly these surveys attest to the security elephant in the room that we know things are bad and really can not do too much about it*.
Hat Tip: Athena Security which has a tool for improving firewall complexity Athena FirePAC
Of particular note, the top two most shocking findings from the Secure Passage report:
Top 10 Shockers Revealed by Respondents:
1. 73 percent think firewall rule bases are too complex or out of control
2. 59 percent feel that a lack of management tools makes policy management difficult
Living firmly in the land of academia and hence being able to speak from the ivory tower, these works should be a huge wake up call for how security research should proceed. All too often in security research, the perfect becomes the enemy of the good but I think researchers forget that easy to use security (yes, Virginia there is such a thing) offers a huge benefit to the overall health of the Internet ecosystem. Certainly, there is a need for high end, complex systems such as for DARPA / etc. but by in large, complexity is not a friend of security.
Moreover, I do not think the problem is one of building a better interface for the existing tools. It is a general philosophy where complexity is viewed as an informal indicator of correctness or completeness. Unfortunately as my students can attest, try publishing something novel but not terribly complex and the results are often less than heartening. Perhaps that is best left to industry but certainly these surveys attest to the security elephant in the room that we know things are bad and really can not do too much about it*.
Hat Tip: Athena Security which has a tool for improving firewall complexity Athena FirePAC
Wednesday, February 4, 2009
Front page baby!
Very cool, our journal article looking at firewall management practices managed to make the cover of the ISSA journal. My student Mike Chapple did a very nice survey of current firewall administrators and IT managers to determine what self impressions administrators had of the correctness of their firewall configurations.
The short / sweet version is that firewall configurations are likely wrong and we know it and things are not getting better. System administrators are swamped and hoping that nothing major goes wrong. For those of you in the security business, I highly recommend using it as justification for a better raise or for hiring new people.
The short / sweet version is that firewall configurations are likely wrong and we know it and things are not getting better. System administrators are swamped and hoping that nothing major goes wrong. For those of you in the security business, I highly recommend using it as justification for a better raise or for hiring new people.
Friday, October 19, 2007
Weekly Papers - Oct 17
SMACK, aka Simplified Mandatory Access Control Kernel by Casey Schaufler attempts to bring MAC (Mandatory Access Control that is, not the network MAC) to the masses via a LSM in Linux. For those unfamiliar with MAC in the security context, think that everything is labeled with explicit access control and stricter rules on changing access. The CIPSO network tagging is also interesting as we had been considering how to convey local context as part of Lockdown during the TCP SYN phase.
Interesting also that the work in that it is a real live implementation.
Interesting also that the work in that it is a real live implementation.
Wednesday, October 10, 2007
Weekly Papers - Oct 10
Playing Devil’s Advocate: Inferring Sensitive Information from Anonymized Network Traces
The paper by Coull, Wright, Monrose, Collins, and Reiter that looks at how good the state of the art anonomyzation schemes with regards to hiding identity appeared in NDSS 2007. With a bit of data mining (clustering), DNS, and search engines, the work attempts to infer identity despite anonymization.
Very cool results demonstrating what I think those who have been skeptical of anonymization have suspected for quite some time.
The paper by Coull, Wright, Monrose, Collins, and Reiter that looks at how good the state of the art anonomyzation schemes with regards to hiding identity appeared in NDSS 2007. With a bit of data mining (clustering), DNS, and search engines, the work attempts to infer identity despite anonymization.
Very cool results demonstrating what I think those who have been skeptical of anonymization have suspected for quite some time.
Thursday, September 27, 2007
Public vs. Private Firewall Policies
One of the mantras in the security world that has perplexed me is the notion that firewall policies should always be kept hidden from everyone else. The rationale of course is that if the rules are hidden, it will make it that much harder to the attacker to gain entry into the system.
However, I am not sure I completely buy that rationale. Is it really that much effort to probe for open ports on guarded systems? Does it really take that long or is itjust a few more minutes while one of the countless botsin the botnet does the remote scanning? Moreover, does the detection of said port scan do any good either withthe sheer volume of typical port scanning going on in a day to day sense?
From a distributed systems vantage point, the silent failure modes of firewalls can be painful to debug. Sure, if the firewall sends an ICMP Port Not Available, that would be great but most simply sink traffic off into /dev/nullleaving the application to slowly time out, often with abysmal service properties. At what point does the benefit of faster debugging outweigh the "security" benefit of hidden firewall rules? I'm guessing the threshold is much lower than what is typically employed. Debugging a normal system is hard, make the system distributed and itturns quickly into a nightmare.
To be fair, there are cases where I think hiding rules is appropriate, specifically when access is constrained to asubset of hosts. The important information to hide is notnecessarily what ports are exposed but to whom access is granted. One could argue that the hiding of this information does significantly impede the progress of the attack as scanning from an arbitrary host gives imprecise information, sort of a Byzantine-esque (I use this term loosely, not precisely) quality to information gathering. Then again,there are likely levels also in this case as well. A simple 'restrict to the local network' policy (aka the local subnet) really doesn't buy that much time or defense but a 'restrict to an obscure host or bank of admin hosts' would potentially improve defenses.
Perhaps should there be a notional ICMP Firewall Denied message to assist with debugging? Likely too problematic for security purposes(reflection DoS attacks) but interesting from a debugging standpoint. The increased tamping down of ICMP messaging (our campus blocks inbound) also likely makes this a non-starter. Perhaps something in TCP? A can of worms but maybe a nominal TCP options field? Something truly crazy would be the ability to query any host for its firewall ruleset. Crazy indeed.
However, I am not sure I completely buy that rationale. Is it really that much effort to probe for open ports on guarded systems? Does it really take that long or is itjust a few more minutes while one of the countless botsin the botnet does the remote scanning? Moreover, does the detection of said port scan do any good either withthe sheer volume of typical port scanning going on in a day to day sense?
From a distributed systems vantage point, the silent failure modes of firewalls can be painful to debug. Sure, if the firewall sends an ICMP Port Not Available, that would be great but most simply sink traffic off into /dev/nullleaving the application to slowly time out, often with abysmal service properties. At what point does the benefit of faster debugging outweigh the "security" benefit of hidden firewall rules? I'm guessing the threshold is much lower than what is typically employed. Debugging a normal system is hard, make the system distributed and itturns quickly into a nightmare.
To be fair, there are cases where I think hiding rules is appropriate, specifically when access is constrained to asubset of hosts. The important information to hide is notnecessarily what ports are exposed but to whom access is granted. One could argue that the hiding of this information does significantly impede the progress of the attack as scanning from an arbitrary host gives imprecise information, sort of a Byzantine-esque (I use this term loosely, not precisely) quality to information gathering. Then again,there are likely levels also in this case as well. A simple 'restrict to the local network' policy (aka the local subnet) really doesn't buy that much time or defense but a 'restrict to an obscure host or bank of admin hosts' would potentially improve defenses.
Perhaps should there be a notional ICMP Firewall Denied message to assist with debugging? Likely too problematic for security purposes(reflection DoS attacks) but interesting from a debugging standpoint. The increased tamping down of ICMP messaging (our campus blocks inbound) also likely makes this a non-starter. Perhaps something in TCP? A can of worms but maybe a nominal TCP options field? Something truly crazy would be the ability to query any host for its firewall ruleset. Crazy indeed.
Subscribe to:
Comments (Atom)
