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."
Sorry for the self-reply, I just want to clarify something. I mentioned ex-military because for the most part military admins are provided software which has the "Seal of Approval," and are forbidden from installing any products which have not been "security tested."
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
The workplace I work for is a rather large multi-billion (possibly trillion) dollar business. When testing application compatability they use development servers which are a mirror to the production ones but completely disconnected from the external network.
1) Apply new software to test enviroment
2) Distribute access to a test group
3) Gather reports, determine impact
4) Distribute into production if deemed appropriate
It isn't the most cost effective solution but it works when you're trying to roll out an update to 1000+ workstations.
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.
well if you are using all commercial applications and not homebrew stuff, I highly recommend checking these guys out.
Secunia[secunia.com]
The will run a scan on all software on the system. Tell you what is there, what has vulnerabilites, patches availible, secure and what has reached their end of life. For those with patches missing or vulnerabilites it will then rate them on criticality. Plus you can also scan remote machines as well.
I find this very usefull for tracking down those bugger programs that are not always listed in add remove programs to see what is all hiding on the system.
MBSA is far from perfect, but it is what IS demands of us. See, us lowly SysAdmins know nothing about security. But IS tells us that Microsoft is secure and Linux isn't because (direct quote) "is is programmed by teenage turds in their basement that don't know anything."
I'm glad we have those specialized security experts (spoonfed by Microsoft) to keep me in line.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
I have 2 words for you...Virtual Infrastructure. VMWare or other simular software can save your bottom and offers easy rebuilds. Someone else may have said this already, but I don't have time to read ALL the comments! :o)
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
As so many have no doubt said above, you CANNOT determine which apps are secure, and there really is no existing 'test suite' for application security in general. It is far too broad a ground to cover.
What you need to do is identify 'known good' versions of applications. Essentially that is going to involve finding a version of each app, or maybe several versions, which have no known unmitigatable security issues. You can do that by looking for CVE's etc.
Those become your good baseline. From there you'll just have to monitor the various security mailing lists and subscribe to the vendor for each application for security alerts. That way you will know when a vulnerability is discovered in your application.
At that point you'll have to patch. The exact strategy you use is going to depend on the vendor, the OS, and your internal needs. In some shops it may be sufficient to enable windows autoupdates, or app specific updates. More likely you're going to need to manage and distribute patches locally yourself.
That brings up the next issue. You need to know what apps and versions each system is running. One way to do that would be to implement NAC (Network Access Control) on your corporate network. If you choose an appropriate NAC implementation it should be able to determine the patch status of a system, jail it if it isn't up to date, etc. At the very worst at least you can find out which machines haven't been patched.
Maybe your organization already has some of this infrastructure in place, so it might not be all that hard to do.
Now, all that being said, if you want to deal with strictly SERVER side applications, especially webapps, there ARE scanners for many of those. They are worth using, though you really should have something like an ITIL infrastructure in place for managing and provisioning those...
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
There hasn't been quite enough information provided to help guide you down to specifics, but let's take a shot. It sounds like you're still discussing thin-client web-based applications and hardening your intranet environment. One of the questions to ask is if you're a "buy vs build" company - meaning, do you buy an application to fill a business need, or do you develop an application to fill a business need? Penetration testers can check the applications for classic vulnerabilities - buffer overflows, cross-side scripting, sql injection, etc, but may not catch everything. Your best bet is, rather than relying on pen testing existing applications (or perhaps in addition to), to bake secure development habits into your software development lifecycle. This only works if your organization is developing these applications in-house. If you are more Applications will have vulnerabilities that will need to be identified and fixed; well-trained penetration testers can assist with this. An isolated environment will permit pen testers to cleanly focus on this application, but they can also test in your production environment. The other thing you may want to consider (regardless of the buy vs build argument) is having a standardized architecture in which to implement software on. The term 'Standard' isn't meant to imply 'homogenous' -- you can have a standard architecture for .net applications and a standard architecture for Java-based apps. Have standard server builds that are hardened for app serving. Part of deploying and maintaining a secure application is deploying correctly; changing default passwords, encrypting credentials when database calls are made, etc.
To further the 'standard architecture' discussion, you could even focus on the B2X approach; have a relatively isolated environment for your internally-facing applications (Business-to-Employee or B2E), and have another, perhaps more-hardened environment for your business customers (the business-to-customer or B2C environment), and finally, business-to-business connections (B2B) can use yet another environment. Strong policies and adherence to these policies around secure restrictions to develop and deploy in these environments will be very helpful.
Standard architectures also permits you to layer your security; don't just look at the app; look at the database calls, the server configuration, services that are running, patches that have been applied, firewall configurations, etc. Harden the environment, not just the app.
I'm more a believer in the standard architecture, rather than the penetration tester, myself.
Best of luck. :)
Well, for a security test environment, I'd find it quick and easy to set up a bunch of virtual machines on an isolated network (that is similar to your production network, with proxies and firewalls to the big bad internet where appropriate, etc.). This will make your test environment easy to clone & reset to a known configuration.
Then you want to place a sniffer (wireshark) where you can see all traffic between the virtual machines. This gives you some idea of what a piece of software is "doing"... what remote servers it's trying to connect to, whether it bothers to use any type of encryption or at least obfuscation when it sends data around in the network, etc. Might want to run portscans (nmapfe) as well to see what vulnerabilities the software opens up on your host, and whether you can exploit them using commonly available hacker tools.
Finally, it'd also be informative to have an intrusion detection system (such as snort + acidlab) on that network (as well as on you production network) to help catch and interpret suspicious network activity.
So there are some basic things you can do to easily assess what risks your applications pose from the outside. It will help you catch basic hacker attacks such as IRC / VNC backdoors and stuff. More sophisticated attacks (which might conceal traffic to the outside via sneaky TCP-over-DNS or the like, or hide backdoors using port-knocking) would be harder to detect... for those you'd just have to have an accountability trail back to your suppliers of that software, especially if you have no way to inspect the source code for that kind of malicious embedded trojan.