There will be another International Workshop on Secure Software Engineering in DevOps and Agile Development (SecSE) this year. The upcoming edition is going to take place in Dublin in conjunction with the Cyber Security 2020 conference (June 15-17 2020). Please submit your papers until 6 February 2020 – three weeks to go! – and spead the word.
Blockchain is not a technology, it is a meme. The legend of a magical technology about to disrupt everything – e-very-thing! – emerged from an ecosystem of investment fraud, where it was originally used to sell worthless coins and tokens to the gullible. The blockchain legend did not have to make sense to fulfill this purpose, quite to the contrary.
Due to media fascination with the speculative bubble formed by Bitcoin and other crypto-“currencies”, the blockchain legend spilled over into the real business world. It had everything it needed to spread: great promises instilling fear of missing out, explanations one could replicate by memorizing rather than understanding, and holes in just the right places that everyone could fill with their personal visions.
Application proposals, unsurprisingly, revolved around what people experienced in their everyday lives, such as tracking bananas from the farm to the supermarket or making payments. The blockchain legend would have worked just as well with any other alleged use case, as it did not promise any specific advantages compared to actual technology.
As a meme, the blockchain legend can spread only among those who want to believe, or at least accept the proposition that blockchain were a technology. The moment one understands the true nature of blockchain as a redundantly-decentrally spread meme one stops spreading the meme.
Two years have passed since peak blockchain. Fewer and fewer people continue to propagate the meme. I can see the light at the end of the tunnel.
This clip from 1983 allows us a glimpse into the history of computer crime. Much of what is being said still sounds familar today, doesn’t it?
Should anybody offer this bicycle for sale, please let me know. It is a 2018 model Bergamont Grandurance RD 5.0, frame size 61cm, frame number AB71241941. Condition mostly as sold, but with an added rear-view mirror at the left bar end, to bottle cages, and upgraded lights (head: Lumotec IQ-X, rear: Secula).
Falls Ihnen jemand dieses Fahrrad anbietet, sagen Sie mir bitte Bescheid. Es handelt sich um ein Bergamont Grandurance RD 5.0, Modell 2018, Rahmenhöhe 61cm, Rahmennummer AB71241941. Zustand fast wie gekauft, aber zusätzlich mit einem Rückspiegel am linken Lenkerende, zwei Flaschenhaltern und besserer Beleuchtung (vorne: Lumotec IQ-X, hinten: Secula).
In this talk, Nickolas Means tells the story of United Airlines Flight 232, which on July 19, 1989 crash-landed in Sioux City after suffering a mid-air engine explosion and consequent loss of hydraulics. Although the crash killed more than a third of the passengers and crew, the fact that the aircraft made it to the airport at all and more than half of the occupants survived is widely attributed to extremely good airmanship and collaboration in the cockpit. Airlines teach their pilots how to work and cooperate effectively under stress and United 232 continues to be cited as a success story for this type of training.
George Neville-Neil’s keynote at AsiaBSDCon 2019:
Before you criticize an algorithm you should walk a mile in its shoes. Sure, it is funny to see images of fried chicken or of a cat misclassified as “dog” pictures. However, you are not as much smarter than algorithms as you may think. Sit down and try the thumb finger switch:
This is a really simple control task, isn’t it? A child could do that! Why can’t you?
Some in the security community think of the Maginot Line as a failure in defense as German troops went around it. This kind of arrogance is, unfortunetely, all too common, especially among security bullies. The following video argues that the Maginot line was a success, because it forced the German troops to go around it:
Just a brief reminder: February 6th, 2019 will be the submission deadline for the next edition of the International Workshop on Secure Software Engineering in DevOps and Agile Development. See the previous announcement for more detail.
The 10th edition of the International Workshop on Secure Software Engineering in DevOps and Agile Development will take place in conjunction with the Cyber Security 2019 conference on June 3-4 2019 in Oxford, UK. The call for papers is already online and plenty of time is left to prepare a paper before the submission deadline in early February. Besides scientific paper submissions the workshop seeks short ignite talks and also industry experience talks.
February 6th, 2019 – Submission Deadline
March 26th, 2019 – Author Notification
April 14th, 2019 – Author Registration/camera-ready
June 3-4th, 2019 – Workshop
Slavoj Žižek does not care about surveillance:
A spectre is haunting the Internet – the spectre of blockchain. Some claim it to be a disruptive technology, others think it is bullshit. In favor of the bullshit point of view the blockchain narrative lacks convincing use cases and looks like a solution in search of problems. On the other hand, a number of reputable companies seem to believe that this blockchain thing does somehow matter. Are we witnessing a mass delusion or is there more to it?
In a recent post, Peak Blockchain, I argued that that blockchain craze has a lot in common with the way Second Life, an online 3D toy world, was being hyped and then forgotten a little more than a decade ago. Perhaps there is more to this analogy than just the way attention rises and then drops in both cases, blockchain and Second Life. A real but boring trend may lure behind the exciting (at least to some) surface and its catchy name.
Second Life reached its peak of attention during the first half of 2007. Conceptually it never made sense: Except for certain types of computer games and some special-purpose applications, 3D worlds rarely make for usable user interfaces. Just imagine having to browse the shelves of a virtual 3D library instead of just googling or having to use an on-screen replica of a good old typewriter to write a letter instead of using a word processor – a user interface should support relevant task rather than needlessly replicate constraints of the physical world.
Despite the obvious flaws of Second Life as a tool and platform for anything, many well-known companies fell for the hype and built experimental presences in this virtual world. At least one of them, IBM, went even further and attempted to turn Second Life into a collaboration support business. Was everyone crazy?
Not entirely. The 3D toy environment of Second Life was merely the bullshit version of a real trend. Around 2007 the web had evolved from a distributed hypertext system into an interactive application platform (“Web 2.0”). Blogs had appeared on the scene (e.g., WordPress – 2003, wordpress.com – 2005). Cloud computing was on the rise, although nobody called it so yet (e.g., Google Docs/Sheets/Slides – 2006, Dropbox – 2007). Social networks and media were evolving (Myspace – 2003, Facebook – 2004, Twitter – 2006). While Second Life itself did not make much sense, it symbolized in its over-the-top manner what was going on as a proxy instance and gave it a name.
Looking at the recent blockchain mania from this angle, today’s trend-behind-the-craze might be the automated interaction of networked artifacts in emergent systems of systems. The evolution of the Internet has not stopped after turning all our computers, tablets, phones, and watches into cloudtop devices, user interfaces to (collections of) services that reside on the network.
Today we are moving toward an Internet of Things (IoT) where thing means anything that is a computer without looking like one. Networked computers come in a variety of shapes today. At home we find entertainment devices streaming audio and video into our living rooms, voice assistants that let us talk to the Internet, and home automation letting us control anything from lights to heating through our smartphones. Then there are connected and increasingly, autonomous cars as well as charging infrastructure for electric vehicles. Manufacturing equipment from machines and robots to entire factories continues to be automated and networked, as does agriculture.
Technically these cyber-physical systems are networked computers as we know them. However, they consist of increasingly autonomous entities forming emergent systems of (semi-)autonomous systems. On the one hand, autonomy is the key feature in cases like autonomous driving or autonomous robots. On the other hand, many IoT devices lack traditional user interfaces and their ability to interact with users in other ways than over the Internet remains rather limited.
As a consequence, IoT devices need the capability to interact with cloud services and with each other without requiring human intervention and perhaps also to make transactions autonomously. For example, one blockchain application that has been mentioned is charging of autonomous electric cars – a car buying electricity from a charger. This interaction must be secure, whatever this may mean in the particular case, and there is no such thing as a PGP key signing party for IoT devices.
Blockchains and cryptocurrencies are unlikely to solve any of the pertinent problems, but the problems are real: transactions between devices, managing access to continuously produced machine data, keeping manufacturing instructions under control while getting them where they are being needed, and so on. I suspect this is the grain of truth in blockchain mania. At some point everyone will drop the burnt term but continue to work on the actual problems and actual solutions.
This is Peak Blockchain. You can watch it in the rear-view mirror as it lies behind us, shrinking smaller and smaller until it will disappear on the horizon. I am using Google Trends as my rear-view mirror, which allows some easy and superficial yet striking visual argument.
Peak Blockchain took place in December, 2017. Up to that time, starting ca. 2013, search interest grew seemingly exponentially, whereas interest has almost halved in the three months from Christmas, 2017 to Easter, 2018.
Peak Blockchain is the all-time high of attention and perceived importance of the blockchain topic. Some confound Peak Blockchain with the Peak of Inflated Expectations in Gartner’s Hype Cycle, which is followed by the Through of Disillusionment, a Slope of Enlightenment, and eventually the Plateau of Productivity. But make no mistake. Neither is the Hype Cycle a law of nature – some technologies just drop off the graph and die, while others are never discovered by the hypecyclists before they become productive – nor is blockchain a real and viable technology trend.
Inflated expectations or rather, exaggerated claims were there many, this much is true in the hype cycle mapping. The blockchain narrative emerged out of the cryptocurrency bubble. When the likes of Bitcoin, Ethereum, and IOTA reached the mainstream, it became simultaneously obvious they had little to do with actual currencies and the nominal value of their tokens was not backed by any economic reality other than that of a speculative bubble.
Everyone saw that so-called cryptocurrencies were bullshit and the speculative bubble was about to burst, yet everyone also wanted to talk about it without looking like an idiot. Out of this dilemma was the narrative born that the first and most notorious of the artificial assets, Bitcoin, might collapse but the technology behind it, blockchain, was there to stay. Not only would the “blockchain technology” thus invented – it had been a mere design pattern until then – survive, it would disrupt everything from the financial industry and digital advertising to crybersecurity (sic!) and photography. For none of this claimed disruptive potential existed the slightest example or explanation, but everyone was keen to ride the mounting wave without being seen as just one of those Bitcoin dorks, and so everyone kept inventing what might happen, somehow, in the future.
Blockchain is only one of several related concepts – others being Bitcoin and cryptocurrencies – that peaked at about the same time:
In all cases we see the same steep rise followed by an equally steep decline. This observation alone should suffice to convince everyone that nothing is to be expected from blockchains, regardless of what the IBMs and SAPs of this world are claiming after having fallen for the ploy. We saw peaks like this before. Little more than a decade ago, Second Life was the blockchain of its time:
At that time everyone, including a number of otherwise reputable companies, rushed to stake their claims in the virtual toy world that Second Life really was and is. The gullible and superstitious believed that companies would benefit from possessing real estate in this toy world and that 3D avatars sitting around virtual tables would be the future of business meetings. This was bullshit not only in hindsight. Everyone with the slightest understanding of human-computer interaction and collaborative technology could easily see how Second Life missed just about any point. This did not prevent IBM from betting a few bucks on the future of Second Life and even trying to create an enterprise version of it where company secrets would stay behind a firewall.
Second Life is long forgotten, and rightly so. There never was any real promise in it, there was only a popular (in certain circles) delusion and the fear of missing out that also drives our contemporary bullshit business fad.
Let us look at real technology trends for comparison. They do not peak and then collapse, but rather grow organically. Take cloud computing, for example:
We see no steep peak here, but rather a mostly linear growth over the course of four years from 2007 to 2011. After climbing to its all-time high, interest decreases slowly and remains at a high level for a long time. Other than Second Life, cloud computing is here to stay.
Another real trend is REST APIs, a way of designing web services that are meant to be accessed by programs rather than users:
We see a mostly steady increase over more than a decade that at some point gained a bit of speed. Again, there is no sudden peak here. As a third example, NoSQL databases started a bit later but otherwise exhibit a similar trend graph:
Even topics that had some hype to them and were being discussed by the general public exhibit slower increases and declines if there is substance behind the hype. Take, for example, “big data” and some related terms:
Real technology trends and topics take time to develop and then they persist or even continue to grow for quite a while. A real technology trend is an evolutionary process. Something gets discovered or invented and turns out useful. People apply the idea and develop it further, which makes it more attractive.
Genuine technology does not suddenly appear like a Marian apparition and disrupt everything within months, nor does interest in it fade as quickly as it would for anything lacking substance after its hollowness became obvious even to its advocates. Peak Blockchain is not the result of a genuine technology trend, but rather the consequence of everyone in a crowd assuring one other of the beauty of the emperor’s clothes when in fact there never even was an empire.
Blockchain is over. Time to ridicule those who jumped on the bandwagon ignoring all obvious warning signs, determined to boost their careers. They will soon exercise their right to be forgotten.
There was a time when personal computers came with security built into their hardware. For about a decade from 1984 on, virtually every PC featured a key lock. Depending on the particular implementation, locking would prevent powering on the computer, keyboard input, hard drive access, opening the case, or a combination thereof. This video tells the story:
From today’s perspective the key lock looks like a weak if not pointless security mechanism. In the best case it makes tampering with the hardware slightly harder—attackers have to equip themselves with tools and spend some time using them—while not at all addressing all the software vulnerabilities that we care about so much today.
Nevertheless the design made a lot of sense.
First, a keylock is a usable security mechanism. Everyone is familiar with key locks and knows how to use them, no complicated setup is required, and there is little potential for mistakes.
Second, an attacker’s physical access to hardware internals defeats most software security mechanisms. Physical access control is therefore a prerequisite for security against certain threats.
Third, personal computers at that time were not really threatened by online or software attacks, perhaps with the exception of relatively harmless viruses spreading through exchanged floppy disks. Someone tampering with the computer was indeed one of the more realistic threats.
Fourth, seemingly minor security gains can be rather effective when put in context. While forcing attackers to carry tools and use them may not seem like a great complication for them, it may suffice to prevent opportunistic attacks as well as quick serial attacks against multiple consecutive targets.
Security technology has evolved to make key locks obsolete, but they made sense at the time of their introduction.
TL;DR: The author thinks Snowden’s home security app, Haven, is snake oil regardless of the algorithms it uses. Operational security is at least as hard as cryptography and no app is going to provide it for you.
Bogus cryptography is often being referred to as snake oil—a remedy designed by charlatans to the sole end of selling it to the gullible. Discussions of snake oil traditionally focused on cryptography as such and technical aspects like the choice of algorithms, the competence of their designers and implementers, or the degree of scrutiny a design and its implementation received. As a rule of thumb, a set of algorithms and protocols is widely accepted as probably secure according to current public knowledge, and any poorly motivated deviation from this mainstream raises eyebrows.
However, reasonable choices of encryption algorithms and crypto protocols alone does not guarantee security. The overall application in which they serve as building blocks needs to make sense as well in the light of the threat models this application purports to address. Snake oil is easy to mask at this level. While most low-level snake oil can be spotted by a few simple patterns, the application layer calls for a discussion of security requirements.
Enter Haven, the personal security app released by Freedom of the Press Foundation and Guardian Project and associated in public relations with Edward Snowden. Haven turns a smartphone into a remote sensor that alerts its user over confidential channels about activity in its surroundings. The intended use case is apparently to put the app on a cheap phone and leave this phone wherever one feels surveillance is need; the user’s primary phone will then receive alerts and recordings of sensed activity.
Haven is being touted as “a way to protect their [its users] personal spaces and possessions without compromising their own privacy.” The app allegedly protects its users against “the secret police making people disappear” and against evil maid attacks targeting their devices in their absence. To this end, Haven surveils its surroundings through the smartphone’s sensors for noise, movement, etc. When it detects any activity, the app records information such as photos through the built-in camera and transmits this information confidentially over channels like the Signal messenger and Tor.
Alas, these functions together create a mere securitoy that remains rather ineffective in real applications. The threat model is about the most challenging one can think of short of an alien invasion. A secret police that can make people disappear and get away with it is close to almighty. They will not go through court proceedings to decide who to attack and they will surely not be afraid of journalists reporting on them. Where a secret police makes people disappear there will be no public forum for anyone to report on their atrocities. Just imagine using Haven in North Korea—what would you hope to do, inside the country, after obtaining photos of their secret police?
Besides strongly discouraging your dissemination of any recordings, a secret police can also evade detection through Haven. They might, for example, jam wireless signals before entering your home or hotel room so that your phone has no chance of transmitting messages to you until they have dealt with it. Or they might simply construct a plausible pretense, such as a fire alarm going off and agents-dressed-as-firefighters checking the place. Even if they fail to convince you, you will not be able to react in any meaningful way to the alerts you receive. Even if you were close enough to do anything at all, you would not physically attack agents of a secret police that makes people disappear, would you?
What Haven is trying to sell is the illusion of control where the power differential is clearly in favor of the opponent. Haven sells this illusion to well pampered westerners and exploits their lack of experience with repression. To fall for Haven you have to believe the premise that repression means a secret police in an otherwise unchanged setting. This premise is false: A secret police making people disappear exists inevitably in a context that limits your access to institutions like courts or media or the amount of support you can expect from them. Secret communication as supported by Haven does not even try to address this problem.
While almost everyone understands the problems with low-level snake oil and how to detect and avoid it, securitoys and application layer snake oil continue to fool (some) journalists and activists. Here are a few warning signs:
- Security is the only or primary function of a new product or service. Nothing interesting remains if you remove it.
- The product or service is being advertised as a tool to evade repression by states.
- The threat model and the security goals are not clearly defined and there is no sound argument relating the threat model, security goals, and security design.
- Confidentiality or privacy are being over-emphasized and encryption is the core security function. Advertising includes references to “secure” services like Tor or Signal.
- The product or service purports to solve problems of operational security with technology.
When somebody shows you a security tool or approach, take the time to ponder how contact with the enemy would end.
Software penetration testing has become a common practice in software companies. Penetration testers apply exploratory testing techniques to find vulnerabilities, giving developers feedback on the results of their security efforts—or lack thereof. This immediate benefit is mostly uncontested, although it comes with the caveat that testers find only a fraction of the present vulnerabilities and their work is rather costly.
Security experts commonly recommend that developers should respond to the results of a penetration test not merely by fixing the specific reported vulnerabilities, but rather analyze and mitigate the root causes of these vulnerabilities. Just as commonly, security experts bemoan that this does not seem to happen in practice. Is this true and what prevents penetration testing from having an impact beyond defect fixing?
Studying Software Developers
We studied this question by observing a product group of a software company over the course of a year. The company had hired security consultants to test one of its products for security defects and subsequently train the developers of this product. We wanted to know how effective this intervention was as a trigger for change in development. To this end we conducted two questionnaires, observed the training workshop, analyzed the contents of the group’s wiki and issue tracker, and interviewed developers and their managers.
The product group in our study comprised several Scrum teams, development managers, and product management. Scrum is a management framework for agile software development. Scrum defines three roles—Development Team, Product Owner, and Scrum Master—and artifacts and ceremonies for their collaboration. The Development Team is responsible for and has authority over technical matters and development work; the Product Owner is responsible for requirements and priorities; and the Scrum Master facilitates and moderates their collaboration.
The participants of our study appreciated the penetration test results as feedback and the training workshop as an opportunity to learn. They managed to address the particular vulnerabilities reported by the consultants. They also felt that security needed more attention in their development work. Yet, after addressing the vulnerabilities uncovered by the penetration test, they returned to their familiar ways of working without lasting change.
Analyzing our observations through the lens of organizational routines, we found three key factors inhibiting change in response to the penetration test and training: successful application of existing routines, the organizational structure of roles and responsibilities, and the overall security posture and attitude of the company.
(1) Existing Routines
To address the immediate findings of the penetration test, our developers used an existing bug-fixing and stabilization routine. Defect reports arrive asynchronously and sometimes require quick response; developers therefore commonly dedicate some—variable—percentage of their working time to defect fixing in response to reports. The penetration test fed the team dozens of new defects at once, but developers hat a routine to deal with it. Moreover, management tracked the number of open defects, so that the sudden increase raised attention and created pressure on the team to get this number down.
Feature development, on the other hand—where change would have to occur—remained mostly unaffected. Feature development followed the process of Scrum and the penetration test neither had a specific impact here nor did it feed requests or ideas into this routine.
(2) Organizational Structure
Following the ideas of Scrum and agile development, a strong division of labor and responsibilities characterized the organizational structure in the setting of our study. Product management and product owners were responsible for the direction of the development work, whereas development teams enjoyed a certain autonomy in technical questions. This structure worked as a social contract: managers expected developers to take care of security as a matter of quality and developers were keen to deliver the features requested by management. However, the penetration test had little impact on the manager’s priorities beyond the pressure to reduce the number of open defects. The developers thus found themselves in a situation where security was not explicitly required and additional security work could not be justified.
(3) Business Role of Security
Finally, security had limited perceived importance for the business of the studied company, which thus far had not experienced any public security disaster and did not actively sell security. The company therefore lacked a security narrative that could have been used to justify security efforts beyond defect fixing. This, together with the inherent low visibility of security and insecurity, shaped priorities. Product managers knew that features sell their products—new features are easy to show and explain, whereas security improvements are not. Security was perceived as contributing little to the success of the product and the company, making it a low-priority requirement.
Our study points to some of the complexities of managing software development and of triggering change by interventions. While it would be tempting to assign blame to a single factors, such as agile development or negligent management, the problem is really more complicated. Organizational structures and routines exist and they are shaped by business needs. Scrum, for example, is highly beneficial for the studied company. One might even ask whether the company’s dealing with security is a problem in the first place. Are they perhaps doing the right thing for their market and customers?
A. Poller, L. Kocksch, S. Türpe, F. A. Epp; K. Kinder-Kurlanda: Can Security Become a Routine? A Study of Organizational Change in an Agile Software Development Group. Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing (CSCW’17), February 25–March 1, 2017, Portland, OR, USA.