After presenting this week at InfoSecWorld 2014 on Why Risk Management Fails, I was asked by a frustrated risk management professional how to build an IT security program.
The days are gone when I could just sketch out a list of technologies to deploy, as I did for the newly appointed CISO of a government agency in a half hour one-on-one session at Gartner Symposium a decade ago. He returned the next year to say “OK, we did everything on this list, what’s next?”
Most organizations have effectively deployed firewalls, IPS, vulnerability management, patching and user access controls. They are caught up with where they should have been in 2004. They may even have deployed layers of alerting, logging, and management tools.
Yet there are still breaches. What are they doing wrong?
I look for what I term ‘trust interfaces’ when examining an architecture. Where in the chain is ‘trust’ the only protection? Think of a service that offers access to a legal database. They deploy SSL, a firewall, maybe even a Web Application Firewall (WAF). They might even have engaged a DDoS defense service.
As attackers attempt to gain access by guessing passwords they have deployed some sort of defense against automated attacks–CAPTCHAs. Then they discover that an attacker was a customer, one who had provided a credit card and contact information. Once authenticated they ran scripts against the database and sucked down everything. The flaw in their architecture was trusting their customers. (Thus my third rule of simple security: A secure application assumes the user is hostile.)
Such trust relationships occur everywhere and invariably lead to abuse of that trust. Some key trust relationships to look for in your own organization:
Employees. Organizations grant a lot of trust to their employees. They have contracts, acceptable use policies, and confidentiality agreements that are airtight. A breach of trust could cost the employee her job. Is that enough? Not when the employee is sufficiently motivated. If a call center employee, making $15/hr., can pick up an extra $20K by selling mortgage applications to a cyber criminal is it worth the risk of losing his job? See the Countrywide case for an example of this happening.
Would an employee of a bank’s options trading desk breach that trust? He would if he was trying to cover $54 Billion in positions. See Jerome Kerviel at Societé Generale.
System administrators. IT staff are embedded with lots of trust. They are given the keys to the kingdom: the passwords to critical servers, routers, and management consoles, usually tied to an admin account, not an individual. Abusing that access to steal information (Snowden), or even hold the organization hostage by changing the passwords (see City of San Francisco) is easy.
Executives. Most IT departments are very experienced with not trusting executives. Or rather, trusting that they will do stupid things and thus building in defenses. But few build defenses against executives doing malicious things.
Network providers. For the past two decades every organization has trusted their telecom provider not to read or capture their traffic. There was no conceivable reason AT&T, Verizon, or any ISP would sniff a customer’s traffic, let alone store it.
The telecoms even failed to help when they could by filtering spam, blocking attacks, or alerting their customers when they had bots signaling to known malicious servers. If their claims of being a “common carrier” were truthful there was no way they would steal information; unless of course their systems had been compromised by an intelligence agency or they were subject to a National Security Letter.
Equipment. When you purchase a firewall or router from Juniper or Cisco do you trust them not to install backdoors so they can steal your information? Of course you do. Is this a trust relationship that should be reexamined? Yes.
Vendors. Beyond equipment vendors there are software vendors. Most organizations have learned to build in defenses around Microsoft deployments that involve expensive vulnerability and patch management infrastructure. But they still continue to trust Microsoft updates. Some test those updates before deploying because every vendor makes mistakes and pushes out patches that break something. But I know of no enterprise that tests updates for malicious changes. (See the Flame virus). This trust is extended to all vendors: Oracle, Adobe, and SAP included.
Lawyers are in the business of trust. That trust is even reinforced with a code of “client confidentiality” conduct. But attackers know about that trust relationship and target outside counsel for patent applications, negotiating positions, and trial strategies.
It is time for every organization, especially those that under the impression that their risk management programs have the covered, to examine their trust relationships.