Saturday, July 26, 2014

Ad-Hoc Security's Surprisingly Negative Residual Effect

Security is fraught with the ad-hoc approach. Some would argue that the very nature of what we do in the Information Security industry necessitates a level of ad-hoc-ness and that to try and get away from it entirely is foolish.

CISOs are challenged with this very thing, every hour of every day. Threats pop up that they aren't prepared for, and present an imminent danger to the business, so they must react. These reactions are necessary to keep the business operational, no one will argue that, but it is when they have a residual effect on the enterprise that we run into problems.

It's the old snowflake rolling down the mountain analogy... sort of.


How it starts

Since no security program I'm aware of has managed to account for all the threats it will encounter, let's take any one of them as an example. The threat may be some semi-custom malware which targets a particular piece of software in their industry vertical, or it may simply be something as common as a banking trojan. The CISO realizes that they simply don't have the supporting infrastructure to mitigate or help in remediation of the threat - so off to the ad-hoc bin we go.

There are, in general, three possible courses of action which follow.

First the ever-popular "we'll write some code" option. Many CISOs have access to some amazing security talent, and thus the ability to whip-up some custom-coded solution which takes care of the issue. Quite common. I'm not even saying this is a bad option! If you've got the talent, why not utilize it to its full potential.

Second, the almost-as-popular "hire an army of consultants" option. External consultants descend on your enterprise and identify, contain, and work to mitigate the current threat. Your hope is that they document their work, and maybe leave behind some clues as to what was done, why, and how you can repeat this procedure int he future.

Now for the most popular option, unfortunately, if the issue is big enough. This is the "let's buy a box" option. CISOs who feel overwhelmed look to their partners and often times the analysts to provide them with options. Not surprisingly, much of the time the 'solution' comes in a nice 2U rack-mountable appliance, with a yearly maintenance contract.

With the threat, at least temporarily, addressed, it's on to the next big issue. Playing whack-a-mole is the modus operandi for all too many in security leadership... and it's not a commentary on their effectiveness or abilities, it's just simply the way it is.

Once you've moved on from the previous problem what we have left is what is commonly referred to as a "one-off".


"One-offs"

Entirely too many networks are simply littered with "one-offs". Solutions which once served some point purpose which have either been forgotten, fallen out of maintenance or support, or simply no longer serve the greater mission of the enterprise security organization. So many of these "one-offs" don't integrate well, aren't interoperable, or don't scale ... or worse they're simply not manageable at the level that your organization needs.

The problem with ad-hoc security measures is that we tend to create too many one-offs like this. Databases getting ripped off through the web apps? Drop in a WAF (Web Application Firewall). PCI requires you to log? Drop in a low-cost SIEM solution. Having difficulty managing the JAVA runtime in your environment ... err ...let's leave that one alone for now. You get the idea.

One of the biggest transgressors in this space is the Identity and Access Management tools in an enterprise. Since the problem is so challenging, enterprises tend to use multiple tools to solve niche, and timely, issues. What's left over is a patchwork of several different IAM tools, identity stores, and rights-management consoles.


The real problem with ad-hoc

The real problem with ad-hoc isn't there are way too many devices, servers, systems, and tools to keep updated and functional. Yes this is definitely a problem, but not the problem, in my opinion. The biggest problem is one of resources. Resources - we're talking about people here. Human beings need to sleep, eat lunch, hang out at the water cooler and take bio breaks. Humans who spend their time trying to make a few tools play nice are really wasting a lot of time...

The challenge of ad-hoc security is that you end up leaving behind a wake of poorly operationalized hardware, software and processes. This turns into a black hole for your people's time, and I don't have to tell you that this creates opportunities for attackers.


The realization

The unfortunate end-result of ad-hoc security, then, is decreased security. You're not really reducing risk over the long-haul but rather increasing it, due to the increased complexity, resource drain, and low levels of inter-operability. It makes perfect sense then that CISOs who don't take a pre-planned approach feel like they're forever on a hamster-wheel and are never getting anywhere in spite of superhuman efforts.


The better approach

Many of you CISOs and security leaders have already discovered and are implementing program-based security measures. You start by defining a business-aligned security strategy, which pre-plans the 'big picture' approach you will take. You set out the high-level guidance, and set timelines and try to manage projects with the understanding that things come up - but you can be ready for them.

This doesn't mean you suddenly stop tactical security measures - you just try to avoid ad-hoc situations which have you dropping in processes and technologies which don't fit in with your long-term goals and strategy. This isn't entirely difficult, but takes having that strategy first!


As always, I look forward to your replies, comments, suggestions and experiences.

Monday, July 21, 2014

Tackling 3rd Party Risk Assessments Through a 3rd Party

In the enterprise, sometimes absurd is the order of the day.

Earlier this week I ended up in a conversation with a colleague about 3rd party risk. We started talking about the kinds of challenges his organization faced, and as the leader of the 3rd party risk program what he's up against. As it turns out when the organization set out to tackle 3rd party risk a slight mis-calculation was made. Long story short, his group has over 100+ vendors to manage in terms of 3rd party risk. That's 100+ vendors that interact with the network, the data, the applications, the people, and the facilities his enterprise has.

His team is staffed by a whopping 3 people, including him. To put this into perspective, and given that there are 250 business days a year, it means his team needs to complete 50 reviews per analyst. With 250 total days to work with, that means that they can spend a maximum of 5 days per 3rd party. Of course, we're not counting vacation days, sick days, or snow days. We're also not counting travel to/from sites to actually do investigative work, or the time it takes to do an analysis, debrief, or any of that.

This started to unravel in my mind, pretty quickly. I pressed my colleague for an answer to how he could possibly achieve any measure of compliance and completeness, to which he answered: "We outsource the evidence gathering to a 3rd party".

My head exploded.

I'm not saying it doesn't make sense, or that there are very many real alternatives - but you have to know how crazy this sounds. They've outsourced the fact-finding portion of 3rd party risk assessments to a 3rd party. BOOM

The truth is that there is a lot that he was doing behind the scenes here which made this a little easier to swallow. For example, a standard questionnaire was developed based on a framework they developed and approved internally which minimized the amount of 'thinking' a 3rd party assessor had to do. Each category of required controls had a gradient on which the 3rd party being assessed was graded, and there was really very little room for interpretation. Mostly.

If you think about it, I'm confident that there are many, many enterprises out there with this minor challenge. Every enterprise does business with at least dozens, on average with hundreds of 3rd parties to varying degrees. From your outsourced payroll provider, to the company that shreds your documents once a week, to the company who sends the administrative assistant who sits at their desk and answers calls and surfs Facebook all day. Every enterprise has a vast number of 3rd parties which need to be assessed - and risks identified.

While I'm definitely not crazy enough to think companies should only handle this with internal, trusted employees, I'm not completely convinced hiring out to a 3rd party is that fantastic of an idea either. There is so much to consider. For example, if that 3rd party assessor misses something, are they liable, or does that fall to your company? Ultimately in the court of public opinion - this is a trick question. The answer is always you.

I suppose the long and short of it is that enterprises have little choice but to use a 3rd party to help them manage 3rd party risk. But then the only question is - do they assess that 3rd party which will be doing the 3rd party risk assessments for unnecessary risk? It's enough to make your head spin, I know it gave me a headache just thinking about it.

What do you think the mature 3rd party risk assessment looks like? Do you have leading practices you could share? Contact me as I'd like to share them with our peers, and others who are struggling with this task right now.

Thursday, July 10, 2014

Compliance and Security Seals from a Different Perspective


Compliance attestations. Quality seals like “Hacker Safe!” All of these things bother most security people I know because to us, these provide very little insight into the security of anything in a tangible way. Or do they? I saw this reply to my blog post on compliance vs. security which made an interesting point. A point, I dare say, I had not really put front-of-mind but probably should have.

Ron Parker was of course correct…and he touched on a much bigger point that this comment was a part of. Much of the time compliance and ‘security badges, aka “security seals” on websites, aren’t done for the sake of making the website or product actually more secure … they’re done to assure the customer that the site or entity is worthy of their trust and business. This is contrary to conventional thinking in the security community.

Saturday, July 5, 2014

Critical Infrastructure as the Next "Cyber War"

I'm tired of reading headlines that say stuff like "It's [cyber] the next war!" because not only are they spreading FUD (fear, uncertainty, doubt) but if this was really the case we [as Americans] would already have "lost".

One of the things the FUD-sters like to ballyhoo about is the nation's critical infrastructure and how our power plants, water treatment facilities and chemical processing plants will be [or already are] targets for foreign nation states in a sneaky digital assault. News flash - this has been going on for some time, and while it's crystal clear to anyone paying attention that the nation's critical infrastructure is in a seriously neglected state when it comes to security - this likely isn't America's biggest problem.

Thursday, July 3, 2014

Harmonizing Compliance and Security for the Enterprise - The Introduction

Pursuit of compliance in the enterprise is proving to be a staggeringly bad security investment, if you ask nearly any enterprise security professional. And yet, we continue to see companies who get breached fall back on the same press releases: "We were PCI-DSS compliant! It's not our fault we were breached!"

I ask myself why, every time it happens. I still don't have a good answer.

Google+