Hacking contracts for fun and profit

One of the big challenges for Information Security, particularly in organisations which have major outsourced IT contracts from the global players such as IBM, Accenture, Wipro’s of this world is how you can do effective security when bound by such constraints.

Security typically has its own schedule within such contracts, but there are usually security considerations across all schedules so it should be someone’s job in a security organisation to actually read and understand them, as they will typically highlight one or more of the following:

Caveats to meeting your own security policies you should be aware of
Activities or transformation which is included, but you’re likely being charged extra for
Nuances to included services, which due to how your processes are setup, you aren’t taking full advantage of

I was told recently I got a reputation with at least one (probably two) of those vendors above due to actually understanding what they’re contracted for, and it’s something I do pride myself of so if you’re in any type of Security Governance, my top tip would be: “Know your key contracts”. It will pay for itself, I’m certain.

Below, I provide a few examples of clauses I found in the past which pose either risks or help identify opportunities for exploitation as they can significantly reduce our extra security spend as they should already be provided by the supplier or significantly improve the assurances you have on how good a service you’re consuming.

Caveats

Many of these contracts, as they’re often provided by teams which are remote have the consideration of having to scale their operations and move people between accounts so homogeneity is key to their profitability. An example I saw was the contract referencing something along the lines of “Yes, we’ll meet all your policies… to the extent that they meet this other document over here”.

Big contracts have a lot of these, so would advise an assessment against any 3rd party provided contract against your policies and make sure you don’t have any particular causes for concern. Just don’t assume they actually understand and operate in accordance to your own policies.

The documents they do have will typically be of a technical nature so it’s up to you to make the traceability between them.

Included activities

One of most eye opening ones related to “delivery of mutually beneficial security improvements as part of continuous improvement”. I could see zero evidence of this ever being the case, as we were charged separately for every nut and bolt. It led me to discussions with the supplier on defining some clear activities which would benefit both parties and should be part of continuous improvement.

Another example, was software for security policy verification being included but I had never seen a single report, coming to know later it was “something they used internally”. I kind of demanded to see the outputs of it, since it was my job to understand the security of my environment and there was no good reason they shouldn’t be sharing that with me.

As with most organisations running their own datacentres and with old world architectures, patching is a constant concern. Contractually this provider had to send high severity notifications within 3 days and this was rarely happening. The processes we had only dealt with Threat intelligence info in that regard and was being lost in a “daily newsletter” the few instances that it diid. I worked with the provider to ensure their security focal point had that as a recurring task.

We even had reference to a full Database activity monitoring service (“install and maintain”) we weren’t consuming and ended up agreeing we should really just be paying for licenses and transformation cost would be up to them. This was a major “gap” in taking advantage of this contract.

But my “pet problem” (in line with my previous post) was Firewall changes. Contract mentioned that if customers (us) provided the right approvals then it was included in the contract, but reality had all firewall changes go to a Change Board to be discussed ad nauseam and be charged separately for all these (cost between £1k and £3k). Ridiculous!

Nuances

An interesting nuance was relating to Vulnerability Management. Though we had a managed service, a few months back a colleague had asked for direct access to the platform which was denied, and when I did this contract review I actually identified that they should be giving us access to it as well, so that made it an easy conversation. We were also being charged by some change management activity which should’ve been included.

And now the horror story

Reporting was my major problem in this contract. Before going deep into this, I need to be fair and express some appreciation that the “outsourcing merry go round” some businesses do (first Wipro then they’re bad boys so we move to IBM then they’re bad boys so we move back to Wipro) aren’t conducive to good service so certainly not to good security either, and a lot of this debt is up to the organisation consuming the service and not entirely the providers fault. But still the service setup makes it so much harder to grasp what’s important and hides all the inefficiencies unless you know what you’re looking for and set time to do it.

The state of security reporting and risk management was, in a word, appalling. And I’ve seen it in 2 organisations I worked for who had this type of outsourcing contract. If you’re starting to work in this type of environment some tales and word of caution below:

Risk management reporting – reports way too extensive conflating threats and risks without any “so what” to them. They just care that someone in the org is present in meetings and no care for seniority so I found an IT manager (mid level) had “risk accepted” risks completely outside appetite. Being fair to the person, he/she mostly said he didn’t have budget to do any fixes on those areas but the provider just took that as “organisation has accepted the risk, so we’re Good”. This is both sloppy and dangerous. Reports sent to upwards of 30 people so dilutes the “who should be doing something about this” and after a few years no one remembers whose job it is.

Reporting suppressions – part, but not exclusively, of this risk reporting approach is that once someone says they can’t fix, you’ll actually get suppressed reporting so you’re blind to all of it from that point on. To illustrate, there was a “not had conversation” with an application provider and no defined maintenance windows so the infrastructure provider took that to mean “I’ll just stop reporting on all missed patching because/until someone defines maintenance windows”. It took me almost 6 months to actually understand this, when I started getting conflicting info between different teams and reports and dug deeper. Now imagine this type of thing built over a period of 5 to 10 years. It kind of implies all the assurance info you have is probably wrong and not giving you any sense of systemic risk, but hey at least the reports look good and you have plausible deniability ? unpicking all this took such a long time and having to go to very senior levels in the outsourced provider as they couldn’t understand the importance of still reporting on it even though we had internal work to figure out.

Undelivered/unmanaged reporting

The contract was very explicit on monthly, quarterly and annual reporting and it included. On further inspection, I realised a lot of it wasn’t being reported on and some parts which were were scattered across multiple different teams like Ops, Service Management and other areas whose expertise or responsibilities were Security Management. I started working with the provider to consolidate all of this reporting for centralised visibility.

Conclusion

Not all of this is exclusively up to the provider, but years of “not so diligent” management and outsourcing merry go rounds, make it really difficult to have any real assurance on the services being provided.

You need to fully understand the constraints posed by such a contract, find the best ways to leverage clauses that give you some wiggle room to design processes to take advantage of nuances in the wording of contractual clauses, and ultimately question everything until you’re confident you’re not getting mostly suppressed reporting that give you a false sense of security (pun intended).

This all rests on 2 things: knowing what your contract says and having a traceable mechanism (even a spreadsheet can do this job) so you understand and assess yourself and the provider in how clauses are being met. What I’ve done in the past is create some slides with summaries of my contract assessment that I could easily refer to moving forward every time I’m told “we can’t do that”, “you need to pay”, “that’s not part of the contract” (it may well be), or “look at this wonderful all green report” and its corollary “these are not the droids you’re looking for”. They probably are.