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.
If yes, then the product is insecure. If no, then the product is secure.
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.
If only the Internet had some kind of search engine where one could easily access the experiences of thousands of sys admins and/or developers.
I swear I saw another story like this one, about VMWare being used to test botnets, and being the perfect test environment for debugging etc., etc.
Sometimes, do we really need duplicates of stories only if we change the headlines.
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
Actually, it doesn't. Testing to find security vulnerabilities will be really iffy. Even if you spend a million dollars worth of someone's time and you don't find any bugs, you still won't know they aren't there.
Testing is just an incredibly inefficient way to find bugs, compared to auditing. You'll get far more bang for your buck by using Free Software whose source can be audited. The cool thing about that is that you might not even have to pay for all that work, since some of the other users will be auditing too. Spread out the expense.
This is the kind of thing where the engineers and the beancounters will be on the same side.
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.
Just another example of: "there are no low hanging fruit" (because they have already all been picked).
I would say, have lab of machines.
* install the new apps on your standard images, and see what security security or config changes they require.
->* also, look for how the app installs and how it appears to work.
->* maybe do some network sniffs and see what the app is doing
* also, check how the server side pieces work and how they talk to other serversa and to the clients
etc.
-Nex6
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
Why reinvent the wheel when you can just use the Common Vulnerabilities & Exposures (CVE) list. This list provides common names for publicly known information security vulnerabilities. Any software that's on the CVE gets removed from your list of approved software. People already did the work, why not leverage it?
'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
HAH! No such thing!
You should deny the installation of rootkits, they cause maintenance and security problems
Seriously. All you need to do is install a user-friendly Linux distro in the workers' machines, and install Windows using VirtualBox.
That's the only way to be sure.
If you're talking about installing software on the Windows Servers, I can only say this: ARE YOU OUT OF YOUR MIND!?!?
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
"Based on its breakthrough binary analysis technology"
Why don't they put this 'technology' in Windows ? Or how about designing a compiler that don't allow insecure code?
davecb5620@gmail.com
Evironment -> Environment
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.
That you mention MBSA has me worried. I've known several shops that were compromised and they relied on MBSA as some kind of tool to go by for securing things. Think about your attack vectors. What kind of exposure do your machines have? What are your users doing on those machines. You can't call an application secure and then assume you are secure. Security is a process, not a product. You want to provide reliability, availability and authenticity without compromising one of the others. You want to make sure that an authorized user can get what they want, that an unauthorized user can't get it or intercept it or modify it. There is a lot more to security than scanning and calling it a day.
My IT department has a rule where any software that does not have regular updating (i.e., windows update) is not allowed. Would this be feasible? Nothing is really ever secure, but an automated or regularly updated application should suffice.
MBSA only looks for know stuff like AdAware and Spybot does.
Windows - Sysinternals old stuff, FileMon, RegMon, and NetMon are what you need to use for seeing how applications behave within your environment.
This all depends on how locked down your environment is. If you have a masochistic GPO then definitely take this route.
Or, Enforce a solid GPO and let any application on there.
Self Defense - A Human Right www.a-human-right.com
When Microsoft cannot create secure software with their muscle, I don't see you have much choice.
Many organizations have tried this approach, but I don't know of any that have been really successful. [For one example, look for user reactions to NMCI -- the Navy Marine Corps Intranet that has become a 4-letter word to any half-intelligent user].
One of the problems is that there are lots of specialized applications. Users are often used to downloading open-source applications (like, say, an ssh client) when they need it -- and they don't want to wait three months to a year for it to undergo testing when it is necessary now. Depending on how large your organization is, there are a very large number of potential specialized applications that users may need or want. Most organizations underestimate just how many of these applications there are. It can be a really hard task to keep up with all of them. If you're talking about a small (less than 50 person) organization, it's probably doable. But any larger and I suspect you'll have problems.
Another problem is versions. If version 1.2 of some app is approved, what about version 1.21 when it comes out? 1.3? Does every version have to undergo the same degree of testing? And how are you going to treat emergency patches? (I've experienced cases when an emergency patch that fixes some newly-discovered security hole can't be installed because of security procedures governing software installations. Kinda ironic.) In my opinion, the only way for this to work is to decentralize as much as possible, and maybe have a class of users that you trust to install software. Otherwise, you'll experience a great deal of user backlash as well as a loss of productivity.
I thought we'd gotten away from the days of "e"-everything. But we're making a "Security Test E-vironment," eh?
Go figure.
I'm only wearing black until they come out with something darker.
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.
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.
One method I use to assess software quality is to skim through the source code. If the source is clean, organized, elegant, and well thought out, I have greater confidence. If the source is sloppy, uses inconsistent indentation/spacing, and is generally a mess, then it's obvious the author(s) lacked attention to detail and didn't put much care into it.
This doesn't fully answer the question—notably, clean-looking code can still contain bugs—but it can yield surprising insight in a short time.
After all, security is part of correctness, which in turn is part of building software with ability and care.
but my main concern is with Windows apps."
First, secure your OS somehow. A Windows install will almost certainly be less secure then a comparable OS X/Linux/BSD install, not only because of the openness of code, but security through obscurity. Your real trouble isn't with skilled hackers, they can get through almost anything if it isn't the nightly build, but rather script kiddies who use 1337hax0rtool.exe to attack.
And there is no such thing as a secure system, only a more secure system and a less secure system.
Taxation is legalized theft, no more, no less.
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"
Start with "Security Engineering" by Ross Anderson. The first edition is online.
Reduce, reuse, cycle
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.
Is that the three-prong o
Compatibility testing between different software suites: Good. This is the second reason to have a list because this is what you're going to run into a lot more than security issues. Some apps may require java1.2.3 another java4.5.1. Or having multiple Oracle apps on the same workstation. These are the issues your application packagers should be documenting for the helpdesk folks.
Testing software for security to be put on that list: Nearly impossible. "Testing" just isn't going to happen, as people have already said unless you get some companies to offer up source code and then have the expertise to even know what to do with it once you get it.
If you're that concerned start using IPSEC on your windows servers/workstations. It may not stop a virus from propagating from within the organization but it can keep snoopers at bay if they somehow get in.
-EB
Do you ever walk alone like a drifter in the dark?
waiting to thoroughly test app and system updates can be as bad for security as not testing apps. Will you wait weeks to mounts to test a windows update just to get hacked by some one uses what the updated fixed to get in.
... but rather to aid in the security management of the network overall. Having a list of allowed applications makes keeping up with what's going in the security world a manageable task. Instead of keeping up with the patches for every conceivable application, it helps to limit the amount of work necessary to keep the relevant software up-to-date. Depending on the level of flexibility employees require, this might for example include Firefox but exclude Skype.
Actually testing applications for security is way beyond the scope of any company not involved in the security industry, in which case, you wouldn't be asking us...
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
That is an incredibly bad idea which will make you the target of user hatred. Your staff is in business to do the business. This is like telling a carpenter that he has to get a new brand of hammer approved by the corporate tool testers instead of just going down the street and buying whatever hammer the hardware store has.
It's also a profoundly impossible task. You have no basis for validating all of the myriad shareware and freeware out there. For Windows software, you mostly don't even have source code you can inspect.
Your best bet is to simply forbid specific pieces of software that are known to be a problem (certain browser extensions) and specific categories of software of are usually a problem (peer to peer.) Then, add to the list as folks make poor choices.
Have fun!
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Web Applications: IBM Rational/WatchFire AppScan, HP's Web Inspect, RatProxy(google code)
OS and Services: Core Security's Core Impact, Nessus, NeXpose, Qualys
There are tons of application related security tools. If your organization is large enough to be creating this kind of environment, you likely have a Gartner subscription or at least have the funds to pull a report from them. Also search through the SANS reading room, they have tons of white papers.
It certainly cannot be secure because all apps have different functions, outputs and installation requirements. You would have to come up with a "lowest common denominator" for the security requirements that apply for all. And if so, it would be of such low common denomination that the term "secure" becomes useless.
What are you going to categorize all this apps with? With the requirement that they don't crash? That they don't access priviledge info (which is mostly done via OS/infrastructure restrictions). That they don't leak info (whatever that could possibly mean). That'd pretty much all you can use as a requirement for building a semi-usable, non-retarded list.
Furthermore, the security of an app, the criticality of it depends on who uses it, where and how. You don't care if your copy of MS Word crashes on your desktop, but you care if a copy of TOAD is running with autocommit on while accessing a production database.
Any IT person worth its salt would see the major folly of trying to create an authorized list of 'secure' applications for general use without specifying a context (type of user, type of use, type of resource been access, blah blah blah.) The whole idea is ludricuous corporate red-taping process-making, const-increasing hooplah.
Now, a wide and open list of authorized software by license (to prevent copyright violations), that makes absolute sense.
Security is an abused word. Most people have no clue what it means, incredibly and unjustifiably so by individuals who earn their living in IT. They confused 'authorized' with 'secure' and assume the attribute of being secure to be free of context, readily applicable to anything, like a color or something.
I want my database' color to be mauve as it has the most ram... plus it's more secure than blue.
I'm pretty sure if you do away with software completely you'll be pretty safe.
In the military environment where I'm currently working we have an established process where all applications, patch releases, etc. must, in effect, be profiled off-line in an autonomous network that's a clone of the real thing right down to DNS, WINS, AD/LDAP servers, boundary firewalls, IDS/IPS, etc. They're installed on a testbed PC running the same Standard Desktop Configuration (SDC) Windows OS release as the intended client's. We use InstallWatch to determine what file / filesystem / Registry additions, deletions, modifications are made during the installation. We then start and configure the product to run with the minimum rights necessary. While running we use netstat and etherape to determine what ports it uses. Any undesirable or unauthorized external connection attempts are either blocked by boundary protection firewalls or BlueCoat proxy filtering. If the results of this testing reveal no problems, we approve the software for our environment and build an SMS installation package. We verify that the SMS package installs and configures the software as desired, then put it in queue for distribution. Individual users are not allowed administrative rights on their systems, and acceptable use policies are widely published. Periodic and random software audits using SMS verify that only software that has undergone our testing and approval process is installed. Security patches usually jump to the head of the processing line so they can be pushed out as soon as possible. All this is expensive, but the cost is acceptable since the network and everything connected to is is considered a weapons system in its own right.
LOL. Just declare a policy against using vulnerable apps, and I'm sure you'll have perfect, instantaneous compliance!
You should set up a small ISA Server lab, and use its monitoring tools to tell you EXACTLY what the apps you are testing are doing, when they are doing it, and from where.
Another advantage of ISA, is that you can control apps via Active Directory. Combine that with packet inspection, and you have something where you can know the exact behavior of an app on your network. One DC, one ISA box and a couple of workstations (XP and Vista) and you can learn whatever you want to know about what an application is up to, when and where.
I repeat, even if you dont think ISA is secure (it is when done right) its the monitoring tools and the integration with AD that are what you need to get the job done.
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.
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.
IT should not be 'creating the list'. Security should be tasked with that. IT should be handed a set of testing procedures and tools used to test, provided to them by Security. IT people are not security decision makers. They, like security folks, have a role in the organization to help support business...and making security related decisions is not their role.
My brother is a high up in the military and complains of this 'seal of approval' constantly. Microsoft salespeople and other constantly will send their products to get 'evaluated' and get the seal of approval the next day as if someone can evaluate their product in 24 hours. Whereas other products that are open source or actually supply the source code can take MONTHS!
It's totally arbitrary and has very little to do with security.
I also spoke with someone who does application and system security certification for a national government. Basically companies pay, the team then plays around and tries to guess what's in the blackbox and what it's doing in there, and then after a while rubber stamps the approval. The tools audited that way are not ones selected by the government, for that matter. The vendors present something and then provide the money for the certification. No money == no review == no certification.
The dude was rather proud that they only did such audits for domestic companies. However, the weakness I spotted was that "foreign" companies only needed an office, subsidiary or representative and that feeble barrier was circumvented.
Certification simplifies "security" evaluation to a more or less straightforward financial bidding process.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
If you have a kickass appsec team you can put them on the job (few companies do these days). If not, hire out a contracting company like ioactive, leviathan, immunity, xforce, etc.
Pass them a list of software you want looked at, and they should be able to send it back to you with ratings on whatever scales interest you (long/short term threat to a corporate network, etc).
I'm not sure if one or any of the companies I mentioned offer services like that. They mostly do product security for the companies that release the software, but still my suggestion would be to write a proposal, pass it around, and see what comes up.
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.
The Navy & Marine Corps do it: DADMS
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
so how long will you test? what are the criteria to make it out of the test environment?
It seems a more reasonable approach would be to:
1. pick software that is in wide enough distribution that exploits are published and patched quickly.
2. Set up the production box on a private LAN. Scan the hell out of it. Lock it down. Scan it again.
If you think your team is going to find zero-day exploits... then you are either lost or secretly have the crack team (in which case you wouldn't be posing this question here;)
This leaves you with proven solutions, scan, lockdown/patch, scan. Then of course you'll need to keep the server/apps up to date and backed up. This is where most well intentioned admins fall short...
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
Apparently there is no spell checker on the list of allowed software applications.
An information security department. It's all well and good for a small business to have security minded IT pros, but there is something that every one should realize... management, IT, janitors... everyone. Ready? MANAGEMENT SHOULD NEVER BE IN CHARGE OF THE SECURITY DECISIONS!!! They will always be involved, but the moment you let them take charge of something they know next to nothing about, you get screwed. This is why businesses have weak passwords (or have them written on post-it nots, stuck to monitors). Sounds harsh? Too bad... The only management types that you want heading something like this would be a CSO or at least a CIO, preferably with years of experience and a CISSP or other information security management type cert. You need someone who knows wtf security is and the fact that there is no such thing as secure software... You need someone who can tell the higher ups where it is not their place to make certain decisions, someone who can educate the ignorant, so to speak.. Why do you think AV's are getting cracked and exploited? Not to beat a dead horse, here, but the idea sounds nice and is a good idea to a point. It should stop at which apps are allowed due to common sense and productivity. You do not want anyone to use limewire (malware) or bit torrent (bandwidth) in the workplace, but perhaps there is a need for IM clients to increase communication efficiency. In short, it is always a good idea to have a dedicated infosec dept that is seperated from, yet works with the IT dept. The jobs that each department does is MARGINALLY different, but all management types know is that they work with computers. You cannot expect business majors to understand what it would actually take to do a threat analysis of each piece software, just as you cannot expect Johnny Helpdesk to know what it takes to keep a business from running itself into the ground. It doesn't work that way. Helpful nuggets: Pentesting is your friend, if you can afford it. Security-minded staff and end-user education is the key to better security. And, lastly, HUMANS are the #1 threat to a security infrastucture, not software... always remember that.
Step 1) Unplug Computer
Step 2) Remove Power Button so that it cannot be turned on
Step 2.4) Send computer to ISS with monkeys only.
Step 3) NUKE IT IN ORBIT
My servers have been deployed in this manner.
my UID is Prime. It makes me special.
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. :)
HaloZero, per this quote from you:
"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," - by HaloZero (610207) on Friday August 01, @11:56AM (#24434863) Homepage
Well, it appears that (cliche)
"Great minds, think alike", per this post by myself today earlier also:
http://forum.tweaks.com/forum/Topic242936-28-2.aspx
E.G.-> In my last post there, in regards to tracing a system for remains of malwares & how to go about it, why + with what tools (Process Explorer for identification of the malware executable, Process Monitor for identifying the files on disk + registry areas it MAY use, & lastly, VMWare for a safe environs to reload & trace said malware in, IF needed!)
I.E.-> Same idea, same techniques, & same tools
(- &, you're right - it works, I've used it many times to kill say, the likes of VUNDO, especially when there WERE no removal tools for it, & variants of it or malwares that behave like it (for instance, hidden by being brokered by svchost.exe inside Windows (which std. taskmgr.exe does NOT 'breakout' child processes run by svchost.exe, as it does say, NTVDM.exe while it runs Win16 & DOS executables for instance))
APK
P.S.=> Nice to see a "/.-er" that knows this game... apk
Seriously. You really, really cannot possibly test for every possible vulnerability in every possible app, especially without the source available! The best you can do, IMHO, is to structure your network and systems to primarily isolate any possible bugs from spreading or from compromising integral data. In this way, if bugs or other breaches of security really *are* arising due to users installing insecure apps, you'll know which users did it because only their own systems will be f*ckd. Further, the users, being employees, need their computers to do their jobs and are not trying to maliciously break them (hard as that may be to believe). Indeed, the guy who's computer is broken all the time obviously can't get his job done, so why would someone sabotage their own job by breaking their own machine? Since I'm sure they really want to *keep* their jobs, many users will be happy to attend more training about good security practices, possibly even taught by you. This has the added bonus that you get to help close the human security loopholes that exist despite your courageous efforts to shelter the users from their own demise: you can remind them not to share their passwords, to check ID of visitors, to keep documents off their desk and screensavers locked when they're away, and all those other *ordinary security* measures without which could give a very malicious or opportunistic person direct access to the hardware on your precious network, a way bigger risk than any software bugs could present...
;)
Give your employer a cost-benefit analysis comparing the migration to either a Linux or Mac server backbone that won't let users f*ck it up so easily, to the zillions of hours of overtime they'd have to pay a whole crew of code-monkeys and network goons to moonlight scrutinize all possible apps for all possible vulnerabilities, and let them decide
-=[You cannot consistently judge this statement to be true.]=-
Try this:
Set up any box, make it OpenBSD, hell, SELinux.
http://www.openbsd.org/
http://www.nsa.gov/selinux/
Lock that bad boy down, complete with Honeypot.
Then go here - piss these guys off (not hard - be patient):
http://www.wolfware.dk/intro/welcome.asp
Did I remind you to watch from a disk-loaded Linux box?
A good time will be had by all.
You'll have to toss the hardware on both machines, but eh, if you grab the Honeypot traffic (if they don't catch it) you could write a book.
PROFIT !!!
~hylas
Backtrack http://www.remote-exploit.org/backtrack.html
I'd say it's better than sex, but I've only experienced backtrack.
I'm pretty sure if you do away with software completely you'll be pretty safe.
Didn't you hear about the 0day abacus exploit?
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
"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."
That sort of seems to imply that someone outside of the IT department thinks this is a good idea and the role of the IT department is to do as it's told.
That's so obviously f***ed that you needn't have posted the rest of the comment. The users should be telling IT what they want to get out of this, not how they want it to happen. IT should then get someone who knows what they are doing to come up with a sensible solution. It's not even a security problem that you have, it's a management and process problem.
If the head of IT is sitting back and letting this happen, they need to be moved on. If the non-IT bosses are forcing it this way over the head of IT's objections, the company needs new management at that level.
You can take measures to get some degree of confidence regarding any applications.
You put a bloody allegory that is frankly pointless, doing what you are suggesting (allow people to put whatever they think they need) is, using another better known allegory, to allow the fools run the asylum.
IANAL but write like a drunk one.
Like others have said, you will have a hard time unless you are an experienced programmer and have access to the source code.
Assuming you don't have access to the source code, I suggest you look at the vulnerability history of the applications you are expected to analyze instead of reverse engineering or fuzzing for vulnerabilities.
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.
Any 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.
I'm not entirely sure what you want to do. You want to either:
a) Analyze software in an attempt to discover vulnerabilities that are not publicly known. White/grey/blackhat shops that are much more qualified than you or I work on this full time, and there are still things that they don't discover. As a system/network admin without the security chops (and presumably without the abundance of free time), you'd be grasping at straws here.
b) Determine whether or not a piece of software is "insecure" before deciding to approve it. There are only two kinds of software that are inherently insecure - 1) poorly maintained or obsolete software (i.e. infrequent or non-existent patching), and 2) software that doesnt meet your company's security requirements (e.g. using FTP in an environment where login credentials and data in transit _must_ be encrypted). All you can really do here is make sure they're all patched and up to date, and attempt to mitigate any vulnerabilities where patches are not yet available. I'd say you'd be best suited by running programs like MBSA and Nessus, which will scan for publicly known vulnerabilities (including CVEs). That and read security blogs, forums, and check CERT bulletins regularly. Realize this is not a static process - a program that passed with flying colors last month will need a second look if a 0-day comes out. Your test lab would be better suited to making sure patches and updates don't break existing functionality before pushing them to the users.
...you can't have a secure platform connected to any sort of network, nor can it ever be administered by a human. For that matter, the base code can't be written by humans either. See: Star Trek: The Next Generation episode S2E03 "Elementary, Dear Data" in which LaForge asks the ship's computer to devise an adversary that could defeat Commander Data in the Holodeck (which it does!), and episode S6E12 "Ship In A Bottle" in which the same adversary gains control of the ship from within a computer system which is physically isolated from the ship's control systems (work that one out!) and is eventually pacified (in less than forty five minutes; how quaintly convenient) for two examples of what computers can be capable of without human intervention. Another example is a learning system such as the Daystrom M5 computer in the classic Trek episode "The Ultimate Computer". Also see: Joshua in "Wargames", Max Headroom in the self-titled show, and those several chess computers which have beaten Grand Masters without ever having studied their play techniques prior to the matches.
Computer systems which build themselves as learned responses to stimuli would, I think, be the most robust, even in a networked environment. As it is, any protective systems in place are written by humans in response to known threats only: antivirus is only reactive, it can never be proactive, ever. The only real protection a networked computer enjoys is the obscurity of the kernel it employs. Long live Linux, may it forever be a nerd OS! :)
Operation Guillotine is in effect.
Quit your company now and get a real job at a real company, you'll thanks me later.
Let me guess, they want to put Windows and Internet Explorer on the list, right?