1/06/2017
Gaps in the Agreement
The Things Outsourcing Services Hides
From You
By Zeke Vogts and Christian Unger
There will be gaps
gap (noun)
8 : a wide difference in character or attitude
9 : a problem caused by some disparity
Here: Missing or mismatching requirements.
Example causes:
• Differences in meaning attributed to terms.
• Maximizing profit – Meeting requirements but opening door for “variations”.
• Minimizing costs – Expecting more than is reasonable.
• Assumptions – Missing any of the above.
Impact:
• Internally: minor to major;
• Externally, more complicated:
• Scope & parameters set in contract.
• Communication significantly more staged / deliberate.
Definition 8 and 9: https://www.merriam-webster.com/dictionary/gap
1
1/06/2017
Coming Up
•
•
•
•
Causes of gaps and the basics of minimizing them;
The experience of a complex arrangement;
Contrived examples to frame lessons learnt; and
Considerations for migrating services.
There will be gaps, focus on:
• Minimizing their numbers; and
• Plan for dealing with their impact.
Aside: Overlaps also potentially problematic.
The Trend
Vendor
Known
Unknown
Known
Good (for now)
Bad
Unknown
Bad
Terrible
You
”Knowns” will:
Change;
 Never have been;
 Be communicated poorly.

Neither “You” nor “Vendor” are atomic;
• Requirements and services may evolve;
• Influences may be:
• Internal (e.g.: changing needs); or
• External (e.g.: industry direction).
In short: Unknowns increase over time.
2
1/06/2017
Fighting that Trend
Goal: Maximise the Known Knowns.
Similar to the Johari Window:
• Tell things known about “you”
• Requirements;
 Function
• Goals;
 Project
• Hopes and dreams;  Mission
to potential vendors;
and
• Ask vendors about themselves –
how their capabilities/qualities
will help.
see “Of Human Interaction”, Joseph Luft, 1969
Multiple Vendors
When there are multiple vendors and it results in gaps in the agreement;
• Why do these setups exist
• Businesses pushing more expenditure to operating budgets rather than
capital budgets.
• Reduction of in-house staff.
• Work is either too limited or is too broad.
• What it leads to
• Multiple vendors increases complexity which can result in security gaps.
3
1/06/2017
Multiple Vendors
Multiple Vendors
So how can we address it?
• Reduce the number of vendors supporting a single solution.
• Focus on documentation and communication.
• Document responsibilities and enforce through SLA’s.
• Dictionaries/Glossaries ensure that communication is at the same level.
• Responsibility Matrix including Shared Responsibilities.
• Having a clear understanding of those responsibilities makes it easier to
communicate.
• If possible have discussions with all the vendors at the same time.
4
1/06/2017
Multiple Vendors
RACI Matrix – Example
Responsible Accountable Consulted Informed
Task
IT Department
Host Support Vendor
Software Support Vendor
Operating System Patching
C
R,A
I
Firewall Changes
C
R,A
I
Software Patching
C
I
R,A
Database Patching
C
I
R,A
Outsourced System
Example is an outsourced piece of specialised software.
Host support by one vendor and Functional support by vendor.
No direct communication between vendors.
Pre-negotiated setup so a lack of documentation and which is reflected in the
Service Level Agreements.
Plenty of assumptions surrounding responsibilities and communication.
5
1/06/2017
Outsourced System
Undocumented port change is made opening a typically internal only server to
internet traffic, which was running programs with exploitable weaknesses.
End result is an outage, rebuild and examination of the servers, their setups and
documentation.
http://dilbert.com/strip/2011-02-24
Outsourced System
So where to from here:
• Examination of current documentation including SLA’s
• Increase communication with the vendors.
• Document the gaps, establish processes to overcome these
gaps.
• Inform the vendors of the gaps, get everyone back on the
same page in terms of expectations around security.
Security is more than the technical aspects. In an outsourced
world vendor management is extremely important .
https://xkcd.com/1339/
6
1/06/2017
Perfect Knowledge
You Know
Others Knows
Goal: Everyone on the same page, everyone knows what:
• Is needed (and / or “wanted”); and
• Can be provided.
Over time, things change, but Perfect knowledge has been achieved:
• Change is entirely predictable and planned for; and
• Other parties’ service only gets better, aligns more with needs and wants.
Reality: This does not happen. Things change – plan for this:
• Document everything; and
• Expect things that are trivial today, to be vital tomorrow.
I know, right?
Suffering the consequences
You Know /
Don’t know
Others Don’t know /
Know
Scenario: Organisation has need for encryption in a system. When asked how
encryption is implemented, vendor states they do not share this information.
Worst case:
Encryption is garbage (at least in this instance).
Internally:
 Vendor response is accepted.
 Evaluation fails to notice.
 System is breached.
Irrespective:
Externally:
 Client query inadequately addressed.
 Sale is lost.
 Sale goes through …?
• Communication and IT / Security team involvement will help.
• Negative outcomes affecting you are your focus.
7
1/06/2017
Unknown Knows | Known Unknowns
You Know /
Don’t know
Others Don’t know /
Know
Scenario: Organisation desires high level of security through 2-factor authentication.
 The vendor delivers, but other clients on the same service / infrastructure can
choose not implemented this for their users.
Scenario: Organisation desires a “separate instance” of a cloud hosted service.
 Separate …
 Front-ends;
 Back-ends (e.g. database / storage);
 Network infrastructure (virtual, physical or logical);
 Stores for art assets; or
 All of the above?
• Define what is meant;
At some point, you have to:
• “Trust” the response; and
• Rely on contract to set outer bounds.
• Processes and communication can break down in any organisation.
• Perfect knowledge is never achieved.
• Vendors seldom implement bad services or provide bad information on purpose.
• … neither would you …
• … incomplete / unsuitable, on
the other hand …
https://en.wikipedia.org/wiki/Hanlon%27s_razor
https://gamerant.com/sony-vs-geohot-seb-69061/
8
1/06/2017
Transitioning to / through the cloud
First Migration:
Focused on features:
• Replicate current, on-site* setup;
• Discard / modify by choice or necessity;
Reason to migrate:
• Strategic direction; or
• Cost vs benefit; and
• Risk Analysis.
* almost certainly evolved over time.
Second Migration:
Different pressures for migration:
• Time / cost / lost skills;
More complex to focus on features:
• Lessons learnt (i.e. problems),
• New needs,
• Scaled back needs (i.e. limitations),
• Old wants (i.e. what works),
• Old needs (i.e. what actually matters),
→ Refined requirements can reduce
costs / more features can raise them.
→ Greater flexibility may “leak” to others.
Don’t accept current limitations as given.
http://dilbert.com/strip/2013-02-25
Some more considerations
Reassess services, rather than “just” transferring them.
•
Most migrations feature some level of satisficing.
•
Requirements likely changed / refined since last “go live”.
Re-assess service before selecting how / where to host, rather than during.
Even if nothing changed in inputs and outputs (i.e. “the service”):
If the platform changed, then processes also changed;

A security audit might not be required – but should be considered;

Cloud services generally reduce control;

Plan for how an incident might be handled;

In stacked services (e.g.: PaaS by Vendor 1, hosted on IaaS by Vendor 2) –
ensure everyone in the chain is certified.
9
1/06/2017
Time and Perception of Progress
Hofstadter's Law:
It always takes longer than you expect, even when you take into account
Hofstadter's Law.
•
•
•
•
Progressing projects without things dropping off the radar is difficult;
Avoid trusting statements without verification against the agreements;
Communicate progress / concerns to stakeholders;
Use / develop a (procurement) framework.
https://xkcd.com/1658/
https://en.wikipedia.org/wiki/Hofstadter's_law
Conclusion
• Communication and documentation is key:
• Minimise number of communication/intersection points between parties;
• Ensure use of same vocabulary
• Consider Dictionaries and Glossaries;
• Create Responsibility Matrix; and
• Document limitations and assumptions.
• System (re)design + Responsibility Matrix == Gaps / overlaps to be addressed.
• Security and Service delivery are balancing acts, they suffer from incidents
being managed or averted with minimal disruption.
 Involve all stakeholders and check agreements with legal.
 Conversely, seek out projects in progress that should involve your team.
10
1/06/2017
Questions?
Zeke – [email protected]
Christian – [email protected]
11