IDS & Corp Auditing - dysfunctionality?

And I wonder why I get migraines...

Our area is starting to go through an internal IT audit. Ok - cool. We are running into a philosophical and soon to be, political matchoff between our areas and Corp Auditing. Why? Because we have host based IDS on our servers, we picked up on their scans, and now they want us to "lower our shields" so that they can come in and do their job... to do their job. Alright I am at a loss so I needs to tap the more experienced of us out there:

So is auditing "correct" in telling us to disable our IDS on our servers so that can do their job?

If so, why?

Thanks in advance for your insights!

:3pow: :splat:

I'm presuming you're systems are connected directly to the internet via a router (of sorts) and the auditors wish to enter from their site. I wouldn't lower my shields unless there were 2 tunneling routers in place (to accept their IP address). If they wished to audit you're site; then ask them to do it at you're site; rather than leaving yourself open to intrusion.

Well vescovono I agree with you, auditor asking to turn off your IDS is a bit weird.
1 - Access from the internet to your system for auditing purpose should not occur, unless they want to test the strengh of your security level in order to improve it.

2 - It could be acceptable if their flows are protected thanx to IPSec. But that's mean that you configured your PKI to accept their certificate.

3- Your IDS isn't active, do you? If yes that's mean it behaves also like a firewall and they can't access to everything. If no, I'll be paranoid and let IDS running to keep a trace of what they're doing in case of legal disagreement.

I feel that's the good palce to give my opinion about active IDS. The idea is great but the risk for false alarm and DoS is to take into consideration.
The IDS is there to alert that something is going wrong, dynamic conter measure can be dangerous to the safety and the stability of your net.

Quote:

---

So is auditing "correct" in telling us to disable our IDS on our servers so that can do their job?

If so, why?

Thanks in advance for your insights!

---

Unless your IDS is active, for example, a detected event triggers a block rule in iptables or you are running something like Psionic PortSentry that will detect attacks/scans then initiate a block on the particular machine, I would strongly disagree with the request to lower your IDS protection.

It would be a little more helpful if you mentioned whether your host based IDS was active or passive (something like logcheck, tripwire, etc) and perhaps even what IDS system you are using. Assuming it is passive, I couldn't think of any valid reason to turn it off and as such expose yourself to an increased danger. If it is active, maybe a compromise of just allowing their addresses in?

I also want to throw something else out there...we were audited once and the auditors requested that kind of access. We granted it to them to so they could get a detailed answer, they then went back and reported they had 'total access' to all of our systems and that our security was crap (grrr...still trying to pull that knife out of our backs)...we now politely give the auditors the middle finger after requests like this, so keep that in mind.

/nebulus

Is this a Security audit… if so then absolutely not.... Is this a system and network audit , if so why are they not physically at your site doing this?

Well - and no laughing - but we are using HP's IDS9000... for now! It is a host-based active IDS running on HPUX 11.X (e.g. 11.00 and 11.11).

We too have also been affected by the knife in the ol' backside, so we are less than willing to open ourselves up again. I know, I know they are doing their job in making sure we keep up to standards, but I still yell 'foul' about this "lower your shields so we can fire upon you" mentality.

This audit is an internal audit by our own company's audit department. Logic would dictate to cooperate as much as possible, but believe it or not -- politics have come into play about this because of what has happened in the past.

Thanks again!

And this is still how we feel about the audit:

:3pow: :shootem:

Whoa. Guess HP is the red-head-stepchild-blacksheep of the *nixes. Well now that HP will support Linux, we'll probably go to that -- too bad it's about 5 years behind everyone else.

Check this - HP is just now going to start using /etc/shadow! Ya - before we would have to 'trust' our systems for the added security. We just shake our heads and get the checkbook out to buy more servers.

Hey at least that puts you five years ahead of windows :)
Hopefuly with IBM and HP and Orical backing Linux it can now catchup to the rest of the *nix world

From my POV:

I would not turn off current protection. The less they can find out, the less they can report access to. If they can't get all the info they want, that means that you are doing your job.

Their job is to prove that you are not doing you job... so they want you to turn off your protection to show that you are not doing what you are supposed to.

If they are blocked... that means anyone else that any would be attacker would also be blocked. Just because they are using automated tools and can't figure out how to beat your protection... that is their fault. That is their job... beat your protection. They shouldn't be asking for your assistance...

By not turning off your protection, it will just prove that you are doing your job and the auditor are just a waste of time and money. (But still necessary.)

We had audits and we were also requested to ease up on our protection. We basically told them to stuff it. Do what they can with what they have. Then if there are weaknesses in our current protection... report that, and we'd take appropriate action. Needless to say... they didn't have much to report on... :D I don't think they've been back since.

Since the .gov requires us to have external audits (due to services we offer)... we just choose a different firm everytime. The results are about the same. They get nothing. We give them a port to plug into and thats it. They are lucky we give them that. We give them no policies, usernames, etc. That is their job to figure out. Any would be attacker would also be starting from scratch. Our auditors are treated as attackers. ;) You would not help an attacker... why help an auditor?

are you sure this isn't part of their test of your security systems? Something like a social engineering attempt to get in to your systems unmolested?

Personally it would have to come down from one of the officers of the company, in writing, that we had to disable our IDS. I would also, at that point, go on record stating that it weakens your overall network security, and while the IDS systems are down that you risk information integrity because of your inability to monitor the datastream.

that's just me, and I've been stabbed in the back a few times myself.

Good luck and let us know what happens.

Vesconovo: Really I think we need to know _what_ it is they are auditing before we can tell you what the appropriate actions should be on your part.

If they are trying to see how much disk space there is available to the network then there might be a, somewhat questionable, reason to turn off the IDS. However, if these systems are open to the world then tell them to turn up at the console at a given time and you'll show them.

If they are doing a security audit then the are "cheating" by having you remove some of your defenses.

So, what are they trying to audit and we can give you better advice?

What type of auditing do they plan on doing is of the utmost importance. Is this a securiyt audit? Are they just checking your network assets? It sounds like they could be checking you for "Social Engineering" by asking you to disable IDS.

My philosophy is that under NO circumstances will I disable IDS unless a director or above will take responsibility in writing.

Snow

I have done a fair amount of auditing in the past. I believe a good audit consists of at least two parts -- attempts to exploit your system from outside and from inside. Once they convince themselves that they can't get in from outside -- and announce it formally to whoever commissioned the audit -- then they should evaluate what a person with approved access (a disgruntled employee, a Nosey Parker, etc.) could do. They should perform the second from a terminal inside your net -- not outside with the protections turned off.

I would never ask you to turn off your protection systems. If I can beat them and gain legitimate access, that is the time to validate that with you and help you stop up the holes. Then I might ask for a user account with the same priviledges that I was able to obtain from the outside to demonstrate (if necessary) what else I could do.

Even if your perimeter is demonstrated to be strong, it is important to also verify what an insider could do. However, this should be done very carefully to avoid blocking out legitimate users and compromising any vital operations and information on the network. There should be a LOT of preliminary coordination between yourself and auditors to assure that tests are fair, that everyone agrees with the performance measures employed, how the results are to be interpreted, who will get a report, and that vital operations are not disrupted by the audit.

They have a list of about 12 things they are checking on. I have not seen the full list, but it what I have comprises:

1) Account management - cleaning up old accounts

2) Passwords - if they can get access to one account, they download the password file and run crackers against it.

3) Ports and services - using nmap or its similiar to a port scan of various ips to. They are looking for what is 'unnecessary,' but after a two year battle on the definition of 'unnecessary' we are at a stalemate, so a few of us were documenting what we were going to have open and closed & compare that to the audit results. We are moving to shutdown every service, opening only what the system or applications directly need, documenting those open ports/services per server and enacting a scanning/action feedback loop to check ourselves.

4) File permissions: shutting down any world-writeable files and directories.

5) ...

I will post more when I have the results - from what I have seen, we have improved from last time, but will still fail. I am somewhat embarassed as I have heard we will fail from the 'stupid' things, like passwords that have not been changed in the last 90 days or are considerably weak. So while I am toting this IDS flag and moving towards more advanced security lockdowns for the "windows of the house" while the "front door" is still somewhat open. Arrrggh! So in this audit they did not even need for us to "lower our shields." If this does happen, then we got some re-work to do here.