Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

[BSidesLV] Building Bridges: Forcing Hackers and Business to “Hug it Out”

Building Bridges: Forcing Hackers and Business to “Hug it Out” – Andrew Hay, Chris Nickerson

Started as a discussion from Shmoocon 2010 – Hackers and business, who’s responsible for what

Nobody wants to accept responsibility

There’s the stereotypical black t-shirt who are too cool to talk to business

There’s the business who just want to protect their business and don’t know what to do

It’s a fight that’s been brewing for a while and both sides really want to meet the other.

This talk shouldn’t exist… but the industry obviously needs it!

  • The problems
  • The view from the trenches
  • The view from the business
  • The way to fix this problem

The view from the trenches

– Management is clueless

– They don’t care about security

– They will only do the “bare minimum”

– They play golf and waste time in meetings all day

– They don’t respond when I show them how important it is

Security guys are overworked, get all the blame and don’t get the respect we deserve

The view from the business

– Hackers don’t have a clue

– They don’t care about the business

– They don’t understand the economic challenges and regulations

– They surf the internet all day

– The don’t listen when I tell them how dangerous it is

The business work long hours, don’t get the respect they deserve

Pure Security vs. Business Security

Hacker perspective:

The business is responsible for operating as a business.

The hackers are screaming they can get into boxes

A secure environment is the goal, but this will never happen –> utopian view

As a business person, availability will usually trump anything else. If the systems go down, it’s a big problem.

Business perspective:

Availability is king!

The cost of secure operation could be detrimental to the bottom line –> Budgets are fixed, scope is fixed. Business doesn’t like it when you come to them with unannounced costs.

Shell a box vs disruption

Hacker perspective:

Shell == Game Over

Security people can’t validate their findings without exploiting systems

Business perspective:

To business, shell means nothing. How does it link to business impact?

There’s a huge difference with the level of responsibility between a hacker (pentester, etc…) and the guys running the business. We say “you must” without thinking who’s really in-charge and responsible for making those choices.

Business doesn’t understand what exploitation or popping a box is. If they think you might take it down then you’ll get delegated to the dev environment to test.

If an exploit is required to validate, we’ll skip that test

Cost vs Completeness

Hacker perspective:

Security guys always want a free scope. When business say they want a system tested, they have a focus. Who are we to complain that we’re only focusing on 2% of the environment.

Having the mindset that everything has to be tested doesn’t work all the time.

Business perspective:

Testing on every level isn’t always whats needed.

Rules for engagement are built from a lack of business understanding… sometimes. This doesn’t mean they’ll change however.

Security people aren’t giving business cases for other things that could or should be tested. Testing everything at once might also not be the best plan. Take things one-step at a time.

“You need to do this because if you don’t you’re stupid” –> not such a good way to convince somebody!

Budget and compliance dictates whats needed or wanted. PCI only needs specific tests. Educate the business that this isn’t always best.

Scope vs Hackers don’t have a scope

Hacker perspective:

As security people we always hide behind this excuse. If you want that, quit and become a blackhat.

“Scope is a guideline… I’m gonna test it all” –> Taking down a productive AS/400 isn’t a good thing if it’s not in scope. Business downtime == money

SE is out of scope? WHY? Real hackers will attack our people –> Do you know what effect this kind of test has? Maybe the company doesn’t need this organizational and legal issue. SE isn’t always easy and clean from the business standpoint.

Business perspective:

Business doesn’t always know whats best for them… if they did, they’d already have secured it

Scope creep does not benefit the business –> testing systems outside of scope causes business issues.

Political ramifications of SE is too much for a business to handle sometimes

Downtime vs Patch to secure

Hacker perspective:

It’s just a patch, install it already!

How much revenue will be lost if this threat vector is exploited!

Patching now may reduce downtime due to a breach later

If you’re worried about installing a patch, test it first

This is stupid, why isn’t it automated? –> Hacker “I could script that”

Business perspective:

Downtime isn’t an option –> WAF or other inline patching –> Put a band-aid on it

But we’ve got a Firewall and AV

Attackers are on the outside –> Users on the inside have all the info.. aren’t they a threat ?

Costs!

We’re a hospital/bank/whatever… we CAN’T go DOWN! –> Not just a technical issue, it’s a reputation issue. Always available!

Feature Release vs Secure Development

Hacker perspective:

It needs to be secure vs it needs to be released

If we fix it now, we’re releasing a secure system and don’t have to fix it later

Delivery timelines can shift

Saving money by fixing now (cite post release 100x bugfix increase cost)

I won’t put my name on THAT <insert tantrum here>

Business perspective:

Delaying the release may jeopardize our Go To Market strategy

Fixes can be applied post release –> Hotfix, next minor release –> Hope nobody finds that vuln before the patch is out!

Development & QA time costs money

May lose money by fixing it now –> Loose customers, loose deals

Feature profits fund future development and also security enhancements –> ones it sells we’ll secure it

Compromise Disclosure vs Potential financial devastation

Hacker perspective:

We should be open and tell our customers

It’s our duty to report flaws to vendors and the public

Business perspective:

This could jeopardize future and current business –> no business, no security, no job!

Let somebody else report it

We’re in business to make money not report vulnerabilities

We got hit, but nothing sensitive was accessed –> SURE 😉

Compliance vs Security

Hacker perspective:

Compliance is NOT security!

Compliance should be a by-product of being secure

Compliance is stupid and somebody else problem

Business perspective:

Compliance initiatives fund security products and tests –> need to test to achieve a tick in the right box

Our customers require us to be certified… not secure

Achieve compliance and security should follow! –> isn’t this the wrong way around?

Not enough money for both… business has to be compliant!

The way to fix the problem

Business want it all neat and pretty…. hackers want the real info no matter how messy it is!

Business needs to

Understand that:

  • Hackers are intelligent people who are responsible enough to be educated on the business and it’s issues
  • Business has a large moving target to keep up with and need effective direction
  • Hackers are their first and last line of defence / They defend your paycheck and require your support
  • Getting the understanding
  • ….

The business keeps moving and the workload to keep up with new threats, systems and technologies is a big issue. Business also don’t want to be the one up till 4am dealing with system security. If it’s working then nobody cares…. no win situation!

Hackers need to

Understand that:

  • Learn more about the business, it’s opportunities and how cost plays into the decision process
  • Identify the political challenges and pose their problems/solutions in a manner that fits
  • Talk in a language that business understands
    • Mimic terms used by business
    • Cut down on the techno babble

Both need to

  • Learn to respect and tolerate the others skills and problems
  • Recognize that both camps bring value
  • Realize that neither camp should dictate best practices but rather agree on best practice
  • Understand that they have the same goals but start off on different opposite sides to get there

Ask yourself what you’ve done to bridge the gap between security and management?

Links:

Advertisements

2 responses to “[BSidesLV] Building Bridges: Forcing Hackers and Business to “Hug it Out”

  1. Pingback: Tweets that mention [BSidesLV] Building Bridges: Forcing Hackers and Business to “Hug it Out” « ©атсн²² (in)sесuяitу -- Topsy.com

  2. LonerVamp August 16, 2010 at 21:13

    Wow, this looked like an excellent talk grounded in a great middle area between business and hacker perspectives. I definitely need to check this out sometime. It’s one thing to say you need to patch, you need to SE, you need to prove exploit, you need to do this and that and this other thing of you’re dumb (implied). But the reality in a business is definitely different and many orgs simply can’t live up to the perfect expectations.

    Hell, if nothing else it keeps us in a job. (Ok, some companies actually want their hackers to give them the perfect responses from a purely hacker perspective, and then make their own decision about what risks to accept and what actions are acceptable. Part of this is identifying the decision-makers. Is it the IT/Sec/Hacker team or a VP/exec? And what are they expecting from the hacker: the bottomline facts or a decision/recommendation that is realistic in business terms? Those two approaches are definitely both valid.

%d bloggers like this: