Why You Need to Allow Your IT Systems to Be Hacked (by the Good Guys)

Don Tennant
Slide Show

Seven Key Components to Start Your Incident Response Plan

If you were to give permission for an ethical hacking team to try to penetrate your systems, how difficult do you think it would be for the team to get in? According to one IT security expert who specializes in this sort of penetration testing, it would likely be a walk in the park.

Kevin Johnson is the CEO of Secure Ideas, an IT security consulting firm in Orange Park, Fla., that boasts the slogan, “professionally evil.” It’s a lighthearted reference to the company’s ethical, or “white hat,” hacking prowess, a prowess that, according to Johnson, can be downright scary for clients who hire the company to identify security vulnerabilities.

“We have never had a test that we didn’t find security problems. In almost every case, we find very serious, critical problems,” Johnson said in a recent interview. “For example, two of my guys right now are at a bank that they’re testing this week. On the very first day, before lunch, they yanked the bank’s entire customer database, including Social Security numbers and banking information. By the morning of the third day, they had complete control of every server, every workstation, every IT system.”


Some of Johnson’s stories would be funny, if the potential consequences of the lax security they routinely find weren’t so ominous.

“One of my guys and I have taken over three different airports by wearing FedEx uniforms, and walking in to the business offices and sitting down in front of computers,” Johnson said. “Nobody questioned the FedEx guys, other than to ask us if we could take a package. We were able to take complete control.”

One of the reasons Johnson cites for the distressing vulnerability of so many IT systems is what he calls the “silo-ization” of IT security.

“The majority of organizations I work with treat security as something separate not only from the business, but from the IT operation,” Johnson said. In fact, he said, a lot of IT operations go so far as to put policies in place that prohibit IT from testing its own security. I asked Johnson what on earth would be the argument for having such a policy in place. He said he wanted to be clear that he doesn’t agree with it, but the argument has to do with liability.

“Many people don’t understand. They’re thinking, ‘Oh my gosh, we just gave these nerds hacker tools. What happens if they hack us? What happens if they attack some other company from our network, using the tools we gave them?,’” Johnson said. “That’s bullsh*t. I’m not saying give your secretary dangerous hacker tools. But if we don’t empower and encourage people to understand how to see security weaknesses and what the attacks really are, there’s no way possible for them to fix it.”

Johnson went on to explain that another core problem lies not within IT, but with the users themselves. He highlighted a particularly serious source of security lapses: collaboration tools like SharePoint.

“One of my favorite things to do when I’m doing an internal test, is we’ll come in on Friday, we’ll connect to the network, and we’ll act like a disgruntled employee,” Johnson said “We go out to the intranet site—the SharePoint system, or whatever system they expose to their employees.”

He said these systems always have a search function, which is meant to help you find information on, say, a particular policy, or a certain document.

“Try it sometime,” he said. “Go to the intranet of whatever organization you’re working with—go to the search and type in ‘password.’ The first couple of pages of results are going to be things like you have to have a secure password, and it has to be 12 characters, and have special characters, and stuff like that.”

But in about the third or fourth page of results, Johnson said, you’re going to start seeing things like what the database username and password is for the credit card storage database, or the account name and password to access the internal HR system.

“It gives this information out. It’s there because somebody said, ‘Oh my gosh, I have to share this password with my team,’” Johnson explained. “Of course, that person already made a mistake by sharing a password with his team.”

Too many users just aren’t thinking about who does and who doesn’t need access to that information, Johnson explained. So it becomes available to everybody.

“We just have this problem of sharing data internally, which is the enabler,” Johnson said.” We don’t look at our systems as a whole. We treat them as individual projects, or individual functions.”



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.