Blog of Jeff Forristal, Security Professional en-us Tue, 20 Jun 2017 00:00:00 -0700 <![CDATA[Understanding the security activity portfolio]]> Understanding the security activity portfolio

There are a lot of different ways to approach security and risk management. If you are a large organization, you may be able to afford to try lots of various security tools and activities, to see what works for you; but if you’re a smaller entity, or your risk management program must face the realities of budget and resource constraints, you need to put more thought towards where you invest.

I strongly believe the security industry must continually look for ways to improve the standard accepted approaches to risk management, for better efficacy towards making security defense cost-effective and driving ubiquity across the digital world. I’m excited to see how security visionaries are rethinking classic security concepts such as penetration testing, and what new advantages that can bring to the table. And I truly do mean rethinking for better effect, not just marketing gimmicks or finding a benign way to add machine learning to the mix for the sake of marketing “me too” ML-era advantages.

Through conversations with some associates at, I became motivated to look deeper at how crowd-sourced security approaches (bug bounties, penetration-testing, etc.) are faring. After all, these new approaches have now been around long enough to produce execution metrics/track record to juxtapose against the mainstay security activities. Have they graduated to find a permanent place in the security activities portfolio? Are they proving cost-effective for the results they are bringing? Are they bringing results that can be had better or cheaper via a more classic means?


Tue, 20 Jun 2017 00:00:00 -0700 <![CDATA[A collection of crypto performance measurements]]> A collection of crypto performance measurements

It’s happened many times in my career, including as recent as circa late 2016. I encounter a fairly new codebase that is actively using MD5 for some purpose. When I inquire about the choice of MD5, I hear a well-meaning software engineer say:

We chose MD5 for data integrity because it’s the fastest.

Not only is MD5 insecure for such security usages, but even the legacy notion of it being the fastest hashing algorithm is suspect given how the latest CPUs include feature sets which, when combined with newer 64-bit algorithm designs, simply challenge everything we once knew about crypto performance on particular systems.

In fact, it’s become unintuitive to really say what’s the optimal choice for certain systems. Crypto performance has varying characteristics and tradeoffs depending upon whether we are talking about a 64-bit x86 Xeon server, a 32-bit ARM mobile device, or an 8-bit microcontroller. On some systems, SHA-512 can outperform MD5 and SHA1; on other systems, that’s not the case.

So how do we know what those tradeoffs are? If we have to pick single target algorithm to support a diverse ecosystem of device types (think: a service used by desktops + mobile + IoT), what’s the right balanced choice that gives us the best available security with reasonable performance by the meekest device in the ecosystem?


Wed, 28 Dec 2016 00:00:00 -0800