Security musings

Metadata is data about your document.

At the most basic it includes things like the file name, the date the file was last updated and other similar information. Common document types like .XLSX, .RTF, .JPG and .PDF are able to store a lot of metadata in addition to the basics listed above. Some of this metadata may be information you didn’t mean to make public.

By way of example - the JPG standard allows for storage of GPS information, date and time taken, information about the owner of the camera and the serial number of the camera body. When you publish a photo you could disclose that a certain person (the owner), was in a certain location (the GPS data) at a certain time on a certain day (date taken). Using the serial number you can link this photo to others and build up a profile of the usage patterns or other information that you might not otherwise realise you were divulging.

Many people use this metadata for exactly this purpose - they want to record this information, have it available and provide linkages. What I am suggesting is stripping it out of any documents that you intend publishing, either to the web or by email or other electronic means. Certainly keep the metadata in documents which remain in your control, but they should be stripped before you release them to others.

Most applications which write metadata to their own files have an option to strip that metadata out for precisely the reasons I’ve outlined above. Google should point you in the right direction for whatever application you are interested in, but here’s an example of the steps for removing metadata from a .PDF document created with Adobe Acrobat XI.

exiftool is a great tool which you can use to check for metadata in your documents. It started life as a tool for working with metadata in image files (specifically EXIF data) but it now handles metadata from many file formats, including all the popular ones that most people will come across in their day to day usage. You can see the set of file types it can report on here

The command line can take a bit of getting used to, but to save you trouble here’s a standard one I use to check what hidden information I can dig out of the metadata on a file - “exiftool -s -g -a”. For a file named “img_5350.jpg" the following command returns almost 200 lines of data about that one single image.

exiftool -s -g -a img_5350.jpg

No, the title doesn't have a typo or a missing word.  Cyber is an over-used word.  Is it time to stamp out the use of "cyber" or at least reduce the usage?

The word “cyber” is regularly added these days to all sorts of words with a view to giving that word currency. We have cyber attack, cyber bully, cyber security, etc . . . In this context “cyber” is used to indicate that the issue was related in some way, shape or form to a computer or digital system.

However the word “cyber” is redundant in many cases. We don't normally say that someone was physically attacked on the street, we just say they were attacked. The context (it happened to a real physical person in the real world) tells us that the attack was physical in nature. In the same way, we don't need to say that a database was the subject of a cyber attack, just that it was the subject of an attack. The only context for a database to be attacked is a virtual or cyber context.

It's definitely the case that there are other contexts for attacks on some I.T. infrastructure items. For example, the old story of someone driving a truck through the wall of your server room and making off with the physical hardware wouldn't normally be described as a cyber attack. In this case it's a robbery, the same as if they broke in and took the contents of your safe. The context of the story would be enough to establish this.

This thought has been in the back of my mind for some time now and was brought to the front by a comment at an (ISC)² talk I attended recently. The speaker, Will Semple, started by declaring that in his view there was no difference between different forms of intelligence. I took this to mean that there's no difference from the point of view of the consumer of the intelligence.

If your organisation is under attack, you are interested in all the relevant intelligence that can be gathered about the attack. Some of this intelligence might be sigint, some might be humint and now some might be cyber intelligence.

From a strategic point of view you may well want to make sure that you have sufficient measures in place for humint, sigint and cyber intelligence in advance of an attack.  In this way there is value in distinguishing between the types of intelligence, but once an attack is underway that distinction is much less relevant.

The key point here is that in an operational mode, as someone involved in the response to the incident, you don't need to know the source of the intel in order to make use of it. You may need to know the source in order to evaluate the usefulness but that's a different story.

We say (or we used to say until recently) that we were going to a cyber cafe to check our email.  This was a legitimate addition of the word "cyber".  Although it could be argued that the quality of the coffee in some cyber cafes wasn't up to much, most places did at least combine the cafe bit with the cyber bit.  It has become less relevant recently since many regular cafes now provide internet access in the same way that they provide knives, plates, sugar, light and heat for their customers enjoyment.

By using the word “cyber” in front of words like “attack” and “bully” are we elevating them to being somehow different than other forms of attack or bullys, or does the extra word help in our understanding?

This post originally appeared on sinctify.com

I came across a website recently which had implemented poor controls with the result that it was trivial to retrieve records for other customers.  I notified the website owners once I discovered the issue and I'm glad to report that within 24 hours of the notification they had addressed the problem.

There was a control in place which meant that you couldn't retrieve medical records for another patient (thankfully), but that control hadn't been applied to the page which served up their billing records.

Here's a snippet of the text I sent them -

Once a user has authenticated to bookings.your.domain they can retrieve details of their bookings at this URL - https://bookings.your.domain/print-receipt/<receipt number>. By entering different values for <receipt number> an authenticated user can see details for other patients. These details include their name, date of birth and other values.

In practice this meant that if the valid URL for my booking was https://bookings.their.domain/print-receipt/3045, then all I had to do to read another patients details was change the URL to read like this https://bookings.their.domain/print-receipt/3046.

There was a control in place so that you at least had to be authenticated before retrieving details so this wasn't wide open to any unauthenticated user on the internet.  This meant that the risk of exposure was somewhat reduced. Once someone was authenticated, however, they could retrieve details for all the records on file.

This post originally appeared on sinctify.com.