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."
You can't be certain unless you have the source code, so tell the folks who are requiring this list to be created that they can say goodbye to Word and Excel.
Unplug the network cable. Its so easy even a caveman can do it.
I know that for most federal government institutions, the NSA is involved testing a product for its security. I've never heard of a place doing it in-house.
Is your boss ex-military or something to that effect? If so, he may not understand the complexity of the task he is assigning.
Just how thorough of testing is being asked? Some security flaws escape eyes for years (see DNS flaw). Some flaws are obvious. But, in general, you can never be 100% certain of a program be 'secure' unless you know its has passed some milspec cert.
While optimistic, I think the new policy is a bit misguided in its wording.
Bearded Dragon
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.
Veracode
Based on its breakthrough binary analysis technology, Veracode offers the world's first subscription-based security testing service that provides organizations with the only automated and independent assessment of security risks in applications, whether those applications are built in house, purchased as commercial off-the-shelf software or developed offshore.
Disclaimer: I know the founders but I am not involved in the company at all.
- SR
'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..'
...
You can't test for security vulns, especially in a Windows environment, as there is so many interlocking components that behave differently depending on the configuration. Introducing a service pack into a previously 'secure' environment and all bets are off. All you can do is patch, patch patch
You could also intalss a second intrusion detection system that monitors the first for unauthorized access and keeps a full audit of access alterations etc. You could also compartmentalize your system so as a breech in a web service doesn't automatically lead to a total system compromise.
davecb5620@gmail.com
You should deny the installation of rootkits, they cause maintenance and security problems
You are apparently talking about black-box testing. For starters, you need a security team to perform penetration testing on the apps in a production-like environment. But if you have home-grown software, you need to address the problem of insecure systems being built by your programmers. The programmers need to understand application security. For a somewhat theoretical but still practical treatment, I recommend my own book, High-Assurance Design (Addison-Wesley, 2005). You should also check out Michael Howard's book and his blog. And then there are Gary McGraw's books which address process. - Cliff
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.
The likely goal (from a management perspective) is to establish an authoritative list to allow for efficient management of vulnerabilities. If you know what's out there and "authorized" you can respond to threats far more quickly than otherwise.
Your management would be silly to expect you (unless you are an application analysis company) to thoroughly vet every application that comes through the door. It would be a terrible waste of time.
Do some basic analysis (what ports does it open, does it connect out to other systems, that sort of thing). Beyond that, I believe the value is simply in knowing about the application and being able to track any potential issues.
Boss: create me a secure test environment.
guy: OK, my first step is to ask the people of the internet.
types: dear slashdot, how can I create a secure test environment?
slashdot responses:
-do not use any microsoft products. they are the borg.
-the important thing is whether you will use vi or emacs.
-use a ham radio instead
-who's going to "helm" the next LOTR "vehicle"
Security is about mitigating risk, not eliminating it.
There is no such thing as an app that is "known secure", only apps that are "unknown risk" and "definite risk".
With that in mind, you can mitigate your risk by:
1 - Closing ports down that you don't absolutely need talking to the world. Nmap is your friend here.
2 - Scan for as many known attack vectors as you can. A good start? Metasploit. Get it. Use it. The bad guys are already probing you with it.
3 - Personally, I also like to run a different server OS than desktop (i.e.: you probably have Windows on the desktop, so use Linux in the server room). Exploiting shared vulnerabilities between client and server makes life so much easier for the bad guy that REALLY wants to spoil your week.
4 - Beware of trust. In this case, beware of trust relationships between machines. You don't want one compromised server leading to a bunch more.
5 - Containment. You CANNOT guarantee every system is secure, so design your network to allow for the eventuality that some portion WILL be compromised. Limit the damage before it happens.
Oh, and after you use the black hat tools to test your network, scrub those systems you used to bare metal. Don't trust that those systems are still trustworthy.
Life is short: void the warranty.
I'm pretty sure if you do away with software completely you'll be pretty safe.
You can't even be sure when you have the source code.
The point there is that you have to have the code for the whole stack not just an isolated application. For an application to be secure, you have to be able to do a valid code audit. For the code audit to be worth anything it has to be done all the way down to the core: compiler, libraries, utilities and operating system. So you can be sure when you have the source code, but you do have to have all of the source code.
So without even touching on the quality issues with MS, lack of code access rules out all MS products from the system on up to user applications. "Shared" source might be fine for specific, limited, platform-specific development contexts, but is basically the same as "escrow" And "escrow" is just another name for closed source, namely, as Ken Thompson point out, insecure. Ditching MS products won't automagically make your site secure, but it is a necessary first step.
Now there are some short cuts one can take in Ken Thompson's example. However, they all boil down to having the code for the whole system as he points out, not just parts. Even diverse double compiling requires, at the end of the day, a system that has been vetted top to bottom to use as the baseline.
Now the next step is to deal with smaller, more modular units of code. They're not only good design but also easier to manage. Again, that rules out a certain party ...
FWIW it's interesting that the ACM recently pulled the Thompson article. It had been available for over a decade. One wonders how much longer the ACM will be a useful source of technical information.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.