What better time to release a blog-inspiring IT security article in the Wall Street Journal than when half the crowd is in Vegas for the week? Yes, the WSJ posted 10 Things Your IT Department Won’t Tell You, which really should be reworded, 10 Ways to Circumvent Your IT Department’s Restrictions. Here are some notes of mine on the article as a whole.

A. The author needs to stress further that employees should look at their corporate policies and talk to their IT staff. Sometimes it just takes user interest to get management to look at legit technological solutions to the below problems, not workers sneaking around. I wonder if the WSJ wouldn’t mind if its editors sent all their email to a third party service or stored their files online? It would just be nice if the author had constantly (or at least at the beginning) reminded readers that while this is all in good fun, they can be crossing policy lines.

B. The author implies, or rather nearly flat-out states, that these items are part of a rather strict and unfriendly IT security stance. This is really not so. Some things like blocking certain websites are done almost as much for saving bandwidth costs as anything, or to prevent such things as porn viewing which can create a hostile work environment. Other things like email size requirements can be an external limitation by the Internet infrastructure at large (i.e. your target’s mail servers). Likewise, storage is cheap, but try telling that to senior management when the Exchange servers start complaining and buckling and backups take too long. Alleviating that means spending money. And often management figures that money is better saved and file sizes remain reasonable. IT security is not the only force here, but rather simple economics in the IT world. Really, often it comes down to treating everyone equally and costs.

C. Contrary to what every non-IT person seems to think, IT pros do not know everything or every piece of software. Limitations are often made so that we have a finite job description. Supporting every piece of software that even 50 users can install is frustrating and a drain on company money.

D. I don’t like the feeling that the author’s Risks sections are skewed to the POV of the user, and not the business as a whole and how dangerous some of these practices may be. Some are properly framed while others are not.

E. That all said, I think this is an important article. It illustrates the common pains our users (and we as well!!) have when it comes to the convergence of work, culture, technology, and social lives. Each of these pain points should be fixed by IT, or at least the policy behind them transparent to the constituents. Each of these should also be examined to see if, instead of benefiting the company and our employees as people, we’re holding them back and trying in vain to stem the tides of culture and progress.

1. HOW TO SEND GIANT FILES – How many companies really do need to send giant files and don’t have any sort of FTP/SFTP infrastructure? No, your baby pictures in bitmap format and 10 times as big as modern monitor resolutions do not count as a business case. I am saddened to see the author tell users to look for the IE lock symbol as reassurance of validity, and that a Verisign logo further ensures the identity of the site. No, that’s not enough, sorry. Oh, and if an Adobe exec runs it, it is less likely to have security holes. Say what? Anyway, IT does need a plan for transferring large files anyway, so get one. Everyone, and I mean everyone, hits the attachment max at some point. Hell, even Gmail has a max; live with it.

2. HOW TO USE SOFTWARE THAT YOUR COMPANY WON’T LET YOU DOWNLOAD – This one really peeves me, because I’ve too often seen a) malware enter because someone wanted certain software, b) computers become unusable due to crappy software or incompatibilities with business software, and c) frustrated users who then frustrate IT because they MUST have some backwater POS software installed or they will quit, or something equally outlandish. The bane of all IT is having to support everyone’s crap. Yes, I’m jaded on this point, but there is usually a process of requesting and approving software for use in the business. Good IT will log all executed software, and query on why they were run. And be aware of your company size. Small companies can likely get more software approved, but large or medium companies just cannot scale IT to support every little thing.

3. HOW TO VISIT THE WEB SITES YOUR COMPANY BLOCKS – First, web-based email is not innocuous. Second, if your company blocks these sites actively, your proxy calls will likely be logged as well. If you need a site opened up or something, ask your manager, HR, or IT. If it is Final Four season and you can’t stream the first round games, well, sorry, but we can’t bring the internet access to a crawl just to see a 15 seed get crushed by a 2 seed in a game that will be played regardless if you are watching or not. And no, you can’t connect to GoToMyPC.

4. HOW TO CLEAR YOUR TRACKS ON YOUR WORK LAPTOP – I really like the author saying, “…don’t use your work computer to do anything you wouldn’t want your boss to know about.” That’s it in a nutshell right there; that should be everyone’s personal policy.

5. HOW TO SEARCH FOR YOUR WORK DOCUMENTS FROM HOME – Ugh. Don’t ask your IT admin to help you set up Google Desktop. Bad. Ask how you can get set up with a VPN connection from home that is secure and allows you access to your computer or a file store. The author stupidly says three things that he/she should have put together. “…top-secret financial information…” and “…search company keeps a copy of your documents on its own server…” and “…myriad state laws regulate how a company has to react when it loses private information…” If you play the “duh” game, you see that you might have to provide some answers why you are allowing top secret, possibly regulated, information to be stored on third-party servers. Good job.

6. HOW TO STORE WORK FILES ONLINE – Like web-based email services, thinking too much about this problem creates ulcers. Yes, I’d like to encourage my users to store their files on third party services, because then they can store megs and gigs of company data out there, then quit (or god forbid get fired), and leave the company with absolutely no means to recover, inventory, or secure that data. Brilliant. These services should be stopped via web filters and software install restrictions, let alone via policy. Oh, and kudos to the author to recommend USB and other portable devices in item #2, then calling them cumbersome in this one.

7. HOW TO KEEP YOUR PRIVACY WHEN USING WEB EMAIL – These “nifty tricks” can spell doom for compliance, if that is your company’s game. Tracking this stuff is such a grey area it’s sick. Honestly, I don’t like my stuff logged for perusal by my manager or HR; I really am part of the generation whose social lives tend to revolve around electronic means. But I do prefer to have things logged just in case, from both my personal POV and from the company POV. We need to make sure our processes and actions are transparent so that employees don’t think we’re reading their IM/email logs to get juicy gossip details. Chances are not good for that happening, sadly.

8. HOW TO ACCESS YOUR WORK EMAIL REMOTELY WHEN YOUR COMPANY WON’T SPRING FOR A BLACKBERRY – Another ulcer about data free-flowing out the company door, but at least the author implores readers to talk to IT.

9. HOW TO ACCESS YOUR PERSONAL EMAIL ON YOUR BLACKBERRY – I don’t see a huge problem with this, until you a) run that attachment…oops, that was a virus and screw things u, b) can’t get it to work and ask IT in which case we’ll tell you no and watch you closer, or c) email that really important client from…oops, your personal email hotjerkyboy69foru from hotmail. Explain that to your boss…

The last one is just a light-hearted gimme; a lame contrivance of journalistic levity.

In the end, all of this comes down to a few protections by IT that can make a lot of these issues be blocked properly:
i. software restrictions based on policy and technology, including executable logging
ii. web filtering, or at least logging if not outright blocking
iii. data privacy/sensitivity training and strict adherence to least privilege access rights, better yet, full logging of all data downloaded/viewed, but good luck with that
iv. work with your users to overcome these challenges and find a happy middle ground

Here is a quick paper (notes) about pen-testing a Windows Active Directory network. While I do know this paper covers only the lowest-hanging fruit, it seems that all too often, these lowest-hanging fruit are the most common fruit found in the wild.

I will add to make sure and grab the cached logins on the workstations attacked as well. Often, systems cache the default last 10 accounts, which almost always includes at least one admin-type account from desktop support or the person who made the image in the first place.

If you crack the local admin password, don’t just use it on other systems, but try to change obvious things in the password. If they’re not the same across the department or even the company, often desktop support has some sort of predictable password scheme based on the computer name or user name or department. Heck, even I had a predictable one back when I did support, but you really had to work to guess it and I left plenty of red herrings laying around (like having the second half of the hash crack into a known word or just lower-case letters to throw off how complex the first half was…)

I have protection on my SSH ports, but I wouldn’t mind more. Honestly, it can’t really hurt. This article by Kevin van Zonneveld on adding brute force protection to iptables (and your Ubuntu install) to help secure your SSH is a welcome addition. Far too often I read tidbits like this that stop at the first step: adding the iptables rules, and leave out all this other good stuff that Kevin goes into, like rummaging in cron to clean up rules, persisting the rules, and so on. I plan on adding this to my server in the next few. Thanks Kevin!

As a side note, it’s been over a year since I’ve been tinkering with iptables, so this will get me back on track as I’ve become rusty…

I just recently finished reading the excellent book, Security Metrics, Replacing Fear, Uncertainty, and Doubt, by Andrew Jaquith. Andrew has written a book, not that I would like to write someday, but a book about a topic that hasn’t been written about before, and he certainly has something (many things!) to say about it.

In fact, I have to make mention of a phrase that toally made me happy to see, since I rarely get such literary enjoyment from technical texts. On page 118, we have this gem: “perfidious outsourcers pilfering proprietary secrets.”

This book is definitely worthwhile for anyone who ever has to present security metrics as a part of their job. I would also recommend it for any security operations people who want to understand why some metrics should be gathered and how to better give your analysts and managers what they want. Likewise, any security operations people are likely the future analysts and managers anyway, so this makes for a very good early orientation to the important questions and how to appropriately answer them, let alone self-evaluate their own systems according to more appropriate metrics.

This Posted in general

Reading the Bejtlich interview sparked a thought. I read this in response to what makes a good network security analyst:

First, you need to want to beat the bad guys. If you are entering the security field because you heard a commercial on the radio advertising higher pay, you will not get far.

For some reason, this made me think of mention that Marcin made recently along with pdp about the movie Hackers and/or that old “hacking” culture that seems missing lately.

I need to give pdp proper kudos for coming out (hehe, read *that* link out of context why don’t ya?) about the movie’s influence on his life personally. There are few things more chic in digital security than bashing CISSP-holders, but bashing the movie Hackers is one of them. I love the movie for what it is, even if the details are dramatized heavily.

At any rate, pdp and Marcin are both (independently and cooperatively at the same time, I think) looking to revive a little bit of that curious innocence and culture that the hacking scene has seen slowly disappear. This sounds fun and cool, and while the industry, technology, and hackers-turned-professionals have largely matured, we can still have a hell of a lot of fun in our little geek circles and keep things immature and fun as a way to keep our lives from becoming overgrown with the burden of the daily IT/security overwork. Embrace your inner deviate, if not in action, at least in thought.

I think the bottom line is to just have enthusiastic, lifelong passion about this field. Live it, embrace it…but that last might be my hedonist side talking.

A quick note that Marcin has posted an interview with Richard Bejtlich over on his blog, ts/sci-security. Richard hosts what is definitely one of my favorite blogs, writes excellent books, and basically is one of those zen masters of his field of expertise, namely network monitoring and everything that goes into that discipline. Of all the people I would love to learn from and work side-by-side with for a few years to sponge up information, he’s near the top of the list, truly. I’d even fetch his coffee, give him massages, and frollic…er…someone stop this downward spiral..!

I’ve recently read two interested papers dealing with DNS-related attacks. First, Andrew Hay pointed over to a paper from the HoneyNet Project titled Know Your Enemy: Fast-Flux Service Networks. The HonetyNet Project is uniquely poised to do some things that most of us cannot autonomously do: monitor and trend threats. This position has allowed them to see Fast-Flux attacks first-hand, where DNS entries are changed dynamically to hide the source of malware downloads and controls. I’d be willing to bet this concept has been in use for quite some time, only many researchers fire off one or two lookups, report to the resulting domains, and that’s it. They likely never see the changes, and thus never realized they were not really doing much good.

I also see that Trusteer has a paper hosted describing cache poisoning against BIND 9 by leveraging predictable transaction IDs to update DNS caching servers surrepticiously. While this seems a bit exotic, I wouldn’t consider it too exotic. In fact, getting an outbound connection by an internal user shouldn’t be a huge problem, and that could be a big payoff if you can poison some major DNS entries. I think the biggest problem is just making sure you’re attacking a BIND 9 DNS caching server. I’ll dive into this paper more than my casual glance tonight. Considering our malware prevalence today, I think this can be easily leveraged by existing maldoers, but may require a bit more targeting than blanket blind malware. I’m interested if the paper goes into countermeasures or how to combat this.

Lastly, this paper hosted by InfosecWriters is an excellent primer on DNS and DNS security. I recently read a DNS paper that was really well written, and I think this was it. I’m not sure where I got the link from, however.

This article about the government’s opinion on P2P networks (they claim it is the cause of sensitive gov’t data being disclosed and is thus evil) is exactly what I thought when I first heard this story today. The use of P2P networks and applications is not the issue here. The issue is data protection and system control. Don’t let your organization-owned systems have P2P software on them (there are plenty of ways to tackle this both on the systems and the network!). And keep track of your data so people don’t bring it home and put it on little Stacy’s computer running 3 default all-shared P2P apps 24/7. Pound in that this activity is against policy. Stop slapping wrists and start meting out real punishments to the employees for such violations.

More fun web server tricks from Full-Disclosure today. Falling under the headings of “information disclosure” and “service fingerprinting” is an enabled server-status page in Apache. Go to your website and add “/server-status/” to the end to get the information, kinda like on apache’s site: http://www.apache.org/server-status

Computer help questions come in many flavors, and while many requests get dodged, there are times when influential or attractive (wink wink) people ask favors that you don’t want to dodge and would rather have a quick and impressive answer. One such situation involves the inevitable accidental file deletion or damaged disk recovery. Two such tools were recently posted to SearchWinComputing, Unstoppable Copier (gui) and Bad Block Copy (cli). There are other tools, but I’ve mentioned them elsewhere on here before (and recently too!). I’m sure there are other forensics tools that do this sort of stuff very nicely, but are likely cost-prohibitive for home users.