Security Assessment Team

All,

I haven't posted for awhile so I'm hoping this is the right forum for this question....

I'll give you a run down on the situation first and then hopefully some of the guru's out there will be able to fill in the blanks...

Firstly, I'm working for a government organisation that has certain security requirements when it comes to our network and server base (Server 2003 and Linux (various flavours).
Joy of joys, we have come up for an audit later this month and it is apparently fairly intrusive and wide reaching.

They have given over 3 hours for one of our networks which is primarily a Windows 2003 servers environment using Cicso switches/routers that is NOT connected to the Internet. Physically seperate entirely.

The opinion and thoughts I'm looking for is what tools do you think they'll be running to scan out network? We are already using the SE core for Linux, and have tried (as much as possible) to lock down the windows servers.
Today I'm looking at running Bastille Linux to help on the Linux boxes and Nessus followed by ethereal to see what is open and floating around the network but I'm a little worried that I'm missing something?

Lastly, is it worth installing the encrypted IOS on the switches aswell?

Any thoughts would be great.

Thanks,
Ross.

I would have a look at the NSA Security Configuration Guides located at http://www.nsa.gov/snac/ . You can then test them using the tools from Center for Internet Security. http://www.cisecurity.com/

Whatever you chose to do make it either matches your policy or look to changing the policy itself.

Thanks, I'd already found the NSA site and have started on the Cisco stuff from there but will look at the CIS site for testing.

Cheers,
Ross.

Hi Ross,

Quote:

---

Firstly, I'm working for a government organisation that has certain security requirements

---

Yeah, I know what you are on about. I will leave the technical stuff to the Gurus and just suggest a bit of practical "audit defence".............. if you know what I mean?

Those buggers are as cunning as a cage of monkeys, trust me on that one mate! Please, please don't overlook the obvious............

1. Wear badges at all times........... if they don't (as is more than probable) then a properly conducted "armed intruder" or whatever you blokes call it, response goes down well.

2. Watch for physical security........... is the door locked? has the removable drive been put in the butterfly cabinet?

3. Has all authentication been carried out to the book? has everything been double checked? and signed for ...............

4. Make sure that they are escorted at all times, preferably by armed personnel.

5. Watch out for the "dolly bird", that is a favourite of theirs............. ;)

Those guys carve notches in their briefcases for blokes they shoot down............. make sure you are not one of those notches mate.

You see, the guys they report to at the top know damn all about IT security........... they will probably try to trick you and catch you on simple physical security......... it is how they justify their existence?

Good luck mate!

;)

Good advice Nihil, even though I had to ask one of the old hands here about the Dolly Bird :)

Physical security is definately a big one, I'm still waiting for the locksmith to upgrade our doors just to be sure on that front.

Thanks again and let's hope that luck doesn't have anything to do with the outcome here!

Keep it coming guys.

OK, a few more thoughts:

Quote:

---

They have given over 3 hours for one of our networks which is primarily a Windows 2003 servers environment using Cicso switches/routers that is NOT connected to the Internet. Physically seperate entirely.

---

That is what we would describe as our "secure network".................... not surprisingly, the weakest link is probably going to be the desktops and users?

It would probably be a good idea to get your user community involved by having a "security fortnight" and reminding them of whatever rules you have regarding external devices, cameras, cell phones, iPods, PDTs, USB drives and the like ;)

Also check that they cannot attach external devices to PCs connected to the secure network, and that your system detects the connection of unauthorised devices to it.

Please do not overlook the humble null modem cable :eek:

I would also suggest that you do your own audit check on the desktops to make sure that they cannot be booted from CD/Floppy/USB............... it would only take one to have slipped through the net?

Also, make sure that all the cases are locked....................

Another thing that can be overlooked is security of any print servers that may be attached to the network. Particularly as these may have had another function previously, and may contain software from that time that now poses a security risk.

Just a few thoughts :)

You may have armed guards in the front lobby, require photo and electronic ID before being allowed entry into the building, but if the ****-house window is left open to the rear parking someone can easily gain entry to the building. ( don't know how it applies, but that is what came to mind when I read this thread. )

Nothing for nothing, and I don't know who it is that will be auditing you and who you work for, but I think nihil is on point yet again ... the obvious will bite you. ( guessing here by statements given this will be more of a security then compliant audit ?? )


Even people who know better often times become complacent.
Besides what has already been stated,
Passwords:

Do people have sticky notes with their passwords on their monitors?
( Do you have password policies and are they followed? )

Do your passwords expire after time? Are they checked before being allowed to be used ( length, easily guessed, etc.? )

Do people give up their passwords to other employees ( or others ) for any reason?

Are your employees routinely reminded about social engineering?

Do your admins have one generic password?


Accounts:

Are unused accounts deleted or disabled?

How and how often are these accounts verified ( policies in place ) and who is responsible for doing so?

Are tasks assigned to admins properly segregated between the admin accounts?

Are users provided with only the access they need?

Services:

Are unneeded services removed from systems?
You may be very conscious of doing this on your servers, but this equally applies to workstations.
These are avenues for insiders to take advantage of.

Also, make sure all necessary patches have been applied, not only to the servers and workstations, but to the routers, etc. There should be no machines or equipment unless absolutely necessary that run systems that have reached their “end of life” and are no longer being supported ( Windows NT, Red Hat 5.x as examples. ) Be prepared to explain and justify in detail why it is absolutely necessary to run those systems.

Make sure that if you have systems that are required to be segregated or isolated from other systems that they are!


Review your policies
Trying to straighten out problems a month before an audit is futile at best. Hopefully everything mentioned so far is done routinely, so you don't have to worry about it. And hopefully you have proper policies in place that cover all the necessary areas both for general acceptance and for your particular needs. But nothing is more embarrassing then to have made known that you do not comply with your own policies. It is one thing to be able to show ignorance of generally accepted standards, as they change so rapidly ( your ignorance may show you are not qualified for the job, ) but is another entirely if they show you have not complied with your own policies, or have not made proper policies. This may not be just ignorance or incompetence, but in a government situation may be misfeasance.

Remember, if an audit finds major security problems they may not even get to compliance issues, or even delve into further security issues.

As far as your specific question, they will undoubtedly use a combination of open source and commercial tools. If your policies and their compliance of which are adequate, the tools they use should not make a difference.

I hope this helped, and I hope this encouraged you rather then worried you.

I've been through a couple of these tests as well. Seen them use every trick imaginable.
To say the least... they are amazing and almost always find ways in.

They probed every aspect of Security pertaining to a military Command Center: Physical Security, Network Security, Telephone systems, and most specifically, how/if end users followed security policies. The various teams conducting the test took days. Found out they even had several people in plain clothes hang out at local resteraunts during lunch hour to see who came in and if they still had their ID/Security badges on in public. They would also eavesdrop on their conversations to see if people were talking about work related (and/or sensitive) issues outside of the facility. All of this ties into Information Assurance training programs.

Also a consideration, limit their availability to your network. If you can, enable some sort of Port Security. A lot of times they will walk around, or if assigned to a specific area, will look for a way to jack into the network and run scans. If the port doesn't work, or is locked down in some fashion, you will have earned bonus points on your review.

You mentioned you have networks that don't have access to the net. In case you are referring to a Niper and Sipernet-like configuration (where you have an unclassified network which has access to the net and a Secret or above network which doesn't) you will most likely have users that have individual accounts on each of those networks. Of course the Information Assurance trainings tell you not to use the same passwords on various networks, but you still get people that do out of laziness..... or in some cases, the upper brass don't always feel those rules apply to them. Regardless, compare passwords from the various networks to see if users have used the same password. If your pen testing team cracks the SAM on an unclass system, I guaranty they will throw those same usernames and passwords against the classified systems. It worked on one case. At that time, one of our own admins (who was the least likely to do this) has the same password on his Niprnet and Siprnet accounts. The pen testing team was able to comprimise a machine on the Niprnet and eventually get access to the SAM on one of the DC's.
Sure enough, they took the username/passwords and ran a dictionary attack on a SIPRNET machine and got in..... WITH AN ADMIN account.... DOOOH!

Anyway.... good luck... these tests are nerve racking!

Thanks guys, your putting forward good ideas and suggestions.

The username/password combo on two separate networks is something that I hadn't thought of, so something to bear in mind as I'm doing my own testing.

Thankfully there is NO access to any USB ports anywhere on the network (not even USB mice) so that is a small bonus when it comes to watching camera's, usb sticks, ipods etc. Likewise the BIOS's are locked down, but I alwas see that as a week link... out with the battery and hey presto, they're in :(

Anyway, thanks again, and any more suggestions would be welcomed.

Cheers,
Ross.

Wotcher Ross,

Quote:

---

out with the battery and hey presto, they're in

---

OK, that is why I mentioned the case lock (physical) and the case opened warning.

Look at lappies.............. some have a boot password, and a login password, and then a hard drive password. The HDD is encrypted as well. I still like the removable HDD solution, and it is not expensive to implement! :) You can do what you like with the BIOS, but without a HDD?

So, what is it with the lappy? well, they have a separate EEPROM chip on the MoBo that handles the physical access. I seem to recall that they are 24C chips? You can leave the battery out for eternity, and it will still not let you in, because it is non-volatile memory.

Yes, of course I know how to get round it, but that should be beyond your average auditor?

The HDD password is a real pig..................it lives in a hidden sector of the HDD, and we are looking at serious Intelligence Services budgets, staff and equipment for this one. I will presume that is what you have to assume in your scenario?

Please have your "proposed security improvements" paper submitted to your GOC about a week before the audit...............it sort of takes the wind out of their sails

;)

Cheers, Johnno

Alrighty.

That was a stressful couple of days but a good learning experience as well. As pointed out by Nihil they were very keen on physical security and impressed by the brand new dead locks on the computer room etc.

In the end they had to ask for an Administrative account as their scanners could penetrate our network and then we had to turn off SP2's firewall on the MS boxen. Very happy with that.

Nessus was the scanner for the Linux platform as expected and that worked in our favour as we use that on ourselves from time to time to see where we're lacking.

Once they'd scanned all of the networks they put out a preliminary report and our network got a pat on the back for the firewalls and also port security on the switches.... Not a bad result so far, now to wait for the full report....

Thanks to all who contributed to this thread. Now to update all of the policies that this process has highlighted I'm missing.

Thanks again,
Ross.

I haven't seen it mentioned, but I'll be honest and say I didn't read every response.. But shouldn't your security policy tell you exactly what they will be looking for? I'm not sure why you would have to go all over the internet figuring out what kind of security you should have when your policy should tell you exactly that. If you don't have a detailed security policy I really wonder how you can complete an audit. How do they know what to check for?

I have complete security audits run every month against several of my machines, these consist of weekly automated checks, monthly internal machine configuration checks, and monthly physical access checks. I never get worried about it because I know the policies and I'm following the policies. Are the machines locked down as tight as they can be, no.. but the policy doesn't dictate that they be any more secure than they are for the data that they have. To me a security audit is like an open book test in high school where you were given the questions two weeks before the test. You should know what they are looking for and should be able to insure you are 100% compliant well before the auditors arrive. I do agree with the other folks that this is not something you should be trying to scamper to fix 30 days prior to an audit. You should be doing it all of the time.

IT operations should have access to the same scanning tools that the Security organization has access to so that proper testing and configuration management can be performed at all times, not just when you are undergoing an audit.

some audits, like Visa PCI don't care too much about your policies (well this is a qualified statement, merchant PCI is one thing and service provider PCI is a different beast all together). While they will test that you are indeed meeting your own policies a lot of audits will go outside of that scope. When I was working in the financial world the FDIC and Visa would regularly conduct their /own/ audits of us that had little or nothing at all to do with the mechanisms that we had in place already.

One little snafu I recall is that we were encrypting data sent from our application servers to our database servers but we had a "weak" key management system in place. We were following our own policies which were fine for stuff like SAS70 audits, internal audits, etc, but when Visa hit it they weren't too pleased with it. They required us to use HSMs to secure the keys.

So while were were good based on our own baseline, and previous audits, we were dinged pretty hard by an external audit that wasn't testing our policy but /their/ own policy against us. A lot of gov't auditing is the exact same way.

Oh and fwiw Visa gave us no heads up as to what to expect from their audit. Trying to get info as to the audit requirements for Visa PCI is like pulling eye teeth, unless you know the "right" people.

I think that it is a good thing that they didn't know exactly what the auditors would be looking for. If someone was actually going to try to break in to steal information, I don't think they would call up the organization and say, "OK, I am going to try to break in, and this is how I am going to do it... " I mean what is the point of doing the audit then. I think that even telling him a month in advance was nice of them. Security practices should be followed closely every day, especially when you are working with sensitive data. Just my thoughts on the subject, I could be way off.

I completely disagree. If you are doing work for Visa, then they should tell you what they expect from the get go. The purpose of an audit is to make sure you are following policies or to correct problems in the policy. It isn't to try and suprise you with things you never thought about.

We do a lot of work with american express. Every system that has anything to do with american express follows our corporate security policy as well as the specific machine policies that were created for those machines by our corporate security department and some security people from AMEX. When they are audited they use the agreed upon security policy. Nothing else. Our policies, as most should, even define how the audits will be conducted.

Quote:

---

Security practices should be followed closely every day, especially when you are working with sensitive data.

---

And without a complete policy how do you do that? Just go on the best effort of the administrators? I don't think so.

Everytime I have ever worked with a government agency or any type of financial firm their security policies were always made very clear from the start. I can think of one audit where we were dinged for several items that were added by our customer to their security policy. When the final report came out as to why we were not following that particular piece of the policy the blaim, and subsequent corrections, were made to their communication process. They had never ok'ed those changes with our security organization, and they never told us.