Net Neutrality By Brad C. Johnson

Net neutrality, at its essence, is about deciding how much a telecommunications carrier can control content (i.e., Internet traffic) on the network. Should the carriers be allowed to block or slow content to the end user?

Internet providers want unfettered access to content for their users because they want as much potential data as possible to get to their target audience: their customers using the Internet: often, to help generate ad revenue. Users, even if they don’t know it, want unfettered access to content because they don’t like the idea of somebody deciding what they can and can’t see or how quickly they get the data.

Carriers, on the other hand, want the right to manage content because it helps them in several important areas. First, Internet traffic traverses over wildly different communication bandwidth mechanisms ranging from (yes it still exists) dial-up, to broadband cable, satellite, WIFI, and phone systems such as 3G and 4G. Carriers don’t want to use up valuable wireless bandwidth with, in their minds, unnecessary data.

Second, carriers are more in favor of a tiered service model to generate revenue. For example, if you want content being delivered at the fastest possible rate you would pay a “tier 1” price. If you can’t afford that or instant availability isn’t critical for your needs, you would pay a “tier 2” or “tier 3” price.

Third, the fact is, regardless of your feelings about carriers managing content or not, it’s getting harder and harder to provide the bandwidth that people want or need for today’s applications and the need for more bandwidth is only growing. This isn’t about censorship or control, per se, but about being efficient with how to use the telecommunications infrastructure both now and in the future as the demand for more data increases.

The bottom line is, there are a lot of interested parties in this debate and those that argue on both sides of the issue: e.g., those claiming net neutrality is a must to ensure the integrity of the data you’re looking at and yet others claiming certain amounts of controlling content (data discrimination) is not only not a problem but desirable to get network “trash” out of circulation. The result is likely to be a series of negotiations, compromises, and proposals that span geographical, political, financial, and other powerful boundaries.

Portions of this text was referenced in the following article: http://www.itbusinessedge.com/cm/blogs/bentley/net-neutrality-resolution-will-require-negotiations-compromises-and-proposals/?cs=37200

Hiring “Hackers” … Please don’t! By Brad C. Johnson

There is an interesting article on the NetworkWorld web site by M. E. Kabay dealing with the recommendation of hiring “hackers” to help better secure your networked environment. For a moment, let’s just ignore that the term “hacker” is ill defined and there are all sorts of other words and phrases that are meant to clarify the issue like “Black Hat,” “White Hat,” “Gray Hat,” “Cracker,” “Ethical Hacker,” etc. For this blog let’s just agree that “hacker” is not an employee of yours and somebody who can break into computer resources.

On the one side is the idea that hiring hackers is a good thing because, even though they may have done bad things in the past, they actually know how to “do it.” That is, break into resources on a network. The theory is that too many security professionals have been ordained as security experts just because they work in a security IT job function and/or they have attained some number of technology oriented certifications. The argument is that just because you have the job title and certification, doesn’t make you actually good at hacking.

On the other side is the idea that hiring hackers is a bad thing because they can’t be trusted, well, because the reason they are called hackers is that they have done bad things without permission: e.g., break into systems they don’t own.

The primary authors on either side of the argument are professional and credible enough to see valid points on both sides. Unfortunately, all of that dialogue doesn’t change, what I believe is, the most important point – a point raised by one of the people who posted a response: restraint.

While it may be true that every security IT professional does not have the skills or expertise of a successful hacker - and let’s not forget that most hackers are actually not that successful and the vast majority of them copy the successes [aka “script kiddies”] of the few truly original and creative ones - one of the behavioral characteristics that most of them do have is that they feel constrained to do things in a certain professional and organized way to ensure the stability of their environment: that is, they have restraint over what they do. Most hackers have no restraint in what they do: they feel comfortable doing anything, at anytime, to achieve a goal no matter what consequences it has on the environment.

It can be argued that one needs to have exactly that kind of destructive freedom to replicate what a hacker might do. I agree, and the way to achieve that is to have protected and segregated (e.g., QA environment) environment where your trusted professionals can try anything they want: not from hiring hackers who may steal or corrupt sensitive information, leave systems less secure than when they found them, or who may infect tested systems with Trojan horse or denial of service software that will be used at a later time – when they are doing their hacking for yet another victim.

Hire a hacker? Please don’t!

New exploit area: Cross Site Printing (XSP) By Brad C. Johnson

One of the true benefits of a networked environment is that it makes resources readily available to you regardless of where they are physically deployed. One of the true realities of a networked environment, however, is that it can be difficult to manage those resources securely. How do you make sure that only the appropriate people (authentication) with the appropriate rights (authorization) can use that resource at the appropriate times (access control) and you know who did it (auditing)?

Most organizations are aware of this management problem for their own Intranets and are painfully aware of the difficulty in deploying resources safely and securely on the Internet. One of the most prevalent types of network/Web oriented exploits – Cross Site Scripting or XSS – has expanded into a new area and is called Cross Site Printing or XSP. This topic started popping up in articles in late 2007 and early 2008 but has recently started to garner some traction.

XSP is a logical variation of XSS in that it is a Web oriented code injection technique. XSP allows you to get access to Intranet printers through a Web portal. Many network printers often listen for printing requests on a well known TCP port: port 9100. If you are "on" the same network or LAN as this printer and it has not been configured to restrict access to it (a common occurrence), you can send anything to that port. If a Web application happens to be on the same network as one of the network printers, you can construct an HTML request to send something to that printer. An article from Net Security describes this capability.

Just to point out how simple this request can be, here is an example of sending a request to a network printer using HTTP:

http://[PRINTER]:9100/FILE-REQUEST

"[PRINTER]" is the IP address or the domain name of the network you are on. This simple HTTP construct would send an HTTP GET request to the printer trying to GET the file /FILE-REQUEST.

As the Net Security article points out, that simple HTTP request would result in basic HTML header information being printed but one could instead send a POST and create a properly formatted request to the printer. This is just the start of a variety of exploits that could be constructed and sent to the device.

At a minimum, this exploit could be used to send SPAM to the printer, or possibly perform a denial of service by sending a lot of requests and tying it up. What’s probably more interesting is that today’s sophisticated printers do a lot more than just print. They scan and store pictures or images that could contain sensitive information that could be viewed or possibly modified if one could interact with the printer interface.

Unless the printer is appropriately secured, then, it would be possible to send data to be printed, possibly change the printer’s configuration, or use the other functions (e.g., FAX or access other network resources) that the printer offers.

Lessons from the Heartland Data Breach By Brad C. Johnson

The Heartland Data Breach situation can teach us all a number of fundamental security lessons. The actual breach was in fact not a single event but a sustained set of intrusions starting back in 2006. In addition, the victims also included Hannaford Bros. and 7-Eleven.

Lesson #1: don’t just read the headlines, dig a little deeper.

The perpetrators prepared for these intrusions for a long time. They developed a set of malware programs and then ran a variety of third-party and public domain antivirus programs against the malware to ensure that it would not be detected by normal antiviral scanning activities.

Lesson #2: intruders are willing to expend as much effort as you do to achieve their goal.

Most of the intrusions were successful using relatively common attack techniques. To use a well-known analogy; if a robber can just open your front door because it’s not locked and you’re not home, there is no need to try to outsmart a sophisticated and monitored burglar alarm system next door. Sometimes, a determined intruder wants to get into your house; most times, a burglar just wants to get into some house – so get into the house that’s easiest to get into. On the Internet, it’s often the same thing.

Lesson #3: many intrusions are the result of finding the easiest opportunity.

Heartland had recently passed a PCI DSS assessment. As we all know, however, passing an assessment, audit, or even being deemed compliant is not an end-goal, but a point in time evaluation. IT environments are constantly changing and therefore there are always challenges in keeping your security stance stable.

Lesson #4: passing an audit probably means you’re safer, but it doesn’t mean you’re safe.

Everybody understands the importance of perimeter security. Unfortunately, it still begs the question: where does my network really start and end? The problem is that it is often difficult to know just who has access to your network and who doesn’t. In the Heartland et al situation, the intruders found their way onto several networks and placed software that went undetected for months on end. Once the software was installed, they were on the “inside” and not subjected to same controls one has when trying to get to the inside.

Lesson #5: be just as concerned about what goes out of your network as what comes in.

All of these lessons point to fundamental security concepts: make sure you understand the details, accept that intruders will try just as hard as you, many intrusions are successful using simple exploits, passing an audit doesn’t guarantee your safety, and you should assume you don’t know who is on your network and protect resources accordingly.

Throwing Out Password Masking With the Bathwater, By Keith Royster

A recent and highly publicized blog is recommending that we stop the practice of password masking. The argument made by the author is that password masking offers little to no security benefit while at the same time creating a frustrating user experience. Even security-famed Bruce Schneier has weighed in on the topic. Specifically, the author notes the following:

• Users make more errors when they can’t see what they are typing
• Users are more likely to get frustrated or feel less confident, and so abandon their login
• To get around these problems, users are more likely to employ insecure password practices such as using overly-simple passwords, or copying and pasting passwords from other locations

The author further states that the primary claimed advantage for masking passwords – that it prevents shoulder surfers from seeing what you type – creates a false sense of security. He correctly points out that a skilled or determined shoulder surfer would simply watch the keys you type, without having to see the characters appear on the screen.

In addition to the author’s points, I would add that masked passwords make it difficult for the user to know if they accidentally have caps-lock enabled. And, lacking any feedback about their typos, users are more likely to accidentally lock their accounts after too many failed logins. This creates not only a negative user experience, but also an unnecessary strain on technical support when they get called about the locked accounts.

All of the author’s points are valid, but in many cases the problem is overstated, the benefits are understated, and the conclusion falsely assumes binary options.

First, the problems described for password masking are exaggerated worst-case scenarios. How often do you really think users get so frustrated with masked passwords that they abandon the site resulting in lost revenue to the site’s owner? Or more pointedly, how often should such problems be attributed to the password masking itself, and not some other poor user interface design? I’m not saying it doesn’t happen, I am just skeptical that the problem is as large as the author claims.

Second, some benefits of password masking are overlooked. The author claims only one benefit – preventing the malicious shoulder surfer from seeing your password on screen – and then argues that this person will just watch you type the keys on your keyboard instead. Here are some additional benefits not explored by the author:

• Depending on your typing speed, watching keys as they are typed is more difficult than reading a password onscreen – especially for weak passwords. Someone attempting to watch you type keys is more likely to fail in capturing the entire password, or will require additional tools (e.g. video cameras) to assist him. Masking passwords may not be a perfect solution, but it’s not valueless either.
  
  
• Accidental password exposure is probably a bigger problem than intentional shoulder surfers. When you are making that next big presentation to coworkers and clients via the office projector, a web share, or within your cube, will you remember to blank your screen before you log in? Or would you prefer to ask your audience to all close their eyes briefly while you log in? Or perhaps you trust them to see your password?

Finally, the author presents the problem as if the solution is binary – we either mask passwords, or we don’t. As some Mac OS X users will tell you, this is a false dichotomy. For example, when setting up a new wireless internet connection, the Mac gives you the option to display the typed or stored password. By default the password is masked, but the user has the option to override this, which can be helpful when you aren’t sure if you fat fingered the password field. Apple doesn’t use this feature everywhere, but perhaps it should.


In conclusion, if you are considering unmasking passwords, make sure you aren’t throwing the baby out with the bath water. The points made by the author have validity, but they describe an opportunity to improve the existing practice of password masking, not a valid reason for abandoning the practice entirely.