NWN Security Updates

Information Security Burnout

kfiscus@nwnit.com (Kevin Fiscus) — Fri, 02 Mar 2012 15:12:00 +0000

RSA Conference is winding down and one of the most interesting and meaningful talks was actually the first I attended - a Jack Daniel moderated panel discussion on stress and burnout in the information security industry. The pannel was really focused on the science and statistical analysis of stress and burnout. It was a great presentation. That said, I'm not going to restate their discussion but rather talk about what it means to me.

When people talke about stress in our industry, a common, if not often spoken response goes something like - "Shut up you baby and quit whining. You get paid well for sitting in a chair typing on a computer all day!" To be honest, that is a valid point. We typically do get paid pretty well and we do sit and type on a computer. Unfortunately, the story is not that simple. During the pannel discussion, a couple of the members mentioned an individual they knew who used to be a tactical narcotics officer and then transitioned to information security. In his prior life he dealt with guns, drugs and really bad guys. After spending a year in his new career he stated that information security was FAR more stressful. That may seem crazy but I think it makes a lot of sense.

When acting as a tactical narcotics officer, a good day is one where everyone goes home alive. The metrics were simple. You could get to the end of your shift and know that you did what was expected of you. When you are done you can go home, relax with the family, take vacations, etc. While the risks are definitely higher, success and failure are easy to define and when you are done, you are done.

Now let's look at the world of information security. In our industry, success is largely determined by nothing happening. We are largely successful when nobody notices what we've done. We work in an industry that was once described by Dan Geer as one of the most challenging intellectual pursuits in the history of mankind - "Too deep to master, too wide to know and to fast to photograph." There are few metrics and it can be argued that we, those who defend computer networks from attack, are losing and have been losing for a long time. We have to be right 100% of the time and the bad guys need only be right once.

If that were the only problem, I think it would be fairly manageable. Unfortunately, there are other aspects to this industry that make things more difficult. Our industry tests to attract a particular type of person. We tend to be extremely driven and competitive. I think there is also some level of insecurity (pun only partially intended) in many of us. We always want to be better and never think we are good enough. As a result, we put pressure on ourselves - often more pressure than our employers put on us. This self-induced pressure does adds to the level of stress we feel.

As an industry, we do little, collectively, to help. We spend all of our time looking for weaknesses. This is great when we are analyzing our networks, applications or operations. Unfortunately, we often find those weaknesses in ourselves and/or in others. When we find weaknesses in ourselves, we feel the need to work harder or feel guilty for not working harder. When we find weaknesses in others, we tend to call them out on them - often publicly. This only adds to the problem and does little to help.

Pulling everything together - we work in industry where there are real good guys and real bad guys and, arguably, the bad guys have the advantage. At best, when we win, nobody notices. At worst, when we win we become the target of those bad guys. Our employers often have little or no understanding of what we really do and thus the pressures we are placed under are largely self induced. When we put ourselves out there, we do so at the risk of attack from bad guys and from our own community. Finally, we do this to work in an industry where there are no clear metrics for success but obvious indications of failure. It's no wonder we are at such high risk of failure.

I guess the real point of this posting is to put out a challenge - don't continue to make the situation worse. We who work in the information security industry know what it is like. If you know someone who is doing a good job, tell them. If you know someone who needs help, help them. If you know someone who seems at risk of burnout, try to help. Information security may be a highly analytical and technical industry but we who practice it are people. We need to keep that in mind.

Security Accountability: A Hidden Problem

kfiscus@nwnit.com (Kevin Fiscus) — Fri, 06 Jan 2012 14:20:00 +0000

When trying to come up with something to post about today I started thinking about the biggest problems I run into when doing security assessment for my clients. A bunch of things started running through my head - lack of web or email filtering, lack of sufficient monitoring, poor web security, no security awareness training and bad patch management all came to mind. I don't think anyone can argue that these all can be problems but that doesn't mean they actually are.

When dealing with information security, we all use a bunch of cliche terms, sayings and phrases but often fail to put them into actual practice. We discuss "defense in depth" but then focus almost all of our efforts on protective controls, ignoring detection, response and recovery. Similarly, we all say that eliminating risk is not our goal. In fact, we say, the elimination of risk is not possible. At the same time, we do penetration testing, scanning and assessments that identify all conceivable vulnerabilities and recommend that they be eliminated. What happened to "risk acceptance". In theory, an organization should be able to review the likelihood that a threat exploits a vulnerability causing harm in terms that can be translated into a dollar amount. Taking a page from the CISSP or SANS Security Essentials class - we should be able to identify an annualized loss expectancy. If the ALE for a given risk is $10,000, it makes sense to spend $1,000 per year to mitigate while it doesn't make sense to spent $20,000 per year. This is infosec theory 101. The question however, becomes how do we actually put this theory into practice? I believe the answer relates directly to the concept of asset ownership.

Many times when I talk to my clients I ask them who "owns" data assets. They reply that IT does. I then ask if IT has the authority to permanently modify or destroy the data assets they "own". The response, in most cases, is that no, they don't. Business decisions about data assets (such as the data in a database) are made by the owner of the business unit that uses that data. This fact alone means that the business unit, and not IT, is the asset owner. So what does that have to do with security and why is it a big problem? Good question!

In these same organizations, I ask how involved the business unit owner is in making security decisions. The response is almost always the same; the business unit simply expects that IT or the infosec group will provide them with security. Unfortunately, what "security" means is often not well defined. Generally, from a business unit perspective, "security" means that their assets will never get compromised with a focus on confidentiality and integrity. As a result, there is no concept of "acceptable risk" and this IT/security is left with the unenviable task of attempting to accomplish "perfect" security with a limited budget and limited resources. Because this is not possible, IT/security is left with the responsibility of determining acceptable risk when may business owners intuitively feel all risk is acceptable (when it comes to allocating budget) while no risk is acceptable (after a compromise has occurred).

So what is the solution to this problem? The answer is easy to say but difficult to do. Business owners (the true data asset owners) must take responsibility for accepting risk. IT/security thus moves into the role of providing risk information to business owners. The information provided should include a description of threats, vulnerabilities and some metric that describes the likelihood and level of harm (perhaps the aforementioned ALE). IT/security should also make recommendations as to risk mitigation steps including cost estimates. If the business owner determines the risk is unacceptable, they should be willing to allocate budget or other resources to mitigate. If the business owner determines the risk is acceptable, they should sign off on the fact and be held accountable for the results. IT/security should not be held accountable for compromise that took advantage of accepted risk. Rather, IT/security would be held accountable if the information they provided to the asset owners was bad or if they failed to effectively implement approved control.

This balance ensures that those ultimately responsible for the assets (the owners) play an active role in making security-related business decisions. It also ensures that budgets are tied, at lease in some way, to risk. Finally, it puts IT/security personnel in a position where they have the capability of successfully doing their jobs rather than staying in the "no win" situation they currently are.

The Scary Truth Behind Hacking Gone Wild

kfiscus@nwnit.com (Kevin Fiscus) — Thu, 04 Aug 2011 12:33:00 +0000

Over the past few months we've seen an unbelievable amount of successful hacking going on. Big names like Sony, Lockheed Martin, RSA Security, NATO and the International Monetary Fund have been in the headlines having suffered massive security breaches at the hands of groups like Anonymous and Lulzsec.

Adding to the madness, a recent article in the Wall Street Journal (http://online.wsj.com/article/SB10001424052702304567604576454173706460768.html) highlighted the fact that in a 2010 the U.S. Secret Service and Verizon Communications's forensic analysis unit responded to a combined 761 data breaches (up from 141 in 2009). Of those, 63% were at companies with 100 employees or less. As also stated in the WSJ article, Visa estimates that about 95% of credit card data breaches involve its smallest business customers.

Yesterday, Fox News reported that "The world's most extensive case of cyber-espionage, including attacks on U.S. government and U.N. computers, was revealed Wednesday by online security firm McAfee" (http://www.foxnews.com/scitech/2011/08/03/massive-global-cyberattack-targeting-us-un-discovered-experts-blame-china/)

What is going on? It feels like a significant paradigm shift is happening in the information security industry and it is not a good one. But why is this happening? In my opinion, what is going on is very simple. Highly publicized hacks followed by named groups like "Anonymous" and "Lulzsec" create the unfortunately all to correct impression that hacking computers is easy. The fact that these attacks are not followed up by highly publicized arrests and convictions creates the unfortunately all to correct impression that you can hack computers and get away with it. Given the likelihood of success and of not getting caught, the situation, from a potential criminal's perspective, boils down to a quote from last week's PaulDotCom podcast - "If you can't do the time, do cybercrime".

The state of cyber security is poor, to say the least. Simple attacks such as spear-phishing and SQL injection are far too successful in far too many circumstances and the bad guys pull further and further ahead. Former L0pht member and current DARPA project manager Peiter Zatko (a.k.a. Mudge) gave a presentation at the most recent ShmooCon stating that the average piece of malware has 125 lines of code while the average piece of defensive software has around 10 million. This disparity creates a problem. Attackers can generate 80,000 different pieces of malware for the effort it takes us to create a single defensive application. And because their malware is much simpler, they would still win that race.

Our biggest problem is that we continue to think of information security in evolutionary terms. We have started with a fairly basic castle model - build big walls around our stuff. As we discovered that doesn't really work by itself, we added some monitoring capabilities and shifted, in thought if not in deed, to the mantra "protection is ideal but detection is a must". In fact, my friend Winn Schwartau wrote a great book called "Time Based Security" that basically stated that the level of security could be measured by the time it takes to detect and then respond to security threats. As we continued to tear holes in out "castles" as a result of third-party connectivity needs, remote workers, web application proliferation, etc. our model started to break again so we again shifted. Now we try to focus on the endpoint by deploying host-based IDS/IPS, endpoint protection, etc. We create walls using VPN tunnels and SSL encryption. Unfortunately, we are still stuck within the same castle - only now the castle just happens to move with us.

The castle was the major defensive military structure throughout the middle ages. The walls withstood prolonged attack and sieges were expensive and dangerous. Breaking castle walls required digging under them using sappers or employing complex siege machines like catapults and trebuchets. Both of these methods were complex, dangerous, expensive and had to be built at the scene of the battle. The came gunpowder and the state of warfare was changed. Now cannon could be deployed to break down castle walls. Those cannon could be build off-site and hauled to the battle by horses, could be fired at range and could be moved to knock down the next castle after the first was rubble. In modern information security, we still use castles - the bad guys use gunpowder.

As I mentioned, I believe a paradigm shift is necessary. One of the best ideas I saw was a posting by Lenny Zeltser entitled "Reflections on Deception and Protean Tactics" - http://blog.zeltser.com/post/7385712192/deception-and-protean-security-tactics. In this article, Lenny postulates about the use of technologies that are easy for us to deploy but that significantly disrupt or delay the attackers. Examples of these include the LaBrea Tarpit, honeypots and “Sparse” files that would look normal on the file system, but would be huge in size when being downloaded.

I don't know if this is the right approach, part of a right approach or if it is going in the wrong direction entirely. I do know that the approach we currently use is resulting in defenders falling further behind each day. While as an industry, I don't believe we have all the answers, I do believe that the first step is identifying the problem. After all, as they used to say on the G.I. Joe cartoons in the 80's, "knowing is half the battle".

Back to Basics

kfiscus@nwnit.com (Kevin Fiscus) — Wed, 13 Jul 2011 11:33:00 +0000

I tend to lurk on a bunch of email based discussion groups where I watch threads that talk about "what should we used instead of the broken MD5 hash" or "what the alternatives to broken SSL". I see lots of focus on the new 0-day sploit and techniques involving intercepting communications, cracking something or other, then using that to compromise something else. There is no question that when it comes to "cyber security", it is an extremely dangerous world and getting more so. Unfortunately, I think the industry of computer security has lost its way.

A article about recent Booz Allen Hamilton compromise, Anonymous was quoted as saying "We infiltrated a server on their network that basically had no security measures in place. We were able to run our own application, which turned out to be a shell and began plundering some booty. Most shiny is probably a list of roughly 90,000 military emails and password hashes (md5, non-salted of course!). We also added the complete sqldump, compressed 50MB, for a good measure." Yesterday, a colleague of mine stated that he found a basic authentication bypass SQL injection bypass vulnerability in a clients payroll server and found that the username/password combination of GUEST/GUEST worked on that same client's VPN. From what I saw or could infer from news about many of the Lulzsec compromises, they seemed to be using SQL injection or similar attacks.

I know 0-day compromises are possible and a threat. I know there are ways to break different types of encryption. I also know that people, generally, can tend to be a little lazy. I don't mean lazy in a bad way but if given the choice between cracking passwords and typing 'or 1=1 into a password field, which would you do? Would you rather research and use an new 0-day exploit or leverage the fact that the target hasn't patched Adobe Reader in 3 years.

As a penetration tester, there are some basic techniques that make my life a lot harder:

• Good patching practice, not only for Microsoft but for all technologies
• Basic hardening, particularly something as simple as changing default passwords
• Security focused web and email filtering.
• Strong firewall rules for both ingress and egress
• Network segmentation and access controls between segments
• A decent web application firewall
• Updated endpoint protection

How many recent (publicized or otherwise) attacks could have been prevented by these fairly basis measures? Am I saying that this is all that is necessary for security? Absolutely not, but I do think that as security professionals, we tend to miss the obvious and focus on the complicated leaving the bad guys with big holes to walk right through. Perhaps we should spend a little time getting back to basics and make sure that the foundation of our security program, the policies and the security infrastructure, are in place because all too often when doing risk assessments for my customers, I find that is not even close to being the case.

Cisco Identity Services Engine: What it Means To You

kfiscus@nwnit.com (Kevin Fiscus) — Wed, 29 Jun 2011 18:37:00 +0000

The recent introduction of Cisco’s next generation network access control system (ISE) raises the bar for internal network security controls and should make you examine whether this system is appropriate for your organization.

ISE is an integrated network access control system. The system is designed to restrict network access based on criteria defined by the organization. These criteria typically includes any combination of the following:

· Correct user ID & password authentication

· Windows group membership

· Up-to-date operating system patches

· Antivirus software functioning & up-to-date

· Machine owned and managed by the organization

· Operating system and/or browser

Based on these criteria, the level of network access is defined commensurate with risk. For example, machines that do not have updated patches might be permitted to only “talk” to the patch server so that updates can be installed. Further, network access can be defined dynamically based on the users role (i.e., only Human Resources users are permitted access to the servers containing personnel data.) Restricted network access for guest users is a natural extension of this technology, allowing visitors to access the Internet using existing infrastructure while protecting internal resources.

In legacy NAC systems, this control is implemented through dynamic VLAN assignment in conjunction with a separate control point, typically a dedicated firewall or NAC appliance acting as a primitive firewall. More modern 802.1x NAC systems control access at the switch-port level, but have proven difficult to implement and maintain, requiring multiple disparate systems to manage.

Cisco ISE is innovative in that it implements everything mentioned above in a single integrated platform with a rich, flexible set of policy controls. ISE has broad hardware support, including the most common Cisco switches & wireless devices. Further, tools to accommodate non-NAC and/or non-802.1x compatible devices, such as printers, IP phones, or CCTV systems, are cohesive and mature, requiring minimal effort to maintain.

Employing security consultants and engineers with broad cross-functional experience, NWN STAR is uniquely qualified to design and implement Cisco ISE systems. Our engineers have implemented NAC systems across a variety of industries, including government, education, banking, retail, and healthcare environments. NWN recently became one of the first Cisco partners to be trained and certified to implement these systems for both small- and large-scale environments.

Gmail Users Beware

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 28 Jun 2011 15:25:00 +0000

Recently I discovered that a Gmail account I use for subscriptions to newsletters and similar non-critical content had been hacked by someone in China. That, by itself, isn't that interesting but there were some interesting aspects of the "attack".

I would like to think that I am fairly security savvy, given that is what I do for a living but this event has opened my eyes to how vigilant we must be as defenders and the true advantage attacker have over us.

I first discovered that this Gmail account had been compromised when I started receiving bounce-back messages from a strange email address - 451231738@qq.com. I know I didn't send any email address so I did some digging. It turns out that QQ is a popular instant messaging site in China. Hmmmm, that's not good. I then checked out the setting on my Gmail account and discovered what actually happened.

Typically, I view the email from this particular Gmail account on any of various other devices (iPad, laptop, etc.). As a result, I don't usually log in to Gmail itself. When I did, I was presented with a big, red flashy sign that said, basically, Danger Will Robinson, someone has recently logged into your account from China - click here to see what happened. I clicked there and found that my account had been accessed at least 3 times from China starting around 10 days before I detected the problem. That, of course, prompted additional investigation.

I looked in the setting of my Gmail account and found a lot of bad things. I first noticed that someone had set up the QQ email address as an address that mail sent to the Gmail account could be forwarded to. Next, I discovered that the password recovery email address was also set to the QQ email address. Finally, I found a number of filters set up to forward any email containing the words "password", "info", "account" and "paypal" would be sent automatically to the QQ account. Also, any email from @blizzard.com or @battle.net would be forwarded.

Given that I don't use this Gmail account for anything critical, I'm not terribly concerned about the impact of this hack. I suppose someone in China could steal my subscription to a newsletter or discussion group but that's not that big of a deal. There are a couple of things that really do have me concerned.

First, how did the attacker manage to compromise my account without me knowing about it? Perhaps my password could have been better but doesn't Google have a setting to prevent brute force attacks?

Second, it scares me that the attacker was able to modify the settings of my Gmail account such that I would not have found out about the attack if the QQ address hadn't been shut down. How many others don't log into the Gmail web site but rely on Mail.app, phone mail clients, Outlook or similar mail clients to get their mail?

Third, how many people use their Gmail accounts to conduct real business (either professional or personal)? How many people use Gmail to reset the passwords on their bank accounts, to pay bills, etc. This type of attack had little real negative impact on me but that we partially dumb luck in that I don't use Gmail for anything really important.

Finally, is this problem specific to Gmail? Are other web-based mail services less vulnerable? Equally vulnerable? More vulnerable?

To wrap things up, if you are reading this and use a web-based email service like Gmail, check you settings as soon as you can. I'm not saying you've been hacked but it is better to be safe than sorry. Remember to check the settings and change your password to these sites regularly.

And Google, if you are by any chance listening, please include an account lockout function (if you don't already have one) and please allow me to include a setting that alerts me if settings are changed. It doesn't have to be fancy - just a quick email stating that "we just wanted to let you know that your settings have been changed - if you didn't do this, you've been hacked!".

Nessus Parser V0.10

kfiscus@nwnit.com (Kevin Fiscus) — Sat, 04 Jun 2011 20:00:00 +0000

Cody Dumont from the NWN STAR team just release the latest version of his Nessus Parser. The parser can be found at www.melcara.com. Here is an expert from his blog posting.

Nessus Parser v0.10 – This is a program to parse a series of Nessus XMLv2 files into a XLSX file. The data from the XML file is placed into a series of tabs to for easier review and reporting. New features with this edition are better reporting of policy plugin families, user account reporting, summary graphs, and a home page with summary data. For more information and questions please contact Cody Dumont from the NWN STAR team.
Email – cdumont”AT”nwnit.com

Access Granted

kfiscus@nwnit.com (Kevin Fiscus) — Fri, 27 May 2011 19:05:00 +0000

Back in April, I discussed the March breach in security at RSA. After I posted my article, I was contacted by a friend of mine that works for a certain “Three Letter Acronym” agency whose name and organization will remain un-named. My friend asked me if I might happen to know exactly what was compromised at RSA? While I couldn’t be certain, I suggested what I (and maybe most of you) had already heard via news channels, media, and security contacts. While I know more details on what actually happened, I don’t know specifics. From my knowledge, what was known to be compromised was possibly the algorithm seed, and maybe the key generation time. The algorithm itself, has been publically known for years. From a security standpoint, this is like having a key, but not sure which lock it fits into.

I told my friend that there shouldn’t be too much to worry about, because while there’s enough pieces compromised to launch a brute force attack (basically, an educated guess that is retried until you succeed), there shouldn’t be enough to do a more damaging attack. Brute force attempts are fairly easy to spot, mitigate, and deny access. My friend was put, at least a little, at ease. That was until last week…

I received notification that sometime last week, a very large U.S defense contractor that uses SecureID tokens from RSA to provide two-factor authentication (something you have, and something you know; think of your Bank Card and your PIN) for remote VPN access to their corporate networks. Before Monday morning an alert went out, and all remote access to the internal corporate network was shutdown. Employees were notified that remote access could be down upwards of a week, possibly more. For telecommuters, this meant you either came into a branch office, or you simply could no longer work. Two days ago, my friend told me, a notification that every person who had an RSA SecureID token, would be getting a new one. This process, as I discussed in my earlier article, would take at least a few weeks to funnel out to everyone.

Along with this, all users (over 100,000 of them) would be required to change their passwords. The amount of help desk related issues this causes, simply means that administrative level files and access have almost assuredly been compromised.

From what I can tell, whomever hacked RSA, had now come into possession of the algorithm for the current tokens, and had then managed to install a key-stroke logger somewhere on the network. With both of these pieces, that unknown lock I discussed earlier in this article was now known.

While this was an expected outcome (most security folks like myself, have been awaiting such a breach), it was not enough to circumvent this from occurring. Shortly after the RSA breach became public knowledge, most companies that relied on SecureID for authentication, started requiring a second form of password before access to the network was granted. This, though as you can probably tell, would not resolve the issue if a key-logger was in place, as the hacker would know the password the minute it was typed.

I am a “Glass Half Full” sort of person, so I guess the silver lining in this story is that my friend and his staff were able to spot the intrusion, and acted appropriately to mitigate any further incidents. Kudos are warranted for such a feat as this is not an easy task. Although the aftershocks caused by this incident will be many, and far into the future.

While I am sure this is not an isolated incident, it is a major one, and one of the first public ones. At the time of this writing, I can state I know of others as well. This is not the first successful hacking attempt using the compromised SecureID technology. It certainly won’t be the last…

What concerns me most though, is that RSA has not been as forthwith in providing full disclosure about what was compromised and how vulnerable we are. RSA, if you’re listening, pretending like this didn’t happen and keeping it all secret, does not help things, it only makes them harder to track.

Even given all of the issues raised in this article, I don’t see anyone abandoning RSA or the SecureID product it sells. While most networks exchange token information over a secured and encrypted network path, this is only a false sense of security. My friend, and his organization can now attest to this.

If this can happen to a very secure network, employing some really talented security staff and products, it can happen to others as well. How far this will lead, and what sort of national secrets will be exposed now that such an attack has publically been proven to work, only time will tell.

Thus Quoth the Token Nevermore

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 19 Apr 2011 23:42:00 +0000

Traditional tokens are a dying breed

There is an oft used term that a recent event is a 'sign of the times'. In 2011 though, technology has dictated the ringing of the bell announcing the dead - at least in terms of the traditional token. Gone are the days of the telltale SecurID key fob dangling from your house keys. The recent hacking of RSA exposed data that could ultimately compromise the security of the widely used SecurID token. In their defense, it's not the first time tokens have been attacked; and yes, compromised. Tokens are, in fact, still around. So, why, you may ask, is this year different from previous ones?

Let us review:

During the 70's the 8 inch floppy was king

The 80's gave way to the 5 inch floppy disk & later, the 3.5 inch

The 90's took it a step further and gave us the CD, USB, and DVD for media alternatives

All hail, the Blu-ray of the new millennium

What this shows is that all things change. Nothing, especially where technology is concerned, is constant. Two factor authentication is no exception. While two factor authentication has seen improvements since the days of yore with complex and cumbersome challenge tokens, we're still relying on this antiquated technology in the majority of physical tokens today.

If you think that a solution is great only because it's stood the test of time longer than most, think again. Columbus thought that, and he ended up only 9,000 miles away from his goal. This sure isn't India...

The simple fact is there are several issues with physical tokens and the way they are, and continue to be, implemented. Some of these problems have been around for almost the entire 30 years we've been using them.

Here are a few examples:

Token deployment, even as simple as issuing a SecurID token to an employee, is tedious, and time consuming; sometimes even relying on snail mail which could take in excess of many months for distribution over an entire enterprise

Over 10% to 15% will be damaged, lost, or stolen every year

Barring all this, at best, a token's lifespan is 3 to 5 years

Users forget their tokens - even ones attached to key rings; Contractors lose track of which token is for which client, adding more confusion

Physical token systems require updates, maintenance, re-synchronization, and replacement

To every problem, a solution exists. How can we, as a global enterprise, still be secure, yet use technology that is already in place? The answer is simple - and you already own it.

Enter: The Mighty Cell Phone.

SMS has been in use for years, but with the global community reaching in excess of well over 5 billion devices currently in use, it seems most of us have overlooked one thing SMS is good for - that being to act as an authentication token. A passcode is sent to your Droid phone, for instance, thus eliminating the need for a physical token. SMS alone is not the answer, though. SMS does, in fact, have its pitfalls. The real answer lies in an ability to create similar (or even better, stronger) security that is already inherent in devices we already predominantly use. The unreliable nature of delays in messaging, cellular dead zones, or network issues with your provider are actual issues you may very well face. I am certain that those who wish to still cling to an antiquated technology, such as key fob based tokens, are sure to use as a rallying cry. At what point, though, do you stop bailing the sinking ship, and find a newer, better, stronger one?

Now Entering: MobilePASS.

MobilePASS by SafeNet, is a technology that still uses the same methodology of tokens, that being a two-factor authentication system. It simply does it in a better way. With MobilePASS, there's no additional hardware to lug around with you, the technology is easily deployed (and furthermore, managed), and the learning curve is non-existent. You do know how to download an app, don't you?

Strong encryption is still on the playing field. The tried and true two-factor authentication is still in the mix, yet the cumbersome, expensive, and dare I say, recently compromised hardware token, isn't.

"But what about my Windows Device?"

"There's an App for that".

In fact, not only is there an app for that old desktop of yours, but there's one for the iPhone, Blackberry, Windows Mobile, Android, Java 2ME, and even Out Of Band devices via SMS. Did I mention that it also covers Windows Server based platforms as well?

To log on to a secure network, from a laptop, PC or even an iPad (with the right software installed of course), users generate a One-Time Password (or OTP for short), via the MobilePASS app on their phone, and then enter this in the login screen thus creating a secure connection. Out of band delivery can also be granted via SMS or even email.

While MobilePASS by SafeNet is only one solution out there that utilizes cellular technology to end the need for the traditional token, this sort of solution is great for many reasons.

It is estimated that such a solution as moving to an SMS based method such as this can reduce the ongoing running costs of authentication means by over a whopping 40 to 60 percent! Lower cost, higher convenience, and utilizing technology already in place.

SafeNet is a global solutions partner of NWN Corporation. As such, NWN can leverage this partnership to assist our clients in lowering their bottom line, ensuring the security of their infrastructure, and delivering the best technology-based solutions currently available.

From ShmooCon - URL Enlargement

kfiscus@nwnit.com (Kevin Fiscus) — Thu, 03 Feb 2011 13:15:00 +0000

Well, ShmooCon started almost a week ago and it's about time to post something. First and foremost, all of the talks were outstanding and I'll probably wind up talking about most of them but I wanted to start with one that stuck out - URL Enlargement: Is it for You? by Daniel Crowley.

We all have seen URL shorteners. Many Twitter clients utilize them automatically. If you haven't seem one, check out www.tinyrul.com. Basically, you put a URL of any length in and you get a shortened version back out. For example, if I enter http://nwnsecurity.blogspot.com, I get back http://tinyurl.com/4v9e7w7. Now that's a savings of only 5 characters. That's not much but could help when using something like Twitter. If you are talking about longer URLs, the savings can be significant.

OK, that's convenient but what does that have to do with information security? Here's where the fun part begins. Check out this link - http://tinyurl.com/4g8gfpk No, really! I promise there's no malware there. In fact, it won't actually point to a web page. Just check out the URL that it resolves to. If you don't want to actually click on the like, check out http://www.longurlplease.com/ or http://www.longurl.org/.

OK, so we've established that URL shortening can be used to circumvent DLP systems. What else can it do? Well, a while back Billy Hoffman (a.k.a. Acidus) created a tool called TinyDisk. It is basically a file system that utilizes TinyURL (or other shortener) for storage. Now you can upload large data files to a stealth file system. That's cool. Unfortunately, I did some quick checking and couldn't find TinyDisk available for download. I'm sure it's out there but I couldn't find it with the 2 minutes of checking I did.

We've established that URL shortening can be used to establish covert channels but there are some other uses that I found to be particularly interesting.

When performing social engineering, will a user click on a link to http://www.somethingevil.com. Probably. But let's assume that the user is paying attention. They might think twice about clicking on somethingevil but what about clicking on http://tinyurl.com/o5h7wv. Now that's a completely different story. URL shorteners can be used to hide the javascript tags in a cross-site scripting attack or other URL parameters that might give away what you are really trying to do.

Also, when a user clicks on a shortened URL, their browser actually connects to the URL shortening service server and that server refers them to the final destination. If you are doing penetration testing and want to track who clicked on what, you can send different people URLs to the same site that were shortened by different URL shorteners. That way, tracking the referred will allow you to identify who clicked what.

One last point. What would happen if you encoded malware in base-64 and shortened that via a URL shortener? Hmmmmm.

Thanks Daniel for an excellent talk. Now off to the URL shortening.

Nessus Vulnerability XML Parser v8 and Cisco ACL Parser v0.05

kfiscus@nwnit.com (Kevin Fiscus) — Thu, 27 Jan 2011 13:45:00 +0000

It’s time for ShmooCon 2011, YEAH!!! This is my first time attending and I am very excited. I would like to release a few maintenance releases of my Nessus Vulnerability XML Parser v8 and Cisco ACL Parser v0.05.

Nessus Vulnerability XML Parser v8 – There was a bug in the creation of the TEXT File report generation. The issue was cause by a variable I called in a foreach loop, if the variable was not an array, but a hash the script would fail. No other changes were made.

The Cisco ACL Parser v0.05 – In the ASA a type of ACL used for the SSL Any-Connect Portal is called a WEBACL. There was a problem in the parsing of these ACL types. Also I changed the name of the output file to be the device hostname-output.csv “fw01-output.csv” instead of “hostname fw01-output.csv”.

These downloads can be found at Cody's blog at www.melcara.com.

I hope everyone enjoys the scripts and I hope to see you at ShmooCon.

Where did all the IP addresses go?

kfiscus@nwnit.com (Kevin Fiscus) — Thu, 20 Jan 2011 19:03:00 +0000

IANA owns the Internet. We'll, at least they manage who gets what IP addresses and guess what?!?!? We are running out. Check out Greg Ferro's posting at http://etherealmind.com/ipocalypse-what-next/ to get more of the scoop. The short story is that we are almost out of unallocated IP addresses requiring the move to IPv6. Now I don't have anything against IPv6 personally but I do know that a wholesale migration to a new IP addressing scheme will likely break one or two things and that's not something I'm looking forward to. That's why Greg's posting was interesting. He provided a link to an IANA web page that lists all of the IP address assignments (in terms of /8 networks). Curious, I checked it out.

I found a lot of what you'd expect - a bunch of /8 ranges assigned to ARIN, RIPE NCC, LACNIC, etc. That's not that interesting. I did find something that was, to me, more interesting. Over 20 /8 ranges were assigned to private companies such as GE, IBM, Xerox HP, DEC, Apple, MIT, Ford, Halliburton, Eli Lily, Bell North, Prudential Securities, Merck and duPont. Also, the Defense Information Systems Agency (DISA) has at least 4 that I counted. IANA has 2 allocated to themselves.

This got me thinking. Does any single company actually need over 16 million public IP addresses? I mean, in the age of NAT, PAT and RFC1918 what do you do with that many public networks. The 13 companies I listed above actually have over 200 million public IP addresses between them. To me, that's a little much.

Don't get me wrong. I'm not saying that these companies don't have a right to the IP addresses they registered. I'm not saying that these companies should be forced to give them up. I'm just wondering if DEC or Xerox even have 16 million computers, let alone the need for 16 million public addresses.

Wait! Stop! Hold on a minute! I'm thinking about this all wrong. Just think of the new security concerns there will be when we move to IPv6 in full. OK, so never mind what I was saying. The the IPv6 insanity begin!!!

Small Business Security 101 - Overview

kfiscus@nwnit.com (Kevin Fiscus) — Mon, 17 Jan 2011 21:42:00 +0000

Security is mandatory. This statement applies whether you are a fortune 50 global mega-corporation or a small business with 25 employees. As long as you rely on computers and connect to the Internet, you face computer-related risks. Actually, even if you don't connect to the Internet, those risks are present. Infection by a virus, worm or spyware, compromise by an external attacker, malicious insiders, careless employees and even hardware failures are threats that organization of all sizes must face. Large organizations have resources to deal with these threats but small and medium-sized business don't often that the money, technology, skills or experience necessary to affect reasonable levels of security. This is the first in a series of posting designed to provide an overview of how organizations with limited time, limited budget and limited personnel can achieve necessary security and, as necessary, regulatory compliance. The focus will be on "cost effective security" that introduces a minimum of operational overhead at a minimum of cost.

This first posting is going to address some of the myths about security and small to medium-sized businesses so let's get right down to business.

Myth 1: My business is too small to be targeted.

This often (but not exclusively) comes up when discussing security with organizations that have only a few employees. The thought is that "hackers" will target big companies and will ignore small ones. This seems to make sense. Big companies have more to steal, they have a larger footprint and they are far more well known. This, however, assumes that all attackers are intentionally targeting their victims - a fact that is not always true. There are plenty of "target of opportunity" attackers out there. Viruses and worms, for the most part, don't care who they infect and if an attacker finds your vulnerable system during random scanning of the Internet, they will be happy to compromise you. Making things worse, your users are browsing the Internet, taking advantage of wireless hot spots at airports, hotels and Starbucks and placing their laptops behind Best Buy purchased broadband routers with the default configuration when they work from home. All of these put your users and your organization at risk. Some studies have shown that a random computer gets compromised if placed unprotected on the Internet after 15 minutes. There are 96, 15-minute blocks per day, 672 per week and 34,944 per year. That's a lot of time for a compromise to happen.

Myth 2: I don't have anything of value so there's no reason I'd be compromised.

This statement simply highlights some misunderstandings or ignorance about what is considered valuable. To a bad buy hacker, any business is ripe with valuable targets. They want your processing power, Internet bandwidth and hard drive space for storing and distributing porn, stolen credit card numbers and other contraband. They also want your systems to use as Spam relays and bot-net zombies.

More personally, employees have access to bank accounts (corporate and personal), Facebook accounts and and even World of Warcraft. Recently, a "friend" on Facebook contacted me via Facebook IM stating that he got mugged outside his hotel in London and that he needed money to get home. His account had been compromised. I didn't send any money but how many people would have - particularly if it was a close friend. I'll also admit to the fact that I had a World of Warcraft account (yes I'm a nerd) that I stopped using for around a year or so get compromised. These things happen all the time.

Finally, bad guy hackers also want personal information such as names, addresses and social security numbers. Identity theft is real and can create havoc in the lives of the victims. And if you think that one of your employees suffering identity theft has nothing to do with you business, wait until it happens and see how their performance and productivity are affected.

Myth3: I have a firewall and anti-virus so I'm secure.

This myth was not limited to the SMB space until fairly recently. This was a common belief until significant, publicized breaches and comprehensive regulatory requirements swayed many large (and regulated) organizations over to a more comprehensive security program mentality. Unfortunately, it still rings true for many organizations. It is, in fact, quite false for a number of reasons. First, the fact is that anti-virus technology is not perfect. Every time testing is done, testers find that some AV products catch some malware and some miss. I've not seen any solid statistics but the number that rings fairly true is that the average AV product is between 60 and 70% effective. Anti-virus is not the answer (although it is part of the answer).

Firewalls are even more of a problem. In the past firewalls were set up to block all inbound traffic and that was good. Then organizations decided it would be a good thing to receive email and host web sites - and holes were created in the firewall. Then organizations went from web sites to mission critical web applications and more holes were created. Today, it is not uncommon to find firewalls with dozens or ports and protocols allowed in, each and every one of which represent a risk. Making things worse, most firewalls are configured to block (at least some) inbound access but to allow all outbound access. This means that users all allowed to establish outbound connections to any IP address on the Internet using any port - and the firewall will allow the responses back in. All an attacker need to do is trick one user into opening a file, click on a link or visit a malicious site and your firewall is now, effectively useless.

Myth 4: Small businesses have simple IT environments.

This isn't something that people often say but rather something that people often assume. Along with that assumption is that security is, as a result, easy. While this may be the case for some organizations, it is not uncommon for even fairly small organizations to have VoIP phone systems, virtualization, wireless, storage (either SAN or NAS), wide area network connections, VPN (site-to-site, IPSec and SSL) tunnels and Active Directory (or other LDAP). These are complex and sophisticated technologies that each bring with them a unique set of security concerns. Particularly in smaller organizations, knowledge of these security risks and the skills necessary to address them is not available making security all the more difficult.

Summary
We've discussed some of the myths about security for small to medium-sized businesses. Hopefully, it is fairly obvious that in the SMB space, while organizations may have fewer employees, they require every bit as sophisticated a security program as their larger counterparts. Consider the following:

A collections company that maintains a database with the personal information of over 11 million people including, in some cases, credit card and bank account data
A private equity fund company that manages over $3 billion in assets
A web application development company that focuses on providing health care data to pharmaceutical companies
A business that provides data center services to credit unions

All of these are real business that have two things in common. They all have sophisticated security needs and they all have less than 5o employees.

The question faced by these organzations, and by may others is how can we achieve these security goals with minimal staff, minimal budget and minimal resources. That is the question that will be answered by upcoming postings. In future postings we will discuss each of a variety of security topics and how they can be addressed by the average SMB. We'll be discussing the following:

VoIP – network design, 802.1x & NAC
IDS/IPS
Endpoint - anti-malware, encryption, application control (blacklisting/whitelisting), integrity verification
Smart phones
Network design
Web app vulnerability scanning, web app firewall
Firewalls and VPN
Authentication – user provisioning, good passwords, tokens, rights assignment, admin rights
SEIM/Central Monitoring
Network Device Hardening
Active Directory – design, GPO
Vulnerability Scanning, Patch Management
Virtualization
Wireless network design, authentication/802.1x/WPA2, etc.
Wireless client attacks, bluetooth, keyboards, etc.
Wireless IDS
Data Leakage Protection
Media Sanitization
Data Classification, Risk Assessment, Security Awareness, Acceptable Use, Incident Response, Change Control
Physical Security
Regulatory Compliance, Policies

For each, we will discuss a typical SMB environment, the risks, the controls and how best to accomplish cost-effective security. Hope to see you there.

Auditing Access Control Lists

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 04 Jan 2011 17:35:00 +0000

During assessments NWN regularly reviews the configurations of many different types of systems and devices ranging from firewalls, routers, switches and servers. Many of these devices, particularly routers, switches and firewalls, have Access Control Lists or ACLs that provide critical security controls. Unfortunately, the process of auditing these ACLs can sometimes be very time consuming. Until now there has not been an open source or free tool to assist with this type of auditing. Fortunately, member of the NWN STAR team, Cody Dumont, has created a tool - the ACL2CSV parser.

ACL2CSV parser is a PERL script, which reads Cisco router, switch, and firewall (PIX, and ASA) configuration files that have been exported from the device in flat text format. It parses the ACLS and object groups (PIX and ASA only) and generates an easy to understand CSV file. This file can them be opened in Microsoft Excel or other spreadsheet software for easy viewing or additional analysis. The ACL2CSV tool expands all object groups and places them into the correct location as if the ACL did not use object groups. The object group expansion works for all object group types. The ACL2CSV parser is extremely fast and easy to use.

For instructions on the use of ACL2CSV, visit Cody’s personal blog at http://www.melcara.com and select the link for Cisco ACL2CSV parser. If PERL is not installed on your system, you will need to do so. PERL can be found at http://www.activestate.com or http://www.perl.com. Once PERL is installed no additional modules are needed. The script assumes PERL is installed at “/usr/bin/perl”, and only uses the “strict” and “Getopt::Std” modules. After the script is copied into a folder found in your system path, you should also modify the permissions to allow the script to be executable. On a Unix, Linux or Mac computer, this can be accomplished via the chmod command.

Once the script is executed and installed, you can run the script. The script requires a file name as an argument, so if you simply type ./acl2csv.pl you will receive the following message:

The command requires a File Name as a command line argument
acl2csv.pl c:\old_pix_config.txt

To check the version, add the “-v” or “v” as the command line argument.
ACL Parser for Cisco IOS, PIX & ASA
DEVELOPED AND OWNED BY Cody Dumont - NWN Security Testing Assessment and Response (STAR)
Licensed to Planet Earth.
I used some code for another tool of this type from James Bly AT mangeek.com
http://mangeek.com/portfolio/pixparser.html
Also Anthony contributed by doing some testing and verification
Version Number 0.04 - Dec 2010
"For Questions Please Contact Cody Dumont - CDumont@nwnit.com "

To run the script, use the following command:
/foo/bar/acl2csv.pl fw_config.txt

Once the script is finished, a completion message will be displayed. There should be no other messages. In the event you receive a PERL array or HASH error message, this means that Cody did not do enough testing. If you get such an error, follow the PERL debugging steps or contact Cody at CDumont@nwnit.com and he’ll be happy to fix the error.
The output of the script will look something like the following.

NAME,LINE,TYPE,FUNCTION,PROTOCOL,SOURCE NET,SOURCE_PORT,DEST NET,DEST PORT,TIME,INACTIVE,LOG,REMARK,ORIGINAL
test441,1,extended,permit,tcp,any,,any,eq 44 ,,,,,access-list test441 extended permit tcp any any eq 44
test442,1,extended,permit,tcp,any,eq 44,any,eq 44 ,,,,,access-list test442 extended permit tcp any eq 44 any eq 44
test443,1,extended,permit,tcp,any,eq 44,any, ,,,,,access-list test443 extended permit tcp any eq 44 any

The definitions of each field are listed below.
NAME – The name of the ACL
LINE – The line in sequential order of the ACL. Please note if the ACL uses Object-Groups, then each Object-Group will have the same index number. The idea is to provide the user with same output of the “show access-lists” command. Please note “REMARK” ACL entries are not counted in this test.
TYPE – This is the TYPE of ACL, the options are standard, extended, webtype.
FUNCTION – The “permit” or “deny” entry.
PROTOCOL – The Layer 3 protocol controlled by the ACL entry.
SOURCE NET – The source network and subnet mask. If the entry is a host, then “host” will be displayed. However if “255.255.255.255” is found in the ACL entry, then “255.255.255.255” will be displayed. The script does not check the validly of the mask, and the assumption is the config is a direct output from “show running-configuration” or “show startup-configuration”.
SOURCE_PORT – If a source port is defined, then the source port is displayed. If no source port is defined this field will be empty.
DEST NET – Same as the SOURCE NET, but the destination section of the ACL entry is displayed.
DEST PORT - Same as the SOURCE PORT part of the ACL, but the destination section of the ACL entry is displayed.
TIME – ACLs can be time sensitive using the “time-range” command. If a time-range is defined, the name of the “time-range” is displayed, however the details of the “time-range” are not displayed. This might be added in a future release.
INACTIVE – If an ACL entry is listed as “INACTIVE”, the entry is left in the configuration, but is not an active rule. Other parsing tools often ignore this, but if “YES” is found in this field then the ACL enter is not an active rule. If the field is empty then the ACL entry is an active rule.
LOG – If log settings are configured, the settings are displayed in this cell. Two examples are “interval 5” and “notifications”.
REMARK – The “REMARK” section is a little harder to deal with. The configuration files currently put the “REMARK” in an ACL entry just above the ACL entry the “REMARK” is connected to. So in the parsing of the ACL, the script will check to see if the preceding entry was a remark, if so this field will be filled with “REMARK” statement. However some ACL’s might have more than one line as a remark, the script will not detect this case. The script will only detect the “REMARK” in the preceding line only.
ORIGINAL – The original ACL entry unmodified. The “REMARK” ACL entries are not displayed.

When the script is finished, open the file using any spreadsheet application. Then you can create filters, freeze panes, etc. You could also import the newly created ACL file into a database.

This tool can save a network administrator, security professional or auditor a lot of time sorting through ACLs. We at NWN STAR hope the security community will find this tool useful and will enhance the overall security of your information system.

The Role Network Devices Play in Defense in Depth

kfiscus@nwnit.com (Kevin Fiscus) — Fri, 09 Jul 2010 20:31:00 +0000

Over the past many years the security industry has coined the phrase “Defense In Depth”. While many Pundants have stated that defense in depth is dead, what I believe the point the Pundants are really trying to get across is administrators are not practicing defense in depth. A spoken or written language, when people no longer use it, is in-fact a dead language. However, with defense in depth, there are still some security professionals that believe defense in depth has not seen it’s true implementation. This is mainly because IT professionals in general are not identifying the roles each network device will play in a defense in depth program.

Because of the this, NWN STAR will help provide a foundation to which IT professionals can better understand some of the roles network devices can play in a defense in depth program. As part of the foundation NWN STAR will identify some of the possible roles an IT professional may encounter or identify in their own network. Then each month NWN STAR will publish an article about the various roles, helping to extend the knowledge and practical deployment of an effective defense in depth program.

The Roles of Network Devices

Due to the nature of network devices requiring an always up status and complexity sometimes surrounding networking equipment, IT professionals usually take a “If it is not broke, don’t fix it” approach. Meaning network devices forgo software upgrades and configuration hardening. However, if the IT professional were able to identify the various roles each device in the network portrayed, then possibly a better plan or approach could be taken to patching and hardening of network systems.

As I see it, there are 2 fundamental types of network equipment, a layer 3 packet switch (a.k.a. a ROUTER), and a layer 2 packet switch (a.k.a switch). Now I know most of you are saying, what about firewalls, IDS/IPS, wireless controllers and so on. If you were to step back, what is a firewall, but a very smart router. What is a wireless controller, but a 802.11a/b/g/n switch. Even an IPS/IDS, depending on the deployment, can be a layer 2 bridging device, i.e a switch, or a layer 3 forwarding device, i.e. a router. So with diving into to all the possibilities up front, if we focus on the core functions of a router and switch, we can identify the roles portrayed by networking devices.

As I was in the Marines for many years in the 1990’s, the analogies I will make will be similar to Marine Infantry. The switch is the initial point of access, so it could be referred to as the front line in our defense perimeter, a.k.a. a Marine Rifle Company. Some of the roles on the front line are the infantry, medics, fire and support, and finally the artillery.

The Switch

In the role of the infantry, the switch will engage with the endpoint and make the first decision on if the node allowed. The switch will monitor the switch traffic and decide if the correct system is connected and if so is the traffic from that system the correct kind.

Then as the medic, the switch must be able to detect injuries to the network and respond accordingly. The medic must also be able to anticipate where problems are going to arise and attempt to divert the injury. An example of this is Navy Corpsman would always make sure the Marines drank lots of water and wore sunscreen. These are two fairly low-tech tasks, yet if Marines don’t have water or are sun burned very badly, they can’t fight. The medic functions of the switch would be similar to a BPDU filter or broadcast storm monitor, and both functions are low-tech and easily configured, they can reduce the threat of tools which can flood the cam table in switch turning it into a HUB.

The fire and support aspect will be the Weapons platoon in a rifle company. The Weapons platoon has heavy machine guns, like the M-60 (Yes I was in when Marines still carried M-60’s) and the 40mm mortars. These systems would be able to attack a larger number of enemy combatants, but remain extremely portable. The switches must be able to act in the same manner, using 802.1x or port-security, a switch can be extremely effective against blocking unauthorized users from gaining access to the network. Additionally using STP port security or private VLAN’s the switch can also provide a greater level of segmentation.

The Router

If the switch is the Marine rifle company, the router and firewalls could be seen as the Marine Expeditionary Unit (MEU). The MEU has an Infantry Battalion, Armored Assault Company, Tank Company, Artillery Company, and an Air Support Wing. All the big fire support needed to support a highly mobile and deadly Infantry Marine. That said, what is the role the router is going to play again, you ask? The answer is quite simple, A BIG role.

A function of the Air Wing and Armored Assault is transportation, hopefully a secure mode of transportation. The role of the router is to secure the transport from one end point to another end point. In doing this, the router can deploy different forms of IPSec, routing table segmentation, and varying levels of packet inspection and filtering.

By packet inspection, a router can now do a deep inspection of packet headers, using Network Based Application Recognition (NBAR), Zone Based Firewall (ZBF), and Quality of Service (QoS). These services can detect flaws in a packet and allow or deny the packet as needed. While the IT professional will not configure all of these features, they might combine the varying features at different levels. For example, when configuring ZBF, the class-maps used to identify traffic could identify traffic using DSCP, IP Pref, or CoS, just to name a few. While the TOS bits, used in the DSCP and IP Pref, can be set using NBAR. Then once the traffic is identified, the traffic can be permitted, denied, and modified in some way to reduce the overall threat. These features can be used to reduce the impact of a DDoS attack, deny packets over a certain size, or throttle traffic down to a limiting factor.

Similar to artillery, the Router can use NULL routes to totally block certain threats based on black lists. A great set of firewall rules and snort rules can be found at http://www.emergingthreats.net. The firewall rules can be changed into NULL route statements, and then advertised via an Interior Gateway Protocol (IGP), to a central router, and then forwarded to a NULL interface, a.k.a. the BIT BUCKET. This is just one way the router can act like artillery and block large blanketing attacks across a wide area.

For a more precise targeted attack against hard targets, the infantry will call in Tanks or Cobra Attack Helicopters. These are great, fast, and super effective. In a similar way, a router can make smaller, more targeted routing rules called Policy Based Routing (PBR). PBR can target traffic entering an interface and forcing traffic to move in a special direction based on a wide number of layer 3 and layer 4 headers.

The Defense in Depth Plan

As with any Marine operation, the Commander gets a set of orders, then formats a plan. So the IT Professional will get a set of business requirements and will format a strategy for supporting these requirements. When the commander first begins his planning, he/she goes to an overlay map and evaluates the current state of the battlefield. So should the IT professional map out the network, even if the map is a high level functional map. Identify critical systems or potential targets, then do a threat assessment. Who is going to attack the system, why would they want to attack the system, and what methods will they use. Then format a plan to defend against those attacks.

For defense in depth to work, the IT Professional must do defense in depth. Look at each layer of access in the network. Some examples are the end-point, switch, wireless, routers, servers, firewalls, VPN termination, and intrusion identification systems (IDS, IPS, SEIM, etc). Once all of these layers can be identified, create your plan. But don’t forget about overwhelming power of network devices, much like the human brain, IT Professionals only use 10% of the features found in networking devices.

Configuration Examples

I also have a blog (www.melcara.com), where I post configuration builders. These are spreadsheet tools used to complete a hardened configuration and create a template easily followed by users with differing skill sets. So feel free to check out the config builders.

SMB Security - The Forgotten Target

kfiscus@nwnit.com (Kevin Fiscus) — Thu, 01 Jul 2010 15:49:00 +0000

I've performed security assessments for organizations that have thousands or employees and for organizations that could fit every member of the company on a city bus. Some of these assessments were done for very "high-tech" organizations while others barely use computers. Logic would dictate that high-tech large, enterprise-class organizations make the biggest targets and that is probably true but it is not the entire picture. Big organizations make big targets but they also can bring to bear big resources. Even having a single person with the correct skill set focused on security can make a huge difference in the effectiveness of an organization's security program. Small or mid-sized businesses (SMB), on the other hand, are often under-staffed with respect to IT in general and have no security expertise whatsoever. This creates a big problem because while they may know how to deploy a firewall, they don't fully understand the threats and thus have minimal or even non-existent security programs.

Now, you could say that small organizations aren't really big targets because they don't have anything that the bad guys would want. After all, they are small and/or not particularly technical. Well, that's not always the case.

I recently did work for a couple of collections companies. Both were small (with less than 50 employees) but each maintained a database with millions of records containing personal information (can you say identity theft) and even credit card and bank account information. Another customer with less than 50 employees stored significant amounts of sensitive information about pharmaceuticals. Still another sub-50 person company manages over $3 billion in assets. If you were a bad guy hacker, would these targets be interesting to you?

I can wonder and suppose all day long but this is all theory, right? WRONG! A recent article on the Dark Reading site (http://www.darkreading.com/smb-security/security/management/showArticle.jhtml?articleID=225701975&cid=RSSfeed) told the story of a Demolition firm in California that suffered a computer breach that resulted in hackers transferring almost a half a million dollars from the firm's accounts to various accounts worldwide. This happened because an employee clicked on a link in an email that directed them to a malicious web site. The site leverages a vulnerability in Internet Explorer to load a Trojan horse on the employees system. From there the attackers collected information about the company and its finances. This allowed the hackers to conduct 27 transactions involving $447,000.

This example is news for the simple fact that it involved actual theft. The only reason the crime was detected was that funds were transferred. If the attackers were after credit card numbers, personal information or even a place to store contraband child pornography, they might never have been discovered. This should make us wonder.....how many SMBs have already been hacked and just don't know about it? Of equal importance, what can small to medium-sized businesses do to promote security if they have a limited staff, limited resources and limited expertise. Oddly enough, I think for most businesses, the answer is simple. Following a few basic steps, organizations of virtually any size can create an environment that is resistant to attack.

Step 1: Patch your technology. This means patching not only Microsoft Operating systems but non-Microsoft operating systems, Microsoft applications, non-Microsoft applications (e.g. Adobe, etc.) and network devices.
Step 2: Baseline your environment. Understanding what your environment looks like when it is running normally is critical if you are going to identify abnormal or malicious activity.
Step 3: Run anti-virus software and keep it updated. AV is not a silver bullet but it can help. Running AV won't stop all threats but stopping 60% of the malware is better than falling victim to all of it.
Step 4: Regularly test your environment using a network vulnerability scanner such as Nessus. This allows you to identify problems before the bad guys can. Vulnerability scanning should be run, at a minimum, weekly and scans should be "credentialled" if possible. Any vulnerabilities that are discovered should be addressed in a timely manner.
Step 5: Use mail and web filtering technologies. As shown in the story about the demolitions company, hackers today target end users via their mail clients and web browsers. Leveraging a product or service that scans incoming and outgoing email and web traffic for harmful content reduces the size of these attack vectors and should be considered a mandatory part of any security program.

These steps won't make organizations 100% secure. These steps shouldn't be considered a total security solution. They should be considered to be a good start. They will make any environment more resistant to attack and will allow organizations to more easily identify problems and thus are a decent starting point. The best part - taking these steps can generally be done with a very limited IT staff, minimal security expertise and in a way where the costs can scale to fit virtually any environment.

Remember, from a hackers perspective size does not matter. Smaller organizations represent juicy targets because the rewards can be great and the risk of discovery is small. Change the game and take steps to make your environment more secure. Take control.

Security Fundimentals

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 08 Dec 2009 15:38:00 +0000

It's been a while. I haven't posted anything in over a month which is actually a good thing. Things have been very busy and seem to be getting more so. I've just come off doing a series of security assessments for a variety of organizations and have come to a realization - the information security industry is broken.

Now before you get all upset and start bombarding me with hate mail, let me explain. Security professionals often talk about being proactive. It is better to put security in place before something bad happens than after. I agree entirely. While we say this however, we spend a huge portion of our time encouraging reactive thinking. Even when we are being proactive, we are being reactive. That might not seem to make sense but think about this.

In my home office I have a collection of computer security books. Some are focused on various certifications so I'll ignore those for the purpose of this discussion. Of the remaining, I count 25 books. (No, that's not all my books but most are in my office at work). Of these 25 books, 23 are focused, in one way or another, on securing things by understanding how they can be compromised with a few focused exclusively on discussing how to compromise. Only two of the 25 (that's 8%) look at security from an exploit or attack independent perspective. One of these focuses on establishing metrics for security and the other on designing security around detection rather than protection. Let's take this further. Almost all of the news groups and email lists I am a part of focus on the newest vulnerabilities, attacks or victims. Most of the podcasts I look at take about penetration testing, computer forensics or social engineering. As I see it, we spend the vast majority of our time learning how bad stuff could happen then reacting to that knowledge. Hopefully, we are proactively reacting but we are reacting none the less. This creates a situation where "good" security can only be achieved by security experts who fully understand the threat landscape. Unfortunately, not all organizations have access to such people.

The other side of the security industry are the vendors of security technology. They often represent the ultimate in proactive action. They want to sell their products and rightly so. However, in doing so, they are often forced into a situation where they have the solution to a problem that may not exist (at least for any given customer) thus they often try to show the customer why they have a problem and then how "technology A" solves it. This creates a situation where security product implementation may not really match up with actual risk. This means security spend is not in line with risk reduction and potentially leaves areas of significant risk unmitigated.

If the security industry has three sides, the third would be regulation. In my opinion, most security regulations have combined the worst aspects of reactive security with a misalignment of controls vs. risk. Some regulatory writes a document that states, to varying degrees of detail, the controls that organizations need to put in place. Affected organizations then react to the regulation by implementing the mandated controls and completing their compliance checklist. They effectively replace security with compliance assuming they are one and the same. Unfortunately, they are not. The result, excessive spend that may not be in line with actual risk and that doesn't actually accomplish the security goals of the regulation.

So what are we missing? In my opinion, what we are missing is a set of basic, fundamental security measures that are easily understood, that can be implemented in virtually every environment and that don't require reading hundreds or thousands of pages of highly technical documentation to understand. Furthermore, these measures cannot be tied to specific technologies. Basically, I'm thinking of some basic uses of common technology and some operational processes that "everyone" can use. Some things that come to mind are:

- Segmenting the network based on business requirements
- Applying access controls to network segments
- Ingress AND egress filtering on firewalls
- Logging ALLOWED inbound & BLOCKED outbound firewall traffic
- Basic data classification measures
- Security incorporated into change control procedures
- Implementation of basic hardening standards for core technologies

The list can get longer but hopefully you get the idea. By putting together some basic guidance, the average IT person who also must deal with security has a good place to start. They can create a technical and operational environment that supports security by design rather than having to try to layer security on top of in inherently insecure environment using the vendor or regulation-recommended technology of the day.

Thoughts?

Where Compliance Went Wrong

kfiscus@nwnit.com (Kevin Fiscus) — Fri, 02 Oct 2009 15:11:00 +0000

Earlier this week I had the opportunity to give a presentation on the new Massachusetts Privacy law or 201 CMR 17. The goal of the presentation was to give attendees a detailed understanding of what the law required, penalties for non-compliance and a roadmap for cost-effective compliance. The presentation itself however, is not the focus of this discussion. Rather, a question asked by an attendee is. During the course of the presentation, one participant asked "if I'm 100% compliment with 201 CRM 17, will I still be fined if there's a breach?" My short answer at the time was "Yes" (although it is still a little unclear how that fine will be determined. The question however, got me thinking.

With regulations like Sarbanes-Oxley, GLBA and the HIPAA Security Standards the focus is on input. What do I mean by that? Well, many of the various laws define that you must implement controls to make sure something bad doesn't happen. In some cases, organizations are left to determine the specifics of the controls while in other, the control requirements are relatively detailed. They key is that these regulations tell organizations what they must do to stop bad things from occurring. I'm referring to this as "input" focus because the regulations focus on what needs to go into a security program.

The converse to this is an "output" focused law. California Senate Bill 1386, the first well known state privacy law, is an example of this. The law is very light on requiring organizations to do anything as far as implementing controls. It is very short and to the point. If you suffer a security breach that results in the disclosure of personal information, bad things will happen to you. The only "control" really mentioned is encryption and even that is not required. This approach allows organizations to perform their own risk assessment and implement the controls they feel are necessary to reduce risk to an acceptable level.

While there is probably no perfect solution, the question asked during my recent presentation highlighted the major flaw in "input" focused regulations. With this type of regulation, compliance does not equal security. Recent security breaches where the organization was previously identified as "compliant" highlight this problem. Unfortunately, the response to these events was to blame the auditor. I watched numerous discussions where people made the case that auditors should be held responsible should a "compliant" organization suffer a breach. I'm sorry but that is just plain stupid. That removes the decision making responsibility from the organization and put it in the hands of a third party who will do what is in their best interests. That means, to a large degree, massive risk avoidance rather than reasonable risk management. Risk avoidance then results in significant increases in cost that are way out of line. Ask yourself this, if you were told that you had to audit another company for security and if they suffered a breach, you would be held responsible, what would you do?

Another problem with "input" focused regulation is that it forces organizations to focus on the specific regulation requirements rather than on good overall security. In response, many organizations create checklists for compliance. They will do the minimum to check off each item in the checklist and nothing more. Suffice to say that this is not the best approach to security either. In effect, it gives the attacker a list of exactly what you are doing and what you are not doing to secure sensitive data. It's no wonder "compliant" organizations often suffer security breaches.

Back to the questions I was asked. If I'm 100% compliment with 201 CRM 17, I will still be fined if there's a breach? To me, that sounds like a significant amount of input focus. I'll restate the question. If I complete everything on the 201 CMR 17 checklist, do I really need to worry about actually protecting personal information? The same question can be asked about other regulations.

Now, let's look at output focused laws like many of the state privacy rules. They simply say that organizations are requited to protect personal information and if they don't, bad things happen. Generally speaking, there are no requirements for periodic audit and there are no checklists for compliance. If you protect personal information, you win. If you fail to protect personal information, you suffer the consequences.

It seems obvious to me that the current method of checkbox security doesn't work well. All it has done is increase IT spend and increase costs of external audit without any real gains in security. Perhaps more focus on achieving security goals and objectives and less focus on a bunch of predefined controls might be a good idea.

Snow Leopard Install Knightmare

kfiscus@nwnit.com (Kevin Fiscus) — Wed, 02 Sep 2009 13:16:00 +0000

Well, it happened. On Friday of last week I ran out to the Apple store and purchased Snow Leopard. More specifically, I purchased the Snow Leopard Box Set with iLife '09 and iWork '09. That was one lucky purchase but more on that later.

After a bite to eat I introduced my MacBook Pro to the Snow Leopard disk. They seemed to get along well for the first minute or two. Then the Snow Leopard installation routine asked me where it should install Snow Leopard. There is only one problem. NONE of my disks including the default "Macintosh HD" were identified as "bootable" and thus Snow Leopard woudn't install. No options, no nothin'. I then went to my favorite troubleshooting tool - Google. I discovered that others were having the same problem but there was no definitive solution. Some people said it had to do with PGP Desktop so I removed PGP Desktop. That didn't work. Some said there was a backup file in the root directory of the hard drive that would cause the problem but that file didn't exist. I tried booting from the install disk. Fail! So what's next? Call Apple.

I got tech support on the line and told them what was going on and what I did. They politely asked me if they could put me on hold and then did so. They came back and had me boot from the install disk and attempt to repair the disk volume. No problems were detected (I had already checked but humored them nonetheless). They put me on hold again and came back with the secret, fine-print, little known fact. The upgrade from Leopard to Snow Leopard works for computers that had Leopard originally installed but not for computers that originally had Tiger. I was told that I needed to buy the full version and not the upgrade. I asked how much that would cost. I then mentioned that I was a little upset as I had already dropped $170 on the "box set". At this time I was somewhat relieved as we had found the solution. At the same time I was a little ticked off because I was going to have to drop even more money on this upgrade. The tech support guy heard me mention the box set and put me on hold again. It turns out that the box set is the full version and thus I had the right product and it still wouldn't install. The brought in another tech support guy to help. This one was a product specialist.

We did another troubleshooting dance, going round and round. We tried to install Leopard on top of Leopard with no success. OK, so it's not a Snow Leopard problem but something wrong with my laptop. We checked the partition information and found all was as it should be. We checked a few other settings associated with the disk and still found no problems. What was the final option? We had to re-partition the hard drive. Yep, that's right. We blew out the whole thing and installed from scratch. I guess it's a good thing that I purchased the "box set".

After a clean install I was able to use my Time Machine backups (completed earlier in the day) to restore my profile, applications, etc. After using the Mac for a couple of days now, everything seems to be working well. I'm still figuring out all the in's and out's of the new Exchange integration but otherwise, everything is working.

Total time to install Snow Leopard including restoring from Time Machine and installing iWork and iLife upgrades - about 6 hours.

Massachusetts Privacy Law - Why EVERYONE should care

kfiscus@nwnit.com (Kevin Fiscus) — Thu, 09 Jul 2009 19:40:00 +0000

The Massachusetts Privacy Law (AKA 201 CMR 17.00) is on the horizon with the deadline for compliance is 6 months away. While many states have instituted privacy laws, this one is a game changer and affects companies beyond those geographically located in Massachusetts. Why is that? I'm glad you asked. Here are some things you need to know:

Q: Who does the law apply to?
The law applies to any person or business who owns, licenses, stores or maintains personal information about a resident of the Commonwealth of Massachusetts. Keep in mind, this is not limited to Massachusetts-based companies. Technically, a company based on California that has personal information about a Massachusetts resident must comply.

Q: What is the purpose of the law?
The law establishes minimum standards for safeguarding personal information in both paper and electronic form.

Q: When does the law go into effect?
Organizations must be in full compliance with the law on or before January 1, 2010.

Q: What is “personal information”?
The law defines personal information as a first and last name or a first initial and last name in combination with any of the following:
- Social security number
- Driver’s license number
- State-issued identification card number
- Financial account number
- Credit or debit card number (with our without access code or PIN)

Q: What does this law require?
The law places a number of requirements on every person or organization “covered entities” that owns, licenses, stores or maintains personal information about a resident of the Commonwealth of Massachusetts. To comply with this law, covered entities must:

- Develop, implement, maintain and monitor a comprehensive, written information security program. Such a program must contain administrative, technical and physical safeguards to ensure the confidentiality of personal information.

- Designate one or more employees to maintain the comprehensive information security program.

- Identify and assess foreseeable internal and external risks

- Evaluate and seek to improve the effectiveness of existing safeguards on an ongoing basis including; (1) Performing ongoing employee (including temporary and contract employee) training, (2) Verifying employee compliance and (3) Implementing a means for detecting and preventing security system failures

- Develop security policies

- Impose disciplinary measures for violations of security program rules

- Prevent terminated employees from accessing records containing personal information.

- Take all reasonable steps to verify that any third-party service provider with access to personal information will protect it

- Limit the amount of personal information collection to the greatest extent possible, limiting the time such information is retained and limiting access to that information as possible.

- Identify paper, electronic and other records, computing systems, storage media (incl. laptops and portable devices) used to store personal information.

- Implement restrictions to physical access to personal information records including a written procedure that defines the manner in which physical access is restricted.

- Perform regular monitoring to ensure that the security program is operating in the manner designed.

- Review the scope of security measures at least annually or whenever there is a significant change in business practices.

- Develop an incident response plan.

- Implement reasonably strong user authentication

- Implement access controls to restrict access to personal information

- Encrypt all transmitted records or files containing personal information that will travel across public or wireless networks

- Perform monitoring of systems for unauthorized use of or access to personal information

- Encryption of all personal information stored on laptops or other portable devices

- Provide firewall protection, up-to-date patching and up-to-date anti-malware signatures of all systems containing personal information that are connected to the Internet

- Conduct regular education and training of employees

Q: Wow, that's a long list. Can you summarize all of that?
Sure. Basically organizations need to:
- Perform an assessment to identify internal and external risks.
- Develop a formal, documented information security program based on the results of the risk assessment.
- Document the program via a suite of information security policies.
- Utilized strong authentication methods and strict access controls
- Ensure effective patch and configuration management
- Implement physical access controls
- Incorporate risk assessment into daily operations
- Perform regular internal audits to verify compliance
- Use secure, encrypted communications protocols
- Perform security monitoring and maintain an incident response program

Q: What can be done to comply with this law? What are the next steps?
First, and most importantly, it is critical to perform of an initial compliance/risk assessment. During such a project you would ideally accomplish two simultaneous goals; assess your current security posture to identify any compliance gaps and perform the initial risk assessment dictated by 201 CMR 17.00.

Based on the outcome of the assessment, there are a number of initiatives that will commonly be required:
- Development of information security policies
- Development of an internal audit program
- Performance of periodic security reviews
- Penetration testing & web application security testing
- Development of an incident response plan
- Configuration of technologies to provide encrypted communications protocols

One final thought. Keep in mind that the law specifically states that compliance will factor the size of the business, the resources available, the amount of stored data and the need for confidentiality of both customer and employee information. Because of this, our recommendations to any customer will only be based on the outcome of a risk assessment.

All of that said, if you are a company that "does business" in the Commonwealth of Massachusetts, you should take a hard look at your security posture and your level of compliance with the requirements of this law. Failure to do so could mean failure to comply with the law and that could open you up to legal liability risks, public relations problems and a host of other nastiness that nobody wants.

10 Most Dangerous Infosec Mistakes

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 07 Jul 2009 15:04:00 +0000

I have had the opportunity over the past couple of months to perform security assessments for a bunch of different organizations including hospitals, universities, manufacturing companies and real estate companies. While the results of these assessments are as unique as the companies for which they were performed, I have noticed some common trends. I thought it would be interesting to try to condence them down into a "top 10" list.

1. Ignoring web application security
2. Poor patch management (expecially internal systems and workstations)
3. Lack of a risk basis to security decisions (or making decisions based on fear uncertainty and doubt)
4. Relying solely on the perimeter for protection
5. Ignoring the operational aspects of security (e.g. IDS tuning, maintenance, incident response, etc.)
6. Poor password management (Is 8 characters with an upper, lower, numeric and special char. changed every 90 days really strong?)
7. Ignoring detection - focusing solely on attempts at protection
8. Failing to account for users (who will always find a way to break security)
9. Failing to implement a DMZ, allowing external access directly to the internal network
10. Focusing exclusively on completing regulatory "checkboxes" - compliance does not equal security

As you read this list, ask yourself, is this you? Have you adequately tested the security of your web applications? Have you conducted a web application penetration test that is complete and comprehensive? If not, how do you now your web applications are secure?

What about patch management? Cross site scripting, email-based links and malicious Javascript make your end users direct targets. If an end user workstation gets compromised the attacker can continue their attacks from within your network perimeter. What will they be able to do? Are you expecting your firewall and other perimeter devices to provide protection in this scenario? Is your network resistant to attack from within? Have you implemented proper network segmentation and implemented strong access controls between internal segments?

If an attacker were to get in, are you ready? Do you have sufficient detective capabilities to identify the attack in its early stages or will you wait until a partner, customer or other third party notifies you of the breach? If you notice the attack, do you have a formal, approved incident response plan in place? What are your incident response goals? Do you want to conduct a forensics investigation or simply get the system back up and running? What about notifying law enforcement?

What about regulatory compliance and risk? Does your security plan focus exclusively on meeting regulatory compliance requirements or are you making security decisions based on assessed risk? One way will cost a lot and achieve little with respect to actual risk reduction. The other reduces costs, achieves compliance in the face of a dynamic regulatory landscape and reduces business risk to an acceptable level. Which are you doing.

I have put together a podcast that covers each of the items on this top 10 list so if you are interested, give it a listen. If you want to discuss this in more detail, please reach out to me. Also, don't forget to follow me on twitter - http://www.twitter.com/nwnsecurity - and on facebook (kevinfiscus).

Take care!

Kevin

Cisco Security Advisories

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 30 Jun 2009 15:16:00 +0000

Wow! Late June saw a lot of action on the Cisco front when it comes to security advisories. Over the course of 3 days, June 24th, 25th and 26th, there were 8 updates. Of these, 2 were new while the other 8 were updates to advisories published on March 25th of this year. The two new advisories were focused on vulnerabilities in Cisco's physcial security technologies.

Cisco Physical Access Gateway
The first is a denial of service vulnerability in the Cisco Physical Access Gateway product. An attacker sending specially crafted packets can create a memory leak. If this happens, connected door hardware (card readers, locks, etc.) may not function causing the door to remain locked or to remain open. Products affected include software versions prior to 1.1. There are no workarounds however free software updates are available. Additional detail about this vulnerability can be found at - http://www.cisco.com/warp/public/707/cisco-sa-20090624-gateway.shtml

As a penetration tester, physical security is paramount and the closer I can get to your critical assets, the better. If I can open your locked doors using some crafted packets, I can access your facility. At a minimum, I can plug in to your network and that's bad. The flip side of this is also bad. If I can cause your doors to lock and stay locked, I can stop security guards from making their rounds and stop people from getting to work. If these locks are used for egress as well as ingress, there may also be life safety issues as well.

Cisco Video Surveillance Stream Manager
The next advisory relates to the Cisco Video Surveillance Stream Manager firmware for the Cisco Video Surveillance Services Platforms and Cisco Video Surveillance Integrated Services Platforms. A crafted packed can cause a reboot of the system. There is also a vulnerability in the Cisco Video Surveillance 2500 Series IP Camera that could allow an authenticated user to view any file on a vulnerable camera. Cisco has released free software to remediate these vulnerabilities. Detailed information can be found at - http://www.cisco.com/warp/public/707/cisco-sa-20090624-video.shtml

If you have deployed these technologies then you must have determined that video surveillance is an important component of your security program. The DoS vulnerability in Cisco Video Surveillance Stream Manager could result in an extended DoS condition which would effectively blind you. The vulnerability in the cameras could allow a non-privileged user to gain privileged access.

Updates
As I stated previously, the remaining issues are updates to previous advisories. They all relate to Cisco IOS and include a vulnerability with Mobile IP and Mobile IPv6, a cTCP DoS vulnerability, a Session Initiation Protocol DoS vulnerability, a crafted UDP packet vulnerability that affects several IOS features, vulnerabilities with WebVPN and SSLVPN, a privilege escalation vulnerability in Cisco IOS secure copy and a crafted TCP packet vulnerability that affects multiple IOS features. Links to additional information have been included below.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

Summary
Now that I've thrown a bunch of information at you, I want to put all of this in terms of risk and risk assessment. When I started writing this post, I had a couple of statements about patching and installing updates along the lines of "Please patch". I pulled them out because I realized that I was going against the normal advise that I give. Should you patch or upgrade your software to fix these problems? The short answer is probably yes but that is not the whole story. Simply deploying each and every patch because the vendor says it is a problem is not risk-based security.

I recommend that you take a look at these vulnerabilities. If you are using this technology and if you are affected by the vulnerabilit you need to ask yourselves "what would the impact be to the business if....". For example, the vulnerability with the Cisco IP Cameras would allow an authenticated but non-privileged user to gain privileged access. Do you have non-priveleged users? If not, does it make sense to install the patch? If you do have non-privileged users, what would happen if they gained priviliged access? What do you believe is the likelihood that that particular vulnerability could be expanded to allow unauthenticated users access?

I understand that this seems more complicated than simply deploying the patch and in some cases, it may be but consider an environment with 500 cameras. How many man hours will be requred to push out the patch to that many cameras? If it will take 1 hour to deploy each patch, that's 500 man-hours. Assuming a simple per man-hour cost of $100, that is a cost to deploy the patch of $50,000. Would the potential impact of the vulnerability cost the orgnization more or less than $50,000. What about other technologies. Deploying a patch on a purpose-built device like a camera may have little down side but what about deploying a similar patch to a critical application or a core operating sytem. Way back when SQL Slammer came out I had a customer who relied on SQL databases. They were unaffected by the worm but the patch caused days of downtime because it broke other applications.

I know I am over simplifying things but the concept is sound. When it comes to security, it is important to understand the potential negative impact to the business, the likelihood of a problem and the costs/risks associated with remediation.

Netgear Vulnerability - Disclosure Notification

kfiscus@nwnit.com (Kevin Fiscus) — Mon, 15 Jun 2009 21:58:00 +0000

Today the members of the Bugtraq mailing list received a notification about an email in a Netgear DG623 router. The text of this email reads as follows:

Product Name: Netgear DG632 Router
Vendor: http://www.netgear.com
Date: 15 June, 2009
Author: tom@tomneaves.co.uk
Original URL: http://www.tomneaves.co.uk/Netgear_DG632_Remote_DoS.txt
Discovered: 18 November, 2006
Disclosed: 15 June, 2009

I. DESCRIPTION
The Netgear DG632 router has a web interface which runs on port 80. This allows an admin to login and administer the device's settings. However, a Denial of Service (DoS) vulnerability exists that causes the web interface
to crash and stop responding to further requests.

II. DETAILS
Within the "/cgi-bin/" directory of the administrative web interface exists a file called "firmwarecfg". This file is used for firmware upgrades. A HTTP POST request for this file causes the web server to hang. The web server will stop responding to requests and the administrative interface will become inaccessible until the router is physically restarted.

While the router will still continue to function at the network level, i.e. it will still respond to ICMP echo requests and issue leases via DHCP, an administrator will no longer be able to interact with the administrative web interface.

This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router.

Affected Versions: Firmware V3.4.0_ap (others unknown)

III. VENDOR RESPONSE
12 June, 2009 - Contacted vendor.
15 June, 2009 - Vendor responded. Stated the DG632 is an end of life product and is no longer supported in a production and development sense, as such, there will be no further firmware releases to resolve this issue.

IV. CREDIT
Discovered by Tom Neaves

This posting elicits so may comments that I don't really know where to start so I've tried to break things down a bit to make the discussion easier to follow.

Vulnerability Severity
First I'd like to address the perceived severity of this vulnerability. It is a denial of service attack against a platform that is most commonly used in the home or SOHO environments. This combination means that most mid sized or larger organizations will likely pay little attention to it. This is a mistake for a few reasons. First, and speaking to small, medium and large organizaiton, you may not used SOHO devices but your users do and they, in turn, connect to your network. This may be via VPN (through the SOHO router), directly using various protocols, or simply by bringing ther laptop from their vulnerable home environment to your "protected" work environment. In short, problems with these devices affect you directly.

Now you may say that this is "just" a DoS problem and isn't going to have an effect. At a minimum, it can effect the productivity of your users. Let's consider an extremely situation - you have a user who is working on a proposal that needs to be turned in on a specific date and time. If their router gets nailed it may delay the proposal causing you to lose the business. From a more day-to-day perspective, many organizations allow teleworking. If they cannot connect to the business network, their productivity will be impacted costing your organization money. If your corporate network, or even a single switch on that network, went down, you'd ensure the problem was addressed ASAP. From the perspective of a teleworker, a DoS attack against their SOHO router are exactly the same as the loss of a corporate switch.

Finally, DoS attacks have a way of turning into other types of attacks - possibly allowing the attacker to gain control over the SOHO router. if that happens, it results in a whole new set of problems for business with users who rely on these systems.

Vulnerability Disclosure
OK, now that we've covered the fact that we should care about this kind of problem, I want to talk a bit about vulnerability disclosure. In this case, that problem was identified in November of 2006 and was posted on Bugtraq on June 15th of 2009 - 2 years and 7 months later. This means that people have been using vulnerable equipment for all that time without knowing it or having any ability to do something about it. That, to me, is a problem. Even now, becuse the product is "end of life" there is not patch available but purchasing a new box - again, a scary situation.

I don't want to come across as an alarmist. The issues affecting this particular device are unlikely to represent a significant security risk to any organization but this problem of vulnerability disclosure is multiplied throughout the industry on virtually every singel technology in existence making it a situation that is relevant to everyone. Now comes the point where I outline a bunch of questions with few answers:

Security researches spend time "hacking" technology. By hacking, I'm referring to the term in the original context, not the media driven "attacker" definition. These researches hack technology for a variety of reasons. It may be part of an authorized penetration test or they may work for a company with a vested interest in vulnerability identification (e.g. a security product vendor, etc.). Often, they just do it for fun. In any case, they discover a vulnerability. This leads them to the first question. Do they notify the vendor, disclose the problem to the public, sell it to the highest bidder......?

If they notify the vendor, they may get a positive response. They may also get brushed off and ignored. They may get critisized or, in rare situations, they may be the target of legal actions or "illegal reverse engineering" or similar "crime". In any of these cases, vendor notification resulting in positive, short term actions by the vendor are not the majority leaving the users of the technoloy vulnerable and ignorant.

If they decide to publish the problem on the Internet making it available to the public the will likely be contacted by the vendor, and/or the vendor's lawyers. The public may be able to, if they are made aware of the problem, implement some controls to reduce their risk level but the security researcher is also putting their discovery in the hands of the bad guys also. In effect, they take off the white hat and put on the grey one.

There are also organizaitons out there who will buy vulnerabilities. This puts some money in the pockets of the reseachers but comes really close to "black hat" work.

This is a bit of a sticky situation and gets more so when you look at the concept of pay. Many vulnerability researchers are either independent consultants or do this type of work as a hobby in addition to their normal 9-to-5. They spend countless hours performing quality analysis for some vendor for free. When they do identify something and turn it in to the vendor, the vendor in turn has the opportunity to make their product better. Shouldn't the researches receive some compensation for the QA work that should have been done by the vendor in the first place? Like I said, this is a sticky subject.

Attack Vectors
The last thing I want to talk about is the way this vulnerability can be attacked. According to the article - "This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router." This seems to imply that if "Remote Management" has not been enabled, this attack is not exploitable from the Internet. While I haven't tested it, I would suspect that Cross-site scripting (XSS) and Cross-site request forgery (CSRF) attacks may also be used to attack the system even of the direct external access is not possible.

New Podcast

kfiscus@nwnit.com (Kevin Fiscus) — Tue, 09 Jun 2009 21:48:00 +0000

I have just taken my first step into podcasting. In this case, I recorded a discussion about the 10 most dangerous security mistakes I see organizations making when I conduct security assessments. Unfortunately, these mistakes occur far too often and make real security exceptionally difficult. I'll apologize in advance for the quality of the audio editing. I'll get better. I promise.

Cyber Security Czar

kfiscus@nwnit.com (Kevin Fiscus) — Wed, 03 Jun 2009 16:01:00 +0000

The White House continues to talk about creating a cyber security coordinator or cyber security czar. Comments from the administration talk about the threat of cyber attacks on our critical infrastructure and of cyber terrorism. My first response - FINALLY! Finally someone is taking the threat seriously. That said, I do not understand what a cyber security czar would actually do.

Many of the articles I have read on the subject talk about the administration's "plan to keep government and commercial information on the Internet safe from cyber criminals or terrorists." They talk about forming partnerships with state and local governments as well as with the private sector and about focusing on training and education. These are all good things but they won't really help make things more secure.

The only way for the federal government to make things more secure is to pass laws or set policy that everyone must comply with. Education won't do it because there are too many organizations that, as a result of ignorance, incompetence or arrogance, won't do the right things. That's why the government has put in place regulations like HIPAA, 21 CFR Part 11, GLBA and Sarbanes-Oxley. That's why the credit card companies put in place PCI DSS. The problem is that these measures just don't work. The minute you think you have created a checklist of minimum mandatory requirements, you have really created the only list of requirements that many organizations will follow. You have also given the bad guys a template of what your securty will look like. In effect, you have made security weaker.

Federal regulations and PCI have taken the wrong approach when it comes to cyber security. This is because they are trying to define the controls that need to be put in place. Unfortunately, information technology is too complex, companies are too diverse and the threat landscape is too dynamic for that to work. The minute you define a control requirement, bad guys find a way around it. The regulations then have to change but that process takes much too much time. Control focused regulatory requirements also create the impression that compliance equals security. That is simply not the case.

So, if the current regulatory requirements are the wrong approach, what is the right one? I'm glad you asked. The short answer is - responsibility. Organizations should be held responsible for the results of their security mesures, not on the measures themselves. If an organization has really bad security but never suffers a breach or compromise, is there a problem? If an organziation is 100% compliant with all regulations but they suffer a compromise that discloses credit card numbers and results in identity theft for thousands did being compliant help? The answers to these questions should be self evident. Unfortunatley, our current regulatory climate would praise the second organization while punishing the first. My thoughts are simple. Hold organizations accountable for effectively securing sensitive data - or more specifically, data that if modified, altered or destroyed, would negatively affect others. Many of the various state privacy laws to this. Let organziations secure their environments as the see fit but hold them accountable for failure. It doesn't take a cyber security czar or a Cybersecurity Act of 2009 to do this. It take a couple of things. First, it requires a national description of what "sensitive" data is. This list doesn't need to be that large but would include personal information that could be used for identity theft, personal medical records, personal financial records (including credit card data), classified government information and the like. Once this definition has been established, two things need to happen; a law needs to be passed that would result in penalties should these data be disclosed and a law needs to be passed (perhaps an expansion of the Computer Fraud and Abuse Act) that makes it a crime to access these data without authorization.

What would the effect of this be? Of course I don't know for sure but here's my guess. Nothing would happen initially until the first few public cases of fines or other penalties levied against organizations who let their sensitive data be compromised were on the nightly news. This would serve as a wake up call (hopefully) making organizations approach security as a matter of risk management rather than as a checkbox that needs to be checked. Would it work? I don't know but I believe it would be better than what is happening today.