How do you measure anything? Generally metrology, the science of weights and measures, involves the analysis of a sample against a standard reference model. In the case of physical measurements the Standard Reference Materials (SRM) are used as the calibration standard. So then, how do you measure software, which is merely a collection of electronic binary digits (bits) representing programs, graphics, and documentation?
Everyday, we download or install software onto our laptops, desktops, servers and PDAs with no understanding of what it is we’re actually getting. Mostly it’s a specific software vendor’s reputation or a promising new feature that drives us to blindly point, click and install, update or upgrade our software. It’s interesting to note that all of the methods that control the delivery and usage of that software are covered and controlled by standards developed to span the seven layers of the OSI Model, but when it comes to the measurement of the software at layer seven, for quantitative, qualitative or authoritative results, the user is left with nothing but hope. Hope that he hasn’t introduced malware or instability into his platform.
But there are technologies today that can be used to provide proven and effective compact measurements for software. For example, One-way cryptographic hashing functions, such as SHA-1, easily transform large bodies of bits into definitive short-hand signatures (also called fingerprints) that uniquely represent the original source data. When the source data is widely distributed, anyone can generate the same cryptographic hash and, if it were available, could compare it against the source hash to verify the authenticity of the data. A change to any single bit of information would result in a completely different fingerprint, enabling immediate detection of alterations. The main point here is that the sample data must be checked against a known reference in order to determine it validity.
Anti-virus vendors use similar techniques to generate black-lists, a list of fingerprints for known bad software. An AV agent collects sample measurements from the software on the target platform and compares them against a reference of undesirable elements. With this comparison certain policies can be triggered such as isolating and/or inoculating the unwanted or malicious code.
But wouldn’t it be more effective if this method were inverted? Enable the use of proactive measurement and validation techniques (also called attestation), to sample software and then compare against a known and trusted reference. By using this “white-list” method the policy method for enforcement is grounded in and extended up from a source of known-good values and would allow only positively identified samples to run in the environment.
But here are the tricks:
How is the white list (the standard or trusted reference) derived, maintained, managed and effectively deployed in the IT enterprise?
How does one minimize or avoid false positives (apparent dangerous is really benign) or false negatives (apparent benign is really dangerous)?
How is trust “grounded” and normalized, and can we provide the desired zero-knowledge-proof?
And is the white-list method mutually exclusive from the black list method described above?
More on these issues in follow on blogs. Your thoughts are welcome.