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:
