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 even be sure when you have the source code.
Tell the folks who want this list that you must trust someone at some point and that will always leave you vulnerable.
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?
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.
This is my sig. There are many like it but this one is mine.
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.
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.
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?
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.
We had a couple guys from their management team on our SecuraBit podcast. http://www.securabit.com/. Very bright folks, and if they weren't up in MA I might throw my resume their way.
All your base are belong to Google.
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.
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.
my suggestion is to call ibm. if you're concerned about windows and windows-based application vulnerabilities, ibm's xforce is responsible for finding a large percentage of known MS vulnerabilities. a couple of years ago, ibm acquired Internet Security Solutions, and incorporated their portfolio into the ibm high performance line.
of all security products that i'm aware of, it's the only one people never seem to be let down by.
check them out, give them a call, ask them questions. if it's not for you, they'll tell you so. www.iss.net
not only is time travel possible, it's irrelevant.