What's my name? No, really, what is it?

[Warning: rant ahead. Slow to impulse power, Mr. Sulu.]

Ever since I've been responsible for user-facing applications -- which is probably since the early Jurassic period -- and ever since I've been using pentesters on those apps, which was probably two seconds after the Jurassic was over -- I've run into the same problem, over and over again.

It's the ridiculous security trope that "username and password feedback is bad."

It's one of the first things that a pentester points out: you can find out valid email addresses or usernames by putting in a bad one and looking at the response. Yes, I know this to be the case.

IT'S ON PURPOSE.

Anyone who has had to provide user support on an application knows how much of that burden is due to users forgetting their usernames, or forgetting which email address they used. Remember: you have one application. The user may have dozens or hundreds of accounts in applications across the Internet, some of which they may use only once in a few years. It's unrealistic to expect them to have been writing down which usernames, email addresses and passwords they've been using since the '90s (especially if they were assigned those usernames - remember when that was a fad?). Unless you think it's okay for them to have saved everything in their browser ... no? I didn't think so.

It's bad enough when they get a clear message saying "We've never heard of you," and they're sure that they do have an account on that system.

Can you imagine how much worse the support load gets, and how much more frustrating it is for the user, if the application refuses to tell them what's wrong?

We may or may not have sent a password reset email to the address you typed in. Even if we sent one, you may not be registered on our system, so the password won't do you any good. Ha ha ha. Take THAT, HaXX0rz!!!1

If you want to prevent user enumeration attacks, you had better have a good alternative in mind. You CANNOT forget the real reason the system is there, and what that user understands and needs in order to use it. If you can't suggest anything that helps, then you are myopic in the extreme, and you're probably just playing reindeer games with other hackers, not contributing usefully to the business that hired you.

Treating username feedback as evil is just playing into the "security by obscurity" mindset. If your system can't withstand attacks by someone who knows a valid username or email address, then you have MUCH bigger problems to solve. Throwing your users under the bus because it's easier for YOU is not the way to solve them.

Thank you for listening.

Things I've learned about CFPs.

Here are some great tips in this article on how to submit to calls for papers (CFPs). I'd like to add a few more, based on my own experience:

• Don't be afraid to reveal the plot. Some people think that they need to submit something very high-level and save the good stuff for the actual talk. As it turns out, this isn't true. You have to show a little leg (or a lot) so that the reviewers know enough about what the conference will be getting. 
• Here are some things that I personally find less enticing as topics: presos about reports (why can't I just read the original report, not sit for an hour listening to someone talk about it?); talks about surveys (unless they promise really surprising or controversial results); talks about historical topics (the only person I've known to do this well is Schuyler Towne); and meta-talks that aren't about security themselves, but are about 'X in security.' (Analysts in security, women in security, beards in security, ear-candling in security, whatever.)
• If you're submitting a talk on how bad things are in security, join the club of about 1,000,000 members. If you're submitting a talk on how you fixed something in security, you have a much better chance of standing out from the crowd.
• They say you can't judge a book by its cover, but the cover IS part of the book, and that's all the reviewers are going to see. Make sure the title and the dust jacket blurb are really compelling. Really - go look at some best-selling books for examples. When it comes time for the conference, people are going to choose to attend your talk or not in about half a second when they're reading the schedule. You'll need to grab them right then and there.
• If you're not accepted, ask for feedback. Most conference committees will give you feedback if you ask nicely. This will help you fix your submission for next time. Sometimes it's a matter of "We got 20 submissions on this topic, and sorry, yours wasn't the strongest." Sometimes it's "Are you kidding? Why did you ever think this was an appropriate submission?" I've seen a case where someone submitted the same (appalling) talk abstract over and over again, year after year. Maybe they thought the conference review was a lottery, and they'd win it some day. But if only they'd asked for feedback, it could have saved them the trouble of submitting every year, because it was NEVER going to be accepted.

 Good luck to all, and may the odds be ever in your favor.

Sauce for the gander.

I attended the Dell annual analyst conference a couple of weeks ago, and was privileged to witness something that made me extremely happy.

As is typical with these analyst events, the vendor features a few customer companies who talk about what they've done with the vendor products, how it helped their business, etc. Also, as is typical with analyst events, we all get little souvenir bags handed out to us with vendor-branded schwag.

Well, all the stars aligned this time, because one of the featured customers was Revlon.

And the goodie bags all contained Revlon products. You know -- lipstick, mascara, nail files, that sort of thing. As a sop to the men, there was a masculine sort of deodorant stick included.

I couldn't help but grin when I saw the reactions around the room. Most of the men were looking into the bag with an expression of, "What the ... I don't even ... what IS this? This isn't meant for me. WTF am I supposed to do with this?"

Guess what, guys in technology? This is EXACTLY the reaction that we (straight) women have when we're confronted by a booth babe.

Le boom.

If at first you don't succeed, FAIL, FAIL again.

Here's an example of security FAIL at its finest.

I have an account for a service online, for which I have to manage things for the rest of my family as well. This service recently switched to another company, and I logged into the new website to find that their policy is that my oldest child is considered an "adult dependent," and I have to get permission to manage the service for her. This "permission" comes in the form of an "invitation" that she needs to send me, which sends me a magic code that I have to input from my account, and then my access is enabled, and everything is supposed to be hunky-dory.

The only thing is, my child is not set up with her own account, because up until now she was just set up as a dependent. So I asked Customer Service what to do, and they said, "Have her register an account and then send you an invitation."

To hell with that. I registered her account myself, which was linked to my own member ID anyway. I figured they would bounce a registration with a duplicate email address, so I used a second email address of my own. They didn't even send a confirmation link to that address; as soon as I registered with all the demographic information (which of course I know quite well), I was logged in to "her" account. And I just took care of business.

So here's where the security design fails, bigtime. I don't know whether someone bothered checking for a duplicate email address on registration, but it didn't matter, because they didn't even use it to confirm before finishing the account setup. And there is absolutely nothing to stop me, as a parent, from setting up the account myself. I can have more than one email address. I know all the demographic info. I can set up the challenge questions with answers that I know. So what is the freaking point of this whole "dependent" exercise?

The fact of the matter is, they have nothing in place to stop an impersonator. Short of reviewing the email address and guessing that it's not hers, there is no way to enforce this ridiculous policy. Drop a cookie to make sure the registering browser is unique? I can delete it. Same IP address? Of course; we live in the same house and she's using my computer. Send her some other individual magic ID number to the house? I get her mail.

This is one of these "paper tiger" security policies that simply annoys me for a span of 15 minutes.

The view from the other side.

Many thanks to Wim Remes, (ISC)^2 board member, for sending me his view of the cert issue and for letting me post it here. DISCLAIMER: this is Wim's own view and does not represent the rest of the board or the organization as a whole.

Hey there,

I do disagree on the CISSP being an entry level cert. It's a pity it has been used by HR drones as a bar for selection because I honestly believe that was never the goal of the cert. With prevalence came expectations too high for a piece of paper to fulfill, or for an organisation to prove the contrary. In my opinion the cert, first and foremost, establishes a common vocabulary among professionals that allows us -even though from different backgrounds and with different focus areas- to talk the same language and understand eachother. The second part I believe the organisation does -not the cert itself- is support an ecosystem of professionals. This has been established through a revised strategy (member-focused instead of product-focused) last year and the establishment of our chapter program. This ecosystem relies on an influx of 'new' people and the support of 'elders'.

While I respect your decision, I don't think it's the right one. In what we are trying to accomplish, people like you are elementary. And frankly, there is no other org that is positioned to even try this.

If anything, we need to work on communication. I do know that more than 50% of what I've written here is not commonly known among the membership and that is a very sad state of affairs.

We have done nothing but focus on preparing the org to go full force on the member-focused strategy, because it is the right thing to do.

Again, I fully respect your decision. Nothing I can do about that.

Cheers,
Wim

Going paperless.

UPDATE:  Boy, this generated a lot more response than I had anticipated.

Let me make it clear: I really respect and admire what members of the (ISC)^2 board are trying to do, and they have a big job ahead of them. I don't think the CISSP is completely useless; there are areas where it's quite useful (I could write a whole post just on the challenges of hiring security pros in government). It's just not something I personally want to put time and money into maintaining.

If anyone can make me change my mind, it'll be Wim Remes and Dave Lewis; they can do just about anything they put their minds to. They're the vanguard of people who are trying to improve the industry, and the world is a better place already because of them.

===============

Much as I love some of the (ISC)^2 board members and heavily involved volunteers, I've decided to let my CISSP certification lapse.

I never actually planned to get it to begin with; I only signed up for the exam because there was a job I thought I might apply for, and the CISSP was required. By the time I decided to go in a different career direction, it was too late for me to get my exam fees back (and for that amount of money, I could have bought a laptop or some wicked designer shoes). So I crammed for about a day and a half, went to the exam, came out two hours later, and was done. Relatively painless, except for the extortion I had to do of certain former colleagues to get the recommendation forms filled out.

Since then, having that certification has done nothing for me, except to make me have to look up my number every so often when registering for a conference. As an analyst, I earn CPEs at least once a week, and I suppose if I could just send (ISC)^2 a link like this to be done with the submission, it might be less annoying. But filing them individually? And possibly being audited on them? Ain't nobody got time for that.

Besides, it still chafes me to think of paying good money every year to be allowed to do something I don't want to do anyway: put letters after my name. At this point, CISSPs are so common, they're like a bachelor's degree:* if you have to brag about it, you probably don't have anything else going for you.

After decades of being in IT, I no longer want to bother proving how much I know. If someone can't figure it out by talking to me or reading my writing, then I don't want their job. If they feel so strongly about that certification that they won't waive it for me, then they don't want me either, and that's okay. (And if someone is trying an argument from authority and won't listen to me because I don't have a current CISSP, then send 'em my way; I could use the belly laugh.)

I suppose a CISSP might be useful for people starting out in security, who need to prove that they've actually put in a few years at it and know the basics. It's a handy first sorting mechanism when you're looking to fill certain levels of positions. But by the time you're directly recruiting people, you should know why you want them other than the fact that they're certified. And then the letters aren't important.

I know that the (ISC)^2 board is working hard to pump up the value of the certifications, and I wish them luck with that. I think their biggest challenge will be getting them out of the category of "gate tickets": if having one helps you get through a gate, then you won't feel like you need it any more after that. (You don't have to keep maintaining a college degree; once you've obtained it, that's good enough for anyone who requires it.)

It'll be hard to create ongoing value for those of us who are past that stage in our careers. Especially for those of us who are too old to go kicking down doors. Maybe in the far future, a security certification will hold the same weight as an engineering one, and need to be maintained in good standing in order to practice your craft. But for that to happen, a lot of other attitudes around security will need to change. More on that in another post.



*Which I also don't have, by the way.

The data cleanse.

Everyone talks about the evils of multitasking, and everyone still does it. I'm becoming convinced, though, that the problem isn't multitasking in and of itself; it's the massive ingestion of data that is putting a strain on our digestive systems.

All of this is represented neatly by browser tabs. Think about it: each one represents a window on a full set of data, whether it be a news site, a blog post, an online store, an animated gif, a social media site, or a white paper. You can switch between them instantaneously, and your brain has to make a context switch and encompass the entirety of whatever you're doing with that tab.

Remember when you read just one book at a time? (Okay, maybe two or three, but they were scattered around the house, and you put one down before you picked up the other one.) You didn't have the sheer speed and volume of context switching that we have today just on our computer screens alone.

And that's not counting the additional inputs represented by phones, music, TV, and conversations. Each texting thread is a conversation, an interaction with another person. Texting and email allow you to conduct conversations with a potentially large number of people at nearly the same time, and with each one, you need to remember what has just gone before, and what you were planning to say next.

Conferences just kick up the stress even more for me. In half-hour chunks, I meet anywhere from one to five people, and learn their names, titles, affiliations and roles. I also hear all about what they're working on full-time, and I have to digest as much of it as I can in that 30-minute span. Once they leave, I have to flush the cache and start over again with the next group of people. This can go on all day, for several days: in a typical RSA conference day this week, I gave a talk, met several people beforehand and afterwards, and went through nine or ten 30-minute meetings, followed by group socializing in the evening. I have no idea how many people I interacted with in total, nor can I remember most of them or our conversations, unless I got their business cards or took notes.

Contrast this with the way the previous generations grew up. A person might meet two or three new people in a day if they were busy. More likely, they'd interact with several people they already knew in an office, or classroom; they might go home and have a phone conversation with one or two people. They'd read a book or a magazine, or they'd watch a TV program (this was before DVRs, so whatever was on is what you'd watch, until it was done). Pretty much one at a time, with some amount of overlap, but nowhere near the broadband mode we function in today. And if you grew up in an isolated area, you might not talk to anyone else on a regular basis unless you lived with them. Some people didn't read more than one or two books in a year, if they read them at all.

The most challenging multitasking I did in my youth was waiting tables, where you only needed to remember the status of six tables at any given time (during a rush, getting up to nine tables was really pushing it). But at least I didn't have to remember more than who was waiting for their cheeseburger, and I could forget everything about the customers as soon as they left the restaurant.

So sometimes I need to go on a data diet. I need to dial back to the amount of inputs that my parents and their parents had. That means putting down the computer, putting down the phone, and doing something for a sustained period of time that doesn't involve reading, and that requires direct focus. (Cooking is good for this, because if you don't pay attention, you're likely to get hurt or at least burn the food.)

Think of it as Paleo for the Brain. I need to consume data the good old-fashioned way, without artificial inflation or modification: having one input going on at a time, where you chew your data thoroughly before you swallow.

If you are feeling frazzled and want to try this, I suggest starting with a Data Cleanse. Stop reading. Don't read anything. Don't talk to anybody. Don't listen to music or watch TV. Just sit in a room without doing anything more complicated than, say, folding laundry. It can be excruciating if you're not used to it; you miss the constant streams of inputs, and your brain doesn't know how to generate its own at the same rate. But eventually your mind will spin down, and you'll go back to having one clear, comprehensible thought at a time that will last for more than a few seconds.

Then you can work your way back into connectivity. Watch one movie -- all the way through, beginning to end (and without the commentary track turned on). Write a long letter or blog post. (See what I did there?) Call someone up on the phone (how quaint!) and talk to them for at least fifteen minutes. Draw a picture. Go for a slow walk. Be conscious of what you're taking in, and throttle the rate. Make sure to take data breaks where you're not interacting with anything or anyone in a way that involves language.

Don't get me wrong: the Internet is a nifty place. But sometimes it feels as if I've been feeding my brain a bunch of pork rinds and ice cream. In order to have higher quality thoughts, I need to have fewer of them, and that means taking in less fuel for the fire.

Pack all the things!!

It's almost RSA time. I haven't figured out yet how many pallets of business cards to bring along, but I have got my two dozen Band-Aids and blister cream, three pairs of shoes, and two backup power supplies. So I'm pretty well set.

I'm looking forward to spending at least some of Sunday at B-Sides San Francisco, where there are some cool talks such as "Sorry Your Princess is in Another Castle: Intrusion Deception to Protect the Web" by Kyle Adams, and "My First Incident Response Team: DFIR for Beginners" by Chort (I feel as though the latter one should come with a picture book and a juice box).

I missed TongaCon last year, and I simply can't do that any more; if @Gillis57 is going to rickroll the Tonga Room again, I need to be there to lend a hand.

On Monday I'll be moderating two panels at the AGC Partners' 9th Annual West Coast Emerging Growth Conference (and that's the only time I'll try to type that again or say it out loud for the week). "New Frontiers in Endpoint Security" and "Taking the Fight to the Adversary: Threat Intelligence in 2013" are both going to be fun -- not just because there are going to be great panelists from many companies, but also because there have been some recent headlines that fit very well with both topics.

Tuesday is our company's breakfast event, and it's another chance to catch up with a lot of people I missed seeing last year. Wednesday morning is my panel with esteemed colleague Daniel Kennedy, "Psychographics of the CISO," also starring two actual live rockstar CISO types. And it'll be great to see the crowd at the Security Bloggers' Meetup in the evening. Rumor also has it that the Girls of Misogyny Networks will be in evidence somewhere on the RSA exhibit floor.

Friday is my talk with Andy Ellis (@csoandy) on "Living Below the Security Poverty Line: Coping Mechanisms," and I'm happy to be able to present this topic in front of an important audience.

And the rest of the time? Well, my Outlook calendar view for the week currently says "66 items."

See you there.

Exercises left to the reader.

The Mandiant report on the threat group it calls APT1 has made a big splash, and deservedly so: the combination of juicy details and actual data such as IOCs (indicators of compromise) is another example of groundbreaking data-sharing around security breaches. Of course, the other side to the publication is its assertion that APT1 is Chinese in origin, and most likely a part of the Chinese government; this is going to provoke a lot of heated discussion.

I've seen some responses already from skeptics, casting doubt on the report's conclusions based on the fact that it didn't include any alternative conclusions other than two that pointed at China (operating either officially or unofficially). Before I get into my own opinion on it, I'd just like to throw out some considerations.

First of all, read the report in its entirety. The authors spent a lot of time connecting every dot they listed, with the proper amount of hedging words in place. Like other high-data reports such as the Verizon DBIR, this one included alternative explanations and caveats in many places. Follow the chain of logic and look at all the data presented before you start to poke holes in it.

Now let's think about some of the assumptions, either implicit or explicit, in the report's assertions. We can call out some alternatives, whether they're realistically possible or not. In no particular order:

Because of the scale of its operations, APT1 must be centrally organized and funded. 
Alternatives: it could be organized, but not from within China; it could be loosely affiliated without being centrally so; it could be using individually contributed resources.

Only the Chinese government has the resources for such an operation.
Alternatives: a very large company or extremely wealthy individual could provide the necessary resources; a different government could be providing them.

An operation that large in scale could not go unnoticed by the Chinese government; therefore it would be operating at least with approval, if not support.
Alternatives: it could be an operation outside of China, faking very large amounts of China-based IP blocks, domain registrations, and other indicators of origin (such as phone numbers); the Chinese government might not know about it, might be unable to stop it, or might simply not care to.

Bad English speakers that use simplified Chinese keyboard layout settings must be native Chinese speakers.
Alternatives: the APT1 group is very good at planting false flags using Chinese speakers (native or not) and using bad English.

Because the three revealed personas appear to be working together and sharing resources in the same geographic location, they must be working for 61398.
Alternatives: they could simply be three people in a social group or other organization that is also located in the region, or is using the same false flags.

Because this linked activity has been going on for so many years (with domain registrations starting as early as 2004), it must be using the same people, the same resources and be supported by the same central organization.
Alternatives: it could be the same people over time, but not affiliated with the same organization; it could be different individuals who "take the reins" and continue the same general activity.

Because APT1 is attacking industries listed in China's strategic five-year-plan, it must be furthering China's goals.
Alternatives: those industries could be on the strategic lists of a lot of countries, and the match with China could be a coincidence.

These are just the ones coming off the top of my head. Now, let's take a step back:

Would any one of these alternatives, if it proved to be correct, torpedo all the other assumptions? Or would a large number of all the alternatives have to be correct, and fit all the available evidence?

In other words, how probable do these alternatives need to be in order to supplant all these assumptions?

(This is my amateur version of an ACH, because I am not in that line of work.)

Now, bear in mind that the evidence laid out in the report may not be all the evidence; it might just be the parts that Mandiant feels are safe to disclose. So the evidence may be even more compelling than we know. Working with what we're given, it appears to me that unless you assume a large-scale conspiracy or an equally well-resourced organization that can fake being sourced in China extremely well (without the knowledge or cooperation of the Chinese government), the preponderance of the evidence points most simply to Mandiant's conclusion. To put it another way, an alternative conclusion would have to be supported by a larger number of less probable, more complicated scenarios that would all have to fit themselves to the facts even better than the China theory does.

It could be that the evidence in the report is either partially or wholly incorrect, or there's a bunch of evidence that contradicts it (and supports the alternative conclusions) that we just don't see. What other evidence would need to show up to do the trick? And how probable is that?

So it's kind of like insisting that the Moon landing was faked -- it would require a perfect conspiracy of silence from hundreds of people over decades, and more sophisticated special effects technology than we know to be available at the time. Sure, you could come up with an alternative conclusion that fits the same evidence, but you'd have to work a lot harder at it.

Would you rather believe that there's an extremely clever and powerful organization out there that is managing to look over years as though it's sourced in China -- without making any mistakes to give it away -- and that the Chinese government can't do anything about? Or would you rather believe that there's a long-term, Chinese government-approved hacking group that isn't perfect and has left quite a few clues behind?

There will never be an airtight case one way or the other, but these things aren't binary. From what Mandiant has presented, the simplest explanation is the one it's offering. It's politically explosive, of course, and that's why belief comes into play. But if you have to do more work to deny something than to accept it, you might want to reconsider your chain of logic.

All up in your bitness.

We knew it would happen: another security vendor gets hit: this time Bit9, which was admirably quick to disclose after it got in touch with its affected customers (and that's the order it should have happened in, folks). We also knew this would follow: the piling-on (I think Bromium wins the ambulance-chasing award this time around). Which is only fair, in that everyone is tempted to pile on every time there's a failure that is linked to a competitor.

But there's a big gap between those who are all pointing and laughing and those who sympathize. It falls along very clear lines: those who have spent time in defense and those who only know offense; those who enjoy pointing out flaws and claiming to have the answers, and those who have had to clean up after the proof that there are no complete answers.

Guess what? If your "solution" needs to be 100% implemented to be successful, then it's never going to solve the problem. Because in the real world, there's no such thing as 100%.

Security is an unrelenting business, one that you can never prove is done adequately. You'll never be finished, and you can never know if you can even take a break. And it's never fully appreciated by the people who make a living based on that reality: the vulnerability finders and the "solution" providers.

You may walk into an enterprise as a consultant, and you may be focused on addressing one particular problem (let's say, implementing monitoring). You may just assess the current situation, prescribe some controls, wish the customer luck, and be on your way to the next gig. Or you might even stick around to see that one project to its "completion" -- in which case, you'll be there for months or years. But unless you spend a year in the captain's chair, trying to cover every possible contingency with fallible humans, limited budget and "helpful" researchers coming up with new ways that your systems are attackable, you don't understand a thing about real defense.

If you are playing just one position, you don't understand the whole game.

Defense is frustrating; it's boring; it's tedious. It's not sexy when you are sitting in a boardroom with an auditor, or when you are looking at a list of scanner findings and trying to manage the year-long projects to fix them. You need an accountant's attention to detail, the skills of a master social engineer, the diagnostic skills of a doctor, and the patience of a saint. In short, you need to know everything that every possible attacker does, and you need to block all of it, all the time, immediately, using resources that you will never completely control.

So if you're one of the ones scolding a breach victim, you're just displaying your own ignorance of the reality of security in front of those who know better. Think about that for a while, before you're tempted to pile on.

Training for RSAC.

Yes, I'm getting ready for the RSA Conference next month in San Francisco. RSA is a particularly brutal week for those in my line of work; thus far I'm meeting with 23 vendors, most of them in 30-minute sessions, and that's not counting the time I'll be walking the exhibit hall, trying to meet with more. I have three panels and one talk to give during the week. We won't mention all the vendor events in the evenings, both public and private, the side conferences taking place, or the fun gatherings like the Security Bloggers' Meetup.

In order to get ready for this challenge, I've been doing the following exercises, which you may want to try as well:

• Walk three miles in heels; drink two cocktails and then walk another mile without spraining an ankle.
• Stand for two hours in one spot, holding a tiny napkin full of mini-quiches and seared tuna canapés in one hand, a glass of Pinot Noir in the other, and handing out business cards with the other other hand.
• Go to a public restroom and practice removing stains from the aforementioned wine and canapés from a white shirt.
• Do wind sprints through a hallway full of high school students to practice the art of the two-minute break between one-on-one meetings.
• Speed-read through books on calculus, knitting, quantum mechanics, teleology, bread baking, and constitutional law to get ready for reams of vendor brochures and white papers.
• Practice lip-reading in a dark room by the light of strobes and lasers. 
• Memorize 80 names per day out of the phone book.
• Practice listening earnestly to comedian monologues without cracking a smile or giggling.
  
  and finally ...
  
• Go geocaching in Costco to practice finding the one vendor at RSA that is not claiming to do 'big data' or 'analytics.'

 See you there.