What’s a blockchain “smart contract”? 

The first thing to know about blockchain smart contracts is they’re not contracts, smart or necessarily on a blockchain.

The first thing to know about blockchain smart contracts is they’re not contracts, smart or necessarily on a blockchain.  They are, in fact, singularly ill-named*.  Let’s address these issues in reverse order, and we should find out exactly what a smart contract actually is along the way.  First, and introduction to what transactions are, and things which aren’t transactions.

An intro to transactions and non-transactions

The best known blockchains are crypto-currencies like bitcoin**.  The thing about currencies – virtual or not – is that what you mainly want to do is buy or sell things using them.  What you want is a simple transaction model: “once I provide you with this service, you’ll give me this amount of currency.”  We know how this works, because every time we buy something in a shop or online, that’s what happens: the starting state is that I have x amount, and the state after completion of the transaction is that I have x-y amount, and you have y amount****.  It’s the moving from one state to another that you care about before you complete the transaction.  Most crypto-currencies are set up to support this type of construct.

This is great, but some clever people realised that there are actually many different ways to do this.  Ethereum was where non-transactional constructs made it big time, and Solidity is the best known example.  Both, I’m pleased to say, are open source projects.  Why not have a more complex set of conditions that need to be met before I hand over whatever it is that I’m handing over?  And – here’s the clever bit – why not write those in code that can be executed by computers?  You might want the currency – or whatever – only to be released after a certain amount of time, or if a stock price keeps within a particular set of boundaries, or if a certain person continues to be prime minister*****, or if there’s no unexpected eclipse within the next five days******.  You could have complex dependencies, too: only complete if I write a new post three weeks in a row and nobody writes unpleasant comments about any of them*******.  Write this code, and if the conditions are met, then you move to the next state.

Not just for blockchains

Let’s start addressing those “not” statements.

Now, in a blockchain, the important thing is that once the state has changed, you then ensure that it’s recorded on the blockchain so that it’s public and nobody can change or challenge it.  But there are other uses for blockchain technology, as I explained in Is blockchain a security topic?  Permissionless systems, often referred to as DLTs, or “Distributed Ledger Technologies” are a great fit for non-transactional state models, largely because the sort of people who are interested in them are closed groups of organisations who want to have complex sets of conditions met before they move to the next state.  These aren’t, by the tightest definition, blockchains.  Banks and other financial institutions may be the most obvious examples where DLTs are gaining traction, but they are very useful in supply chain sectors, for instance, where you may have conditions around changing market rates, availability and shipping times or costs which may all play into the final price of the commodity or service being provided.

Not that smart

Smart contracts could, I suppose, be smart, but for me, that means complex and able to react to unexpected or unlikely situations.  I think that people call them “smart” because they’re embodied in code, not for the reasons I’ve suggested above.

That’s actually a very good thing, I think, because I don’t think we want them to mean what I was talking out.  Most of the usages that I’m aware of for “smart contracts” are where two or more organisations agree on a set of possible outcomes of a system based on a set of known and well-constrained conditions.  This is what contracts are generally about, and although I’m about to argue with that part of the nomenclature as well, in this context it’s fairly apposite.  What you want, generally, is not unexpected or unlikely situations and smart processing in an AI/ML type way, because if you do, then the parties involved are likely to get outcomes that at least one or more of them are surprised, and likely unhappy, about.  Simple – or at least easily defined – is a key behaviour that you’re going to want built into the system.  The Solidity project, for example, seems aware of at least some of these pitfalls, and suggests that people employing smart contracts employ formal verification, but as we’ll see below, that just scratches the surface of the problem.

Not contracts

Of course, there are some contracts – IRL contracts – that exist to manage complex and unexpected conditions.  And they exist within a clear legal jurisdiction.  The words and phrases that make them up are subject to specific and well-defined processes, with known sanctions and punishments where the conditions of the contract are not met or are broken.  There are often instances where these are challenged, but again, clear mechanisms exist for such challenges.

For now, “smart contracts” just don’t fit this description of a contract.  Just mapping legal contractual wording to computer code is a very complex process, and the types of errors to which processing of code is prone don’t have a good analogue within the justice system.  There’s the question, as well, of what jurisdiction is relevant.  This is usually described in the contract terms, but what if the processing of the “smart contract” takes place in a different jurisdiction to that of the parties involved, or even in an unknown jurisdiction. Should this matter?  Could this matter?  I don’t know, and I also don’t know what other types of issue are going to crawl out of the woodwork once people start relying on these constructs in legally-enforceable ways, but I doubt they’re going to be welcome.

We’re not helped, as well, by the fact that when IT people talk about software contracts, they’re talking about something completely different: it’s the advertised behaviour of a system in the context of known inputs and starting conditions.

What has this got to do with security?

Once a transaction – or “smart contract” has completed, and made its way onto the blockchain or distributed ledger, it is immutable, pretty much by definition.  But what about before then?  Well, simple transactions of the type described at the beginning of this post are atomic – they happen or they don’t, and they are “indivisible and irreducible” to use the jargon.  They are, for most purposes, instantaneous.

The same is not true for “smart contracts”.  They require processing, and therefore exist over time.  This means that while they are being processed, they are subject to all the sorts of attacks to which any system may be vulnerable.  The standard list is:

  • C = confidentiality.  The state of a “smart contract” may be subject to snooping, which may lead to asymmetric knowledge or leakage to non-approved parties.
  • I = integrity.  This is the nightmare case for many “smart contracts”.  If an entity – whether a party to the underlying contract or not – can change the internal state of the code executing the “smart contract” intentionally or unintentionally, then the outcomes of that “smart contract” will not be as expected, and any of the parties involved may have good cause to dispute the outcome.  What’s more, such a dispute may not even depend on proof of loss of integrity, but just on suspicion.  Proving run-time integrity – let alone mitigating when it is shown to have been lost – is extremely difficult within an execution context.
  • A = availability.  If one party sees that the conditions associated with a “smart contract” are turning out to be unfavourable to them, then they might try to affect the availability of any part of the system the makes up the “smart contract”, whether the processing of the code itself, the inputs to the system or the outputs from the system.  Any of these might have a significant impact on the real-life outcomes.

So what?

This post started with what may have seemed to be a pedantic attack on a naming convention.  As I think will probably be clear********, I’m not comfortable with the phrase “smart contract”, and that’s mainly because I think it has caused some people to think that these constructs are things that they’re not.  This, in turn, is likely to mean that people will use them in contexts where they’re not appropriate.

I also worry that because the use of words means that they bring baggage with them, this will lead to people not fully thinking through the impact of security on these constructs.  And I think that the impact can be very major.   So, if you’re looking into these constructs, please do so with your eyes open.  I’ve not talked much in this article about mitigations, but some exist: keep an eye on future posts for more.

 


*I like to think that the late, lamented authors Terry Pratchett and Douglas Adams would both appreciate smart contracts for exactly this reason.

**the first thing you’ll find many bitcoin commentators saying is “I wish I’d bought in early: I’d be a multi-millionaire by now.”***

***I wish I’d bought in early: I’d be a multi-millionaire by now.

****less taxes or house cut.  Sorry – that’s just the way the world works.

*****or doesn’t.

******I’m not expecting one.  I’d tell you, honest.

*******this is not an invitation.

********if it isn’t by now, either you’ve not read this carefully enough, or I’ve done a bad job of explaining.  Try reading it again, and if that doesn’t help, write a comment and I’ll try to explain better.

 

 

What’s the point of security? 

Like it or not, your users are part of your system.

No, really: what’s the point of it? I’m currently at the Openstack Summit in Sydney, and was just thrown out of the exhibition area as it’s closed for preparations for an event. A fairly large gentleman in a dark-coloured uniform made it clear that if I didn’t have taken particular sticker on my badge, then I wasn’t allowed to stay.  Now, as Red Hat* is an exhibitor, and I’m our booth manager’s a buddy**, she immediately offered me the relevant sticker, but as I needed a sit down and a cup of tea***, I made my way to the exit, feeling only slightly disgruntled.

“What’s the point of this story?” you’re probably asking. Well, the point is this: I’m 100% certain that if I’d asked the security guard why he was throwing me out, he wouldn’t have had a good reason. Oh, he’d probably have given me a reason, and it might have seemed good to him, but I’m really pretty sure that it wouldn’t have satisfied me. And I don’t mean the “slightly annoyed, jet-lagged me who doesn’t want to move”, but the rational, security-aware me who can hopefully reason sensibly about such things. There may even have been such a reason, but I doubt that he was privy to it.

My point, then, really comes down to this. We need be able to explain the reasons for security policies in ways which:

  1. Can be expressed by those enforcing them;
  2. Can be understood by uninformed users;
  3. Can be understood and queried by informed users.

In the first point, I don’t even necessarily mean people: sometimes – often – it’s systems that are doing the enforcing. This makes things even more difficult in ways: you need to think about UX***** in ways that are appropriate for two very, very different constituencies.

I’ve written before about how frustrating it can be when you can’t engage with the people who have come up with a security policy, or implemented a particular control. If there’s no explanation of why a control is in place – the policy behind it – and it’s an impediment to the user*******, then it’s highly likely that people will either work around it, or stop using the system.

Unless. Unless you can prove that the security control is relevant, proportionate and beneficial to the user. This is going to be difficult in many cases.  But I have seen some good examples, which means that I’m hopeful that we can generally do it if we try hard enough.  The problem is that most designers of systems don’t bother trying. They don’t bother to have any description, usually, but as for making that description show the relevance, proportionality and benefits to the user? Rare, very rare.

This is another argument for security folks being more embedded in systems design because, like it or not, your users are part of your system, and they need to be included in the design.  Which means that you need to educate your UX people, too, because if you can’t convince them of the need to do security, you’re sure as heck not going to be able to convince your users.

And when you work with them on the personae and use case modelling, make sure that you include users who are like you: knowledgeable security experts who want to know why they should submit themselves to the controls that you’re including in the system.

Now, they’ve opened up the exhibitor hall again: I’ve got to go and grab myself a drink before they start kicking people out again.


*my employer.

**she’s American.

***I’m British****.

****and the conference is in Australia, which meant that I was actually able to get a decent cup of the same.

*****this, I believe, stands for “User eXperience”. I find it almost unbearably ironic that the people tasked with communicating clearly to us can’t fully grasp the idea of initial letters standing for something.

******and most security controls are.

Why microservices are a security issue

Should you go about decomposing all of your legacy applications into microservices? Probably not. But given all of the benefits you can accrue, you might consider starting with your security functions.

I struggled with writing the title for this post, and I worry that it comes over as clickbait.  If you’ve come to read this because it looked like clickbait, then sorry*.  I hope you’ll stay anyway: there are lots of fascinating** posts and many*** footnotes.  What I didn’t mean to suggest is that microservices cause security problems – though like any component, of course, they can – but that microservices are appropriate objects of interest to those involved with security.  I’d go further than that: I think they are an excellent architectural construct for those concerned with security.

And why is that?  Well, for those of us with a systems security bent, the world is an interesting place at the moment.  We’re seeing a growth in distributed systems as bandwidth is cheap and latency low.  Add to this the ease of deploying to the cloud, and more architects are beginning to realise that they can break up applications not just into multiple layers but also into multiple components within the layer.  Load-balancers, of course, help with this when the various components in a layer are performing the same job, but the ability to expose different services as small components has led to a growth in the design, implementation and deployment of microservices.

So, what exactly is a microservice?  I quite like the definition provided by Wikipedia, though it’s interesting that security isn’t mentioned there****.  One of the points that I like about microservices is that, when well-designed, they conform to the first two points of Peter H. Salus’ description of the Unix philosophy:

  1. Write programs that do one thing and do it well.
  2. Write programs to work together.
  3. Write programs to handle text streams, because that is a universal interface.

The last of the three is slightly less relevant, because the Unix philosophy is generally used to refer to standalone applications, which often have a command instantiation.  It does, however, encapsulate one of the basic requirements of microservices: that they must have well-defined interfaces.

By “well-defined”, I don’t just mean a description of any externally-accessible APIs’ methods, but also of the normal operation of the microservice: inputs and outputs – and, if there are any, side-effects.  As I’ve described in a previous post, Thinking like a (systems) architect, data and entity descriptions are crucial if you’re going to be able to design a system.  Here, in our description of microservices, we get to see why these are so important, because for me the key defining feature of a microservices architecture is decomposability.  And if you’re going to decompose***** your architecture, you need to be very, very clear which “bits” (components) are going to do what.

And here’s where security starts to come in.  A clear description of what a particular component should be doing allows you to:

  • check your design;
  • ensure that your implementation meets the description;
  • come up with reusable unit tests to check functionality;
  • track mistakes in implementation and correct them;
  • test for unexpected outcomes;
  • monitor for misbehaviour;
  • audit actual behaviour for future scrutiny.

Now, are all these things possible in a larger architecture?  Yes, they are.  But they becoming increasingly difficult where entities are chained together – or combined in more complex configurations.  Ensuring correct implementation and behaviour is much, much easier when you’ve got smaller pieces to work together.  And deriving complex systems behaviours – and misbehaviours – is much more difficult if you can’t be sure that the individual components are doing what they ought to be.

It doesn’t stop here, however.  As I’ve mentioned on many previous occasions in this blog, writing good security code is difficult*******.  Proving that it does what it should do is even more so.  There is every reason, therefore, to restrict code which has particular security requirements – password checking, encryption, cryptographic key management, authorisation, to offer a few examples – to small, well-defined blocks.  You can then do all the things that I’ve mentioned above to try to make sure that it’s done correctly.

And yet there’s more.  We all know that not everybody is great at writing security-related code.  By decomposing your architecture such that all security-sensitive code is restricted to well-defined components, you get the chance to put your best security people on that, and restricting the danger of J. Random Coder******** putting something in which bypasses or downgrades a key security control.

It can also act as an opportunity for learning: it’s always good to be able to point to a design/implementation/test/monitoring tuple and say: “that’s how it should be done.  Hear, read, mark, learn and inwardly digest*********.”

Should you go about decomposing all of your legacy applications into microservices?  Probably not.  But given all of the benefits you can accrue, you might consider starting with your security functions.


*well, a little bit – it’s always nice to have readers.

**I know they are: I wrote them.

***probably less fascinating.

****at the time of writing this article.  It’s entirely possible that I – or one of you – may edit the article to change that.

*****this sounds like a gardening term, which is interesting.  Not that I really like gardening, but still******.

******amusingly, I first wrote “…if you’re going to decompose your architect…”, which sounds like the strap-line for an IT-themed murder film.

*******regular readers may remember a reference to the excellent film “The Thick of It”.

********other generic personae exist: please take your pick.

*********not a cryptographic digest: I don’t think that’s what the original writers had in mind.

Wow: autonomous agents!

The problem is not the autonomy. The problem isn’t even particularly with the intelligence…

Autonomous, intelligent agents offer some great opportunities for our digital lives*.  There, look, I said it.  They will book meetings for us, negotiate cheap holidays, order our children’s complete school outfit for the beginning of term, and let us know when it’s time to go to the nurse for our check-up.  Our business lives, our personal lives, our family relationships – they’ll all be revolutionised by autonomous agents.  Autonomous agents will learn our preferences, have access to our diaries, pay for items, be able to send messages to our friends.

This is all fantastic, and I’m very excited about it.  The problem is that I’ve been excited about it for nearly 20 years, when I was involved in a project around autonomous agents in Java.  It was very neat then, and it’s still very neat now***.

Of course, technology has moved on.  Some of the underlying capabilities are much more advanced now than then.  General availability of APIs, consistency of data formats, better Machine Learning (or Artificial Intelligence, if you must), less computationally expensive cryptography, and the rise of blockchains and distributed ledgers: they all bring the ability for us to build autonomous agents closer than ever before.  We talked about disintermediation back in the day, and that looked plausible.  We really can build scalable marketplaces now in ways which just weren’t as feasible two decades ago.

The problem, though, isn’t the technology.  It was never the technology.  We could have made the technology work 20 years ago, even if it wasn’t as fast, secure or wide-ranging as it could be today.  It isn’t even vested interests from the large platform players, who arguably own much of this space at the moment – though these interests are much more consolidated than they were when I was first looking at this issue.

The problem is not the autonomy.  The problem isn’t even particularly with the intelligence: you can program as much or as little in as you want, or as the technology allows.  The problem is with the agency.

How much of my life do I want to hand over to what’s basically a ‘bot?  Ignore***** the fact that these things will get hacked******, and assume we’re talking about normal, intended usage.  What does “agency” mean?  It means acting for someone: being their agent – think of what actors’ agents do, for example.  When I engage a lawyer or a builder or an accountant to do something for me, or when an actor employs an agent for that matter, we’re very clear about what they’ll be doing.  This is to protect both me and them from unintended consequences.  There’s a huge legal corpus around defining, in different fields, exactly the scope of work to be carried out by a person or a company who is acting as an agent.  There are contracts, and agreed restitutions – basically punishments – for when things go wrong.  Say that an accountant buys 500 shares in a bank, and then I turn round and say that she never had the authority to do so: if we’ve set up the relationship correctly, it should be entirely clear whether or not she did, and whose responsibility it is to deal with any fall-out from that purchase.

Now think about that in terms of autonomous, intelligent agents.  Write me that contract, and make it equivalent in software and the legal system.  Tell me what happens when things go wrong with the software.  Show me how to prove that I didn’t tell the agent to buy those shares.  Explain to me where the restitution lies.

And these are arguably the simple problems.  How to I rebuild the business reputation that I’ve built up over the past 15 years when my agent posts on Twitter a tweet about how I use a competitor’s products, when I’m just trialling them for interest?  How does an agent know not to let my wife see the diary entry for my meeting with that divorce lawyer*******?  What aspects of my browsing profile are appropriate for suggesting – or even buying – online products or services with my personal or business credit card*********?  And there’s the classic “buying flowers for the mistress and having them sent to the wife” problem**********.

I don’t think we have an answer to these questions: not even close.  You know that virtual admin assistant we’ve been promised in sci-fi movies for decades now: the one with the futuristic haircut who appears as a hologram outside our office?  Holograms – nearly.  Technology behind it – pretty much.  Trust, reputation and agency?  Nowhere near.

 


*I hate this word: “digital”.  Well, not really, but it’s used far too much as a shorthand for “newest technology”**.

**”Digital businesses”.  You mean, unlike all the analogue ones?  Come on.

***this is one of those words that my kids hate me using.  There are two types of word that come into this category: old words and new words.  Either I’m showing how old I am, or I’m trying to be hip****, which is arguably worse.  I can’t win.

****yeah, they don’t say hip.  That’s one of the “old person words”.

*****for now, at least.  Let’s not forget it.

******_everything_  gets hacked*******.

*******I could say “cracked”, but some of it won’t be malicious, and hacking might be positive.

********I’m not.  This is an example.

*********this isn’t even about “dodgy” things I might have been browsing on home time.  I may have been browsing for analyst services, with the intent to buy a subscription: how sure am I that the agent won’t decide to charge these to my personal credit card when it knows that I perform other “business-like” actions like pay for business-related books myself sometimes?

**********how many times do I have to tell you, darling…?

Next generation … people

… security as a topic is one which is interesting, fast-moving and undeniably sexy…

DISCLAIMER/STATEMENT OF IGNORANCE: a number of regular readers have asked why I insist on using asterisks for footnotes, and whether I could move to actual links, instead.  The official reason I give for sticking with asterisks is that I think it’s a bit quirky and I like that, but the real reason is that I don’t know how to add internal links in WordPress, and can’t be bothered to find out.  Apologies.

I don’t know if you’ve noticed, but pretty much everything out there is “next generation”.  Or, if you’re really lucky “Next gen”.  What I’d like to talk about this week, however, is the actual next generation – that’s people.  IT people.  IT security people.  I was enormously chuffed* to be referred to on an IRC channel a couple of months ago as a “greybeard”***, suggesting, I suppose, that I’m an established expert in the field.  Or maybe just that I’m an old fuddy-duddy***** who ought to be put out to pasture.  Either way, it was nice to come across young(er) folks with an interest in IT security******.

So, you, dear reader, and I, your beloved protagonist, both know that security as a topic is one which is interesting, fast-moving and undeniably******** sexy – as are all its proponents.  However, it seems that this news has not yet spread as widely as we would like – there is a worldwide shortage of IT security professionals, as a quick check on your search engine of choice for “shortage of it security professionals” will tell you.

Last week, I attended the Open Source Summit and Linux Security Summit in LA, and one of the keynotes, as it always seems to be, was Jim Zemlin (head of the Linux Foundation) chatting to Linus Torvalds (inventor of, oh, I don’t know).  Linus doesn’t have an entirely positive track record in talking about security, so it was interesting that Jim specifically asked him about it.  Part of Linus’ reply was “We need to try to get as many of those smart people before they go to the dark side [sic: I took this from an article by the Register, and they didn’t bother to capitalise.  I mean: really?] and improve security that way by having a lot of developers.”  Apart from the fact that anyone who references Star Wars in front of a bunch of geeks is onto a winner, Linus had a pretty much captive audience just by nature of who he is, but even given that, this got a positive reaction.  And he’s right: we do need to make sure that we catch these smart people early, and get them working on our side.

Later that week, at the Linux Security Summit, one of the speakers asked for a show of hands to find out the number of first-time attendees.  I was astonished to note that maybe half of the people there had not come before.  And heartened.  I was also pleased to note that a good number of them appeared fairly young*********.  On the other hand, the number of women and other under-represented demographics seemed worse than in the main Open Source Summit, which was a pity – as I’ve argued in previous posts, I think that diversity is vital for our industry.

This post is wobbling to an end without any great insights, so let me try to come up with a couple which are, if not great, then at least slightly insightful:

  1. we’ve got a job to do.  The industry needs more young (and diverse talent): if you’re in the biz, then go out, be enthusiastic, show what fun it can be.
  2. if showing people how much fun security can be, encourage them to do a search for “IT security median salaries comparison”.  It’s amazing how a pay cheque********** can motivate.

*note to non-British readers: this means “flattered”**.

**but with an extra helping of smugness.

***they may have written “graybeard”, but I translate****.

****or even “gr4yb34rd”: it was one of those sorts of IRC channels.

*****if I translate each of these, we’ll be here for ever.  Look it up.

******I managed to convince myself******* that their interest was entirely benign though, as I mentioned above, it was one of those sorts of IRC channels.

*******the glass of whisky may have helped.

********well, maybe a bit deniably.

*********to me, at least.  Which, if you listen to my kids, isn’t that hard.

**********who actually gets paid by cheque (or check) any more?

Why I love technical debt

… if technical debt can be named, then it can be documented.

Not necessarily a title you’d expect for a blog post, I guess*, but I’m a fan of technical debt.  There are two reasons for this: a Bad Reason[tm] and a Good Reason[tm].  I’ll be up front about the Bad Reason first, and then explain why even that isn’t really a reason to love it.  I’ll then tackle the Good Reason, and you’ll nod along in agreement.

The Bad Reason I love technical debt

We’ll get this out of the way, then, shall we?  The Bad Reason is that, well, there’s just lots of it, it’s interesting, it keeps me in a job, and it always provides a reason, as a security architect, for me to get involved in** projects that might give me something new to look at.  I suppose those aren’t all bad things, and it can also be a bit depressing, because there’s always so much of it, it’s not always interesting, and sometimes I need to get involved even when I might have better things to do.

And what’s worse is that it almost always seems to be security-related, and it’s always there.  That’s the bad part.

Security, we all know, is the piece that so often gets left out, or tacked on at the end, or done in half the time that it deserves, or done by people who have half an idea, but don’t quite fully grasp it.  I should be clear at this point: I’m not saying that this last reason is those people’s fault.  That people know they need security it fantastic.  If we (the security folks) or we (the organisation) haven’t done a good enough job in making security resources – whether people, training or sufficient visibility – available to those people who need it, then the fact that they’re trying is a great, and something we can work on.  Let’s call that a positive.  Or at least a reason for hope***.

The Good Reason I love technical debt

So let’s get on to the other reason: the legitimate reason.  I love technical debt when it’s named.

What does that mean?

So, we all get that technical debt is a bad thing.  It’s what happens when you make decisions for pragmatic reasons which are likely to come back and bite you later in a project’s lifecycle.  Here are a few classic examples that relate to security:

  • not getting round to applying authentication or authorisation controls on APIs which might at some point be public;
  • lumping capabilities together so that it’s difficult to separate out appropriate roles later on;
  • hard-coding roles in ways which don’t allow for customisation by people who may use your application in different ways to those that you initially considered;
  • hard-coding cipher suites for cryptographic protocols, rather than putting them in a config file where they can be changed or selected later.

There are lots more, of course, but those are just a few which jump out at me, and which I’ve seen over the years.  Technical debt means making decisions which will mean more work later on to fix them.  And that can’t be good, can it?

Well, there are two words in the preceding paragraph or two which should make us happy: they are “decisions” and “pragmatic”.  Because in order for something to be named technical debt, I’d argue, it needs to have been subject to conscious decision-making, and for trade-offs to have been made – hopefully for rational reasons.  Those reasons may be many and various – lack of qualified resources; project deadlines; lack of sufficient requirement definition – but if they’ve been made consciously, then the technical debt can be named, and if technical debt can be named, then it can be documented.

And if they’re documented, then we’re half-way there.  As a security guy, I know that I can’t force everything that goes out of the door to meet all the requirements I’d like – but the same goes for the High Availability gal, the UX team, the performance folks, et al..  What we need – what we all need – is for there to exist documentation about why decisions were made, because then, when we return to the problem later on, we’ll know that it was thought about.  And, what’s more, the recording of that information might even make it into product documentation, too.  “This API is designed to be used in a protected environment, and should not be exposed on the public Internet” is a great piece of documentation.  It may not be what a customer is looking for, but at least they know how to deploy the product now, and, crucially, it’s an opportunity for them to come back to the product manager and say, “we’d really like to deploy that particular API in this way: could you please add this as a feature request?”.  Product managers like that.  Very much****.

The best thing, though, is not just that named technical debt is visible technical debt, but that if you encourage your developers to document the decisions in code*****, then there’s a half-way to decent chance that they’ll record some ideas about how this should be done in the future.  If you’re really lucky, they might even add some hooks in the code to make it easier (an “auth” parameter on the API which is unused in the current version, but will make API compatibility so much simpler in new releases; or cipher entry in the config file which only accepts one option now, but is at least checked by the code).

I’ve been a bit disingenuous, I know, by defining technical debt as named technical debt.  But honestly, if it’s not named, then you can’t know what it is, and until you know what it is, you can’t fix it*******.  My advice is this: when you’re doing a release close-down (or in your weekly stand-up: EVERY weekly stand-up), have an item to record technical debt.  Name it, document it, be proud, sleep at night.

 


*well, apart from the obvious clickbait reason – for which I’m (a little) sorry.

**I nearly wrote “poke my nose into”.

***work with me here.

****if you’re software engineer/coder/hacker – here’s a piece of advice: learn to talk to product managers like real people, and treat them nicely.  They (the better ones, at least) are invaluable allies when you need to prioritise features or have tricky trade-offs to make.

*****do this.  Just do it.  Documentation which isn’t at least mirrored in code isn’t real documentation******.

******don’t believe me?  Talk to developers.  “Who reads product documentation?”  “Oh, the spec?  I skimmed it.  A few releases back.  I think.”  “I looked in the header file: couldn’t see it there.”

*******or decide not to fix it, which may also be an entirely appropriate decision.

The simple things, sometimes…

I (re-)learned an important lesson this week: if you’re an attacker, start at the front door.

This week I’ve had an interesting conversation with an organisation with which I’m involved*.  My involvement is as a volunteer, and has nothing to do with my day job – in other words, I have nothing to do with the organisation’s security.  However, I got an email from them telling me that in order to perform a particular action, I should now fill in an online form, which would then record the information that they needed.

So this week’s blog entry will be about entering information on an online form.  One of the simplest tasks that you might want to design – and secure – for any website.  I wish I could say that it’s going to be a happy tale.

I had look at this form, and then I looked at the URL they’d given me.  It wasn’t a fully qualified URL, in that it had no protocol component, so I copied and pasted it into a browser to find out what would happen. I had a hope that it might automatically redirect to an https-served page.  It didn’t.  It was an http-served page.

Well, not necessarily so bad, except that … it wanted some personal information.  Ah.

So, I cheated: I changed the http:// … to an https:// and tried again**.  And got an error.  The certificate was invalid.  So even if they changed the URL, it wasn’t going to help.

So what did I do?  I got in touch with my contact at the organisation, advising them that there was a possibility that they might be in breach of their obligations under Data Protection legislation.

I got a phone call a little later.  Not from a technical person – though there was a techie in the background.  They said that they’d spoken with the IT and security departments, and that there wasn’t a problem.  I disagreed, and tried to explain.

The first argument was whether there was any confidential information being entered.  They said that there was no linkage between the information being entered and the confidential information held in a separate system (I’m assuming database). So I stepped back, and asked about the first piece of information requested on the form: my name.  I tried a question: “Could the fact that I’m a member of this organisation be considered confidential in any situation?”

“Yes, it could.”

So, that’s one issue out of the way.

But it turns out that the information is stored encrypted on the organisation’s systems.  “Great,” I said, “but while it’s in transit, while it’s being transmitted to those systems, then somebody could read it.”

And this is where communication stopped.  I tried to explain that unless the information from the form is transmitted over https, then people could read it.  I tried to explain that if I sent it over my phone, then people at my mobile provider could read it.  I tried a simple example: I tried to explain that if I transmitted it from a laptop in a Starbucks, then people who run the Starbucks systems – or even possibly other Starbucks customers – could see it.  But I couldn’t get through.

In the end, I gave up.  It turns out that I can avoid using the form if I want to.  And the organisation is of the firm opinion that it’s not at risk: that all the data that is collected is safe.  It was quite clear that I wasn’t going to have an opportunity to argue this with their IT or security people: although I did try to explain that this is an area in which I have some expertise, they’re not going to let any Tom, Dick or Harry*** bother their IT people****.

There’s no real end to this story, other than to say that sometimes it’s the small stuff we need to worry about.  The issues that, as security professionals, we feel are cut and dried, are sometimes the places where there’s still lots of work to be done.  I wish it weren’t the case, because frankly, I’d like to spend my time educating people on the really tricky things, and explaining complex concepts around cryptographic protocols, trust domains and identity, but I (re-)learned an important lesson this week: if you’re an attacker, start at the front door.  It’s probably not even closed: let alone locked.


*I’m not going to identify the organisation: it wouldn’t be fair or appropriate.  Suffice to say that they should know about this sort of issue.

**I know: all the skillz!

***Or “J. Random User”.  Insert your preferred non-specific identifier here.

****I have some sympathy with this point of view: you don’t want to have all of their time taken up by random “experts”.  The problem is when there really _are_ problems.  And the people calling them maybe do know their thing.