This post is a quick analysis of an interesting lunchtime keynote here at the ISSA Summit in Los Angeles, with a broad range of speakers and interesting topics.  This one particularly touches my heart because it forces us to think about negative consequences, versus positive incentives and how difficult that balance is.

Ask yourself something -who pays for the security bugs in the enterprise software you buy to be fixed?

What about all of the hidden, often forgotten costs?  I address that in this post, and tell you a little bit about what we're doing to alleviate customer pains in this area.

It's not often I get to welcome one of my local friends into the HP family - but today is one of those days.  Many of the Chicago area locals already know Nick well, but in case you don't - I'd like to be the first to officially welcome Nick Donarski -@Kizz_My_Anthia - to the HP ShadowLabs team.

Every once in a while something from the real world gives us in the Information Security world a peek into the 'real world'.  As I read about the various hacking groups out there trying to force better security I can't help but think back to a book I read way back in high school.  The book is called "Bartleby, the Scrivener" and it was written by Herman Melville, back in 1853 and it offers remarkable insight into the perceived fight that we all feel we're fighting to force our enterprises to adopt better security.

A while ago we put out a survey that asked the following question:

"Are you getting the agility you expect from your Cloud?"

By the way, in case you haven't answered the survey yet - please click here and do so, and spread the word to your colleagues.

Today, at TakeDownCon here in Dallas I brought up a term during my offense keynote that I thought everyone in the audience would, and should, be familiar with.  The concept of Root Cause Analysis (RCA) should be a familiar principle to you if you've ever worked the defensive side of information security (or warfare) or if you've ever done any software reverse-engineering or hacking.  RCA knowledge isn't limited to hackers - anyone doing any sort of incident response should be familiar with performing root cause analysis to identify failures' roots, to unmask the source of a failure and figure out how to keep it from happening again.

In the final chapter of the Logging: Opening Pandora's Box series we'll talk our way through getting to a state where you're actively getting a new level of awareness from out logging capabilities.  Awareness is defined as the ability to know, understand and react to various types of events in near-real-time in order to defend your enterprise.  Whether you're defending it from performance failures, functionality failures, or security failures is dependent on the group you work in - but we'll tackle that another time.

Continuing on with the series on logging titled "Opening Pandora's Box" we move into the third stage of realization - paralysis.  Once you've gotten through the first two stages of anxiety and elation to this third stage - I think you find yourself a little overwhelmed.

Today I'd like to pose a very simple question that's been troubling me for a while now - Why do efforts to build and maintain software security programs keep falling off the priority table in the budgeting cycles at even the "big enough to know better" sized organizations?  It's a question I've been wrestling with for some time now and a few conversations with some very intelligent colleagues from companies you would definitely know at InfoSec World and other venues over the past 3 months have got me perplexed.  Perhaps the answer to this question comes down to corporate culture, enterprise priorities, or maybe it's something else entirely.  Without pointing fingers, this post is dedicated to those who continue to struggle with software security long after we all think everyone should "get it" by now...

In the Converged Cloud, information security departments have to make a choice.  Either adopt the new security paradigms, learn to let go of control and adopt governance, or risk becoming irrelevant.  A bold statement, sure, but one that I feel strongly reflects the reality of the collision of security and the cloud.

In a previous post [Logging: Opening Pandora's Box - Part 1 (Anxiety) ], I started us thinking about the Pandora's Box that is your enterprise logging function.  In this post, we get past the anxiety that you were feeling and start feeling good about logging.  More than just feeling good about logging, we're starting to feel great about what logging can do for us, and how it can improve our enterprise security posture.

This post kicks off a series of posts titled "Opening Pandora's Box", that will cover the untapped wealth that is your corporate logs.  After talking about logging with some people in the customer space, and our engineering and research groups back here at HQ, it's clear to me that logging is more than just something that everyone should be doing ... it's like a Pandora's Box that many organizations are almost afraid to tap into.  I thought it would be a good idea to explore this more, so kicking off this series is phase 1 you'll probably go through when you start thinking about logging - anxiety.

A while back I wrote a blog post explaining the difference between NoOps and DevOps - with a slant from the Information Security perspective.  If you haven't checked it out yet, I encourage you to do so as a primer to this post, and to get a more grounded understanding of where my head's at when it comes to addressing the NoOps movement.  Is NoOps just another excuse to forget security?  Or do we (Information Security Professionals) actually have a chance to affect fundamental change in how code gets deployed in a risk-averse manner?

If you missed THOTCON 0x3 and Chicago's Security BSides I will tell you, as will others, you missed a pair of events that were cross-sectional to how Information Security is evolving.  The two conferences were back-to-back and mixed technical presentations with accessible speakers to try and continue to build a sense of community in sweet home, Chicago.  I can't say everything was roses and rainbows though, as a few of the discussions that were exhibited demonstrated just how poorly defined and understood the practice of information security really is.

Have you ever attended a professional conference only to find yourself spending more times talking to your peers in the hallways than in the actual structured tracks?  I've done it, and I am seeing it happen more and more in the industry so I want to familiarize you with this thing we refer to as Hallway Con and why you need to care.