Fairhaven, The River

Audit and accountability (HIPAA) lecture

Anupam Datta of CMU gave a good lecture at Microsoft Research, available here.  Healthcare privacy (HIPAA), financial regulations (Sarbox), and others are shifting to the use of audit and accountability rather than access control methodology.  His lecture discusses this from the perspective of the external control system.

First, he agrees that this is the right way to handle the increasingly complex issues that must be accomodated.  Access control methodologies will founder and flail, either not delivering the desired privacy or not delivering the desired services.

He then discusses the theoretical basis for analyzing and using audit as a control method.  The really hard problem is dealing with the real world data gaps, and with the inherent uncertainty of interpreting events.  In his terms, you need an "oracle" to take the ambiguous situations and decide whether these events did or did not meet the regulatory requirements.  The dominant need for the "oracle" is to answer questions around purpose, intentions, and plans.  He explains the semantic issues involved.

This need for an "oracle" to answer otherwise unanswerable questions is one reason that access control methods will fail, while audit control can succeed.  In the post-facto audit analysis you can find ways to deal with the "oracle" problem.  In the real time access control situation, the lack of an oracle results in failures.

Then he gives a high level overview of how audit logs would be analyzed.  This is at the level of discussion of first order logic, not programming requirements.  He's the first person I've heard complimenting HIPAA in a long time.  He found the highly operational nature of HIPAA led to a clean analysis solution, other than the inherent need for an oracle.  He also gives a high level first order logic equation describing HIPAA.  It's just a short simple equation.  He's right, HIPAA is a clean set of requirements when viewed properly.

 

Android 4.0 smartphone encryption

A risk analysis of smartphone encryption.

I just got a new smartphone with Android 4.0, which has the option to encrypt the smartphone contents.  I found the details of how it works here.  Short form: It encrypts the /data partition.  This is everything user specific, downloaded, etc.  It can recreate a factory reset blank from unencrypted boot capability.  The internal data is AES-128 encrypted using the same password as is used to unlock the phone, after hashing.  There might be a back door, but it seems unlikely.

Short form result: It's not worth it to encrypt. Password protected unlock is sufficient for my risk profile.

Analysis starts with the assets to be protected.

• Personal information on smartphone (data, apps, etc.).  I can keep this minimal.
• Traffic data (call history, etc.)
• Financial loss due to unauthorized use
• Smartphone itself.
• Ability to reprogram smartphone, e.g., cyanogenmod.

Risks:

• Accidental loss, e.g., I leave it somewhere
• Random theft, e.g., pickpocket
• Targetted theft, e.g., personal enemy
• Random surveillance, e.g., routine copy on arrest by police
• Targetted surveillance, e.g., FBI is after me.

The encryption is vulnerable to dictionary attack primarily.  The password has to be something that I'm willing to enter every single time I use the phone.  This means that the password will be easy to enter.  That means it's going to be small.

So, the impact on assets if encrypted will be:

1. If accidental loss, a) it will not be returned, b) it will not be compromised, c) phone will be factory reset and resold most likely.
2. If random theft, the same as 1)
3. If targetted theft, they might have the resources to use a dictionary attack, but unlikely, so the same as 1).
4. If random surveillance, it will increase their interest in me and they probably have to tools to break in.
5. If targetted surveillance, they will break in.  I'm not going to make my life miserable with a long difficult password.  Someone like the CIA will have the computer power to succeed with a dictionary attack.
6. Once encrypted, attempting to root or reprogram the phone will probably brick the phone.  So encryption destroys this asset.

Results for unencrypted are:

1. If accidental loss, a) low probability it will be returned, b) it will be compromised, c) phone will be resold, perhaps without a factory reset.  This is based on experiments with leaving cell phones to be found.  Financial abuse is likely.
2. If random theft, a) it will be compromised, c) phone will be resold, perhaps without a factory reset.  Financial abuse is likely.
3. If targetted theft, random surveillance, or targetted surveillance, it will be compromised.  Financial abuse is less likely.
4. Rooting and development use remain possibilities.

The intermediate case of locked but not encrypted greatly reduces the odds of compromise for accidental loss or random theft.  It's not that hard to trick these phones into letting you copy a memory image out via USB.  A random thief won't bother, because that's only useful if the goal is access to data.  Locking but not encrypting changes the low probability of return for accidental loss into a zero probability of return.  It doesn't seem to change anything else.

This leaves unsettled the odds of various events.  In my case, the odds that I'm a surveillance target are low  and the potential interest in perhaps rooting the device is high.  There is no need to put high value data on the phone, and there is no regulatory need to encrypt the phone.  So locked seems sufficient.

If I had protected health information or high value commercial information this encryption is adequate only if the information is not the target.  For interesting targets, like professional athletes, it's not adequate.

If you're a political activist, union organizer, etc., the analysis of cellphones remains unchanged.  Get a steady flow of cheap dumb phones and multiple SIMs.  Remove SIM and battery except when you must make a phone call or check voicemail.  Leave SIM, battery, and phone at home whenever on business. Get a separate "for arrest" phone and SIM that you use only when going to demonstrations, etc.  Don't depend on encryption.  It will be penetrated.

Defining Metadata

Summary:The Dublin Core work leaves out the importance of establishing an intended use as context for metadata.  Having this context then makes their level of interoperability and some of the issues around metadata storage much clearer.

Dublin Core leaves out the importance of intended use when discussing metadata.  It may be too obvious to those close to the problem. Their definition
      "Metadata is data about data>"
while correct, is insufficient.  All data is metadata from some context.  A clearer definition is:
      "Metadata is data about data, that is useful in a specific context of intended use."

Johm Moehrke's post gives good examples of the kinds of intended use that are important for medical records.

It makes sense to say that PatientID is metadata about a document in different contexts:

• It could mean that "This document is about PatientID"
• It could mean that "This document references PatientID", e.g., a document about a child references the mother.

You need the context of a use to understand metadata.

The context of use also explains the levels of interoperability that are otherwise left dangling by the Dublin Core.  The degree of interoperability is in the context of the intended use.  An example of the lowest level of interoperability might be a piece of metadata called "license".

At the lowest level, that word "license" is all you know about the metadata.  You can only guess about possible meanings.  You don't know the format of "license".  Maybe it is a text blob that contains legal language.  Maybe it's a URL to a document in an unknown format.  Maybe it's a UUID.  This is the lowest level of interoperability and it makes automated processing nearly impossible. But, it's an important improvement over having nothing.  There are many situations where this vague hint is sufficient information for a person to figure out what to do.

At the highest level, you find something like "diagnosticCode", with a specification that it is to be encoded as an HL7 CWE, with a value selected from the 2011 XYZ profile value set.  Now I have the semantic meaning, the format, the vocabulary, complete version information, and can perform extensive automatic processing.

It's important to separate the discussion of metadata, intended use, and degree of interoperabilty needed in early discussions defining metadata.  They are different concepts.

Another issue that is not mentioned in Dublin Core is the decision of how metadata is stored and conveyed.  This is an interface and exchange problem only.  Within any processing system you don't need agreement with others about how any data is stored or conveyed.  But metadata discussions do need to understand that when exchanging metadata there are three possible situations:

• The metadata may be embedded in the document, and not otherwise exposed.  This means that it is only accessible to systems and people that understand the document format.  An example of this could be "patient's mother" or "KVP setting".  These are metadata for some rather specialized uses in genomics and procedure analysis.  An indexing registry for medical records is unlikely to maintain these as a separately stored metadata index.
• The metadata might only be available as a separate item.  The hash value for a document is almost never stored as part of the document.  It's use is as a separate piece of metadata used by the privacy, security, and integrity systems.
• The metadata might be stored both as part of the document and as a separate item.  PatientID is often stored both ways.  When using patientID as part of finding and selecting documents, it is appropriate to have separate indices for many reasons.  But when processing those documents, it is necessary to have that patientID information in context within the document.  This does lead to some considerations about consistency rules when defining how the metadata is to be used, and that is normal.

 

Definitions matter (median income statistics)

Summary: definitions matter much more than I expected.

There have been lots of public opinions about the change in median income in the US, and what it means for policies.  It turns out that the definition of median income matters much more than I expected.

This table shows the increase in percentage from 1979 to 2007, for those who want the answer up front:

Income Included	Tax Unit	Household	Size Adjusted Tax Unit	Adjusted Household
pre tax, pre-transfer	3.2	12.5	14.5	20.6
pre tax, post-transfer	6.0	15.2	17.0	23.6
post tax, post-transfer	9.5	20.2	25.0	29.3
post both, plus health insurance	18.2	27.3	22.0	36.7

The widely reported figure is the 3.2.  This is used to argue that there has been no improvement.  All the gains have gone to the top 1%.  The middle class is being hollowed out.

The different definitions make for a more nuanced answer, and reflect difficulties in getting data.

The different terms are:

• Tax Unit is the tax filing unit.  This is what the IRS tax statistics report.
•  Household is what you would expect.  It's all the people in the house.  So everyone in the household is combined.  This captures the effects of grandparents, parents, and children all being potential earners and sharing income and expenses.  It also captures unmarried couples, shared custody, etc.  The IRS statistics don't capture this, but the monthly Census survey does.
• Size adjustment modifies the income using the same adjustment as is used for cost of living.   A family of four needs more income than a single person, but not four times more.
• The kinds of income reflect regular wages/dividends, transfer payments like social security or food stamps, and finally health insurance benefits.  These variations also reflect data gathering.  The IRS can measure some transfer income, like the EITC, but not other transfer income, like food stamps.  EITC and food stamps are two very large social welfare programs in the US.

A recent paper is interesting in that it works from the census bureau data rather than the tax data.  This lets it measure households, transfer payments, and health insurance.  The tax information can only measure tax units.  They compared their results with the tax data and confirmed that they matched when measuring the categories that the IRS can measure.

My Conclusions:

• There is no "right" number.  The proper issue is what is the question that you are trying to answer.  The shifts in households, with grandparents and adult children moving back together with parents may be a compensation for economic hard times.  These numbers show that it works and has more than compensated for income loss.  Health insurance costs have gone up dramatically, as these numbers show.  Transfer payments and a progressive tax rate do appear to have a significant effect.
• The "middle class is vanishing" is at best misleading. 

Paper is at http://www.nber.org/papers/w17164

There is some more data on trends in household sizes, etc.  There is also a breakdown of quintiles.  For the all included houehold category, the bottom quintile saw 26.4% growth and the top quintile saw 52.6% growth.  The top 5% saw 63% growth.  There is no data for the top 1% because privacy related data blinding was applied by the census bureau, and only larger aggregates are reported.

So you can argue that all parts of the population saw significant improvement, or that the rich saw a larger improvement, or that the middle class is suffering.  The data shows that the progressive tax rate (EITC included) does have an effect, transfer payments and the social programs do make a difference, and that healthcare benefits do make a difference.

 

Dell U2711 and getting full resolution

The documentation from Dell and others is utterly atrocious, so people like me write posts like this to help others with their setup.  First, although Dell never documents this, these are the limits for various kinds of input:

• DisplayPort can do the full 2560x2048
• DVI-I Dual Link can do the full 2560x2048
• VGA can only do up to 2048x1152.  (Interpolation makes text a bit fuzzy.)
• DVI Single Link can do up to 2048x1152
• HDMI I can't test properly.

Then there are the variations of support by various systems.  Vendors do not document their hardware well enough to know what will work without trying it.  I have found:

• MacBook Pro with MacOS, DVI-I Dual Link is supported at full resolution
• Intel D94GZIS with Windows 7, DVI-single link at 1600x1200, DVI-VGA Adapter at 2048x1152
• Intel DH67CL with Linux and Intel Driver 2011Q3, VGA adapter to DVI works at 2048x1152, DVI only up to 1600x1200
• Dell Latitude 630 in Docking Station: DisplayPort at full resolution

The documentation and connector for the DH67CL claim dual link capability but after various experiments I've found no way to configure the driver to use it properly.  Documentation of the Intel driver provides no information about dual link setup.  The default configuration did not set it up automatically.