Slashdot Mirror
Creating a Security Test Environment?
Enderandrew writes "Our IT department has been tasked with creating a list of authorized software, and only allowing software to be added to such a list after it has been thoroughly tested. In theory that sounds like a great idea — but how should we test apps to make sure they are secure? We have tools to scan internal websites, and we use MBSA for our Windows servers. However, I'm turning to Slashdot to ask what are the best methods for creating a test environment where I can analyze apps for security vulnerabilities. We're a multi-platform shop, but my main concern is with Windows apps."
Security at what level? You need to draw a line where your security is 'good enough', because some things are simply too far outside your scope.
;), but instead to secure yourself, your customers, your employees, and your infrastructure against a broad swath of threats. You can't tighten the screws down on one aspect alone and proclaim being bulletproof.
VMware is your best friend in this case. When dealing with client/server software, I'd install it in a VM, and then nmap it to see what affect it had against the machine with or without a firewall. Just to see what sort of ports were open, to characterize the software.
You can also use a lot of the great tools from SysInternals to poke around a bit more in the softwares workings, but using only software that is 100% security certified means you're going to have a bunch of people with blank hard disks. If you're using Windows and are paranoid to that point about security, I wouldn't look too far under the hood of that operating system if I were you.
There is the 'Good Enough' line. The point of systems security is not necessarily to maintain a paranoid, logged level of dilligence against every packet (though DPI isn't a -horrible- idea - it's ALL situational, tho
Informatus Technologicus
IIRC, nessus does network security scans that check for holes in software on the network (missing patches, etc.). You could do a pen. test using a live CD like Arudius, INSERT, PHLAK, etc. Check out the security live CDs at Frozentech's Live CD site. Many have the nessus package on board.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
You should deny the installation of rootkits, they cause maintenance and security problems
and refuse to give them hot pockets until they crack the program.
This is a no-win situation for the persons assigned to certifying an application. I personally have a very hard time communicating with managers who believe, with an unshakable faith, this is a reasonable solution to a perceived problem. When it blows up, MY head rolls, not theirs. The ages-old "Get IT in my office *now*" blame-shifting game.
The right way to handle this would be to push back hard and explain why this is an epic failure in the making and resources quagmire. That isn't typically a good political solution though.
I would love some advice as to how to change such foolish thinking.
Maybe you've got a good thing going there, but if there have been IT organizational changes recently, this may be a harbinger of things to come.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
If a group from sales can't break an app, it's secure.
You might also use a bunch of chimps. The only difference there is all of the poo flinging, screaming and downright annoyance factor, but it's hard to find good chimps, so it's easier to just put up with it and use folks from sales.
1) There is no secure software. Just software that doesn't have any known vulnerabilities.
2) Define 'thoroughly tested'.
3) White-listing applications is going to cause your company pain as people wait for required tools to become available.
4) You can't afford to do this yourself.
Look at it this way. When PHB is shouting for his new shiny piece of software to work, you can bet that 'thoroughly tested' gets severely watered down. You'll be left with some software on the list that has vulnerabilities whilst other people can't get their jobs done because the software hasn't been listed yet. Even if you avoid those pitfalls and manage to 'thoroughly test' each application, how many applications does your company use? Say you can test an application in 2 weeks - For one fulltime employee you'll white-list 24 applications in a year. The fact that you are asking /. for help suggests that you don't have much knowledge or experience in this field, so you're going to have to pay for training or for an employee with that training.
This model is doomed to failure, and whoever suggested it should be shown the door and replaced with a CISSP qualified guy (or gal). Security is a process, and what you need are tools to help carry out that process. Someone with a CISSP qualification will know where to find those tools.
Some of those tools might include auditing (to find what applications are in use), firewalls, IDS systems (to detect suspicious traffic), patch management (to mitigate vulnerable software), an intelligence provider (to tell you about new vulnerabilities and patches in a timely manner), a Security Event Management system (to manage security data and drive processes) etc...
For the record, I am a QA lead engineer with experience in enterprise and industrial security. I do this kind of stuff for a (good) living.