Slashdot Mirror
Does Open Source Need a Red Team?
"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."
You might want to check out this chart and see for yourself.
Hmmm....OpenBSD, anyone?
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.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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.
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. 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.
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
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.
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
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.
I'd rather have an OSI Red Team that was more like Delta Force.
They could wear MIT wearables, have an internet uplink, and code-fu your ass into submission.
-- I'd say your post was about 3 monkeys, 18 minutes.
A while back I wrote a paper titled The Two-Edged Sword of Open Source Software, which might be of interest.
"Flyin' in just a sweet place,
Never been known to fail..."
are so fuckin' fired you're re-hired.
Move on, you un-funny punk.
Come in Red Leader, are you there?
I've got three imperial battleship ships all over me.. I can't shake them... arrrgghhh!
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.
mx
Thank you Theo, you are great
I have mod points and I am not afraid to use them
(It's a voice over in the backgound)
sorry, had to...
It's called Academia.
But seriously, folks, companies like Rational (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.
--That's the point of being root, you can do anything you want, even if it's stupid.
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.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
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.
11*43+456^2
Commies like Richard Stallman aren't Red enough for you?
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.
Cole's Law: Thinly sliced cabbage
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. in addition there are numerous citations for fuzz - here's one.
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.
US Citizen living abroad? Register to vote!
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?
Matt
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.
I think, therefore thoughts exist. Ego is just an impression.
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.
May we never see th
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
...because the blue team would fight the red team for total domination. But can we fight over something cooler than blood gulch? I just hope that Church wouldn't have to die this time.
... 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!"
"We are all in the gutter, but some of us are looking at the stars." - Oscar Wilde
Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins,
Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins,
Ruby Sleeps