The Immutable Friday Fav Five

August 26th, 2011 No comments

One of the reasons I started this blog was to share things I had encountered in the security and privacy world. I have done quite a bit of editorializing, but not too many of the quick and useful posts. I thought it might be helpful to post about five of my favorite reads and links on Fridays–unless I get too busy. So let’s start off with a few interesting links:

  • PacketFence is a free and open source NAC system. I haven’t used it so I can’t vouch for it either way, but it’s nice to see a NAC in the free software world. NACs are good at preventing things like man-in-the-middle attacks, help you with asset control and help to keep the worm-of-the-day off your network when a contractor plugs in his laptop. Free software can also be a good way to meet a requirement even with limited or no budgets.
  • Need a forensics tool? Maltego may fit the bill. It’s also free to use, but not free software in the sense that it doesn’t seem to have an OSI compatible license. Like PacketFence, there are also commercial support and versions available.
  • Jamie Riden wrote a very nice piece on his/her response to an SSH attack. There are some nice recovery and lessons-learned aspects to the article. Another possible countermeasure would be the use of OSSEC along with its active response capabilities. This might have been able to prevent the compromise entirely.
  • Would you like to have a log of all commands entered on a Cisco router? This is something that can be very useful for audit and compliance, as well as change management needs. This is a great one for PCI environments.
  • The ‘nix mtr tool can be useful for troubleshooting network problems. The WinMTR does pretty much the same thing from a Windows host. It’s also free software.

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

 

How to Suck at Security for Executive Management

August 22nd, 2011 2 comments

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!

Categories: Risk Management, Secure Design Tags:

Garden Security III: The Houdini Hare

August 3rd, 2011 No comments

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.

OSSEC 2.6 Released

July 20th, 2011 No comments

The OSSEC team is pleased to announce the general availability of v2.6. This version includes support for IPV6, a new tool for key management of ‘nix agents, an option to increase the block timeout for repeat offenders, and many other goodies.

Major kudos for this release go to Dan Parriott (ddpbsd). Dan is the most active person helping OSSEC users today on the mailing list and IRC. He also seems to find time to write documentation, which–let’s face it–no one really likes to do, and writes new rules and decoders. Thanks, Dan.

If you would like to see what I am up to in the OSSEC world, check out my repository on Bitbucket. My commits are generally tested and ready for integration into the next release, so try them out and let me know how they work for you. The tickets section is basically my task list of things I am already working on or plan to implement.

As always, thanks to everyone who contributes and supports our work. If you have some free time, stop by #ossec on freenode to say hi.

Garden Security II: The Bunny Breach

June 16th, 2011 2 comments

*(&$#@!!

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.

Garden Security

June 11th, 2011 No comments

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!

Categories: Risk Management, Secure Design Tags:

Why Some Merchants Should Not Worry About PCI Part II

May 9th, 2011 No comments

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.

Categories: Dialogue, Risk Management, Standards Tags:

Why Some Merchants Should Not Worry About PCI

May 7th, 2011 5 comments

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.

Categories: Dialogue, Risk Management, Standards Tags:

15 – Emergency Phone Number Dialed

April 15th, 2011 3 comments

One of the things I have been trying to do lately with OSSEC is to bring it into the “real world.” I have been exploring how to add support for useful and interesting devices such as phones, TVs and facility alarm systems. I have been tinkering with one device, a VoIP ATA adapter made by Grandstream and I thought I would share what I had come up with. You’ll probably see this in a future release of OSSEC, so let me know what you think.

There are a couple of interesting (to me, anyway) rules. One of them is when someone dials an emergency number like 911. This might be useful if you have family members at home and you are out and about. In fact, I am somewhat sorry to say that this one proved to be effective very recently in an actual emergency (everything is OK now).

Another useful rule might be the one which tracks calls to premium-rate numbers (think psychics and sex lines). If someone is doing that, you may (or may not) want to know about it right away to avoid a huge bill.

Businesses could write rules to be alerted when a competitor’s number is dialed. It might be nothing, but what if it happens only during hours when the boss isn’t around?

These rules do not detect traditional IP-based attacks, but we can certainly expand them to do so. The point is simply that you may be able to use OSSEC in ways that you didn’t originally conceive.

If you have a Grandstream 286, 502 or 503 ATA adapter, download these files and check it out. The grandstream_decoder.txt stuff can go in your local_decoder.xml and the grandstream_rules.txt can be placed in your local_rules.xml (watch for rule ID collisions).

Let me know if you run into any problems. What interesting things have you done recently with OSSEC?

Categories: Log Analysis Tags:

How to Configure Auditing for Dozens of Enterprise Systems

March 23rd, 2011 No comments

Open source log analysis types sometimes need to be crafty. We often don’t have relationships with the companies who’s products we support, but that doesn’t stop the users from wanting to use software like OSSEC to analyze logs from big, enterprise-type closed source stuff.

We scour the Internet for log samples and documentation–anything, really–that might help us out.  So today when I came across some documentation for IBM’s Compliance Insight Manager, I thought I would pass along what I found.

Under the Configuring auditing for specific platforms section, you’ll find instructions on how to configure auditing for dozens of enterprise systems. It even goes far beyond what to click or which file to edit. There is info on audit capabilities, monitoring recommendations, suggested audit settings and tuning.

This is a worthwhile resource to bookmark. Until next time..

Categories: Log Analysis, Log Management Tags: