I liked this post by Curphey in relation to the SourceFire IPO. In fact, I like it because of how it portrays IDS/IPS and the typical installation.

[1:20:17 AM] XXXX-XXXX says: I’ve never been at a company where i’ve heard them say they were happy with their sourcefire deployment or for that matter… convinced me they were glad they made the purchase
[1:21:58 AM] XXXX-XXXX says: The security departments gets this new toy, they quickly figure out they dont have the time to babysit it (or configure it properly) then they outsource the monitoring
[1:23:02 AM] XXXX-XXXX says: once the monitoring company gets it.. they detune it as much as possible.
[1:24:44 AM] XXXX-XXXX says: What I see happening is “what do you mean this IPS might stop legit traffic? well lets just run it in IDS mode then”

[1:24:52 AM] XXXX-XXXX says: and after talking to XXXX-XXXX sales engineers
[1:25:02 AM] XXXX-XXXX says: 90% of XXXX-XXXX deployments are in IDS mode only
[1:25:40 AM] XXXX-XXXX says: Less then 5% of XXXX-XXXX deployments take advantage of the SSL decryption and analyze features.

While we have a larger and larger IT force doing things like desktop support and making sure the business world still works in the digital world, there is still a huge shortage of the type of geeks who “get it” and can make a difference with truly technical things. This is why the dashboard IDS/IPS has been superficially successful because it doesn’t require deep technical knowledge to get and click through alerts. But the knowledge of what those alerts means is pretty damn spotty and if the IDS/IPS doesn’t support tools to drilldown into the mucky darkness of the real technical trenches, that solution is overall just superficial.

But how do you know your out-sourcer is decent with security? Really, we shouldn’t move to make security a commodity that is driven by checklists and statistics without understanding. We need more skilled professionals, even if that means they have an inflated salary for a while and later take a small dip.

[10:15:40 AM] XXXX-XXXX says: Hey, I’m so glad you guys took over our security monitoring! We had no clue what was going on with the IDS/IPS after the installation techs left. You guys have helped us pass important compliance initiatives and haven’t impacted our business at all!

[10:18:23 AM] SecMonTech04 says: No problem! Looks like we came in just in time too! You had 12,476 alerts in the last month alone, but we’ve totally taken care of you! Just look how much you needed us!

[10:19:49 AM] XXXX-XXXX says: Sweet mother of all that is good and pure, that’s a lot! Whew! By the way, is that the number of alerts after you’ve tuned the monitoring?

[10:20:45 AM] SecMonTech04 says: Uh, yes.

[10:22:27 AM] XXXX-XXXX says: What did you all tune out?

[10:23:33 AM] SecMonTech04 says: Um, we ignore ARP alerts because it’s really just too noisy.

[10:24:12 AM] XXXX-XXXX says: That’s it?

[10:24:56 AM] SecMonTech04 says: I believe so…

[10:26:43 AM] XXXX-XXXX says: This is kind of odd. How many of those alerts are important enough to warrant further investigation or worry and wouldn’t ever be tuned out by anyone?

[10:29:42 AM] SecMonTech04 says: Looks like about 3…maybe 6 if I am paranoid.

[10:30:31 AM] XXXX-XXXX says: That’s it?

[10:31:21 AM] SecMonTech04 says: Oh, and we’re not really monitoring much on incoming port 80 because there’s too many application level attacks that we don’t want to give you a false sense of security about if we said we protected port 80.

[10:32:22 AM] XXXX-XXXX says: Huh? Why the hell not??

[10:34:45 AM] SecMonTech04 says: By the way, did you read the latest alerts from the anti-virus companies? The Internet is falling apart and is being overrun by hooligans and criminals. You better be glad you have us!

[10:37:32 AM] XXXX-XXXX says: Hold on a minute, back up. You’re not tuning anything out and not monitoring what might be one of our most important incoming ports. Are you actually blocking any attacks at all?

[10:39:12 AM] SecMonTech04 says: No, we’re operating in IDS-only mode. We don’t want to risk negatively impacting your business and cause you to distrust and dislike us.

[10:44:41 AM] XXXX-XXXX says: Oh god, I need some Tums…

[10:49:40 AM] XXXX-XXXX says: You realize we will need to start blocking some things?

[10:51:40 AM] SecMonTech04 says: Tell you what, we will turn in blocking (IPS mode) for all incoming ports between 55000 and 58000. Will that be enough?

[10:53:11 AM] XXXX-XXXX says: Whew, I think that will be ok…glad you guys are the experts.

[10:55:54 AM] SecMonTech04 says: Actually, we hire not only the inept techs you let go because you outsourced security, but we also employ interns who just click “ok” to every alert that comes in. They don’t really know what this means either.

[10:56:30 AM] XXXX-XXXX says: …I’ll assume you meant to type that in another window.

[10:59:10 AM] SecMonTech04 says: Oops, yes I did, sorry.

For once I am posting a question since it is something I have yet to be able to answer properly, but the bug keeps itching at me to answer it.

How do you physically locate a wireless user? Pretend you have a wireless network and someone has been getting in. Other than getting lucky and walking around, how do you locate someone efficiently?

Now, I know expensive and expansive solutions exist for larger campus-type wireless implementations to locate users using information on their signal strength and triangulation between overlapping wireless coverage. But what about for your average techie joe who wants to do this? Is there any software and non-expensive hardware that can help?

I also know that I could attempt attacks against a laptop and see if I can turn on an annoying WAV file and increase the sound…but that’s a bit too intrusive and variable.

I’ll likely troll a few forums and IRC chans looking for this information over the course of the next few months as I’d really like to answer it.

In case you missed this, the REcon 2006 presentation videos are available.

REcon is a Reverse Engineering Conference in Montreal. If you’re in that area and consider yourself part of the “in” crowd (or want to be) with reversing, you might want to check this out. Since I’m not exactly a reverser, I can’t attest to their quality. Perhaps the presentations might not be worth it, but the socializing and drinks with other geeks might be worth it.

I’ve watched the presentation by David “h1kari” Hulton on Breaking Wireless… Faster where he talks about FPGA and speeding up the cracking process (dramatically!). Of course, the chips themselves are dramatically costly, hehe. The demos don’t go over quite as smoothly as they could, but still a solid personality and presentation on wireless attacking by the author of coWPAtty.

It might be the hardest battle you will face as a security professional. It might cause the most grief, frustration, and exasperation. No, it’s not trying to make sure all your Windows servers perform smoothly. It’s not trying to fend off the dozen vendor calls that come in every day. It’s not even an entire weekend wasted because of some unknown glitch caused by someone else that brings down critical systems. And it’s not quite the often futile attempts to deter the insider attacks.

Quite possibly the hardest battle we will face is the battle to change the culture of a business from one that trusts everyone, particularly those “in the family,” to one that practices diligent security. Ever try to tell your Help Desk personnel that they should not ask for user passwords when doing some work over the user’s lunch hour so as not to disrupt their normal work day? Those same desktop people who typically are evaluated based on their customer service to those users? I’ve been in those shoes and I fully empathize. As a support person, you want to be able to bend over backwards if an important user needs you to; not to give a look of regret and explain that “security process” is tying their hands a bit and inconveniencing everyone.

Have you ever seen the look on senior management’s and human resources’ faces when you tell them they need to operate in a way where they don’t necessarily trust their own people? There’s not much more they brush off quite so quickly and easily than claims that their own people may be a threat, even an accidental one.

This battle can be easy in some compan…no. It can be easy in some organizational cultures. The military has ingrained security process very deeply. Larger corps are also a bit more successful in steering culture, especially those that might have real reason to hide things (think Boeing, Lockheed, or Microsoft, e.g.).

But the rest of us…yeah, the rest of us someday have to face those cultural battles where we should not be handing over passwords or being accomodating to persons whose username we may have seen but have never yet met when they ask for something beyond their typically level of access. Is this a new direction for the company that her department is shifting a bit and we have to compensate, or is this an attempt to get access to something she shouldn’t have? If we ask the manager to verify and/or authorize, will they just take the path of least resistance and kneejerk a “yeah sure, I approve” response? What kind of look do you get when you explain that perhaps their manager and then the data owner both need to approve access? Is it acceptance or a flash of genuine annoyance that you know will be spread around to anyone willing to hear?

And these are not things that are easily overcome with training and used education. It is one thing to educate a user about something they didn’t know previously and are open and receptive to the information. But it is another side of training altogether to tackle culture and paradigm shifts. This typically takes a lot of time and a lot of repeated training towards this aim (or just force it with technology and a big clue banana).

I admit, some places in this country might be easier to adjust attitude than Des Moines, Iowa where I live and work. We’re still a very open community and trust and customer service are pretty natural. Even “trust but verify” is a difficult adjustment. When does the line get crossed between being a helpful steward to a company versus practicing a dangerous habit?

Just like a courteous security guard who tends to recognize faces regularly, all it takes is one person out of 10,000 who walk by in a year to bury the company or disclose information that emboldens a competitor, jeopardizes a nation, and affects the livelihoods of your fellow workers. Just one person that is allowed to pass because he looks familiar (he was fired last week against his will), is dressed like a VIP, and looks like he’ll pin your manager’s ass to the wall if you inconvenience him, can be The One.

While my team has yet to convey a culture shift in the people that matter when it comes to security and customer service, at least we are still trying. We continue to implement technology to not only help cover the company’s ass in case our paranoia becomes reality, but we also try to maintain a foundation that if the direction of mgmt changes, we can quickly adjust and add on security as our openings allow.

(This post was partially inspired by Scott Wright’s recent post about the insider threat.)

Dave Aitel posted this to his mailing list today:

Next week is Shmoocon – and I’ll be there with whatever the latest
build of SILICA is in my pocket. Feel free to pull me aside for a
quick demo.

Man, Silica is about as expensive of a high class hooker, and it looks as good too! It’s sexy as all hell, and if I ever came up on a few grand to drop on a toy, I’d seriously think about this one (assuming I could get properly vetted). if any of you are at Schmoocon and see him (or maybe his wife too?) around, totally ask to see Silica in action.

Just posting a quick pair of links in case anyone is interested in reading about creating an exploit/buffer overflow. Trirat Puttaraksa discusses a Snort 2.6.1 DCE/RPC Preprocessor Remote Buffer Overflow. Part 1 is a DoS condition and part 2 goes into actual code excution. Very interesting, although beyond my abilities for now. Browse the rest of his blog for even more dissections.

I’m in a bitchy mood today and want to rant on something. This article from ComputerWorld about “How dangerous is Skype” came in at the wrong time.

First, let me just say that I am mixed in my feelings about IM and Skype in a corporate environment. I think this is a trend that, in the long run, will be a losing battle for corporate IT and security. IM is just part of our culture and life, and embracing technology for the betterment of people and the company does have weight. That’s not to say I want Skype in corp nets, but I can sit on either side of the fence comfortably. Encrypted network traffic is also part of our future, and we need to start dealing with it now instead of whining about it.

Here is my take on some of the “Skype FUD” or myths that Michael Gough tackles in his article.

Myth No. 1: Skype uses a lot of bandwidth on my network. Great, I’m glad that Michael Gough tells me that a voice call takes 30kbit/sec on my network. That’d be great if I allowed only one call at a time. Scale that out with your users and get back to me.

Myth No. 2: Any computer can be a Supernode. This is one of those beefs with Skype that has been around a long time, and I hated it because it’s not an issue in almost every corporate network. Michael is correct, you can’t be a supernode if you’re behind a NAT. But, that does mean, as Michael mentioned earlier, that your communications will be weirdly routed through someone else. Annoying, but really a non-issue in any NAT situation. (This may become a huge problem in IPv6 or it may become a big problem for Skype itself if less and less supernodes are available as people hide behind NAT or slow connections.) So, I agree with Michael: this is a myth.

Myth No. 3: Skype is susceptible to IM worms and viruses. Myth? What the crap? Is this the Apple defense about “well other IM apps have had lots and Skype none so that means security?” Yes, in part it is although he oddly mixes actual client vulnerabilities with malware sent via other IMs via file transfer. That inflates his “other IMs” numbers and keeps Skype’s really low. *sigh*

He also mentions that file transfer can be turned off (which it can be on other IM apps too) and files can be scanned by anti-virus (other IM apps as well). So, I’m not sure what he’s trying to say here, but I can illustrate that Skype is no different from other IM apps that have been hit with his 1,000+ issues.

I also challenge that “the main vulnerability of IM applications is their file transfer
feature.” I conjecture that links to malicious sites sent via IM is more dangerous. This “myth” from Michael is completely wrong, and Skype is absolutely no different from any other IM program.

Myth No. 4: Skype is hard to stop on my network. This really is a half-myth but I slightly dislike how Michael Gough tackles it. From the start, Skype was not hard to defeat: just block it from being able to authenticate and logon the user. Easy. I’m surprised he never mentions this; maybe this has changed. I also dislike that he attempts to defend the network by controlling the OS inventory and OS outbound connections. I don’t think this is the best approach, and Skype should be able to be blocked on the network by the network alone. I will admit, however, that stopping a P2P app on a network presents problems, so in a way, Michael’s approach is still solid advice. The real issue, though, is Skype should not have to be that hard to block on the layers it uses.

Myth No. 5: Skype is encrypted, so I can’t archive IM messages. This is a two-headed dragon and I’m surprised Michael Gough attempted to tackle this in either direction as a myth. Instead, he fumbles the ball:

This one’s not really a myth. Skype sessions are encrypted, so yes, you
can’t capture or archive Skype communications. The same is true of many
IM applications, though, so it’s not less secure than other IM programs
that can use encryption.

Bah! Yes, Skype is encrypted so you can’t archive it off the wire, but I’m not sure what settings and apps he uses to say that other IM programs are the same. I can sit down and monitor and grab IMs off the wire on every other popular IM program with default settings. Skype has this feature enabled by default whereas other IMs do not. In fact, I can turn off this setting on every IM program, but with Skype I absolutely cannot. Also, for an article that itself says it is geared to corporate networks as well as individuals, he ignores any issues with HIPAA or compliance that requires logging/archiving/monitoring of data egress via IM. For home users, this is an awesome feature to protect privacy. But this is maybe the biggest hurdle Skype has been facing when it comes to corporate use.

Just to add one more item. Until Skype settings can be controlled centrally, that is another hold in the argument for Skype in the corporate network. Let me centrally control and force settings, file transfer allowances, and yes, adjust encryption such that I can monitor data egress (note that I don’t necessarily want it cleartext). There are other considerations, but that’s all I’ll throw out for now. 🙂

If leaders can be humane and just, sharing both the gains and the troubles of the people, then the troops will be loyal and naturally identify with the interests of the leadership. -The Art of War, Chapter 1: On Assessment.

There are many ways to look at this quote. In regards to IT security, this immediately made me think about one of the biggest frustrations that senior management can give us: being above the policies. It is highly frustrating when people in leadership positions try to be above the security measures put in place due to their station or ego.

Likewise, as IT professionals we sometimes do have certain liberties and access above and beyond some policies, especially in testing or lab environments or on assessment systems, but by and large we also need to try our darnedest to not be exceptions.

The news of this tool is making the rounds, so I thought I’d post quick. Errata Security has partially released a tool called Ferret which purports to show what all is being leaked through your wireless connection everytime you use it.

How do you run it? Download the file and pull out the pre-compiled ferret.exe. Run it from a command line without options and it will tell you your network interfaces. Pick your interface and run ‘ferret.exe -i#’ to use that interface. Incidentally, you can use a wired or wireless connection if you’d like. (You might need winpcap, but I don’t know since I always have it installed anyway.)

The bottomline is this current tool is not as revolutionary as some news and mailing lists are stating. It is really just a sniffer that is only looking for specific data including broadcasts and some application data; things that anyone running any sniffer would be looking for (such as cleartext IMs, passwords, usernames, sites you visit…). Since this is meant for wireless networks, this stuff is typically “broadcast” anyway, due to the medium.

The real beauty will be in the next part of Ferret that they release, the visual/correlating tool.

Check it out, but if you’re used to looking at packet captures, don’t expect to be wowed right now.

There is question that seems to be boiling around, both now and in the past year or so. Where is security headed? Is security moving to the network/switches? Is security moving to the application and away from the OS? Is it moving to protect data at rest and transit? End-point security? Or just to meet compiance?

These are pretty big questions because it can shape the direction of a company for the next 5 years. I wish I had more answers beyond, “If you take any one approach, you may leave yourself weak in the others. If the whole industry does this, we’ll just have a wavering trend where for 10 years the network solidifies and gives way to applications and then 10 years where applications get hardened and network progress breaks down.” You can even push that out to technology vs training.

Just some interesting, largely rhetorical questions I keep in mind lately and would love to see discussed at length in the community.

CNN was kind enough to post an amazingly oddly placed article about the latest RINBOT/DELBOT/SDBOT variant

This is awesome because now what is otherwise a non-event is becoming something mgmt and normal users are asking me (us) about. Yay! So here’s some information to help point you in the right direction in case you get questioned.

As far as I know, only Symantec has this malware variant on their radar. Everyone else seems to be considering this one a minor blip on the radar.

In short, this malware strain is simply an infector for your run-of-the-mill botnet and is not a new threat. Variants of this bot have been around over a year, and this is the 9th (I believe) variant. The vulnerabilities this malware attacks have had available patches for months or longer.

RINBOT – Symantec/Trend name
DELBOT – Sophos name
SDBOT – McAfee name

This new variant spreads in three major fashions:
– Windows Server Service vulnerability (patched in August 2006)
– Symantec AV Client Vulnerability patched late last year
– IPC$ shares with common or no security
– some variants use email attachments

This is not a really new threat. You don’t have much to worry about if you do not use Symantec applications and you have patched your servers. Obviously, you also want inbound ports stopped on your perimeter. I won’t spam more links. The ones above should be sufficient.

I had planned out a couple posts. One was going to explain in no unclear terms that user training is broken and won’t help. The follow-up was going to be the opposite in how technology will not ever protect us without end-user training.

I decided to put that on hold and maybe not even post it, but I did want to blab about something else I see in the IT and security communities. I see a lot of very polar opinions on how things should be. You have user training versus technological controls. ROI vs insurance. Business skills vs technical skills. Full-disclosure vs alternatives in either direction. Black hat vs white hat. Perimeter is dead vs perimeter is impoant.

The bottomline? All of these approaches are correct and all should be practiced to some extent. Just like all those diet fads, stick solely to one for a long period of time and you’ll have new problems. But if you took the basic concepts from many, you can end up with a very effective approach.

There is a place for each extreme, but they are all necessary and need to be balanced. There are also people who, for instance, can be mired completely in the technical realms and leave the businesspeak to their bosses and not only be successful personally, but help drive their company to success. The balance doesn’t have to be in each individual, but a department can achieve balance with imbalanced parts. Then again, even imbalance will work depending on the corporate culture, needs, and outside influences.