"What do you say to organizations considering software security, but struggling with adoption due to the inevitable, additional drag on release cycles?" -- I say read this, because there is a discussion to be had, still...

Lots going on in the enterprise space right now, including the rush to push out mobile apps. They're springing up like weeds, replacing websites, and are gaining multi-factor authentication for security... but wait, does any of this added security make sense, especially on the mobile platform?

Let's investigate.

Have you ever had a vacuum salesperson come to your door and offer a free demo on why their vacuum is 10x better than your existing unit? I have, and a recent pitch from a vendor I saw reminded me of this little trick...

Wrapping up the 5-part series "Deconstructing Defensible" we need to talk about the what, why, from whom, how and when of defensibility. These are key questions that need to be asked - and answered - while shifting your mindset from 'security' to 'defensibility'.

Every time someone says "Big Data" a collective cringe travels across the information security industry, like a disturbance in the Force. Some security professionals simply shrug off the term as a fad, or marketing buzzword. While the hype around big data has absolutely been marketing-driven lately, there is a very real need for Big Data style analysis in security...

This post is from a guest-blogger, Dan Houser, who read one of my previous posts and decided to expand on the point and add his own viewpoint on managed versus unmanaged technical debt ... it's a very interesting read I encourage you to take a minute to consume...

What's the difference between secure and defensible?

It becomes more clear when we revisit the old, tired analogy of the castle model of security. Tough outer defenses meant to keep the 'bad guys' out, but once you're inside you've got full access to everything as if you belong. This thinking just doesn't work in today's modern enterprise... Let's talk about why and what we should be doing about it.

It's hard to find someone who will argue that technical debt isn't a valid reason to do security (or really, any type of defects) fixes early and often. The further away from the point of origin, the more expensive - and this is definitely a valid argument except when it comes to a few edge cases... and then technical debt is gladly paid.

Strategy. Tactics.

These words are two very different but cannot exist without the other in the enterprise security context. While speaking on these two issues, I've found it important to write a post that explains how I think about these terms to help level-set the conversation...

Twitter was hacked.

There is a lesson to be learned and broadly applied to enterprise security here...Rather than focusing on the on the negative, let's look at the positive here... wherein Twitter was able to detect, respond and restore to minimize the impact of the breach.

There are entirely too many organizations out there, of all maturity levels, that are building their defensive capabilities tailored to today's threats. Whether it's Anonymous, APT or something else with a big scary name, they're spending time being reactive to the specific threat rather than defending their business strategically. Today's media briefing roundtable was interesting in that it presented an alternative, more sane viewpoint...

In many organizations, it's painfully obvious that the maturity of the Information Security organization lags significantly behind the maturity of the business and its processes. Why? This relationship in maturity appears to be hinged on the relationship between the business and Information Security itself, and whether the two components of the enterprise are partners, or simply some level of adversary... 

Security OPS teams are often limited by their own rules. When an event is suspected, the only people allowed to have knowledge and information about the suspected event are security people, which limits not only the effectiveness of that investigative body, but also the effectiveness of detection, early-warning, and response ultimately. This need-to-know problem is the reason why many organizations have separate IT OPS and Security OPS event managers, ticketing systems, and investigative processes... 

Poor software quality creates fragile ecosystems in software.

A great piece I read recently made me think about the ripple effect software quality can have downstream and how waves get bigger the further they are from the source...

Another massive Java vulnerability.

This time the U.S. Department of Homeland Security steps in and says "disable Java!"... but while that may be a good idea for the average home user, where does that leave the enterprise which is stuck with Java as a desktop requirement?