Author: adam

Toolbox: After a Conference

Wow. Blackhat, Defcon, I didn’t make any of the other conferences going on in Vegas. And coming back it seems like there’s a sea of things to follow up on. A little bit of organization is helping me manage better this year, and so I thought I’d share what’s in my post-conference toolbox. I’m also sharing because I don’t think my workflow is optimal, and would love to learn how you’re working through this in 2019, with its profusion of ways to stay in touch.

I’ve added a new first step relative to last year, which is to write a trip report, for myself. It captures who I talked to, impressions, followup, and value of the event.

Next, I have a stack of queues to process:

  1. Email. My inbox, but I also have a folder called “followup.” I move a lot out of my inbox to the followup folder so I can see it when I’m back from travel. (I also have a set of monthly sub-folders: followup/august, followup/september, they let me deliver when I say “I’ll get back to you in three months.”)
  2. Signal, iMessage. For both of these, I go back through the conversations I’ve had, see if I had followups or if I dropped the ball on someone.
  3. Linkedin. I get a lot of linkedin requests, and I’m a fairly open networker. Sadly, the UI works very poorly for me. I would love to hear about tools that allow me to effectively move messages to something other than a LIFO queue.
  4. Workflowy. I’m experimenting with this as a note taking tool, and it’s not bad.
  5. Business cards. I go through the whole stack of cards for todo items. I try to write notes on business cards. I discovered I did that on one of 6 cards where I remembered something. That’s not very good odds, and forces me to consider what I might have missed. Still exploring how to make best use of cards without notes. Advice really welcome here.
  6. Slack channels. Go through, look at DMs and channels.
  7. Calendar. For each meeting, think about the meeting, check my notes, see if I remember followups or things that didn’t make it to an email/workflowy note. And yes, there were several discussions that I know we discussed followups that I re-discovered by looking at my calendar.
  8. Photos. Photographs are the new note-taking, and so going back through pictures you took is important.
  9. Twitter, Facebook. I’m trying to break from Twitter, and don’t use Facebook, but I figured I’d include them here because they’re maybe worth remembering.
  10. Read Later queue in Instapaper (new!)

After the queues, as a consultant, I have customer work to get back to and sales contacts to followup on. I have expenses. I haven’t found an expense app that I really like, and so I stuff receipts in an envelope each evening, and then deal with them when I get home.

If I missed any followups, I’m sorry. Please reach out!

But more, I’m curious what works for you? What’s in your toolbox?

Blackhat Best Practice

Shortly, I’m off to Blackhat. My Threat Modeling Intensive classes both sold out (thank you!)

Nearly a decade ago, I put forth a set of best practices:

  • Breath mints
  • Ricola
  • Purell
  • Advil
  • Gatorade
  • This year, I’m adding a travel humidifier. I’ve been using this one, and it really needs to soak for 10 minutes, but then it adds a nice stream of moisture to the room.

Also, at a conference, you’ll ask, and get the question “What’s new?” Learn to answer it well, it will make your conference more valuable.

Actionable Followups from the Capital One Breach

Alexandre Sieira has some very interesting and actionable advice from looking at the Capital One Breach in “Learning from the July 2019 Capital One Breach.”

Alex starts by saying “The first thing I want to make clear is that I sympathize with the Capital One security and operations teams at this difficult time. Capital One is a well-known innovator in cloud security, has very competent people dedicated to this and has even developed and high quality open source solutions such as Cloud Custodian that benefit the entire community.” I share that perspective – I’ve spent a lot of time at OWASP, DevSecCon and other events talking with the smart folks at Capital One.

One thing I’ll add to his post is that the advice to “Avoid using * like the plague” is easy to implement with static analysis, by which I mean grep or diff in a commit hook. Similarly, if you want to block the grant of ListBuckets, you can look for that specific string.

Over time, you can evolve to check that the permissions are from a small subset of permissions you agree should be granted. One of the nice things about the agile approach to security is that you can start tomorrow, and then evolve.

At Blackhat next week, Dino Dai Zovi will be talking about how “Every Security Team is a Software Team Now.” Part of that thinking is how can we take advice, like Alex’s, and turn it into code that enforces our goals.

As we learn from breaches, as we share the code we build to address these problems, we’ll see fewer and fewer incidents like these.

Valuing CyberSecurity Research Datasets

There was a really interesting paper at the Workshop on the Economics of Information Security. The paper is “Valuing CyberSecurity Research Datasets.”

The paper focuses on the value of the IMPACT data sharing platform at DHS, and how the availability of data shapes the research that’s done.

On its way to that valuation, a very useful contribution of the paper is the analysis of types of research data which exist, and the purposes for which it can be used:

Note that there has been considerable attention paid to information sharing among operators through organizations such as ISACs. In contrast, we examine data provisioning done primarily for research purposes. Cybersecurity data resides on a use spectrum – some research data is relevant for operations and vice versa. Yet, as difficult as it can be to make the case for data sharing among operators, its even harder for researchers. Data sharing for research is generally not deemed as important as for operations. Outcomes are not immediately quantifiable. Bridging the gap between operators and researchers, rather than between operators alone, is further wrought with coordination and value challenges. Finally, research data is often a public good, which means it will likely be undervalued by the parties involved.

The paper enumerates benefits of research, including advancing scientific understanding, enabling infrastructure, creating parity in access to ground truth(s) for academics, technology developers, and others who don’t directly gather data. It also enumerates a set of barriers to research, including legal and ethical risk, costs, value uncertainty, and incentives.

These issues were highly resonant for me, because our near miss work certainly encounters these issues of value uncertainty and cost as we consider how to move beyond the operational data sharing that ISACs enable.

I’m very glad to see the challenges crystalized in this way, and we haven’t even reached the main goal of the paper, which is to assess how much value we get from sharing data.

While talking about this paper Robert Lemos has a story at Dark Reading, and Ross Anderson liveblogged the WEIS conference.

Happy Apollo Day!

Today is the 50th Anniversary of “One small step for a man, one giant leap for mankind.”

It’s an event worth celebrating, in the same way we celebrate Yuri’s Night.

The holy days — the holidays — that we celebrate say a great deal about us. They shape who we are. The controversies that emerge when we try to add (Martin Luther King) or remove a holiday (Columbus Day) are controversies because they express who we are, and how that could be changing.

Some of these new holidays are silly: Talk Like a Pirate Day, Star Wars Day.

Some of the holidays are happy, some are somber.


Apollo Day could celebrate the engineering achievement, the risks and dangers of exploration, and the sadness that we haven’t been back.

So, the only way to start a holiday is to start a holiday. Start by wishing people a happy Apollo day, and we’ll see if it reaches escape velocity.

Books Worth Reading: Q2 2019 (Apollo Edition)

  • A Man on the Moon, Andrew Chaikin is probably the best of the general histories of the moon landings.
  • Failure is not an Option, by Gene Kranz, who didn’t actually say that during Apollo 13.
  • Marketing The Moon by David Scott and Richard Jurek. I was surprised what a good history this was, and how much it brought in the overall history of the program and put it in context.
  • Spacesuit: Fashioning Apollo, as mentioned previously.
  • Full Moon. Gorgeous photography, printed from very high quality scans; the author convinced NASA to provide access to first generation negatives. You may need to search on Amazon to find a reasonably priced copy.

Also worthwhile: From the Earth to The Moon (DVD, Blue Ray), and the Museum of Flight Apollo exhibit, in Seattle through September 2nd.

Safety and Security in Automated Driving

Safety First For Automated Driving” is a big, over-arching whitepaper from a dozen automotive manufacturers and suppliers.

One way to read it is that those disciplines have strongly developed safety cultures, which generally do not consider cybersecurity problems. This paper is the cybersecurity specialists making the argument that cyber will fit into safety, and how to do so.

In a sense, this white paper captures a strategic threat model. What are we working on? Autonomous vehicles. What can go wrong? Security issues of all types. What are we going to do? Integrate with and extend the existing safety discipline. Give specific threat information and mitigation strategies to component designers.

I find some parts of it surprising. (I would find it more surprising if I were to look at a 150 page document and not find anything surprising.)

Contrary to the commonly used definition of an [minimal risk condition, (MRC)], which describes only a standstill, this publication expands the definition to also include degraded operation and takeovers by the vehicle operator. Final MRCs refer to MRCs that allow complete deactivation of the automated driving system, e.g. standstill or takeover by the vehicle operator.

One of the “minimal risk” maneuvers listed (table 4) is an emergency stop. And while an emergency stop may certainly be a risk minimizing action in some circumstances, describing it as such is surprising, especially when presented in contrast to a “safe stop” maneuver.

It’s important to remember that driving is incredibly dangerous. In the United States in 2018, an estimated 40,000 people lost their lives in car crashes, and 4.5 million people were seriously injured. (I’ve seen elsewhere that a million of those are hospitalized.) A great many of those injuries are caused by either drunk or distracted drivers, and autonomous vehicles could save many lives, even if imperfect.

Which brings me to a part that I really like, which is the ‘three dimensions of risk treatment’ figure (Figure 8, shown). Words like “risk” and “risk management” encompass a lot, and this figure is a nice side contribution of the paper.

I also like Figure 27 & 28 (shown), showing risks associated with a generic architecture. Having this work available allows systems builders to consider the risks to various components they’re working on. Having it available lets us have a conversation about the systematic risks that exist, but also, allows security experts to ask “is this the right set of risks for systems builders to think about?”

A chart of system components in an autonomous vehicle

Navigation