Don’t patch it, it’s fine?

I wrote back in 2013 about my shock at discovering that the companies are now publicly calling to stop the investment in security and avoid fixing security bugs in my article Brainwashing in security. There, we witnessed the head of Adobe security, Brad Arkin, tell us that the companies should not be wasting their precious resources on “fixing every little bug”, agreeing to the comment made by another participant, John Viega from SilverSky, that:

“For most companies it’s going to be far cheaper and serve their customers a lot better if they don’t do anything [about security bugs] until something happens.”

All right, fast forward three years and Adobe becomes a showcase. Here is what Google senior security engineer Darren Bilby, speaking at the Kiwicon, has to tell us about the security of the contemporary software:

“We are giving people systems that are not safe for the internet and we are blaming the user,” Bilby says.

He illustrated his point by referring to the 314 remote code execution holes disclosed in Adobe Flash last year alone, saying the strategy to patch those holes is like a car yard which sells vehicles that catch on fire every other week.

The security strategy at Adobe is clearly paying its dividends. Way to go, Adobe, way to go…


Data breach at LinkedIn

linkedin-default-shareApparently, there was a serious data breach at LinkedIn and many customer records were stolen including “member email addresses, hashed passwords, and LinkedIn member IDs”. LinkedIn sent out a notification informing that the passwords were invalidated. What is interesting in the note is that they included a cryptic note that the break-in was “not new”. What could they mean by that?

On May 17, 2016, we became aware that data stolen from LinkedIn in 2012 was being made available online. This was not a new security breach or hack. We took immediate steps to invalidate the passwords of all LinkedIn accounts that we believed might be at risk. These were accounts created prior to the 2012 breach that had not reset their passwords since that breach.

I can take a wild guess that they passwords prior to 2012 were stored either unencrypted, without salt, or using some very weak algorithm. The security breach itself was, of  course, “new” but the only information at risk are those passwords in the database that were stored in this old-fashioned way.

So, according to my wild guess, there must be more information stolen than they tell us but LinkedIn judged that the only information that threatens themselves were those old passwords so they finally invalidated them (what they should have done back in 2012) and told us they are happy with it.Unfortunately, there is no way to know for sure.

You can make your own wild guess at what happened.

Position yourself on Security Maturity Grid

I wrote up the Security Maturity Grid the way quality management is usually presented. The grid is a simple 5 x 6 matrix that shows different stages of maturity of the company’s security management against six different security management categories (management understanding of security, problem handling, cost of security, etc). The lowest stage of maturity is called ‘Uncertainty’ – the organisation is inexperienced, security management is a low priority and reactive, etc – then as security management matures it goes through the stages of ‘Awakening’, ‘Enlightenment’, ‘Wisdom’, then the highest level, ‘Certainty’. Each point – maturity versus category – on the grid has a brief description of how that combination appears in the company.

I keep the grid on a separate page, Security Maturity Grid, so have a look and try to position yourself or your company on the grid. Then wait for the software security goons to show up :)


Worst languages for software security

I was sent an article about program languages that generate most security bugs in software today. The article seemed to refer to a report by Veracode, a company I know well, to discuss what software security problems are out there in applications written in different languages. That is an excellent question and a very interesting subject for a discussion. Except that the article really failed to discuss anything, making instead misleading and incoherent statements about both old-school lnguages like C/C++ and the PHP scripting. I fear we will have to look into this problem ourselves then instead.

So, what languages are the worst when it comes to software security? Are they the old C and C++, like so many proponents of Java would like us to believe? Or are they the new and quickly developing languages with little enforcement of structure, like PHP? Let’s go to Veracode and get their report: “State of Software Security. Focus on Application Development. Supplement to Volume 6.

The report includes a very informative diagram showing what percentage of applications passes the OWASP policy for a secure application out of the box grouped by the language of the application. OWASP policy is defined as “not containing any of the security problems mentioned on the OWASP Top 10 most important vulnerabilities for web application” and OWASP is the accepted industry authority on web application security. So if they say that something is a serious vulnerability, you can be sure it is. Let’s look at the diagram:

Veracode OWASP by language 2016-01-18-01

Fully 60% of applications written in C/C++ come without those most severe software security vulnerabilities listed by OWASP. That is a very good result and a notable achievement. Next, down one and a half to two times, come the three mobile platforms. And the next actual programming language, .NET, comes out more than two times as bad! Java is 2 and a half times as bad as C/C++. The scripting languages are three times as bad.

Think about it. Applications written in Java are almost three times as likely to contain security vulnerabilities as those written in C/C++. And C/C++ is the only language that gives you a more than 50% chance of not having serious security vulnerabilities in your application.

Why is that?

The reasons are many. For one thing, Java has never delivered on its promises of security, stability and uniformity. People must struggle with issues that have been long resolved in other languages, like the idiotic memory management and garbage collection, reinventing the wheel on any more or less non-trivial piece of software. The language claims to be “easy” and “fool-proof” while letting people to compare string objects instead of strings with an equal operator unknowingly. The discrepancy between the fantasy and reality is huge in the Java world and getting worse all the time.

Still, the main reason, I think, is the quality of the developer: both the level of developer knowledge, expertise, as it were, and the sheer carelessness of the Java programmers. Where C/C++ developers are actually masters of the software development, the Java developers are most of the time just coders. That makes a difference. People learn Java in all sorts of courses or by themselves – companies constantly hire Java developers, so it makes sense to follow the market demand. Except that those people are kids with an ad-hoc knowledge of a programming language and absolutely no concept of software engineering. As opposed to that, most C/C++ people are actually engineers and they know much better what they are doing, even when they write things in a different language. But the “coders” are much cheaper than real engineers, so the companies developing in Java end up with lots of those and the software quality goes down the drain.

The difference in the quality of the software is easily apparent when you compare the diagrams for types of the issues detected mostly from the same report:

Veracode Problem Areas 2016-01-18

You can see that code quality problems are only 27% of the total number of issues detected in the case of C/C++ while for Java code the code quality issues represent the whopping 80% of total.

Think again. The code written in Java has several time worse quality than the code written in C/C++.

It is not surprising that the quality problems result in security vulnerabilities. Both quality and security go hand in hand and require discipline and knowledge on the part of developer. Where one suffers, the other inevitably does as well.

The conclusion: if you want secure software, you want C/C++. You definitely do not want Java. And even if you are stuck with Java, you still want to have C/C++ developers to write your Java code because they are more likely to write better and more secure software.

Backdoors in encryption products

padlock-security-protection-hacking-540x334After the recent terrorist attacks the governments are again pushing for more surveillance and the old debate on the necessity of the backdoors in encryption software raises its ugly head again. Leaving the surveillance question aside, let’s see, what does it mean to introduce backdoors to programs and how they can be harmful, especially when we are talking security and encryption?

Generally, a backdoor is an additional interface to a program that is not documented, its existence is kept secret and used for purposes other than the main function of the program. Quite often, a backdoor is simply a testing interface that the developers use to run special commands and perform tasks that normal users would not need to. Such testing backdoors are also often left in the production code, sometimes completely unprotected, sometimes protected with a fixed password stored in the code of the program where it is easy to find, i.e. also unprotected. Testing backdoors may or may not be useful to an attacker depending on the kind of functionality they provide.

Sometimes the backdoors are introduced with an explicit task of gaining access to the program surreptitiously. These are often very powerful tools that allow full access to all functionality of the program and sometimes add other functions that are not even available at the regular user interface. When talking about security and encryption products, such backdoors could allow unauthorized access, impersonation of other users, man-in-the-middle attacks, collection of keys, passwords and other useful information among other things.

The idea of the proponents of introducing backdoors into security and encryption software is that we could introduce such backdoors to the encryption and other tools used by general public. Then, the access to those backdoors would only be available to the police, justice department, secret services, immigration control and drug enforcement agencies… did I miss any? Maybe a few more agencies would be on the list but they are all well behaved, properly computer security trained and completely legal users. And that access would allow them to spy on the people using the tools in case those people turn out to be terrorists or something. Then the backdoors would come in really handy to collect the evidence against the bad guys and perhaps even prevent an explosion or two.

2015-07-19-image-5The problem with this reasoning is that it assumes too much. The assumptions include:

  1. The existence and the access to the backdoors will not be known to the “bad guys”. As the practice shows, the general public and the criminal society contain highly skilled people who can find those backdoors and publish (or sell) them for others to use. Throughout the computer history every single backdoor was eventually found and publicized. Why would it be different this time?
  2. The “bad guys” will actually use the software containing the backdoors. That’s a big assumption, isn’t it? If those guys are clever enough to use encryption and other security software, why would they use something suspicious? They would go for tools that are well known to contain no such loopholes, wouldn’t they?
  3. The surveillance of everyone is acceptable as long as sometimes one of the people under surveillance is correctly determined to be a criminal. This whole preceding sentence is by itself the subject of many a fiction story and movie, “Minority Report” as an example comes to mind. The book “Tactical Crime Analysis: Research and Investigation” might be a good discussion of problems of predicting crime in repeat offenders, now try applying that to first-time offenders – you get literally random results. Couple that with the potential for abuse of collected surveillance data… I don’t really even want to think about it.

So we would en up, among other things, with systems that can be abused by the very “bad guys” that we are trying to catch while they use other, trustworthy, software and the surveillance results on the general population are wide open to abuse as well. I hope this is sufficiently clear now.

Whenever you think of “backdoors”, your knee-jerk reaction should be “remove them”. Even for testing, they are too dangerous. If you introduce them in the software on purpose… pity the fool.

CAST Workshop “Secure Software Development”

7033818-3d-abbild-monster-mit-investigate-linseWe are organizing the workshop on “Secure Software Development” now for the third year in a row. As usual, the workshop is in Darmstadt and the logistics is cared for by the CAST e.V. The date for the workshop is 12 November.

This year most presentations seem to be in German, so probably it does not make much sense for non-German speaking people. But if you speak German, we have some rather interesting subjects like our experiences with vulnerability management, research into sociotechnical basis of development security and problems with developing the mobile payment infrastructure security.

The workshop is a great place for discussions and meeting various people working on security in software development. Please, come and join us on 12 November!

Windows 10: catching up to Google?

windows-10-is-spying-on-every-user-but-theres-a-way-outWindows 10 has turned out to be a very interesting update to the popular desktop operating system. Apparently, Microsoft envies Google for their success in spying on everyone and their dog through the Internet. Accordingly, Microsoft could not resist turning Windows into a mean spying machine. People were mightily surprised when all of the new spying features of Windows started to get uncovered.

To start with, the EULA, the license agreement, actually states clearly that Microsoft will collect the history of browsing, WiFi access point names and passwords, and website passwords. All of this information will be stored in the “user’s” Microsoft account, i.e. on the servers of Microsoft. Every user will receive a unique identification number that will be available to third parties for targeted advertisement.

When you use BitLocker for disk encryption, the key will be also stored at Microsoft! The license agreement states that the password will be copied automatically to OneDrive servers. I told you that going with BitLocker was not something a sane person would do, didn’t I?

And now all of that personal data can be used by Microsoft at will:

We will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary to protect our customers or enforce the terms governing the use of the services.

See, it’s not just in case that a court issues an order, but simply whenever Microsoft thinks that they need to.

Some observers report that the license also reserves the rights for Microsoft to disconnect “unlicensed hardware”. I did not find that part in the EULA though, I don’t know if it is true. I found something else though. Windows 10 will also remove your anti-virus or other anti-malware protection: “other antimalware software will be disabled or may have to be removed”.

That’s the part about EULA. There is also Cortana, the virtual assistant, and various parts of the OS that submit various information to Microsoft. Well, Cortana can be disabled. However, it turns out that even disabling every single thing that reports user information to Microsoft does not help – Windows 10 still reports a lot of things, now without even informing the user. Apparently, the user cannot switch off all of the monitoring.

One of the things that cannot be switched off is a built-in keylogger. The keystrokes are recorded in a temporary file and then submitted to Microsoft servers. Keylogger is active even when you are not logged into the Microsoft account.

Another thing is the microphone and camera. Whenever the microphone is on, it records the sound and transmits it to the servers of the company. The same happens to the video camera, the video is recorded automatically and the first 35 MB are sent over to Microsoft.

Microsoft explains that all of this is necessary to create a database of users, so that the targeted advertisement can be sold to third parties. However, these are obvious privacy violations and some of them are even performed without informing the user.

Microsoft has also announced that some of the features of the Windows 10 will be backported to the previous versions of Windows. So we can expect soon the updates for previous versions that will introduce these spying features across all of Windows computers.

Continue the TrueCrypt discussion: Windows 10

I already pointed out previously that I do not see any alternative to the TrueCrypt for encrypting data on disk. TrueCrypt is the only tool that we can more or less trust so far. You will probably remember that Bruce Schneier recommended to use Windows encryption, the BitLocker, instead of TrueCrypt and I called that idea nonsense. To prove me right, here comes the Windows 10 End User License Agreement (EULA) that states explicitly Microsoft will retain the keys to the encryption.

windows-10-is-spying-on-every-user-but-theres-a-way-outThis is rather amazing but, indeed, if you used the BitLocker to encrypt the data on disk, the key will be copied by Microsoft to the OneDrive servers. Of course, that makes the encryption quite pointless as the OneDrive servers are controlled by Microsoft and they will give the key to government authorities and intelligence agencies.

Moreover, Microsoft actually reserves the right to do anything they want with all your data, which by definition includes your keys and the data protected by the encryption:

We will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary to protect our customers or enforce the terms governing the use of the services.

So, really, all of your information is not only accessible to the government and intelligence agencies but even the company itself will access and manipulate your data whenever they believe it “necessary”.

Yes, TrueCrypt remains the only tool for disk encryption on Windows and you cannot, in good faith, claim that BitLocker is a good substitute for it. And, really, go Linux already.


truecryptSince the anonymous team behind TrueCrypt has left the building, security aware people were left wondering what’s next. I personally keep using TrueCrypt and as long as it works I will keep recommending it.

Recently, Bruce Schneier has raised a few red flags by his strange advice that seems to indicate that he is being paid now for his “services to the community” by parties not so interested in keeping the community secure. One more thing is his advice to switch from TrueCrypt to BitLocker.

The guys that “disappeared” from behind TrueCrypt recommended to switch to BitLocker and that makes BitLocker suspect right away. Moreover, anyone working in security would be right suspecting that BitLocker, coming from Microsoft, would be backdoor-ed. And now Bruce Schneier is coming out and saying that he recommends BitLocker now instead of TrueCrypt? Great. I am not going to trust either.

TrueCrypt for the moment remains the only trustworthy application for disk encryption. There is an effort to make TrueCrypt survive and support newer features of the file systems. I hope it works and we still have some tool to trust in five years from now.

I have also stored the recent versions of TrueCrypt.

The human factor: philosophy and engineering

The ancient Greeks had a concept of “aretê” (/ˈærətiː/) that is usually loosely translated to English as “quality”, “excellence”, or “virtue”. It was all that and more: the term meant the ultimate and harmonious fulfillment of task, purpose, function, or even the whole life. Living up to this concept was the highest achievement one could attain in life. Unfortunately, it does not translate well into English where the necessary concept is absent.

To give an example of arete, one could consider a work of art, like a painting, or a book. We could argue infinitely about a work of art and its many aspects but the majority of people do not have any problem identifying whether a work of art is actually a masterpiece or a stupid piece of garbage. That “whatsit” that we identify in a masterpiece is the arete, the harmony of total and complete excellence of the author pouring his virtue into his work.


Unfortunately, the science of the today’s world is not built on the same principles and, in fact, is divorcing from it further and further. It all started probably with the Aristotle and his move away from the “essence of things” being the source of everything else. Aristotle taught us, essentially, that we can understand things by splitting and analyzing them, that the “essence” of a thing could be understood from a thing itself, that we could achieve anything through the “divide and conquer” principle. That is where our scientific methods originate. Aristotle, among other philosophers, gave us the logic and foundation for all other sciences.

The scientific methods of divide and conquer are great, that’s what built this civilization, effectively, but they have a downside. They are all fine when there is a counterbalance to them but when they are taken as the only possible view of the world, when they are taken as the ultimate philosophy, they are taken to the extremes and start causing problems. It is surprising that such a far-fetched connection should have to be made, from ancient philosophy to contemporary engineering and security, but our engineering is based on how we think, so our products necessarily reflect our (apparent or obscured) philosophy.

What is the problem with the philosophy direction that started with Aristotle that we all effectively follow ever since? The problem is that it lives no place and does not require the arete, the harmonious excellence. The philosophy of today makes our thinking, and not only scientific thinking, compartmentalized. We are now used to thinking about things as completely separate from each other. We are used to dividing the world up into small chunks and operating on those small chunks one at a time, arguing that thus we are making the whole thing more manageable. We treat the world as a puzzle, investigating and tweaking one piece at a time. But we forget about the relation of the chunk we are working on to the grand scheme of things. We forget about the influences and dependencies, both in space and time. We forget that the puzzle must click together in the end.

Screenshot from 2015-04-22 10:55:04For example, when you get the quality management explained to you, you usually receive the overview of the famous “5 views of quality”. The “transcendental view” is formulated as the inherent quality obvious to the observer – “I know it when I see it”; “product-based view” provides for designing a product against benchmarks for speed, mean failure rate etc.; “user-based view” calls for satisfying the consumer preferences; “manufacturing-based view” requires conformity to user requirements; and the “value-based view” calls for design based on cost-benefit analysis. Out of all these things, the only thing that customer really sees and really cares about is the first one – the arete, the “transcendental quality”. Guess which one is completely ignored in quality management? The very same one, for a very simple reason that it is not easily broken up into pieces to be measured and “improved” on their own. And the same problem permeats all of our engineering, and especially security.

Systemic approach

That means we tend to ignore one of the cornerstones of security: systemic approach. We often come across this myth declared even from security conference stages that secure components will mean a secure system. This is the assumption that drives many a creation of systems that are claimed for this reason to be secure. Well, what a surprise: it won’t and they aren’t. This problem is well-known in the security field, especially where seriously high levels of security are involved, like smart card business. When you take two secure components and combine them, you cannot make any statement about the security of the whole based just on the security of each part. You must consider the whole thing before you can make any statements regarding the system.

Secure components are never secure unconditionally. They are secure conditionally. They are secure as long as a certain set of assumptions holds true. Once an assumption is invalid, the component is no longer secure. When we combine two secure components we create a problem of composition, where the components potentially interact in unforeseen ways. They may be secure still, but may be not. This is the case where a systemic, holistic view of the system must definitely take the upper hand.

Short time horizons

Another problem is the extreme shortening of the time horizons. Did you notice how everyone is interested only in the immediate results, immediate profits, things we can deliver, sell, buy, have, wear, eat, and drink today? It is noticeable everywhere in the society but in the software industry it has become the defining aspect of life.

When whatever we are building exists in isolation, when we need not consider the effects on the industry, technology, society… we do not need to worry about long-term results of our work. We did this “thing” and we got our bonus, that’s the end of the story. But is it?

I am sure we all came across problems that arise from someone not doing a proper job when they did not think it was worth the trouble because it was all done and gone. Yes, for whoever did it, it was done and gone, but for us, the people coming after, don’t we wish that someone was more careful, more precise, more thoughtful? Don’t we wish he had spent just a little more time making sure everything works not just, but properly?

I have a friend that works in a restaurant chain in St-Petersburg. That’s a pretty large chain and there are many things to do, of course. One thing that we talked about once was the Food Safety and Health inspection. I was surprised, frankly, at how much effort goes into the compliance with those rules. They actually do follow all of the guidance for Food Safety and perform thorough audits and certification. When I asked her why they bother with this, my friend told me that they have two very serious reasons to do so and both of them are long-term overall business risk problems. One, if someone should get a food poisoning, they would otherwise have no certifications and audit results to fall back on and they would have a hard time in court proving that they actually did follow due diligence in all matters. Two, they would lose a lot of clientele if something like this would ever happen and for an established industry with a lot of competition that could as well mean going out of business.

So, you could call that risk management, due diligence, or simply good understanding that business is not just about getting the products as cheaply as possible out of the door in the long term, the understanding that there is more to making good business than momentarily advantages. My friend has a holistic view of the business that encompasses everything that’s important for the business and that makes her and her business successful.

They could, like so many companies in our software field, take a short term view and save some money, get something quick and dirty done, but they have an understanding that this is not a sound business strategy long-term. In our field, the security is getting worse and worse and somehow we still think it is okay to think entirely in the short term, to the next release, to the next milestone. What we need is a proper long term consideration of all aspects of the products we develop and deliver for things to start changing to the better. The holistic approach to the software development may slow things down but it will bring the risk of the future collapses down for all of us.

Security prevents innovation

Another aspect of the same “faster and fancier now!” game that we encounter regularly is the “Security should not prevent innovation!” slogan. Says who? Not that I am against innovation but security must sometimes prevent certain innovation, like tweaking of cryptographic algorithms for performance that would break security. There is such thing as bad or ill-conceived innovation from the point of view of security (and, actually, from every other point of view, too). Wait, it gets worse.

Innovation’ has become the cornerstone of the industry, the false god that receives all our prayers. There is nothing wrong with innovation per se but it must not take over the industry. The innovation is there to serve us, not the other way around. We took it too far, we pray to innovation in places where it would not matter or be even harmful. Innovation by itself, without a purpose, is useless.

We know that this single-minded focus will result in security being ignored time and again. There is too much emphasis on short-term success and quick development resulting not only in low security but low quality overall.

Finding ways of doing things properly is the real innovation. Compare to civil engineering, building houses, bridges, nuclear power stations. What would happen if the construction industry was bent on innovation and innovation only, on delivering constructions now, without any regard to proper planning and execution? Well, examples are easy to find and the results are disastrous.


What makes the big difference? We can notice the bridge collapsing or a building falling down, we do not need to be experts in construction for that. Unfortunately, collapsing applications on the Internet are not that obvious. But they are there. We really need to slow down and finally put things in order. Or do we wait for things to collapse first?

Uncertainty principle

An interesting concept has surfaced not so long ago as an excuse for not doing anything, called the “uncertainty principle of new technology”…

It has been stated that the new technology possesses an inherent characteristic that makes it hard to secure. This characteristic is articulated by David Collingridge in what many would like to see accepted axiomatically and even call it the “Collingridge Dilemma” to underscore its immutability:

That, when a technology is new (and therefore its spread can be controlled), it is extremely hard to predict its negative consequences, and by the time one can figure those out, it’s too costly in every way to do much about it.

This is important for us because this may mean that any and all efforts we do on securing our systems are bound to fail. Is that really so? Now, this statement has all of the appearance to sound true but there are two problems with it.

First, it is subject to the very same principle. This is a new statement that we do not quite understand. We do not understand if it is true and we do not understand what the consequences are either way. By the time we understand whether it is true or false it will be deeply engraved in our development and security culture and it will be very hard to get rid of. So even if it was useful, one would be well advised to exercise extreme caution.

Second, the proposed dilemma is only true under a certain set of circumstances, namely, when the scientists and engineers develop a new technology looking only at the internal structure of the technology itself without any relation to the world, the form, and the quality. Admittedly, this is what happens most of the time in academia but it does not make it right.

When one looks only at the sum of parts and their structure within a system, let’s say, one can observe that parts could be exchanged, modified and combined in numerous ways often leading to something that has potential to work. This way, the new technologies and things can be invented indefinitely. Are they useful to the society, the world and the life as we know it? Where is the guiding principle that tells us what to invent and what – not? Taken this way, the whole process of scientific discovery loses its point.

The scientific discovery is guided by the underlying quality of life that guides it and shapes its progress. The society influences what has to be invented, whether we like it or not. We must not take for granted that we are always going the right way though. Sometimes, the scientists should stand up for fundamental principles of quality over the quantity of inventions and fight for the technology that would in turn steer the society towards better and more harmonious life.

Should the technology be developed with utmost attention to the quality that it originates from, should the products be built with the quality of life foremost in the mind, this discussion would become pointless and this academic dilemma would not exist. Everything that is built from the quality first remains such forever and does not require all this endless tweaking and patching.

We can base our inventions and our engineering on principles different than those peddled to us by the current academia and industry. We can re-base the society to take the quality first and foremost. We can create technologically sound systems that will be secure. We just have to forgo this practicality, the rationality that guides everything now even to the detriment of life itself and concentrate on the quality instead.

The beauty and harmony of proper engineering have been buried in our industry under the pressure of rationality and the rush of delivery but we would do better to re-discover it than to patch it with pointless and harmful excuses.


NASA Apollo Mission

Think of the Apollo mission that brought people to the Moon. Would you not say that that was a great achievement not only for the engineers but the whole world? The Apollo mission was a project that encompassed many different areas, from metallurgy to psychology, to make space travel possible.

357863main_apollo-insigniaApollo ships also had software. The software was complex and had lots of parts. The spaceship contains a lot of sensors, equipment and machinery that are controlled by software. There is command and data handling, telecommunications, electrical power systems control, propulsion control, guidance and navigation systems, spacecraft integrity control, thermal control and so on. The spaceship is an incredibly complex system that operates under a wide variety of hard and extreme conditions. There is the vibration stress and accelerations, radiation and cosmic rays, meteoroids and extreme temperatures. And do not forget that the system also must be fool-proof. As one of the people working on the Apollo put it, “there is always some fool that switches the contacts polarity.”

And this complex system that had to operate under a tremendous stress actually worked. Apollo did not only go to the Moon but returned safely back to Earth. Is this not an example of great engineering? Is this not an example of a great achievement of humankind?

The software for the mission was developed by the engineers of MIT under the project management of NASA and using the software development process experts from IBM. However, the success of the software development for the Apollo mission could not be attributed to the software process guidance form the IBM or to the project management of NASA. They all failed miserably. They tried and divided the system up in components and developed the software to the best standards… and it did not work. MIT were lucky in a sense that the start was delayed due to hardware problems, otherwise NASA would have to cancel it for the software problems.

it gets difficult to assign out little task groups to program part of the computer; you have to do it with a very technical team that understands all the interactions on all these things.
— D. G. Hoag interview, MIT, Cambridge, MA, by Ivan Ertel, April 29, 1966

The software was only developed because the MIT engineers got together and did it as a single system.

In the end NASA and MIT produced quality software, primarily because of the small-group nature of development at MIT and the overall dedication shown by nearly everyone associated with the Apollo program.
— Frank Hughes interview, Johnson Space Center, Houston, TX, June 2, 1983

The software for the Apollo program was failing as long as they tried to isolate the systems and components from each other. Once the engineers used the “small group”, that is they got together and worked on it as the whole system with close dependencies and full understanding, they were successful. It is not so much that they refused the oversight and process expertise but that they took a systemic, holistic view of the whole thing and they all understood what they are doing and why. Some of the corners they had to cut caused malfunctions in the flight but the pilots were prepared for those, they knew those could happen and those faults did not abort the mission.

Software is deadly

As the society progresses, it writes more and more software and creates more and more automation. We are already surrounded by software, by devices running software of one kind or another, at all times. Somehow, we still think it is all right not to care what kind of software we put out. I think it is time to understand that everything we make will end up impacting us directly in our lives. Everything is controlled by software: TV, airplanes, cars, factories, power plants. Consequences of errors will be felt by everyone, by all of us, in many cases literary on our own skin. Current methods of software development cause mass malfunction.

We screw up – people die. Some examples:

  1. Therac-25: A state of the art linear accelerator for radiation treatment. The equipment delivered lethal doses of radiation to three people due to a setup race condition in 1985.
  2. Ariane 5 rocket destroyed in 1996: Conversion of velocity in the guidance unit from 64 bit to 16 bit overflowed. Destroyed 4 scientific satellites, cost: $500 million.
  3. Nuclear holocaust was avoided twice at the last moment because a human operator intervened, verified the automated results as false positive and prevented a strike back. The dates are: June 1980, NORAD Nuclear missile false alarm and September 1983, Soviet Nuclear missile false alarm.
  4. March 2014: Nissan recalls 990,000 cars because a software problem in the occupant classification system might not detect an occupant in the passenger seat and prevent airbag deployment.
  5. July 2014: Honda has conceded that a software glitch in electronic control units could cause cars to accelerate suddenly, forcing drivers to scramble to take emergency measures to prevent an accident. Honda Motor Co., citing software problems, announced that it is recalling 175,000 hybrid vehicles.
  6. April 2015: U.S. GAO publishes the “Air Traffic Control: FAA Needs a More Comprehensive Approach to Address Cybersecurity As Agency Transitions toNextGen” report, stating that the flight control computers on board of contemporary aircraft could be susceptible for break-in and take over by using the on-board WiFi network or even from the ground.

Complex relationships in the real world – everything depends on everything – make the situation more and more dangerous. The questions of technology and ethics cannot be separated; developers must feel responsibility for what they create.

Specialization or Mastership

There is a tale that six blind men were asked to determine what an elephant looked like by feeling different parts of the elephant’s body. The blind man who feels a leg says the elephant is like a pillar; the one who feels the tail says the elephant is like a rope; the one who feels the trunk says the elephant is like a tree branch; the one who feels the ear says the elephant is like a hand fan; the one who feels the belly says the elephant is like a wall; and the one who feels the tusk says the elephant is like a solid pipe.


All of them are right. The reason every one of them is telling it differently is because each one touched a different part of the elephant.

Our narrow-specialized view of the world is very similar to that of the blind men feeling an elephant. I see the security part of the elephant, developers see the functionality part of the elephant and none of us see the whole of the elephant. As a result, the improvement is judged on a fragment of the system, not the system as a whole. We think that if we make a larger front right leg, we will get a better elephant. Or, maybe, that’s a longer trunk that’s important. In reality, we get an ugly and malfunctioning elephant. We get a failure. Develop a function, take no account of security – get a failure. Develop a security feature, take no account of usability – get a failure. Since nobody has the holistic view, any approach to making the elephant bigger on one or another side fails. We fail on all fronts.

The absence of holistic approach that unites all of the aspects of the system and sees it in action results in complete and unavoidable failure.

This failure causes both direct financial and indirect, through the waste of resources, losses. We need to slow down and get an overview of what we are doing, each of us. We need to get some understanding of the whole. We need to figure out how everything works together. This is not a problem of documentation, or communication, or proper processes. This is the deeper problem of understanding our creations and thinking about the world. We need to be able to put it all together in our heads to be able to work out how to make the elephant better.

The agile methods proponents did a step in the right direction by saying that specialization is not necessary or even harmful for software development. Unfortunately, they did twenty steps away by saying that developers only need to understand a small chunk of code they are working on and nothing else.

Security is integral to development

So if you look at the current software development, you will notice that security is always built around the product like a fence, after the fact. First you get the function and then you get a fence of security around it. And the situation is exactly the same with other things like quality and usability. As a result, you get something like a bit of more or less coherent code with a bunch of fences around it. You are lucky if the fences end up being concentric too. The developers of different aspects of the system tend to have completely different ideas about what the system does and its intended environment.

That is not a good way of dealing with product development. We need product development that unites all aspects of the product and includes its interaction with the world. We need developers that understand the product’s function and can deal with the multitude of aspects of the product and its lifecycle. Developers and managers must understand that security is an integral part of the product and deal with it responsibly.

I notice that when I talk about the security program I created at Software AG, I invariably get the same reaction: what our security team is doing is very advanced and simply amazing. Well, for me it is not. The difference is that most companies go after security piecemeal and after the fact, while we applied the holistic approach and we introduce security to all areas of product development. Other companies simply perform some penetration testing, fix the bugs and leave it at that. We go after the development process, company policies, developer training and so on, taking the view that everything we do contributes to security or insecurity of our products. That creates a very impressive feeling of quality to what we do even though it is perfectly normal to do and expect.

Let’s start small. I want you to look back at the ancient Greek philosophy and understand the meaning of taking a holistic approach to everything you do. We need that principle, we need the holistic approach in other areas of our lives too but we need it badly now in software engineering. We need the excellence, the harmony, and the overview. Next time you do your job try considering and following a more holistic, systemic approach.

The holistic approach will allow you to make sure that whatever you do is actually correct, secure, of high quality, works as expected and is simply right for the customer. It will allow you to control the changes and innovation, external influences and impulses, while understanding what should be used and what – ignored. The holistic approach will also mean that you deliver long-term value and improvements, making finally that better elephant that the customers have been waiting for.


Posts navigation

1 2 3 4 7 8 9