A provider doing an ICT security review should give the client what they need, not what they want, says security specialist Daniel Ayers.
This means thinking like an attacker, outside the “box” of standard procedures and the client’s initial motives for having the review done.
And if the persistence of similar kinds of vulnerability in successive reviews indicates an ICT management problem rather than a technical problem, the provider should not hesitate to go higher up the management structure with their findings, he says – even if it’s to criticise the competence of the manager who’s paying for the review.
Ayers, managing director of security consulting company Special Tactics, led a sometimes contentious discussion of security reviews at a Wellington meeting of the Institute of IT Professionals on May 30.
Organisations request such reviews for a variety of reasons, he told the meeting: because there has been a change in their infrastructure; because an outside party has asked for assurance of the client’s security; because the company is seeking its own assurance that a new collaborative arrangement will not expose it to new vulnerabilities - or simply because a review is set down for annual execution. “Those [last] are the clients I worry about most,” Ayers says, because their mindset is on a fixed cycle.
A security review is usually motivated by a need for “assurance”, he says; “they want to know everything’s OK and that they’ve done everything they should be doing to protect themselves.
“A review is sometimes requested because the client wants to know if ‘they’ can get into the network,” he says. Sometimes there’s a real ‘they’ in their sights; a specific threat people are thinking about; at other times they’re thinking of an ill-defined class of “internet hackers”.
Traditionally we’ve thought about ICT security as protecting information; what’s called the Confidentiality Integrity and Availability (CIA) model, Ayers says.
“In my view that no longer applies. We now attach more importance to infrastructure and attacks often aim at disrupting infrastructure rather than stealing information.
“As consultants we were set the challenge of whether we could switch the water off in a city. We could and it wasn’t difficult; we just had to walk into a library and plug into a network port on the wall. If real attackers started doing that it could get really embarrassing.”
Unfortunately, he told the IITP meeting, consultants too often think in terms of a fixed-time assignment which involves running through a standard methodology almost like a checklist; they don’t think like an attacker who’s been studying the company’s specific environment for some months and constructing a specific plan.
Here Ayers was challenged by Colin Slater, a partner at PricewaterhouseCoopers, who accused him of confusing security review with the different and more straightforward activity of penetration testing.
“That’s a very small part of a very large question; what is ‘secure’?” he said.
“It’s a bit disingenuous to say a methodology is a checklist; it is not and will never be. Methodologies such as the Open Source Security Methodology Manual (OSSTMM) and those promulgated by the International Standards Organisation “are not checklist-based; they’re principles-based” and will take the advisor into the country of what the client needs rather than what they want, Slater said.
Ayers stood his ground; “I’ve seen security reviews done literally as a checklist,” he said. It’s relatively rare in my experience to see it done properly under a standard like OSSTMM.
“Danger arises when you have consultants looking at it like consultants. It’s typically done in a fixed period of time – say a week - because that’s how consultants think. My concern is that sometimes when you’re looking at a thing through the lens of a consultant you’re trending away from the way threats work. [So] the value of the process is diminished and you can get an invalid result.”
“You talk about what in your view clients expect; I’ve never come across clients who expect any of that – if ever,” said Slater.
“Clients they don’t want to be told [they’re safe]; they understand that’s an unrealistic expectation. They want to understand – in English – what are their current risks. They will assess that information in the context of their business.”
The security review, Ayers says, should go further than immediate assessment of vulnerabilities to an assessment of the organisation’s competence to cope with an attack.
“I’ve spent a lot of my career in forensics, as the ambulance at the bottom of the cliff,” he said.
“My experience is that when we respond to an incident, the organisation is often not well prepared for it. The transition from business-as-usual to ‘we have a problem’ is not pre-planned and often not very smooth.” This point was emphasised in the book Responding to Targeted Cyberattacks, reviewed in Computerworld, June 3.
Finally, Ayers says, managing security risk is not just a job for the ICT people. It crosses over to the executive team. The human resources department has a role to play too, in formulating a posture in response to the threat of internal attacks. “This can be a matter for employment contracts; what you can and can’t do to investigate your employees; what obligations your employees have.
“There are legal questions; if you outsource some of your IT to a third party, is there a contractual obligation on that third party to assist you in a review or penetration test,” Ayers says – “or are they going to say: “you’re not allowed to do that to our network”?