Blog post

Import data, not malware

Created:  16 Jul 2018
Updated:  16 Jul 2018
Author:  Richard C
Import data not malware

Today we've released a cornerstone of the NCSC's security architecture practice - our pattern for safely importing data. This pattern is one we've been recommending in our consultancy work for many years, but it's being published on the web for the first time today. We hope you find it useful.

The pattern incorporates some of the techniques we describe in our security architecture design principles. In particular, we rely on the concepts of transformation and validation, ordering them into a gateway designed to let you bring data into your systems without inadvertently importing malicious code.

The pattern is generic, so should be tailored to fit your particular scenario. In lower risk situations, you might want to leave out some of the controls, such as the transformation engine, but if you're facing higher risks you might want to use them all and seek particular assurance in the validation engine.

One top tip I’d like to share from my experience of using the pattern is to remind users to ask for the data they need, rather than the document it's wrapped in. I’ve often heard requirements for regular PDF transfers, when what is actually needed is some text, or numbers contained within a PDF. The data might arrive in a PDF, but that’s not necessarily what's required to pass through your gateway.

Please let us know if the pattern proves useful to you. We have a couple more in our pipeline to publish too. The next will focus on safely exporting data, which the eager amongst you should note is not simply the reverse of the import pattern!

 

Richard C

Chief Architect, NCSC

5 comments

Sam - 17 Jul 2018
Should this pattern be used for OFFICIAL networks or just those classified OFFICIAL SENSITIVE? The intro talks about only using it for sensitive data so wanted to check what the rules are.
Richard C - 24 Jul 2018
The pattern could be useful in a variety of scenarios; we didn’t intend the word ‘sensitive’ to map to the SENSITIVE caveat used in the public sector. In the public sector context, the SENSITIVE caveat applies to information rather than systems or networks.
You can use this architecture pattern with OFFICIAL information, but whether you should will depend on your situation and will need skilled judgement.
Peter Barnsley - 17 Jul 2018
This is fantastic news! You have saved me a lot of work Rich. Cheers.
Max Pritchard - 18 Jul 2018
It looks like a well-thought out model of data import to enable connectivity whilst avoiding, as far as possible, risks of data exfiltration and mitigating risk of compromise.

I have found that extra controls add considerable complexity to a networked system, which increases both the likelihood of outages caused by IT failure, and the duration of outages. With availability being accepted as one of the three cornerstones of security, and DDoS attacks and the like threatening the system's availability - does your model need to consider how to find the right balance between system integrity/confidentiality and system availability?
Mr.robot - 07 Sep 2018
A few good scripts + sintactics pattern policies
( well set up ) + good configuration of gateways and routes + good awareness concepts well implemented on users should be enough security. Metadata must be reduced and cleaned from caches on every file transfers. Indexing by the right all db where information is stored and re-creating new keys and tokens per session.

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No