My Blogging

Blog regulars will notice that I haven’t been posting as much lately as I have in the past. There are two reasons. One, it feels harder to find things to write about. So often it’s the same stories over and over. I don’t like repeating myself. Two, I am busy writing a book. The title is still: Click Here to Kill Everybody: Peril and Promise in a Hyper-Connected World. The book is a year late, and as a very different table of contents than it had in 2016. I have been writing steadily since mid-August. The book is due to the publisher at the end of March 2018, and will be published in the beginning of September.

This is the current table of contents (subject to change, of course):

  • Introduction: Everything is Becoming a Computer
  • Part 1: The Trends
    • 1. Capitalism Continues to Drive the Internet
    • 2. Customer/User Control is Next
    • 3. Government Surveillance and Control is Also Increasing
    • 4. Cybercrime is More Profitable Than Ever
    • 5. Cyberwar is the New Normal
    • 6. Algorithms, Automation, and Autonomy Bring New Dangers
    • 7. What We Know About Computer Security
    • 8. Agile is Failing as a Security Paradigm
    • 9. Authentication and Identification are Getting Harder
    • 10. Risks are Becoming Catastrophic
  • Part 2: The Solutions
    • 11. We Need to Regulate the Internet of Things
    • 12. We Need to Defend Critical Infrastructure
    • 13. We Need to Prioritize Defense Over Offense
    • 14. We Need to Make Smarter Decisions About Connecting
    • 15. What’s Likely to Happen, and What We Can Do in Response
    • 16. Where Policy Can Go Wrong
  • Conclusion: Technology and Policy, Together

So that’s what’s been happening.

Tags: ,

Posted on October 13, 2017 at 2:13 PM • 72 Comments

Comments

Edward • October 13, 2017 2:49 PM

Bruce, hope this book isn’t a lot of affirming the obvious, e.g.:

  1. Cyber intrusions are increasing, getting worse
  2. Security is hard
  3. We need better rules

Hate to judge a book by its index but that list looks like a lot of things anyone with a passing interest in digital security would already know.

Mailman • October 13, 2017 3:04 PM

I wish you plenty of success with the book!

I love the irony of this:
You are posting less on the Internet, because you are writing a book about a hyper-connected world.

Bruce Schneier • October 13, 2017 3:31 PM

@Edward

“Hate to judge a book by its index but that list looks like a lot of things anyone with a passing interest in digital security would already know.”

It will be a lot of affirming the obvious, but I hope it won’t be entirely affirming the obvious.

I write for a general audience, and while “passing interest” is probably an overstatement, the book will contain a lot of things that anyone with a strong interest in digital security will already know.

Bruce Schneier • October 13, 2017 3:34 PM

@Alejandro:

“Ambitious project with tough questions. I hope you find the answers!”

Me, too.

Daniel • October 13, 2017 4:29 PM

“8. Agile is Failing as a Security Paradigm”

I’m very curious as to why you think this is so because I am one of those people who think that, at least for ordinary users, agility is the /only/ viable security paradigm. (In the past I have referred to this as “dodge” but I’ll accept agility since one must be agile to dodge.) As I see it agility might change which is to say that people may need to learn to doge right rather than doge left, so to speak, but I’m skeptical of the claim that agility can ever fail. Still, I respect you enough to be open to your thoughts on the topic…

Wael • October 13, 2017 4:46 PM

@Bruce Schneier,

Blog regulars will notice that I haven’t been posting as much lately as I have in the past.

Yes, noticed.

it feels harder to find things to write about. So often it’s the same stories over and over. I don’t like repeating myself

That too was understood! We won’t allow you to give up on us. We can post new stuff for ya! Hope you’re not preparing us for the end. I mean, it was like an alarm went off in my head, you know. I said, here’s a guy that’s got his act together. Here’s somebody who’s got it, all figured out. Here’s somebody who has the answer. we’ll follow you, Mr. Schneier. Don’t freakin do it, man!

I am busy writing a book. The title is still: Click Here to Kill Everybody: Peril and Promise in a Hyper-Connected World.

One, good luck. Sounds like an intriguing title. Ten, kinda of pessimistic view… So how does it feel to write and finish a book? Been thinking about doing that for years, but I never got to it… I know it’s rude to ask, but can I freakin’ retire on a good selling book? lol

Spellucci • October 13, 2017 4:55 PM

@Bruce and @Daniel,

I, too, am interested in 8. Agile is Failing as a Security Paradigm.

I have spent a lot of my career in the database world. Agile appears to be ideal for front end development work, but it is rather different to make an application code change than it is to make a database schema change. For example, the rollback of a failed schema change is non-trivial.

I have no experience in applying agile to security, but I imagine there are fundamentals in security design which are equivalent to database schema changes that one has to be deliberate about changing.

peacehead • October 13, 2017 4:59 PM

The book table of contents looks very impressive and agreeable in terms of meaningful content.
More importantly, I like how it will discuss ideas for solutions to mitigate or reduce or prevent the very valid concerns.

Thank goodness for those of the world who honor and believe in the Precautionary Principle.
Your materials appear to be the type of literature which will help those of us who prefer to live and flourish and interact and think and grow and learn and share without massive conflict, destruction, devastation, exploitation, and suffering.

Knowledge still has worth. Propaganda can’t defeat facts.
Thanks for being an educator as well as a lifelong learner.

Even when you accidentally drop into pure speculation on this forum, the type of speculations that you discuss with respectable sincerity are several levels above those who don’t even value intellectualism or who are too intellectually lazy to consider the limits of their personal field of educational vision.

I know it’s sometimes hard to substantiate claims and that accusations of those who bear fault is not proof of guilt or description of actual events and procedures and persons involved (Innocent Until Proven Guilty In A Court Of Law means something and always will!, allegations are not proof; Anti-Russian gossip, for example, is still gossip and not facts!)

The sciences are always important. It critical that scientific voices be heard in whatever published forms gets the ideas across. And yet also, all intellectuals have the responsibility (in my educated opinions, of course) to not devolve into logical fallacies and biases of the subcultures that make our lives more difficult than they need be.

Peace be with you, Mr S. and readers of this site.

Sincerely,

–“Anybody and Everybody, Peace Needs You Now; please don’t go AWOL.”

Jonathan Rosenne • October 13, 2017 6:06 PM

  1. We Need to Regulate the Internet of Things
    I hope we do a better job than with PCI, but I wont hold my breath.

Clive Robinson • October 13, 2017 6:33 PM

@ Bruce,

The “root of all evil” in the Internet is the lack of meaningful privacy. Contrary to what many think there realy is no anonymity on the Internet currently

Whilst there is PET around much of it fails brcause the base assumptions are wrong (in the same way the early Internet champions were wrong).

Whilst it is possible to build an anonymous network ontop of the current IP bassed Internet those that control the physical layers are going to fight long and hard to prevent not just anonymity but privacy as well. Because their fundementaly flawed business models demand the unmasking to monetize individuals at levels no previous dictators or tyrants would have dared dreamt be possible.

Such corporate “data rape” can not be stoped by National legislation, it needs the likes of the UN and the ITU to bring this about. Unfortunatly the ITU is realy a talking shop steared by “junior spooks R Us” trying to finesse the latest hole in a standard.

I can easily see the Internet fracturing into individual national networks and it’s primary utility will be lost. This nearly happened at the ITU meet[1] at Doha in 2014, and is very likely to happen again in the near future when the current SME theme is crushed out by the global-corp initiatives currently causing issues in the FCC and other national regulators.

[1] https://en.m.wikipedia.org/wiki/ITU_Telecom_World

Kubark • October 13, 2017 6:41 PM

The Editors need a punchier title.

Code Name: USEFULIDIOT
My Secret Life as a CIA Weasel

Now we’re talkin!

Ross Snider • October 13, 2017 7:11 PM

Wish list for policy:

  • Licensure for engineers. If you write buggy code, you can lose your license to sell software.
  • Licensure for managers and salespeople. If you misrepresent the quality of features of code, you can lose your license to sell software.
  • Licensure for businesses. If you engage in security anti-patterns or anti-competitive business practices, you can lose your license to sell software.
  • Licensure for auditors and auditing companies. If you misrepresent or misunderstand a product you are auditing, you can lose your license to audit.
  • Product labeling. Customer information about code and services from an unbiased source.
  • Better Business Bureau support.
  • No self-assessment from compliance regimes. Companies do not hire their own auditors. They are not able to set the scope of what they get audited for. They do not get to schedule their audits. They do not get to hire “checkmark” pentesters.
  • Liability for damages and a consumer protection agency.
  • An end to end-user-license-agreements.

do !Agile • October 13, 2017 7:16 PM

@Daniel

I can think of several issues that lead to Agile failing as a security paradigm.

I suspect that Bruce’s angle will be a rational one that addresses only the worst aspects of Agile. Those parts just incidentally happen to run rampant in the majority of Agile implementations. 😉

The problem, I believe, is that Agile is generally being adopted as a philosophical means of producing software output. Culture over standards and practices. This is nonsense.

The tradeoff between culture and standards is made during adoption and leads to poor engineering habits; ultimately undermining security in the process.

I firmly believe that it is possible to implement Agile to improve security, but cultural elements of Agile run against the grain of good security so naturally that it breeds bad security so easily…

Most implementations of Agile software development are actually just adoptions of select cultural elements that are mistaken for disciplines. Once the philosophy enters the development lifecycle it is in effect a fundamentally and catastrophically flawed process.

I’ve had the opportunity to see Agile implementations that essentially amount to a mantra like “Code iteratively, while making incremental changes, in evolutionary motion, while not forgetting to be adaptive and fail fast!” -or- “Continuous delivery or die!”.

The problem with adopting Agile as a cultural philosophy is that there is little to no standard, and no complete model, no discernible paradigm at onset. Process is what produces output, culture in place of process produces anomalies.

The bottomline is that Agile implementations in fail-fast software companies typically lack the details that ensure quality and security on output. No two implementations are alike, because Agile in itself subverts proactive design with reactive design, leading most implementers to believe that if their model is broken they can just fix it later. Try fitting good security into a culture that believes that failing at security before fixing it is the right thing to do.

This is not to say there are not successful Agile implementations out there that are successfully executed to produce software of high quality and security, but the majority are horrendous and security is worse off because of these.

Bob • October 13, 2017 8:34 PM

Agile has its place in the ongoing evolution on non-critical applications. I am working on an agile team doing just that right now. But since I come from a more3 rigorous world of DO178, IEC62304, IEC61508, etc. I sometimes get frustrated and forget that a failure in what I am now working on only means a business report might be a day late, and the tolerance for lateness is actually 3 days, so no big deal.

When my software is keeping a plane full of passengers in the air, I really appreciate the thoroughness of design and testing that goes into flight control software. The FDA and medical software is trying, but they haven’t really caught up to the aviation people yet.

But when my software is oredering inventory to put on the shelf of a retail store, its not nearly so critical, and adding enhancements to that soiftware is a good application of agile methods.

Security may or may not fall somewhere in the middle of this spectrum, depending on just what it is you are trying to secure. The problem, with security is how it suprises you with major ramifications for some little thiig you didn’t think about!

Anon • October 13, 2017 11:10 PM

The problem with Agile is it is largely reactive, not proactive. It’s too ad-hoc, and lacking depth of consideration. It also promotes less design and more ad-libbing when it comes to writing software, or putting systems together.

Systems are too complex IMHO, and require an engineering approach to help ensure things are done properly.

Agile says replace the battery; engineering asks what type and size. Subtle difference, but a significant one.

mostly harmful • October 13, 2017 11:37 PM

@Bruce Schneier

Thank you for keeping your living room here open for discussions.

As for your book in progress, this item is a compelling teaser: Customer/User Control is Next. Such dramatic ambiguity!

I look forward to reading your work. Good luck with it.

@Ross Snider

Looking at the licensure items on your wishlist, I wonder what measures might discourage wolves from stepping into their time-honored role as henhouse guards. Because those are some nice fat chickens.

tyr • October 14, 2017 12:11 AM

@Ross Snider

I would much rather see software folk forced
to take a remedial ethics class which explains
how framing an argument generates wrong answers.

Framing takes advantage of a masssive cognitive
hole in human behavior.

EX:
You are in a lifeboat with 11 people but the
boat only is capable of holding 10 safely.

Who do you throw overboard from the people in
the boat?

The correct answer is no one. You use your brains
to find a solution that is better than random
murder of a stranger.

The ethical trap is in the question and it starts
you on the path to a really bad solution set.

Some of what is dealt with in security is symptoms
but the underlying problems never get addressed
due to endless symptom chasing. You cannot fix
ethical problems with hardware and software all
you do is push the root cause further into the
darkness and human nature does the rest.

Wael • October 14, 2017 12:44 AM

What We Know About Computer Security

The shortest chapter of the book. What we don’t know would be a longer chapter.

Missing four chapters from part 2? I would be interested to see what you have to say about regulations, it’s been a common word in your vocabulary for the past few months. How would regulations help if we can’t enforce them on some entities?

Clive Robinson • October 14, 2017 1:26 AM

@ do !Agile, ALL,

Security is a “thoughtfull” process, like “safety” and “Quality”.

In the case of all three they start long before Day Zero of any project and they need the buy in from everybody from the very top to the very bottom of the organisation.

To get to a good level of “security” you first need a good level of “safety” and both require a very good level of “Quality”, otherwise it will just not work.

The big problem has been and will probably remain the requirment from sales, marketing and thus managment of “Quantity” over “Quality”.

You can not, except by unlikely chance, have “Quality”, “safety” and thus “security” when “Quantity” is the only real marker for success.

Unfortunatly sales and marketing assume, not necessarily incorrectly, that the customer wants quantity over quality, because they have been brought up that way. As most parents know children think they run on treats, not what they realy need. Adults however tend to know what they realy need balance and fiber. It’s time for the computer using communiry to “grow the heck up”, what users realy need are “stability”, “reliability” and “usability”.

There is a reason cars and landline phones all work in a similar if not identical way, it’s “what users expect, need and want”. Bells and whistles they rarely need. Think about “go faster stripes” and “white walled tyres” what they only feed is a limited subset of egos…

Clive Robinson • October 14, 2017 1:32 AM

@ Bruce,

Me, too.

Answers are easy, it’s the “right” answers that are hard…

In an industry notorious in it’s lack of real metrics, the scientific method does not realy work. Thus determining “right” is way way harder than it should be.

do !Agile • October 14, 2017 2:10 AM

@ Clive

Touché…You crack me up sir.

Most developers I work with follow Agile methodologies like a religion. To them it is the truth and the light. How do we shift their focus to thinking about the rubber and the radials before the tires meet the road?

@Bob

An excellent example of where seemingly benign software meets high impact threats is in IoT. Low barrier to entry, mass produced low cost devices outfitted with immature software running on general purpose OS. A few of these devices amount to a low impact threat, but collectively in hundreds of thousands or millions can become a critical impact threat.

Is this all a simple case of white walls before rubber?

Clive Robinson • October 14, 2017 2:37 AM

@ Wael,

The shortest chapter of the book.

From the vantage of my hospital bed, I reckon you could do it in a sentance or two 😉

    To be effective in use computers need to be connected to an external environment, usually in complex and overly broad and permissive ways. We know that computer security is about the control of information both into and out of a computer by both intended and unintended channels.
    Even with our knowledge of physics the majority of engineers do not understand the number of unintended channels there are or their interactions. Untill this situation changes computer security will not be possible except by strict issolation from the larger environment. As information is impressed on energy this requires computers that need to be secure to be energy issolated from the larger environment.

That do as a rough draft?

Cassandra • October 14, 2017 3:02 AM

@Clive

I hope your stay in hospital is a short as possible, and your recovery is fast and complete.

@Bruce

Re-stating the same thing over and over again has value when it comes from an expert. People who understand and accept a message only need to hear it once: your audience includes people who do not understand security, and people who don’t want to accept or believe the messages provided by security experts – such as the politicians who want backdoors without compromising encryption. Repetition is sometimes the only way to eventually get a message across. Please don’t give up.

Clive Robinson • October 14, 2017 3:15 AM

@ do !agile,

Most developers I work with follow Agile methodologies like a religion. To them it is the truth and the light.

The weasel word in there is “religion”… As it implies a belief in something that can neither be touched or quantified that is just simply better. Science does not work that way, nore does engineering, so why should “code cutting” get a pass?

Whilst beauty does act as a guide in both science and engineering, in that what looks unpleasent genearly is, it should be treated with caution when it comes to quality, safety and security. Safes for instance have “elegant simplicity” in their design but few would say thay have beauty.

The other problem with religion is “mantras” they are like “teaching by rote all it does is “fix the chant” in the head, not meaning, understanding or wisdom.

“And here endeth the lesson for today” 😉

Clive Robinson • October 14, 2017 4:57 AM

@ tyr,

I would much rather see software folk forced
to take a remedial ethics class…

When I wore the clothes of a younger man, all tangible engineering courses had not just “ethics” but “safety” built in I took the oath and still have “a ring of iron” though I don’t wear it these days due to size of finger issues.

Software is seen by way to many people as “intangible” almost ethereal and something “children should do” just like drawing. Thus neither safety or morals are “built in” to CS courses…

Sometimes I think that all CS graduates as part of their finals should program a robot arm to give them a shave with a cut throat razor for real whilst they sit their with a blindfold on. To get the point about software safety in to their heads.

If they get it wrong and their head comes off, it can be seen not as a loss to society but a net benift, as they will not be inflicting their unsafe attitudes on society down the line potentialy harming many many more people.

Clive Robinson • October 14, 2017 5:27 AM

@ tyr,

Below is the obligation at the ceremony of the engineer oath. It was formulatrd by Rudyard Kipling who had suffered great loss during the first world war. Hence it has a certain poignancy,


    I am an Engineer.

    In my profession I take deep pride. To it I owe solemn obligations.

    Since the Stone Age, Human Progress has been spurred by the Engineering Genius. Engineers have made usable Nature’s vast resources of Materials and Energy for Humanity’s Benefit.

    Engineers have vitalized and turned to practical use the Principles of Science and the Means of Technology. Were it not for this heritage of accumulated experiences, my efforts would be feeble.

    As an engineer, I, (supplicants name), pledge to practice Integrity and Fair Dealing, Tolerance, and Respect, and to uphold devotion to the standards and dignity of my profession, conscious always that my skill carries with it the obligation to serve humanity by making best use of the Earth’s precious wealth.

    As an engineer, I shall participate in none but honest enterprises. When needed, my skill and knowledge shall be given without reservation for the public good. In the performance of duty, and in fidelity to my profession, I shall give the utmost.

The last two paragraphs are what engineering morals should be about.

mr.robot • October 14, 2017 5:48 AM

I feel the problem is culture with too much management and not enough techy people, feels like people who can bs in an interview and sell themselves are getting the roles. (support side)

Sure I think there is still a lot of techy people working on the dev side of things but again management and sales have invaded this space and everybodys wants a “quick win” and a sprint to get the product out on the market with QA being handled not by devs but by support to manage expectations of the customers.

As well as the obsession with driving down costs, let’s hit the devs as hard as possible and outsource as much as possible.

Am taking a long break as I feel very disillusioned with this industry as incredible as the technology may be I feel we can achieve so much more i.e. really security maybe not perfect but far better than what we have now imo Encrypted email should be the norm not the exception.

For that to happen we need a massive culture shift i.e. pay for services and demand real change at government level but for that we will need to take to the streets 🙁

Some Guy • October 14, 2017 6:11 AM

–> As an engineer, I shall participate in none but honest enterprises. When needed, my skill and knowledge shall be given without reservation for the public good. In the performance of duty, and in fidelity to my profession, I shall give the utmost.

Whether an engineer, manager, or CEO, this is our ethical responsibility to society. In the real world, these values have been upstaged by
It’s all about me.

This attitude has taken us where we are now.

Clive Robinson • October 14, 2017 6:20 AM

@ Cassie,

I hope your stay in hospital is a short as possible, and your recovery is fast and complete.

Thank you for the kind thoughts.

Unfortunately the Dr.s as normal appear a little perplexed by the root cause of my problems. Thus they tend to treat me with the sort of caution Superman had with kryptonite 😉

So here I repose with the symptoms of a realy realy bad hangover (the merrygoround effect etc) and much numbness whilst my eyes have decided to take up an independent existence. When young this would have been viewed as the badge of a good night out. Sadly for me no Bacchanalian pleasures / revelry of a good night out or alcohol etc, just picking up a bottle of spring water in a “super market” and crashing down like a felled redwood tree in the snacks&water isle…

Then laying there amongst the dirt from a thousand shoes for an hour whilst waiting for an ambulance to cart me off to the durance vile of a hospital bed. Then just as I started feeling a little better an emergancy injection kicked in and I got sea sickness big style, apparently I went green, then grey, then a waxy translucence that morticians try to cover up to stop grieving relatives having nightmares.

What I do remember in the disembodied state of fuge was hearing a consultant talking loudly of shocking and ketamine. Not wanting to be like a race horse out the starting gate, I’m thankfull they decided to hit me with a large helping of deadly nightshade instead. The old folk ways are the best, as long as they leave out the Druid knives :-S

Any way the upshot is they think it might be my other meds causing probs, so a solution might be on the cards if they can find the right permutation which at around a little over 3.5million might take a while on blind trial…

But I have a little faith that there might be a faster way so who knows “I might be home for Christmass” 😉

Rudy • October 14, 2017 8:32 AM

@Clive Robinson: I hope you”ll recover soon and fast. Your comments here are always interesting, actually an important reason I visit this blog, besides what Bruce S. writes. Hopefully we can all enjoy your comments here for a long time to come.

Wael • October 14, 2017 8:32 AM

@Clive Robinson,

Any way the upshot is they think it might be my other meds causing probs

That’s good! All the best, sir!

“I might be home for Christmas” 😉

And that’s what you call fast? Well, with a British gourmet hospital food, you might get in shape and not get stuck in the chimney again 🙂

JonKnowsNothing • October 14, 2017 10:26 AM

@Clive Robinson
I would like to affirm comments from others about how important your insights are and sincerely wish that you recover ASAP.

When I read the comments section, there are 2 orders of scans: One for Bruce S comments, the other for comments from Clive Robinson.

There are many many fine contributors but your comments, observations and historical knowledge are greatly appreciated.

My biggest reactions are:

Gee I didn’t know that!

And now I do.

Much thanks and at least good technology lets you connect from the hospital!

JonKnowsNothing • October 14, 2017 10:39 AM

@Bruce

Re: New Book

MORE information for the general public is FANTASTIC!

While some of us discuss bits and bytes, the importance of pushing information to those who cannot is one of the most important roles of anyone familiar with technology.

Too often (mea culpa) we tell people: Just Do THIS.

It takes time and efforts to expain why. Generally, no one cares why, they just want to DO SOMETHING.

When people do ask me “why”, over time I’ve been forced into 2 pathways:

Do you want the nickel version or the long version?

Being able to explain something detailed and technical to the general audience is a talent.

Re: TOC

A. Regulations and Certifications do nothing without enforcement.

Certifications only restrict the number of players in the marketplace. The medical associations are legion for this, as are the entrance exams to major expensive universities.

If you restrict the flow, you create a shortage.

Shortages have advantages and disadvantages.

There is little technology that is actually required for life. People survived before and they will survive after – or at least until something globally disastrous happens.

There are lots of problems with certificates mostly because they are invented shortage producing systems.

Quality Enforcement in the USA has been done by the legal profession. To many this is an anathema. It’s a slope that is slippery and does not always end up well.

Today’s example:

Tesla fires hundreds of workers

https://arstechnica.com/cars/2017/10/tesla-fires-hundreds-of-workers/

What certificate enforcement is going to be useful here?

Do we want to claim if you get dumped this shows you are incompetent? Your skills are poor? You are somewhere, somehow, sometime a PITA and no longer employable? What would it mean to say I worked HERE if the company disavows your contributions?

You can fill in the blanks with every company that’s ever done a massive layoff. IBM, HP, etc.

Nearly every company dumps employees but this rarely means they are without qualifications or the ability to be a positive contributor in other situations.

It says everything about the company though and the people who remain. Consider: Google, Apple, M$, FB, IBM, HP. Consider all the companies that work in Mil-Spec Industries from screws and nuts to wiring to metal fabrication to software.

Certifications do nothing.

Regulations do nothing if there’s no enforcement.

In a global world we are struggling over Who Enforces What, Where, When, How and at What Penalty.

Just look at BREXIT to see the magnitude of the problems.

B. Technology Capitalism is Disaster Capitalism.

Technology creates its own disasters and then scavenges the results for another round of disasters.

The Shock Doctrine: The Rise of Disaster Capitalism is a 2007 book by the Canadian author and social activist Naomi Klein.
https://en.wikipedia.org/wiki/The_Shock_Doctrine

We can argue about bits and bytes but the fundamental issues are deeper.

When asking about security/privacy yesterday, today and tomorrow the answer will still be:

  • You do not need to worry about that. Someone else is doing it.
  • Nothing to see here, move along.
  • Get back in line.
  • Do your own project.
  • STOP talking about this.
  • YOUR FIRED!

I will look forward to the insights Bruce and everyone here bring on these topics.

CallMeLateForSupper • October 14, 2017 11:44 AM

@Bruce
“The book is due to the publisher at the end of March 2018, and will be published in the beginning of September.”

I look forward to this one in particular.

No pressure, mind you, but I wish you would simply “nerd a little harder” and get it out by December 2017. (nudge-nudge wink-wink)

Daniel • October 14, 2017 11:47 AM

There is confusion in the comments regarding Part 1, Chapter #8. Some people (like me) are reading “agile” as a broad-based concept in line with mitigation, avoidance, etc. Other people are taking @bruce to refer to a very specific concept known as “agile software development”.

https://en.wikipedia.org/wiki/Agile_software_development

I don’t know which is the right construction but if there is confusion in these comments then that is something @bruce will need to make sure to clarify in his book.

Anthony • October 14, 2017 11:55 AM

Bruce,

I’d respectfully encourage you to consider the insights of the Austrian School of Economics on public policy and regulation as it pertains to technology. We need regulation, but it has to be market-driven regulation, not legislatively-driven regulation. Legislators are the same people who say things like the laws of math can’t trump the laws of the country, and that they don’t need to understand technology to regulate it.

The reason we have incidents like the Equifax breach (as one of many, many examples) is because of a crony alliance between big business and government. These massive companies are given privileged positions by law to handle our data, and then they’re protected from financial liability when they misuse that data. Genuinely market-driven reforms would likely unleash the private watchdogs and provide for arbitrators to impose unlimited financial liability on corporations and their officers for egregious security incidents.

Here’s a few resources you may want to consult for your research on this topic:

  1. Murray Rothbard’s 1959 book Science, Technology, and Government, in which he predicted and explained the ultimate technological triumph of the United States over the Soviet Union’s central planning of technology.

  2. Peter Klein’s response to the thesis of Mariana Mazzucato.

  3. Klein’s 2016 lecture on government and big business delivered at Mises University.

do !Agile • October 14, 2017 12:25 PM

@Daniel

You raise a good point. I suspect that the answer is some mix of both broad based methodology and software development concepts.

When I refer to Agile I’ve done so with the pronoun variant that does first associate with software development concepts.

I would assume though that if we were only using the term in the sense of a broad based meaning, we would be discussing ‘agility’ and its effect on security.

I’m not sure that gets to the heart of why software is failing, which admittedly I may be prematurely concluding is the conversation Bruce is having.

I look forward to Bruce’s further insight, like yourself and other contributors.

MikeA • October 14, 2017 1:27 PM

Really commenting to wish Clive well and a speedy recovery, but while I am here:

“Agile”. I’ve generally seen it as a religious approach to justifying shooting from the hip, but I’m aware that saying that can unleash a wave of “No True Scotsman” replies.

Regulation v Market: Markets work with (reasonably) symmetric information. Regulations can help to encourage that, but are very often just cartels with guns. Not an easy tradeoff for plebs to make, or even influence. Some of the most horrific construction work I have seen was done by licensed contractors and signed off by government inspectors.

“Managers can manage anything” v “Engineers who know what they are doing”: I survived one startup where I should have known to beware when they advertised for Linux driver writers and required CVs to be Word(tm) documents. Then when I asked the verification folks what facilities for fault injection their simulation system had, and got blank stares. Some of that may have been naive mgmnt, but some was…

“Kids today” have a touching faith in stuff just happening to work. Correctness by Construction and Programming with Contracts might as well be obscure native rituals of a vanishing tribe. We’re all about “fix it later, with possibly a massive change in one of the 17 layers, not caring about breakage to other users of that layer. We can always fix that breakage later, right?”

tyr • October 15, 2017 12:53 AM

@Clive

Hoping you are out soon and in better shape.

I heard that Wozniak weighed in on AI, he said
the AI will be fine. I assumed that for the
rest of us things wouldn’t be that great.

Having been rolled around looking bad myself
I sympathize. Well wishings work.

Clive Robinson • October 15, 2017 5:09 AM

@ Mike A,

We can always fix that breakage later, right?

Ahh the “Peter Pan” school of CS, located in “Never Never Land”…

It goes right along with the “magic pixie dust” thinking we find getting more and more prevalent these days, not just in software, but software methodology thinking in logic design as well[1]… Apparently it’s “Market driven” but I suspect that there is a significant imbalace due to the fact the software industry market is not realy either open or fair, thus an actor has no choice to express an opinion let alone “vote with their wallet”.

[1] There are two basic logic design Hardware description languages (HDLs) VHDL and Verilog. The thing is hardware logic is all about data flows and time events, programing languages are mainly control flow and lack time events. Unfortunatly in the not so disyant past somebody added Object Oriented Programing (via C++) to HDLs. This was probably one of the biggest mistakes made as a “high level flow control” mentality is not realy suited to a low level data flow mentality. Thus you can design using an OOP HDL and get it to work in the simulator etc, but it will be a failure in one of several ways when commited to silicon and likely either mis function or have a shorter than expected life.

Clive Robinson • October 15, 2017 5:35 AM

@ All,

Thank you for your kind thoughts, hopefully they will get around to sorting out something soon. But it appears their may be lasting effects, to find out they are going to have a little play around inside. As Terry Pratchett put it “Straight to the heart via the groin”… Hopefully no “pump paranoia” will occur and I will be up and about spreading my usual humourous stories with just a hint of the “faintly rediculous”.

Speaking of which the bed I’m currently occuping is “defective” unbeknown to the hospital staff. Put simply the raising mechanism works but the holding break is defective, so you are just drifting off to sleep and if the head is raised the break slips and you get that “Good by California” feeling that is most disconcerting. As I pointed out to the nurse, it’s just as well I’m on a cardiac ward, as the darn thing nearly gave me a heart attack. It certainly set off the monitor alarms…

Get well soon • October 15, 2017 8:18 AM

Agreed with other posters Clive is one of the reasons I keep coming here, find him to be very insightful and knowledgeable in the field and able to cut through the shiz.

I feel like Bruce has to be very cautious in some of his statements to avoid inflaming political situations with the extreme being having to take a side.

But least the stories are being covered and this will remain one of my most visited sites.

Nick P • October 15, 2017 12:13 PM

@ Clive Robinson

Hope you get better, man! 🙂

@ Anthony

“We need regulation, but it has to be market-driven regulation, not legislatively-driven regulation. ”

“The reason we have incidents like the Equifax breach (as one of many, many examples) is because of a crony alliance between big business and government.”

You kind of contradict yourself there. In safety and security, the market-based approach with the companies in the lead has always led to non-sense designed to absolve them of liability in court by pretending to address the problem. There was usually a subset of actual safety/security improvements buried in there, too. They just mostly don’t care. So, it has to be forced on them with a financial gain and/or punishment attached to compliance.

We don’t have to speculate since it happened before in security under TCSEC and is still happening in safety under DO-178C. The quality of the systems improved a ton in both models. The first products strongly conforming to a security policy were released under the TCSEC. They did excellent in pentesting versus about anything in regular, software market. In both models, they’re required to achieve specific objectives to sell the product, a third party certifies (or rejects) their submission against those objectives, and the cost of certification failure makes them invest heavily in getting it right the first time. The high costs also make reusable components from vendors make more sense. There’s a whole ecosystem forming up in DO-178C of model-driven tools w/ code generation, static/dynamic analyzers, certified compilers, robust middleware, and so on.

So, it works. Just gotta do the regulations right which is tricky. The TCSEC was overly prescriptive on what features need to be included. DO-178C looks well-thought so far where it’s more about guaranteeing you had QA processes and certain bases covered. We could similarly mandate a few things for secure systems with mostly a focus on assurance activities and strong design/code/configuration review. A subset of TCSEC called Security Development Lifecycle developed by Steve Lipner at Microsoft also turned their QA around to make Windows have vastly lower number of 0-days. So, that’s one precedent for it. Methods such as Mill’s Cleanroom, Meyer’s Eiffel Method w/ SCOOP for safe concurrency, or Praxis’s Correct by Construction might also be encouraged.

Note: I’m in favor of multiple methods of handling this combining regulation, market forces (esp companies w/ exemplar products), and liability for incompetence handled by courts. I’m not for one-size-fits-all even though pro-regulation.

Clive Robinson • October 15, 2017 1:35 PM

Is it Agile or Scrum that’s dumb?

It’s no secret I’m not keen on various software “methodologies” as they appear to be there to provide lots and lots of “Wall Paper” to “paste over the cracks”, or as observed by some of SCRUM “for MBAs to put on powerpoints”.

In essence team dynamics are what make for success not the methodology. If you get a bully or two on a team that brow beat their method onto others the whole team becomes about as productive as a pile of sodden recycling.

Back in late 2014 Giles Bowkett wrot a humrous polemic called “Why Scrum Should Basically Just Die in a Fire”. Unfortunatly it’s not on his site any more, and a quick search failed to find if it had been moved elsewhere.

Jean-Paul • October 15, 2017 4:19 PM

Bruce, great book, good luck!

Will you consider the effect of complexity on security?

The “Black Swan” (Nicholas Talieb) effect?

I recall an old Scientific American article on the diminishing returns as software gets more complex. For example, virtually no chance for operation of the 100M line Star Wars system control SW.
Does this problem figure in your analysis ?

With Kind Regards, from Paris!

Your old friend !

Jon

ATN • October 16, 2017 4:09 AM

I wonder if there isn’t something missing in the table of contents, something about the economics of software these days.
Everything should be free, or at least no cash involved – doesn’t help designing or maintaining quality software.
Even the biggest of companies these days, when asked to select two of “quality, quick to market, cheap” select “cheap” and “cheaper”.
People sell their own security to be able to throw birds or see dancing cows.
I am not even sure that is an education problem, a lot of people know what they are doing when they use “free and closed-source” software.
And a lot of developpers gave up developping/maintainning open-source software just because licenses are not enforceable, even massive companies consider GPLv3 as completely free for use, and some country law system priced their intellectual properties laws completely out of reach of developpers / small companies.

PP • October 16, 2017 10:05 AM

i have to go “Beyond Fear” to be able to add a reminder for this title on my calendar in September 2018.

RSaunders • October 16, 2017 10:26 AM

It looks like a great outline, but there’s more going on in 1.6 and 1.8 than their titles convey (surely that’s why you need a book rather than just an outline!). Though it doesn’t match the pattern, “Reuse” is the prime culprit in 1.6. If diversity is seen as a security mechanism, it’s not economically motivated in a world of reuse like OpenSSH. You can buy routers from diverse companies with diverse supply chains and still get a common vulnerability.

Reuse is also why Agile is a problem. Agile puts value on reuse, and making small tweaks, to keep from “breaking the build”. It artificially makes security an all-or-nothing construct, which can only lead to more “nothing” security.

Anon • October 16, 2017 9:40 PM

@do !Agile:

Most developers I work with follow Agile methodologies like a religion. To them it is the truth and the light. How do we shift their focus to thinking about the rubber and the radials before the tires meet the road?

Tell them in no uncertain terms that Agile programming is no different to a school kid just writing code; no understanding, just punching keys until it works. It’s crap.

Unfortunately attacking their intelligence and making it personal is probably the only way, unless you can find some better method. Unfortunately there are as many ways to write software as stars in the sky.

An analogy I use is building structures: any idiot can put steel girders together, but it takes a structural engineer to ensure it won’t collapse. The end structure looks the same, but is different in how it was designed and constructed.

tl;dr: You can’t see the difference, but it most certainly is present.

@mr.robot:

It’s like many areas of life – quantity over quality. At some point, the quality becomes so bad, things start to fail. We are actually starting to see this in major engineering.

The idea of “planned obsolescence” has filtered into general engineering, and now things are built within microns of being too thin or within 1% of ultimate load limits in normal operation, and are breaking unexpectedly.

We need to get back to over-engineering things slightly, so they last forever. We have optimized things too far.

Software is no different. Just because it is intangible, doesn’t make it any less important to do it properly.

Christopher • October 17, 2017 7:37 AM

@agile, @scrum, @snakeoil… the first and last methodology I ever learned or needed was structured analysis. Rest in peace, Ed Yourdon.

Vincent L Gambino • October 17, 2017 8:44 AM

@Anthony – re Austrian School, etc. – I second that motion, but I don’t expect it to carry.
@Many Others – I’m getting in line with everyone else in wishing for Clive to fully recover, for both his sake and ours…

Vincent L Gambino • October 17, 2017 8:50 AM

@Christopher – I’d add Knuth to Yourdon. Hell, I still have the D&T “Managing the Systems Development Process” manual on my shelf. Although it’s been many years since I had an opportunity to use it, I’d wager it’s still more relevant to producing quality code than most of what passes as design guidance today.

PP • October 17, 2017 10:02 AM

“We are clearly giving new meaning to words”.

This is the current book contents (subject to change, of course):
vs
This is the current table of contents (subject to change, of course):

Just in case a rap battle turns into a rhapsody.

Tordr • October 18, 2017 5:22 AM

Bruce, in part 2 you talk about the solutions which start of with regulating and defense. I think we need to go deeper, we need to have a good understanding of trust and power.

In IT-security we often frame the world and risk analysis in an attacker-based or asset-based view. But an attacker based risk analysis often needs an the image of an attacker that is going to attack the system, but where is the attacker when we ar willingly entering facebook to view a newsfeed from our friends. Is it not better to say that we trust the algorithms in facebook to give us “unbiased” (unbiased based our world view). That trust can be broken by facebook selectively changing this view based on its goals to modify our mood. Facebook also have the power to mediate all exchange of information on it’s platform, so it should never be seen as neutral, although it always tries to paint itself as neutral. (Ref: the Norwegian newspaper which asked on its frontpage for facebook to take its editorial responsibility seriously and to put in place an responsible editor).

An asset-based view on the other hand suffers from the problem of securing one central repository, but misses the fact that this system might accept blindly messages from other trusted system (such as a web-servers). So asset based security misses the fact that an attacker can escalate its attack.

Trust and power on the other hand brings other perspectives into consideration. To what extent do you trust an application on phone. Is your view of trust the same as the android/iphone developers view on trust? What power to shape your views does facebook have when your on its platform? Do the government/private individuals trust self driving cars when the car manufactures will quickly lay the blame for any accident on the driver.
Power also comes into play when we have the “blame the user” defense from IT-security whenever a user has a virus, but as we know from zero-day attacks that a user can in many cases be powerless from preventing such attacks. Also we know/suspect that malware attacks has been served from otherwise reputable sources so where should a user go without risking an attack?

John Carter • October 18, 2017 7:41 PM

As someone who builds connected things for a living….

….it becomes painfully clear that “Over The Air Upgrades” are an inevitable security pre-requisite of the current software ecosystem.

This adds risks of defects, eats bandwidth, adds a vast and particular tasty attack surface and creates a storm complexity.

Well, it’s that or a disposable world.

ie. Your screen cracking or battery wearing out are (designed to be) events of the same order as your firmware being cracked.

ie. When your firmware detects it’s been cracked (either via intrusion detection or OTA announcement) you throw it away and by the new model.

PS: For a view from the frontline… Please read…

https://daniel.haxx.se/blog/category/tech/security/

…he speaks from the position of having written and maintained a critical piece of IoT infrastructure with an installed base of 3 billion instances.

Reader • October 19, 2017 10:05 AM

If you see an industry that’s headed in a very dumb direction, what is the way to turn them around? Assume in your answer that their comms have a megaphone and yours have a silencer.

K-Veikko • October 25, 2017 2:43 AM

Once comes the day when you ask yourself for the meaning of the life. – If am not needeed anywhere. If I am not obliged to do anything or achieve anything. What would I do?

Do I leave the world after me in better shape than it was when receiving?

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.