Usually we’re looking at a nice fat application wrapped around data. It looks great, manipulates the data into all sorts of interesting reports, and adds a lot of value to the data. But ultimately, without the hamburger, the bun is useless.

Many IT Auditors and business managers tend to approach security by testing the application controls - synonymous with testing the hamburger by sampling the bun. The bun looks great, controls are all set, no one can see what they shouldn’t, right?

BIG Wrong. This is why the PCAOB is now requiring SOX auditors to examine the configuration of databases. I’m delighted to see that this is finally a requirement, because that’s where the beef is, and always will be. Inside the databases.

First question to ask: How does the application talk to the database?
Every connection to the database requires a username and password (even if the password is blank). EVERY CONNECTION. So, what is the application using? I’ve found IDs and passwords hard-coded inside applications (well, you won’t be changing the password on that one!), inside ASP code on the web server that serves up the application (hack the web server, get the database, too!) and sniffed it online using port 1433 and/or ODBC connections (IDs and passwords run in clear text). Another fun one is to examine a user’s workstation and find the ID in the ODBC configuration (pushed out via script) so that the user can use their Excel application or nice Access database code. (Of course, I’m talking Microsoft SQL server here, but these items are applicable across the variety of databases.)

Second question to ask: What rights does the application ID have?
It’s ironic that so many software companies cut expenses by enabling an application ID that has db-owner rights to the database. That way everything works, right? I’ve seen it dozens of times, and it’s always painful. Often there is no DBA at the company, or it was installed and the DBA is stuck with it. If it’s in production, removing that access will probably break the application, and no one wants that. So everyone crosses their fingers and toes that no one discovers this easy in. And, PS, hopefully there is a password to that ID.

Third question to ask: Is logging enabled to critical database tables?
Don’t believe anyone who says, “Logging can’t be turned on due to performance issues!” Sure, if you turn EVERYTHING on to be logged, the server will tank. But setting up triggers that send reports and logging access to half-a-dozen tables is not going to impact the server (unless, of course, the application is already a hog). It means more work for the DBA, but if she is skilled, it shouldn’t be a problem. A good DBA can do that in his sleep.

This way you can watch who is getting to the beef. Why does the application ID matter so much? Because if I have that ID and password, I don’t need that application to get into the database. The application is just a pretty face - I can connect via Excel, Access, or any other database-connecting application as long as I have a username and password. Just to see what I can get. And if that application ID has dbowner access, or even better, sysadmin access, I can get everything in the database.

The application may have good controls, but outside the application, or using MY application, those controls won’t exist. Beef, lots of it, sans bun. In short, hacker hamburger.

So, OK, how does this make a good audit, Eigen, you ask? Sounds like a pain in the neck, right? Two magic words for you: compensating controls.

1. Create a Patch Management Policy
Policies come from the top down and demonstrate that the executive level is invested in managing and securing the enterprise. Policies dictate the scope of standards (“Once a month, we will review patches and document risk, etc, etc”) and procedures (“the patches will be tested on server A, deployed on production servers C,D,E…”) to deploy the patches. This Policy should be part of your overall Vulnerability Management. It’s part of managing risk.

2. Identify What Needs to Be Patched
Don’t just think Microsoft, or even just think servers. Every device on your network, at some point or another will need to be updated. Some devices may require multiple types of updates, such as a server that holds a database; both need to be patched. You need to know your entire inventory, and categorize those devices in terms of risk, so that you can prioritize patching. Some devices, such as your workstations, will need to have software patched, such as Microsoft Office. It will be worth your while to have a complete software and hardware inventory. Think of the SQL slammer worm: it paralyzed networks not only because of SQL Server, but because of all the default installations of MSDE (Microsoft Desktop Database Edition) on workstations.

3. Classify and Rank
Different devices on your network may have different levels of risk, so that patching them takes higher priority than say, patching a printer (yes, these must be updated, too!). Take the time to assess the devices according to their risk levels so that you know what must be patched first.

Different patches have different levels of risk. Those that Microsoft, for example, identifies as “critical,” should always be assessed and tested for deployment first. All patches should be reviewed for criticality and ranked. That allows testing and deployment to proceed efficiently. Lower priority patches can be deployed on a more moderate timeline.

4. Test, Test, Test
It certainly is true that Microsoft, in particular, has vastly improved its process for creating solid software updates that don’t, generally, break things. However, good process requires that you not make changes on a production system without ensuring that the patch will not break some critical procedure. Use your development environment as a test bed, or even your less critical production servers to rollout the patches to. You’ll be glad you did.

5. Document, Document, Document
What got patched when? How will you remember the reason you didn’t patch a particular server in six months? Develop a documentation system, or better yet, use your Help Desk system to document who, what, when and why. You can track compliance very effectively with those reports and not an extra cent.

6. Trust, but Verify
On more than one audit, I have discovered that the great piece of software the client set up to patch everything stopped working, or didn’t patch certain other systems. Once a quarter, run a check using MBSA (Microsoft Baseline Security Analyzer, a FREE tool from Microsoft) for Microsoft products, at the very least. It will also give you a good baseline on the security of those servers, and a better night’s sleep!

1. If we’re compliant, that means we’re secure.

Would that this were so! Unfortunately, the letter of the law is usually far less than the spirit of the law. If Management isn’t invested in securing the entire network, they often settle for compliance with existing laws and regulations. Having a secure environment takes a lot of resources, time, and investment in infrastructure processes. Compliance is only the beginning.

2. We have {enter name of software here} so we’re compliant.

I’m sorry, but there is no such software. There’s plenty that give out some really pretty reports and provide some oversight, but that’s very different from securing an enterprise. Usually, multiple layers of software and good people are required.

3. Our vendors tell us they’re compliant, so our information is secure. If they get broken into, it won’t impact us.

Ultimately, it’s YOUR data, whether it resides on a third-party’s web site or inside your network. If they are broken into and your data is stolen, that is what the newspaper will report. Your customers will blame YOU for not monitoring the vendor more closely. You can outsource functions, but not responsibility.

4. Everybody in my organization is trustworthy.

The “fraud triangle” consists of the following elements: Incentive, opportunity and capability. Anyone can find incentive if the opportunity and capability exists. Insider attacks are far more effective than external hackers. Organizations of any size that don’t do internal monitoring are asking for trouble - they’ve provided opportunity, incentive is plentiful and often the hack takes very little capability. If people know they are being monitored, they will think twice.

5. Compliance only happens once a year.

If you have strong security controls, policies and procedures in place, your auditors won’t spend half as much time on site, the audit will not require hours and hours of extra work and you can be quite pleased with yourself at the end of the day. Isn’t it great when you give the auditors what they’re looking for and they go away? If all that stuff is working, you have a secure environment and an audit is a non-event.

Don’t prepare any information in advance and tell me you’re very busy
We send out requests for information a month in advance and offer custom scripts to help get the information easily. It’s usually information you should have at your fingertips - user lists, MBSA scans, router configurations, etc. Database queries take a little more time. I know you’re really busy - what admin isn’t? When I don’t get any information, it doesn’t make you look busy, it makes you look incompetent.

Don’t answer my emails or phone calls
If your manager has told you to do this, route my requests directly to him, and cc me. Then you’re off the hook and your manager can look bad. That’s what they’re there for. If you’re just avoiding me, well, see the note above.

Be condescending about technical issues
Yes, I know IT Auditors don’t know your systems as well as you do, and we never will. We have to ask for dumb things. Be patient and tolerant, and we’re much more likely to be helpful.

Don’t allow my laptop on your network because “it’s a security issue.”
Please don’t embarrass yourself this way. A competent engineer can route us directly out the firewall without ever touching the network. This statement means you’re either incompetent, lazy, or hiding something. Not to mention the fact that I’ve been vetted, ’scoped and checked across multiple continents AND my company has a boatload of liability insurance. I break it, I own it. Smile, your network is safe due to your competence, isn’t it? Make it look easy.

Stonewall giving me access to critical systems because “you might break something.”
Other than questioning my technical competence, (thanks!) it tells me that you’re afraid I’m going to find something you don’t want me to see. Truly secure and resilient systems can recover from almost anything an admin can do to them. If your systems aren’t that secure or able to fail over, acknowledge it upfront. We’ll work out what I need to see together.

Lie outright.
I can count on the fingers of one hand (and not use all the fingers) the systems I’ve seen where the engineers and managers have been proud to walk me through and show me what they are doing. I love being “wowed.” I don’t get that very often, and I really enjoy seeing a well run network.

I’ve also had engineers take me aside and reveal security issues they were concerned about that weren’t being addressed, and I keep those sources as confidential as I can. If you tell me where the problems are, then I know you are not the problem. If you are losing sleep over some issue, share the pain - I can lose sleep, too. You can use an auditor’s report to get management to pay attention to security issues.

Make the most of my visit. Ask lots of questions. Understand why I’m asking what I’m asking for. It will make your job easier, and I’ll be out of your hair sooner. And who knows, you might want to be an IT Auditor someday. You’d probably be really good at it, because you would know where to look.

So, a nifty new FREE tool “rumint.” (Short for rumored intelligence - why the name - who knows) Anyway, when you load a capture file (it will run a number of formats, including tcpdump) and select “Text Rainfall” from the View pulldown, and Voila! A screen that pulls ASCII text from each packet in the capture. Oh my. What a thing of beauty. I had an epiphany, it was so easy to read. You can set it for looping, as well.

This tool is part of an emerging field of “Security Data Visualization.” When I first heard of this topic, I thought of dashboards and graphs, but that’s not what this seems to be about, except in a peripheral way. I’ve just bought the first book out on the subject, Security Data Visualization And so far it’s gotten some very good reviews from at least one big name in the field. It’s also written by the author of rumint.

I think what they are shooting for is a new way of looking at data flow that uses the best part of the human brain. Computers can do a lot of things around computation and correlation, but they are basically only as good at it as we tell them to be.

You and I can look at a dataset in a certain way, and it comes together in a gestalt. Computers are not yet able to do this. Like looking at enough pieces of a puzzle, suddenly we will see the picture. I had that exact experience with rumint, which, by the way, can also run with real time packet captures.

And in any case, if it makes your life easier reading packet captures, enjoy! Kudos and thanks to the author.

Continuing my quest for how to measure good security, I ran across an excellent article on the Information Systems Audit and Control Association website. (Yes, I admit it, I visit there and read lots of stuff) The authors grabbed me with a reasonable title: How Can Security be Measured? and one of the ways to examine the organization’s security posture as a whole is to use a capability maturity model. (CMM). Here’s the good point:

Management needs some measure of how secure the organization is. Organizations need to ask themselves:

* How many resources does it take to be “safe”?
* How can the cost of new security measures be justified?
* Is the organization getting its money’s worth?
* When does the organization know it is “safe”?
* How does the organization compare its posture with others in the industry and with best practice standards?

As you can imagine, there are a number of CMMs out there that relate to information security. The article lists several, and goes on to propose its own. Looking at the different varieties, I scanned over the organizations I have audited over the years, and considered where those organizations were in terms of the size of the business, the number of employees in the IT Department, and the complexity of the IT infrastructure.

The COBIT CMM has a structure I like:

Five levels of progressive maturity:
1. Initial/ad hoc
2. Repeatable but intuitive
3. Defined process
4. Managed and measurable
5. Optimized

Depending on the size of the organization, we can consider it like so:

1. Initial/ad-hoc - Policies are informal, everybody in IT knows all the systems, all the employees
2. Repeatable but intuitive - Policies are informal, everybody in IT knows what to do
3. Defined process - Procedures have to start getting written down, because the department is too big for everyone to know everything on the systems
4. Managed and measurable - Policies are put in place so that change is managed and communicated due to the size and structure of IT and the business
5. Optimized - Policies and procedures are developed to optimize change and manage risk - including compliance with regulations

If you think about your organization today, where are you in this model?

Here are some rules to follow for using an Intrusion Detection System on your network:

1. “Set It and Forget It” makes an IDS useless.

Why? Activity is happening on the network all the time. Suspicious events happen that are based on low level alerts that can aggregate - setting your email to high alerts only means you are missing the boat. Plan to spend at least an hour a day looking at the primary console and logs after you’ve finished cruising your firewall logs. And no, using an ESM (Enterprise Security Managment) tool to alert you does not get you off the hook. Only the human mind is capable of correlating activities and events in a remotely effective manner. We don’t yet have sufficient heuristics to automate intrusion detection.

Intrusion Detection Systems have a back end database to hold all the signatures they can monitor for. Some IDSs install agents on servers and have remote sensor collectors (say for the other side of the continent). The signatures can be updated almost daily. Do you need to install all the new signatures? No, but you’d better make sure you install the newest and nastiest ones that apply to your network. And keep the servers and database patched.

2. “We get too many false positives!” means it has not been configured correctly.

Why? Intrusion Detection Systems must be tuned. That means using about a month to analyze the traffic your IDS sees and eliminate the normal flow of events from your alerts. IDSs have an enormous database of signatures and if you turn all alerts for those signatures ON, you’ll be watching for UNIX hacks on your all-Microsoft network. Remove unneeded signatures from monitoring, and little by little you will remove alerts that are really normal traffic on your network. Why a month? Some transmissions only occur once a month. And taking out those signatures gives your sensors more CPU to see the traffic.

3. “One Size Fits All” means you’re not wearing anything.

I usually ask for the individual policies for each IDS sensor. For each sensor placement on your network, you want your intrusion detection system to watch for different traffic. It’s the best way to deploy sensors sparingly (and effectively) on a network. One sensor on the core router will not be enough, unless it can hold multiple policies: one for your internal network, one for your DMZ, and one for your extranet.

Think about it. You want to be watching for web-based attacks on your DMZ, but they will mean very little on your corporate network. Those signatures can be minimized internally, unless your internal web servers are high risk. If your DMZ is accessed from the Internet, many more signatures will need to be enabled. If you have one generic policy, you’re drowning in false positives and missing the REAL nasty traffic in the flotsam. And yes, you will have to spend time tuning and updating them on a regular basis.

4. “We have an IDS!” doesn’t mean it’s working.

Have you tested your IDS to make sure it’s working? I’m ashamed to say that too many IT Auditors don’t take a good look at this, and incorporate a simple test into their audits. A well tuned IDS should report an internal user running a portscan. It damages nothing, and is one of the most frequent first steps taken by a hacker with ill intent. And make sure that management knows ahead of time, but not the engineers in charge of the IDS. See what happens, and how quickly they report it.

4. “Oh, we outsource THAT,” means your risk has gone UP when your costs went down.

Unfortunately, I have yet to see an outsourced policy configuration on an IDS that was truly effective. IDSs are time intensive, and no one knows your network like an admin ON your network. As a result, you may get some very well-formatted canned reports every month, and it is certainly better than no IDS at all, but the effectiveness of the system decreases with every step away from your network. It’s a business decision, I know.

The other risk has to do with intrusions - you can outsource the functions, but you cannot outsource the responsibility, for both fiduciary and reputation risk should a breach occur.

Just buy a real boat anchor.

But your credit card information (and mine) is only as secure as the hardware at the point of sale. The machine that your card gets swiped through does all the work. And depending on the age of that piece of equipment, all of your information may be transmitted and stored elsewhere to be harvested by thieves. Or the machine may be compromised at the register by a dishonest employee that “harvests” your information. Other machines can be accessed (and hacked) remotely.

So, what do I check? Is the entire credit card number visible on the receipt? What about the expiration date? Some vendors sell machines that save the entire number to their copy and blank out the numbers on mine. You would think that PCI or the FTC’s FACTA law would mandate removal of all numbers on both receipts. True, FACTA does mandate that all but the last five digits be masked, as well as the expiration date. However, it doesn’t apply to manually generated receipts (the old-style imprint) or handwritten invoices or receipts. Notably it also does not require truncation of credit card numbers on the merchant’s transaction record or even the merchant’s copy of the receipt. Does that make sense to you? Me neither.

If you write in a tip, make sure you reconcile that number with what is billed to you….. otherwise you may be paying much more of a gratuity than you intended, AND you will have trouble reconciling expenses (I hate that).

And make sure the card you get back is YOURS. That’s another favorite trick I didn’t know about until recently when someone gave me the heads-up.

It has always bothered me that IT security and IT audit pundits and promoters propose all sorts of theories masquerading as fact for assessing risk. Everyone has a different unit of measurement, including some very large standards organizations. This is simply an attempt to justify the cost of securing data. It has always bugged me because I have yet to see a good explanation for measuring events that have not happened. If there is a solid security architecture, Bad Things don’t happen. Mostly. How to get this across in measurable terms is deplorably difficult to the non-IT parts of the business (usually management).

We’ve been reduced to using “compliance requirements” to justify the cost for “security initiatives” across an enterprise, and that limits their applicability to what the regulations require, rather than basing our efforts on solid evidence for security improvements. Measurements and quantification just do not exist. (Gasp! Heresy, I know.)

How do we differentiate between an organization that has no security incidents because of their solid security practices, and an organization that has no incidents due to blind, dumb luck? Or my personal favorite, no incidents because they don’t have any way to even know if such incidents occur? Yes, we’re fine because we have no idea.

Jaquith does a great job of picking apart the BS Bingo, especially flashy terms used by vendors, who must continually sell you something to stay in existence. (When did true improvement turn into the next release?) If you run a Google search on “compliance,” there are 133 million results. Try the same query minus “.com,” and the results fall to a measly 12 million or so. No wonder most of our security spending has gone to product, not process. Companies have turned to compliance as a metric for good security.

Yes, we have no real idea what constitutes good information security practices.

In the last 9 out of 10 Windows Domain IT audits, what group of people hasn’t changed their password(s) in over a year (sometimes two)? You guessed it. The last network admin got a little huffy, when I inquired, and replied, “We do comply with corporate policy! We just change them manually.” She cc’d my boss and her boss. Ouch.

I guess she didn’t read the file she sent me: it’s right there in plain text - the exact date. I copied and pasted her team’s last change dates, simply replying to ALL, and referencing the attached file. I try to be polite when watching someone loudly and publicly announce how badly they want to eat their shoes. After a pregnant day of silence, she came back with a very polite response telling me they were designing a new group policy just for their group to ensure passwords were changed in compliance with corporate policy. I could tell the shoe leather wasn’t very tasty.

I’ve done it too, as an administrator; somehow we don’t think that the rules should apply to us. After all, we’re the good guys! How, a non-engineer might ask, do they circumvent the group policy? Simply go into the administrative interface and select the checkmark for “password never expires.” All done.

As an IT auditor, I represent my company’s standard for IT, and so does a network administrator. If I am not following the rules, why should anyone else? Network Administrators have the most powerful rights on the network - capturing their passwords would allow a thief into everything. And the longer you don’t change it, the more time people have to work on getting it.

Plus, it just makes us engineers look bad.

P.S., the next most common group of non-changers? CEOs.