Friday, March 20, 2015

OpenSSL Is No Reason To Go All Twitter

Recommendation::Crypto
Audience::Intermediate
UUID: b3ae8f36-426c-4b6c-9464-19033c6808e5

Must...resist...the Power of the Force.

I have never been so tempted to post a few very snappish things that really could be effectively done in 140 characters. Security drama marketeers that were hoping for another major flaw in OpenSSL yesterday, instead of a DoS attack, etc.

On Twitter, security seems to be all about teh drama, and I am on record that Drama Indicates FAIL.

OTOH, OpenSSL does deserve come comment. It is so widely deployed that it might justifiably be regarded as Critical Infrastructure, though that term is also drama-bait. Cyber-attacks. a) Oh noes, run in fear, or b) evaluate it in terms of your threat model, and make rational decisions. I am big fan of b.

It turns out that there is a very good cheat-sheet for OpenSSL. Ivan Ristik has published a revision of OpenSSL Cookbook. It isn't exactly how I would would have done it, but then Ristick has absolutely no need to emulate some random guy that gets a few hundred hits per month. Because Ivan Ristik, who is a major talent. You have to register to get it in one of several formats, but it is a worthy update. You can also download Apache Security, and Modsecurity Handbook after registration

It does lack a few things, such as an explanation of compiler options, which are pretty much out of scope for a brief overview of the high points. And the openssl speed -evh command-line option will not have any effect on at least some Intel Ivy Bridge CPUs. Though -multi (n), which tells 'openssl speed' how many cores to use very much will. In my tests, it scales in a very linear fashion, as expected. I still have to do plots of cores v temp. Maybe next week.

I note that speed(1), on my system, does not document all command-line options. So, for instance, not knowing about '-multi (n)' will cost you a verification test.

TODO: update the OpenSSL Position Paper.













Wednesday, March 18, 2015

(Some) Books That Seem Important To Me

Commentary::Personal
Audience::All
UUID: 796fa48c-2be5-4e09-a181-a3a3c00bc4a0

Have an image of a stack of books. They are all worth writing about, in contexts that may be surprising. That one on the bottom? SPAM NATION was a recommended purchase in Just Buy Spam Nation. It became a best-seller, which had nothing to do with my efforts (this site only gets a few hundred hits per month), but because Brian Krebs rocks, in terms of consumer security. Which is why I recommend his site. Pardon me, but I seem unable to force my fingers to type 'Blogroll'. It ranks right up there with 'Blogosphere', in terms of suckage.

I mentioned some of these in Four Books on Order, back on March 9.



Followers (both of you) may note that I am now including an Audience identifier, and a UUID. More on that in a future post.


Tuesday, March 10, 2015

Namespaces Continue to Annoy Me

commentary::namespace

I do not know who this guy is, but I dropped this into a quotes file long ago. Because he obviously had a better handle on the situation long before I did.
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
 There are a couple of other things that I cannot really validate, related to personal names. Such as an ancient note reminding me that a full name can consist of a single ASCII 'a' (doubtless transliterated)', which can occur in Indonesia. That note is really old, does not include a source reference, and I am sadly lacking Indonesian friends.

As a personal aside, I have to mention that you might be sad too, if you both knew how wonderful Indonesian cuisine can be, and lacked a source of ethnic Indonesians friends to mooch off of. That is pretty sad state of affairs, but I digress.

A 2010 post listing 40 potential errors related to just personal names, opened my eyes, and not just to the current madness I am contending with. I don't know the guy, but was impressed enough to drop into the reference system. Falsehoods Programmers Believe About Names is still entirely relevant.

What makes it truly FUBAR is that this doesn't just touch on security fundamentals. It goes to the roots of how authentication and authorization is done. In my experience it is easy to find errors related to this problem, to the extent that it gets a bit boring. So, all you SysAdmins, DBAs, Web developers, etc., please take note

Also, please do not forget about multi-byte character representations v ASCII. There are a lot of problems with libraries that lead to issues with sanitizing input. The world thanks you in advance.

Knock-on Effects of This Problem, as Related to Policy

  1. It can effect the usefulness of the entire concept of policy. Requiring username standards such as firstname.lastname can become silly, and be easily seen as silly. Breeding contempt for policy is probably not your goal, so please do not do this.
  2.  The effects of item 1 require weird workarounds for the people in the trenches, doing the admin work. Policy flaws have now propagated from users to admins. This is not a win.
  3. The combination of 1 and 2 can build into a situation where it is is impossible to audit who has access to what. As different groups will establish different workarounds, recovering from a breach becomes more difficult. That is pretty much the last thing you want.
  4. Even minimal security training for new employees becomes difficult, as you are effectively indoctrinating them in the belief that security policy is something to be circumvented. 








Monday, March 9, 2015

Four Books on Order

Commentary::Personal

Now and then you have to blow a hundred bucks or so on books. A Safari subscription at O'Reilly subscription can save you quite a bit on professional expenses, but at the end of the day, you often have to cough up some additional cash.

Today, the total was 4. One does not count: The Hydrogen Sonata, by Ian Banks. Pure entertainment.

So what does count? The following three.

  1. Hackers - Steven Levy. I am looking for support for my argument that the crypto wars never ended. The NSA would then be a continuing chapter in that game, as described very well by any Bamford work you would ever care to read. _Hackers_ is on my Safari bookshelf, but that is not the same thing as being able to refer to page numbers in the original edition.
  2. How Learning Works: Seven Research-Based Principles for Smart Teaching - Susan A. Ambrose. Widely acclaimed, and we damned sure need better methods of teaching security. Or any other subject, for that matter.
  3. Capital in the Twenty-First Century - Thomas Piketty. This book has already had enormous press, so I won't write much about it here. I will mention that I regard economics as a highly-politicizied proto-science, at best. But without bringing economics, in whatever state, into the mix, neither security practioners or researchers can really have much much effect. 

Wednesday, March 4, 2015

Timeframes: Immediacy Trumps Traditional Academia

commentary::internals::blog

The time has come to leave the ACM. So those side-bar links will be going away. I am a security practitioner. I don't regard what I do as primarily about software engineering, or computer science. It touches those fields, as well as statistics, visualization, {systems, network, database} administration, compliance, and much else. But this is mostly about bandwidth, and the ACM does not currently represent an optimal use of an always-scarce resource: time. Staying informed, in the security field, is a hard problem. Just as it is in any other technical field; we are not special snowflakes.

The ACM has annoyed me a few times, and I'll mention a bit of that. But I will not use the current "Let me be clear" phrase. I only need some modest amount of skill in written communications to be clear, not the permission of an audience. If you interpret this post as a rant, I will have failed. Failure sucks, but not as much as failing without knowing it. Comments are welcome, not least because I may have totally missed the boat on this, and insight from someone I have never heard of might completely change my view. The Internet is useful for more than cat pictures.

First off, here is one case (there are others) that the ACM makes. These are notable people, and they are all in favor.

Bryan Cantrill, Vice President of Engineering at Joyent, Ben Fried, Chief Information Officer at Google, and Theo Schlossnagle, Chief Executive Officer at OmniTI, discuss motivations and benefits of joining the Association for Computing Machinery (ACM).


A short watch at 2:45.

I am not familiar with OmniIT, but this is an indication that I should probably should fix that. Joyent employs Brendan Gregg, whose performance work will likely enable more practical security work than many realize. And of course everyone knows something, pro or con, about Google.

There are other people whom I respect quite a bit, who have written for Communications of the ACM. I will be linking directly to them in future, and I'll write about exactly why in future posts related to commentary::internals::blog.

So why would I not be renewing my ACM membership? Again, it is all about bandwidth. These people are all CEOs. They have fiduciary responsibilities, hence broader concerns, such as access to well-rounded software developers at going labor rates, media perception, etc. I have only one concern: achieving a security posture commensurate with risk.

Let's take one SIG I belonged to as an example. SIGSAC (Special Interest Group on Security, Audit, and Control). For those of you who might not be familiar with ACM SIGs: perhaps you have heard of SIGGRAPH, the graphics Conference That Got Big. CGI in movies, etc. Huge impact, because Media.

Now, back to security, which has almost no impact, despite all the data loss. Let's look at a couple of papers presented at the fourth edition of the ACM Conference on Data and Application Security and Privacy (CODASPY 2014). These are both interesting papers, in that they might have important near-term implications.

Automated Black-box Detection of Access Control Vulnerabilities in Web Applications
KameleonFuzz: Evolutionary Fuzzing for Black-Box XSS Detection

But unless I missed it, which is always possible, neither paper gives a location where you can simply go get the code, and begin experimenting. That seems a bit out of touch with the times, where fuzzing software is commonly described in other fora, and code is readily available. Much like the IETF does business, running code trumps whatever paper you might care to write, if you care to have an impact on the (rather larger) non-academic world.

That is where the people in the security trenches need to play with the code, form conclusions as to whether it is immediately useful, or how soon it might be useful, in terms of stability, performance penalties (nothing is really free-as-in-beer), and think about budgets.

This is the bit that might be perceived as a ranty bit. Again, it is not intended that way.

I have to mention that ACM ships disks of conference papers. I am sure that they regard that as a benefit of membership, but their disks include autorun files. Given the vast history of Windows system compromise via autorun, this is more than somewhat ironic. Particularly in the case of SIGSAC, where baldy stating why there is no autorun, and the lengthy list of system compromises powered by autorun, would be educational. No, research and teaching are not the same thing in academia. But this is just silly; the sooner any benefit provided by autorun vanishes, the sooner security practioners might actually succeed in getting people to never, ever, enable it. Frankly, there are major dumbass points to be awarded on this one, and I do not thank SIGSAC for making my job harder, and charging me for the privilege.

Another item is that some of the benefits might not be all that one would expect.

  • The selection of technical books is much smaller than what is available from the O'Reilly Safari service.
  • The Tech Packs are subject to doubt. I submitted extensive flaws in basics, such as broken links, in the Security Tech Pack, and those were repaired. However, nothing was updated. Particularly, there is nothing regarding security economics beyond one very old paper, despite much work done more recently. This is not a membership benefit.