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.

Monday, June 16, 2014

Choosing the Right Entry Point for a Software Security Program

The topic of software security, or AppSec, has once again cropped up recently in my travels and conversations so I thought it would be prudent to address that here on the blog. As someone responsible for software security in an enterprise, Fred was being given a small pool of money and a chance to plan, design, and implement a software security program. The big question on Fred's mind then, was where to start.

As we talked through the options, and I discussed some of the mistakes I've made and have witnessed others make, I tried to advise Fred to be cautious. One of the most important things one can do wrong when starting a software security program from scratch is starting in the wrong part of your Software Development Lifecycle or SDLC. This can be exacerbated by the fact that many organizations have many more than one software development lifecycle, and picking the wrong starting block is quickly amplified.

Sunday, June 15, 2014

Getting Wrapped Around the CISO Reporting Structure Axle

CISOs are in the lime-light right now as the parade of data breaches marches on. One of the big topics is the issue of reporting structures. Where should the CISO report to? Should the Senior Information Security leader be a company officer? All valid questions, and more.

Tuesday, June 3, 2014

In Defense of Reactive Security

Warning: This post contains a Sun Tzu quote...

Let's start here:
You're driving down the street, minding your own business and doing the speed limit. Both hands are on the wheel, no cell phone in sight, radio turned down to a moderate level, and you're generally driving like the books tell you to. As you approach the intersection where your light is green you take a quick glance to your left, then to your right. All is right, and you have the clear go-ahead. Now as you come into the intersection a child on a skateboard dives into the street in front of you...
In your mind, right now, you've slammed the breaks and are laying on the horn, right?

Every one of us reacts to our environment, it's how we survive. And yet - when you say "reactive" security today you get looks from people like that's a dirty word. Why is that? Much like other circumstances where perfectly reasonable terms and ideas get hijacked ... I blame marketing.

A responsible enterprise security program plans for as many possible negative scenarios as possible and accounts for them in advance (called being pro-active) and then reacts as conditions in the environment change (called being reactive). One without the other simply makes no sense, and yet all the marketing literature has CISOs thinking that being reactive is somehow bad.

It would appear that in the quest to invent new problems for the many 'solutions' out there, the term reactive has been ascribed some meaning I'm not familiar with. To clarify - both reactive and pro-active security measures are required - in harmony.

There's this interesting quote from Sun Tzu that applies here, mostly-
Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.
Pro-active security is better known as strategy. This is all the planning a security leader will do based on a survey of their current resources, capabilities, technology and environment - and if you're lucky maybe based on history as well. Being pro-active is a great idea, in fact, it's absolutely essential. Anyone who's ever tried to paint a room, or lay tile, or heck even sleep-train children will acknowledge that without a proper plan you may be able to get half-way in before you realize you're lost. There is a divergence with Sun Tzu's quote here, in Information Security. Strategy without tactics, in our industry, is certain failure. I don't mean the type of failure where you get hacked or breaches, I mean the type of failure where you get hacked or breached and you find out 9 months later because someone reports it to you... or the media calls your PR officer and asks for a quote on the giant breach you've experienced.

Reactive security is better known as tactics. You need tactics. Your organization, and your strategy is nothing without tactics. The principal reason is that sometimes, just sometimes, those bad guys/gals that we all plan for get creative and adjust their behaviors. Sometimes the markets shift, and business climates, technologies change. Sometimes a vulnerability is found in something you consider core to your security - maybe like SSL, for example - and you have to adjust quickly and decisively. Reactive or tactical security is something you can indeed plan for, but only as much as you can plan for it happening...and you have to give yourself and your security program enough flexibility to be able to adapt and adjust.

From experience, one of the biggest issues to date [that I've come across in my clients and personal experience] in security programs is that they become inflexible, unable to adapt to their changing environments. Once a security strategy is laid out, funding is set, and projects are launched everything is set in stone. Should needs change, adversaries surface we didn't account for, or simply new technologies or methods arise - we're left with a shrug of the shoulders and "Well, the budget for this year is set, we can plan for that for next year" - which is absolutely insane.

So I give CISOs which I advise 3 simple rules to go by:

  1. Develop a strong plan, which has clear goals and has the ability to be flexible when needed
  2. Develop a tactical capability to pivot on-the-fly as needs, environments, and adversaries change
  3. Expect to have to adapt either or both of those

Tuesday, May 27, 2014

Hacking the Registry to Keep WindowsXP Updating - A Bad, Bad Idea

When WindowsXP officially expired on support a while back - I wrote a post blog post titled "The Great WindowsXP Cataclysm" which talked about some of the reasons organizations had for staying on the antiquated operating system. Some of those reasons were valid, especially if you were running a Point-of-Sales (POS) terminal system which is based off of WindowsXP Services Pack 3 called "Windows Embedded POSReady 2009". According to this Microsoft lifecycle support site, this POSReady system runs embedded WindowsXP, and is supported until April 9th, 2019.

Leave it up to the security community to figure out that a simple registry key which identifies the POSReady 2009 operating system could be hacked into the registry of a WindowsXP machine to keep it getting updates. Well ... sort of. This is where it gets weird. Read this ZDNet article with Microsoft's response carefully... and notice that while they admit this will update WindowsXP systems, there is a  string of caveats that should make you think twice.

It's important to acknowledge that this hack (and that's all this really is) essentially tricks the update service into thinking your OS is a point-of-sales WindowsXP embedded device. The essential questions, which Microsoft hints at, is just how different is WindowsXP from WindowsXP Embedded? The answer is - quite a bit, actually. Check out this paper on the difference between WindowsXP Professional and WindowsXP Embedded and decide for yourself if you're willing to take that risk. Architecturally, the two operating systems are close, obviously since they're both based off the same kernel. Once you start getting into the add-ons and run-time environment options Professional and Embedded start to look dramatically different - in my opinion. This means that if you start applying patches and bits meant for the embedded operations system onto your corporate desktops at very least the results would be unpredictable...

So let's summarize my thoughts here.
  • some organizations are still on WinXP on the corporate desktop (and elsewhere, obviously)
  • for those that haven't migrated, excuses are critical... not necessarily valid, but critical
  • a quick registry hack is available which tricks Windows Update into pushing patches and updates meant for a variation of your WindowsXP operating system onto your machine(s)
The hack is a bad idea for the following reasons:
  • potentially de-stabilizes your WindowsXP operating system
  • necessitates significantly more testing to ensure compatibility
  • quite obviously breaks your software agreement
  • could potentially get you into a CFAA or other legal situation
Essentially, my thoughts are this - if you're resorting to hacking the registry to get patches which are meant for an OS similar to yours onto your machine for security - you've got a big, big problem. The energy you're expending, and potential hazards you're creating on top of system stability and unknown security issues ...should get you fired. Immediately.

Folks - this isn't a viable work-around to keep WindowsXP alive. It's a bad, bad idea.

Tuesday, May 13, 2014

Enterprise Security Tools Vendors' Big Problem

I’ve spent a substantial amount of time helping organizations justify enterprise security software purchases, specifically software security testing tools, in my career. Over that time it was common to run up against the question of “Why buy an enterprise tool when we can use open source?” The answer at the time, which was almost 5 years ago at this point, was that the maturity of the open-source tools wasn’t there. That argument, in recent years, has all but vanished, and enterprise security vendors which have open-source or inexpensive alternatives are in trouble.

The most immediate effect I’m seeing is in the testing tools space. Penetration testing tools are the natural target for erosion of market-share by open source simply because these type of tools are generated in large volumes by testers as they work through engagements and it’s natural for people to want to share. Take for example the most popular penetration testing platform hands-down right now – Metasploit. HD Moore’s community-sourced platform has grown into a monster, with code commits in volumes that would make even the most diligent enterprise security software shop blush. Now – not all this code is clean and brilliantly functional, but it does the job and most of all it’s on the leading edge of innovation as ideas can quickly be pushed to the code base, and taken up and built upon by members of the community. A brilliant approach that a closed-source enterprise software shop will struggle to match. Tools in this space that have price tags north of $10k, $20k are struggling for the very simple reason that even though the open-source equivalent isn't necessarily as polished and pretty – in many cases technically it’s more advanced, more up-to-date, and as a result of being community driven ... more innovative.

I don’t think this means certain death for the big closed-source enterprise security vendors though. It would appear that there is still a customer demand for the tools that these shops release – but it’s a matter of understanding your target market. As I see it there are at least three classes of users: specialist, expert, and master ranked by the person’s abilities.

At the specialist level you’re typically not getting someone who can write their own complex scripts, or exploit code. In fact they’re generally just looking for a blunt implement to do the job…with no requirement to do it exceptionally well. In software security these people manifested as an analyst who was tasked with a series of tasks and one of them just happened to be testing the organization’s web applications. These people weren't testers by skill or trade, nor were they particularly knowledgeable about penetration testing, or even coding web applications. They needed to do a job and that job was to test the app with the least amount of pain. They would look at low-cost or open-source alternatives which weren't particularly polished, required lots of manual work/scripting, and buckets of knowledge and (generally) understood that this wasn't going to be a relationship for them. They sought out the enterprise software which gave them push-button results, and did some of the thinking for them. No assembly required, batteries included.

The next rung up the ladder was always tricky – because the expert class was just smart enough to be dangerous to themselves. What I mean by that is these people knew a little bit about software development, they knew the basics of security and were willing to tinker. They still had a job to get done, and the enterprise software path would have been more productive in many of these cases, but either because they had a passion and desire to learn, or because they simply wanted to see if they could do it – they would compare open-source to closed-source tools (apples and pumpkins) and not fully understand that these were different. This user was tricky because they often times felt that the open-source alternatives were “good enough” even though their skills wouldn't be good enough to produce value from the tools they were using. This as you can guess produced scary results.

The third category was the master class. I met only a handful of these types in my time in that supporting role. These people had no desire or need for enterprise-built security testing tools… they were too constraining, too slow-moving, and just not good enough. They could do run into a problem the enterprise software couldn't tackle and effectively code their own way around it… which allowed them to move faster, be more agile and adapt to the changing nature of the target better. I stress that there were very few of these people out there…and most fell into the expert class. Master class is typically achieved after years of experience immersed in technology and focused work. Generalists rarely get to this level of skill – and it’s really the enterprise’s fault for pushing people to perform 3-4 different roles on average … only 1-2 of them really fall into the person’s wheelhouse.

“Horses for courses” one of my colleagues would say. Make sure you’re advising intelligently so that the right person has the right tool in their hand for their skill set, and the job at hand.

The interesting thing, I think, is that as more security professionals flood the market there dynamics are being skewed. I believe that the distribution between specialist, expert and master is dramatically dramatically changing. A few years ago I would have said that we had 50% specialist, 40% expert, and 10% master class out there. Today’s security industry is becoming more community-enabled and driving that distribution to the right more. So now I think we’re closer to 30% specialist, 50% expert, 20% master and continuing to shift towards master at a good pace. This is both good for the overall state of security, and bad for enterprise security software companies which relied on the specialist and expert classes as a target buyer.

The good news is that enterprise security software isn't dead, it’s just being forced to re-evaluate its value propositions. Enterprise software shops need to re-focus their efforts to engage the community more, make their tools more open (one of the biggest gripes ever is proprietary closed formats of data) and extensible and start to think about lowering their costs… or maybe shift their licensing models to the as-a-Service model. I’m not saying I have the answers, but these shifts are happening and they’re not asking for permission. Enterprise security software shops, if they wish to stay relevant, need to address the shifting sands of skills, needs, and community. Or they can become irrelevant …

Tuesday, April 29, 2014

Penetration Testing Does Not a Secure Enterprise Make

Now that the dust has somewhat settled from the Target breach, and the subsequent law-suit madness is hopefully over I feel like it's safe to write about this topic, as much as it can ever be to discuss a touchy subject. Much of the writing and rhetoric, and finger-pointing for blame, around that breach centered around the fact that a 3rd party was hired to 'find faults' in the 1st party, and the 3rd party apparently failed to do so. Or ... something like that.

I wish I could say that this is the first time I've heard a confused understanding of what penetration testing is, but it's not. I also wish I could say that the purpose, limitations, and actual best-use of penetration testing is well understood amongst enterprises - but again - it's not.


Penetration testing as TVM

An organization I'm familiar with basically used penetration testing by a 3rd party as their stand-in TVM (threat & vulnerability management) program. The case was that the internal security team's ability to identify weaknesses and toolset were weak, and the CISO believed that the best way to identify threats that his team should focus on, in order to best position his defenses, was to be regularly penetration tested. So, four times a year his organization would undergo a structured, scoped and time-boxed penetration test which - of course - Information Security was ready and prepared for.

I'm sure you can already pick out the few glaring issues with this approach, but it continues to disturb me that the defensive posture of an enterprise is allowed to be determined by the testing capability and talent of another organization. Not to take anything away from the company that is currently charged with the penetration testing contract - because I have no reason to doubt their talents - but it's foolish to think that they'll find "all the issues", or even the most important ones. While I think penetration testing is important to identify the things that are glaring, and obvious from a complete outsider's perspective - it should be in no way (in this blogger's humble opinion) authoritative on what you should consider important. Third-party penetration testing does not replace a threat and vulnerability management program, period, end of story. It just can't.

There are too many variables here. The thing that's most important to understand is that penetration testing is ultimately too limited, in the way it's implemented by CISOs, and has a very little chance of being holistic enough. Penetration testing will definitely identify some externally visible, exploitable vulnerabilities if you hire a good crew. Otherwise you'll get what you pay for, the output from a Nessus scan copied and pasted into a PDF. The problem here is that you need a more complete picture. There are nuances. Different testers look for different things, they have different approaches, and will likely have different results. You need a consistent, repeatable, and continuous approach to identifying your vulnerabilities supplemented by penetration testing. You simply can't swap out a TVM program for even regular penetration testing. It won't work.


Penetration testing leads to security

An organization, any organization, cannot simply test itself secure. That's as insane as an auto manufacturer crashing cars until they stop failing crash tests. You still have to actually fix the issues! And we all know how that goes. How many of you have stories where you go out and test one of your clients, only to discover that nothing, or barely anything, has been 'fixed' from the last round of testing?

While penetration testing is definitely a good way to identify exploitable, visible security issues in your enterprise when done right, it's not going to make you more secure unless you do something about the problems. Therein lies the challenge... too many CISOs are looking for someone to come in and find nothing wrong and move on. We call this the compliance with penetration testing requirements.

Good security leads to good security. Whether you're hiring outside firms to perform penetration testing or not. There is no substitute for sound strategy, executed well and with purpose and executive leadership's backing.


What's the point then?

You may think I'm down on penetration testing, at this point. You're wrong. I think there is a time and place for one of the most important validation activities a security program can perform. I stress that this is a validation activity - once you've shored up your issues you seek to validate your posture with a good and thorough testing.

For those enterprise CISOs who are building or optimizing their security program penetration testing is a validation exercise. First and foremost, you need to know what your high-value assets are. There is no substitute for this, and penetration testing nor crystal ball will not help you here. Identification of critical assets is a primary activity of any security program, and everything you do will be based from that point. Next make sure you've built a solid TVM infrastructure, with good policies and practices. Ensure you have a workable definition of critical, and how you make go/no-go decisions when it comes to remediation, deferring a fix, or simply accepting a risk. Then make sure you have the necessary backing to ensure that you can execute when it's time. Once you've done all that, and you're sure you've done enough internal test-fix rounds have someone perform a thorough penetration test on your organization to show you all the things you've missed or simply not thought about. It's amazing how many times someone can get at a high-value target through what we perceive is a low-value asset...

Lastly, don't get too mad at your 3rd party penetration testing organization for failing to identify the avenue of infiltration that caused your big breach. There are a lot of factors that go into what is considered a 'good' penetration test - and many of the failings fall on the shoulders of the client...but that's a discussion for another time.

Wednesday, April 23, 2014

Best Practices - The Only Thing Worse Than Compliance

There's only 1 thing worse than hearing a CISO talk about their organization's culture of compliance. There is only 1 thing which makes compliance sound like a worthy goal. There is only 1 thing that makes my skin crawl when someone in an enterprise security role discusses.

That one thing is hearing a CISO proudly announce his organization's adherence to "best practice". What does that even mean?! Let's ask Wikipedia-
"A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark."
That definition makes sense. Except ... in security every organization is just different enough so that what works great for one enterprise, will likely fail miserably for another. I know everyone believes their enterprise is a special snowflake, and that ultimately none of them are that different - but there are enough differences such that the term best practice is almost meaningless in my humble opinion.

What makes this whole matter worse is that while the security professionals community laments the notion that enterprises are largely made up of static defenses their adversaries are highly dynamic. Make no mistake - your adversaries don't follow "best practice" when it comes to penetrating your weak defenses. They scout you, identify a weakness, and exploit it. Done.

Sunday, April 6, 2014

The Great WindowsXP Cataclysm - Part 1

This post is cross-posted to my HP Corp blog as well at http://hp.gom/go/white-rabbit
 
The end is nigh!



Let me start off this two-part series by saying that I survived the first time this happened. If you've been around a long time in IT you may remember this operating system called WindowsNT 4.0 - and I was there when it finally, for real this time, truly and for sure went end-of-life. I think there is much parallel between what happened then, and where we are today.


Saturday, March 29, 2014

Analyzing the Target Breach "Kill Chain Analysis" Report

-- If you haven't read it yet, the document "A "Kill Chain" Analysis of the 2014 Target Data Breach" is a must read for anyone in the role of enterprise [cyber] defense.

I've been studying recent breaches through the looking glass of the "Lockheed Martin Kill Chain". If you'd like a primer on the importance and background of the kill chain methodology you should read Rodrigo Bijou's fantastic analysis. The LM kill chain methodology for examination and defense from an attack is actually quite brilliant. It's not necessarily revolutionary - but enterprise security professionals now have a structured and documented way of trying to thwart attackers, and learn from breaches. So it's fair to say that this is something everyone in defense (and oddly enough, offense) should know like the back of their hand.

Tuesday, March 25, 2014

Attribution - The 10 Ton Elephant in the Room

First let me tell you why I'm writing this post you're reading, and why I hesitated to write this post in the first place. I am not a full-time threat or security researcher, let me just get that out of the way. I'm fully aware I don't qualify to have the in-depth attribution conversation which I'll leave up to the experts but there are many things that still fall into my wheelhouse, so here is a semi-organized collection of my thoughts on this specific topic of attribution in cyber.

This current discussion on the DailyDave regarding the APT1 report Mandiant put out (one year on) list is seriously boiling my bunny(tm).

Monday, March 10, 2014

Here a box. There a box. Everywhere a breach. Notes from RSA 2014

TL;DR - More of the same, and security is still a 1U 'solution' that fails every time, eventually.

Hey everyone, I’m writing you from the settled dust of RSA Conference 2014. It typical fashion I made grandiose plans to meet up with people I’d not seen in years, and meet people I only knew by a handle over Twitter or some other online forum … and it all went to hell. Best laid plans and all that, right? Every year RSA Conference is the same. You show up in San Francisco and hit the ground in a fast sprint. Although I don’t feel like I was sprinting so much as the ground underneath me was moving so fast I could only keep up by running my hardest. Analogies aside, I ended up with a talk, a panel and some booth time and of course time with our often very interesting client base. Then I made the mistake of walking the showroom floors. That’s right, there’s an s at the end of that word because there were in fact two sides of Moscone this year that were used for exhibition.

Google+