×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Does Open Source Need a Red Team?

Cliff posted more than 10 years ago | from the stuff-to-discuss dept.

The Internet 49

garyebickford writes "IMHO the Open Source community (whatever that is) needs a Red Team project. This would be an open source project, but its output would be a process rather than a piece of software. If such a group exists, I'm not aware of it. This document and this page [from the Google cache] are from a commercial company (picked at random from a Google search) that provides similar services. The OS Red Team would provide 3rd party security testing, code review and evaluation for open source projects prior to release, providing a 'report card' stating what has been reviewed and tested, and recommending fixes. When a package is released, the Team's 'weather report' stating the probabilities that a package would survive different kinds of attack would be a valuable piece of information for prospective users." Do you think the Open Source Community would benefit from such an effort?

"The Team could also provide a set of recommended processes and tools for O.S. projects to follow prior to submission to the Red Team test queue. This by itself would be a valuable tool.

Such teams are sometimes used by companies to test the security of their networks and software. The O.S. community have done an excellent job so far, but as open source is used more and more by the mainstream computer users, vetting by a 3rd party would help make many organizations more likely to accept a piece of O.S. software.

The Team would, like any open source project, be comprised of both experts and newbies. The newbies would have the opportunity of doing real testing under the guidance of folks who know more, thereby becoming more expert themselves. The experts would provide a centralized open-source-oriented set of recommendations and specialized review as needed.

Either the Red Team or its members could also provide paid services for commercial software, and could participate with university CS departments in training students, providing the opportunity for valuable cross-training between schools. It might even be possible to arrange course credit for work on the Team.

Many Open Source projects could benefit from such a 3rd party group to recommend development procedures, code styles, and actual testing to teach and motivate better security practices in code design. The plain fact is that many (most?) of us developers are not completely 'up' on the issue of security - it's a very dynamic area of specialization. This initiative could be another resource that will be useful in establishing OS in the mainstream."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

49 comments

Dollar continues to decline against the Euro (0, Offtopic)

EuroTroll (695121) | more than 10 years ago | (#6611687)

Have you noticed that the dollar hasn't been doing very well against the euro?

You might want to check out this chart [yahoo.com] and see for yourself.

Re:Dollar continues to decline against the Euro (0, Offtopic)

Captain Pedantic (531610) | more than 10 years ago | (#6613847)

Stroke of genius by Bush &co.

A devalued dollar will really help US exports and therefore the economy, but at the same time it will be the Tax cuts which take the credit. Of course, the Keynesian method of pumping Iraqi oil money into US companies will also help, but again this essentially left wing economic policy will be ignored and the right wing trickle down policy will look like it saved the day.

The icing on the cake, however, is in making USians too afraid to travel abroad, therefore they will be oblivious to the negative effect of the weak dollar.

Already have an ecosystem. (1)

GigsVT (208848) | more than 10 years ago | (#6611872)

You find a flaw in something that is not some Bob Blog v.001, and you can sell it to one of several security companies.

If money doesn't motivate you in such direct ways, you tell the authors, they fix it. You post to bugtraq, and your career gets a boost.

This is one part of open source that has viable business models. I don't think any more community effort than what is already being done (yes, people are auditing code) is going to fly.

Re:Already have an ecosystem. (0)

Anonymous Coward | more than 10 years ago | (#6611902)

Which security companies pay for notification of flaws ?

I find this immprobable. It seems very open to abuse. What if I as a coder put flaws in my package and have an agent report them to collect the money ?

Re:Already have an ecosystem. (2, Interesting)

GigsVT (208848) | more than 10 years ago | (#6612273)

Which security companies pay for notification of flaws ?

http://www.idefense.com/vcp_faq.html

I've seen a couple others, I can't recall offhand.

I volunteer (0)

Anonymous Coward | more than 10 years ago | (#6611879)

to piss off and troll OSS developers by claiming there are security holes in their products. I will emulate Brett Glass, Theo de Raadt, and that Bitkeeper guy as much as possible. I am sure you will all agree I should do the job because only a congential troll like me would like this job. Oh, and I'll also look at code once in a while.

Funding? Needed at All? (4, Insightful)

hbo (62590) | more than 10 years ago | (#6611972)

OK, so you are going to hire highly experienced and expensive talent to do security audits for open source projects that don't have a revenue model? Where's your revenue model?


And of course, the benefit of open source is that all sorts of motivated, talented people from all over the world pitch in to do a similar analysis for free, and without a formal "red team." This breaks down quite a bit with the volume of Free Software being produced nowadays, however. But the important pieces of infrastructure (Apache, e.g.) DO get the scrutiny their importance demands. Not to mention pounding by black hats.


Someone mentioned OpenBSD [openbsd.org]. But even they don't audit everything. They confine their attention to the core of the OS. That's quite a lot of software, but the ports tree is quite a bit more. The ports get somewhat more attention than they would simply because you've got a large set of security conscious users.

Re:Funding? Needed at All? (2, Insightful)

garyebickford (222422) | more than 10 years ago | (#6612759)

A couple of points on funding were made either in the original or by others - I noted that either the project as a whole or members individually might sell the service for commercial software or business clients who want the security. I also noted (this is a bit more difficult) that some universities might offer credit for participation - many open source projects are now essentially university projects, such as PHPWebSite.
The paper by _iris (92554) [slashdot.org] suggested previously that this function might be part of an insurance package. Business insurers often require IT emergency plans, risk analysis and 3rd party network security audits, and might reasonably require a company moving to open source software (read, "unknown vendor") to have the software reviewed. This is exactly where the idea of a group specializing in OS software would fit and quite possibly make money.

As for "all sorts of motivated, talented people", I think you're making my point. The "Red Team" project could provide a focus for those folks to achieve some synergy - I'm not involved in that area much but I suspect that a lot of those folks are feeling 'behind the curve' lately. It's amazing how well the community has done. A project that focusses that effort could greatly improve the availability of the 'right' information and fast access to folks who have the experience.

I do disagree with your thought that the "important pieces" get scrutinized, if you mean to say that's sufficient. The problem is that, using Apache for example, Apache itself can be bulletproof but many scripting projects using modperl, PHP, JSP, etc. are not. The result is a server that is nearly as vulnerable as if Apache itself had a vulnerability.

Apache scripting is what triggered my thought on this topic. A large number of scripting vulnerabilities have been reported lately. I can't guarantee that the scripts I've written have been bulletproof. I'd like to have a resource that, perhaps with some configuration by me, could run through a set of tests of my scripts. This couldn't guarantee anything but it could help developers.

Re:Funding? Needed at All? (1)

hbo (62590) | more than 10 years ago | (#6612946)

You suggest that the "red team" could fund itself by offering services to commerical concerns. This is, of course, just what existing companies do. But your company, (or project) would have to take on a lot of pro bono work by its definition. It's a nice idea, but probably impractical. (I'd love to be proved wrong.)


I don't disagree that Free Software could use more security auditing. That's the principle focus of OpenBSD and other projects. And I do believe that more-or-less secure components often get put together in insecure ways. I think Free Software has some edge over proprietary in this regard because of community support. But God knows, it's not enough. I'm just not convinced that you've tabled an approach that would be both effective at addressing such weaknesses and economically viable at the same time. How do you shoo the cat herd of free talent toward the goal of fixing up all the insecure web sites based on Free Software? There are way too many permutations.


The problem of auditing source code is easy by comparison. Such an approach has been shown to work well with OpenBSD. But they succeed because the tree is guarded with zeal. And they are patient. They didn't go with Bind 8 for years, until they could audit the sucker. There is a disconnect between the kind of conservative development you need to make something like OpenBSD succeed and the 6 month product cycles of the Linux vendors, not to mention the chaotic pace of this or that subproject.


I don't want to come off completely cynical about this. You've identified a real problem, and started looking at an application of the power of Free Software development models to address it. But I think you need to sharpen your focus some.

Re:Funding? Needed at All? (1)

hbo (62590) | more than 10 years ago | (#6613128)

Regarding Bind in OpenBSD. I just checked my 3.3 system, and I'm running Bind 8 from the ports tree. They still haven't let it in to the core OS!

Re:Funding? Needed at All? (1)

L.J. Hanson (936) | more than 10 years ago | (#6614580)

That's your fault. OpenBSD 3.3 installs Bind 9.

Re:Funding? Needed at All? (1)

hbo (62590) | more than 10 years ago | (#6615235)

D'oh! You are right, of course:

hbo@gate> named -v
BIND 9.2.2

I was off by one tab in konsole. 8-\

Yes. (3, Interesting)

nadador (3747) | more than 10 years ago | (#6611997)

The first phase of the open model was the developer stage - individual people contributed their talents to produce interesting software. Their products were raw and unrefined, but very powerful. All of the best practices that (supposedly) happen at commercial software houses - all of that process - was chucked out the window in favor of devoting time to the very real creative experience of molding and bending and shaping new code.

The second phase of the open model was the documentation phase. When they collected code from the net to make their products, the commerical vendors of open software took the raw, unrefined code, and harnessed its power into a form that PHBs could recognize. Now we have Ximian - a refined product that PHBs recognize, built on the creativity of GNOME developers. Now we have MontaVista and Timesys Linux kernels - products that PHBs recognize, refined to their needs, but built on the creativity of the kernel developers.

I suppose that the third stage of the open model might be to do this - to help open projects apply best practices for software creation, test, and maintenance. I just don't know who you're going to get to do it. Individual developers, I would imagine, will be more concerned with the raw creativity of hacking at code in vi. Commercial companies will more be more likely to apply these practices to the code that they ship their customers, not the code that lives in the repository at SourceForge, although maybe they coincide.

I suppose my point is that you have to find people who want to do it, or money to make people want to, and I'm not sure where you're going to find either.

"Best Practices" are context-dependent (4, Interesting)

korpiq (8532) | more than 10 years ago | (#6613516)


I suppose that the third stage of the open model might be to do this - to help open projects apply best practices for software creation, test, and maintenance.

Are you implying that open development (with its world-readable version trees, communication through archived, public message systems, bypassing monetary systems as the controlling aspect of software development, etc.) has somehow proved itself so inefficient that it should be given up in favor of whatever the closed development sector has to offer?

It's the closed commercial sector that is supposed to bend toward open methods, not vice versa. That is happening through grass-roots efforts like "stealth" installments of Linux-servers in the end of 1990's followed by "stealth" installments of Linux-workstations right now, as well as governmental and communal bodies around the world already embracing the open model as a cost- and result-effective method unbound by the insecurities of commercial offerings.

I'm sorry to sound this flamy, but your comment (as well as this whole subject, actually) reminds me of quite a few people who claim they have a grasp of the open development model, while they still look at it through a 1980's commerce school's window.

As for the security of Open offerings, mature projects' insecurity (the cumulative time window of exploits open against product's lifetime) should be compared to that of closed-development (=non-patch-accepting) offerings. From what I gather, on that basis insurance prices against IT disasters should be considerably cheaper with mature Open products.

Re:"Best Practices" are context-dependent (2)

nadador (3747) | more than 10 years ago | (#6615580)

Maybe I mispoke. I didn't mean to imply that open model will bend to the way that the closed software world works. I do agree that the commerical companies are bending to do things the open source way, and not the other way around.

But lets be realistic about whats going on.

Where I work, half of our product is the documentation that we supply to our customers detailing design, implementation, and testing. A big chunk of our time is spent going over records of integration testing and through the logs of the version control system. This totally stiffles people like me who want to go and fix the ugly, nasty code that lives in our version control system, but I know every line of code change is going to be another couple of minutes in a code review with our customer. It has been my experience, and correct me if I'm wrong, but most open source projects pride themselves on the design behind the technical aspects of their projects, not by their quality assurance.

If I understand the point of the story, the question is whether or not open projects need a devoted test and process organization, which is what we used to call our Software Engineering Process Group before the last reorg. They do black box testing, make tool suggestions, etc.

I can see how that service would be a tremendous service to an open project, but I don't know if you're going to find people who want to do QA in their free time.

Re:"Best Practices" are context-dependent (1)

korpiq (8532) | more than 10 years ago | (#6618505)

But lets be realistic about whats going on.

Absolutely. Real world is infinitely interesting.

It has been my experience, and correct me if I'm wrong, but most open source projects pride themselves on the design behind the technical aspects of their projects, not by their quality assurance.

That might well be. It might well be a contributor to quality as well, but this is getting hypothetical. In the free software world, it seems quality is being ensured more by stabile service uptime than development-documentation. More process-like, where the process is a software's life cycle from the inception of an idea to version 1.0 to being replaced by something else, including its development, deployment, use and redevelopment, rather than a "product" out of the door never to return. A service model rather than a shrink-wrapped shopping item.

I can see how that service would be a tremendous service to an open project, but I don't know if you're going to find people who want to do QA in their free time.

I know I wouldn't want to, and I know the people I know who do it for money wouldn't. But if and when someone needs it done, that someone will pay for it. Be it governmental or other bodies embracing open source, insurance companies or some Homeland Security office. It's a whole lot easier to do thorough QA after active development cycle for software with its source code available than without.

This far the code itself together with pounding throughout the world has provided a quite sufficient natural quality assurance for quite a few projects... Please just don't think "Linux kernel" here ;)

So yes, we seem to agree; traditional corporative-style QA won't be likely to happen upon free software unless that software is finding it's way to an environment that requires it, and at that stage corporate-style budget ceases to be a problem.

Maybe you should try asking the OSDL (3, Insightful)

Alpha27 (211269) | more than 10 years ago | (#6612082)

http://www.osdl.org/

I recall they are an organization sponsored by big names in the IT industry, that could possibly emplore such an idea. Their idea is to proviude enterprise class testing to help advance the linux community. I don't see why this couldn't be an extension of it.

I'm sure a nicely worded, thought out paper explaining the benefits would at least get a response, and possibly spike some interest.

Red Team Go! Red Team Go! (2, Funny)

TitaniumFox (467977) | more than 10 years ago | (#6612145)

I'd rather have an OSI Red Team that was more like Delta Force.

They could wear MIT wearables [mit.edu], have an internet uplink [natecarlson.com], and code-fu your ass into submission.

j00... (0)

Anonymous Coward | more than 10 years ago | (#6612257)

are so fuckin' fired you're re-hired.

Move on, you un-funny punk.

The Two-Edged Sword of Open Source Software (4, Interesting)

_iris (92554) | more than 10 years ago | (#6612158)

A while back I wrote a paper titled The Two-Edged Sword of Open Source Software [intercarve.net], which might be of interest.

Insurance, yes (2, Interesting)

garyebickford (222422) | more than 10 years ago | (#6612652)

Yes, one of the possible sources of revenue could be insurance-related. I would think that the way such a thing might work would be that an established carrier would want to hire the group to vette a piece of code before offering clients hacker or data loss insurance. Such insurance already exists, so this is a potential market for someone wanting to do the project. If I were an insurer I might well require 3rd party evaluation of any new software in a mission-critical or financial or other high-cost-of-risk environment.

Red leader do you copy? (0)

Anonymous Coward | more than 10 years ago | (#6612275)

Come in Red Leader, are you there?

I've got three imperial battleship ships all over me.. I can't shake them... arrrgghhh!

Process will make it better? (3, Interesting)

madmaxx (32372) | more than 10 years ago | (#6612394)

You think a process will make OSS better? The act of defining a process renders it useless, as the principles become static. Software will only get better when we do away with processes. Software is complex, it requires us to think -- not follow procedures.

I've been a part of many small and large processes, and none of them were effective. The best any of them were able to do was to soften what was produced by the morons. In lessening the effect of retarded developers, the processes become a hindering block to those who know wtf they are doing. Process is so fun.

Software development needs to be organic. OSS needs more mentors, gurus of the deep, dark, unknown to become one with the new blood. It is about community, and about collaboration - the real sort of kinship where people build things together. Process is about as un-personal as it gets.

Re:Process will make it better? (2, Interesting)

garyebickford (222422) | more than 10 years ago | (#6612828)

I don't mean to suggest that some Cathedral be built. My first engineering job was as a Software QA Engineer - the most hated title in the company. Projects were almost always late and over budget before we got them, and when we rejected them yet again with another 200 'blue sheets', managers' blood ran cold.

I see this as just another project that is itself a resource to projects that want to make use of it, just as GTKlib is available as a resource.

Lest you go off the deep end waxing poetical in the dark (sorry... :O) What I'm proposing is a focal point for the mentoring you're talking about. It's an Open Source version of the Red Team concept.

Re:Process will make it better? (2, Interesting)

ComputerSlicer23 (516509) | more than 10 years ago | (#6613179)

That's a really nice thought, but Engineering is all about process. There should be a process, and guidelines, and a list of things that happen for code to be "good to ship". OSS does this informally, by the users using it, essentially out of appriciate for the scratching of the itch.

One of the more complicated things we ever did, involved sending a guy to the moon. That involved lots of Engineering. That's the closest thing I can think of to writing new software. First, they didn't have the tools to make the stuff they needed. They had to make tools, to make the final products they needed. Then they did testing, documentation, procedures, failure cases, procedures for handling all of the failure cases. Then they did training. Then they did more training.

They had to create materials, and process, and solve invent whole new areas of Engineering to do that. They had all kinds of problems they overcame, by letting the Engineer's imagination run rampant, and then having it, checked, re-checked, and double checked. They did it, by having redundant checks, and redundant design teams. They had fail-over systems in triplicate. They tested literally everything they could. When something failed, they investigated way, and change the procedure to mitgate the probability of that happening again.

It'd be wonderful to see some process be implemented. Right now, to get code into say the stock kernel, there is a process. You convince Linus it's good enough. You can do that a myriad of ways. If it's small you just send it to him. If it's larger, you send it to a large list of people who peer review it. You send it to a maintainer of a popular tree. They let is sit in their tree for a while. Nobody reports a bug, some people report success. Whoopie, it'll probably end up in a source tree. It's very, much a process. It's just not a process a single company can execute. They can't have the internal talent lying around to do it.

There are a lot of projects that have little to no internal review. They have only a handful of developers examining the code. Some of whom might not be the greatest coders in the world.

The reason Apache, Linux, FreeBSD, and other large projects are successful, is because they have an over abundance of people who care, who are extremely talented. They also tell people who are crappy who try and contribute to go fly a kite, until they can get up to snuff. It'd be nice to see a group of people, who care, precisely because they are paid to care. Right now, a lot of those people are paid by Linux distributors, or other distributers of OSS.

Personally, I'd rather see an open source static source checker developed so auditing could be streamlined and automated. You run the checker against your code, it analyses all of the possible cases, and emits warnings. You have a way to notated the code (preferrably, out of band of the source code) to say, I've checked this one, don't warn me any more. Have all that integrated with a SCM tool, that will identify when you have changed a section that has previously been human approved, and nullify the approval. So you reduce a lot of the grunt work of doing an audit.

Something even more sophisticated for the Linux kernel, that says, function call foo, can only be called if lock bar is held. Then having a compiler check to see if there might be a problem. Have rules about function bar can't call anything that can sleep. Then have a the tool check it. So for each project you can establish a ruleset, and enforce the rules in a relatively automated way. This function can't be called from interrupt context, and build the call tree to see if it ever can be called. I believe smatch is the beginnings of such a project.

I guess in the end, the gurus, execute their own personal process, and if you have really great guru's the project works. If you have guru's whose process sucks, it's a failed OSS project. The reason you don't see big catastrophic failures in OSS, is they die while they are young. All successful OSS projects have a process, they just aren't something you write down on a list of paper in 10 minutes. They are something you gain over a lifetime of experince. About the closest I have seen is Mozilla, which bootstrapped itself out of it's failure by essentially starting over, with only the best people, thru a big pile of hardwork and plenty of elbow grease.

Kirby

Re:Process will make it better? (1)

sql*kitten (1359) | more than 10 years ago | (#6613988)

Software will only get better when we do away with processes. Software is complex, it requires us to think -- not follow procedures.

I'm guessing you have little or no real-world experience. Consider artifacts from other technical disciplines: airliners, nuclear power stations, skyscrapers, etc. Very few software projects in the world are even within an order of magnitude of the complexity of one of those. Yet all those things require a great deal of process to get right, and the proof, as they say, is in the pudding - they are all very reliable. Whereas software, much simpler, is renowned for being unreliable. And you think software needs less process??

Re:Process will make it better? (0)

Anonymous Coward | more than 10 years ago | (#6615715)

Consider artifacts from other technical disciplines: airliners, nuclear power stations, skyscrapers, etc. Very few software projects in the world are even within an order of magnitude of the complexity of one of those.
No: most software projects are far more complex than one of those, and have the additional disadvantage of never having been done before.

Re:Process will make it better? (1)

sql*kitten (1359) | more than 10 years ago | (#6615907)

No: most software projects are far more complex than one of those, and have the additional disadvantage of never having been done before.

I don't believe that is the case. Nearly all applications written are about retrieving data from some form of database, displaying it in some way, optionally allowing the user to edit it, optionally performing some calculation and writing it back to some form of database. Yet still, software projects frequently end in disaster.

Also, look at the people involved. Professional engineers with decades of experience work on airliners and skyscrapers, whereas any kid who hasn't even completed college can write large amounts of code. That indicates that writing code is considerably easier than real engineering.

Re:Process will make it better? (0)

Anonymous Coward | more than 10 years ago | (#6617487)

No.

It indicates that the barriers to entry are lower for writing code than for building skyscrapers.

After all, anyone with a computer and toolchain can build the next killer app, with very few resources.

However, how many 747's and Sears Towers come out from someone's basement?

Yes there is, it is called OpenBSD (1)

MerlynEmrys67 (583469) | more than 10 years ago | (#6612466)

Oh yeah, BSD is dead isn't... But Theo has been providing this service for years...

Thank you Theo, you are great

what's the deal with you homosexual fanatics?!?! (-1, Troll)

Anonymous Coward | more than 10 years ago | (#6612489)

I don't want to start a holy war here, but what is the deal with you homosexuals? I've been sitting here in this bathroom stall with a turd-burglar (a leather wearing pansy) sucking my dick for 20 minutes now. 20 minutes! At home, with my girlfriend, who by all standards should have less experience eating a meat popsicle, the same orgasm would take about 2 minutes. If that.

In addition, during this oral sex attempt, he fingers my asshole. And everything else has ground to a halt. Even trying to fart fails.

I won't bore you with the laundry list of other problems that I've encountered while dealing with other fairies, but suffice it to say there have been many, not the least of which is I've never seen a shemale that looks as god in a dress as it's woman counterpart. My girlfriend on the rag has a more appealing vagina. Thie guy just has a cock that he probably wants sucked off. From a pleasure department, I don't know how people can claim that gay sex is superior.

Slashdot editors and other pillow-biters, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to shove their cock up some guy's asshole than crease the sheets with a fine-looking lady.

It's [sort of] been done. (1)

innosent (618233) | more than 10 years ago | (#6612545)

It's called Academia.

But seriously, folks, companies like Rational [rational.com] (now part of IBM) do this sort of thing. They sell products based on their ideas, but the end result of their efforts is software process techniques and tools. They've had some of the best minds in Computer Science working for them, people who have produced UML, the Unified Process, and many more while working at Rational.

OSS doesn't need a "Red Team" (1)

photon317 (208409) | more than 10 years ago | (#6612782)


Open Source projects have all the benefits of that sort of analysis built into the process already. Since the source is out there for anyone to analyze any way they see fit (source analysis, or external analysis of compiled binaries or running software), if the package has any interest from legitimate users, it tends to have interest from both white and black hack security analysis.

Generally the greater the end-user interest, the great the security analysis interest. The black hats of course follow that trend because the most widely-deployed packages are the ones for which holes are most useful. The white hats do it because finding and fixing problems in a package with a wider audience nets a wider recognition of their talents, and they seem to thrive on recognition. The only real difference is that the white hats tend to tell the develop first and/or offer a patch simultaneous to public disclosure, while the black hats tend to exploit it in private for a bit and share with their groupies until revelation is virtually inevitable, and then rush to publish before any of their peers do (again, for recognition).

Of course the same model applies to closed projects, but the difference is that only external analysis can be done, unless you're a paid Red Team with access to the proprietary source. Therefore it's arguable that OSS is the winner here with a wide array of disparate Red Teams working for us, whereas the proprietary software company has to pay a single or small hundful of them and hope that those select individuals can equal the analytical power we have in our masses.

Re:OSS doesn't need a "Red Team" (1)

Anonymous Conrad (600139) | more than 10 years ago | (#6613826)

OK, but you're saying "Apache 1.2.3 is probably secure because it's been out there for some time". That's pretty vague.

I think the guy's proposing "Apache 1.2.3 has passed a thorough security audit by a reputable group". That'll weigh heavier with PHBs.

So we need a reputable group that's willing to audit and publish for free. OSS either needs to raise money to pay people to do this or to organise their own group and get it a good reputation. I think he's suggesting that the latter.

Re:OSS doesn't need a "Red Team" (1)

photon317 (208409) | more than 10 years ago | (#6638272)


In real, actual, factual terms, saying that the most current release of Apache is secure because of all the reasons I outlined above carries far more real weight than any certification company can provide.

However, you are on the nose that a PHB would rather see an audit from an individual company. I guess it comes down to whether you want to bow down to the man and do what your PHB says regardless of how braindead it is, or you're willing to stand up to your PHB and educate them on the science and reality of computing.

What do you mean? (0)

Anonymous Coward | more than 10 years ago | (#6612997)

Commies like Richard Stallman aren't Red enough for you?

"Community"? (4, Interesting)

fuzzybunny (112938) | more than 10 years ago | (#6613001)


Nice idea. However, it fails on one problem: there is no "Open Source Community". Or rather, there is, but it's not the sort of homogenous, integrated entity/organization that gives managers and powerpoint jockeys warm fuzzy feelings.

Rather, it's a bunch of dudes knocking out code. And for the same reason you're not going to get most of them to provide adequate documentation, which is thoroughly understandable given that (a) they're doing something for fun, and (b) they're not getting paid for it, you're not going to get these people to submit to procedures and processes, on the whole. Hobbyists will continue to build stuff on a lark, doing it the way they feel like doing it.

Now if you want to provide something like this as a service for companies hoping to use OSS, great. However, someone would have to pay for it, which takes away one of the big pluses of OSS. In fact, that's one of the reasons your average commercial entity goes for proprietary software--it's the management perception that there is an organized set of procedures and such behind its development (usually true to some degree) as well as an organization they can sue if things go pear-shaped.

Nice idea, but needs practical development.

other ways... (2, Interesting)

kevin lyda (4803) | more than 10 years ago | (#6613441)

red team sounds like something a closed package would need. linux and other free software offer additional options for testing. openbsd does a continuous code audit. linux has the kernel janitors [sourceforge.net]. in addition there are numerous citations for fuzz - here's one [nec.com].

i get the idea you want a company to do all this work and then place a certification on distros or packages. you confuse the issue with the buzzword scented "red team" references, but it really sounds like you want to use the services of such a company - or create one and create buzz for such a company.

This already exists (3, Funny)

Tuross (18533) | more than 10 years ago | (#6613505)

Folks... it's called "bugtraq" and it's been around for decades.

Anyone else amused by the irony that someone is advocating open source software should start practising the things closed source development is now getting buzzword compliant with, which is made popular in that arena because its already such a success with open source software? ;)

But look at the competition (1)

0x0d0a (568518) | more than 10 years ago | (#6613520)

The next time Linux is suffering from an RPC bug that allows remote root over amost all existing installations, then I'll agree that OSS desperately needs a review time.

Until that time, OSS is kicking the shit out of commercial software WRT security. I say just let it continue doing so.

Sardonix? (2, Interesting)

packetknife (536137) | more than 10 years ago | (#6613542)

Not exactly what you are discussing but there was a lot of hoopla around Sardonix [sardonix.org] many months back and it doesn't appear WireX has done anything real with it yet. I'm on the mailing list and it sounds of crickets.

Another thing to remember is that there are decent references out there, some quite well known, that people could follow and use but simply don't (Viega's book, and number of HOWTOs, etc.).

In anycase, you might want to approach WireX and see what, if anything, can be done to resurrect Sardonix. Cheers, -Pk

that would be cool... (1)

Munk (59689) | more than 10 years ago | (#6614245)

...because the blue team would fight the red team for total domination. But can we fight over something cooler than blood gulch [redvsblue.com]? I just hope that Church wouldn't have to die this time.

Red Shirts (3, Funny)

Jack Comics (631233) | more than 10 years ago | (#6616023)

... Sure, so long as they don't join Starfleet.

Captain Kirk, Mr. Spock, and the Red Team beam down to an alien planet -

Kirk - "Rodriguez, check to see what's causing that buzzing sound coming from the rock nearby."

Rodriguez (Red Team) - "Bleep you! Go check it out yourself! We've lost three Red Team members this past week that beamed down to strange worlds with you!"

very last post, i suck (1)

muirhead (698086) | more than 10 years ago | (#6722464)

Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], very grumpy!

very last post (1)

Ruby+last+post (699442) | more than 10 years ago | (#6731111)

Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], very grumpy!
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...