VB2010

I just attended my first Virus Bulletin Conference. Luckily it was in Vancouver, just a few hours north of Seattle, so it was an easy drive.   This was also my first time in Vancouver (more than a few hours) and I can say that this is a very beautiful, friendly and modern city with some fantastic food.  We also had a nice room with a fantastic view.

So the conference.

The keynote was by Nick Bilogorskiy of Facebook.  He got into all the evil ways your FB account can be jacked and what the crooks would do with it.  He got into Koobface a bit with hints that those responsible are in the cross-hairs. Graham Cluely blogged a nice summary here.  Take-away: If you must use FB, make sure you use the built-in tools to warn you if your account profile is altered.

First up after the keynote in the Corporate track was Ray Pompon, who is quite the handsome and intelligent fellow.  He did a fantastic job of breaking down how the FBI takes down a malware author.    He had to start late because of the keynote but he made his points well during both the talk and the Q&A.   (disclosure - I am Ray Pompon and this review might be a little biased)

Paul Boccas of Sophos got in some good PDF malware analysis and provided the perfect set up for an Adobe joke when he asked "Is there anyone from Adobe here?" with the response from the crowd "It's a security conference!"   Adobe is indeed the new "Microsoft" when it comes to being a security whipping boy.  The more things change, the more they stay the same.

Websense's Don Hubbard did a fantastic job of scaring the crap out of me with his breakdown of how easily it is to juice search engine results and plant fake news with links to malicious sites.    Highly recommend reading his slides if/when they are available.

I stayed late and caught a great vendor presentation from ESET on under-reporting in the financial sector.  The big problem is that banks tend to record customer stolen account fraud as "other" on the SARs.   Of course banks are incentivized to point the blame finger outside their institution (and in this case, it's partially justified) but in the end, everyone loses.   For more on bank shenanigans regarding misrepresenting risk please see The Headlines for the Past Two Years.

Gunter Ollmann's talk on measuring bot-net numbers was great.  TLDNR - bot-net numbers are misrepresented.  Why?  First, the bot-net operators themselves lie for obvious monetary reasons.  Second, what is considered a bot?  There are lots of categories that are not created equal.  1) Infected victims (the usual number reported) but may not have working rootlets.  2) Members - infected and root kitted but not under C&C.  3) Taskable - the subset of members under C&C but control is time or function limited.  and finally 4) Fully controlled zombies.   Each category is often an order of magnitude smaller than the previous category.   There's a meta-lesson there too - never take simple numbers at face value.  You need to dig deeper and understand what is being measured and how.

This led me to conclude just how generally misrepresented and misunderstood our numbers are in InfoSec.   Botnet numbers are inflated.  Bank customer fraud is under-reported.  Malware victims are under-reported (my talk).  We security folk have a serious problem here.  Not just a lack of actionable intelligence but these bad numbers just undermine our already shaky credibility with the business types.  Take heart, there are solutions out there.  Alex, I'm looking at you and your VERIS. 

Speaking of misunderstood, there was the Symantec Stuxnet talk.   Granted, these guys did a great job of forensics reverse engineering the SCADA payload embedded in the rootkit.  You've probably seen all the tweets, posts, and video from the presentation so I won't add much more.  Suffice to say that it was all very exciting to have news cameras rolling and an excited crowd… only to be confused and deflated (ha) by "theoretical" demo of an attack with some bizarre speculation thrown into the mix.  I wish more infosec folks would study basic intelligence analysis techniques before they attempt to speak in public about such matters.

It also gave me pause to think about Stuxnet and what it means.  It is indeed a very sophisticated piece of weaponized software.  This was no mere criminal malware and almost certainly the work of a (cough, cough) APT. Heck, even the United States could be the APT in this case.  But what does this say about the future of malware?   Will we security folks be ducking and cleaning the blowback and friendly fire of APT's shooting high-powered malware at each other.  Hey, we're all on the same Internet and it's all inter-connected.  Can we at least agree to play nice at a governmental level?   KTHX

Buried in all this, there was a diamond in the rough of a talk by Safensoft on ATM malware defenses.  The talk was the defensive response to the Barnaby Jack talk on Jackpotting an ATM.  Turns out that ATMs are heavily used in Russian for many things, including bill payment for consumers. In Russia, ATM takes your money. This makes them more heavily used and relied upon.  And of course, a lot of the ATMs are just Windows XP SP2 boxen with some ATM code running on it… and many on a network.   Based on this, it was no surprise to find that lots of Russian ATMs were "jackpotted" in 2009.  So Barnaby Jack wasn't just doing bleeding-edge proof-of-concept, he was reporting "old news".    Safensoft, a traditional anti-piracy company, was forced to use a different malware defense approach because ATM hardware was too slow for the usual AV big-blacklist-of-doom approach.  Instead, they went with a white-list focus with heavy integrity checking around program flow.  Sounds like a road map for the future of general AV to me.

General chatting at vendor booths and with other delegates revealed an interesting new fact to me.  As I'm not a deep malware guy, I did not realize just how few anti-X engines are out there.  There are the big guys like Symantec, McAfee, etc and then a lot of OEM and engine-licensing going on with other companies on top of that.  It does make me fear a little bit of a monoculture vulnerability but on the other hand, blacklist collection is tough, tough work.

Other conferences bonuses:
- Gratuitous use of 80's music on Hotel speakers between talks

- Lots of cool accents - Russian, Cockney, Hindi, Irish, Chinese.

- Lots of cool people attached to those accents.  It was a pleasure to meet so many smart and funny geeks in the malware field from all over the world. 

- Hordes of Microsofties attending - their first full year with a real AV product.  Yet overall, their talks were pretty tame.  One of the presenters actually did a magic trick during his talk.  But it was still a psych-101 talk aimed at novice infosecers.

- The Stuxnet balloon pop / May-9-1979 press by Symantec provided rich fodder for jokes… which the Symantec folks laughed along with like good sports.

- A cool presenter gift from the VB folks

Things I hate about security reports, a rant

This post is by request from @shrdlu and how I can say to no to that? 

I am frequently dismayed the quality (or lack there of) in what we security professionals choose to present outside our little geeky enclave.   I’ve covered some of this before when talking about pen-testing / vuln assessment.   

Sadly, it hasn’t improved much.  I am frequently put in the position of having to apologize for our profession’s inability to craft a document that anyone else but a security professional would consider a “business document”*.  This doesn’t even cover the persuasiveness (or lack of) in most “Security recommendations”.  The icing on the cake is that these documents are often the work product of consulting engagements costing tens of thousands of dollars.  When someone spends thirty grand for a pen-test or a firewall recommendation, the value of the work done needs to show in the document.  And I’m not talking about color glossy graphics.  I’m talking about clarity, relevance and clear reasoning.

You wonder why the executives ignore us, this is one big reason.

Now, I’ll just grab a random VENDOR$ report off my desk here and get into some specifics.

Your template makes you look lazy.  And the fact that you used improperly makes you look sloppy.

It’s got hooks for things that I didn’t buy yet there are orphaned headers and text in there from them.  It’s an awkward one-sized-fits-all affair. Does the advice you dispense also fall into that category?  I’m tempted to believe that.

Executive summaries that aren’t summaries and aren’t written for executives

Here’s how the current exec summary reads:

1.       Client hired Consultant to do job XYZ
2.       Consultant did job XYZ using generic technical process blahblahblah
3.       More detail on generic technical process blahblahblah
4.       Job XYZ was done on date ABC, the end.

Huh?  What is this a summary of?  The proposal?  Here’s how I would expect it to read:

1.       Client hired Consultant to do job XYZ and job was performed on date ABC
2.       Consultant found MOST-HEINOUS-FINDING1 explained in 1-sentence non-technical language covering likelihood and impact (repeat as necessary) or Consultant found no significant vulnerabilities and security of Client appears to be sufficient in comparison to comparable organizations
3.       Consultant also found OTHER-FINDINGS but they aren’t that important because of low likelihood or low impact
4.       We’re not perfect and were given constraints in our testing, other vulns could be there, please plan accordingly

Chart junk

Graphics, diagrams and charts that convey almost no useful information or are so confusing that they actually detract from the report.   More common than not in technical reports.  Sadly.  Do yourself a favor and read some Tufte.

Technical Tables of Torpor

Trying read through most tables in reports usually causes, blurry vision, dizziness, and finally sleep.  Sweet, sweet sleep.  The purpose of a table in report (especially if non-techies are going to see it) is to make your reasoning clear, to invite easy comparisons or to clarify a difficult concept.   Think about what you want to convey with a table before you start slapping text and numbers into boxes.   What decisions do want the reader to make using the table? (besides being impressed with your ability to cite lots of data)  Then eliminate everything else that doesn’t need to be there.

Apparently Arbitrary ratings

There are long strings of “high” attached to things like “Total risk” or “Cost to mitigate”.  Executives wonder if this is canned bs (yes, it is) or was this calculated relevant to their organization in a meaningful way (likely not). This just makes us want to see how you came up with the choices.  And often those details aren’t there.  How did you decide that this is a “Magenta priority” and the probability is “Unlikely”.  What does that mean anyway?  Where are you getting your data? (out of your posterior cavity, I bet)

Frontloading reams of technical detail

Technical detail needs to be there.  It falls under category of showing your work and how you came to some conclusions.  But put this stuff in the back.  No one wants to wade through it in the first reading of the report.   It gives me the nagging suspicion that you’re trying to impress me with your technical prowess.   Hint: Good work should not need to call attention to itself.  When it tries to, I suspect it’s the opposite of good work.

Qualitative Quantitative

The security person’s trap – mixing and matching Qualitative (real numbers) and Quantitative (subjective wild guesses) .  Both have their place (as long as their explained) but when their mixed together, or worse multiplied together, it just sets my teeth on edge.  And it confuses anyone who looks closely at whatever is being measured is going to ask “What exactly is being measured here?”  Cut it out.

Lack of examples

Whatever your doing, the more real world examples, you cite, the more credibility you gain. Screen shots, legal citations, news clippings, hacker emails, quote, whatever.  Put them in the report.  Cherry pick a few and put the rest in the back (again, don’t frontload). 

* Before you say it, let me add that if an organization spends a bunch of money on a security report, you can bet your sweet weasel that someone in a suit and tie is going to at least look it over.  So don’t go playing the “these reports aren’t meant for non-techies” card on me.  In any case, I’m a techie and think these reports are terribly written. So there.

Why do I do this?

I've watches this Simon Senek TED talk three times in as many days and it's given me a lot of food for thought.

He talks about the power of why, as in why do you do something. I'm not one for new agey happy talk and platitude pushing. Some of these kinds of speakers remind me of the Sphinx in Mystery Men. But this talk really got to me. It made me think about why I do what I do. Why am I in infosec? There are most days when it's a humiliating painful grind.

So far, I've come up with: I believe that most cyber-crime can be avoided.

Everything I've done in the past ten years stacks up behind this belief. I've consulted on security. I've sold security. I've lectured to infosec students and laymen alike. I've engineered . I've mentored. I even write a web comic about security.


I know there are some people in infosec because of the money, or the challenge, or even the (false sense of) power. Maybe I feel a little bit of all those things, but mostly I think that this hacking crap is far worse than it should be. And I want to do something about that.

VB 2010

Presenting at VB 2010 in Vancouver. Here's the program. My talk will be on "Case study - successes and failures apprehending malware authors"

Does past behavior predict future behavior for finding vulnerabilities?

I'm looking at my risk model for an application and faced with a question about whether past vulnerabilities is a relevant statistic to examine or not.

For example, say I'd found three buffer overflow weaknesses in Application X in past and had them fixed. Is the likelihood of more buffer overflow weaknesses higher, lower, or the same?

Off the top my head, the arguments are:

"Yes, more likely" - the programmers made this mistake several times already, they'll make more. This is the argument the auditors will probably make.

"No, less likely" - the programmers realized the error of their ways and removed all or most of the buffer overflow weaknesses in the entire application. This is the argument the development team will probably make.

"It depends" - Vulnerabilities are a series of independent events or this variable by itself is insufficient to determine predictability.

I'm sure someone's done some analysis in this area, probably with software bugs. Probably involve Markov chains and a lot of math.

Intuitively, I'm inclined to go with the "it depends" answer and throw this measure of my risk model, unless someone says otherwise.

Everyone else is doing a predictions blog post…

I’m going to focus on the growth of semi-automated social engineering. Why? Well, first because we humans need to communicate and technology has recently exploded to facilitate this. Second, the important thing to focus in security is how things fail. Right now, things are failing (as usual) with the user. We can’t expect the user to be rational and security-minded, that’s what our job. So they are the weakest link and will continue to be exploited. Third, I approach infosec with a warfare mindset, not an engineering one. And defense engineering always follows advances in warfare. We will always be playing catch up.

Prediction One - Technology-mediated scamming of users soars past our capability to deal with it
By this I mean, I mean phishing, spearing, fake security alerts, social engineering malware. It will quickly reach the point where it will overwhelm not only our defenses but the even the context we use to describe it. There are so many attack surfaces and so little useful defenses in the hands of the average user, we’re in for a rough ride. Why will this get more prevalent? Well, because of...

Prediction Two - Better use of unclassified and "harmless" data to leverage higher access
Military wonks have been warning us about this for decades. Now we're going to see it go farther into the mainstream, especially with all the info stored in Facebook, LinkedIn, Flickr, blogs, and Twitter streams. Some of the worst stuff is being generated by our friends and family without our consent. Just ask Sir John Sawers. This will lead to...

Prediction Three - Attackers will becoming adept at exploiting unknown critical dependencies
There's dozens of these kinds of undocumented and unexpected linkages between our organizational security systems and the consumer-grade applications we all swim on a daily basis. Password resets that bounce out via email to our iPhone or Gmail accounts. Twitter links with embedded passwords that happen to match our main password. Web mail sites can be used to spread custom malware internally. They're considered low value and therefore have weak security accordingly. And what about those consumer grade systems? Well, expect...

Prediction Four - Larger attacks against "soft" targets because of items 1,2,3
Why hack Twitter, Facebook, Gmail, etc? Because that's where the money is, duh. Most of these services were designed to protect low-value assets and casual attackers. But that value is out of proportion because of the aforementioned dependencies, the value of this secondary data in escalating attacks, and the scam-value of the friend-trust relationships embedded in these systems. Which all leads to...

Prediction Five - The move of the traditional perimeter from the Untrusted Internet User to the Trusted User.
Most of the standard threat models say the normal user is somewhat trustworthy. Many say otherwise that's a bad idea. As items 1-4 become widespread, the popularly accepted models will need to evolve to simply not trusting the average user or customer in the slightest bit. For many high-risk applications, like web-banking or large e-commerce sites, we're pretty much there. Now everything will move to this level, even the common low-value / low-hanging fruit applications and services. Those of us folks who already live in that mindset, we'll be helping the rest of the world deal with the new paradigm. The standard of reasonable care will change to this new baseline and more resources will need to be expended. When will it reach that point? Probably soon. So what can we do about it?

In the near future, I see us faced with two choices: Radically alter the user experience to the point where any high-level application change (like transferring or altering valuables, changing your password or installing local software) looks like something out of a COBIT change control process (approval & authorization, separation of duties, mandatory change windows). Think "sudo" not only in our operating system, but also within our applications. We stuck a toe in the water with Vista and the users hated it. Another solution to pursue is to push more security downwards into the operational core (behavior monitoring, red flagging, white listing and application flow restrictions). Perhaps by combining these two, we can come up with something useful. I hope someone’s already working on a more intelligent warning tool that fires off meaningful alerts like “It appears that you are about to submit your credit card number to a server in Latveria whose domain was registered only two weeks ago. I think is a Phish and you should verify things before continuing.”

Those are my rough thoughts this chilly December day. I'll be thinking and working on solutions to these problems in the coming year. Let me know if you have any ideas that might help.

Ten ways to build/improve your infosec career

I talk to a lot of students and folks just launching their security career. This article is for you. Veterans, feel free to chime in and tell me what I missed or did wrong. On with the list.

1. Communicate in a business positive manner.

Learn to communicate on their terms, not yours. The worst problems that occur in infosec (and in technology) are communication problems. This is because techies don't speak to their customers (the users) in the language that their customers understand. It's also important to phrase things positively and not negatively. Instead of saying - "You can't use
56 bit crypto because the traffic is sniffable and now PCI compliant" in a project meeting, say "We should use newer encryption systems as customer's will expect us to do a quality job securing their data and it will reduce our legal exposure, yet it won't cost us anything to do."

2. Discover your assets
You accomplish goals if you don't know what they are. And you can't protect your assets if you don't where or what they are. After number 1, this is the second most common mistake I see infosec people make. To get an accurate read on this, you need to the grunt work. That means scanning with tools, interviewing people, reviewing documentation and examining configurations - then cross-referencing your results.

3. Do the risk analysis
Take your asset list, map the risks to them and rate them. This is your priority list. Everything you should do should circle back to this. If you've never done a risk analysis before, there are lots of different ways to skin that cat. Here's one. Here's another. And get creative. The bad guys will get creative so remember that when you're doing your analysis.

4. Never assume
If you don't see it for yourself, you shouldn't assume it was done correctly and completely. This is what audits should be about. Assumptions have a way of coming back at you in the worst way - like the confidential data you didn't know existed that is stored on the systems you didn't know were connected to the Internet. It's safe to assume one thing - you'll never know everything.

5. Don't compromise yourself
This is more than just ethics (which is important) but also about segregation of duties and who's orders you obey. The security team should never report to the IT director. IT's mission is to use technology to fulfill the business objectives. Security's mission is to use technology to fulfill the business objectives safely. Sometimes these things overlap, sometimes not. When push comes to shove, IT will let security slide to make a deadline. There are times when security can be sublimated to the greater mission, which brings us to...

6. Remember who signs your paycheck
This is a corollary flowing from items 5 and 1. Just because the organization wants to do something risky, doesn't mean you need to be a roadblock. Your job is to provide information to the decision makers about risk. If the organization is willing to take on the risk, then your job is to make sure it can be done as safely as possible. Remember, business is about risk. And you can never be 100% secure.

7. You can outsource tactical tasks, but never your strategic thinking
I've seen a lot of organizations outsource their firewalls, their log reviews and major project implementations. Sure, if you're got a very tight set of expectations locked into the contract that you can verify on an on-going basis (see #4). I've even seen organizations hire in consultants to do things like write their entire security policy or DR plan. You can bring in consultants to help with these things, but make sure you're feeding the strategy to build upon. You need to make sure that these outsiders are creating solutions that are as flexible and intimately fitting as a pair of good jeans. I've seen organizations throw down tens of thousands of dollars for cookie cutter security documentation which might get them through an audit but doesn't provide more value than that.

8. Stock your tool chest appropriately
Hat tip to shrdlu for pointing out the Alton Brown method of choosing tools. Whenever you can, choose a multitasker over a unitasking tool. You've got a limited budget and you never know what the business guys are going to throw at you (see item 6). The best deals are for things that you can use in a variety of ways to protect yourself in lots of different ways. For me, DLP is useful as a discovery tool (see 2), an access control and even as a general awareness tool (see 3). If can't afford a dedicated virtual server sitting around waiting to guest host the latest greatest VMware security tools then at least have some burned ISOs ready to go.

9. You can break the rules when you've mastered them
Until then, implement the best practices and the PCI compliance standards. They're there for a reason. And most people are getting hacked because they're forgetting to do the simple well-known stuff. This also applies to enforcing your own rules. If you truly understand the security policy, then you'll known when you can bend it (see item 6) and when you must enforce it (item 5).


10. Network
In person, online, at conferences, locally and around the world. Meet other security people and swap war stories. You'll want the advice and you need to commiseration. I try to attend at least one national conference a year and 4 local ones. Plus my blog, the Security Twits and my Brazen Careerist network. Find a mentor and be a mentor. It's important to give and to take. Even if you don't think you have something to contribute, you do (even if it's only to share your fails). And for many of us, the problem is the opposite. Stop bragging and just shut-up-and-listen. Nobody likes a know-it-all.



Christmas Bonus Item

11. The question of specialization
If you're already not along in your career, then you will discover that the consummate security professional knows everything about security. To be worth anything, you should at least be competent with the basics like the ISC2's common body of knowledge . But at some point, you'll be tempted (either by yourself or your organization) to start specializing. If you do end up specializing, my advice is to pick a couple of specialties. Not only does it make you more layoff-proof, but it's also a lot more intellectually interesting. Some of us end up specializing in being generalists (hah), which really means we end up specializing in management because we spend more time overseeing things than actually doing things. That's fine, just get very good at all these items. Heck, if you're a Heidi fan, you'll notice that our beloved geek girl detective specializes in forensics, penetration testing (social engineering, physical security, info reconnaissance) and malware analysis.