Just a quick note:
“Eat less bread” requests a British poster from WWI. We all know it makes sense, don’t we? Resources become scarce at wartime, so wasting them weakens one’s own position. Yet this kind of advice can be utterly useless: tell a hungry person to eat less bread and you will earn, at best, a blank stare. However reasonable your advice may seem to you and everyone else, a hungry person will be physically and mentally unable to comply.
“Do not call system()” or “Do not read uninitialized memory” request secure coding guides. Such advice is equally useless if directed at a person who lacks the cognitive ability to comply. Cognitive limitations do not mean a person is stupid. We all are limited in our respective ability to process information, and we are more similar to than dissimilar from each other in this regard.
Secure coding guidelines all too often dictate a large set of arbitrary dos and don’ts, but fail to take human factors into account. Do X! Don’t do Y, do Z instead! Each of these recommendations has a sound technical basis; code becomes more secure if everyone follows this advice. However, only some of these recommendations are realistic for programmers to follow. Their sheer number should raise our doubt and let us expect that only a subset will ever be adopted by a substantial number of programmers.
Some rules are better suited for adoptions than others. Programmers often acquire idioms and conventions they perceive as helpful. Using additional parentheses for clarity, for example, even though not strictly necessary, improves readability; and the const == var convention prevents certain defects that are easy to introduce and sometimes hard to debug.
Other rules seem, from a programmer’s point of view, just ridiculous. Why is there a system() function in the first place if programmers are not supposed to use it? And if developers should not read uninitialized memory, what would warn them about memory being not initialized? Such advice is inexpensive – and likely ineffective. If we want programmers to write secure code, we must offer them platforms that make secure programming easy and straightforward and insecure programming hard and difficult.
Security and protection systems guard persons and property against a broad range of hazards, including crime; fire and attendant risks, such as explosion; accidents; disasters; espionage; sabotage; subversion; civil disturbances; bombings (both actual and threatened); and, in some systems, attack by external enemies. Most security and protection systems emphasize certain hazards more than others. In a retail store, for example, the principal security concerns are shoplifting and employee dishonesty (e.g., pilferage, embezzlement, and fraud). A typical set of categories to be protected includes the personal safety of people in the organization, such as employees, customers, or residents; tangible property, such as the plant, equipment, finished products, cash, and securities; and intangible property, such as highly classified national security information or “proprietary” information (e.g., trade secrets) of private organizations. An important distinction between a security and protection system and public services such as police and fire departments is that the former employs means that emphasize passive and preventive measures.
The way to learn whether a person is trustworthy is to trust him.
In their Black Hat stage performance, employees of a security company showed how apps on certain mobile phones can access fingerprint data if the phone has a fingerprint sensor. The usual discussions ensued about rotating your fingerprints, biometrics being a bad idea, and biometric features being usernames rather than passwords. But was there a problem in the first place? Let’s start from scratch, slightly simplified:
Conclusion: Not every combination of patterns-we-saw-in-security-problems makes a security problem. We are leaving fingerprints on everything we touch, they never were and never will be confidential.
Carcinogenic is a scary word, but what exactly does it mean? The International Agency for Research on Cancer (IARC), a part of the World Health Organization (WHO), has established a framework. The IACR reviews scientific evidence for and against carcinogenicity claims and places agents in one of the following categories:
The IACR publishes classification criteria and lists (by category, alphabetical). Wikipedia also maintains lists by these categories with links to the respective pages.
Keep in mind that this classification represents only the state of evidence regarding cancerogenicity in humans, not your risk of becoming exposed to an agent, a dose-response assessment, or overall health risk from exposure. Hint: everything that kills you quickly and reliably is unlikely to cause you cancer.
Is security about keeping secrets? Not really, although it seems so at first glance. Perhaps this mismatch between perception and reality explains why threats are mounting in the news without much impact on our actual lives.
Confidentiality comes first in infosec’s C/I/A (confidentiality, integrity, availability) trinity. Secrets leaking in a data breach are the prototype of a severe security problem. Laypeople even use encryption and security synonymously. Now that the half-life of secrets is declining, are we becoming less and less secure?
Most real security problems are not about keeping secrets, they are about integrity of control. Think, for example, of the money in your wallet. What matters to you is control over this money, which should abide by certain rules. It’s your money, so you should remain in control of it until you voluntarily give up your control in a transaction. The possibility of someone else taking control of your money without your consent, through force or trickery, is something to worry about and, if such others exist, a real security problem. Keeping the contents of your wallet out of sight is in contrast only a minor concern. Someone peeking into your wallet without taking anything is not much of a threat. Your primary security objective is to remain in control of what is yours most of the times and to limit your losses across the exceptional cases when you are not.
This security objective remains just the same as you move on from a wallet to online banking. What matters most is who controls the balance in which way. In a nutshell, only you (or others with your consent), knowingly and voluntarily, should be able to withdraw money or transfer it from your account; you should not be able to increase your balance arbitrarily without handing in actual money; others should be able to transfer any amount to your account; exceptions apply if you don’t pay your debts.
Confidentiality is only an auxiliary objective. We need confidentiality due to vulnerabilities. Many security mechanisms rely on secrets, such as passwords or keys, to maintain integrity. This is one source of confidentiality requirements. Another is economics: Attackers will spend higher amounts on valuable targets, provided they can identify them. If there is a large number of possible targets but only a few are really valuable, one might try to make the valuable target look like all the others so that attackers have to spread at least part of their effort across many candidate targets. However, strong defenses are still needed in case attackers identify the valuable target in whichever way, random or systematic.
The better we maintain integrity of control, the more secure we are. Systems remain predictable and do what we want despite the presence of adversaries. Confidentiality is only a surrogate where we do not trust our defenses.
The following videos teaches us the 7 signs of terrorism:
Now watch out for terrorists.
We are organizing a workshop on agile secure software development in conjunction with the ARES’15 conference. Please find the full call for papers on the workshop website, http://www.ares-conference.eu/conference/workshops/assd-2015/. The conference takes place in Toulouse this year.
Submission Deadline: April
Author Notification: May 11, 2015
Proceedings version: June 8, 2015
Conference: August 24-28, 2015
Security, privacy, and safety by design sounds like a good idea. Alas, it is not going to happen, at least not with innovative technology. Collingridge’s dilemma gets in the way: When a technology is new and therefore easy to shape, we do not understand its downsides – and the non-issues to be – well enough to make informed design decisions, and once we understand the problems, changing the now established and deployed technology fundamentally becomes hard. Expressed in terms of the Cognitive Dimensions framework, technology design combines premature commitment with high viscosity later on.
With digital technology evolving at high pace, we are continually facing Collingridge’s dilemma. Big data and Internet-scale machine learning, the Internet of everything, self-driving cars, and many inventions yet to come challenge us to keep things under control without knowing what to aim for. Any technology we never created before is subject to the dilemma.
A tempting but fallacious solution is the (strong) precautionary principle: to take all possible risks seriously and treat whatever we cannot rule out as a problem. This approach is fallacious because it ignores the cost of implementation. Every possible risk is not the same as every likely risk. Trying to prevent everything that might go wrong one will inevitably end up spending too much on some possible but unlikely problems. Besides, Collingridge’s dilemma may apply to the chosen treatments as well.
As an alternative we might try to design for corrigibility so that mistakes can be easily corrected once we learn about them. With respect to the information technology domain this idea seems to echo what David Parnas proposed in his seminal paper On the criteria to be used in decomposing systems into modules (DOI: 10.1145/361598.361623). Parnas argues in this paper that software modules should hide design decisions from their surroundings, so that the inner workings of a module can be modified without affecting dependent modules. Constructs supporting this found their way into modern-day programming paradigms and languages; object-oriented programming is the most abvious application of Parnas’ idea.
But the dilemma is not that easily solved. First, software design is too narrow a scope. Technology is more than just software and can become quite viscous regardless of how easily the software is changed. Just think of the Internet and its core protocol, IP. Most operating systems come with support for IPv4 and IPv6 and there are many good reasons to move on to the new protocol version. Yet we are still waiting for the day when the Internet will abandon IPv4 in favor of IPv6. The Internet as a system is really hard to change. Nevertheless, modularity helps. When attacks against Internet banking users became widespread starting ca. 10 years ago, for example, banks in Germany managed to update their authorization mechanisms and increase security in relatively short time and with few troubles for their customers.
In their recent paper Cyber Security as Social Experiment (NSPW’14, DOI: 10.1145/2683467.2683469), Wolter Pieters, Dina Hadžiosmanović and Francien Dechesne argue that experimentation could help us to learn more about the side effects of new technology. Since people are part of any interesting system, this amounts to running social experiments. If we do not care and just deploy a technology, this is an experiment as well, just less controlled and systematic. Particular to cyber security is the challenge of involving adversaries as they are the root of all security threats. The general challenge is to run social experiments responsibly within ethical bounds.
Even with experiments, some negative consequences will likely escape our attention. Some effects take too long before they show or show only after a technology has been deployed at a global scale. Could James Watt have thought of climate change due to the burning of fossil fuel? Probably not. But at least we understand what the meta-problem is.
(This post appeared first on the ESSE project blog.)
Earlier this year Andreas presented at the New Security Paradigms Workshop our paper An Asset to Security Modeling? Analyzing Stakeholder Collaborations Instead of Threats to Assets (DOI: 10.1145/2683467.2683474). During our work with the GESIS Secure Data Center team it emerged that the common way we use to do risk assessment may be flawed. In this paper we discuss what is missing and how to analyze collaboration networks to understand consequences of security incidents.
Risk assessment, as described for example in ISO 31000, is a systematic process that prepares decisions. The goal of this process is to find appropriate risk responses and treatments. A risks can be accepted or even increased (if doing so entails an opportunity); it can be avoided, shared or transferred; or the risk can be mitigated by reducing its likelihood or impact. As a prerequisite for informed decisions one goes through the risk assessment process, during which one identifies, analyzes, and evaluates pertinent risks. The figure below, a more elaborate version of which can be found in ISO 31000, illustrates this process chain.
Stakeholders participate in this process as a source of information, knowing their respective business or business function and being able to assess likelihoods and impacts. This standard approach to risk assessment has the premise that risk treatments are variable and the objective is to find optimal values for them.
In our paper we propose a complementary approach. Our premise: Stakeholders collaborate in complicated networks for mutual benefit. Risk and incident responses are to a large degree determined by their collaboration relationships. These pre-determined responses are not to be defined as a result of risk assessment, they rather constitute a factor to be considered in risk analysis and evaluation. The figure below is a simplified version of Figure 8 in our paper:
The Secure Data Center serves its users, which are part of a larger research community; the SDC also needs its users as serving them is its pupose. Beyond the individual user, the research community at large benefits from SDC services and influences their acceptance. Primary investigators provide data; they benefit from wider recognition of their work through secondary analyses and fulfil obligations by archiving their data. Survey participants are the source of all data. Everyone wants to preserve their willingness to participate in studies.
The need for an extension of risk assessment methodologies became apparent when we reviewed and discussed with the participants of our study the threat models they had produced. They expressed various concerns about the stakeholders involved and their possible reactions to security incidents. Although traditional approaches to risk assessment include the analysis of consequences, they fail to provide tools for this analysis. In the security domain in particular it is often assumed that consequences can be evlauated by identifying assets and assigning some monetsary value to each of them. According to our experience it’s more complicated.
Andreas Poller; Sven Türpe; Katharina Kinder-Kurlanda: An Asset to Security Modeling? Analyzing Stakeholder Collaborations Instead of Threats to Assets. New Security Paradigms Workshop (NSPW’14), Victoria, BC, September 15-18, 2014. DOI: 10.1145/2683467.2683474 [BibTeX]
That was a nice bit of trolling. A rough timeline: (1) Apple and later, Google announce modest improvements to a security building block of their respective mobile device platforms, device encryption. (2) Government officials in the US publicly complain how this would obstruct law enforcement and request means to access encrypted device data. (3) The usual suspects are all up in arms and reiterate their arguments why crypto backdoors are a bad idea.
What is wrong with this debate, apart from it being a rerun? First, encryption is not as secure as claimed. Second, encryption is not as important as assumed.
Device encryption is just one small security building block. It protects data stored on the device against access without the encryption key if the adversary encounters the device in the turned-off state. Attacks against encryption typically go for the keys. As we were just reminded, police can compel suspects to hand over their fingerprints and unlock a device. Some countries have key disclosure laws.
Against running devices there are further attack options. If any key material is held in RAM, it can be extracted, at least in principle, with a cold boot attack. Whether Apple’s Secure Enclave design does anything to protect against such attacks remains unclear. As we’ve learned with Microsoft’s encryption scheme, Bitlocker, even hardware-supported encryption can leave a number of loopholes (Trust 2009 paper).
Encryption has its limitations. It protects data subject to several conditions. In particular, the adversary must be unable to obtain the key or subvert the execution environment. While plug-and-play forensics would be more convenient for law enforcement, there are ways around device encryption.
Mobile platforms extend beyond the individual device. Not only do devices communicate liberally with other devices and with Internet services, they also depend on the platform operator. Apple and Google run appstores and supply software updates. Whatever the software of a device can or cannot do may change at any time.
Encryption protects files against access bypassing the operating system, not against access from within. Protection against rogue users or applications is a matter of authentication and access control — software making decisions, software that can be modified. While this channel entails some tampering-with-evidence problems for law enforcement, it seems technically quite feasible to use it.
Encrypted equals secure only from a microscopic perspective. I have advocated before to pay more attention to systemic and macroscopic aspects, and the crypto wars 2.0 debate illustrates nicely how a too narrow focus on a single security mechanism skews our debate. Encryption matters, but not as much as we allow them to make us believe it would.