• United States



Undercover: A Case of Help Desk Failure

Jun 11, 20097 mins
Application SecurityCybercrimeNetwork Security

How a lack of coordination between departments at a large bank opened up a big security hole, and what we did about it.

As the engagement leader on security assessment projects for our clients, I frequently run into what I call the “IT Myopathy Syndrome.”

Quite a few well-meaning and high-placed individuals worry about protecting their IT assets and forget a basic principal: In “Capture the Flag,” if you capture the flag, the game is over. [Related: Physical and IT Security Convergence: The Basics]

Here’s an example of one such case.

On a recent jaunt to a client — a large national bank — my team and I were received warmly. After the mutual introductions were concluded and before the ceremonial taking off of the jackets, we were shown to a conference room where our team was to be based during the first phase of our four-week project. [Related: Here Come the Auditors: Judgment Calls]

Once we sat down, plugged in our computers (to check e-mail, of course) and started feeling a bit more comfortable, the director of IT security walked into the room and started a conversation with us.

Since the accounting group was our “sponsor” and our scope was allegedly not discussed with him, he wanted to know what we were planning to do, in what order, when and how.

A few minutes later he blurted out: “I don’t know why you are here at all. We got everything under control. We got firewalls, we do penetration testing. No vulnerabilities to find.”

“Oh, no!” I thought, “Another engagement full of political battles between the sponsors and other principals. We best stay out of it.”

Continuing the conversation, I stated that per our scope, we have to go through a checklist of controls, verify their existence, test their validity and measure compliance. One of the first controls we had to deal with, I explained, is information security awareness.

The IT security director answered: “We are 100-percent covered. We make all new employees read a brochure and sign a statement acknowledging reading it and of the possible consequences of not complying with the rules.” “Great,” I said, “let’s test this, OK?”

After a few seconds of hesitation, he agreed. We went into the next conference room, just the two of us and I asked to use the desk phone, which he graciously allowed.

I dialed the number for the IT help desk, which was found on a large label pasted on the phone.

The following is a transcript, from memory, of the conversation that followed (names have been changed to protect the “guilty”).

Help desk: “Good morning, Large Bank Help Desk, how may I help you?”

Me: “Ahh, yes. This is Joe from IT, my password isn’t working.”

Help desk: “Oh? Did you check to see if the CAPS LOCK key is on?”

(Good first step, I think, shows either knowledge or a clean flow chart.)

Me: “Yes. It just won’t work. Can you reset it for me?”

Help desk: “Sure, but let me verify who you are first, OK?”

(Great, I think, they appear to know what they are doing so far.)

Me: “Sure, what do you need?”

Help desk: “Well, your full name.”

Me: “Joseph P. Itdirector”

Help desk: “Your employee number?”

Me: “123412345.”

(The number was printed in bold letters on Joe’s badge.)

Help desk: “Your extension?”

(Good, I’m thinking, it is NOT printed on the badge, but let’s try a bit of social engineering.)

Me: “Oh, my base is in New York, but right now I am at extension 223,” (the extension number from the station at which I was calling).

Help desk: “No problem, we just ask it to call back to see if your new password is working after we reset it.”

(Uh-oh, I think, BIG PROBLEM!)

Help desk: “OK, I reset it to be “PASSWORD1″ — all in caps.”

Me: “Thank you very much.” Then I hung up.

I turned to Joe and said, “Joe, your new password is “PASSWORD1.”

Joe nodded his head. “See?” he said triumphantly, “They asked all the right questions!”

“They sure did.” I agreed. “The problem is that the only two pieces of information they asked for were your name and employee number. Both of those pieces of information are found on your badge. Does no one ever lose a badge, which contains your bank’s name on it, around here?”

This happened with the IT Help Desk people, who should be some of the most trained IT people in the company, and this happened to the IT security director’s account.

“But,” Joe said, “You are here to do an IT audit. This is social engineering that you just did!”

“Not exactly,” I said. “We are here to do a security assessment of IT controls, and two of the controls we have to check are awareness and training. This showed us that some people are not as aware as they should be and maybe more training is needed.”

“Well,” Joe said somewhat defensively, “I am not the one printing the badges. This is not an IT problem!”

I agree. This is not an IT problem only. This is a problem for the entire organization.

If security professionals today do not see the connection between a physical access badge and the security of their information systems, we have a big problem.

“We are not here to cast blame,” I said. “We are simply looking to see which controls need improvement, and I think that the process to verify users can be improved, don’t you?”

In Joe’s case, the opportunity to improve was noted and later acted upon by the enterprise.

A complete new process involving IT security assistance was introduced to the help desk, and refresher courses are now an annual mandate.

A similar problem exists in IT people saying, “Well, access control is not my problem.”

They may be following organizational guidelines, but not organizational best ideas. An example can be seen in the CISSP exam’s required body of knowledge.

The 10 principals of a basic CISSP are:

  • 1. Access control;
  • 2. Application security;
  • 3. Business continuity and disaster recovery planning;
  • 4. Cryptography;
  • 5. Information security and risk management;
  • 6. Legal, regulations, compliance and investigations;
  • 7. Operations security;
  • 8. Physical (environmental) security;
  • 9. Security architecture and design; and
  • 10.Telecommunications and network security.

Notice that item three is not “data center continuity,” and that item eight is not “firewall security.” What good would 100-percent recovery of our entire computer and information be if we had no place to recover it to?

What good will a great backup program do if the employees (i.e. users) are not there to access it?

Similarly, what good is a firewall if by passing by one door or bypassing one receptionist, a person with bad intent has reached the keyboard? Has loaded the server on a truck? How is that “protecting the information?”

For our profession to continue existing, we must evolve.

Caring about firewalls and antivirus, for example, is an analyst’s responsibility, and in a large company, it’s a manager’s responsibility. To earn the “C” or the “O” and to continue to enjoy a seat at the table, information security professionals must become business people.

In many companies today, and perhaps not in small part due to the global recession, we see the security function being pushed down in the enterprise.

From a vice-president level to a director; from a director, to a manager. This trend reflects business realities.

We must metamorphose and trade our traditional IT focus and lingo into organizational (read: business) vision.

Business does not “care” about IT. Business cares about risk and opportunity.

Similar to how CIOs do not want to be seen as a utility (they would rather be seen as a strategic asset), security professionals ought to want to be seen as risk mitigators.

To ensure our survival and justify our salaries, we should look at organizational processes and not focus on IT functions.

The author is a former CISO, director of strategic consulting for a security vendor and a government security operative.