>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

Security Services Termsgiving a specialized field its due

I’ve long been on the lookout for a chance to work with a top-level computer security professional on contract terms tailored for security work. Recently I got just that chance with Christopher Allen, co-author of the TLS standard, through Blockchain Commons. Christopher and Blockchain Commons publish their organizational as well as technical work online, including the new contract terms. Have a look.

The terms were written to be read, and not just by lawyers. Christopher prefers plain English, and so do I, because it means more of the people actually involved in the deal—security pros and their clients—can and feel welcome to read, understand, and feed back. If you buy or sell security-related services, and especially if you do security reviews for hire, Christopher and I would definitely welcome your thoughts, on GitHub or by e-mail.

From a legal point of view, responsible security-related post peculiar problems when it comes to disclosure, for both sides.

On the researcher side, warranties around security-related work are often specially written, or even specially negotiated. The models, reports, and other analyses those warranties apply to might be destined for publication, or they might be for client eyes only. In some cases, client and researcher might agree to publication either with or without attribution. Where a researcher or firm has an established name or track record, they may insist on more time for published reports that will bear their seal of approval.

On the client side, typical confidentiality terms also conflict with best practices for vulnerability disclosure. Frequently security researchers find problems in client systems that trace back to problems in subsidiary systems, like software libraries, frameworks, and protocols. As a matter of enlightened self-interest, clients want those problems reported back to the maintainers of the affected subsystems on which they rely. Reporting means disclosure, but not of everything about the system the researcher was hired to audit, or even the researchers relationship with the client. Those details may or may not be fit for public consumption. So disclosure has to be limited to just enough information for those receiving disclosure to patch their subsystem, thus protecting the client’s project and security goals.

Of course, security work of all kinds rubs up against other aspects of the law, too. Especially alarming to researchers, what looks like a helpful professional hint from their point of view can look instead like a shakedown or an attempt to compromise important systems from another, especially to those not versed in the security side of the industry. When researchers make their findings available to vendors and maintainers, especially vendors and maintainers that aren’t their clients, they need reassurance that their reports will be welcome. But those on the receiving end, for their part, need researchers to communicate their reports responsibly, too. The state of the art in disclosure policies that respect and balance interests on both sides, as well as the protection of the public and its data, is ever changing. Our legal terms can’t fall behind.

Finally, security pros of course share some of the same concerns as other kinds of developers, especially open-leaning developers. As an example, where software contractors often have go-to open source libraries and frameworks, as well as “shelf code” and common assets they reuse across client projects, security researchers often develop files of boilerplate, diagrams, templates, and other work that helps them deliver quality reports efficiently. In both cases, it’s important to make sure intellectual property and other terms make workable distinctions between what clients pay to own and what those working on contract develop as part of the toolkit of their craft, or draw from the commons.

No set of legal terms is perfect, not for any given time in its industry, and certainly not for all time. But I’m proud and happy to say that the terms Christopher and I produced for Blockchain Commons come closer for this very urgently needed kind of work than any I’ve seen so far. I have been looking. And I look forward to improving them over time, and seeing them improved by others.

The public deserves secure, vetted software and software systems. The people doing the work, and the companies wise enough to pay for it, need and deserve engagements that facilitate peak performance, fair remuneration, and maximum leverage from specialized knowledge and skills. I’m proud to do my part to help them, with modern, readable, and open legal terms.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history