The other way you can approach whitelisting is using digital certificates and software signing. Most software now is signed – which guarantees it has not been altered or corrupted since it was signed – and you can work with certain lists of certificate issuers or certificate signers. Within the certificates you have two elements: you get the issuer's verification, like VeriSign, while the signers are organisations like Google or Adobe. When you have something signed by Google you generally trust it; however, although it may be signed by Google, you also have to figure out the issuers, because there are some dodgy certificate providers who will provide signing for a little bit of cash. You have to make sure that both the issuer and the signer are trustworthy. But sometimes even malware gets signed; it's really quite a complicated situation. On top of that, the certificate infrastructure has at various points in time has been infiltrated, compromising the assurance they provide. This means that by themselves, relying on certificates for whitelisting is not enough and that’s where our proposal comes in.
Richard Pain: How does your new machine learning technique for application whitelisting work?
Dr Oliver: What we're seeking to do is to automate the technical validation of applications in a way that is sensible. For some software, new updates can come out on almost on a daily basis and are listed on a company’s whitelist so fast. Each version might be similar and it might be signed, but that’s not an indication that the new version is necessarily safe since it’s possible to remove a little bit of code and put in a little bit of malware. Instead we’re suggesting a technique using machine learning called locality sensitive hashes (LSH) that can actually check the similarity between software versions. When this is combined with digital certificates allows IT managers to quickly inspect a piece of software and say it's good to go.
There’s also another situation which occurs commonly in enterprises. Often they generate their own software and they don't want to spend time mucking about every time they update it to make it work with their whitelists. Now with our new technique, all they will have to do when they recompile their new versions is to get it signed, then our machine learning tool will detect whether it’s sufficiently similar to their previous versions. Using this approach you do not have a single point of failure, making it difficult for cyber-attacks to subvert the whitelisting system.
Using these three approaches together – whitelists, certificates, and LSH – will provide a convenient way for enterprises to ensure the software is safe, even when it has just been updated and is not on a whitelist yet.
Sign up for CIO Asia eNewsletters.