There are many elements to this story: Is What GeoHot did illegal, as Sony claims? Will it lead to more piracy? If it did lead to more piracy, would it even matter? Was what Sony did by removing a feature of the device illegal or unethical? But I think the two main questions above all are: Who owns the device, and How far does free speech go?

We live in an era where corporations are asserting more and more control over the devices we purchase. Unlike a physical book or a lamp, the technology of today allows for interactivity between the manufacturer of the product and the product, itself. Companies like Apple and Sony have attempted to use this to their economic advantage by restricting what valid purchasers of the product can do with their own device. They restrict what apps you run, if you can resell it, and can even take the product back on a whim. Make no mistake: the rights we have enjoyed over our own property are under full frontal assault. Companies like Sony would like nothing better than to convince you that you don’t actually own the product you purchased–that it is really just a long-term rental–that they get to decide the rules.

The other main question besides device ownership is: How far does free speech go? We already know that free speech is not unlimited. You can’t yell “fire” in a move theater and not expect consequences. But at the same time, we are actually very tolerant of free speech. The fourth ammendment guarantees the rights of white supremacists just as it does those whose speech we find copasetic.

“But, wait!” observant readers will say. Sony is not the government and this is a civil issue. If Sony thinks it has been harmed by the free speech that is the release of the private key, they have a right to address that in the courts. Surely, if the secret formula to Coca-cola were to be released, you would expect an army of lawyers to descend on that person.

While it is true that speech can harm a company, a large corporation like Sony can’t necessarily be expected to win a case just because it doesn’t like someone’s speech. They actually have to prove harm in some way, be it libel, slander, trademark infringement or what-have-you. If that weren’t true, and if the law didn’t provide some protection even in cases where the government wasn’t involved, companies like Sony would successfully sue every security researcher every time a new flaw is found.

This case is not about piracy. If George is to be believed, he has never used the Sony online service, never assented to the EULA and never pirated a game. This is about Sony attempting to send a message: The PS3 is ours, not yours. Play by our rules or we will ruin you financially. To anyone else: freely discuss the hack, or, for that matter, look at it, and we will come after you, too.

I have considered everything from staying completely silent on this issue–certainly the safe choice career-wise–to getting a tattoo of the leaked key. But I can stay silent no more. Sometimes you have to speak up for what you believe is fair and right. And I believe it was fair and right for George Hotz to use his device in any way he chose to. I believe it was wrong for Sony to remove a feature that people paid for and had a reasonable expectation to be able to use. And I believe it is right for everyone to freely and openly discuss the hack, including the key, so that they may use their own device in any way that does not involve piracy, and to further the discussion about what device security means.

If the facts are truly what they appear to be, then I support George Hotz and I wish him well in his case.

Throughout the years, I have learned that this perspective is somewhat unique. Infosec practitioners are usually not the owners of the data; rather, we provide guidance and feedback on how to keep data safe and secure. It is up to the data owners to either take our advice or not, and when it comes to the ethical and moral considerations within security, we often don’t see eye-to-eye.

From my perspective, a data breach is more than just a technical or process failure. When it involves custodianship of other people’s information, it is a breach of trust–a broken promise to those who entrusted their information to you. With that broken promise comes a moral imperative: an honest effort to apologize and make things whole again. From the perspective of those not within the security field, a breach ranges from something that simply needs to be fixed, to something that no one can ever know about, even at the expense of laws.

During my career, I have been asked to do things by data owners that seem to be on-the-edge, ethically speaking. In some cases, I have politely declined–such as when someone asked me to change a ticket type so an auditor for an upcoming audit would not discover the problem. In other cases, the situation hasn’t been so black-and-white–such as when I was recently asked to recommend an alternative antivirus for Windows NT. I could have simply recommend an antivirus solution as asked, with the caveat that I know it would not adequately protect something as insecure as Windows NT. Instead, I gave choices in order of the preferred solutions: move off the platform, invest in an IPS, or accept AV knowing that it will not protect the system. Still, I wonder if I should have even presented AV as an option.

We have an implicit moral imperative to act responsibly. Just as a responsible electrician would not shove frayed wires back into a wall cavity, so do we have a responsibility to promote only the highest standards and, in some cases, actually refuse to act in a way that a data owner may ask us to.

There will never be completely clear answers on how we should act in the face of situations that are somewhat muddy, but it is clear that a line has to be drawn somewhere. Where that line exists depends on the individual, and on their own set of unique circumstances. If the infosec industry is to be considered trusted and professional, each person has to have a line that they will not cross, and there should be a line that we as a group will not cross.

Where is your line?

Even though I am using predominantly free software, there are trade-offs and decisions to be made. Do I want to use the free ATI driver at the expense of 3D acceleration and performance or the more fully-featured non-free version? Do I want to use the Adobe Flash player (from a company who had Dimitry Sklyarov arrested for legal activities in his own country) or the free-but-somewhat-buggy Gnash player? Would I be willing to give up contributing to OSSEC Windows Agent development, even though the agent, itself, is free?

Perspectives on software freedom range from purists such as Richard Stallman, who believe all software should be free, to people like my wife, who really don’t care and would rather just have it work. For myself, I am most interested in maintaining a healthy marketplace where free and non-free software can offer users viable alternatives–a marketplace that ensures information can be exchanged freely and easily. Using and maintaining proficiency in free software allows me to easily make that choice if the developer of a non-free software application presents unacceptable terms.

We’re entering a new era of computing. It’s an era where phones and tablets are finally making their mark, while desktop computing takes a back seat. It’s also an era where user choice is being annihilated by companies like Apple, who make it abundantly clear that they consider the device they sold to the consumer to still be theirs, and who act as the gatekeeper deciding exactly how you can use your device. It’s an era where the bundling of the browser to the OS is the least of our worries; now the companies control the entire platform.

Freedom is all about choice. It’s also about evaluating the trade-offs. When there is a clear free and non-free solution to my problem, I try to default to the free option. By doing so, I help to keep the ecosystem alive and thriving, which, in some small way, ensures the free flow of our information now and in the future.

Update: A perfect example of Apple trying to control the free flow of information can be found in this article, in which Apple is described as removing the Wikileaks app. It is not for Apple to decide whether or not its customers should be the consumer of such information on devices they own. Enough said.

Unfortunately, the stakes have risen from spam to outright malicious e-mails and this time the suspected company is Payscale.com. When I received a malicious PDF to a very unique address only used for that site, I wanted to let them know about a possible breach. So I sent an e-mail to every one of the contacts I could find on their web site. I wanted to make sure someone knew about this.

After over a week with no response from anyone, I received another e-mail, this time a malicious link posing as an Adobe Flash Player update. Still no response.

I think the right thing to do is to publicly discuss the issue. I think that when a company doesn’t respond to concerns such as this, and the public entrusts their data to them, it is ethical and right to publicly discuss the issue so people can make an informed choice about doing business with that company.

I can’t say that Payscale.com has been breached because I don’t know. What I can say is that the source of these malicious e-mails seems to have a strong connection to this company, and that they did not respond to a possible breach notification. Consumer beware.

Update: I am happy to report that, as a result of this post, I was contacted by someone at Payscale.com. My contact does seem genuinely concerned with looking into the issue. Again, this may or may not be anything, but the point of the post seems to have succeeded–getting someone to acknowledge that a security issue may exist.

But what is the right thing to do when there is an indication that a company may have been compromised? Is it ethical to disclose at all? Is it ethical to not disclose, since others would presumably entrust their data to the company without having this important piece of information? This is the question I have been pondering for some time.

While I think there is still room for healthy debate, I have come to the tentative conclusion that the company should be notified first and given an opportunity to respond, and only if they either do not respond or respond in such a way as to indicate that they are not going to consider the issue, should your concerns be disclosed publicly. I think that companies who may have had a breach have the right to deal with it internally. However, if it affects others and the company does not give an indication that they have looked into the issue, the right thing to do is to publicly discuss the issue so as to warn others about the potential consequences of entrusting their data with that company.

Publicly discussing a potential breach could be just the catalyst a company needs to begin an investigation that helps them to limit their losses. And while this shouldn’t be necessary, the reality of the world we live in is that information protection is rarely practiced well, let alone incident response.

On the other hand, this may only work well (or not) in the consumer area. If there is anything that the Wikileaks debate has taught us, it is that–regardless of whether you think the release of this kind of information is a good thing–there are consequences. One has to carefully consider the potential ethical and legal consequences when choosing to make a public disclosure. What if it initially looked like a breach, but was simply a misunderstanding? What if your words lean towards libel and not opinion? What if disclosing the potential breach results in people losing their jobs?

While there are no right or wrong answers, it is an area that deserves attention and discussion in the security community. As protectors of information, we need to be diligent about the way we handle it, and that involves careful reflection about the ethics and consequences of our actions.

What do you think?

Ok. Put your gloves on. Here are some countermeasures and considerations for all of the risks we discussed previously.

1. Alert manipulation. Recall that alert manipulation is the process by which alerts are used against us.
   1. Alert tickling. The idea with alert tickling is to send just enough normal-looking alerts to create a window for the attacker to go undetected. There are a couple of ways to defend against this. One is active response. By default, anything that is level 6 or higher can trigger an active response such as blocking the IP for 15 minutes. The cool thing about active response is that it will continue to work even if your alerts are delayed until the next hour. This means the attacker might still be blocked regardless of when you get the e-mail. Another countermeasure is to increase the default number of alerts per hour to something like 9999. Of course, this opens you up to the next risk of alert flooding. Perhaps the best countermeasure is to configure the do_not_delay option in ossec.conf. Adding something like this would save all e-mails over 12 until the next hour, except for those that appear to be an attack:

   <email_alerts>
   <email_to>secanalyst@example.com</email_to>
   <group>attacks</group>
   <do_not_delay />
   </email_alerts>

   2. Alert flooding. With alert flooding, the attacker would like to swamp you with so many alerts that you just can’t bear to read them all. Besides tuning, the best option to protect against alert flooding is to keep the email_maxperhour setting at a reasonable level. If you choose to go that route, be sure to note the risks that can introduce and plan accordingly.
2. Killing the OSSEC processes. I am a firm believer in the mantra that if someone has administrative access to your system, they can do whatever they want. Ultimately, there is nothing you can do to completely protect against this risk. On the other hand, not all administrative users are savvy enough to be able to subvert the ossec processes. A well-written SeLinux policy just might be enough to hold them back. Also, recall that I talked about the non-malicious attacker. Non-technical safeguards such as background checks, job rotation and common workstation areas might be enough of a deterrent for those situations.
3. Log injection. With log injection, the attacker wants to control the log output. There are two main types of log injection: remote and unauthenticated. They can also be combined for greater efficiency.
   1. Remote log injection. The basic defense against remote log injection is to first assume that all input is malicious. Nothing from the user can be trusted, even if your OSSEC installation is on a private network. The second line of defense is to write your OSSEC decoders in such a way as to restrict where in the message input can be coming from. Referring again to Daniel’s paper, Attacking Log Analysis Tools, we can see that adding a ^ (to denote the beginning of the line) or a $ (to denote the end of a line) is often enough.
   2. Unauthenticated log sources. The obvious countermeasure to unauthenticated log sources is to not use them. However, while that is the best defense, it is rarely practical in a modern network. Sometimes you are simply faced with the choice of getting logs through syslog, or not at all. Given the choice, I would choose to get the logs. One approach is to design an out-of-band network where your unauthenticated network devices can send their logs. That approach is rather expensive and not very pragmatic for most people. The more practical approach is to enable IP spoofing protection on your network devices, such as in this example. Be aware, though, that it may not protect against attacks within the same broadcast domain.
4. Traffic manipulation. This attack can be difficult to prevent. Not only does it involve the direct manipulation of traffic, as is the case with something like ARP poisoning, but also intentional or unintentional flooding. Common countermeasures include NAC protection, blocking DoS attacks upstream and not using unauthenticated log sources.
5. Active response manipulation. Active response can prevent an attack from becoming a breach. It can also enable an attacker to block legitimate traffic. OSSEC accounts for this by giving you the white_list option for use in ossec.conf. Any IP or range added to this option won’t be blocked by active response. Keep in mind that a trusted host may be compromised first, with the attacker looking to elevate the access. The safest option is to not whitelist anything. OSSEC also includes a timeout for responses, so if you are accidentally blocked, you can try again in about 15 minutes.

By now you may be starting to realize that the default configuration of OSSEC is very sane and has taken most of these risks into account. At the same time, it gives you enough flexibility to meet your needs and to make your own risk decision. The important thing is to consider the possible consequences of changing a default setting and be comfortable with the additional risks it may present.

OSSEC can be abused in a number of ways. Many of those are not the fault of OSSEC, but rather they speak to weaknesses in basic protocols or the analyst using the tool. Here are some of the ways an attacker may try to abuse OSSEC:

1. Alert manipulation. Alerts can be manipulated in a few different ways. The basic idea is to attack the alerting mechanism in such a way as to throw the defender off the trail. Here are a few of those ways:
   1. Alert tickling. By default, OSSEC will send no more than 12 alerts per hour. This is to prevent an attacker from flooding you with a sea of alerts. This leaves the potential for the bad guy to intentionally engage in something, maybe from a different IP, that looks like noise. You’ll chalk it up as nothing to worry about and the attacker will have a window to proceed while being undetected.
   2. Alert flooding. In this attack, the point is to flood you with as many alerts as possible. The attacker may know that you have raised the default number of alerts per hour, and will count on you not reading them all. A savvy attacker will begin the attack with simple stuff that looks like noise, hoping you will read the first few alerts and delete the remaining 1,000.
2. Killing the OSSEC processes. If your attacker is an administrator, then it is easy to simply kill the processes. Anything logged while the OSSEC processes aren’t running will not be sent once OSSEC is restarted. It is valid to say that if one has administrative access, then all bets are off. Understand, however, that not all attackers are outright malicious or untrusted. Your attacker could simply be an administrator who doesn’t want to follow the change control process, and stops OSSEC before making the unauthorized change.
3. Log injection. When the attacker can manipulate the log file to their liking, we call it log injection.
   1. Remote log injection. While SQL injection is well-understood, it’s log-based sister, remote log injection, is not widely discussed. The basic premise is the same. Anything coming from a user should not be trusted, as it could be malicious. As Daniel demonstrates in his paper, Attacking Log Analysis Tools, when the regexes responsible for parsing the message are not well-written, it gives the attacker the possibility to manipulate the log monitoring program in his favor.
   2. Unauthenticated log sources. By default, OSSEC sends all logs encrypted with blowfish. In addition, a counter is added to each log to prevent log replaying (an attack in itself). However, OSSEC also supports syslog, because, well, let’s face it, that’s sometimes the only option. As you may know, syslog messages can be spoofed. Since the protocol is UDP, the attacker does not have to worry about completing the connection. So, if an attacker can spoof the source IP, he can cause you all sorts of grief. For a great example of how to spoof syslog, check out the paper, The Ins and Outs of System Logging Using Syslog.
4. Traffic manipulation. At attacker who can interfere with the traffic between the OSSEC agent and the manager might be able to keep the message from being received. If the message isn’t received, the manager can’t correlate and alert on the log.
5. Active response manipulation. Active response can be a double-edged sword. On one hand, it can prevent an attack from becoming a breach. On the other hand, when combined with unauthenticated log sources, the attacker might be able to spoof traffic and block legitimate hosts from accessing your host.

Understanding the risks leads to the inevitable question, “how do I protect myself?” In part II, we’ll discuss some countermeasures for these attacks, as well as the trade-offs for these countermeasures.

First, I would like to say that the level of transparency in this response is truly commendable. Rather than sweep this under the rug, they have chosen to share the details of what happened, why it happened (more on that in a moment) and what their plans are to, hopefully, prevent future breaches.

I encourage you to read the entire post, because it is a good account of how actual, real-world attacks happen. Targeted attacks take advantage of trust (both in people and machines), shared and weak passwords, too much privilege and an assortment of other security 101 vulnerabilities.

The attacks consisted of a XSS vulnerability, brute-force logins, a shortened URL, password sniffing, password re-use and social engineering. Pretty typical stuff, really.

What I find most interesting about this report is the emphasis on technical countermeasures in the What are we Changing? section, when the attack succeeded primarily due to vulnerabilities in human beings.

• The Infrastructure Team members clicked on a cloaked and untrusted link, which launched a XSS attack.
• A brute force login succeeded against a poorly chosen password. But prior to it being successful, no one seemed to be getting alerts on so many failed login attempts.
• They once again exploited the Infrastructure Team by getting them to log in with a password that the team members, themselves, did not choose.
• They took advantage of cached passwords on the server.
• Slicehost didn’t respond to the attack when notified, which enabled one host to continue its attack against someone else.

These are all people issues. It’s the same stuff that we security types have been trying to hammer into the brains of people for years now. There are certainly technical countermeasures which could have helped, but this was an attack on people.

It’s easy for us to play armchair quarterback and be critical of the response, however that is not my intention, Rather, it is my intent to simply cast another light on the response so we can all learn and secure our assets more effectively.

I would be working away in my cubicle when someone would come up behind me. It went something like this:

“Hey, Mike. Just wanted to let you know what you’ll be seeing me <insert action here> in the logs. No cause for concern.”

“Thanks for the heads up,” I would reply.

The administrators knew they were being monitored, but didn’t exactly know the full details of the monitoring. They naturally assumed I would see what they were up to. In many cases I wouldn’t have known.

The vast majority of these folks were honest to begin with, but I can’t help think it assisted them in following process and being just a bit more transparent with what they were doing. Maybe it even dissuaded someone who was on the fence from doing something vindictive.

After seeing this in other environments, I think it deserves a term. At the risk of coining a term for something that has already been identified, I hereby declare this the “OSSEC Effect.” The definition (which could use some refinement) is as follows:

OSSEC Effect: The alteration of a computer user’s behavior when they know their actions are being monitored, but do not realize or understand the extent of the monitoring. Users will, without provocation, volunteer information they believe could be seen as questionable, whether the monitoring system would have known about it or not.

I wasn’t too concerned since all of my credit card numbers are unique and automatically generated, and all of the e-mail addresses I use for businesses are also unique, but just the same, I checked my statement. So far, all is well.

As a security guy, I suppose I should forever relegate monoprice.com to the vendor blacklist. After all, they must have been doing something wrong to allow the bad guys to get in, right? That may indeed be the case. They may have had security so bad you could drive a truck though it. Then again, maybe it was very good.

Breaches happen. It’s very, very hard to cover every known threat, let alone the unknown. Security professionals have to anticipate and protect against all threats, while the criminal only has to find one vulnerability. Most of the time it’s not even under our direct control. We are charged with the responsibility of security and get the blame when a breach happens, but encounter fierce resistance when we tell management what really needs to be done to properly secure a site.

Unlike Gexa Energy, who took almost a year to notify affected customer of a breach, monoprice.com took the bold move of prominently and publicly placing a warning on the front page of their web site.  They further went on to stop accepting orders while the breach investigation was continuing. Right now they’re trying to get back on their feet.

Preventing a breach is difficult enough, but the truer measure of an effective security program is how you respond to a breach. Do you issue carefully-crafted letters from the PR department or do you level with your customers? Do you attempt to shun responsibility or do you recognize your mistakes and learn from them?

It seems that monoprice.com recognizes its responsibility to its customers and is doing the right thing. That, combined with my personal risk-mitigation strategies, probably means I will do business with them again.