Long-time Open Source and Linux bod, distributed systems security, etc.. Founder of P2P Consulting.
マイク・バーゼル：
オープンソースとLinuxに長く従事。他にも分散セキュリティシステムなども手がける。
I had previously been (woefully) unaware of the opportunities for abusing various naming systems
(NOTE: this post deals with a particular company, and though they didn’t sponsor it, I was the grateful recipient of some excellent swag from them at an industry conference, and promised to write an article as thanks!)
A year ago, I visited RSA Conference North America in San Francisco. This was far from my first trip to RSA, which is one of the great (and probably the biggest) global security conferences. There’s a huge exhibitor hall – in fact, several – and many people attend just this, rather than the full conference. I always make a point of having a look at all of the different booths to see if there are any new companies or organisations in the areas that interest me or to find out about things I was previously unaware of. There are people using all kinds of incentives to try to get you to pay attention to them, from food to magicians, from give-away swag to prizes. I’d been doing a lot of walking around and was tired, and happened to discover quite a large booth which had some little seats to sit on. The deal, of course, was the if you sat down, you had to listen to the company pitch – and at the end, they’d do a prize draw and you might win something fun.
At it happened, I’d not heard of the company before and didn’t really have much interest in what they seemed to be talking about – DNS security, it looked like – but I really needed to rest my feet, so I sat down and reminded myself that I had a chance of winning something, even if the subject was as boring as many of the pitches I’ve heard over the years.
It turned out not to be. The company was Infoblox and, to my surprise, I went back several times to find out more about what they do and the research they publish. I went back even after I’d managed to secure one of their prizes, what they do is specialise in an area which I had previously known almost nothing about. On leaving the conference, I promised to write a blog post about what they do, as a gesture of thanks. And I realised as I was preparing to travel to RSA this year (it starts next week, at time of writing) that I’d never fulfilled my promise, and was feeling about it, so this is the post, to assuage my guilt and maybe to prompt you, my dear reader, into finding out more about network security solutions, or what they call DDI (DNS, DHCP, and IPAM) management.
Most companies at exhibitions and conferences spend most of their time telling you about their products, but Infoblox took a different approach – which I heartily recommend to anyone in a similar situation. Rather than just pitching their products and services, they presented the research that they do into the various vulnerabilities, bad actors, criminal traffic distribution systems (TDS) and rest. They had the researchers talking about the work, and made them available after the brief pitch for further questions. Did they mention their products and services? Well, yes, but that wasn’t the main thrust of the presentations. And the presentations were fascinating.
I had previously been (woefully) unaware of the opportunities for abusing the configuration and control of the various naming systems around which our digital lives revolve. I suppose that if I’d thought about it, I might have realised that there would be bad actors messing with these, but the extent to which criminal – and state-sponsored – actors are using these systems shocked me, if only because it’s an area of security that I’d hardly thought about in the 30 or so years that I’ve been in the field. Criminal gangs hijack domains, trick users, redirect traffic and sometimes camp out for years in quiet areas of the Internet, ready to deploy exploits when the rewards seem worthwhile enough. I’ve written over the years about attackers “playing the long game” and biding their time before employing particular techniques or exploiting specific vulnerabilities, but the sheer scale of these networks honestly astounded me. I can’t do justice to this topic, and the very best I can offer is to suggest that you have a look at some of the research that Infoblox provides. They do, of course, also provide services to help you protect your organisation from these threats and to mitigate the risks that you are exposed to, but as I’m not an expert in this particular area, I don’t feel qualified to comment on them: I recommend that you investigate them yourself. All I can say is that if Infoblox do as thorough and expert job around the services they provide as they do in their research activities, then they’re definitely worth taking seriously.
Technologies, when combined, sometimes yield fascinating – and commercially exciting – results.
Mike Bursell
Sponsored by Super Protocol
Introduction
One of the things that I enjoy the most is taking two different technologies, accelerating them at speed and seeing what comes out when they hit, rather in the style of a particle physicist with a Large Hadron Collider. Technologies which may not seem to be obvious fits for each other, when combined, sometimes yield fascinating – and commercially exciting – results, and the idea of putting Web3 and Confidential Computing together is certainly one of those occasions. Like most great ideas, once someone explained it to me, it was a “oh, well, of course that’s going to make sense!” moment, and I’m hoping that this article, which attempts to explain the combination of the two technologies, will give you the same reaction. I’ll start with an introduction to the two technologies separately, why they are interesting from a business context, and then look at what happens when you put them together. We’ll finish with more of a description of a particular implementation: that of Super Protocol, using the Polygon blockchain.
Business context
Introduction to the technologies
In this section, we look at blockchain in general and Web3 in particular, followed by a description of the key aspects of Confidential Computing. If you’re already an expert in either of these technologies, feel free to skip these, of course.
Blockchain
Blockchains offer a way for groups of people to agree about the truth of key aspects of the world. They let people say: “the information that is part of that blockchain is locked in, and we – the other people who use it and I – believe that is correct and represents a true version of certain facts.” This is a powerful capability, but how does it arise? The key point about a blockchain is that it is immutable. More specifically, anything that is placed on the blockchain can’t be changed without such a change being obvious to anybody with access to it. And another key point about many blockchains is that they are public – that is, anybody with access to the Internet and the relevant software is able to access them. Such blockchains are sometimes called “permissionless”, in juxtaposition to blockchains to which only authorised entities have access, which are known as “permissioned”. In both cases, the act of putting something on a blockchain is very important – if we want to view blockchains as providing a source of truth about the world – then the ability to put something onto the blockchain is a power that comes with great responsibility. The various consensus mechanisms employed vary between implementations but all of them aim for consensus among the parties that are placing their trust in the blockchain, a consensus that what is being represented is correct and valid. Once such a consensus has been met a cryptographichash is used to seal the latest information and anchor it to previous parts of the blockchain, adding a new block to it.
While this provides enough for some use cases, the addition of smart contracts provides a new dimension of capabilities. I’ve noted before that smart contracts aren’t very well named (they’re arguably neither smart nor contracts!), but what they basically allow is for programs and their results to be put on a blockchain. If I create a smart contract and there’s consensus that it allows deterministic results from known inputs, and it’s put onto the blockchain, then that means that when it’s run, if people can see the inputs – and be assured that the contract was run correctly, a point to which we’ll be returning later in this article – then they will happy to put the results of that smart contract on the blockchain. What we’ve just created is a way to create data that is known to be correct and valid, and which we can be happy to put directly on the blockchain without further checking: the blockchain can basically add results to itself!
Web3
Blockchains and smart contracts, on their own, are little more than a diverting combination of cryptography and computing: it’s the use cases that make things interesting. The first use case that everyone thinks of is crypto-currency, the use of blockchains to create wholly electronic currencies that can be (but don’t have) divorced from centralised government-backed banking systems. (Parenthetically, the fact that the field of use and study of these crypto-currencies has become known to its enthusiasts as “crypto” drives most experts in the much older and more academic field of cryptology wild.)
There are other uses of blockchains and smart contracts, however, and the one which occupies our attention here is Web3. I’m old (I’m not going to give a precise age, but let’s say early-to-mid Gen X, shall we?), so I cut my professional teeth on the technologies that make up what are now known as Web1. Web1 was the world of people running their own websites with fairly simple static pages and CGI interactions with online databases. Web2 came next and revolves around centralised platforms – often cloud-based – and user-generated data, typically processed and manipulated by large organisations. While data and information may be generated by users, it’s typically sucked into the platforms owned by these large organisations (banks, social media companies, governments, etc.), and passes almost entirely out of user control. Web3 is the next iteration, and the big change is that it’s a move to decentralised services, transparency and user control of data. Web3 is about open protocols – data and information isn’t owned by those processing it: Web3 provides a language of communication and says “let’s start here”. And Web3 would be impossible without the use of blockchains and smart contracts.
Confidential Computing
Confidential Computing is a set of technologies that arose in the mid 2010s, originally to address a number of the problems that people started to realise were associated with cloud computing and Web2. As organisations moved their applications to the cloud, it followed that the data they were processing also moved there, and this caused issues. It’s probably safe to say that the first concerns that surfaced were around the organisations’ own data. Keeping financial data, intellectual property, cryptographic keys and the like safe from prying eyes on servers operated in clouds owned and managed by completely different companies, sometimes in completely different jurisdictions, started to become a worry. But that worry was compounded by the rising tide of regulation being enacted to protect the data not of the organisations, but of the customers who they (supposedly) served. This, and the growing reputational damage associated with the loss of private data, required technologies that would allow the safeguarding of sensitive data and applications from the cloud service providers and, in some cases, from the organisations who “owned” – or at least processed – that data themselves.
Confidential Computing requires two main elements. The first is a hardware-based Trusted Execution Environment (TEE): a set of capabilities on a chip (typically a CPU or GPU at this point) that can isolate applications and their data from the rest of the system running them, including administrators, the operating system and even the lowest levels of the computer, the kernel itself. Even someone with physical access to the machine cannot overcome the protection that a TEE provides, except in truly exceptional circumstances. The second element is remote attestation. It’s all very well setting up a TEE on a system in, say, a public cloud, but how can you know that it’s actually in place or even that the application you wanted to load into it is the one that’s actually running? Remote attestation addresses this problem in a multi-step process. There are a number of ways to manage this, but the basic idea is that the application in the TEE asks the CPU (which understands how this works) to create a measurement of some or all of the memory in the TEE. The CPU does this, and signs this with a cryptographic key, creating an attestation measurement. This measurement is then passed to a different system (hence “remote”), which checks it to see if it conforms to the expectations of the party (or parties) running the application and, if it does, provides a verification confirms that all is well. This basically allows a certificate to be created that attests to the correctness of the CPU, the validity of the TEE’s configuration and the state of any applications or data within the TEE.
With these elements – TEEs and remote attestation – in place, organisations can use Confidential Computing to prove to themselves, their regulators and their customers that no unauthorised peeking or tampering is possible with those sensitive applications and data that need to be protected.
Combining blockchain & CC
One thing – possibly the key thing – about Web3 is that it’s decentralised. That means that anyone can offer to provide services and, most importantly, computing services, to anybody else. This means that you don’t need to go to one of the big (and expensive) cloud service providers to run your application – you can run a DApp (Decentralised Application) – or a standard application such as a simple container image – on the hardware of anyone willing to host it. The question, of course, is whether you can trust them with your application and your data; and the answer, of course in many, if not most, use cases, is “no”. Cloud service providers may not be entirely worthy of organisations’ trust – hence the need for Confidential Computing – but at least they are publicly identifiable, have reputations and are both shameable and suable. It’s very difficult to say the same about in a Web3 world about a provider of computing resources who may be anonymous or pseudonymous and with whom you have never had any interactions before – nor are likely to have any in the future. And while there is sometimes scepticism about whether independent actors can create complex computational infrastructure, we only need look at the example of Bitcoin and other cryptocurrency miners, who have built computational resources which rival those of even the largest cloud providers.
Luckily for Web3, it turns out that Confidential Computing, while designed primarily for Web2, has just the properties needed to allow us to build systems that do allow us to do Web3 computing with confidence (I’ll walk through some of the key elements of one such implementation – by Super Protocol – below). TEEs allow DApps to be isolated from the underlying hardware and system software and remote attestation can provide assurances to clients that everything has been set up correctly (and a number of other properties besides).
Open source
There is one important characteristic that Web3 and Confidential Computing share that is required to ensure the security and transparency that is a key to a system that combines them: open source software. Where software is proprietary and closed from scrutiny (this is the closed from which open source is differentiated), the development of trust in the various components and how they interact is impossible. Where proprietary software might allow trust in a closed system of actors and clients who already have trust with each other – or external mechanisms to establish it – the same is not true in a system such as Web3 whose very decentralised nature doesn’t allow for such centralised authorities.
Open source software is not automatically or by its very nature more secure than proprietary software – it is written by humans, after all (for now!), and – but its openness and availability to scrutiny means that experts can examine it, check it and, where necessary, fix it. This allows the open source community and those that interact with it to establish that it is worthy of trust in particular contexts and use cases (see Chapter 9: Open Source and Trust in my book for more details of how this can work). Confidential Computing – using TEEs and remote attestation – can provide cryptographic assurances not only the elements of a Web3 system are valid and have appropriate security properties, but also that the components of the TEE itself do as well.
Some readers may have noted the apparent circularity in this set-up – there are actually two trust relationships that are required for Confidential Computing to work: in the chip manufacturer and in the attestation verification service. The first of these is unavoidable with current systems, while the other can be managed in part by performing the attestation oneself. It turns out that allowing the creation of trust relationships between mutually un-trusting parties is extremely complex, but one way that this can be done is what we will now address.
Super Protocol’s approach
Super Protocol have created a system which uses Confidential Computing to allow execution of complex applications to be made within a smart contract on the blockchain and for all the parties in the transaction to have appropriate trust in the performance and result of that execution without having to know or trust each other. The key layers are:
Client Infrastructure, allowing a client to interact with the blockchain, initiate an instance and interact with it
Blockchain, including smart contracts
Various providers (TEE, Data, Solution, Storage).
Central to Super Protocol’s approach are two aspects of the system: that it is open source, and that remote attestation is required to allow the client to have sufficient assurance of the system’s security. Smart contracts – themselves open source – allow the resources made available by the various actors and combined into an offer that is placed on the blockchain and is available to anyone with access to the blockchain – to execute it, given sufficient resources from all involved. What makes this approach a Web3 approach, and differentiates it from a more Web2 system, is that none of these actors needs to be connected contractually.
Benefits of This Approach
How does this approach help? Well, you don’t need to store or process data (which may be sensitive or just very large) locally: TEEs can handle it, providing confidentiality and integrity assurances that would otherwise be impossible. And communications between the various applications are also encrypted transparently, reducing or removing risks of data leakage and exposure, without requiring complex key management by users, but keeping the flexibility and exposure offered by decentralisation and Confidential Computing.
But the step change that this opens up is the network effect enabled by the possibility of building huge numbers of interconnected Web3 agents and applications, operating with the benefits of integrity and confidentiality offered by Confidential Computing, and backed up by remote attestation. One of the recurring criticisms of Web2 ecosystems is their fragility and lack of flexibility (not to mention the problems of securing them in the first place): here we have an opportunity to create complex, flexible and robust ecosystems where decentralised agents and applications can collaborate, with privacy controls designed in and clearly defined security assurances and policies.
Technical details
In this section, I dig a little further into some of the technical details of Super Protocol’s system. It is, of course, not the only approach to combining Confidential Computing and Web3, but it is available right now, seems carefully architected and designed with security foremost in mind and provides a good example of the technologies and the complexities involved.
You can think of Super Protocol’s service as being in two main parts: on-chain and off-chain. The marketplace, with smart contract offers, sits on an Ethereum blockchain, and the client interacts with that, never needing to know the details of how and where their application instance is running. The actual running applications are off-chain, supported by other infrastructure to allow initial configuration and then communication services between clients and running applications. The “bridge” between the two parts, which moves from an offer to an actual running instance of the application, is a component called a Trusted Loader, which sets up the various parts of the application and sets it running. The data it is managing contains sensitive information such as cryptographic keys which need to be protected as they provide security for all the other parts of the system and the Trusted Loader also manages the important actions of hash verification (ensuring that what is being loaded what was originally offered) and order integrity (ensuring that no changes can be made whilst the loading is taking place and execution starting).
Trusted Loader – configuration and deployment with Data and Application information into TEE instance
But what is actually running? The answer is that the unit of execution for an application in this service is a Kubernetes Pod, so each application is basically a container image which is run within a Pod, which itself executes within a TEE, isolating it from any unauthorised access. This Pod itself is – of course! – measured, creating an attestation measurement that can now be verified by clients of the application. We should also remember that the application itself – the container image – needs protection as well. This is part of the job of the Trusted Loader, as the container image is stored encrypted, and the Trusted Loader has appropriate keys to decrypt this and other resources required to allow execution. This is not the only thing that the Trusted Loader does: it also gathers and sets up resources from the smart contract for networking and storage, putting everything together, setting it running and connecting the client to the running instance.
There isn’t space in this article to go into deeper detail of how the system works, but by combining the capabilities offered by Confidential Computing and a system of cryptographic keys and certificates, the overall system enforces a variety of properties that are vital for sensitive, distributed and decentralised Web3 applications.
Decentralised storage: secrets are kept in multiple places instead of one, making them harder to access, steal or leak.
Developer independence: creators of applications can’t access these secrets, continuing the lack of need for trust relationships between the various actors. In other words, each instance of an application is isolated from its creator, maintaining data confidentiality.
Unique secrets: Each application gets its own unique secrets that nobody else can use or see and which are not shared between instances.
Thanks
Thanks to Super Protocol for sponsoring this article. Although they made suggestions and provided assistance around the technical details, this article represents my views, the text is mine and final editorial control (and with it the blame for any mistakes!) rests with the author.
Just six months ago, I started a YouTube channel, What is cybersecurity?, to provide short videos (most are under 4 minutes and all are currently well under 10 minutes) discussing topics and issues in cybersecurity. I’ve spent 25+ years in the field (well before anyone called it “cybersecurity”) and had been wondering how people get into it these days. In particular, I’m aware that not everyone processes information in the same way, and that for many people, short video content is there preferred way of gaining new knowledge. So I decided that this was what I’d do: create short videos, publish frequently and see how it went.
To celebrate this, here’s a post describing various aspects of the process.
Methodology
I thought it might be interesting to people to understand how I’ve gone about choosing the topics for videos. When I decided to do this, I created a long list of topics (the initial list was over 150) and realised very early on that I was going to have to start with simple issues and build up to more complicated ones if I wanted to be able to address sophisticated concepts. This meant that I’ve started off with some of the basic building blocks in computing which aren’t specifically security-related, just because I wanted to be able to provide basic starting points for people coming to the field.
I was slightly concerned when I started that I’d run out of ideas for topics: this hasn’t been a problem, and I don’t expect it to be any time in the future. Currently, with 100 videos published, I have over 250 topics that I want to cover (which I haven’t recorded yet). Whenever I come across a topic or concept, I add it to the list. There are few books that I mine for ideas, of which the most notable are:
Trust in Computer Systems and the Cloud – Mike Bursell (my book!)
Security Enginineering (3rd edition) – Ross Anderson
CISSP Exam Guide (9th edition) – Fernando Maymi, Shon Harris
As mentioned above, the videos are all short, and, so far, they’re all single-takes, in that each is a single recording, without editing pieces together. That doesn’t mean that I don’t have to re-record quite frequently – I’d say, on average, that 50% of videos require two or more takes to get right.
Audience
Who do I expect to be my audience? These are the personae that I’ve targeted to start with:
undergraduates reading Computer Science or similar, with an interest in cybersecurity
masters students looking to move into cybersecurity
computing professionals wanting more information on specific cybersecurity topics
managers or professionals in non-computing roles looking for a definition or explanation of a particular term
(after looking at UK students) A level students in Computer Science
Playlists
YouTube encourages you to create playlists to help people find related topics on your channel. These are the playlists that I currently have (I expect to create more as I get into more complex topics):
Cybersecurity concepts compared takes two or more topics and draws out the differences (and similarities). There are so many complex topics in cybersecurity which are really close to each other and it’s not always easy to differentiate them.
Camera: Razer Kiyo Pro (though currently I’m trying out a Sony ZV-E10, which provides lovely video, but requires a 175ms audio delay due to USB streaming processing performance)
” Thank you, I have a test tomorrow and you helped clear things up!”
As I mentioned in my last article on this blog, I’ve started a YouTube channel called “What is cybersecurity?” aimed at people wanting to get into cybersecurity or looking to understand particular topics for professional reasons (or personal interest). So far, the most popular video is “What is encapsulation?“. I was delighted to get a comment on it from a new subscriber saying “Thank you, I have a test tomorrow and you helped clear things up!”. This is exactly the sort of use to which I’ve been hoping people will put my channel videos.
Since I launched the channel, I’ve been busy recording lots of content, applying some branding (including thumbnails, which make a huge difference to how professional the content looks), scheduling videos and trying to get my head around the analytics available.
I have to say that I’m really enjoying it, and I’m going to try to keep around a month’s content ready to go in case I’m unable to record things for a while. In order to get a decent amount of content up and provide an underlying set of information, I’m aiming for around 3 videos a week for now, though that will probably reduce over time.
For now, I’m concentrating on basic topics around cybersecurity, partly because every time I’m tempted to record something more complex, I realise how many more basic concepts it’s going to rely on. For example, if I want to record something on the CIA triad, then being able to refer to existing content on confidentiality, integrity and availability makes a lot of sense, given that they’re building blocks which it’s helpful to understand before getting your head around what the triad really represents and describes.
As well as single topic videos, I’m creating “What’s the difference…?” videos comparing two or three similar or related topics. There are so many topics that I remember being confused about, or still am, and have to look up to remind myself. I try to define the topics in separate videos first and then use the “What’s the difference…” video as a comparison – then people can refer to the stand-alone topic videos to get the specifics if they need them.
So, it’s early days, but I’m enjoying it. If you are interested in this topic or if you know people who might be, please do share the channel with them: it’s https://youtube.com/@trustauthor. Oh, and subscribe! I also want suggestions for topics: please let me know what questions or issues you think I should be covering.
I’ve been a little quiet here recently, and that’s a result of a number of events coinciding, including a fair amount of travel (hello Bilbao, hello Shanghai!), but also a decision I made recently to create a YouTube channel. “Are there not enough YouTube channels already?” you might reasonably ask. Well yes, there are lots of them, but I’ve become increasingly aware that there don’t seem to be any which provide short, easy-to-understand videos covering the basics of cybersecurity. I’m a big proponent of encouraging more people into cybersecurity, and that means that there need to be easily-found materials that beginners and those interested in the field can consume, and where they can ask for more information about topics that they don’t yet understand. And that’s what seems to be missing.
There are so many different concepts to get your head around in cybersecurity, and although I’ve been running this blog for quite a while, many of the articles I write are aimed more at existing practitioners in the field. More important than that, I’m aware that there’s a huge potential audience out there of people who prefer to consume content in video format. And, as any of you who have actually met me in real life, or seen me speak at conferences, I enjoy talking (!) and explaining things to people.
So my hopes are three-fold:
that even if the channel’s current content is a little basic for you now, as I add more videos, you’ll find material that’s useful and interesting to you;
that you’ll ask questions for me to answer – even if I don’t post a response immediately, I’ll try to get to your topic when it’s appropriate;
that you’ll share the channel widely with those you work with: we need to encourage more people to get involved in cybersecurity.
So, please subscribe, watch and share: What is cybersecurity? And I’ll try to keep interesting and useful content coming.
This is not just an issue for the UK: if our government gets away with it, so will others.
I recently wrote an article (E2E encryption in danger (again) – sign the petition) about the ridiculous plans that the UK government has around wanting to impose backdoors in messaging services, breaking end-to-end encryption. In fact, I seem to have to keep writing articles about how stupid this is:
You shouldn’t just take my word about how bad an idea this is: pretty much everyone with a clue has something to say about it (and not in a good way), including the EFF.
One of the arguments that I’ve used before is that data leaks happen. If you create backdoors, you can expect that the capabilities to access those backdoors and the data that you’ve extracted using those backdoors will get out.
How do we know that this is the case? Because government agencies – including (particularly…?) Law Enforcement Agencies – are always losing sensitive data. And by losing, I don’t just mean having people crack their systems and leaking them, but also just publishing them by accident.
“Surely not!” you’re (possibly) saying. “Of all the people we should be trusting to keep sensitive data safe, the police and other LEAs must be the best/safest/most trustworthy?”
But that was the US, and nothing like that would happen in the UK, right? I offer you four (or five, depending on how you count) counter-examples, all from the past few months.
I’m not saying that our police forces are incompetent or corrupt here. But as everyone in the IT security (“cybersecurity”) business knows, attacks and data loss are not a matter of “if”, they are a matter of “when”. And once it’s out, data stays out.
We must not allow these changes to be pushed through by governments. This is not just an issue for the UK: if our government gets away with it, so will others. Act now.
Having a budget assigned and time set aside for patent creation and filing should be an important part of your company strategy.
To learn more about creating and applying for patents, please visit my consultancy, P2P Consulting, for more detail about how we can help you.
Disclaimer: I’m not a lawyer! Don’t treat any of this article as legal advice: always consult your legal counsel for legal matters.
When I was fund-raising for our start-up (just a couple of years ago at time of writing), one of the questions that frequently came up was “what about IP”? For the techies amongst my readership, this isn’t “Internet Protocol”, but “Intellectual Property”, and, for most start-ups, what the question really meant was “do you have any patents to protect your business idea and the technology behind it?”. When the question wasn’t forthcoming, I would always raise it myself, because, as it happened, we did have a good story around Intellectual Property.
Unlike many other start-ups, it turns out.
There are four types of Intellectual Property, which we can list thus, including their relevance to start-ups (I’m concentrating on software start-ups, as they situation is somewhat different for different approaches):
Copyright – protects the implementation and expression of code
Trademarks – protect things like your logo and colour scheme
Patents – protect the functionality of the code
Trade secrets – have to be protected through secrecy, NDAs, etc.
If you decide that you need to do more than just rely on trade secrets (which are all very well for soft drink recipes and things which can’t be reverse engineered, but aren’t great for software), and you’re more interested in the software side of IP than trademarks, that leaves two key types: copyright and patents. People get these confused, and although I’m not a lawyer (see disclaimer above…), the way I understand the difference is this: copyright just protects the bits and bytes of the code in the way that it’s written, whereas a patent protects what it does. A competent engineer can look at your code (or its effects, sometimes) and rewrite it (in another language, using different patterns, using subtly different processes) to get the same effects, so copyright doesn’t really help here. A patent protects you from someone implementing the same effects – or, more accurately, the processes, methods and mechanisms that you use to create these effects – and this is almost always the type of protection you want.
What can you patent?
Now, you can’t just patent anything, and there are actually differences between what you can patent depending on the authority granting the patent (the US patent authorities’ rules differ from those of the European Union, for instance), but a couple of rules of thumb are useful as starting points:
you can’t generally patent mathematical equations or algorithms;
you can’t patent business processes.
What you generally can patent (depending on your jurisdiction, etc.) are processes and mechanisms that would be difficult or impossible for humans to do on their own and which also make or cause changes to external systems (such as causing things to happen in the physical world).
Another important test is that the idea should be both novel and also not immediately obvious to someone skilled in the art. This is often a lower bar than most engineers think, it turns out: once an idea is explained to you, it often feels obvious, but that doesn’t mean it was to start with!
What should I patent?
Subject to the points mentioned above, you can patent pretty much anything you want, but it probably doesn’t make sense to patent everything you come up with: if you’re in the AI business, then patenting an idea around 3D printing for efficient traffic lights probably isn’t sensible (unless your AI is great at CAD/CAM, maybe). The patent process is resource-intensive (typically consuming the time and effort of senior engineers and staff who you’d prefer to be spending their time on getting your product or service out of the door) and fairly expensive. You should work on a strategy to decide what is key to your business now, what is likely to be key in the future, what might help you in possible technical or business pivots and what might protect you from competitors now and in the future. The exact priorities between those will vary from company to company, but understanding these – and having a budget assigned and time set aside for patent creation and filing should be an important part of your company strategy.
When can you patent?
The obvious answer is “as soon as you have the idea” – you absolutely don’t need to have an implementation of it. Beyond that, things vary (again) between jurisdictions. Generally, good advice is to apply for a patent before you disclose anything about the idea to anyone else via an academic paper, GitHub repository, conference session, LinkedIn post or similar (though conversations under NDA should generally be OK). For US patents, you generally have a year after first disclosure, but in other jurisdictions, you don’t, so be careful!
Why should I patent?
The best answer, I think, is “to protect your core business” – aligned, therefore, with the answer to your answers to the questions “what should I patent” above. Some key reasons that people create patents include:
Company valuation
Defensive / fight back
License/sell
Market/partner
Sue
Offensive use of patents is unlikely for start-ups, but all the others can be very useful, even if licensing or selling them may seem like a way down the road for many early stage companies. The two which are likely to be most interesting for early stage companies are valuation and defensive. Showing that your company has real ideas (which are, what’s more, protected by law) is a great signal of value for almost any type of exit. On the other hand, if there are companies out there who threaten you, alleging that you are impinging on their space and ideas, being able to say “we have a patent in this area, back off”, can seriously reduce the amount of time and money that you spend on lawyers. And that makes everyone happy (apart, maybe, for the lawyers).
There are sometimes reasons that people are reluctant to apply for patents. These include a lack of knowledge of the process (which this article is hopefully addressing), a decision to protect trade secrets instead and moral qualms around the whole question of whether software should be patented at all. Many of those concerned about this last point worry about “patent trolls” and the techniques they use to attack and restrict expression of ideas, particularly in open source. Luckily, there are some very good models and organisations designed to address exactly this point: if you want more information, I strongly advise reading up about the Open Invention Network, the LOT Network and Red Hat Patent Promise.
How should I start?
I plan to write more articles on how to get started with patents, but there are three steps that I’d strongly advise all start-ups to consider as soon as they are able:
consider an IP strategy, and discuss it at the Board level (this will, I promise, send good signals to your investors!).
set time aside every few weeks to discuss possible patent ideas and record the idea, the date it was created, and who was involved in its invention. This is important information that you’ll need when you do start the patenting process.
think hard before sharing any important, business-critical technical information externally, as disclosure may hinder your ability to patent it in the future. You should talk to all your employees about this (not just the techies!).
The other thing you can do, of course, is talk to an expert in patent creation (often called “harvesting”) and filing. Intellectual Property lawyers specialise in the latter part of the process, but the actual creation and preparation of ideas in such a way that lawyers can efficiently help move you through the filing process (sometimes called, somewhat scarily, “prosecution”) is a different set of skills. This part of the process is something I’m very happy to help you through my consultancy P2P Consulting: do get in touch for more details.
Towards the end of April this year (2023), I joined the Confidential Computing Consortium as the Executive Director, and I thought it might be interesting to reflect on what that means. I’ve been involved with the CCC since its foundation in October 2019: in fact, I was one of those who helped shape it and move it to foundation from its inception a few months earlier. I have, at various times, acted as the Red Hat (Premier Member) representative on the Governing Board, project representative for Enarx, Treasurer, member as part of Profian, and General Member representative before a brief period of a couple of months as we closed down Profian where I wasn’t involved. I’ve spoken for the CCC at conferences, staffed booths, written blog posts, contributed to white papers, helped commission a market report, recruit members and pretty much everything else that is involved in a Linux Foundation project. It’s been a fairly large part of my professional life for approaching four years.
So I was very happy to be invited to become invited to apply to be Executive Director, a position that had been mooted while I was still involved in the consortium, but which I’d had no expectation of being approached about. But what does an Executive Director do? I don’t see any reason not to share a cut-down version of the role description as per the contract (redacted just for brevity, and not any reasons of confidentiality):
Attending events, speaking, providing booth presence, etc.
Blogging as appropriate, participating in podcasts, etc. to raise awareness about the CCC and its mission.
Engage premier and general members to encourage involvement and solicit feedback, helping the governing board set goals and milestones if appropriate, and generally taking the pulse of the organization from the members’ perspective.
Recruit new membership from relevant organizations.
Recruit new projects to the CCC.
Attend Governing Board meetings and report on work to date and plans for the next period. Report out via simple slides for the governing board presentation.
This is a short but very broad brief and it raises the question: does an Executive Director direct things (are they foremost a manager?) or execute things (are they foremost a task performer?)?
The answer, of course, will vary from organisation to organisation and I know that is true even between the Executive Directors for different Linux Foundation projects, but for me, it’s a (sometimes uneasy) “both”. Member organisations are both blessed and plagued by the fact that, to start with, nothing gets done unless members’ employees do it. They need to arrange meetings, organise conference attendance, manage webinars, write white papers and all the rest. They may get some implementation help for some of these (the Linux Foundation, for example, has a number of functions which can provide help for particular specialist functions like marketing, research or project management), but most of it is run by the members and their employees. And then they get to the stage where they decide that they need some help at a senior level.
What does that person do? Well, here are some words that I think of when I consider my role:
support
chivy
encourage
recruit
explain
advertise
represent
engage
report
You’ll note that some of these are words that are about working with people or members (e.g. support, engage, encourage), whereas others are more about doing things (e.g. advertise, explain, represent). The former feel more like the “directing” part of the role and the latter feel more like the “executing” part of the role. Obviously, they’re not mutually incompatible, and some of the words can lean in both directions, which makes it even more clear to me that it’s hybrid role that I’m fulfilling.
Given my hybrid background (as a techie with business experience), this feels appropriate, and I need to keep ensuring that I balance the time I spend on different activities carefully: I can neither spend all my time on making technical comments on a draft report on GRC (governance, risk management and compliance) nor on considering recruitment options for new members in the Asia Pacific region. But at the same time, it feels sensible that, as someone tasked with having an overview of the organisation, I keep at least some involvement (or knowledge of) all the major moving parts.
It doesn’t change the fact, however, that things only really get done when members get involved, too. This is one of those areas where it’s entirely clear to me that I can only execute tasks to a certain level: this has to be a collaborative role, which frankly suits me and my management style very well. The extent to which I keep an eye on most things, and the balance of work between me, members and other functions of the organisation are likely to change as we continue to grow, but for now, I’m very much enjoying the work I’m doing (and the interactions with the people I’m doing it with) and juggling the balance of executing versus direction.
The more of these you adopt style, the more successful you’re going to be (at not being a good boss).
Dedicated to AB: who helped me get it right (the times that I did).
I’ve written “how not to” guides before (e.g. 7 tips on how not to write a book, 7 tips on how not to write a book, 7 tips on how not to write a book), but now that I’m not a boss anymore (after we closed down Profian earlier this year), I feel there’s enough space between when I was a boss and now for me to write my latest. I’m not pretending I was the best boss in the world (though one of my previous employees just sent me a mug saying “World’s Best Boss” – just sayin’), but I tried to model good behaviour and a healthy work environment. I had to work at this: it’s not my default place of comfort. So if I can get how you’re supposed to do it, then hopefully anyone can.
Note: please, please recognise that this is satire. Please.
1. Don’t ask how your employees are
Some people start off meetings with small talk. This is not what you want. They find out what participants have been up to, what they plan to do over the weekend, and other irrelevant “EQ” stuff like that. None of this is related to business and is a distraction from the work that your employees are paid to do. In fact, that you are paid (or pay yourself) to do. It’s a waste of time, and time is money, so it’s a waste of money, particularly when it’s your time and your money. You don’t need to know other people, their views of priorities to work with them or manage them. Give them tasks, get a move on.
2. Expect the same commitment from your employees that you put in
You may be paid more than everyone else (if you’re not, then why not? Fix that!), and the organisation for which you work is what defines you and everything about you, and this may not be true for everybody else you manage, but that’s no excuse for them not giving everything (their workday, their evenings, their weekends, their health – emotional, physical, spiritual, mental) for the company. That goes for the lowest paid to the highest paid employee (you). If they’re not giving it their all at all times, they don’t deserve a job. Get on with it.
3. Family? Friends? Pets? What do I care?
People get ill? Maybe. What’s that to do with me? You’re paid to do a job, and that job doesn’t include your taking time off to look after them. And certainly not pets. Pets aren’t even people. So they can’t be family. Ridiculous. They can make their own way to the doctor/vet. Oh, and by “taking time off”, I include evenings and weekends when you should be doing as I do and committing every last minute of your time to the company (see previous note).
4. Talk, don’t listen
You’ve been a junior person (unless Daddy/Mummy promoted you directly to where you are, in which case, well done), and so you know all of the important things: there’s nothing else that people need to teach you. This means that you can tell them what needs to happen, and if things don’t happen as they should, then that’s their fault for not paying sufficient attention to you and your words of wisdom – or just being too stupid to understand. In either case, disciplinary proceedings are likely to follow. And not for you, absolutely not.
5. Apportion blame, take credit
When things go wrong (which they often do – see above), then it’s not your fault. Make that clear. Spread blame. However, when things happen to go right, we all know who that’s down to, don’t we? You. Your leadership. Your vision. Your management. Even if you don’t actually know much about what went right, you can still take the credit. What a brilliant boss you are.
6. Keep information close to you
Most people don’t need to know things. Provide the very least that they need to do their jobs – or, preferably, even less than that: make them work it out themselves. If they need information, you have leverage. You can get them to work harder, or take on new tasks, or hold off from that raise that you’ve been dangling in front of them for the past 18 months. This is also useful when taking credit for things your team has done: if nobody else knows the details, there’s less chance that they’ll try to question you on it.
7. Expect telepathy
You can’t do everything. This is both a blessing and a curse, in that you have less control, but more free time (or time to do the things you find important, which is nearly the same thing, or should at least seem to be the same thing to your employees). This means that you have to delegate. There are four methods to delegate:
Research – get a subordinate to research options and report back so you can make a decision.
Updates – the subordinate does the work, reporting back to you as required across the duration of the tasks.
Done – the subordinate does the work, and tells you when it’s complete.
Exterminate – you hand the task completely over to the subordinate, to be completed or killed the task at their discretion, no need to inform you.
You’ll note that these form an acrostic: “RUDE”. This is because it would be rude of you to give any clues as to which of these models you expect when you tell someone do to a task. They should be able to work it out themselves telepathically and, again, the less information you give them, the more opportunities there are for it to be their fault when it goes wrong.
I hope this last of tips is useful for anyone wanting not to be a good boss. I can pretty much guarantee that the more of these you adopt in your management style, the more successful you’re going to be (at not being a good boss). Good luck!
A consulting practice reflecting the expertise and experience I’ve built up over the past 25+ years in the industry.
It’s been a few months since we decided to close down Profian, the start-up we created around the Enarx project, and I’ve been working on what my next steps should be. The first, and most obvious, is that I started a couple of months back as Executive Director for the Confidential Computing Consortium, part of the Linux Foundation. I’ve also got far too good at a number of online games – too embarrassing to list here. But the other thing that I’ve been working on is starting a consulting practice, reflecting the expertise and experience I’ve built up over the past 25+ years in the industry.
There are a number of services that I’m offering:
software patent strategy and harvesting
open source strategy
start-up strategy
VC and PE due diligence
cybersecurity
Some of them speak for themselves: I’ve been in what’s now called “cybersecurity” for over 20 years, and my previous role was as CEO and Co-founder of a start-up. I’ve also been involved in due diligence, which explains the Venture Capital and Private Equity offerings. I plan to write more about all of the offerings in future articles, but the other two – around software patents and open source strategy – probably deserve a little more detail at this point.
Here are the basic descriptions of these services – feedback is definitely welcome:
Intellectual property is a valuable resource for start-ups: for valuation, partnership and competitive advantage. Many start-ups know that they should be managing their Intellectual Property – in particular filing patents – but few have the skills or time to do so efficiently. P2P Consultancy runs in-person patent workshops to generate ideas (“harvesting”) and works with management on the appropriate company strategy, selecting harvested ideas that are best aligned. P2P Consultancy can then work through the process of taking each patent idea through the write-up, discussion and filing stages with patent lawyers, saving valuable staff time and helping the company internalise the skills and gain the experience needed to manage the process in future.
Patent strategy and harvesting
P2P Consulting offers services to companies looking to build a strong strategy for their involvement with open source projects and communities which is consistent with the commercial goals of the organisation. Mike Bursell, P2P Consulting’s founder, has been involved with open source strategy for over 15 years, in companies ranging from multi-nationals to start-ups, considering issues ranging from community growth and involvement to open source licensing decisions, intellectual property protection and go-to-market. P2P Consulting provides expertise and links in the open source ecosystem and insights into the opportunities and challenges associated with embracing open source as a strategic differentiator.
Open source strategy
I look forward to growing the consultancy alongside my other activities, and offering these services particularly to start-ups looking to consolidate their patent portfolios and expand their open source involvement. For queries, please visit the P2P Consulting LinkedIn page, the https://p2pconsulting.dev or email me at mike@p2pconsulting.dev.
Alice, Eve and Bob - a security blog 