ShackF00

We’ve all been a n00b at some point. I don’t care who you are, at some stage of the game you didn’t know much, or started a new gig, or tried something for the first time in full view of other people, or whatever the case may be – you’ve been a n00b. My friend Raf Los at HP, who I’ve known for years and has been through the security gamut just like me, posted a really interesting semi-rant the other day, check it out here. His observation? We crusty security types kind of suck at letting new people into the club. I don’t know about most of you (well, actually I do), I hated cliques in high school. The “you can’t sit at our lunch table” crowd. The “we’re having a massive party at XYZ’s house tomorrow night, and you can’t come” crowd. Yes, we all know who I’m talking about.

We’ve kind of become that crowd.

We’re not welcoming, or mentoring, or open-minded about new people coming in. Be honest – when was the last time someone arbitrarily asked you to guide them or lend some experience, where you really went out of your way to help them learn about infosec? This is, of course, for all you crusty types like me. Well, I was pretty lucky, I guess – I had a few really kick-ass people who let me ask a plethora of questions in the early days, and really bolstered my confidence and desire to keep forging ahead: Lampe, Herb, Jimmy the Slick…I’m talking to you.

So I have some advice for the n00bs. Those of you that aren’t truly n00bs anymore, you may want to check out an earlier post of mine called “Career Tips for Security Geeks.” Noobs, read this first, then read that one too. So here goes:

1. Please please please please PLEASE do not come out of school with a degree in “Information Assurance” or some other bullshit and tell me you are a security professional. You are not. You are either a) still my intern for another year until I have hazed you sufficiently, or b) the new anti-virus admin. Yes, I’m serious. Experience and technical skills count in security – I’ma let you finish, but first you will be starting at the bottom rung of the ladder if all you have is said IA degree and a will to learn. This leads us to…
2. Show me. Yep. Don’t talk theory, or concepts, or God forbid mention wretchedness like the Bell-LaPadula Model. Help me get security in order. Models don’t actually DO anything. They’re great for drunken whiteboarding sessions. And CISSP exams.

At this point, you’re thinking “Wow – Shack said he was going to help us out! He’s being one of those clique-ish types, though!”. Well…not really. That’s all the harshness I’m giving out, and there are good reasons for this advice. Well…one more, don’t get cocky. We’ve got way too many cocky folks already, and we’re trying to change the dynamic. So here’s some more practical advice for the n00bs:

1. Really, the best security people came from some other backgrounds. I really think you should spend a few years doing something else first. Coding, systems admin or network admin, DBA, etc. How can you secure stuff when you have no experience with it? Security isn’t all about IDS, pen testing, etc. The most important security is mitigating risk in regular old technology design and use, and you should have some hands-on time with THAT before you go saving the world.
2. Understand the following: TCP/IP, Cisco IOS, Windows admin (basic), Unix admin (basic). Pick a scripting language and endeavor to become a little bit proficient with it. Not a lot, that’s OK, but a little Perl-Fu or Python-Fu or Ruby-Fu or just Shell scripting-Fu can go a LONG way. These are basic skills. What about security? Re-read #1 above. Now do it again.
3. Allocate $500 and go visit your friend Amazon.com. Or better yet, roll Ramen noodle style and get used books by perusing titles at www.bestbookdeal.com. It rocks. What to buy? Hacking Exposed, latest edition. Counter-Hack Reloaded. Network Security Hacks (2e). Everything written by Richard Bejtlich. Malware (Skoudis and Zeltser). Security Engineering (2e). Applied Cryptography. This is a good start, look for others too – read them and keep going. Plan on spending $50-100 a month on books.
4. Understand how to lock down operating systems. Read the CIS benchmarks, DISA STIGs, and vendor guides from M$ and others. This is 101 stuff, and you need to know it WAY before you get to the “sexy” things like pen testing.
5. Become familiar with a packet sniffer of your choice. Wireshark is good. So is TCPdump. Both are free, and you can start breaking down packets and looking at them to see what the hell is going on.
6. Learn about Snort. Spend a month or so installing it, tweaking the configs, learning about rule creation, planning architecture and so on. Will it be your only IDS? Maybe, maybe not, but it’s the best for the $$$ and you need to learn.
7. Download the Backtrack security assessment toolkit from http://www.remote-exploit.org/backtrack.html. Load it up in a test network (repeat – test network. Did I mention test network?) and start running some tools to learn about scanning (nmap, hping3), vulnerability scanning (OpenVAS, maybe Nessus for local scans or if you have a license), and pen testing with Metasploit and exploits from Milw0rm and others.
8. Plan on going for the SANS GSEC certification. Forget about your CISSP or anything else right now, you need a solid set of fundamentals, and the SANS Security Essentials course is your best bet. I teach for SANS, full disclosure, but I endorse this with no bias whatsoever – it really is the best for newcomers to the field.

You now have the basics. Specialties, like code security, Web app security, pen testing, network security, etc all come a bit later. I won’t go into all that here, but you should be waking up every day with a fire under your ass. READ! Check out blogs and sites like darkreading.com, csoonline.com, packetstormsecurity.org, and others. Listen to Paul, Larry, John, Carlos and gang at www.pauldotcom.com to get in the spirit of things. And when you tell someone you are new to the field, and you have a legitimate question that they can help with, don’t let their lack of social skills get in the way. If they won’t help you, find some of us that aren’t worried about impressing the clique and we’ll help you. I got my OWN lunch table. And you’re invited. Unless you have, like, body odor or something. Then you’re not.

Information Security

So I was, as usual, inspired by everyday events and news to relate to the infosec community. In its own way, so many of the things we encounter day-to-day have parallels in our security community…but I digress. The topic of the day is “zero tolerance” policies. I recently read an article about a nice young man named Zachary Christie. He’s a good student, learning karate, and a Cub Scout. He’s also a criminal. Well, at least in the eyes of his school system. Why? He had the AUDACITY to bring a fork/spoon/knife camping utensil to school to use at lunch and show his classmates. Zachary, incidentally, is 6 years old. SIX.

I could understand a gentle reprimand. The ol’ “We have a policy here” talk. But Zachary didn’t get that. Nope, this hardcore 6-year old got suspended for 45 days! With the last week in solitary confinement for shanking a fellow inma…errrr, student! OK, I’m kidding about the last part. But the point should be clear – 45 days for this offense is actually punishing the student (very excessively), the parents (who will have to accommodate him with work schedules), and any rational, thinking person in the USA. That’s right, we’re all being punished because this makes us realize just how stupid we can be. And that hurts.

So. What about infosec? Well, we infosec people are policy creators and enforcers. Influencers, too, in many cases, but that’s less relevant here. I’ve had some really interesting conversations in the past with SANS students and Advisory Board members on this same topic. Some are all for draconian policies. Yaaar, matey, walk the plank! Others take a less heavy-handed approach. Which is right? Well, in my opinion (and we all know what THAT means), there are a few policy areas where we must be 100% black and white:

• Theft or intentional mishandling of sensitive data (PII, Trade Secrets, etc).
• Possession of child pornography.
• Intentional hacking or circumvention of access controls to do…anything.
• Espionage.

That’s it. Yep, really. Supporting evidence plays a big role in most (if not all) of these, so even these may not be completely cut and dry. Generally, though, it’s a safe bet to have clear violation rules in place for any of these. What about others, though? What about all those myriad policies that we have painstakingly written that everyone in the organization hates? Some make sense, sure, but there’s probably some that should be visited on a per-case basis. Many people in many organizations hate security people. Some of you will say “so what?”. I say – you’re losing the game. People WILL get around you one way or another, and if they hate you they will try 10 times as hard. I’m not advocating being wishy-washy, and there are plenty of reasons (governance, compliance, industry standards, etc) why certain policies should have less “wiggle room” than others. But if we always approach policy with a “my way or the highway” attitude, we are going to isolate ourselves even more in infosec, and that’s a tragedy. Just something to think about. </rant>

Information Security, Rants

I know this picture’s quality sucks, but it’s my favorite parody of the Homeland Security Threat Level system, so I wanted to include it. Much has been said about this deeply flawed system, and a Tweet from @AdrianLane of Securosis just got me thinking about this again. We’ve all made fun of this system for a huge number of reasons. The big one? It has no impact, representing the most ludicrous example of fearmongering ever put forth by the American government.

There’s some really telling insight here, though, that relates directly to why security is not wholly accepted by people at businesses everywhere. Here are a few corollaries we can draw:

1. The system makes no sense, intrinsically. The colors chosen are arbitrary, and so are the names. When we talk about threats in our environments and networks, we use terms that are really only meaningful to us in many cases, as well. What do those terms mean to the business? What does “Critical” mean versus “High”?

2. The system is meant to spread a bit of fear and keep people on edge. In that regard, it works for many Americans who aren’t clued in to the statistics around terrorist activity likelihood. In short, you’re more likely to be bitten by a rabid snail and die a horrible death than encounter even the slightest hint of terrorist activity in your lifetime. This, of course, is lost on those that actually supported the notion of “Freedom Fries”. Business leaders don’t like FUD, either. Imagine this exchange:

Security guy: We need an IPS!

Business manager: Why?

Security guy: People are attacking our network! We’re all going to die!

Business manager: How are we all going to die? What’s the risk to the business? What else do we have in place? What are the costs?

Security guy: We need an IPS! I need 1 million dollars!

Business manager: Hmmmm….

3. We don’t get enough information about WHY the level is assigned. Sure, this stuff is super-sensitive, but just telling me that things are worse without explaining why doesn’t help me to adapt my behavior in any way. In infosec, we may have the same problem. If I don’t explain WHY the missing patch is a problem, how will a business unit manager understand why I’m ranting about it? Aside from common sense, and reading the news, business managers cannot be expected to understand why security threats are serious, and why vulnerabilities that they can remediate have significant impact if left alone.

4. The worst issue, in my opinion: the Threat Level has absolutely zero actionable information. In other words, it doesn’t tell people what to do. What do you mean, exactly, by “be more vigilant”. How do I get “more vigilant”? Spy on my Muslim neighbors? Well, we make this mistake in infosec all the time. We often fail at helping people help themselves. A classic example of this is the report I generate with a vulnerability assessment. It says a problem is “Critical”. It states the problem, usually in a fairly abbreviated manner. I bring this to someone’s attention. But do I really explain WHY the problem is critical, with explicit descriptions of how it applies in our environment (problem #3, above)? And do I tell people how to fix the problem? And what the risks are of leaving it alone versus fixing? You get my point. It sounds ridiculous, but I have seen MANY reports from pen tests and other assessments that really don’t tell me how to fix the problem, or what happens if I don’t.

Information Security

Call me crazy, but it bothers me that information security is so “hard”. I know, I know, seems like we all say this, and we endlessly rail against the usual evils that make our lives suck on a daily basis: management doesn’t understand, infrastructure is too complex, the Dev teams don’t give a $*@#&, etc. And on. And on. I have lived this life – it’s easy to fall into the mindset of going to work each day with a frame of reference that looks a bit like this:

1. I know my job. ***Whatever this may be***
2. I know my organization. ***Politics, infrastructure, etc.***
3. I know my team and their capabilities. ***Who does what***
4. I know our tools and systems ***Security-specific tools and systems like IDS, SIEM, etc.***
5. I *think* I know what my problems are.

One thing that’s interesting, though, is that we almost never get to build or design a security architecture from scratch. We just keep adding on or changing the Frankenstein monster that is our security machine, and gradually build up the complexity of it all and lose at least some semblance of control. Ugh. Just for the heck of it, what if you could start with a completely blank slate? I’m not talking tools, just a mindset of how to go about things? At the most simplistic level, my mental security model would probably look a little like this:

Network Level: Create a policy based on “Deny All” and allow only what’s needed.

Host Level: Application Whitelisting and Configuration Management via imaging and policy controls.

Application Level: Secure coding and QA, with behavioral assessment and input filtering.

You’ll also notice an up arrow with the term “Behavioral Assessment” – this signifies the importance (in my mind) of behavioral analysis and comprehension as you move from network –> Host –> Application. In other words, most important at the App, least important at the network. This is NOT to say that host and network behvaioral analysis is unimportant, far from it. But as a starting point, I’d go with the App since we should be able to define the flow of business logic within it and then observe deviation.

Now, of course we want change management and patch management and monitoring tools and all of that…but as a simple mental model? I can get my arms around this thing pretty well. So given that we don’t get a “RESET” button in security…how do we return to a simplified view of things and build from there?

Information Security, Musings

So, this post is totally inspired by a Tweet I saw from Zach Lanier (aka @quine). He came! He scanned! He found vulns! He dutifully sent them off to the various IT folks who manage systems and applications! And….(crickets chirping). Nothing. No one cared.

So, this post is meant to give you infosec folks some shiny new ways to get those beloved admins and dev teams to actually RESPOND TO YOUR EMAILS AND PHONE CALLS! Here we go:

1. As if by magic, several cases of Mountain Dew appear in said admin’s cubicle. You could even add a little sticky note – “Call me. I’ve missed you!”
2. Hack your admin’s boss’ computer and change the screensaver to the BSOD! This will create some good humor in the department, and you can conveniently drop by in the throes of this madness and bring up your list of issues!
3. Somehow tie the remediation of those vulns to a free T-shirt. God knows that highly-paid IT professionals will actually engage in physical violence to get a free T-shirt.
4. Send a meeting invite with the subject “Donuts” or “Pizza”. Works every time.
5. Pull the classic “ARP Cache Poison your Coworker” trick! Mwahahaha – no more “ThinkGeek” or “Slashdot” for you! Redirect their HTTP requests for geek Web sites to the Barry Manilow Fan Club site. This will get frustrating. Then, when their entire day is ruined, swing by to hear their tale of woe. Mention how you can “look into the problem” with the network folks. Once things are working again, cash in your “grateful points” to discuss the vuln list you sent.
6. Make a contest out of fixing vulns, or maybe just replying with a reasonable response…? Sure way to get attention? The prize is any-*#$%-thing with XKCD content.

These are just ideas to get you started. Granted, most are silly, or even (gasp!) highly unethical, but hey! Gotta think outside the box here.

Humor, Information Security

Over the last few years, I’ve really noticed a trend in security practitioners who tend to ask: “Are we secure?”

Good question.

The problem with this question is that it implies that an absolute answer is required. However, at this point we can all guess that an answer of “yes” is too ambitious, whereas an answer of “no” doesn’t take into account any protective/defensive measures we may have employed.

Security is, in my opinion, unable to accommodate absolutes. There is no black. There is no white. There is only gray. That then leads to the inevitable follow-on: how (in)secure are we? And that, of course, is a much harder question to answer. Much attention has been devoted to security metrics, and Andy Jaquith’s book on the subject is a hell of a good start. Although lately, however, I’ve been doubting the ability of current risk management and metrics “best practices” to adequately frame the “current state” of our security and risk tolerance. Why?

Simple: Things Change.

Unless we’re measuring constantly and re-adjusting our concepts of risk posture, we’re likely to be (almost) always wrong. In its own right, this represents a series of absolutes itself. Every measurement we make, using your favorite metric or risk analysis measure (SLE, ALE, etc) is a point in time. Thus, an absolute, albeit one that is measured and quantified in some way. However, how do we accommodate for changes? How does a change in the environment impact the measurement we are relying on? I know products like Skybox and Redseal do “what-if” types of analysis, but I’m looking more at the big picture – how do we get a real idea of “how secure” we are? In real-time?

And yes, I know – this seems to be the stuff of unicorns and flying pigs, but I don’t want to be cynical or sarcastic forever. At some point, we need to get this right.

Information Security, Musings

This is NOT intended to be a mean and/or overly cynical post. By no means do I imply that auditors are bad in general, in fact I have been one and still do audit and compliance work today. But there’s some unspoken truths that I’ve encountered over the years, from both sides of the fence. Things that people think and won’t say, and some common circumstances that are just a fact of life in the world of auditing and regulatory compliance. Here goes.

1. I am actually just following a checklist. And that’s that.
2. I do not understand the technology I am auditing. This is really common, and it shouldn’t come as a surprise. Too many technologies, not enough technically skilled people in audit.
3. The well-dressed, experienced greyhairs came in and sold this deal, but I graduated from college 8 months ago and went through ( E&Y || IBM || Deloitte ) auditing bootcamp. And numbers 1 and 2 on this list are present, too.
4. Most firms are really incentivized to help you pass. Why? Because in many cases, you can fire them and get a new  firm that is “easier” on you. This is not a universal truth. But it’s a big business, and no firm wants to get a reputation as “very difficult”. Leading us to…
5. Show me a viable set of compensating controls, and I’m liable to pass you. Or at least get you a neverending series of extensions. This could be exactly the right thing. Or not (if #1 and #2 are in play). They have to be reasonable though. (See #10)
6. Auditing standards suck. Although ISACA and other organizations are trying really hard to help with this, try finding a commonly-accepted auditing standard for Cisco ASA Firewalls, or Ubuntu servers. Lots of random sites, some more well-known than others, but still no universal standard.
7. Compliance regulations suck. They are almost all poorly written, vague drivel with 50 pages to somehow ambiguously describe one central point. PCI is much better, but still lots of grey area. This, combined with #6, leads us to…
8. You can’t have it “your” way. I’ll work with you, in a polite and professional manner. All part of the schtick. But at the end of the day, I’m following my auditing methodology, with my particular interpretation of things, and whatever skills and knowledge I bring to the table. So yes, it’s all about me.
9. I know more than you. The antithesis of numbers 1, 2, and 3 on this list. Sometimes auditors really do know a LOT about an area or areas, and they can really guide you. Two problems usually occur here. First, egos get in the way. Major gender in IT? Male. Do men stop and ask for directions often? No. Second, money and time. Auditors can be educators, sure. But most of the time, they’re there to gather information, provide a report with recommendations, and then check back in. They’re usually billable, and many organizations aren’t paying them for a huge number of training hours.
10. Covering my ass is my major goal. No auditing firm will forget the lessons of Arthur Anderson. Although some firms may still be less-than-ethical, most are 100% aboveboard and will pester the everlasting crap out of you to get enough detail to justify audit results and recommendations. This is ultimately a great thing for everyone, as audits are probably more thorough. But no one likes to admit this.

And here’s a bonus:

• I know you probably don’t like me. And that’s a shame. Better communication and collaboration with auditors would go a long way toward improving audits, controls, and likely security as a whole.

Information Security

And what about ethics?

This is not quite a book review, not enough time for all that, but I did just finish reading an excellent book, really the first of its kind that I’ve encountered. The book “Adventures of an IT Leader” by Harvard Business Press is written as a story, not some horribly dry academic treatise on the subject of managing IT. The plot, in a nutshell, is about a business leader in a turnaround company (new CEO) who is asked to take over IT and shape it up. He knows nothing about IT management, is not technical, and is under a lot of pressure from day one. The book then goes through a series of events and circumstances in this guy’s first year on the job.

I loved it. In fact, for any technical person in IT or infosec who wants to get a good grasp of business decisions and the process you’ll go through in making them, this is a fantastic read. A little contrived, and if you’ve been around a while, you’ll recognize some things and already know others, but a fun book nonetheless.

Why am I talking about it, though, and what’s the relation to the title of this post? Well, about midway through the new CIO’s tenure, the company has a security issue. This is a major topic in the book, although they stereotyped us “security types” a bit (purple hair? Skull T-shirt? C’mon, that’s only for Defcon for most of us). I won’t give away too much plot, overall, but here are the relevant facts:

• Company has sensitive financial data on people (they process loans)
• A fair-sized risk exists due to coupling of an acquisition’s network, security and IT have known about this for a while. Nothing was done (budget priorities.
• Company’s site experiences a DoS attack, coupled with some odd behavior that makes them THINK customer data may have been accessed. They can’t find definitive evidence (logs, etc) however.
• Legal wants them to be proactive and notify customers to be alert for strange account activity.

This brings us to the executive meeting where everyone has to decide what to do. To make this short:

• New CIO recommends a pretty drastic plan to wipe systems and start clean to make sure no more compromises exist. 2-3 days of downtime, planned for a weekend, still a big impact. We all know this isn’t that practical in real life, either, but it’s not wholly unrealistic.
• CEO says “Hell NO” to notifying customers AND shutting down systems. In other words, no GNUs is good GNUs.
• Head Legal Counsel and new VP of Loan Operations (new CIO’s replacement) challenge the CEO, saying they should notify customers to be proactive and wipe the systems.
• CEO promptly fires them both. Meeting adjourned.

Wow. This was a very interesting case study, and one that did not seem TOO unrealistic to me, frankly. There are some later follow-ups in the book, where the CEO explains that business can be a gamble sometimes. Risks have to be taken, regardless of a “higher moral ground” kind of stance. Also, keep in mind that there was no DEFINITIVE proof of data leakage, just suspicions. Other hacking activity (like the DoS) was present, but a data breach was not certain.

What do you think? Aside from legal requirements to notify, if a company feels that it can protect its reputation and save jobs, stock price, etc…is there an occasion when the “silent fix” is the right approach? In other words, clean up the backyard but don’t say a word about it? What if they did the risk analysis and determined there was a 80-90% chance they could pull it off? Mind you, I’m not necessarily espousing this approach, only debating.

Information Security

So it’s time to add a new installment of “BS Filtering for CISOs”. AS I stated in the first post of this series, BS filtering is a critical skill for CISOs everywhere, just as vital to the success of an information security team/program as content filtering and packet filtering for the technical members of the staff (not to suggest, of course, that the CISO isn’t or hasn’t been technical, far from it).The concept of “BS Filtering” does not always mean that people are deliberately trying to con you, though; you may just need to read between the lines, dig a little deeper into statements, etc.

This is particularly the case for dealing with vendors and 3rd parties, where you can get easily misled, contractual language aside. Here are a few tips specific to security professionals that I’ve gleaned over the years.

• Understand the business motivations first. By this, I mean understand what each party wants to get out of the negotiation. In the case of a vendor, it may simply be another sale or a new customer relationship. In the case of a business partner, they may be looking for a new sales or marketing channel, a means to increase revenue directly with you, or they could even be looking for a strong reference partner/customer. Knowing what the underlying motivation is can help you to have a more intelligent business discussion about risks and rewards for both parties involved.
• Do your homework. This sounds like common sense, and to some extent it is, but there’s a few concrete examples for security pros that can be useful to keep in mind:1. Talk to customers, preferably those in the same or similar business as you. You need to get an idea for how security has been handled by this vendor or 3rd-party during the course of their relationship. Put together a list of things that would concern you, and ask to speak with a customer they’ve had for at least a year or more. If they are reluctant to do this, you should be extremely skeptical of doing business with them.

  2. Ask them how they handle sensitive data covered by compliance regulations, if this applies to the scenario. Particularly with the advent of cloud computing and other hosted/provisioned applications and services that are remote from your data center(s), this becomes absolutely critical.

  3. Related to #2, ask them how they will demonstrate adherence to your internal and organization-specific security policies governing sensitive data. How will they keep it separate from other customer data? What guarantees will they give you? How will they respond to a data breach? There should be some contractual language crafted around the answers to these questions, once you’ve had the discussions.

• Ask to see a SAS70 (at the least) or other indication of security in the area where your data/systems/applications will be housed. If possible, arrange a site visit for you to personally inspect the premises and do your own due diligence. I’ve fought for this and won before, and so can you.
• Ask for audit results if possible. Especially those related to your particular data types, such as payment card data.
• Inquire about configuration and hardening standards, and which the organization uses. Do they follow CIS guidelines for Windows builds? Do they use the DISA ESX controls for hardening VMware platforms? Ask to see proof of the build (or image maintenance/deployment) and how often it is audited.
• For vendors hawking gear/software, ask about the volume of support cases maintained and CLOSED on a daily/weekly/monthly basis. Inquire about average turnaround time for support cases, and of course ask to speak to customers before you buy. This really comes down to availability at the end of the day, if the product doesn’t function properly it may be largely useless.

These are just a few of the “anti-BS considerations” you will need when evaluating business partners, vendors, and 3rd party providers. This doesn’t take into consideration the majority of typical operational considerations like uptime, SLAs, etc. For security pros, the most pressing issues are related to handling of data, adherence to internal and external compliance and policy requirements, and availability for security-specific products and services.

Information Security

So this will be hard to swallow for some. Particularly those who idolize folks like Charlie Miller, Dino Dai Zovi, and Alex Sotirov. Or whoever you know that found some amazing hack and paraded it around to win themselves a few minutes of supergeek fame.

Business 101: You can’t forcibly create a market where there isn’t one. It doesn’t work, it never has, it never will. So for those “vulnerability researchers” who are complaining how they are getting the shaft from software vendors who won’t pay them for their software, I hate to break it to you, but you’re shit out of luck, methinks. I think you inevitably have one of three options:

1. Keep finding bugs because you love finding bugs. Get your little minute of fame, and maybe your new MacBook or whatever, and STFU.
2. Sell your bugs to WasiSabiLabi or iDefense or some other marketplace. Maybe even an underground marketplace if your ethics are questionable.
3. Stop doing it. Get out. Find a new hobby. Get some sun, maybe – slowly, though, that pasty skin will burn if you’re not careful!

In a recent article in SC Magazine, Dino Dai Zovi states the following:

“Vendors have been getting a freebie for a while,” Dai Zovi said. “[But] why would I want to sit down and volunteer to find a bug in someone’s browser when it’s a nice, sunny day outside?”

Well, great question! Just DON’T! Seriously, are we all supposed to have some sympathy for folks who volunteer their time to find software bugs? Another dose of reality: all software has flaws. I can live with this. It’s just a part of business. So stop trying to make it seem like it’s these terrible, sloppy vendors who code so badly that SuperSecurityCoderMan has to come in behind them to show them all how bad things really are! Geez. Just SO SICK of this. I respect your skills, bro, but either help the community, take your 15 minutes and move on, or just stop with it already.

The other argument I hear is that “if I didn’t find this bug, some evil h@X0r would”. OK, let it happen. Seriously. If it happens, it happens, we can’t avoid the inevitable forever. But lose the martyr act. I, for one, am over it.

Information Security, Rants