There’s an interesting article in the CBC, where journalists took a set of flights, swabbed surfaces, and worked with a microbiologist to culture their samples.

What they found will shock you!

Well, airplanes are filthy. Not really shocking. What was surprising to me was that the dirtiest of the surfaces they tested was the headrest. (They did not test the armrests.) Also, the seat pocket is a nice incubator and rarely cleaned. Not all that surprising, but I hadn’t considered it.

I’m pleased to be able to share work that Shostack & Associates and the Cyentia Institute have been doing for the Global Cyber Alliance. In doing this, we created some new threat models for email, and some new statistical analysis of

It shows the 1,046 domains that have successfully activated strong protection with GCA’s DMARC tools will save an estimated $19 million to $66 million dollars from limiting BEC for the year of 2018 alone. These organizations will continue to reap that reward every year in which they maintain the deployment of DMARC. Additional savings will be realized as long as DMARC is deployed.

Their press release from this morning is at here and the report download is here.

GAO Report on Equifax

I have regularly asked why we don’t know more about the Equifax breach, including in comments in “That Was Close! Reward Reporting of Cybersecurity ‘Near Misses’.” These questions are not intended to attack Equifax. Rather, we can use their breach as a mirror to reflect, and ask questions about how defenses work, and learn things we can bring to our own systems.

Ian Melvin was kind enough to point out a GAO report, “Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach.” As you’d expect of a GAO report, it is level headed and provides a set of facts.

However, I still have lots of questions. Some very interesting details start on page 11:

Equifax officials added that, after gaining the ability to issue system-level commands on the online dispute portal that was originally compromised, the attackers issued queries to other databases to search for sensitive data. This search led to a data repository containing PII, as well as unencrypted usernames and passwords that could provide the attackers access to several other Equifax databases. According to Equifax’s interim Chief Security Officer, the attackers were able to leverage these credentials to expand their access beyond the 3 databases associated with the online dispute portal, to include an additional 48 unrelated

The use of encryption allowed the attackers to blend in their malicious actions with regular activity on the Equifax network and, thus, secretly maintain a presence on that network as they launched further attacks without being detected by Equifax’s scanning software. (Editor’s note: I’ve inverted the order of the paragraphs from the source.)

So my questions include:

  • How did the attackers get root?
  • Why wasn’t the root shell noticed? Would our organization notice an extra root sell in production?
  • How did they get access to the other 48 databases?
  • Why didn’t the pattern of connections raise a flag? “As before, Equifax
    officials stated that the attackers were able to disguise their presence by
    blending in with regular activity on the network.” I find this statement to be surprising, and it raises questions: Does the dispute resolution database normally connect to these other databases and run the queries which were run? How was that normal activity characterized and analyzed? Encryption provides content confidentiality, not meta-data confidentiality. Would we detect these extra connections?

Specifically, while Equifax had installed a device to inspect network traffic for evidence of malicious activity, a misconfiguration allowed encrypted traffic to pass through the network without being inspected. According to Equifax officials, the misconfiguration was due to an expired digital certificate. The certificate had expired about 10 months before the breach occurred, meaning that encrypted traffic was not being inspected throughout that period.

Would your organization notice if one of hundreds or dozens of IDSs shut up for a week, or if one ruleset stopped firing?

More published incident reports will help us get smarter, and provide better answers to the questions that CEOs and boards are asking: could this happen to us? With this report we an answer that better, but still not well.

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.

I had not seen this interesting letter (August 27, 2018) from the House Energy and Commerce Committee to DHS about the nature of funding and support for the CVE.

This is the sort of thoughtful work that we hope and expect government departments do, and kudos to everyone involved in thinking about how CVE should be nurtured and maintained.

(Updated March 2019, to use a wayback machine link rather than the original link.)

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