RFC8280 - Human Rights Protocol

RFC 8280: odd but has the potential to become one of the most important RFCs ever. The same way at some point every RFC has a section called "Security Considerations", Security is now but one of basic aspects when designing a new technology.

Welcome to other considerations. Most are (arguably) absolute and consensual, e.g., Heterogeneity Support or Reliability. Others are not quite so such as Content Agnosticism, Censorship Resistance, Privacy.

Just coming up with such a list is fascinating. I'd have some to add -- as in for consideration when designing a new protocol -- while others feel redundant or not advisable at all (is "decentralisation" always desirable?")

Here's a list of the "moral content" of a protocol:

6.2.1. Connectivity .......................................43
6.2.2. Privacy ............................................43
6.2.3. Content Agnosticism ................................44
6.2.4. Security ...........................................45
6.2.5. Internationalization ...............................46
6.2.6. Censorship Resistance ..............................47
6.2.7. Open Standards .....................................48
6.2.8. Heterogeneity Support ..............................50
6.2.9. Anonymity ..........................................51
6.2.10. Pseudonymity ......................................51
6.2.11. Accessibility .....................................53
6.2.12. Localization ......................................53
6.2.13. Decentralization ..................................54
6.2.14. Reliability .......................................55
6.2.15. Confidentiality ...................................56
6.2.16. Integrity .........................................58
6.2.17. Authenticity ......................................59
6.2.18. Adaptability ......................................60
6.2.19. Outcome Transparency ..............................61

"Security doesn't matter" & ethereum hacks

In the early 2000s, there was a famous article titled "IT doesn't matter". At the time, this was preposterous. It caused lots of controversy and I remember having several discussions until I realised people had not read the actual article.

The thesis of it was very simple: it doesn't matter because IT had become a basic function such as HR. IT was not a competitive advantage anymore. IT was a "vanishing advantage".

Security doesn't matter.
Just like IT, Security & Privacy is never an end in itself, but means to arrive to a goal. The goal is the mission of the organisation, put simply. It is, and always have been, for the vast majority of companies, more of a license to operate:

• because its customers so require
• because there are regulations to comply with
• because it keeps the business running

Few business see Security as a need such as Capital. Banks is such a sector. They typically do not care about ISO 27001 certifications because the business-case of Security is intrinsic.

Security does not matter because it is becoming less and less of a competitive advantage. It is a necessary need (so to say) to do business and hence is becoming essential such as HR or Sales. More interesting, is that Security is stepping in to the customer front. To give an example, half of my time is not doing security as such but speaking to customers that want to be reassured we have good practices. Nowadays, for many, simply having a ISO 27001 certification is not enough. One has to show evidence of practices.

So the Ethereum hacks.

Considering this, it is just surprising that an Ethereum ICO could be hacked like this. Was there not USD 2k to get some advice and implement, for example, stop gap measures?

As Bruce Schneier says, the problem is not the smart contracts technology but rather the ecosystem around it.

Then another one, now with a small difference: they are an established wallet (browser integration) company and, my guess, almost everyone is a software developer. This typically sets an environment of sloppy security since Security is typically seen as a technical challenge such as password entropy. Security is much much more. Browse their website -- do we see anything about Security?

Yes, we do, after the 19 July. Is there a security statement explaining what lessons they learned. No. Hat do they do? They setup a bug bounty. Because Security is all about buffer overflows, 512-AES and WAFs, innit?

One of these days I will sit down in front of a pint and write "The Manual Securitist" -- how to fully protect and certify an organisation using only manual/human controls. I hope I never have to do this, but I am fully convinced all, say, CIS-20 or PCI/DSS  controls can be implemented, to a large extent, with technology of the 1960s.

.

Challenges with IoT Security

I was asked to complete a survey on Challenges and Promises of the Internet of Things. Not surprisingly, my laser beams were pointing at Security and Privacy.

Here's how I defined, to myself, the methodology:
* google "IoT challenges" and skim through results for exactly 10 minutes
* get a pint and brainstorm with myself
* let thoughts freely flow for exactly 45 minutes
* 5 minutes to fix sentences and typos

Here's the result.

What are the chief obstacles and Challenges to IoT adoption?

§  Lack of overall security frameworks.

This is not an issue of IoT per se, but how everything is managed. For example, the SDLC is typically not secure, if any maintenance exists at all. There are two problems here: the actual hardware (updating the firmware) and the cloud supporting service. Please note the recent US IoT Security Act (draft).

§  Secure technologies

The building blocks of IoT, at the thing level, such as network protocols, micro-storage, IoT OSes, etc, are not secure enough. This is to be combined with a lack of security wrappers, that could mitigate the intrinsic lack of security.

§  Security complexity

Considering the many building blocks of a IoT products (hardware, network, servers, cloud, web, mobile app, etc.), it is virtually under all threats known to man. If a service is only a website, or a car, at least the security vectors are confined to that particular technology and implementation. Quite ironic, Things are small but they sit in a very large area.

§  Physical security

Physically securing a device is really hard and expensive. There are no off-the-shelf, cheap, readily available, solutions for that. Once it is physically breached, trust in the user breaks and trust in the Thing itself also breaks.

§  Security of software management

This is a special case but one of the biggest problems. It only becomes apparent with scale. On one hand, patching devices is not straightforward. On the other hand, installed software will take up more space every time. Space is however limited because updating the hardware will often be impossible or impractical. What will people do with legacy devices? Just like phones, they will keep using them, even those aware they are vulnerable to even “script kiddies”. Some 50% of all the phones in the world are trivially hackable.

§  Liability

If a Thing is compromised it becomes a liability for both the manufacturer/developer and the user. Today security liability is vastly undefined (the upcoming NIS directive will partially address this). Most DDoS-for-hire services use things (like cameras) for that.

§  Liability (2)

There are no robust Insurance products for Security. Fighting liability easily outweights revenues from the product itself. Preparing for that scenario (so to limit liability) is still in baby steps before robust compliance frameworks. From where I stand, it is truly a “do everything you can think of” because it will sooner than later be used in court. Any little step may be the difference between going out of business overnight with a penalty and getting a wrist slap.

§  Liability (3)

If someone's home or car is hacked via the Thing, the company will be liable up to, as is the case with connected cars, corporate crimes against life. Today not even medical devices are covered but I expect this to change up to home surveillance cameras used to watch a baby from a different room in a house.

§  Corporate Liability/compliance and governance

Security nowadays is based on risk assessments. A Thing made by a company with no established Security practices will never be able to do business with established companies (and even less with regulated). When they accept to manage the risks themselves, they will soon realise the cost of ownership is too high. There is plenty of lessons from the past.

§  Data Privacy issues

IoT have the potential to collect what seems to be, at first glance, information that is not problematic. Profiling then becomes an issue (see the recent Vacuum robot mapping homes and just reselling it - how naive). Things about the Quantified-Self is a good example. Excellent ideas, excellent products, (poor business models), but no idea of the ecosystem.

§  Unconvincing business models

The idea that an arduino and a front-end developer is enough. IoT always comes with the promise of scale but until then the underlying business models will always seem to me immature. Reason is the actual hardware + software costs seem to be considered central when they will, necessarily, become marginal. As an analogy, the cost of producing a car is 10% and 90% is maintaining the brand, operations, maintenance, parts supply chain, etc.

§  Unconvincing business models (2)

Many still think that collecting Data will, sooner or later, become an asset. Usually, it comes with little care to Privacy or regulations. Collecting Data just because it may be monetised in the future will basically become a liability.

§  Unconvincing business models (3)

The skill set of most IoT companies is ill-incentivised in my opinion. Hardware and front-end skills are only an enabler. Managing data, the product lifecycle and the supply chain is the right direction.

§  Lack of killer applications.

Which is surprising. So far, the best is smart meters – do their job, clear use-case, helpful, fully managed, belonging to the operator and not the user.

§  Lack of interoperability between IoT

This will be a long lasting one and likely never truly solved. Combined with interoperability, lack of usability is also a problem once a certain level is passed. Even today using a printer is a problem and there are countless academic solutions to autoconfigure a printer. We all get jammed paper and “cannot find printer” far too often. Further, combining all the data from several things in order to deliver value is, and always will be, a hard problem (no shortage of academic papers on it).

§  Things are physically clumsy

Cables and chargers…