Immutable Security

Here are the five or more links that I found interesting for this week:

• PDF-XRAY is a site where you can submit suspect PDFs for analysis. Now you can download the code behind the site and have a go at the file locally. This might be a better alternative than sending a potentially sensitive file to an unvalidated web site.
• Are you wondering whether that weird looking exe in a startup location is malicious? Virus Total is one of my favorite sites for getting a second opinion. It will scan a file you submit with multiple AV engines and let you know what they think. A file that comes back clean is not necessarily clean, but if multiple AV engines tell you that it is infected then it probably is. Another feature, which seems to be new since my last visit, is the ability to scan a web site. It will check the index file and let you know if any obvious malware is being delivered from the site.
• Threat Expert is a similar site to Virus Total, with the added advantage that it returns a pretty detailed report. The report tells you what the file actually attempted to do. I like to use both sites on a suspect file.
• Feeling pretty confident in your firewall egress policy? What if I told you that systems can be controlled with ping packets, or ICMP. Ok, I’ll wait while you pick your jaw up from the ground.
• As we become more and more of a gadget society, we’ll be running into things like this quite often. Jerome Radcliffe discovered some vulnerabilities with an insulin pump. Since the pump controls the dosage of insulin to the patient, a security vulnerability in a device like this is not just inconvenient, it can be fatal. Medtronic, the company behind the device, seems to be doing a very poor job at handling what seems to be a very honest and ethical disclosure. Information security concerns may be new to these types of devices, but we can’t let the companies PR their way around these issues. The stakes are simply too great.

That’s it for today. Have a great weekend!

Here are the five or more links that I found interesting for this week:

• This is just all kinds of awesome. It’s not that I am with the bad guys, but when they get this creative you have to give them credit. A bunch of criminals used 3D printers to print out ATM Skimmers. This is just another way that the face of information security is changing.
• Also on the ATM theme, here’s a method to steal ATM PIN numbers using a thermal camera. I am not entirely sure, but given how the cameras are used in house energy audits, my guess is that this can be done from some distance.
• Just for fun, check out this security architecture fail. Can you spot the defect?
• RSA blogged about the recent breach that they experienced. Shortly after they announced the attack, I also blogged about the tendency to call attacks APTs. I fear that describing an attack as an APT is simply another way of failing to take responsibility. It is understandable that they had a breach, but the truth is that attachments exploiting 0-day holes in client software is not particularly advanced today. I have dealt with several 0-day pieces of malware. RSA had layers of security that failed. Again, it’s understandable that they failed–securing everything is hard–but use it an an opportunity to examine the individual layers that led to the breach. There was no magic here. This is  a standard attack method these days.
• Did you know that OSSEC can audit your system? It’s better to know you have vulnerabilities before they are exploited. Daniel Cid explains how to detect outdated web applications with OSSEC. Good stuff.

That’s it for today. Have a great weekend!

Here are the five or more links that I found interesting for this week:

• Dave Hoelzer from SANS provides some very useful “AuditCasts.” These are short, instructional videos on various topics. This week, Dave talked about the benefits of split DNS. One implementation of split DNS that Dave did not mention specifically is to not have the internal DNS servers forward requests at all; rather, you may rely on your proxy to do the queries for you. This can be helpful if a malware infection is trying to phone home. If they are relying on DNS for the call-back, it might fail.
• What should you do after compromising a system (on which you had permission, of course)? These Linux and Windows community docs provide some good tips. I wouldn’t recommend running these commands or tools without knowing exactly what the outcome will be. They could be dangerous.
• The Morto RDP worm takes advantage of poorly chosen passwords. Microsoft has a pretty good write-up of the behavior of the worm. OSSEC should detect the invalid logon attempts. I have some ideas on how a few rules could detect this general class of infection.
• Barracuda, the company that has a pretty decent anti-spam gateway, offers their RBL for free. I have been using the Spamhaus Zen RBL for quite some time and decided to give this a try. Putting it before the Spamhaus list, the result has been pretty good. Spamhaus now rejects only 3-5 messages a day since the BRBL is blocking lots of spam that Spamhaus would have caught. So far, I know of no false-positives. Using both seems to work pretty well.
• Lenny Zeltser reminds us that security is best designed with failure in mind. Security controls will fail, but that doesn’t necessarily have to lead to an information breach. A good security design plans on these controls failing with the information remaining safe.

That’s it for today. Have a great weekend!

Here are the five links that I found interesting for this week:

• The Shadowserver foundation is comprised of a group of volunteer security professionals who gather information about Internet-based crime. One of the more interesting projects is a compilation of how various antivirus vendors fare against 0-day threats. How does your vendor hold up?
• Logs are not much good if you can’t trust them. Maintaining log integrity is vital to a robust incident response process. Here is a great article on how to protect your logs from tampering. It’s not fool-proof, but it can go a long way.
• Information security is a profession that necessitates a solid ethical foundation. Security professionals are often trusted with the most sensitive of data. This presentation, from the Honeynet Project, tackles some of the more thorny situations about performing ethical research.
• Looking for a really awesome way to store and compare your Cisco configs? Rancid, or the Really Awesome New Cisco confIg Differ, may be just the tool for you. It stores Cisco configs in CVS and can let you know something changed. By the way, OSSEC is also capable of something very similar.
• Are you looking to use virtualization in your PCI program? It can be done, but like most technologies, has to be approached carefully. This guide will show you some of the things that need to be considered.

That’s it for today. Have a great weekend!

An off-beat comment with a colleague last week gave me the idea for this post. We were discussing ways in which security programs fail and he jokingly suggested that I blog about how to fail in security, rather than how to succeed. This struck me as a really good idea. We spend a lot of time focusing on how to improve security, but comparatively little time talking about how you can fail at security. So if you are in senior management, or know someone who is, and truly want your security program to fail, here’s how:

• Don’t define a high level vision: As a leader, you might think that steering the ship should just be left to the worklings. After all, you have worked long and hard to get where you are today. This is the point at which you should be able to kick up your feet and relax! If this is you, then you should not make it clear how the security program should fit within the overall business objectives. Don’t worry, it will work itself out.
• Micromanage: This is the opposite of the strategic approach. You should be able to relax, but you just can’t trust the worklings to accomplish your vision. Maybe you hired the wrong people, but whatever the case, you should make sure to watch their every move. If you don’t, they will just surf blogs like this one.
• Mandate unfunded initiatives: Having a properly funded project plan for security initiatives is so web 1.0. Nowadays, you can either just let the cloud worry about it or let the worklings use open source. After all, there are no costs to implement open source solutions, even if there are no licensing costs. They’ll complain about not having a budget to play with, but they’ll eventually give up and just do it.
• Move your risk into the cloud: Cloudy, cloudy cloudy, that’s what it’s all about-y (just go with it). When you move your critical infrastructure into the cloud, it can’t fail. Clouds don’t go down, they are elastic and just keep growing like magic. You don’t need to worry about the details, that’s why you write the check every month. You no longer have to worry about risk when your data is in the cloud–after all, all the big companies are doing it.
• Blame the security department for a breach: The entire reason you have a security department is to prevent breaches. So, if you have a breach, then someone must not be doing their job. Never mind that you didn’t give them the responsibility, resources and accountability to get the job done, there are plenty of people out there looking for jobs. You can just wipe the slate clean and start over. The Board of Directors will then know you take security seriously.

There are others things you can do, but this should get you started. I wish you all of the failure you can hope for!

Never underestimate the potential of a motivated attacker–or a hungry rabbit.

Fairly confident in my beefed up garden security, I entered my garden to commune with my plants. They probably would have preferred water, but I am an earthy kind of guy.

Not five steps into the garden, what did I find? A small, hairy and rather surprised looking rabbit was looking up at me, as if in disbelief that I had entered his compound. But this time was different. He had a mouth full of greens. Oh, yeah. Cold busted.

Being the more intelligent species, I had a stroke of genius rather interesting thought. I would close the gate and chase him around the garden. By blocking his exit, I would now know the exfiltration point.

I closed the gate and turned with a start, confident in my stature. I might have resembled Chuck Norris at that very moment.

Quickly, I darted toward the bunny. He dashed! I pursued. He circled the corn! I matched his gate like a, well, middle-aged geek chasing a rabbit around his over-engineered and under-producing garden.

He stopped. I stopped. We stared at each other for what seemed like an eternity, but must have been only three or five seconds. I heard a noise to my left. I quickly turned my head and turned it back to the intruder’s position. He was gone. In that instant, he had managed to teleport himself to the other side of the fence. I grimaced and admitted losing this battle, but not the war. He had escaped and most importantly, hidden his escape route.

So what’s the security lesson here? This is a security blog after all, and it’s only right that I throw in some kind of security fluff to justify my obsession with hungry rabbits. The lesson, my friends, is that breaches are never truly over. You may have recovered and gone back to business, but there may still be a subtle back door in your network. The information that was lost still has to be accounted for and damages repaired. The lessons learned only build on previous lessons learned and contribute to the overall improvement of your security program. The recovery and lessons-learned stages may be the final stages of handling an incident, but, to borrow upon a favorite phrase of mine, eternal vigilance is the price of security.

*(&$#@!!

I stepped outside tonight to water the garden and what did I find? A fuzzy-tailed rabbit happily hanging out inside my garden–with the gate closed. My perimeter has been breached!

How did he get in? I am still doing an analysis, but I believe he squeezed in below the gate. He was a small bunny and this seems like the biggest vulnerability to exploit for a critter his size.

How can I close the hole? I am still pondering this, but I am thinking of something that works kind of like tire strips, which will hopefully dissuade him from crossing the perimeter. I might also post a picture of Chuck Norris for good measure.

I thought I should post this in the interest of full disclosure. It has been a long day.

I like to garden. Truth be told, I’m not very good at it. I get a little better every year, but I am not one of those people who can just look at a plant and make it grow.

This year I decided to get serious and build a 500 square-foot garden. So, being the technical type, I took measurements, used software to design the layout, researched planting dates, and of course, planned my garden security.

Plants have several threats. They are attacked by small animals like the rabbits in my yard, bugs, diseases, drought and the inattentiveness of geeks like me. Here are the threats I planned for, along with the corresponding countermeasures:

• Threat: small animals
• Countermeasures: Garden fence (perimeter security) and honey plants. I bought a fence with one-inch holes, which are too small for something like a rabbit to get through. I then dug a perimeter ditch and buried about 8-10 inches of the fence to protect against burrowing. Where the fence meets the house, I attached it with some screws to avoid the critter squeezing through a less well-protected area. To lure the small animals away from the main garden area, I plan to plant something like alfalfa in a five-gallon bucket. This is my “honey plant,” which will hopefully be more attractive due to its accessibility.

• Threat: Insects
• Countermeasures: BT, handpicking and honey (companion) plants. The primary defense against the “bad” insects is to plant other desirable plants with properties desirable to the “good” insects. The good insects then come along to check out the plants, see some tasty bugs and gobble them up. Plants like borage and yarrow are good at attracting good insects like lady bugs. The second countermeasure is simply to inspect the plants and pick off the bad insects. If all else fails, I can then resort to the safe chemical BT. It’s worth noting that I don’t need to get rid of all of the bad bugs. There is a point of acceptable risk where some bad bugs remain but my veggies are thriving.

• Threat: Infrequent watering
• Countermeasures: Paying more attention. I sometimes work late and forget to water my garden. The countermeasure here is simply to do a better job. It’s not unlike some of the manual processes we put into place in our security program when we recognize a deficiency. A future upgrade will integrate a soil moisture sensor into my home automation system, resulting in an automated system to detect the threat of lack of water and execute a response. It’s not unlike an OSSEC active response. :)

What’s the point of this post? The point is that information comes in many forms and we can use our information security skills in daily life. The information here comes in the form of vegetables. That’s what I am trying to protect. When viewed in the context of threats, vulnerabilities, risks, countermeasures and trade-offs, maybe this will be the year my garden thrives. Let’s hope for juicy tomatoes!

For the past couple of weeks, I have been reading with great interest the coverage of Sony deciding to bring suit against George Hotz. George, or GeoHot, as he is known, and others like him, hacked the PS3 after Sony removed the “Other OS” feature. It was this “Other OS” feature that appealed to people like George in the first place, since it allowed the more technical among us to use the PS3 in interesting ways–such as to run a custom version of Linux.

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.

I have a dirty little secret. It doesn’t have anything to do with the NSA, a leaked memo or pink leotards. But it’s a secret just as earth-shattering, just as awe-inspiring and just as potentially devastating as any other well-hidden secret that has been revealed. Intrigued? Ok, here it is: I have sometimes knowingly agreed to, or even recommended less than secure solutions. Let me give you a minute to collect yourselves.

Yeah, that’s right. Call the ISSA Ethics Committee. Call ISC(2). Call the President. I have been a bad, bad infosec professional. Do what you must, but I have a right to a defense. Allow me to explain my side of the story…

When I was just a young lad starting out in the security field, I had a pretty firm idea of what I thought it meant to be secure. I attended the right conferences, read the hardening guides and dutifully regurgitated what I had learned. Why would anyone choose to be insecure? I thought. That just didn’t make sense.  Security was about correctness. To be less-than-secure was like a mistake on an exam. It needed to be corrected.

As I went along, I learned that the take-it-or-leave-it approach had a few drawbacks. People didn’t really think the same way I did. They had their own jobs to worry about. When security got in the way, it was easier to route around it. When everyone was able to do their jobs every day, the “hackers are coming” argument became less and less effective.

Eventually, I noticed something interesting. The people that I had developed good relationships with were a bit more amenable to my suggestions. When I listened to the the challenges they faced and explained the benefits of what I was trying to do, they saw things in a different light. I made a bit more progress.

Today, I still try to build these important relationships. And when dealing with people who are not security minded, I am much more likely to make compromises. When asked to exclude a location from antivirus scanning that I know doesn’t need to be excluded, I might offer to make exclusions on read only, so that anything newly written will be scanned. When hardening a system, I might purposely leave out a setting that I think will likely cause the administrators to experience a lot of trouble and subsequently develop a negative association with security. I might even recommend that a risk not be addressed at this time, so as to focus limited resources on more important issues.

As infosec practitioners, we are the diplomats of our profession. We want others to come to us with security concerns, not try to route around us. We want to be partners with those we serve. And just like any other form of diplomacy, that involves compromise.