Sorry if it is silly question. I'm new here. If you don't mind me asking, I got one question.
Do you guys encrypt acquired RAM dump to prevent from being tampered during transit/transport?
What would be the best practice please? I would like it to be forensically sound and comply with ISO 27001 standard.
I'm using Magnet RAM Capture tool.
Sorry if it is silly question. I'm new here. If you don't mind me asking, I got one question.
Do you guys encrypt acquired RAM dump to prevent from being tampered during transit/transport?
What would be the best practice please? I would like it to be forensically sound and comply with ISO 2701 standard.
I'm using Magnet RAM Capture tool.
Why "encrypting" it?
Like *any* data, if the scope is validation (i.e. proof of no tampering) a checksum/hash is what is *needed*.
As a matter of fact, in theory one could find a way to unencrypt your data (let's say stealing the password you used) and then, after having changed *something*, re-encrypt it with the same method and password.
You would have no way to be certain that the data wasn't modified.
On the other hand, creating a hash collision is not trivial (if possible at all, of course depending on the hashing algorithm used).
MD5 is compromised since years
http//
SHA-1 is possible
https://shattered.io/
SHA-256 is (till now) safe.
jaclaz
Encryption does not offer a way to detect tampering. Digital signatures do.
ISO 2700x is an generic strategic infosec standard and should be kept away from anything practical.
Hint finding an attack against one algorithm is hard enough, finding one that works against several is close to impossible.
Sorry. I should explain better. I don’t want prying eyes to look at my ram dump while being transported to another location. First responder will perform onsite acquisition in another geo location and then ship it to HQ etc.
I can encrypt ram acquired image e01 with built in Encase was encryption but encase imager is heavy on footprint. I avoid using it.
In FTK or other ram acquisition tools, I don’t see built in functionality part of acquisition process to encrypt for RAM image/dump. Also FTK ram capture works in user space.
I was wondering if encrypting ram image (evidence) is even required.
Sorry. I should explain better. I don’t want prying eyes to look at my ram dump while being transported to another location. First responder will perform onsite acquisition in another geo location and then ship it to HQ etc.
More or less that would imply either a break in the chain of custody or the suspect of an "inside job" 😯 .
Where/how is the RAM dump stored?
How (physically) is the RAM dump transported/shipped?
I mean, is it not a hard disk, is it not put in a sealed, signed envelope of some kind, which (still physically) is inserted in a rigid transport case (possibly with a lock and maybe also with a second seal)?
Is the package at ANY time managed (or even touched) by anyone who is not a sworn LE signing for its custody?
Is the package at ANY time left unattended in ANY place that is (by other means) without access to anyone else but the custodian?
Encryption can - in theory - be broken, so if you believe that someone can have access to the evidence that is IMHO the problem, after all one could access the (encrypted) Ram dump, make a copy of it and (again in theory) decrypt the copy.
As a side note, a RAM dump - usually - is not something that anyone (with the exception of a number of programmers and forensic investigators) will be able to actually "read".
jaclaz
Do you guys encrypt acquired RAM dump to prevent from being tampered during transit/transport?
Yes, one way or another. It's not just a question of forensic standards or RAM acquisition. Among the first steps to secure a business that relies on sound, attributable data processing is to encrypt all of your underlying storage on a volume or device/hardware level. In principle, there is no plainly readable storage media within your company, and I think this should be mandatory for a company that processes PII/SPI.
There can be exceptions, of course, like a floppy disk to update the BIOS of a legacy system, but they are not in permanent use and not used for any "production" data.
Within this environment, which is hardened against the outside, you build your internal access control. In a forensic environment this will often require file level encryption, because many steps of forensic analysis imply to work with elevated rights on the user's machine. You also want to avoid the Snowden effect, if your administration and analytical roles are separated.
An ACL approach to restrict these mighty users at least to individual machines is very fragile in the context of centralized management. Encryption doesn't prevent an impersonation attack, of course, but it prevents immediate access to other users' historic data.
I would like it to be forensically sound and comply with ISO 2701 standard.
ISO 2701 is "Drawn wire for general purpose non-alloy steel wire ropes – Terms of acceptance" … are you sure that's the right thing to comply with? You should, I think, at the very least use drawn wire intended for forensic purposes, and there are benefits of using alloys rather than pure steel for data storage purposes that you may want to take into account..
If you meant to refer to ISO 27001 … it doesn't make good sense either. 27001 is a framework for how to build an information security system. That is, it tells your organization how a good IS environment should be created. It doesn't set rules if you should encrypt this or that data. It may tell you that you need to have a rule for it, though.
You should rather go to your own organization and ask 'how do I need to treat RAM dumps?' It may be that you have rules for information classification if so, those should tell you how this particular RAM dump should be classified. You probably also have rules for handling classified information that tells you whether or not it needs to be encrypted during transport, or if it even allowed to be transported by a third party, such as postal services or the like.
Don't ignore the risk that comes with encryption you mustn't lose the encryption key. If you do, you may be even worse off. But again, that is something that you or your organization or your customers should decide.
Hello guys. Thanks for all your help. yes, it is 27001 that our Info Sec dept is working toward. Sorry I confused you.
I'm not sure how it would play its part in ISO27001 but my focus is on creating a documentation for forensic acquisition with best practice.
Regardless of ISO standard, in RAM acquisition, I was looking for best workflow and practice. I was thinking sending a un-encrypted form of ram dump to another location is not a good idea for non-repudiation purposes. Am i correct in saying that?
Apart from Encase Imager, as far as I know, no other standalone RAM acquisition tools offer built in encryption when creating an RAM image/dump.
I appreciate even with ChainOfCustody followed, the chances of someone intercepting the parcel in transit, open the non-encrypted RAM image, look for specific data and change it in real life is possible but quite slim. All I would like to know if RAM image needs to be transported with encryption.
Thanks so much in advance. )
Regardless of ISO standard, in RAM acquisition, I was looking for best workflow and practice. I was thinking sending a un-encrypted form of ram dump to another location is not a good idea for non-repudiation purposes. Am i correct in saying that?
It depends on your threat model. What exact threat are you trying to protect yourself from? 'non-repudiation purposes' is vague whose repudiation of what?
You can sign the RAM dump digitally from that point in time you are protected against claims that the dump was created by someone else, as long as you can show that your private key is not accessible to anyone else, and tell the recipient that only that key is acceptable for signing purposes. If the signature is time stamped by a secure time service (as it should be), you can even pinpoint the time when it happened. (If a second person countersigns, you may even get additional protection.)
Encryption may also give such protection, but it depends on how you do it. Public-key encryption is not obviously a good idea, as you encrypt with the recipients public key, and that is by definition public. You need something more. Secret-key encryption would do, but you need to be able to show who is holding the secret key, and that none of these people has made it available (deliberately or not). Creating a secret key (time-stamped if possible) just before imaging starts might do it.
But either of these would only protect against claims that the dump isn't one you created, at that particular point in time. It won't protect you against claim that the source of the dump isn't the computer you claim it to be, but something you made up on your own. (That's a reason you may want double signatures.)
For general case, and for images that won't leave your hands, I would recommend encryption, just because you never know what's in the image. If an encrypted image is going to leave your hands, you need to perform a crypto-key handover … and you can't botch that … or decrypt the image, which adds time and effort. Encryption is expensive *everyone* involved must follow the rules, and may not impossibly be prepared to be audited on that. For example, keys should have a limited lifetime. Yet, you may need to save old keys in case an old case surfaces, and you need to verify an old signature. But you may no longer be with the same department … so you need a solution for that.
Thus, best practice to me would probably involve digital signage, but it would mean a lot of additional requirement about key management. It may involve encryption, but that depends on other things.
I appreciate even with ChainOfCustody followed, the chances of someone intercepting the parcel in transit, open the non-encrypted RAM image, look for specific data and change it in real life is possible but quite slim. All I would like to know if RAM image needs to be transported with encryption.
Does chain of custody extend to material out of your hands? When you hand it over to postal services or someone outside your company/department, the chain of custody is broken, IMHO. You may show that the handover was performed well by signing the first entry in the new chain of custody form created by the recipient (and vice versa, he signing your last entry). At least, that's how I understand the term actual practices probably vary.
However, a digital signature (or equivalent protection) would help ensure that later modifications of that data can be detected. That may be what you are really trying to achieve by a chain of custody, and use of a digital signature may allow you to use postal services. (With some additional protocol you need to keep your copy until the recipient has verified that he received an unchanged image by mail, for example)
But as your question is "I would like to know if RAM image needs to be transported with encryption", the answer remains the same that is decided by whoever owns the information, or by whoever has it in his custody, and is generally based on a threat/risk analysis what could happen, what damage would be made, what protection is possible, what do they cost, and what further risks do they add?
For some additional information, see Watson & Jones Digital Forensic Processing and Procedures (Syngress, 2013). I don't find any entry in the index on digital signatures or encryption, though, … but that may only mean indexing may be sub-par. It may be somewhere in chapter 9 (Case processing) or chapter 10 (Case Management). (I just got my copy, and I'm having some difficulties reading it – see separate thread.)
(Added No, it seems to be in chapter 8, section 8.7.3 Transport. Where it basically says that evidence collected from an Incident Scene must be hand-carried or escorted back to the Forensic Laboratory and its Evidence Custodian. Use of car is permissible, if it cannot be hand-carried … and that Couriers should be avoided unless they can guarantee hand-to-hand contact with no overnight stop in courier hubs – but if they are used, they must sign chain of custody. Postal services are out. Electronic transmission doesn't seem to be covered, but on the hand-to-hand principle, would need some kind of VPN solution.
I should say that the chapter reads like an de-identified company policy, so don't take it as 'you must do it like this', only as 'this is how X does it' … or 'what we suggested X to do' … or something on those lines … )
Still it seems to me that IF the issue was before
"How to make sure that a physical object[1] containing "plain" data is not mingled with during transport?"
Now it is
1) "How to make sure that a physical object containing "encrypted" data is not mingled with during transport?"
AND
2) "How to make sure that the encryption key is not intercepted/revealed during transport/delivery?"
but also
3) "How to make sure that the encryption key is not lost, mistyped or corrupted?"
As said hashing/signing the data (plain or encrypted) only answers the slightly different question
1) "How to make sure that the data has not (or has) been mingled with?"
and still you will have the same additional issues
2) "How to make sure that the hash is not modified during transport/delivery?"
3) "How to make sure that the hash is not lost, mistyped or corrupted?
The main answer is still a proper chain of custody of the evidence.
However let's see what happens in different cases when *something* goes wrong 😯 .
"proper" chain, no hashing, no encryption
No way to know if data was mingled with (but "improbable" because of the correct chain of custody).
"proper" chain, no hashing, encryption
1) If encryption key was compromised, no way to know if was mingled with (but "improbable" because of the correct chain of custody").
2) if encryption key was modified or lost, NO data
3) if - for whatever reasons - a single byte changed in the data, NO data
"proper" chain, hashing, no encryption
1) if hashing key was compromised, no way to know if was mingled with (but "improbable" because of the correct chain of custody").
2) if hashing key is lost or modified/corrupted accidentally, the suspect that the data may have been mingled with (still "improbable" because of the correct chain of custody") but however 100% of data
3) if - for whatever reasons - a single byte changed in the data, , the suspect that the data may have been mingled with (still "improbable" because of the correct chain of custody") but however 99.9999% of data available
jaclaz
[1] Still in my idea that the RAM dump is saved in a physical storage media and that this latter is transported from acquistion location to laboratory