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:

• 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!

Virtualization is a quickly growing area in IT right now. The prospect of running dozens of virtual servers on one physical server is most appealing. As long as licensing costs don’t eat up too many of the savings, it really does have the potential to transform an infrastructure into something much more efficient.

Of course, with any new technologies there are risks. Sometimes the risks are completely new and sometimes they are the same risks we have been dealing with for years — just repackaged in a slightly different way.

When most people think of virtualization security, they think of things like breaking out of the guest machine onto the host. This would be a very serious attack if successful because it has the potential to leverage one attack into something that can compromise several hosts. Even malware is getting into the business. The Blue Pill proof-of-concept used a small hypervisor to intercept calls to and from the guest, thereby controlling it according to desires of the attacker.

These are real threats, but for most organizations they do not represent the most serious threats to virtualized hosts. I was reminded of this last week when I read about Jason Cornish, a former IT employee of drug maker Shionogi. Jason had a beef with his former employer and he took it out by logging in and deleting 88 virtualized hosts. That’s the functional equivalent of a tornado taking out a small data center. He was able to do this simply because of a password which was not changed upon his termination, thereby allowing him remote access.

What’s the lesson here? The point is that we cannot forget the fundamentals of information security when implementing new technologies. That means doing the non-sexy stuff like changing default passwords, revoking access immediately for terminated employees and sending logs to a centralized log server. In the virtual world, we might review the access levels of the virtual administrators to make sure they are appropriate, separate hosts of different sensitivities onto different hypervisors and get alerted when a virtual machine is added, deleted or moved.

We do need to keep an eye on evolving virtual security threats, but we also have to keep the other eye on the fundamentals. We need both.

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!

Yesterday, I wrote a post saying that the lady who cuts my hair needs to comply with 100% of the PCI standard. This was based on my experience in PCI in corporate environments, some of which do not actually store card holder data and are pretty low volume.

Saying that all merchants must adhere to 100% of the entire standard is wrong. The correct statement is that all merchants must adhere to 100% of whichever SAQ Validation Type applies to them. The different validation types do indeed enforce only a small subset of the standard on many merchants, which was pretty much my major beef with PCI.

So, there you have it. PCI does have some reasonable requirements in place, depending on the circumstances of the transaction. I stand corrected.

When I had my hair cut today, I got to thinking about what level of responsibility this small business should have to protect my credit card data. This is not some big chain. It’s one lady with a couple of employees to help out. She knows as much about computers as my Mom, which, no offense to Mom, is not a whole lot. It’s not that she (or Mom) isn’t smart, it’s just that they are ordinary non-computer folks. They have skill sets in different areas, and that does not make them any better or worse than a tech-savvy person.

Although she probably doesn’t even realize it, Lisa (the hair lady) is supposed to comply with PCI. She doesn’t even get a break for just having a card terminal. She has to comply with the entire standard. Some sections will not apply, such as if she does not store the card data, but she doesn’t get a “just the hair lady” break.

I think she should.

Don’t get me wrong, I actually think PCI is one of the best standards out there. Since it is so prescriptive, it doesn’t leave a whole lot of wiggle room for larger companies to justify their way out of it. It absolutely can lead to better security. I have witnessed it. But it is not a one-size-fits-all standard.

It’s unreasonable for merchants like Lisa to be expected to act like companies with security departments and dedicated budgets for lots of fancy controls. So while this may not be the expected position of a security professional, I can’t ignore that little voice in my head that says she should just do what she does well–that is cut hair–and not worry too much about credit card security. PCI is not a law, and the chance of her suffering extensive damage from a credit card breach is small. A few reasonable precautions are all she should have to worry about. Anything else is a design failure of the credit card system and should be addressed there.

Update: Be sure to read the follow-up post where I stand corrected.

Sometime when I wasn’t paying attention, a bunch of marketing folds must have gotten together to come up with a new, catchy acronym. I imagine the meeting must have gone something like this:

Joe: We’re not selling enough of our <insert product here>. We need a way to really connect with people.

Linda: The problem is branding. Cross-site Request Forgery doesn’t really roll off the tongue too well.

Bill: Hmm… Advanced.. Problem.. Fixer..

Tom: That’s a good start. How about Advanced Persistent.. Software..?

Joe: Wait for it… Advanced Persistent Threat!

All in unison: Awesome! Let’s go for drinks.

OK, so maybe it didn’t go down exactly that way, but it’s fun to imagine.

So, what exactly is an Advanced Persistent Threat, or APT? According to Wikipedia, APT attacks utilize traditional attack vectors such as malware and social engineering, but also extend to advanced attacks such as satellite imaging. It’s a low-and-slow attack, designed to go undetected.  Finally, there is a specific objective behind it, rather than the incoherent activity of some fifteen-year-old hacking away in a basement for brownie points with his buddies.

It’s not just vendors getting in on the game–companies are increasingly blaming their security failures on APT, as if it was far too sophisticated for them to possibly defend against.

There’s no doubt that such attacks exist. Corporate espionage and nation-state attacks are very real and, in some cases, extremely sophisticated. But these attacks are very rare. The truth is that the vast majority of attacks are not very advanced because they don’t need to be. It is extremely difficult to defend against all known attack vectors. The defenders have to get everything right, all of the time. The attackers only have to find one or a few small holes to work their way in. That’s just the current state of information security.

I think we should generally avoid using the term Advanced Persistent Threat. There are two main reasons I feel this way.

1. It’s highly likely that it’s not an APT at all. Even if you have a great security program with the smartest security people in the world, a company of any appreciable size is going to have hundreds of ways in. You can have everything patched and the front-desk lady will give up her password. You can require two-factor authentication for all remote access until the smart phones come along. You can have great perimeter security until your business partner gets compromised, and you realize that your perimeter really doesn’t begin and end at the firewall. Face it, your company is insecure on its best day.
2. Using terms such as APT, while sexy, encourage us to gloss over the actual facts. Just as intellectual property is a way of lumping together things like copyright and trademark, APT discussions keep us from focusing on which attacks were actually used and how our defenses failed. There is no APT attack. There are SQL injection attacks. There are social engineering attacks. There are buffer overflows in software. There are default passwords left on systems. There are insecure trust relationships. APT is a dangerous umbrella term.

Even those few who do face what people call APT attacks need to break them down into their core elements in order to understand and defend against them. For the rest of us, let’s go back to discussing how our security design failures could lead to a compromise. And if one should occur, let’s speak to the specifics of the attacks so we can learn our lesson, even if a little humility is in order.