I liked this article on the NYTimes site about email uses and abuses. How do you stop people from forwarding work email to a place they shouldn’t, such as web-based mail services?

Well, the answer is that you can’t, and you really don’t need to bother trying to do so. Where I work we block port 25 outbound except when from certain servers which have strict relaying settings. We also utilize SurfControl which cuts into web-based email services such as Gmail, Yahoo, Hotmail, Hushmail, etc. The problem is that I can still just find a service so obscure that the filters don’t catch it…such as my own mail server. Or I can just tunnel over something else and get there. But you still really can’t stop me from e-mailing a Gmail account any more than any other account unless a company has really no business communicating with the world outside its own walls.

So what do you do? In something like this, it helps to realize and accept that prevention is impossible. In that case, how to you mitigate, minimize, log, audit, and CYA without being a barrier to the company’s purpose?

1) Evaluate why your users would want to send email to their home-based email accounts, particular webmail. Most users are not malicious and are only trying to get work done in the easiest way they know how. Maybe they want to work from home. In that case, provide web-based access or, better yet, a full-featured way to connect to their work account from home without all the additional hoops of a VPN and such. People using Exchange have little excuse to not be using OWA and a nicely-featured web front end. Ask why the users are doing these things, and then provide them such easy and logical solutions so they don’t try to circumvent the process.

2) Obviously, log outgoing mail. If someone does keep trying to email out sensitive information, logs are necessary to track it. There should be one or two levels of logging. First, log all mail headers incoming and outgoing so that you can track activity. Second, such as in the article’s hospital example, filter and log data in mail that is leaving the network, for instance medical records and other personal information. Obviously the second level of logging is more intensive, and shouldn’t be bothered with unless the company has particular need.

3) Retain the ability to monitor employee email usage down to even reading their email. While this ability shouldn’t be exercised all that often (how many employees are happy about others reading their email, honestly? and how many unhappy employees are the productive employees?), the policy should keep this option open in the event of suspicious about a truly malicious user. Authorization should be limited to HR, a direct manager or two, or approved technical staff, with no party acting alone. This is easier in some organizations and more difficult in others that have different work/life balance expectations in employees. The more an organization is sympathetic to the converging role of technology at work in personal life (kinda like personal phone calls to the doctor), the less hands-on the policy should be. Some companies will actually need to have staff regularly reading actual emails for regulations complicancy, and that’s fine, too, when needed.

4) Block outgiong 25 and incoming 110 (and other common ports, like Gmail’s ports) to only authorized servers. This won’t stop people from web-based email or completely non-standard setups (I can tunnel it on any port I want, really), but at least a huge swath of people will be prevented from storing and sending email from their workstation mail client. Besides saving storage space and resources, no one needs to accidentally send out an email to a client from their PajamaMonkey69 email account at Yahoo. Also keep tight control on mail relay settings for those approved mail servers. Attempts should be logged and investigated, especially when originating internally.

5) Software policy should drastically limit user email clients to one (maybe two) approved email client applications. Make things as standard as possible. Manage that app properly.

6) Education. Education is not a panacea, but at least educate and teach employees how to use the tools given to them, and why circumventing them can put the company, themselves, and their clients at risk needlessly. This also should help draw out difficulties they may have with the tools and maybe expose why they circumvent policies in the first place.

I didn’t get but three paragraphs into Bruce Schneier’s latest wired.com article about secure passwords, and I came across, “Your encryption program’s key-escrow system is almost certainly more vulnerable than your password, as is any “secret question” you’ve set up in case you forget your password.”

How often do botnet herders need to break into a system by gaining access to the password? And once they get in, how often do they actually ever care about the password? Not often, I suspect. Why care about the password if the user runs your program as their already-auth’ed credential? Why worry about laptop encryption when the user is already logged on? How often have I seen someone walk away from their laptop at Panera or Starbucks and not lock it? Point taken, though, that passwords, while targeted and popular, are maybe not the weakest link any more, just like network-borne attacks are quiet compared to fashionable web app attacks lately.

I’ll put up a better link later when I find one, but a recent presentation and paper (I printed them out yesterday but have not read them yet) on a Snort algorithmic vulnerability has been talked about and patched. The vuln would cause Snort to spike the cpu to 100% and eventually crash. Why is this useful? This is a lot like someone cutting off the alarm systems before robbing a bank. You can even do this externally if a company has Snort running outside the firewall (not uncommon in order to determine differences across the perimeter defenses) and that same server is running the inside Snort instance. Since this is an easy but technical exploit, I suspect this to be packaged eventually into attack toolkits rather quietly. I would suspect old Snort instances may stay in production for years in some cases.

From Whitedust, I was pointed to this interesting article about employees who have left Google. I am inspired by hearing that a number of these people were far older than I am now when they started at Google. Sometimes one gets bogged down with that thought that only happenin’ things occur to the brightest students fresh out of college doing amazing things. That’s the flashy story you always hear. That if you don’t jump up high enough out the doors onto the rungs of the career ladder, you’ll burn out before getting up higher where you want to be. Really, that’s not true, and that’s something to continue to look forward to through my entire career and life, to be honest.

I’m still settling into what I want this blog to be, so please bear with me. I’m also ramping up my studying for the CCNA which I need to make sure I take sooner than later and get it done with, plus all my other smaller projects at home. This weekend we are scheduled to get lots of freezing rain and about 3-7 inches of snow Sunday. Unlike other parts of the country, though, we’re used to it and life moves on just fine and the Internets don’t disappear with the power when some flakes drop!

Turns out Andy ITGuy also has the same Art of War desk calendar that I have and posted some feedback on this entry yesterday:

“Generals in the field must already be acquainted with all the sciences of warfare before they can command their own soldiers and assess battle formations.” Chapter 3: Planning the Attack

It took me an extra day to revisit this topic, but I think this is a difficult place in security management and IT management. It is difficult to know so much about the sciences of our warfare. It seems difficult enough to even brush against all the various topics that need to be dealt with. I’ve worked for managers that couldn’t do my job for the life of them, and they never commanded the trust or respect of the teams they managed. I’ve also worked for managers who could do my job, and they were much more effective in all aspects. But there is still so much to be informed about these days.

I’ve worked with SSL extensively, as has any sysadmin that knows what a web server and SSL certs are. But what about the real dirty guts of SSL? Sometimes, topics like this are difficult to grasp, but I found something that made enough sense to me that I re-wrote the process of an SSL session negotiation on a piece of scratch paper just to visualize it. Palisade has a question and answer about SSL which is written in very plain English for an intermediate to understand, and it actually makes complete sense to me! Other quiz questions are also available, although some are a little less interesting to me. Reading about HTTP cache smuggling is interesting (and makes sense, since you can hijack HTTP connections anyway, which can be fun on wireless with airpwn). .NET best practices are not quite as interesting to me right now.

Ever since Joat made mention of purchasing one, I’ve been eyeing the Wi-Spy and have it marked up on my “to buy” list for the future. Today, though, I see Joat received an email informing him that the price was going to go up in February. In fact, it is doubling. This little tool is far too cool to let pass away at a higher price. As far as I know, anything comparable is many hundreds of dollars more expensive, so I might move this up my list and get it in the next week or so. It can be bought off ThinkGeek as well as the manuf. site.

Just what I need, another feed/link/dashboard! But I will say I kinda like what Security Database has put up. I especially like the security tools alerts which are RSS-able.

It amazes me how slowly wireless has been tackled, especially as everyone has completely jumped on Office products and browsers with all sorts of problems. Perhaps this year will usher in some more changes?

By way of Whitedust, I was pointed over to a pair of NetworkWorld articles. The first deals with new laws and guidelines about business-run wireless networks, both public and those intended to be private. In addition, it tackles vendors who should not default insecure or at least give users some guidance on securing those devices. These are seemingly easy and no-brainer topics, but yet implementation is such that I am astounded about the lack of attention wireless technologies receive. Heck, even insecure cell phones get more press compared to the data networks! The second talks a little bit about 802.1X (in that sort-of-technical-but-not-really-technical way the NetworkWorld writes).

More laws make me happy when it comes to securing wireless and our digital world. But more laws also make me say, “D’oh!” a few more times, since I am one of those people who likes to drive around and see what open wireless networks there are, and hopping on one when I have a need (when traveling or at a friend’s place, for instance, and just hopping on an open neighbor network).

It is interesting to hear us be adamant about perfection in security, whether it be perfect devices, perfect approaches, or perfect coding. Really, digital integrity pales compared to personal safety. Do we expect perfection in being safe when on the road? Do we demand that cars be built to absolutely withstand the stupidity of drivers? Do we move to diminish the role of the user when driving? Do we do much beyond laws, liability, some technological improvements, and a common understanding that green is go, red is stop, yellow is speed up and pretend not to notice anyone else, and lines are guidelines on traffic flow except in parking lots where they are so much street grafitti? Ever try to play traffic cop in your car, where the guy behind you wants to speed and basically blows out his O-ring having a caniption fit behind you while you drive the limit (yeah, me too, it’s fun because I can be a dick now and then).

It is interesting that we accept a certain level of reasonality when it comes to our safety in life, but become hardassess when talking about digital security.

Have we achieved perfection in physical security, whether it be at home or in the workplace? It might sound like I am being defeatist. On the contrary, I say this all very enthusiastically. Update: I am going to amend, but not remove my original post above. Yes, there are differences in my choice of analogy and the security world. In too many cases, we don’t end up living with our bad choices on the road, but in digital insecurity, we end up living with them. Ask any identity theft victim how hellish their life has been since. Likewise, I accidentally dismissed one thing I thump a lot when it comes to the digital life: efficiency. If a traffic accident were like a digital security incident, then one accident might end up affecting every single car built in 2003 in the state that is currently on the road, and when others currently at rest get started up in the morning, they immediately suffer the same result. One obscure issue in MySpace that only 50 people even understand could result in a worm that affects many thousands of people.

Ordinary people see the means of victory but do not know the forms by which to ensure victory. -The Art of War Chapter 4: Formation

Am digging into my inner wireless geek this month as well. This means buying a little bit more hardware. Most of this stuff is best available on eBay and I plan to get my hands on some of these things soon.

Orinoco Classic Gold wireless PCMCIA card x2
Sharp Zaurus SL-6000
AmbiCom compact flash wireless card (or similar)

The Sharp Zaurus runs on Linux and has internal wireless. This means I can run Kismet on it. I already have an older Dell Axim X5 that I picked up at my old job and totally forgot I still had (and if I want another one for some reason, they seem dirt cheap on eBay). It has no internal wireless and runs Windows PocketPC, but I can put the compact flash wireless in this guy and get it to run. It also gives me the ability to run Ministumbler if I wanted to. I’d rather use Kismet and the Zaurus, but I got lucky in already possessing a little-used Axim.

Now, why would I want both Kismet and Ministumbler? First, some people simply respond better or worse to Linux or Windows. If I don’t want to show someone how to do wireless tricks, I’ll glaze their eyes over with Linux. If I’m looking to impress a gir…err…a manager with pretty colors and graphs so they spend money on or for me, I may get better results on Windows and Ministumbler. Second, Ministumbler is an active recon tool, so it will only see networks that have the SSID broadcast. Kismet is passive. While it will see non-broadcast SSID networks, I’m not yet sure how it sees them if there is no traffic on them..

Now I just need to pick out a GPS unit (I don’t want to spend much, I’m not an extreme outdoorsman who needs something amazing) and possibly decide if I want to explore an external antenna or hold off on that. All told, I don’t expect to spend more than $60 on the wireless cards and maybe $200 on the Zaurus.

Also just saw this 2-part article on SecurityFocus about wireless forensics.

Not a huge deal, but it looks like one of those nicer sites that I don’t see many people talk about has had a facelift. Whitedust doesn’t display correctly for me at work on IE7, but it does look like they have ramped up their news coverage and now report quite a wide array of things in the RSS feed. Their news reminds me a lot of Rootsecure: some news, some articles, some podcasts, and so on. Always been some good stuff there despite them being a relative new-comer to the scene and UK-based.

One of my favorite questions to ask pen-testers or other security assessors is how often they are successful and what techniques are the most successful. I imagine social engineering and physical attacks have a very high rate of success; in fact, I wouldn’t bat an eyelash if pen-testers claim those are 100% successful when attempted. I’m sure there are many other ways they can own a network, but when they run into a tough cookie to break, I wouldn’t be surprised if those methods combined with some wire sniffing yields positive results almost all the time. This article I read this morning caught my imagination:

Core Security Technologies has never failed in its spear phishing tests
against large organizations, Caceres said, an indication of the task DOD
faces as it attempts to battle its latest network threat. The human
factor which requires e-mail users to carefully examine their messages,
plays a critical role in defeating spear phishing, Caceres said.

I think this is why discussion on user education is still rather mixed. Most everywhere I read that user education is necessary as we build security awareness and programs in organizations, with this as proof that we need more education. Others will claim that user education is not going to solve this, and we should focus more on technology and other aspects. They will also cite these results by saying that getting intelligent users who consistently make the correct decisions is a losing battle.

At any rate, I love hearing about success rates and common means of access into networks. Jeremiah Grossman has been doing a related survey for web application specialists for a few months now, and has been quite readily and hungrily accepted.

I wonder if there are similar surveys or data for pen-testers?

Update: Of interest, Dana Epp pointed me over to a presentation on combating social engineering.