[EMAIL PROTECTED] (Stephen Mednick) writes: > it's not a case of how valuable the data is, more importantly it's to > do with what the security classification is that has been assigned to > the data. Depending on the data's security classification dictates the > media overwriting/sanitisation method that is it be deployed in > accordance with government requirements.
security classification is simplification ... like role-based access qcontrol is simplification for permissions. ... recent post on dealing with permissions http://www.garlic.com/~lynn/2008b.html#26 folklore indeed the issue normally reduces to what is the threat model? security classification tends to be associated with threat model where divulging the information is not desirable ... and classification level attempts to make the measures to prevent information divulging proportional to the damange that might happen if the information is divulged (and/or the effort that an attacker will go to in order to get the data). For magnetic media this might be something like overwritting a specific number of times with (different) random data ... nist standard: http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf An example of how this gets simplified is example of consumer financial information stored at a merchant. The "damage" gets translated into security proportional to risk ... and the risk is what is the value of the information to the merchant ... old post on the subject: http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk The problem is that the real threat model and therefor risk, is that the value of the information to the consumer (and to any attacking crook) is possibly one hundred times larger than the value of the information to the merchant. The merchant is required to keep transaction logs (and the associated account numbers) for some period as part of mandated business processes. The information value (to the merchant) is some part of the merchant's profit margin on the transaction ... for hypothetical example for some number of product transactions, this could be $10,000. The value of the information to the crook, is related to the credit limits associated with the individual accounts. This could conceivable be $10,000,000 (totally unrelated to the value of the information to the merchant, i.e. some portion of the profit on the purchased products). Since the value to the crook can be 100 to 1000 times larger, the attacking crooks can afford to outspend the defending merchants by possibly one hundred times. in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. Part of this was looking in detail at end-to-end vulnerabilities and threat models ... as part of coming up with x9.59 financial standard http://www.garlic.com/~lynn/x959.html#x959 part of the x9.59 financial standard was eliminating the usefulness of the account transaction log information (at merchants) to attacking crooks .... i.e. it didn't involve trying to prevent attacking crooks from getting at the information ... it just made the information useless to crooks for performing fraudulent financial transactions. A different example was we also got involved in co-authoring the financial industry x9.99 privacy standard. As part of that we had to look at both GLBA and HIPAA (financial transactions can used for medical procedures which may be listed). One of the issues in HIPAA is that there is a real requirement to make some amount of medical procedure information available. At a result, HIPAA allows for information to be available if it can't be associated with an individual (aka "deidentified"). deidentified Under the HIPAA Privacy Rule, data are deidentified if either (1) an experienced expert determines that the risk that certain information could be used to identify an individual is 'very small' and documents and justifies the determination, or (2) the data do not include any of the following eighteen identifiers ... snip ... As part of working on x9.99, we put together a privacy merged taxonomy and glossary ... see: http://www.garlic.com/~lynn/privacy.htm for other details see notes at http://www.garlic.com/~lynn/index.html#glosnote ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
