How Google turned me into my mother.

We are facing a big problem, one that's hidden behind the more prominent issues of cybercrime, encryption wars, and vulnerability disclosure. It's endemic to our digital infrastructure, and it's going to get worse over time. And it's so complex that I'm not sure I can do it justice in a blog post. I've been talking about it here:

https://www.youtube.com/watch?v=lU8_S0V_zOQ (B-Sides London)

https://www.youtube.com/watch?v=mKnKQv-0cwE (HouSecCon)

In a nutshell, it has to do with digital delegation.

What do I mean by that? I mean any situation where an online user needs to be able to delegate all or part of their access or capabilities to someone else -- whether temporarily, intermittently, or permanently. Most identity and access management models only deal with delegation in an enterprise context: Alice needs to go on PTO, and Bob needs to cover for her during that time, without anyone confusing the two people for the purpose of accountability.

But real life is more complicated than that, and it involves legal protections as well. Take the reasonably simple example of a minor child. A parent or legal guardian has the authority to administer many things for a child, but the design of online accounts is often muddled. Which signups does the parent have to do, and which ones does the parent simply approve at some part of the workflow? If a registration is asking for a date of birth, whose date of birth are we talking about? And what happens when the child reaches the age of legal majority? Does the parent suddenly have to turn over access to a login, or does the parent drop out of the approval workflow?

At the other end of the spectrum, we have the problem of what happens to online accounts after the owner dies. We still haven't worked that out too well yet -- there are good talks out there by people who have had to deal with it personally -- but death is a pretty permanent condition, as well as a binary one. What about temporary or intermittent delegation?

If you were incapacitated today for a month -- let's say, due to the proverbial bus accident -- who would be able to pay your online bills? A friend can't just go to your bank and say, "Yeah, I just need to be set up as a secondary on this account so I can get into billpay." No, if you were conscious, you would probably just give your friend your password. And if you're using 2FA with that account on your phone (as everyone should do, right?), you'd have to hand over your phone -- oh yes, and the passcode for the phone too. Or would you let your friend change over the 2FA registration to their phone for a while, to make it easier?

That's just one scenario. The harder one, which I've had to live through twice now, is the declining parent who has good days and bad days, and doesn't want to give up control of their accounts. They may be so impaired that they make mistakes with them, or forget how to use the sites, but they won't simply sign everything over to their child (and in some cases, they may already be so disabled that they can't take the legal steps to sign things over anyway).

Dealing with an incapacitated loved one is heartrending. You want to allow them as much autonomy as possible, while protecting them from themselves. Above all, you don't want to have to get them declared legally incapacitated; that will ruin your relationship forever. You simply want to be able to help them out. "Hey Dad, do you just want me to log in and take care of this for you? I know you're tired today, but this bill is due." And in the future, they may have good days where they can go back to doing it themselves; you don't want to have taken over their logins, changed passwords, set up your own phone as the recovery number, and so on. There has to be a better middle ground, between impersonation (which can trigger fraud alerts) and the permanent, legal takeover.

So here's the story behind the title of my talks, and this post. I had to take over my father's Gmail account when he had a stroke, so that I could get into his accounts and reset the passwords, so that I could pay my parents' bills (as well as watch those accounts for fraud). Later, I had to take over my mother's Gmail account, and I set up my personal (non-Gmail) email address as a secondary on her Gmail.

What I found out was that Google helpfully associates the two addresses when you do that, so whenever someone using Gmail tried to mail me at my personal email, Google would say brightly, "Oh, you mean [my mother]!" So whenever anyone mailed me using Gmail -- business associates, friends, merchants, etc. -- the messages would be sent to me, but under my mother's name. That's pretty creepy when it happens.

I went in and removed my email address as the secondary, but it didn't fix the problem. I am now permanently associated with my (now deceased) mother as far as Google is concerned. I reported this to them, but they did not consider this to be a security or privacy issue, so there you are. (I don't want to delete my parents' Gmail accounts, because I don't want an impostor popping up in the future, and there may still be alerts coming in from other accounts I don't know about.)

The bottom line here is that we need a massive overhaul in the design of consumer-facing systems that can take into account different delegation cases. They need to handle authentication, re-certification, and legal proxies, and they need to understand non-binary conditions, while at the same time continuing to protect against account takeovers and fraud.

Right now, this is not a crisis, since the majority of people who are becoming incapacitated did not set up much in the way of online accounts. But as the tech-savvier baby boomers age, it is going to get much worse; I have hundreds of accounts out there dating back decades, some of which I'm sure I've forgotten about and never entered into a password manager. If my children had to take over my business affairs, there would be no other way for them to do it other than online (they don't know how to write a check, and all my statements arrive electronically anyway).

Luckily, a few companies out there are starting to become aware of the issue and offer emergency access functionality. It's a start. But we need global, consistent mechanisms for doing this, and they need to be set up at the point of initial registration, not months after someone has managed to get a legal power of attorney signed and notarized, and has had to fax it to fifteen different entities.

I don't have a ready answer for this, except that a bunch of us need to get to work on it. Our digital future as a society depends on supporting our real-world life cycles.

A matter of taste.

I've figured it out: The word "cyber" is like garlic.

For most palates, just a bit of cyber in anything is enough. It makes it all a bit more interesting.

Some people love cyber so much that they put it in everything, in massive amounts (chicken with 40 cloves of cyber, for example). Others are so sensitive to cyber that they can't stand the faintest whiff of it.

If you've been raised in a culture that uses cyber a lot, you won't realize how it comes across to those who haven't grown up with it. People will pull away from you with horrified or disgusted looks on their faces and you won't know why. When you've been steeping in cyber, you don't notice the smell any more.

There's even a certain part of the United States that just loves its cyber. It puts on a regular cyber festival, where you can get cyber flavor in everything. I've never been to it myself, but I can tell you right now that I will never accept cyber-ice cream.

Some cultures love cyber, and some don't, but if you're part of a couple and only one of you has ingested cyber that day, you're going to have compatibility problems later on that evening.

And one final thought: if you feed your toddler too many spinach pierogi with cyber, she's going to be exhaling that stench for days until it clears out of her little body. Trust me on this one.

Why the airplane analogy doesn't fly.

Don't get me wrong — I love Trey Ford. He is one of the most inspiring infosec pros I know. He's smart, creative, full of mind-blowing ideas, and has energy to spare. And I love his talk at SecTor about what we can learn about information sharing from the aviation industry.

There's just one problem: aviation isn't all that comparable to cybersecurity.

Imagine that instead of flying the plane herself, a pilot had to convince all the passengers on the flight, EVERY flight, to do the flying together. And many of them aren't good at it, and don't care; they just want to sleep or watch videos or whatever.

The passengers change all the time, so you can't keep them educated on what to do. Depending on the size of the plane, there may be tens or hundreds of thousands of passengers helping with the flying. Instead of a finite maintenance crew that's under the direct control of the airline, there are dozens or thousands of different crews from third-party companies, all doing their bits (or not).

The aircraft types range into the thousands, dating back to Kitty Hawk and up to the newest models, and most of them have at least some custom alterations that can be changed between flights, so the various manufacturers won't take responsibility for anything they didn't add. Remember, too, that each of those alterations was probably made for a good reason — or at least, a reason that was good at the time. (That's a huge part of what we don't know about breaches today: we sometimes know the chain of events and contributing vulnerabilities, but we make rash judgments about why they happened without knowing the full story.)

The airlines all have different ideas on how they should equip their planes, so some pilots have one of everything new and shiny, and others have to make do with duct tape and bags of pretzels. (And some airlines are just now thinking that maybe having a dedicated pilot is a good idea.)

Oh, and did I mention? The weather is actively trying to disrupt your flight, usually in a way that you won't notice until it's too late. (Although you still have to worry about hacktivist storm cells that want you to look bad.)

All of these differences highlight our challenge in security: because everything is so complicated, so flexible, and so NOT under our individual control, we can easily blame someone else for their breaches because they did things so differently. And the pilot is nominally in charge, so that's where we concentrate the attention, but even the pilot can't get the toddler in 32B to stop screaming and fly straight. I'm not even going to mention the armchair aviation enthusiasts who sit near the runway with binoculars and lasers and provide "helpful" critique. (Oops, I guess that slipped out.)

So how can we still make use of what we've learned from information sharing in aviation? As Trey says, we can at least collect data now in a way that we may be able and willing to share later. If only we had a black box that collected vital information about a breach in a way that didn't expose the inner workings of the business, or those custom-built additions. If only we could sanitize the data in a way that communicated the important lessons ("don't combine these tray tables with that boarding process, and especially don't add a pilot over 6 feet tall without upgrading the landing gear") but defanged our industry's reflexive attempts at a certain kind of blame ("how stupid was that? We'd never do that!").

When I consider all this, sometimes I despair that we'll ever figure it out. But with positive thinkers like Trey, we may just have a chance.

When your risk profile is different.

Ready for some (more) unfounded speculation?

Both people and organizations tend to want to keep their data within a circle of trust; it's why there has been (and continues to be) resistance to putting sensitive data in the cloud. It's a function of human nature to keep things close -- which is why people still keep files on their desktops or laptops, use USB drives, and run servers at home. You keep your treasures in an environment that you know best, and where you feel you have the most control over them.

According to the Washington Post, President Bill Clinton had had a personal email server at home; Hillary Clinton had a server which had been in use during her first presidential campaign in 2008, and this same server was then set up for her at home when she took the Secretary of State post.

Besides this controversy with her home email server (and yes, I commented on that on CNN, but they must not have liked most of what I had to say), I noticed the other day that apparently Caroline Kennedy had been using personal email as well for State Department business. This suggests to me that they may have had a reason in common for doing this, one that hasn't been highlighted so far:

They both have a very different risk profile from most public officials.

When you're a celebrity -- independent of the position you currently hold -- your threat modeling has to include just about everyone. Any friends you have, any staff members you hire, could turn on you at any time for some perceived advantage. Now, Hillary could have had knowledge that the State Department was bad at securing its own systems, but I don't think that was it. I think she just couldn't trust staffers that worked for the agency and not for her personally. Any of them might try to access her email for political or personal reasons -- and let's face it: she's spent many, many years being embattled. The same would go for Caroline Kennedy, as well as anyone else who was famous before they took office.

In other words, their threat model holds colleagues to be a higher risk than hackers.

If you think this is surprising, you haven't been inside the minds of most non-security people. They have seen and experienced many more threats on a personal level than they have The Notorious A.P.T, so they will defend against the threat they believe in more.

None of us really knows how secure the server ended up being (although it looks like Hurricane Sandy caused natural disasters to become a more prominent part of the threat model, which is why they finally moved it to a provider with an actual data center), so I can't comment on that. Nor am I in any position to comment on the legal or classification issues, since those seem to be changing depending on who's got the microphone at any given time. But from a threat modeling perspective, I can absolutely understand why people want to hold their staff close and their data closer.

Oh, and by the way: if you can't view things from other peoples' perspectives, you're not going to be very good at threat modeling.

Lessons in grown-up security.

Okay, so for the sake of those who can't say anything, I feel I have to say something.

Remember how much you hate people talking about things they don't understand? So do I. And let's face it: if you're not on the inside of an organization, you don't know 100% of what's going on there. Oftentimes it's less than 50%. And if it has to do with security, the percentage can drop as low as 10%.

The hysteria around Chris Roberts supposedly hacking a plane and "making it go sideways" has reached an all-time high. Which isn't to say it couldn't go higher, because media. But let's go through the versions here:

There's what he told people he did.
There's what they interpreted from what he said.
There's what he thought he did.
There's what he actually did.

Then there's the usual Telephone game of people misinterpreting, mis-reporting, and deliberately twisting all those things when they hear them second- and third-hand.

But one fact remains: there are people who actually know what's possible to do, and they ain't talking. Nor will they. Even if Roberts was talking complete bullshit, nobody on the inside is going to step forward and say it publicly. So in this case, silence does not equal assent.

We don't know whether the airline manufacturer already has experts doing pentesting, and they don't need any more, thankyouverymuch. Just because they're ignoring your reports doesn't mean they don't already know about what you think you're trying to say. They don't actually owe you an answer: "No, you didn't really get through, but if you had done THIS instead ..." Just because you decide to walk onto the court, it doesn't mean you get to be a player.

We don't know why United decided to come out with a bug bounty program, although it's mighty responsible of them NOT to encourage randoms to try hacking the avionics. Those who are complaining that it's missing from the bug bounty program are completely clueless in that regard, and have probably never been personally responsible for anything more consequential than a runaway shopping cart.

There may be no truth at all to what the FBI claims Roberts did, and they're just prosecuting him because letting him go free would send the wrong message to other juvenile delinquents out there.

The bottom line is, if you're not actively working WITH the company whose technology you're researching, then you're an adversary. So don't be surprised if they treat you like one. United has every right to say to Roberts, "You didn't actually do anything harmful, but you're a dick, so stay off our airplanes."

You can be a security researcher, but in the immortal, wise words of @wilw: Don't be a dick.

Achievement unlocked?

This week was Hell Week for analysts, otherwise known as Meet All The People, Inspect All The Things, otherwise known as the RSA Conference. Everything was going as expected: I made it through all the speaking engagements (at least one a day this time), spent a little time on the expo floor making a video with the awesome @j4vv4d, did the press interviews, and kissed all the hands and shook all the babies in 30-minute meeting slots.

I was heading over to the Security Bloggers' Meetup, wearing some really spectacular (if you'll pardon the pun) blinking-LED sunglasses that Javvad had given me, and I decided to leave them on for the short walk across the street to Jillian's; I figured they would look good in the dark bar.

All of a sudden, some male conference-goer walks by me, and in passing, he tells me, "There's a switch on the earpiece of the glasses, probably on the right, and you can turn them off that way so they won't run down the battery."

WTaF. Is this guy really mansplaining to me HOW TO OPERATE MY OWN SUNGLASSES?

Yes. Yes, he was.

Now, this is only the most harmless of micro-aggressions compared to what other women go through ("I want to talk to an engineer, not a booth lady"), but what most people don't understand is why we don't take people's heads off at the time. It's simple: you're so stunned, you don't think of the right words until much later. Imagine someone comes up to you out of the blue and says, "Hey buddy, you're wearing socks, we're going to have to ask you to leave." Completely on automatic, you might say, "Oh, okay, sorry about that," and start moving before the rest of your brain finishes processing the "What?" And many of us are trained to be polite first and foremost, so it's a reflex that has to be overcome.

So I said to the guy, "THANK YOU FOR EXPLAINING THAT TO ME. I WOULD NEVER HAVE FIGURED IT OUT BY MYSELF."  (Blogger doesn't have a sarcasm font, but imagine my saying it in one.) And now I'm sure that this Derpasaurus Rex took that completely seriously and thought I was really thanking him. So I should have done better, but it did take a few more minutes for the incredulity to drain away, and then it was too late.

What causes this level of pea-brained sexism to happen? I don't normally encounter it, or at least not so that I'd notice. I'm neither young nor pretty, but I was wearing a skirt at the time, which I don't normally do. What thought process goes on to make someone decide that a middle-aged mother of two, minding her own business, urgently needs sunglasses instructions?

The best I can come up with is this: the guy was truly bothered by the sight of someone wearing blinking sunglasses (on top of the head) in daylight.

"That's wasteful. Oh, it's a woman. She must not know how to turn them off."

And it would never have occurred to him to go through the same thought process if it had been a man. He would have assumed the man had a good reason for leaving them turned on, and it might still have bothered him in some Derpy Engineer Syndrome fashion, but he would have let it go.

Anyway, that was the one surreal moment from the conference this week. I think I'll put away the skirt for next year.

Looking logically at legislation.

There's a lot of fuss around the recent White House proposal to amend the Computer Fraud and Abuse Act, and some level-headed analysis of it. There's also a lot of defensive and emotional reaction to it ("ZOMG we're going to be illegal!").

First of all, everyone take a deep breath. The reason why proposed changes are made public is to invite comment. This is a really good time to step up and give constructive feedback, not just say how much it sucks (although a large enough uproar will be taken into account anyway). Try assuming that nobody is "out to get you" -- assume that they're just trying to do the right thing, as you would want them to do for you. Put yourself in their shoes: if you had to figure out how to protect citizens and infrastructure against criminal "cyber" activity, and do it legally, how would you do it?

There's another really important point here, beyond the one that if you don't like it, suggest something more reasonable. Jen Ellis talks about the challenge of doing just that in her great post. And I agree with Jen that an intent-based approach may be the most likely avenue to pursue, although proving intent can be difficult. I'm looking forward to seeing concrete suggestions from others. As I've pointed out before, writing robust legislation or administrative rules is a lot like writing secure code: you have to check for all the use and abuse cases, plan for future additions, and make it all stand on top of legacy code that has been around for decades and isn't likely to change. We have plenty of security people who should be able to do this.

If they can't -- if there's no way to distinguish between security researchers and criminals in a way that allows us to prosecute the latter without hurting the former -- then maybe that's a sign that some people should rethink their vocations. (It also explains why society at large can't tell the difference, and doesn't like security researchers.) After a certain point, it's irrational to insist on your right to take actions just like a criminal, force other people to figure out the difference, and not suffer any consequences. If you want to continue to do what you're doing, step up and help solve the real problem.

Depends.

I've always had a problem with compliance, for a very simple reason: compliance is generally a binary state, whereas the real world is not. Nobody wants to hear that you're a "little bit compliant," and yet that's what most of us are.

Compliance surveys generally contain questions like this:

Q. Do you use full disk encryption?

A. Well, that depends. Some of our people are using full disk encryption on their laptops. They probably have that password synched to their Windows password, so I'm not sure how much good encryption would do if the laptops were stolen. We talked about doing full disk encryption on our servers. I think some of the newest ones have it. The rest will be replaced during the next hardware refresh, which I think is scheduled for 2016.

Q. So is that a yes, or a no?

A. Fine, I'll just say yes.

Or they might ask:

Q. Do you have a process for disabling user access?

A. It depends. We have a process written down in this here filing cabinet, but we don't know how many of our admins are using it. Then again, it could be a pretty lame process, but if you're an auditor asking whether we have one, the answer is yes.

Or even:

Q. Do you have a web application firewall?

A. No, I don't think so. ... Oh, we do? That's news to me. Okay, somewhere we apparently have a WAF. Wait, it's Palo Alto? Okay, whatever.

Q. Do you test all your applications for vulnerabilities?

A. That depends on what your definitions are of "test," "applications," and "vulnerabilities." Do we test the applications? Yes, using different methods. Does Nessus count? Do we test for all the vulnerabilities? Probably not. How often do we test them? Well, the ones in development get tested before release, unless it's an emergency fix, in which case we don't test it. The ones not in development -- that we know about -- might get tested once every three years. So I'd give that a definite yes.

The state of compliance is both murky and dynamic: anything you say you're doing right now might change next week. Can you get away with percentages of compliance? Yes, if you have something to count: "83% of our servers are compliant with the patch level requirements." But for all the rest, you have to decide what the definition of "is" is.

Compliance assessments are really only as good as the assessor and the staff they're working with, along with the ability to measure objectively, not just answer questions. And I wouldn't put too much faith in surveys, because whoever is answering them will be motivated to put the best possible spin on the binary answer. It's easier to say "Yes" with your fingers crossed behind your back, or with a secret caveat, than to have the word "No" out where someone can see it.

In fact, your compliance question could be "Bro, do you even?" and it would probably be as useful.

Shock treatment.

Another day, another bug ... although this one is pretty juicy. One of the most accessible primers on the Bash Bug is on Troy Hunt's blog.

As many are explaining, one of the biggest problems with this #shellshock vulnerability is that it's in part of the Unix and Linux operating systems -- which means it's everywhere, particularly in things that were built decades ago and in things that were never meant to be updated. There will be a lot of hand-wringing over this one.

But I think I have a way to address it.

It's a worn-out analogy, but bear with me here. Windows in buildings. Now, we know glass is fragile to different extents, depending on how it's made. Imagine that we had hundreds or thousands of "glass researchers" who published things like this:

"Say, did you know that a 5-pound rock can break this kind of glass?" 

Whereupon business owners and homeowners say: 

"Oh jeez, okay, I guess we'd better upgrade the glass in our windows." 

Researchers:
"Say, did you know that a 10-pound rock can break this kind of glass?" 

Business- and homeowners:
"Sigh ... all right ... it's going to be expensive, but we'll upgrade." 

Researchers:
"Say, did you know that if you tap on a corner of the glass right over here that it'll break?" 

Business- and homeowners:
" ... " 

Researchers:
"Say, did you --" 

Business- and homeowners:
"WILL YOU FOR CHRISSESAKE GET A LIFE??"

Yes, glass is fragile. So is IT. We all know that. And we don't expect everyone in the world to have the same level of physical security that, say, bank vaults do.

If there's a rash of burglaries in a neighborhood, we don't blame the residents for not having upgraded to the Latest and Greatest Glass.* No, we go after the perps.

Without falling too much into the tactical-vest camp, I think we ought to invest more money and time into defending the Internet as a whole, by improving our ability to tag, find and neutralize prosecute attackers. Right now, the offerings in the security industry are heavily on the enterprise side -- because after all, especially in the case of the finservs, that's where the money is. There are some vendors who are trying to address critical infrastructure, automotive and health care, which are three areas where people can and eventually will die as a result of software breaches. But we shouldn't wait until that happens to go on the offensive. We need a lot more investment in Internet law enforcement.

This is a case where expecting the world at large to defend itself against an infinite number of attacks just doesn't make sense.



*If you think it's cheap to patch, you haven't worked in a real enterprise.

A tenuous grasp on reality.

"Don't blog while angry," they say. Well, it's too late now.

One thing that has bothered me for years is the tendency for security recommendations to lean towards the hypothetical or the ideal. Yes, many of them are absolutely correct, and they make a lot of sense. However, they assume that you're starting with a blank slate. And how many people ever run into a blank IT slate in the real world?

Here are some examples.

"Don't have a flat network." Well, that's very nice. And it's too late; we already have one. Any idea how much time and effort and money it will cost to segment it out? Start with buying more/new network equipment; think about the chaos that IP address changes bring to multiple layers of the stack. Firewall rule changes (assuming you have them), OS-level changes, application changes (and you can bet that IP addresses are hard-coded all over the place). Think about the timing that a migration needs -- maybe Saturday after midnight until Sunday 6am in the local time zone? And figuring out the policies around which hosts really need to talk to other hosts, on which ports, because while you're playing 52-node pickup, you might as well put in some least privilege.

"Build security into applications early in the SDLC." Yes, absolutely, great idea. What are we going to do with the applications that are already there? Remember those calculations on how much it will cost to fix something that's already in production as opposed to fixing it in development? There's no way around it: you're going to need a bigger checkbook.

"Stay up-to-date on commercial software." Well, what if you're two years behind? (It really does happen.) Again, you're looking at a Project to implement this seemingly simple idea. From the ERP implementation that isn't supported by the vendor yet on the newest operating system, to the dozens of different JVM versions you've got running in production, this is a much more expensive recommendation than you realize.

And yes, these recommendations all hold true for what enterprises should do going forward. But in most cases, they need help making the changes from what they have and what they're doing today.

It would help so much more if instead of couching recommendations and standards in terms of where you should already be, you talked about them in terms of how to get there. After all, security is a process, not an end state; a journey, not a destination. Everyone starts out from different points, and needs different directions to know where to go. There are some ways an organization with 200 security staff and thousands of applications can pivot that will be different from the ways an enterprise can pivot with 2 security staff and with everything hosted by a third party.

So recommendations might look like this: "From now on, you should not automatically grant administrative rights to each desktop user. And here's how you go about taking those rights away from the ones who already have it." I believe incorporating more flexible and realistic security principles will make them easier to swallow by the people who have to implement them.

How to help.

There are a few movements afoot to help improve security, and the intentions are good. However, to my mind some are just more organized versions of what we already have too much of: pointing out what's wrong, instead of rolling up your sleeves and fixing it.

Here are examples of Pointing Out What's Wrong:

• Scanning for vulnerabilities.
• Creating exploits.
• Building tools to find vulnerabilities.
• Telling everyone how bad security is.
• Creating detailed descriptions of how to address vulnerabilities (for someone else to do).
• Creating petitions to ask someone else to fix security.
• "Notifying" vendors to fix their security.
• Proving how easy it is to break into something.
• Issuing reports on the latest attack campaigns.
• Issuing reports on all the breaches that happened last year.
• Issuing reports on the malware you found.
• Issuing reports on how many flaws there are in software you scanned.
• Giving out a free tool that requires time and expertise to use that most orgs don't have.
• Performing "incident response," telling the victim exactly who hacked them and how, and then leaving them with a long "to-do" list.

None of this is actually fixing anything. It's simply pointing out to someone else, who bears the brunt of the responsibility, "Hey, there's something bad there, you really should do something about it. Good luck. Oh yeah, here, I got you a shovel."

Now, if you would like to take actual steps to help make things more secure, here are some examples of what you could do:

• Adopt an organization near you. Put in hours of time to make the fixes for them, on their actual systems, that they don't know how to do. Offer to read all their logs for them, on a daily basis, because they don't have anyone who has the time or expertise for that.
• Fix or rewrite vulnerable software. Offer secure, validated components to replace insecure ones.
• Help an organization migrate off their vulnerable OSes and software. 
• Do an inventory of an organization's accounts -- user, system, and privileged accounts -- and lead the project to retire all unneeded accounts. Deal with the crabby sysadmins who don't want to give up their rlogin scripts. Field the calls from unhappy users who don't like the new strong password guidelines. Install and do the training and support on two-factor authentication.
• Invent a secure operating system. Better yet, go work for the maker of an existing OS and help make it more secure out of the box.
• Raise money for budget-less security teams to get that firewall you keep telling them they need. Find and hire a good analyst to run it and monitor it for them.
• Help your local school district move its websites off of WordPress.
• Host and run backups for organizations that don't have any.

And if you're just about to say, "But that takes time and effort, and it's not my problem," then at least stop pretending that you really want to help. Because actually fixing security is hard, tedious, thankless work, and it doesn't get you a speaker slot at a conference, because you probably won't be allowed to talk about it. Yes, I know you don't have time to help those organizations secure themselves. Neither do they. Naming, shaming and blaming are the easy parts of security -- and they're more about self-indulgence than altruism. Go do something that really fixes something.

Want some more bad news?

I didn't think so, but I had to share this anyway.

I was listening today to a presentation by the CTO of Dell SecureWorks, Jon Ramsey (who for some reason has not yet tried to implore me to stop calling him "J-RAM"). He's always full of insights, but this one was both unsurprising and earth-shattering at the same time.

He pointed out that the half-life of a given security control is dependent upon how pervasive it is. In other words, the more widely it's used, the more attention it will be given by attackers. This is related to the Mortman/Hutton model for expectation of exploit use:

And yes, so far the water is still pretty wet. But he also pointed out that the pervasiveness of a control is driven by its requirement for compliance. 

In other words, once a particular security technology is required for compliance, its pervasiveness will go through the roof, and you've just lowered its effectiveness half-life to that of hydrogen-4. The very act of requiring more organizations to use it will kill off its utility. (And this is even worse than Josh Corman's denigration of PCI-DSS as equivalent to the "No Child Left Behind" act.)

Does this sound an awful lot like "security through obscurity" to you? Pete Lindstrom put it nicely when he said that this means the best security control is one that is the least used.

Now, we all know that security is an arms race between the adversary and the defender, and we also know that obscurity makes up a good portion of the defense on both sides. The adversary doesn't want you to know that he's figured out how to get through your control, and you don't want him to know that you know he's figured it out, so that you can keep on tracking and blocking him.

If so much of security relies on a contest of knowledge, then it's no wonder that so much of what we build turns into wet Kleenex at the drop of a (black) hat.

This means that we need more security controls that can't be subverted or deactivated through knowledge. In this case, "knowledge" often means the discovery of vulnerabilities. And the more complex a system you have, the more chances there are for vulnerabilities to exist. Getting fancier with the security technology and layering it both make it more complex.

So if we're trying to create better security, we could be going in the wrong direction.

The whole problem with passwords is a microcosm of this dilemma. A user gains entry by virtue of some knowledge that is completely driven by what he thinks he'll be able to remember. This knowledge can be stolen or guessed in a number of ways. We know this is stupid. But to turn this model on its head will require some innovation of extraordinary magnitude.

Can we design security controls that are completely independent of obscurity?

If you want to talk this over, you can find me in the bar.

The power of change.

[Yeah, I know, it's been a long time since I updated this blog. When you write for a living, you tend to write the things you get paid for first, and often you don't have any time or ideas left over after that.]

So much of security is about doing it, not just having it. The best products can be useless in the wrong hands: you have something that's supposed to be blocking, but you have it only in logging mode. Or you have it in blocking mode, but you only enabled a few of the available rules. You have it installed in the wrong location on your network because that's the only place you could put it. It tells you what you need to know, but you never have time to look at it. And so on.

I believe that most of security relies on detecting and controlling change. And there are so many aspects to change that have to be considered.

1. Recognizing change. Do you know how your systems, operations and usage patterns are supposed to be? This is probably the biggest challenge, believe it or not. Just knowing your baseline, in everything that happens in your environment, will be impossible for any one group or team. This baseline knowledge is institutional, and will be spread across staff at every level. The network team may know what normal traffic looks like, but they may not know what makes it normal.
2. Detecting change. This might sound like it's the same as the item above, but it's not. Detection implies both recognition and timeliness. It requires finding what has changed, when, in what way, and by how much. 
3. Understanding change. This is the next step in the line: if you know what has changed, and the details, then you should be able to understand the root cause of the change (someone was trying to restore a database) and the implications of the change (it clobbered the production version and now it has to be rebuilt, before the stock markets open in the morning). Or you realize that the change happened for a particular reason, and it will likely be followed by other changes (a connection is made to an unknown external system, and your sensitive data is about to head in that direction).
4. Initiating change. Making a change happen is often interwoven with politics. Why do you want to initiate the change? Are you allowed to request it? Who will execute the change? These are all big questions when, for example, you are trying to get a security hole plugged ("Turn off that SMTP relay! Now!!").
5. Designing change. If you understand the effects of a change, you may need to make sure it happens with certain timing, in a certain sequence, on certain systems, done by certain people. You have to design the change, especially if it's a complex one -- say, a migration off of Windows XP.
6. Controlling change. Making a change happen the way you designed it to happen, within the time frame that you need, without political or organizational fallout, is harder than you think. It may take longer than you hoped for that application's vulnerabilities to be patched. If changes need to be approved by other entities, you may need to persuade them to give that approval. The person assigned to execute the change doesn't actually know how to do it, and is going to do it wrong. Reverting a change could be more complicated than making the original change. 
7. Preventing change. Most people think that security is all about this part, but it's not. Any business requires change, and it's up to the security team to help ensure that change happens in the right ways. In some cases it's still important to stop some changes from occurring (such as malware being deposited), but the prevention has to be fine-grained enough to address only those change cases. For example, this setting can be changed, but it should never be done on Sundays. This rule can be changed, but only by people in this role. Or something can be changed, but it has to create a notification for someone else who needs to know about it. These types of changes should not be made unless they are logged. 

Business rules, as well as risk management decisions*, will dictate how changes are initiated, designed, approved, executed, recorded and evaluated. And if you don't have a good handle on these business and risk requirements, you'll be severely hindered in detecting unauthorized changes and responding to them.

You can't use malware detection if it takes too much work to figure out what a false positive is. Rather than being able to understand those changes, you'll ignore alerts about them until a bigger change happens as a result. (Or until you get a call from the Secret Service.)

There's no point in running a vulnerability scanner if you can't cause fixes to be made based on the findings. Moreover, you shouldn't use a vulnerability scanner as a "compliance detection" tool: it may tell you that your systems are configured exactly the way your policies specified and they haven't changed, but you may have stupid policies.

If you can't figure out the effects of a change, then you will either try to prevent it out of fear, or you will execute it wrongly. If you don't know how a change is made, you can't design a process that will limit collateral damage.

Luckily, you can start mastering all these aspects of changes without spending a lot of money. Just knowing what your systems, applications and users are supposed to do is a huge start towards effective security -- and it takes time, but it's cheap. After that, the road will be different for every organization, because the changes, effects and control points will be different. There will be things you can't change, changes you can't detect, or business processes that constrain (or mandate) change. Look at what power you have over change, to figure out how secure you can be.


*Notice I didn't say "security best practices."

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.