I thought I would get one last post on this site before 2013 rolled over, but much like most of 2013, I didn’t get anything out. There have been a few reasons for this, which I may as well throw out for posterity.

1- Not much new to say about security. Eventually, you do kinda get sick of the same old thing in security. Lots of people whine about this and say we’re not innovating or doing security in some new way that will win the War. I think that’s a lame way to look at it, and not correct at all. It’s not like security/insecurity evolves on its own; both are functions of technology in general, and follow along behind. And there’s no real win there; security will *always* be behind the curve. But still, it does get annoying when you have really nothing actually *new* to say.

2- Fucking Google killed Reader and fucking Twitter killed older API-using clients. My dearth of posts on this site corresponds to my lack of posts on Twitter. This is because, at nearly the same time, Google killed my preferred RSS feed reader of choice (and by preferred, I mean, preferred by a long shot) and Twitter shut off support for their older API, which killed my preferred Twitter client of choice, DestroyTwitter. I liked DestroyTwitter because it worked on both my Linux and Windows systems as a standalone client. I really have yet to *like* any others I’ve tried. I’ve sort of moved to Feedly for RSS feeds, but I just haven’t made it a normal part of my day/week like Google Reader was. I have yet to adopt a new Twitter client. Both of these make me feel very disconnected.

3. Been a busy year in general for me, both personal and work. Work has been busy with lots of changes and…challenges. On the personal front, I’ve just kept my interests elsewhere for the most part. The older you get the more you realize you only have so much time in a day. Tinkering with security-related stuff sort of took a backseat for the year after Twitter and Google cut me off. I’ve hung out in the main lobby, but have not delved deeper into back rooms.

No really huge, big, crazy reasons. Just sort of a break, which I do every now and then since I’ve had a blog of some sort since 2001 or so.

Probably the worst thing about business-to-business (B2B) security questionnaires is that you know 90% of them are being required, but never really reviewed. You can sort of answer anything, and as long as you have a “yes” or check mark of any sort, the reviewer isn’t smart enough to dig further. (Kinda like PCI QSAs!). Because of this situation where not-smart people are reviewing these answers, there are some questions I dread. Especially when someone gets a burr up their ass about better answering a question they don’t understand. I.e. achieving that checkbox!

So, what is your least favorite question to read on B2B security questionnaires?

For me, it is any question that involves DDoS protection. I work for an SMB. Our DDoS protection is pretty much hitting the low items. 1) We monitor bandwidth and servers and services to know when any are saturated or having resource issues. 2) We will work with our upstream ISP in the event we need their help in limiting inbound traffic to us. 3) Our standard for systems and processes is to provide for both high availability and disaster recovery/BCP. (In fact, we’re pretty nicely set up that way for an SMB of our size.) 4) As a bonus, we do have some capability to do some traffic threshold monitoring, shaping, and shunning with our firewall/IPS and web load balancer combo, but that is only after the traffic makes its way to us.

But if someone wants that answer to be better and more pro-active, you cause me to drink some more. Because what that really says is I should spend a good 100-250k on DDoS protection software (that won’t itself promise anything anyway) and a staff member to hold its hand, so that our checkmark in that DDoS box is a little more heavily outlined (and yet still not necessarily truthful). And even with that spend, there are multiple other places where a DDoS may occur. Wireless access on our campus. Email blasts. Legitimate traffic that exceeds what anyone planned for that fills our bandwidth/drops our firewalls/keels over web servers/overwhelms database servers/etc. Most of the time people who think about DDoS are just thinking about junk traffic filling up their Internet bandwidth, or maybe one step further and looking for known, singular resource-gouging attacks like a ping of death or SlowLoris or something. But, what about poorly written code in your custom application that bogs down resources that no tool is going to drop into place and automatically detect because, well, it’s custom code?

Anyway, coming in a close second to DDoS questions are Web App Firewall questions. Sure we have one, but is anyone actually making it useful to the custom apps it is protecting? Nope, not beyond the obvious like a 1000+ character URL (Apache issue from 10 years ago) or a GET for root.exe…

If you collect annual security and threat reports like I sure do, you’ll want to not miss the Sophos Security Threat Report 2014 like I did. If you follow the security news all year, nothing in here is particularly surprising, but a report like this is nice to whip out when a middle-manager wants to defend Android in the enterprise as being secure (da fuq?) or some other such nonsense. Happy reading!

Interesting story for those of us who administer IIS 7+ web servers: “The Curious Case of the Malicious IIS Module” from SpiderLabs. As sort of shown in the article, even an SSL-wrapped site isn’t safe, since once you’re inside IIS, you’re actually behind the SSL encryption process which is handled in the OS starting with IIS 7/Win2008. Even in earlier versions, getting that far gives you unencrypted visibility, pretty much.

The up side is if someone has this level of access to drop a new IIS module on your web server, they likely have access to just flat out change your code. So other than particularly nefarious attackers or automated tools that just do it for them, I’d not expect to see rogue IIS modules. However, this is definitely something to look for in modern IIS web servers and something to inventory and poll and alarm on anything new appearing.