The actual article are very different from the obvious slant that exists in the posting summary. It's also unclear whether the original poster actually read Sage or simply relied on comments from the Robert McMillan article in PC Advisor. Either way, I've read both and McAfee doesn't seem to be targeting open source in any way that's unfair or incorrect (read for yourself):
"Paying a price for the open-source advantage" is not the cover story, but rather the cover text describing the subject matter for Vol 1 Issue 1 of Sage. Here are the contents:
- Security Trends and Events of the Last Six Months [Technical Article] - Good Intentions Gone Awry [Feature Article] - Money Changes Everything [Feature Article] - Open-Source Software in Windows Rootkits [Technical Article] - Building Better Bots [Feature Article] - Is Open Source Really So Open? [Opinion / Editorial] - Vulnerability Bounties [Opinion / Editorial] - Will the Worm Eat the Apple? [Technical Article]
In this Issue:
The Open Sourcing of Threats
Open source is an important and powerful force in today's networked world. From basic tools and utilities to applications and operating systems to the foundation of the Internet itself, opensource products have created tremendous value.
The fundamental tenets of the movement are quite simple:
"When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. This rapid evolutionary process produces better software than the traditional closed model at a speed that, if one is used to the slow pace of conventional software development, seems astonishing." 1
Belief in the open source philosophy approaches an almost religious zeal in its most ardent proponents. However, like any powerful tool, open source can also be used for malicious purposes, particularly in security. Whether posting a terrorist training manual or a how-to guide for attacking infrastructure, there are consequences to the free and open sharing of information--especially in the realm of computer and network security, where the desirable degree of openness in the sharing of vulnerability and threat information and the role of open source in the production of malware are significant points of contention.
As Dmitry Gryaznov explains in "Good Intentions Gone Awry," malware authors have been collaborating and sharing source code, using books and bulletin board systems and, eventually, ftp sites and the Web, since soon after the first computer viruses appeared in the late 1980s. Gryaznov also quantifies the significant impact that such sharing has had on the production and proliferation of malware.
Igor Muttik continues the narrative in "Money Changes Everything," in which he presents ample evidence of a vibrant and sophisticated open-source community actively engaged in the development and dissemination of both new and repackaged malware. The bundling of threats and the use of obfuscating tools (to thwart security scanners) offer clear evidence that modern malware is the product of collaborative efforts.
The advent of bot herders and their botnets, however, signals a change in the character of and intent of malware. Though malware authors started sharing and collaborating 20 years ago, the degree of process maturity and quality of code in those early threats was never comparable to that of commercial software products. As a result, most malware was, by comparison, poorly written, prone to failure, and ultimately ineffective. Michael Davis' "Building Better Bots" confirms that this situation has changed. Bot malware is now developed with the same methodologies and tools used to produce marquee open-source products such as Firefox, Apache, and MySQL. Driving this charge toward professional quality code are the fi nancial rewards that a large botnet can earn for its master, whether from sending spam, injecting adware, participating in a Distributed Denial of Service (DDoS) attack, or performing some
It does, but the results aren't always what I would like to see. When I saw how they were handling addresses I though to myself that this was an interesting way to deal with the problem but that I could improve upon the implementation.
I work with Microsoft Axapta (http://www.microsoft.com/BusinessSolutions/Axapta/default.aspx) and the product has a bit more than just the standard address fields (although the approach could probably be expanded upon.
One table keeps track of countries (3-Digit/2-Digit/2-Character ISO 3166 code, country name) along with a code for address format. I tend to set up a 1 address format per country even if multiple countries use the same format.
The address format is displayed as a series of rows in a grid and lets you build an ordered list of fields that make up the address. Here are the choices:
Address
Postal (Zip) Code
City
County
State
Country
Street Name
Once you've selected you can select a separator and a newline (flag). Here's the format for a US address:
What I like about this setup is that the data model is consistent. What I don't expecially like but can live with is that you need a supporting code routine to read/write addresses - you can't just grab them from the table and expect them to look perfect.
From the UI, the application lets you enter the first two lines of the address then tab to the zip field and enter a postal code. There's a supporting postal code that has the city/state/county/country info that will populate the rest of the fields (so it's less typing) along with a textarea that displays the entire address as it will print.
Yes - the Axapta scrollbars do not show the relative position within the grid - they're relative to the number of pages/records that have been fetched into the thin client. I've often wished that Axapta could pre-determine how many records are in the table as a total and then set up the scroll bar so that it works in a more 'familiar' way. However, it's important to understand that you're dealing with a 3-tier client and the client is only fetching the records as you ask for them.
OTOH, I would think that it makes more sense to use the excellent search functionality to go to the record(s) you want - Axapta let's you do wildcard searches on almost every field in every database.
Slashdot Mirror
The actual article are very different from the obvious slant that exists in the posting summary. It's also unclear whether the original poster actually read Sage or simply relied on comments from the Robert McMillan article in PC Advisor. Either way, I've read both and McAfee doesn't seem to be targeting open source in any way that's unfair or incorrect (read for yourself):
"Paying a price for the open-source advantage" is not the cover story, but rather the cover text describing the subject matter for Vol 1 Issue 1 of Sage. Here are the contents:
- Security Trends and Events of the Last Six Months [Technical Article]
- Good Intentions Gone Awry [Feature Article]
- Money Changes Everything [Feature Article]
- Open-Source Software in Windows Rootkits [Technical Article]
- Building Better Bots [Feature Article]
- Is Open Source Really So Open? [Opinion / Editorial]
- Vulnerability Bounties [Opinion / Editorial]
- Will the Worm Eat the Apple? [Technical Article]
In this Issue:
The Open Sourcing of Threats
Open source is an important and powerful force in today's networked world. From basic tools
and utilities to applications and operating systems to the foundation of the Internet itself, opensource
products have created tremendous value.
The fundamental tenets of the movement are quite simple:
"When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. This rapid evolutionary process produces better software than the traditional
closed model at a speed that, if one is used to the slow pace of conventional software development, seems astonishing." 1
Belief in the open source philosophy approaches an almost religious zeal in its most ardent proponents. However, like any powerful tool, open source can also be used for malicious purposes, particularly in security. Whether posting a terrorist training manual or a how-to guide for attacking infrastructure, there are consequences to the free and open sharing of information--especially in the realm of computer and network security, where the desirable degree of openness in the sharing of vulnerability and threat information and the role of open source in the production of
malware are significant points of contention.
As Dmitry Gryaznov explains in "Good Intentions Gone Awry," malware authors have been collaborating and sharing source code, using books and bulletin board systems and, eventually, ftp sites and the Web, since soon after the first computer viruses appeared in the late 1980s. Gryaznov also quantifies the significant impact that such sharing has had on the production and proliferation of malware.
Igor Muttik continues the narrative in "Money Changes Everything," in which he presents ample evidence of a vibrant and sophisticated open-source community actively engaged in the development and dissemination of both new and repackaged malware. The bundling of threats and the use of obfuscating tools (to thwart security scanners) offer clear evidence that modern malware is the product of
collaborative efforts.
The advent of bot herders and their botnets, however, signals a change in the character of and intent of malware. Though malware authors started sharing and collaborating 20 years ago, the degree of process maturity and quality of code in those early threats was never comparable to that of commercial software products. As a result, most malware was, by comparison, poorly written, prone to failure, and ultimately ineffective. Michael Davis' "Building Better Bots" confirms that this situation has changed. Bot malware is now developed with the same methodologies and tools used
to produce marquee open-source products such as Firefox, Apache, and MySQL. Driving this charge toward professional quality code are the fi nancial rewards that a large botnet can
earn for its master, whether from sending spam, injecting adware, participating in a Distributed Denial of Service (DDoS) attack, or performing some
It does, but the results aren't always what I would like to see. When I saw how they were handling addresses I though to myself that this was an interesting way to deal with the problem but that I could improve upon the implementation.
One table keeps track of countries (3-Digit/2-Digit/2-Character ISO 3166 code, country name) along with a code for address format. I tend to set up a 1 address format per country even if multiple countries use the same format.
The address format is displayed as a series of rows in a grid and lets you build an ordered list of fields that make up the address. Here are the choices:
Address
Postal (Zip) Code
City
County
State
Country
Street Name
Once you've selected you can select a separator and a newline (flag). Here's the format for a US address:
Address[Newline=Y]
City[Newline=N][Separator=", "]
State[Newline=N][Separator=" "]
Zip[ ][NewLine=Y]
Country[NewLine=N]
What I like about this setup is that the data model is consistent. What I don't expecially like but can live with is that you need a supporting code routine to read/write addresses - you can't just grab them from the table and expect them to look perfect.
From the UI, the application lets you enter the first two lines of the address then tab to the zip field and enter a postal code. There's a supporting postal code that has the city/state/county/country info that will populate the rest of the fields (so it's less typing) along with a textarea that displays the entire address as it will print.
OTOH, I would think that it makes more sense to use the excellent search functionality to go to the record(s) you want - Axapta let's you do wildcard searches on almost every field in every database.