I guess I told my team about this, but neglected to put anything here! A few days ago Microsoft issued an advisory about a “Vulnerability in ASP.NET Could Allow Information Disclosure”. There are really two aspects of this vuln that require attention: being able to read viewstate data and being able to pull files/info out of the server, such as the web.config contents.

A video of POET (Padding Oracle Exploit Tool) demonstrating the attack is available, along with more info at Netifera. If you’re looking for even more detailed analysis on the crypto attack, check out Gotham’s excellent blog post along with their own tool, PadBuster.

ScottGu has a great blog post with more details and workarounds, along with an FAQ post, and there is a special forum carved out for discussion on this issue.

Is this a Big Deal? Reasonably so, I think it is, especially as a gateway into further application attacks that lead into system access, as the earlier video demonstrates. An attacker could sniff client traffic, grab viewstate, and attack it to possibly retrieve that client information. But why bother with that? The important part is an attacker can generate his own viewstate and directly attack the application and even the server on his own.

The attack is noisy. The attacker will generate a large number of exceptions in the logs, but unless there are specific alerts for such jumps in numbers or an analyst is watching logs in realtime (yeah, right), the attack can be quick enough that detection won’t catch it before damage is done.

Another mini-rant. I saw this today in an email:

…recent research on text-based tasks such as software development have shown that time improvements of up to 15% can be achieved with a widescreen monitor.

I’m glad that wasn’t about me! Really, reading something like that from a manager would make me feel like a rat in a cage or a sweatshop, milking as much productivity out of me as possible like some automaton. What if I didn’t make a 15% time improvement? Am I fucked?

It really should be something like, “Hey, Bob, what sort of configuration can we get you that will help you be happiest in your job with us?” Or if you can’t be personal, at least figure out a consensus with the team, not based around metrics, but around happiness.

Fine, times are tight in some places and metrics help justify budget expenses. But at least don’t let such statements go downward…

A couple Friday quick-rants. These didn’t happen today, just in general!

Please don’t wait until 4:30pm on a Friday to make a non-trivial need-it-now request for something you’ve known about for more than a day. Don’t make me go crazy for your lack of planning.

And if that request is something that regularly happens and usually doesn’t involve me, please don’t tell me you don’t know any details. If it is that important to you and happens regularly, please educate yourself on the things that your job’s success depends upon. (Or, from my role, don’t hoard the details; freely share them. Even if they don’t make sense, they may help a future request succeed.)

No. One word, a complete sentence. We all learned to say it around our first birthday, so why do we have such a hard time saying it now when it comes to our work?

I read this article, No One Nos over at A List Apart, and really liked some of the thoughts it struck up. I work in security, infrastructure, operations. Saying some form of, “No,” is a nearly daily occurrence; and a nearly daily stressor (business always defaults to convincing “No” people to start being “Yes” people*). Whether it is a misguided project request, request for access to something sensitive, or configuration change without proper oversight. So any article talking about, “No,” I will usually read, even if I do so grudgingly.

I really liked this bit that was kinda left hanging:

Each one of us brings an area of specialization to our projects, and it is our responsibility to exhibit that expertise. …It is your duty to assert that capability and share your knowledge for the betterment of the final product.

Later on, the author talks about the answer, “Yes! No. Yes?” While I’ve never heard of something like that before, the concept itself is something I think many people naturally find, including myself. Rather than saying no outright, get on their side, but then basically say something isn’t possible or get them to realize the same. But it might be possible if we do xyz (which is usually hire more staff, spend more money, eschew policy/best practice…similar to pricing yourself out of a situation).

If I were to add something to the author’s message, I would emphasize the last couple paragraphs. I resent business in general that takes a, “Don’t say no,” attitude (irony?) on a general basis. We have to be able to (constructively, if possible) say no and also accept when a no is said to us.** (For deeper thinking on a Friday, one might draw some parallels to American culture and our legal system…)

I’m ranting a little bit, but really I agree with the author’s message.

Found via Jarrod Loidl’s blog.

* This ties in with my dislike of the “Give ’em the pickle,” business mantra. Avoiding “No” and also giving someone the “pickle” are fine, but only when the opposite party is reasonable. If the customer is unreasonable or the requestor is unreasonable, then cute maxims like these fall apart.

** I work or have worked in proximity to someone who doesn’t hear when someone tells them no. Few things in a job like mine are as frustrating as someone like that. This contributes to why sec folks drink and vent a lot! 🙂

Insecure Magazine issue 27 is available [pdf].

This is a shorter issue, and I honestly didn’t really take much away from it, but I did enjoy the article Payment Card Security: Risk and Control Assessments (pg 44). Specifically, I liked reading about FMEA (Failure Mode and Effects Analysis) and basically the rest of the article after that.

FMEA isn’t necessarily groundbreaking (you’re still pulling numbers out of the air), but I’d never heard of it before and I liked seeing a quick summary of bullet items to fill in for it.

The Preventative/Detective controls and Guidelines for Risk Mitigation mentioned later are collectively just a way to summarize PCI DSS requirements, but is worded much better.

I mentioned previously that I didn’t have much to add to this year’s DBIR. That’s not entirely true, but the thoughts below are definitely not a big deal. The DBIR already spent several pages on PCI-related material, and certainly didn’t (or shouldn’t) need to spend much more on it at this time.

But I still found some of the data interesting.

Which requirements have the best adoption? I’m not surprised by these results all that much. Encrypting transmission (Req 4) is an easy win* when you just look at SSL. Restricting physical access (Req 9) is also an easy win* if you lock your doors (please read the * down below before I raise your hackles too far!). Using and updating Anti-virus (Req 5) is likewise easy, although I’d question how many enterprises are actually validating that updating procedure! And policies (Req 12) are highly adopted, most likely because they tend to be fire and forget. Ideally, I’d like to see policies be the most adopted simply because they should be some of the first check boxes accomplished and/or the quickest to wrap up. (Then again, few people enjoy writing them…)

It is no secret that these particular requirements read quickly as the more clear and easier requirements.

Which requirements have the worst adoption? Developing secure systems (Req 6) is consistently pretty low, and not surprising: it is one of the crappiest single requirements in the PCI DSS. It is vague and downright huge. Regular testing (Req 11) is next, which again is not surprising (vuln scans, IDS/IPS, pen tests), although I think that is usually due to costs as much as anything, both in terms of human hours spent attending to those technologies as well as the capital costs of external pen tests or hardware to satisfy the requirement. I also find that Req 11 is one of the bigger “security geek” items in the list, that really doesn’t even involve general IT operations staff competencies.

As the DBIR rightly points out, the requirements with the most ongoing tasks associated with them are the ones least adopted.

Wait, 2 of them decreased?! – The DBIR mentioned, but I don’t recall it discussing any reason why the anti-virus (Req 5) requirement and vendor-supplied defaults (Req 2) actually decreased 9% and 19%, respectively. AV, as mentioned above, is one of the higher adopted items, yet it decreased; and removing vendor defaults should be a slam-dunk for operations. Maybe the problem, like so many things that are shoddy with security in enterprises, is in the on-going verification of updated AV and validation that vendor-defaults are changed. Or maybe some breaches this past year took advantage of passwords that got reverted back or the attackers removed AV and nothing threw alarms about those systems being unprotected. Who knows…

Like I said, the DBIR didn’t need to spend even more time on PCI, but I found Table 9 (pg 54) to be pretty interesting…just like I had last year.

* By “easy win” I mean these *can* be easily met in limited circumstances. Reality for someone serious about security can still make these items strangely difficult and open to interpretation.

I’ve written previously about my mp3 player/portable media player purchases, namely the Cowon A3 (mp3/video player) several years ago and more recently my Cowon iAudio 7 (nano competitor).

I have now purchased and been using a Cowon J3 PMP. Since I’m not an electronics review blog, I’ll keep my observations short and somewhat personal. Obviously, I’ve been happy enough with Cowon to not deviate from them since I first purchased the A3 as a replacement to my original 4th gen iPod. (The 20gb iPod is ‘permanently’ attached in my car and I’m happy that support for updating it outside of iTunes is far better than it used to be, making it less ‘evil’ in my eyes than it used to be.)

My cons outweight the pros in number, but as far as value goes, the pros far outweigh the cons in my books. The gulf isn’t quite as big as when I got my A3 or even the iAudio 7, but the J3 makes me very happy indeed.

Pros
– sound quality: In short, the sound quality is fucking amazing. I love the full equalizer control and ability to play with some of the enhancing effets in the JetAudio software. I’m hearing songs in a new light with the J3. The 3d surround enhancement also makes me turn around now and then wondering if someone is behind me. Quite honestly, the sound is beautiful and it alone is worth the money.

– easy management: The biggest selling point for me has always been Cowon’s ability to be easy to load files into. Just plug the device into a Linux/Windows PC, it registers as a USB storage device, drag files to the Music folder, unplug and enjoy! I also have no need for playlists, fancy artist/album groupings, or complex playback depending on my mood. I just want to shuffle my 3,000 trance/techno songs. Or 4,000 chill songs. I only have 5 folders holding all of my ~70gb of music.

– small, light: lighter than my cell phone, so it is pocket-worthy! That was always one of the few issues with the A3 being too bulky for normal pockets.

– microsd support: The internal drive is only 32GB, which is small for me, but I love the microsd support. I can buy a new 32GB microsd card, load it with my chill music, and when I want to listen to it, just insert the card. Or just always keep the card in for 64GB available at all times.

– radio: Ok, I don’t listen to the radio, but if I ever needed (weather, emergencies) or wanted (sports, wake-up alarm) to, this guy has a built-in radio function.

Cons
– video support: Somewhat surprising, the files I’ve ripped from my movies that play on my A3 don’t play on the J3. This is somewhat perturbing as I’d rather not re-encode all my files. This kinda leads me to the conclusion that I should just rip my movie backups into ISO files rather than encoded media formats which may become useless or too lossy in the future (a debate I’ve been having with myself for some time now). The ISO files will always be useful as sources for doing future encodings, and my desktop systems will read them just fine for immediate playback. Anyway, it is not a huge deal as I’ve only rarely watched movies on my A3, and my A3 is still quite capable in that regard.

– mp3 playback shows album art: Some people wouldn’t think this is a con, but for me it is. I don’t download and update and manage album art, so most of my songs end up with a blank default icon filling about 2/3 of the mp3-playing screen. I’d love to turn that off or change the display or just have a generic wallpaper, but I’ve yet to find that option. This device isn’t going to convince me to start complicating my life with album art management. I find this a weird inclusion for a device really touted as the simple alternative for people who don’t want bloated music management.

– need an AC adapter: The J3 charges via a USB cable connected to a computer. However, while plugged in, you can’t use the J3 as it goes into a locked mode. Using the AC adapter will allow charging+playback. Not expensive or a huge deal, but just a small annoyance.

– special USB cable: The USB cable is not one I’ve seen before; and of course not one I have replacements for.

– included earbuds: Ok, the earbuds are just fine soundwise, but once you put the soft covers on them, you can’t tell visually which is the Left or Right earbud. I just scratch the outside of the Left one to tell. Also, I don’t get why one side always has a shorter length than the other.

– slow startup: The startup of the J3 is surprisingly slow, but not something that is a huge deal to me. I’m not impatient.

– doesn’t start music upon startup: Again, not a huge deal, but sometimes I’ll go a few minutes without any music before realizing I need to touch Music, and then Play to get things going. My A3 just starts right into whatever was playing when I turned it off.

– spotty accessories: The Cowon isn’t the biggest player on the market in the States, and as such the ability to score excellent accessories such as a padded case are slim. In fact, I still carry my A3 in a PSP case, which it fits into perfectly! I have yet to find something similarly perfect for the J3. Basically, just a padded sleeve or some sort is fine for me.

– shows fingerprints/scratches: The touchscreen and body show fingerprints easily, and the back metal can scratch easily. The “new” appearance of gear is always a tough mental battle to fight, but it is easiest to just accept that things will get scuffed, rather than fret over it! There are more important things in life to fret over.

Just a quick mention of new Adobe 0days that are making the rounds. I may not have bothered since details are so few at this time, but the media is all over these two, particularly the Flash issue. Neither are patched, and Adobe has provided scant mitigation details. Probably because most of the suggestions involve crippling their software or using additional/replacement software that essentially says, “don’t use our tech.”

A week ago, Adobe Acrobat/Reader were hit with a 0day being exploited in the wild.

Yesterday, Adobe Flash had a 0day advisory announcement.

I’m pretty tolerant when it comes to security vulnerabilities in software. While I side with those who say we need to build things secure, I just don’t think that is ultimately realistic. I also have at least some proximity to business and software/web development, so I know what often does or does not go into those processes. I can tolerate security vulns if the business plays response really well.

I can even tolerate security being a new thing to a business and them playing catch-up for a while, kinda like Microsoft has done with Windows and Office products. But Adobe doesn’t appear to be improving, in my observations.

The lesson that gets lost in all of this, though, especially with the general computer-using public and media is the problem of feature bloat trumping security concerns. Adobe may take the lumps from the vulnerabilities, but all of this is probably enabled directly by user demand and use of those features. So, thanks for needing/wanting those features and making the rest of us less secure. (The same argument I make about HTML in email. Thanks for that, Marketing…)

I just recently beat out the Brutal difficulty level in Starcraft II, so thought I’d just share some tips on the levels I found to be hardest. For better tips, just look up the levels in YouTube for examples of good play. For any player, I’d suggest doing the Normal campaign first, then Hard, then Brutal once you know what you’re doing. If you want multiplayer strategies, I’d highly suggest following Force’s Starcraft 2 Strategy YouTube channel. Have fun!

Outbreak – I found this to be surprisingly difficult. On Brutal, I made 3 bunkers at each entrance, manned mostly with marines and marauders. I didn’t do much with hellions. It helps to focus fire aberrations and the shooting infected. I didn’t bother with the expansion and it helps to wipe out one whole section (I did top) to basically relieve that entrance defense. Return to base with at least 30 seconds of daytime left.

Welcome to the Jungle – The mission wants you to use Goliaths, but they’re just too weak. I had problems early on here, even in Hard! But this mission is actually very easy if you just build up a Marine-Marauder-Medic ball (about 4 marines to 1 medic to 1 marauder) with upgrades and just hop from protoss force to protoss force. Rather than mine any gas yourself, just wipe the protoss off the map and you’re free to do whatever. (There’s even a feat of strength achievement for that.)

The Great Train Robbery – The key here is to build a second Factory and simply pump out Razorbacks along with some marine-medic support. Roam around and kill bunkers when they start getting placed. This is easy once your know what to expect.

In Utter Darkness – A fun mission, but my least favorite to complete and one of the 3 hardest ones. Open with 10 more probes rallied to your minerals, a dark shrine, 2x gateways, and a starport. Then wall off the top entrance with another gateway, and plug the holes with zealots on Hold. From there, start producing (preferably with warp gates) Dark Templar, while using your force and the DTs to beat back the first 3 waves (done right, you won’t lose anything but a phoenix or two). From there, you should have enough time to make enough DTs to do a Hold wall on each entrance. If you get to that point, the rest is easy. Switch to building Void Rays, and use your voids/phoenix to focus fire any Overseers (detectors); basically poke at any approaching waves, kill any detectors, then get out before they reveal and kill your DTs. Pepper your base with cannons using all extra minerals, get air upgrades, and when you can, transition into building carriers. At about 1500-1800 kills you’ll likely need to fall back to the high ground, and the kills will start to rack up quickly. Don’t make a single other ground unit besides DTs enough to make full walls. After the first 3-4 waves, whatever ground forces you have are inconsequential anyway as long as your DT walls hold.

Supernova – One of the 3 hardest Brutal missions. I cheesed this one, though I didn’t want to. I got my CC into the far right-middle of the map along with some repairing SCVs and about 12 Banshees. I then waited until the last few moments to slide up and destroy the artifact. I really always had trouble with these missions with soft or hard timers on brutal. I’ve heard doing this mission when you have Thors makes for an easy win.

Engine of Destruction – One of the 3 hardest Brutal missions.This mission is a breeze if you have Banshees and Vikings unlocked (I didn’t so I had to actually start over; Wraiths are too weak). Build a bunker and siege tank (in siege mode) as your defense in the north. Build a second starport and start pumping out Banshees and later Vikings. Use the initial Wraiths to soften the first 3 bases. Kill Medivacs, Siege Tanks, Battlecruisers, the lone Raven in base 2, and if time permits, Bunkers and Razorbacks. Rally your Banshees north of your bunker as none of the attacks feature anti-air units. If you get past the third base, the rest is downhill from there; just keep making air units. I’d suggest squeezing in an Armory and air upgrades as well, and maybe take over the geysers left behind in the second base. A few Science Vessels are nice, and keep SCVs near the Odin to repair him if he gets into trouble (beware, in Brutal the AI will target repairing units!). Later you’ll be attacked from the south after base 4, but either ignore it or mop up with your air. For my winning playthru, on base 5 the Odin actually got down to 24 hp. Close call!

Maw of the Void – This took me several tries, but my key was to get an Armory early and start warming up air upgrades. Later on the Protoss will be 3/3 and your battlecruisers need to match that. Use the DTs you free to soften the bases up and for sure to take out the last northern and southern generators using some kamikaze-like runs; done right you’ll have just enough alive to get both down. If the mothership vortexes half your fleet, send the rest in and wait it out. You shouldn’t lose a single BC, until the last pushes, with proper repairing and a few support Science Vessels. When not attacking, put them in the middle of the map to cut off any protoss transports or attack waves. Same with DTs (but watch out for attacks with Observers). Be sure not to go too slowly; the protoss can win this through attrition as there just aren’t all that many resources when you have a BC fleet.

All In – I pulled back my defense and built 3 bunkers on each approach. While garrisoning them up, build all Siege Tanks and Banshees. The tanks are for defense on both sides and along the artifact cliff base (just keep building until you have a screen-full! The Banshees are to be sent out en force to kill Nydus Worms while cloaked and add firepower against Kerrigan. I helped my base defense with a line of southeast turrets as well, for the Overlord swarm. To save the artifact later on, build a bunker near it, put some marines in it, and then cover the rest of the artifact plateau with Perdition Turrets.

A Sinister Turn – Get the Robo bay early with a pylon as far back as you can get it. As long as you don’t draw attention to it, it won’t get attacked. Just build Immortals with a few Zealots and Stalkers and you’ll find this easy. Immortals pwn Maar and anything else here. Stalkers start with Blink, so it really helps to Blink them away from Maar after absorbing a few hits. Micro-management of forces really helps on this map.

The Dig – There are three keys here. First, get a defense up early because the first few waves can wipe you out. Even bounce your ground force back and forth until you have enough units. Second, rather than bother with the expansion to the south and moving your bunkers north of it, just bunker the ramp to your base. If you need it later, you can salvage the bunkers. Third, make constant use of the drill to take out Colossus (they give sight to high ground which is killer), High Templar (Psionic Storm destroys tank clusters), Immortals, Archons, and Void Rays when they show up. Queue up multiple targets with the drill to give you more time to develop the rest of our economy and defense. Favor marines and place a few extra turrets for the air waves.

Really, for every other mission, the typical MMM-ball works wonders.

Jeremiah Grossman has an interesting post that covers 2 neat topics: scalable scanning and WhiteHat’s hardware setup. Cool stuff on the second part. For the first part, I think watching topics like scalable security and scanning would be important for those who think all this IT and more importantly security emphasis these days will lead to further outsourcing of said roles to specialist groups. I’m not an executive or into accounting, but I am not oblivious to the idea that IT/tech/security is not a core competency in most organizations, and instead is a cost center (i.e. not a competitive advantage either). (Yeah, I like dropping terms I actually learned in school now and then…)

Then again, maybe a specific case like Jeremiah’s is a bit strange. I mean, look at how much their hardware (storage) requirements have to increase, and no doubt they need tools and/or people to make sense of the reports, as their scan targets increase. Perhaps desktop scanning software scalability is not the real battleground, but rather how do you do web security scanning quickly and meaningfully (as a sort of macroscopic/meta vantage point)? While admittedly conceding that you can only get x% of the scanning done via automated means.

It (obviously) crossed my mind that another group who may have the use-case for large-scale scans could be attackers. But that may be a bit of a red herring. Do they need to do such huge scans to be successful? No. Even if they did, as demonstrated by Jeremiah, you’d need some serious infrastructure (provided by botnets no doubt) to power the whole thing. The more of that you need, it seems to me the more said attacker would be exposed. Attackers are still far too successful with smaller-scale, smaller-footprint attacks that can be surgically wielded from pinpoint locations that are not hard to expend. Even assuming the worst, I’d doubt attackers would ever need to move above desktop-grade scanners anyway.

Just thoughts!

Yeah, we’ve all heard more than we need to about Symantec’s Hack is Whack campaign and the security holes found in the newborn site.

This is what I call a decently Big Deal; a sort of case study in how even a security giant is dropping a site out onto the internet that is full of holes. Certainly Symantec has security experts enough to review their code and make suggestions, or code it up properly from the start. Or at least have some oversight to slow down the process and make sure marketing has their details buttoned up, right? (I’m quite aware that marketing no doubt implemented and ran with this completely on their own, likely through a third party or even fourth party, but my point will remain…)

This really provides a horrible, sobering example of the state of things right now, especially in how important security truly is to organizations. Far too many do whatever they want, until someone pokes the soft spots and points them out. The more public or damaging, the more likely a quick response is forthcoming. And this from a security company!

I’m not going to go so far as to say this is a call to arms for security to be at the forefront of marketing in Symantec or even any organization. That’s a dreamy ideal, but not one I’m thinking is realistic at this point. No one likes security dragging the timelines out and making things complicated!

It should instead be more of a call to arms for executives to care about this sort of thing, which in turn can start permeating that cultural change in everyone else. It just doesn’t work to be 100% reactive. That is still what I call the Big Gamble in organizational security. Roll it out there and hope no one ever cares too much and finds big holes. That or the attitude that you can’t secure it yourself, so roll it out there and let others provide your QA and security testing for you. I agree you can do those approaches, but they can’t be your only approach. You’ll either continue to be laughed at, or you’ll get pwned and not know it.

I may still be a bit idealistic in my viewpoint. In larger corps, they’re just too big to play catch-up on everything that is going on. In smaller corps, they just want to survive and can’t afford to go slow or imbed security in something that may not even exist in 6 months if it fails.

The PCI Guru has a nice reference on writing compensating controls for PCI requirements you “can’t” meet.

This is another incomplete, but interesting post. Not sure why I started writing this , but I always like the dreamy feel of “best case scenario” types of descriptions. Like what is your dream job? What is your dream vacation? In this case, what is your dream security team posture? I’ve added a thought below in bold. I probably never released this since I likely have said these same items in other blog posts, comments on other blogs, over twitter, and in personal discussions, so it sounds a bit like a broken record to myself.

Simple steps to a strong security posture:

– Staff. Don’t skimp on quality security staff. The anchor of any security team is the skill, talent, and enthusiasm of the top players. It is ok to have some lesser-skilled players or interns. They help provide perspective, an ability to allow senior staff to mentor, be mentored, and possibly do the things that you’d hate to have a $100k staffer do every day like cruise logs or something. In addition, be liberal with their training opportunities, both on and off the books.

– Operate the team as an advisory unit, a monitoring unit, and an active penetration team. Basically, don’t just watch for breaches or react to things already done. Be an internal consultation team for developers, sysadmins, or others who would like or need more guidance on security issues. The team should also be able to and allowed to do planned and unplanned security audits and penetration tests against company assets. It’s not just about implementing, tuning, and addressing trouble tickets about a host-based firewall on desktop systems, or auditing the systems through a central mgmt interface to ensure exceptions aren’t being granted by non-security-minded desktop staff. It’s about helping the business as a whole.

– Be given autonomy and authority in the company to make recommendations, on par with a high-level consultancy. If a security team expects an application to be built securely and offers proper assistance and knowledge to the app team, they should expect to have their concerns addressed reasonably, rather than what often turns into a mgmt political battle or simply ignored demands. It needs oversight over the company assets and IT, really.

– The team should be given some level of operational power or control, especially over their own systems and test systems/networks. Security staff isn’t just about installing endpoint software or watching logs or even consulting or pen-testing internally. They should be able to test and implement changes as needed without having to walk someone else through it or wait (politically and timely) for a real engineer to attend to their ticket. It is my opinion that quality security staff would also make quality operations staff (or quality management in general if that is their focus)…so give them that latitude. (They should also be held as accountable with availability mistakes as operations, when acting in that space.) Of course, this butts up against the problem of having too many hands in the cookie jar, for instance 6 people having access to update firewall rules. That’s 5 extra ways of doing it that don’t match your own philosophy!

This is my getting rid of some incomplete thoughts sitting around in my unpublished bucket. This post could be 3 years old or it could be 3 weeks old, I’m not sure. Peeve #4 is a bit of a reality, and I’m not sure I would today include that in here if I rewrote this today. The ending example goes nowhere, and #5 isn’t finished. Either way, just getting this off my chest and published.

5 of my IT security pet peeves. Notice that these are not necessarily technical issues. I don’t feel like our biggest challenges are technical in nature. And while I might call these pet peeves, they don’t necessarily frustrate me nearly as much as most of my driving pet peeves.

1. No Big Box Tool beats a good admin, but we’re obsessed with the Big Box Tools. I’m not a big fan of all-in-one-boxes or UTM or centralized SOC-in-a-BOX. On one hand, I really like the power that tools have been getting in terms of analyzing and collecting data in one place. Sadly, I don’t think any single box performs better than other smaller tools being used wisely by a crafty admin to achieve the same goals. There is a certain watering down (each piece is lower quality compared to specialized tools) and dumbing down (take the analyst away from the guts long enough and he’ll only know how to work the GUI and not dig deeper manually) and feature-bloat (try to pack every option that 10,000 companies will use but no company uses half of them at once) to big boxes that simply cost in terms of quality. The real key here is whether you have a crafty admin with the time necessary to wisely wield those surgical tools. Instead, we too often take the quality hit to save some money…

2. Not enough time. In our American culture, we have this obsession with milking productivity from our workers. We demonize leisure time, personal time, even vacations; maybe not openly, but we insinuate that anything less than 100% is bad. This trickles down into IT staff who have little free time to improve their situation beyond rushing from one fire to the next, or one project to the next. You know you’re in this situation if you’re doing task A, notice that issue X is occuring just because you happen to see it, but know you won’t ever get to it and so just leave it. Security cannot be improved when time is booked. Either you don’t have the time to properly tune tools, investigate alerts (we’ve all had days where 1 alert takes 1 hour and days where 1000 alerts takes 5 minutes), do simple audits to verify security, or keep on top of current news. Let alone the mistakes that will be made due to the pressured time-boxing… You want to improve security? Improve the time your staff has to find and make enhancements. Anything else just means everyone relies on the audits and only does what is prescribed at the time. (This also means your staff needs to be enthused about security, and not just use their extra time to surf YouTube. If you don’t have enthused staff, then replace this item with : People who don’t hire enthused staff!)

3. Too many people still believe ignorance (or ignoring it) is an effective security strategy. I’m borrowing this straight from the article I just posted about earlier, because I think it is an epidemic (pandemic) problem. That noise coming from your engine? Yeah, it’ll go away, right? It wouldn’t happen to us! I think ignorance and human habits of ignoring problems is a real issue. I understand that some risks are accepted and not every problem absolutely needs resources pushed at it to solve it, but collectively we’re sucking with even the basics of digital security. (I think most organizations scope-limit their auditors from half the stuff that is wrong.)

4. Convenience trumps security, or, security is never as easy as it sounds. There are a few tasks that sound easy but illustrate exactly how time-consuming really managing security is: data classification company-wide, account oversight and review, file server permissions audits, knowing exactly what data is where (yay laptops!), log reviews, and change management. Convenience trumping security is a more appropriate way of saying functionality over security.

5. We want security now, for free, and to last for years without further inputs. How many PCI projects have we collectively seen that have deadlines? And after that deadline, PCI (or security) is considered done and the consultants/contractors let go). That’s a win for sure!

Just to juxtapose a few items from above, here is one scenario. You have a not-very-technically-proficient security admin in your company. He’s not given the most access, probably not enough to do this job effectively. He doesn’t have the ability to implement proper NSM without the techs making his requests bottom-of-the-barrel priority. In fact, he doesn’t have much more than the ability to get an All-In-One-Security-Box. Likewise, said security box doesn’t give him much data for an alert. Oh, and by the way, he’s an important admin who talks with execs every few weeks with some certs under his belt, so he feels he gets paid more than someone who does the grunge work like reviewing logs, accounts, or testing those firewall changes. So no one really checks that stuff. When audited, the admin knows just enough to give the auditor enough for a report, keep him away from the things he knows suck, but not enough to allow the auditor to expose underlying issues.

I really don’t know where the fuck this post came from or where I was going with it. It offers nothing, but the picture links are fun! Took me a bit on the wildebeest one to realize I was trying to say “just another beest in the herd” with the “middle” pic. To my sensitive readers (really, there are sensitive security geeks?), skip the seal pic.

1. Too many words in PowerPoint presentations are bad. More creativity, more pictures, more visualization. Less words, less boring.

2. We also have this need to give quick representations of our risk or compliancy to management, often in the form of scores or grades.

I think these ideas should be combined “mashed up.” Screw the grading scale of A, B, C, and the levels like high, medium, low.

Imagine: You walk into the board room with several managers and execs. They get around to asking you how the company looks as far as compliance to PCI and/or your desired security level. You stand, flip open your notebook, and pull out a card the displays this picture:

seal clubbing

I don’t have to give details, I think it speaks for itself: STATUS BAD!

Here are some more examples of compliance status levels.

Bad
Medium
Good
Good