A PARROT has become the latest voice to fool Amazon’s Alexa voice assistant after ordering gift boxes using an Amazon Echo. Buddy the African Grey Parrot, mimicked his owner’s voice so convincingly that her Amazon Echo accepted the order for six gift boxes. (“
Parrot mimics owner to make purchases using Amazon Echo
.”)

As Alexa has a facility to require a PIN code before placing an order, it was really down to the family that their bird was able to make the request.

Of course, Buddy would have been unable to learn the PIN.

Via Michael Froomkin.

There’s an interesting new paper at bioRXiv, “The Readability Of Scientific Texts Is Decreasing Over Time.”

Lower readability is also a problem for specialists (22, 23, 24). This was explicitly shown by Hartley (22) who demonstrated that rewriting scientific abstracts, to improve their readability, increased academics’ ability to comprehend them. While science is complex, and some jargon is unavoidable (25), this does not justify the continuing trend that we have shown.

Ironically, the paper is released as a PDF, which is hard to read on a mobile phone. There’s a tool, pandoc, which can easily create HTML versions from their LaTeX source. I encourage everyone who cares about their work being read to create HTML and ebook versions.

Threat Modeling and Architecture” is the latest in a series at Infosec Insider.

After I wrote my last article on Rolling out a Threat Modeling Program, Shawn Chowdhury asked (on Linkedin) for more informatioin on involving threat modeling in the architecture process. It’s a great question, except it involves the words “threat, “modeling,” and “architecture.” And each of those words, by itself, is enough to get some people twisted around an axle.

Continue reading

Breach Vouchers & Equifax 2017 Breach Links

[Thursday, September 21th is the latest of 5 updates.]

When I wrote “The Breach Response Market Is Broken,” I didn’t expect one of the players to validate everything I had to say. What I said was that the very act of firms contracting with breach response services inhibit the creation of a market for breach response, and the FTC should require them to give vouchers to consumers.

Vice Motherboard is reporting that “Firm Hired to Monitor Data Breaches Is Hacked, 143 Million Social Security Numbers Stolen.”

It’s not clear what database was accessed. On their website, Equifax says “No Evidence of Unauthorized Access to Core Consumer or Commercial Credit Reporting Databases” and “Company to Offer Free Identity Theft Protection and Credit File Monitoring to All U.S. Consumers.”

But here’s the thing; I don’t trust Equifax to protect data that … they just failed to protect. I want protection from an independent firm.

Equifax’s self-dealing in providing breach response services is unfair. No rational, well-informed consumer would select Equifax’s service in this situation. Equifax’s offering of credit file monitoring to all US consumers is also an unfair trade practice, which undercuts innovation, and limits the ability of new entrants to deliver effective services.

The FTC should require Equifax to send a voucher to each impacted individual which can be used to purchase any identity theft protection service on the market as of August, 2017.


Usually I don’t try to blog fast moving stories, but I may make an exception.

Update 1, later that day:

Update 2, Sept 9:

  • The International Business Times reports “Equifax Lobbied To Kill Rule Protecting Victims Of Data Breaches.” They report Equifax wrote “a rule blocking companies from forcing their customers to waive class action rights would expose credit agencies ‘to unmanageable class action liability that could result in full disgorgement of revenues’ if companies are found to have illegally harmed their customers.” It’s a nice life, having the government block your victims from suing you, especially if you’re worried that the harm is great enough to result in ‘full disgorgement of revenues.’ Now, you might argue that’s hyperbole, but maybe it’s a real fear.
  • The Onion reports “Equifax Impressed By Hackers’ Ability To Ruin People’s Finances More Efficiently Than Company Can.”
  • Equifax once brought me to a Nine Inch Nails concert, and under the payola rules, I ought to have disclosed that when writing about them. It was over a decade ago, and had slipped my mind.

Update 3, Sept 12:

Update 4, September 16:

Update 5, September 21:

Open for Business

Recently, I was talking to a friend who wasn’t aware that I’m consulting, and so I wanted to share a bit about my new life, consulting!

I’m consulting for companies of all sizes and in many sectors. The services I’m providing include threat modeling training, engineering and strategy work, often around risk analysis or product management.

Some of the projects I’ve completed recently include:

  • Threat modeling training – Engineers learn how to threat model, and how to make threat modeling part of their delivery. Classes range from 1 to 5 days, and are customized to your needs.
  • Process re-engineering for a bank – Rebuilt their approach to a class of risks, increasing security, consistently and productively across the org.
  • Feature analysis for a security company – Identifying market need, what features fit those needs, and created a compelling and grounded story to bring the team together.

If you have needs like these, or other issues where you think my skills and experience could help, I’d love to hear from you. And if you know someone who might, I’m happy to talk to them.

I have a to-the-point website at associates.shostack.org and some details of my threat modeling services are at associates.shostack.org/threatmodeling.

Star Wars, Star Trek and Getting Root on a Star Ship

It’s time for some Friday Star Wars blogging!

Reverend Robert Ballecer, SJ tweeted: “as a child I learned a few switches & 4 numbers gives you remote code ex on a 23rd century starship.” I responded, asking “When attackers are on the bridge and can flip switches, how long a password do you think is appropriate?”

It went from there, but I’d like to take this opportunity to propose a partial threat model for 23rd century starships.

First, a few assumptions:

  • Sometimes, officers and crewmembers of starships die, are taken prisoner, or are otherwise unable to complete their duties.
  • It is important that the crew can control the spaceship, including software and computer hardware.
  • Unrestricted physical access to the bridge means you control the ship (with possible special cases, and of course, the Holodeck because lord forgive me, they need to shoot a show every week. Scalzi managed to get a surprisingly large amount from this line of inquiry in Red Shirts. But I digress.)

I’ll also go so far as to say that as a derivative of the assumptions, the crew may need a rapid way to assign “Captain” privileges to someone else, and starship designers should be careful to design for that use case.

So the competing threats here are denial of service (and possibly denial of future service) and elevation of privilege. There’s a tension between designing for availability (anyone on the bridge can assume command relatively easily) and proper authorization. My take was that the attackers on the bridge are already close to winning, and so defenses which impede replacing command authority are a mistake.

Now, in responding, I thought that “flipping switches” meant physically being there, because I don’t recall the episode that he’s discussing. But further in further conversation, what became clear is that the switches can be flipped remotely, which dramatically alters the need for a defense.

It’s not clear what non-dramatic requirement such remote switch flipping serves, and so on balance, it’s easy to declare that the added risk is high and we should not have remote switch flipping. It is always easy to declare that the risk is high, but here I have the advantage that there’s no real product designer in the room arguing for the feature. If there was, we would clarify the requirement, and then probably engineer some appropriate defenses, such as exponential backoff for remote connections. Of course, in the future with layers of virtualization, what a remote connection is may be tricky to determine in software.

Which brings me to another tweet, by Hongyi Hu, who said he was “disappointed that they still use passwords for authentication in the 23rd century. I hope the long tail isn’t that long! 😛” What can I say but, “we’ll always have passwords.” We’ll just use them for less.

As I’ve discussed, the reason I use Star Wars over Star Trek in my teaching and examples is that no one is confused about the story in the core movies. I made precisely this mistake.

Image: The Spaceship Discovery, rendered by Trekkie5000. Alert readers will recall issues that could have been discovered with better threat modeling.

Organizing threat modeling magic

I was inspired to develop and share my thoughts after Adam’s previous post (magical approaches to threat modeling) regarding selection of the threats and predictions. Since a 140 characters limit quickly annoys me, Adam gave me an opportunity to contribute on his blog, thanks to him I can now explain how I believe in magic during threat modeling.

I have noticed that most of what I do, because it is timeboxed due to carbon based lifeforms constraints, needs to be a finite choice selection from what appears to me as an infinite array of possibilities. I also enjoy pulling computer related magic tricks, or guesses, because it’s amusing and more engaging than reading a checklist. Magic, in this case, is either pure luck or based on some skills the spectators can’t see. I like when I think I’m having both.

During the selection phase of what to do, there’s a few tradeoffs that have been proposed such as coverage, time and skills required. Those are attack based and come from the knowledge of what an attacker can do. While I think that those effectively describe the selection of granular technical efforts, I prefer to look at what are his motivation rather than the constrains he’ll face. And for all that, I have a way or organizing it and showing it.

 

Attack Tree

When I think about the actual threats of a system, I don’t see a list, but rather a tree. That tree has the ultimate goals on top, and then descend into sub-goals that breaks down how you get there. It finally ends up in leaves that are the vulnerabilities to be exploited.

Here’s an unfinished example for an unnamed application:

A fun thing to do with a tree is to apply a weight on a branch. In this case the number represent attacker made tradeoffs and is totally arbitrary.

If you keep it relatively consistent to itself, you end up with an appropriate weighting system. For this example, let’s say it’s the amount of efforts you estimate it takes. You can sum the branches in the tree and get sub-goals weight without having to think about them.

And from that we can get a sum for the root goals:

But then how do I choose to prioritize or just work on something?

I could just say, well I’m going to do the easiest things to do, maybe because finding an SQLi in the application is easier than finding a slow API request, so better start looking at that first.

But regarding to decision, I often decide to do the most common human behavior: just don’t do it myself.

With the help of the tree, I just let the actual business reality do the selection on which root goals to pick. By that I mean the literal definition of reality, although nowadays people seems to forget what it really means:

“reality · noun · 1. the world or the state of things as they actually exist, as opposed to an idealistic or notional idea of them.”
– Google Almighty

I never ask the business line if they think they’ll have SQLi, but rather, if they worry more about denial of service or information stealing.

One advantage of that, is that those decisions are at the root goals. The tree is a hierarchy; the higher level you are, the bigger impact you’ll have. Like spinning a big cog wheel versus a smaller one:

3 gears

If you were to pick on each vulnerability at the time, you’ll spin your working wheel a lot, while just really advancing the root goal a bit. Work on doing the selection on the root goals, then you’ll see that it’s impact is far greater for about the same amount of time. That’s efficiency to me.

And that’s how I turn magic into engineering 😀

Of course, in order for it to be proper engineering, the next step would be to QA it. And at that point, you can fetch all the checklists or threats repository you can find, and verify that you covered everything in your tree. Simply add what you have missed, and then bask in the glory of perceived completeness.

 

For the curious practitioners, I’ve used PlantUML in order to generate the tree examples as seen above. The tool let you textually define the tree using simple markup and auto balance it for you when you are updating it. A more detailed example can be found on my Threat Modeling Toolkit presentation.

a fresh look at a 3700-year-old clay tablet suggests that Babylonian mathematicians not only developed the first trig table, beating the Greeks to the punch by more than 1000 years, but that they also figured out an entirely new way to look at the subject. However, other experts on the clay tablet, known as Plimpton 322 (P322), say the new work is speculative at best. (“This ancient Babylonian tablet may contain the first evidence of trigonometry.”)

The paper, “Plimpton 322 is Babylonian exact sexagesimal trigonometry” is short and open access, and also contains this gem:

If this interpretation is correct, then P322 replaces Hipparchus’ ‘table of chords’ as the world’s oldest trigonometric table — but it is additionally unique because of its exact nature, which would make it the world’s only completely accurate trigonometric table. These insights expose an entirely new level of sophistication for OB mathematics.

Navigation