Does PCI Matter?

There’s an interesting article at the CBC, about how in Canada, “More than a dozen federal departments flunked a credit card security test:”

Those 17 departments and agencies continue to process payments on Visa, MasterCard, Amex, the Tokyo-based JCB and China UnionPay cards, and federal officials say there have been no known breaches to date.

There are some interesting details about the who and why, but what I want to focus on is the lack of (detected) breaches to date, and the impact of the audit failure.

The fact that there have been no breaches detected is usually a no-op, you can’t learn anything from it, but with credit cards, there’s a “Common Point of Purchase” analysis program that eventually turns a spotlight on larger “merchants” who’ve been breached. So the lack of detection tells us something, which is that a large set of PCI failures don’t lead to breaches. From that we can, again, question if PCI prevents breaches, or if it does so better than other security investments.

The second thing is that this is now a “drop everything and fix it” issue, because it’s in the press. Should passing PCI be the top priority for government agencies? I generally don’t think so, but likely it will absorb the security budget for the year for a dozen departments.

The Architectural Mirror (Threat Model Thursdays)

A few weeks ago, I talked about “reflective practice in threat modeling“, thinking about how we approach the problems we face, and asking if our approaches are the best we can do. Sometimes it’s hard to reflect. It’s hard to face the mirror and say ‘could I have done that better?’ That’s human nature.

Sometimes, it can be easier to learn from an analogy, and I’ll again go to physical buildings as a source. (I last discussed this in “Architectural Review and Threat Modeling“.)

Here, we see 91 units of housing delayed for 3-4 months about the color of the exterior:

A project to create 91 units of microhousing on First Hill will take a second try at getting final sign-off from the board…In June, the board asked that the project return for a second pass citing unhappiness with the choice of cement fiber panel finish to step down at the upper levels of the northern edge of the building and echoing public comment that the color of bricks selected for the building was too dark for the neighborhood’s existing “context.” (Capitol Hill Seattle blog)

Now, Seattle has a very visible crisis of housing and homelessness. These 91 units will likely help 91 people or families get off the street. But…the color of the bricks is wrong, so stay on the streets for an extra few months? I exaggerate for effect and consideration, not of this choice, but to ask for reflection — are there choices imposed by security that make such a tradeoff in your organization?

Are you holding back revenue or customer satisfaction for goals that might wait, or might simply not be as important from an executive standpoint?

And if you have a tracking system for projects, it has to work.

The number of Seattle permit applications completing initial review plummeted 75 percent from April to May, from 266 to 66. Builders say problems with the system are setting their projects back by weeks or months…Soon after launch, the new system repeatedly stalled and permit documents appeared to go missing. Tempers grew so hot that at one point the city called the police on a livid customer… In May, less than 11 percent of medium-complexity projects hit the two-week target. (“Rocky launch of Seattle’s new construction-permit system causes delays, anger.“)

Security can be the reason projects are consistently randomized or miss their deadlines, and when it is, other teams work around us, ignore us, or question why they’re paying for a security function that doesn’t function.

The world is a fine source of opportunities to reflect, if only we take advantage.

Space Elevator Test

So cool!

STARS-Me (or Space Tethered Autonomous Robotic Satellite – Mini elevator), built by engineers at Shizuoka University in Japan, is comprised of two 10-centimeter cubic satellites connected by a 10-meter-long tether. A small robot representing an elevator car, about 3 centimeters across and 6 centimeters tall, will move up and down the cable using a motor as the experiment floats in space.

Via Science News, “Japan has launched a miniature space elevator,” and “the STARS project.”

Reflective Practice and Threat Modeling (Threat Model Thursday)

Lately, I’ve been asking what takes threat modeling from a practice to a mission. If you’re reading this blog, you may have seen that some people are nearly mad about threat modeling. The ones who say “you’re never done threat modeling.” The ones who’ve made it the center of their work practice. What distinguishes those people from those who keep trying to teach developers about the difference between a hactivist and a script kiddie?

A book I’ve read recently, “The Reflective Practitioner: How Professionals Think In Action,” gives some useful perspective. It’s about how practitioners use the cases and issues before them to grapple with questions like ‘is this the best way to approach this problem?’ It’s not an easy read by any stretch. It engages in analysis of both what makes a profession, and how several professions including architect, psychologist, and town planner engage with their work.

They may ask themselves, for example, “What features do I notice when I recognize this thing? What are the criteria by which I make this judgment? What procedures am I enacting when I perform this skill? How am I framing the problem that I am trying to solve?” Usually reflection on knowing-in-action goes together with reflection on the stuff at hand. There is some puzzling, or troubling, or interesting phenomenon with which the individual is trying to deal. As he tries to make sense of it, he also reflects on the understandings which have been implicit in his action, understandings which he surfaces, criticizes, restructures, and embodies in further action. It is this entire process of reflection-in-action which is central to the “art” by which practitioners sometimes deal well with situations of uncertainty, instability, uniqueness, and value conflict.

Those seeking to advance their practice of threat modeling would do well to pick up a copy and use it as a lens into reflecting on their practice of the arts.

After the jump, I’m going to quote more bits that struck me as I read, and offer some reflection on them.

Continue reading “Reflective Practice and Threat Modeling (Threat Model Thursday)”

Threat Model Thursday: Legible Architecture

The image above is the frequency with which streets travel a certain orientation, and it’s a nifty data visualization by Geoff Boeing. What caught my attention was not just the streets of Boston and Charlotte, but the lack of variability shown for Seattle, which is a city with two grids.

But then there was this really interesting tidbit, which relates to threat modeling:

Kevin Lynch defined “legible” cities as those whose patterns lend themselves to coherent, organized, recognizable, and comprehensible mental images. These help us organize city space into cognitive maps for wayfinding and a sense of place.

One of the questions I get all the time is ‘what’s the right way to model this system?’ And the answer is the right way is the way that helps you find threats. A good system model balances detail with abstraction. It’s laid out in a way that uses space and relative position to help the viewer follow a story.

Sometimes the underlying physical or logical reality makes that easy. Other times, the reality is more like the streets of Boston, and the official map draws a simple picture with the southern Red Lines being the same length, and similar visual portrayal of the Green Line. But the second map, from http://www.urbanrail.net/am/bost/boston.htm, shows a very different picture.

Boston Subway Map official
Boston map geographic

What’s the right model? What’s the legible architecture of a system?

Modeling a system that’s grown organically over decades is a very challenging task. That’s true of Windows, that’s true of many large enterprise systems, that’s true of the air traffic system. One of the advantages that cloud architectures bring is the opportunity to sweep away some of that historical complexity, and to create comprehensible models. That simplification carries value in terms of architectural consistency, makes it easier to impose checkpoints, and will be augmented over time with the accretion of complexity, inflexibility and eventually need to be swept away itself. That’s rarely easy even when computers are like crops, rather than like pets.

As your threat modeling evolves, it’s important to ask: what’s the legible architecture of these systems?

That’s emphatically not because legible architecture is a goal. It’s a tool. Having understandable models of your systems makes it easier for everyone to interact with them, and that makes design easier, it makes evolution easier. Legible architecture is a property that makes other properties easier to achieve.

Toolbox: After a Conference

Wow. Blackhat, Defcon, I didn’t even make the other conferences going on in Vegas. And coming back it seems like there’s a sea of things to follow up on. I think 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 from how others are working through this in 2018 with its profusion of ways to stay in touch.

First, 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 say “I’ll get back to you in three months.”)
  2. Signal
  3. 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.
  4. 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.
  5. Workflowy. I’m experimenting with this as a note taking tool, and it’s not bad. It’s a bit of a pain to extract the data (for example, I can’t email myself a branch of the tree), but copy and paste from the website is decent. It turns out the website has great export, but still learning.
  6. 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.
  7. Slack channels. Go through, look at DMs and channels. I suppose I should use some feature to note that I intend to followup. Is the Slack way to say “come back to this” to star a message?
  8. 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.
  9. Photos. Photographs are the new note-taking, and so going back through pictures you took is important.
  10. 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.

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?

Photo: Patrick Perkins.

Aretha Franklin

I remember an interview I read with Ahmet Ertegün, the founder of Atlantic Records. He was talking about Aretha, and he said that one of his producers came in, saying that she wasn’t measuring up. He asked the producer what was up, and was told that they were trying to get her to sing like the other successful soul singers, and it wasn’t working out.

Ertegün told the producer that he saw the problem, sitting right there. The fellow didn’t want to let Aretha do what she knew, which was gospel.

There’s a lot of wisdom in that short story, from not wanting to impose our vision of what people should be, to seeing the root of a problem.


In the meanwhile, I just hope that she pulls through. She’s given a lot of joy to a lot of people, and she deserves a long, happy retirement.