Last updated: 
4 months 2 weeks ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Rebuilding trust in the Internet's building blocks

Thursday, July 11, 2019 - 10:22

Merike Kaeo's keynote "Waking Up the Guards" at the FIRST 2019 conference (recording now available on YouTube) highlighted how attacks on the internet core no longer target a single service (naming, routing, signing) but move between these to achieve their hostile result. Defenders, too, need to consider the consequences of their implementation choices as a whole, to reduce to opportunities for bad things to happen "in the seams" of the Internet. Thus, for example, an attack on DNS that started by exploiting weaknesses in BGP routing needs to be mitigated through a combination of prefix filtering, Resource Public Key Infrastructure (RPKI) and DNS Security (DNSSec). Those may well be managed by different parts of the organisation, or even different organisations, which need to work together to ensure the individual tools are effective in combination. Default settings – which are often selected for ease of debate, rather than overall security – may not be the best choice.

Key building blocks to all these systems are hard-to-impersonate identity, integrity, confidentiality and audit but, again, their interactions need to be understood. Ensure they do actually complement one another, rather than introducing single points of failure. Encryption, in particular, needs to be deployed with care: over-use may add little to confidentiality, but severely limit auditability. If an operator cannot detect when their infrastructure has been compromised then there's little benefit in passing on confidential communications to an unknown and probably hostile destination. Identity typically depends on some kind of credentials, but the security aspects of their whole lifecycle – generation, distribution, storage, recovery, delegation/transfer, revocation and destruction – need to be understood to avoid introducing weakness.

Finally, although Merike limited this point to communications with managers, it seems to me that it may be more widely valuable. Don't talk in acronyms, as I have here (!), say what a protocol or service actually does. Even for technical people, once in a while talking about "ensuring authoritative answers come from the expected place" might highlight mismatched assumptions that would be hidden by simply repeating "DNSSec".