Most modern operating systems have support for IPv6 – Windows Server 2008, Windows 7, Mac OS X and Linux all support it and most of them have IPv6 enabled by default. IPv6 was made to be very easy and self-configuring. There are many tunneling solutions to allow a IPv4 host to connect to a IPv6 host. Some of these are also self-configuring.  It is possible that you might have a tunnel happening on your network without knowing about it.

The local-link addresses that are self-generated by an IPv6 aware host provide a resource for a malicious application to establish communication via IPv6 to other IPv6 devices unbeknownst to most monitoring devices. It is possible to brick a Windows 7 host by advertising hundreds or non-existent routers that it will dutifully attempt to set up as routes.

Someday IPv6 will be the new “normal” and IPv4 will be “old tech”. Until that day you need to be aware and check the configurations on your network.  If you’re not using IPv6 (meaning, you haven’t set it up explicitly) then I’d recommend disabling it. If you don’t have a need to establish a tunnel to have IPv6 connectivity then block IP protocol 41 on your firewall. IP protocol 41 is used to set up most types of IPv6 tunnels. Also block IPv4 traffic to/from address 192.88.99.1 used for Teredo tunnels.

So come Wednesday, things won’t really change but you might want to look at making changes to help secure your network from potential issues.

Like most legislation, the stated purpose is difficult to oppose.  While there is considerable debate regarding the value of online piracy, there is no doubt that it runs afoul of our current laws.  Furthermore, the nature of the Internet makes it difficult to track down and attribute the violators.  When a single DVD is stolen from a retailer, there is a limited loss, the value of that single DVD.  When a movie is posted to a torrent site, that theft is magnified by a factor of 100.  Unfortunately, this response is filled with dangers that are easily identified and difficult to avoid.

The current crop of arguments against the legislation focus on the draconian take-down provisions.  Essentially, entire sites could be shut down due to alleged copyright infringment.  Without the courtesy of adjudication, sites could be forced off-line for “causing harm.”  It’s this notion, the allegation of third party harm, that causes the concern.  There is an increasing notion that information security can be legislated.  By opening the door to allegations of harm, it appears that we have stepped one step closer to the vicarious liability nightmare we’ve all hoped to avoid.

Several years ago, I can remember the question being asked, ” can an individual be held accountable for activities their machine takes?”  Being young(er,) and positive in my wisdom, I enthusiastically answered yes.  Now, being a little more seasoned, I question that statement.  I have many customers, all protected by conscientious security personnel.  They keep abreast of the threats, respond to the indicators.  They educate their users, install the protection, manage the perimeter.  They meet the regulations, obey the standards, even enforce the policies.  Yet, every morning, I review page after page of security threats present in the networks.  If a professional is challenged to keep a network clean, what chance does a private individual have?  And if they can’t keep the machines clean, should the ISP be held accountable?

Like so many issues in this ever-changing landscape, there are no easy answers.  It is incumbent to step lightly in the realm of legislation, and it is the information security professional’s duty to provide the best guidance we can to those in power.  Slippery slope gets used a lot, in this case, we’ve already seen the groundwork laid.

The saving grace here is that it is only the updates and configurations that are being channeled through this P2P network. For those defending the enterprise, the initial vector and the payoff are still handled through traditional means. The initial vector is easy enough to defend, at least on paper. Strong user training coupled with regular updates is a surprisingly effective tool against that initial infection. Likewise, egress filtering, coupled with up-to-date IDS goes a long ways towards identifying machines posting information. There are other tools available to the enterprise. At RiskAnalytics, our AutoShun and it’s big brother the Sentinel keep track of the ZeuS network C&C servers, bidirectionally blocking the traffic. So, while the updates may be difficult to detect, there are other pieces of the chain that still leave distinctive traces.

While this is a disturbing development, it’s not unexpected. The number of successful ‘bot takedowns over the past couple of years is creating pressure on the operators to make the adjustments necessary to ensure the survival of their networks. Likewise, the white hat side of the fence will have to make adjustments to our defensive strategies to account for this new line of communication.

The largest estimate I have heard for the TJX hack is $3.5 million in actual cash. The negotiated settlement just to the Visa corporation was $40 million. To date, over $250 million dollars has gone out of the coffers of TJX to pay various settlements to various vendors and business partners. If you start adding in all the extra monies spent in marketing and public relations, the hack easily multiplied its damages by 100. So, with the advantage of hind-sight, which risk would be better to address? Is it possible to address the litigation risk without addressing the security risk?

In the U.S., we graduate approximately 40,000 lawyers per year. The national unemployment rate for an attorney is 2.1%. By comparison, the last reported census of CISSP certifications is a little over 50,000 for the entire world, with an unemployment rate of around 3.3%. There are more of them, and they’re more fully employed, the numbers don’t stack well.

How do we address the litigation risk? If I had the “right” answer, I’d be lounging in the Bahamas counting my millions. There is no single answer, rather we have to look at it from the perspective of a litigant. My personal experience has been that the best defense against litigation is to raise the bar. Just as there’s no blinky light that will protect you against a dedicated hacker, there are no solutions against a dedicated attorney. Instead, you need to shape the battlefield. The best defense is a sound security policy built around realistic expectations of what your organization can accomplish. Concrete statements such as “we will” or “we won’t” are nothing more than litigation traps that organizations set for themselves all too frequently. Pardon my SANS pimping, but Benjamin Wright made reference to the notion of “aspirational policies” during the 523 course, and it resonated. The notion is that you acknowledge the human factor in your policies, stating that the goal is perfection but we know we’ll fall short. Now, in a litigation setting, that provides no shelter, but it doesn’t provide the hanging rope to the plaintiff either. I believe the logic boiled down to, what you write may not help you, but it most certainly can be used to hurt you. From the perspective of the plaintiff, this policy provides a much less straight-forward approach to proving negligence. I’ve also become fond of noting what a policy is meant to address within the policy. Clearly define your risk concerns and how the policy is designed to meet that risk calculation. By spelling out the specifics, there are no questions in the courtroom regarding the purpose of particular policies. Most class actions rely on being able to interpret for a jury, remove that capability.

So, what’s the point of this post? Is it a warning of things to come? A cautionary tale meant to inspire fear, uncertainty and doubt to a profession filled with FUD? The incoherent ramblings of a topic starved blog? The point is that there are very few “right” answers to most of our questions. Sometimes, just being aware of the questions has to suffice.

In the InfoSec field, this viewpoint seems to be gaining momentum, and that is a sad state of affairs. Faced with an increasingly long list of regulatory requirements, the profession is finding itself scrambling to meet seemingly arbitrary requirements that seem to have little to do with the particular organizational risks. It doesn’t need to be this way.

I’m certainly not advocating ignoring the requirements of an organization’s regulatory regime. Instead, I believe that the requirements can be interpreted in such a way that genuine security becomes the deliverable. As a profession, we need to quit interpreting “to the check-box.” If there is a requirement, we should fashion solutions that contribute to the risk solutions for the organization. If PCI mandates that firewalls be reviewed every six months, don’t turn it into an exercise in minimalism. Establish a program that genuinely reviews the firewall rules, and tests the implementation. Review not just the words of the rules, but the impact and the procedures that led to them. Don’t be satisfied with what a third party states as your organization’s goals, work within that framework to truly increase the security posture of your organization.

We’ve become complacent. We preach the value of “true security” and fret away at our inability to promote such a state. We complain about the regulatory requirements, the check-boxes, and the theater. A better solution is to make the theater work for us.

http://article.gmane.org/gmane.comp.apache.announce/58

To make it very clear, Spamhaus effectively closed off large segments of the Internet from their customers. Rather than expend the energy hunting down every individual spammer, they chose to cut them off at the knees by invalidating an entire class b range of addresses. For the spammers, it’s not going to be as simple as switching servers at the ISP, now they have to find a new base of operations.

RiskAnalytics has taken the same approach for years now. Our AutoShun and Sentinel product lines both operate on the assumption that there are segments of the Internet that simply should be avoided. Sitting in-line, we simply shun any of the 3.2 million addresses that we have positively identified as being host to malicious players. We don’t inspect the traffic, we don’t listen to the conversations, we just block any traffic from or to that IP. We maintain an extensive intelligence capability and constantly update the list of known bad-actors. In short, we place the known bad guys out of bounds.

It’s not the end-all solution. There will always be the new threat, not yet identified. Customers still need to maintain a culture of security, users still need to be taught safe computing practices. The fact remains that there is no silver bullet to your information security woes. But the practice of simply refusing communications with known threats can go a long way towards securing your enterprise.

Every organization needs to develop a plan for maintaining its software. Rules, regulations, policies and contractual agreements are all beginning to address server patching. Failure to comply can lead to loss of business partners, restrictions to payment methods and, in some cases, regulatory fines.

The cure for back-level software is fairly straight forward, patch your servers. The challenge comes when an organization has to figure out which software needs to be patched. There are a number of products in the market that allow an organization to inventory not only the physical hardware, but the software loaded on that platform as well. Obviously, organizations that have embraced this approach do a better job of keeping the systems patched. For smaller organizations, and companies that have not yet implemented such a solution, the challenge becomes more formidable.

One of the most important aspects of server patching is that ALL applications must be patched. Too often, organizations update the OS of a server and fail to update all the applications that have worked their way onto the servers. Items such as Adobe Reader, Flash, and Firefox are not uncommon on a production server, and usually at least a generation or two behind the times. Usually installed for the sake of expedience, these applications live quietly in the production environment, used only occasionally and rarely documented. Keeping track of these rogue installs is a difficult task.

For those without the automated inventory, the starting point is to limit your exposure. Limit the amount of software installed on any server, create policies to limit and control the software that gets installed on servers, and maintain accurate lists of what type and version of software is installed on your servers. As with any good audit, the secret of success is to limit the scope. By keeping the servers as lean as possible, the chances of “missing” a patch decrease considerably. The easiest way to accomplish this is through your organization’s policies. Establishing a life-cycle process that includes items such as software installation can go a long way towards creating the security culture that most organizations are striving to achieve. When creating the policy, don’t confuse an iron hand with secure. Good security has to take the business needs into account. When policies get in the way of productivity, policies get bypassed…usually without notification. For validation, there are plenty of open source tools to test your servers. Older forks of Nessus are still supported, and many have local security checks for your operating systems. Likewise, they can look for out of date and vulnerable software. By limiting the amount of software installed, organizations can also simply use the “check for updates” function built into most modern software. The key is, make the job as simple as possible. There are no rewards for useless complexity, but there can be plenty of penalties.

Most organizations today have embraced the notion that all software must be updated regularly. Those organizations that have gone through the process of creating a patching policy know the difficulty involved, but also understand the necessity. Firewalls are no different. The attackers have access to every piece of hardware an organization can put into its environment. They dissect, decompile, poke and prod to find vulnerabilities. Odds are, if you have a device on your network, they know how to break it.

The most common firewall issue today is simple misconfiguration. A rule hastily put into place during a troubleshooting session can be devastating to an organization’s data security. All too often, the frenetic efforts to make an application “work” results in hastily conceived changes to a firewalls ruleset. Free thinking administrators will try many different changes without proper documentation or testing in an effort to correct perceived issues. Over time, these subtle changes begin to add up, the result being the “shield” of an organization’s firewall is really nothing more than a screen. Usually, the efforts are performed under the guise of business need, but all too often the business ends up with glaring weaknesses in the perimeter.

Aged software is another common issue. In general, organizations are loathe to upgrade or patch firewall software. A belief that the system will fail, or a notion that “it’s working now” act as an attitudinal barrier to proper maintenance. As exploits become available, that vaunted software becomes more of a speed bump than an actual defense.

The solution is both simple and complex. The mechanics are straightforward, the implementation more problematic. Establish procedures for making any changes to a firewall. The changes should involve review of all proposed changes and implementation during normal maintenance windows. By establishing a firm policy regarding firewall changes, organizations can create a culture of planned migration rather than allowing “on-the-fly” changes to the defenses. Likewise, regular reviews of firewall configurations, with documented justification for each and every rule or configuration setting for the device. This allows the firewall rules to maintain pace with the business needs, and forces the organization to acknowledge business processes that affect the security of an organization. Additionally, ensure that all network devices, including firewalls, follow the organization’s software patching process.

Firewalls are normally out of sight, don’t let them slip out of mind as well. They are the vital hard shell to your organization’s data infrastructure. Regular review and proper maintenance are essential if your organization is to stay out of the headlines.