Summertime is the season for traveling circuses and local fairs, so I shouldn't be surprised that this carnival atmosphere has spread to security. A company named Permanent Privacy just announced a $1 million prize to the person who can crack its algorithm and uncover the underlying encryption keys.
Now I realize there is some history here. In January 1999, a group of academics cracked the 56-bit Data Encryption Standard in just over 22 hours and won a prize of $10,000. That said, I am not a big fan of security showmanship like this from unknown security start-ups.
Why? First of all, this "challenge" isn't really a challenge at all. Permanent Privacy technology is based upon the AES (Advanced Encryption Standard) algorithm and since no one has cracked AES, it's highly unlikely that anyone will crack AES with an additional proprietary security wrapper . Furthermore, information security is no longer an academic playground for brainiacs at Berkeley and MIT. Rather, it's serious business that impacts everything we do. Given this level of criticality, I'd rather see things like Common Criteria or FIPS certification than a publicity gimmick.
As a start-up, I understand that Permanent Privacy needs to generate buzz and all PR is good PR. Heck, I did the same thing as VP of marketing at a misguided CLEC during the boom. Security isn't like other technologies however, it's more about law, order, and safety. Oracle was dragged through the mud when it advertised its database as "unbreakable." Perhaps it's just me, but I think Permanent Privacy deserves a similar treatment in the market.
As the Slashdot commentary suggests, new research that finds open-source code quality to be no better than that of proprietary software has its flaws. "Code quality" is difficult to measure. Finding metrics to analyze the successes and failings of four operating systems--FreeBSD, GNU/Linux, Solaris, and Windows--is especially difficult.
So, while Coverity recently found open-source software quality to be quite high and continuously improving, I suspect there's some truth to the conclusion of the research:
Across various areas and many different metrics, four systems developed using wildly different processes score comparably. At the very least, the results indicate that the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.
... Read more
Borland Software has sold its CodeGear development tools division to Embarcadero Technologies for about $23 million, the companies said Wednesday.
CodeGear sells the products that Borland used to be best known for--its JBuilder Java development tool, Delphi, and C++Builder. More recently, CodeGear has created development tools for PHP and Ruby.
Borland Software CEO Tod Nielsen
Two years ago, Borland CEO Tod Nielsen announced a plan to sell off the tools division separate from its application lifecycle management product line. The tools division has been hurt from competition from free, open-source products, notably the Eclipse IDE.
CodeGear products are aimed at individual programmers, while the lifecycle management suite is designed for teams of developers, testers, and architects.
Since then, Borland hadn't been able to find a buyer.
Embarcadero brings in more than $60 million in annual revenue selling database management and design tools. The acquisition gives it access to the millions of developers that use CodeGear software, it said.
Update 7:50 AM Pacific: corrected figure for Embarcadero's annual revenue before its planned acquisition of CodeGear.
This week, the PCI Security Standards Council announced the availability of its new Payment Application Data Security Standard (PA-DSS). PA-DSS provides a set of best practices to software vendors for developing secure payment applications that don't store sensitive or private data such as personal identification numbers, and ensure that these applications support standard Payment Card Industry Data Security Standard (PCI DSS) requirements. Once a certification process is established, retailers will be able to purchase applications with a PA-DSS "good housekeeping" seal of approval.
Hmm, what a good idea. Retail companies get the benefit of a third-party audit of their software vendor's code and get to make their selections based on whether a vendor meets the PA-DSS standard. It's great for the retail and financial services industries mandated by PCI, but what about the rest of us poor schmoes? Shouldn't we get the same kind of protection?
Well, maybe we should but it ain't gonna happen anytime soon. My suggestion to CIOs in other industries is caveat emptor. IT executives shouldn't buy any software from any vendor without some type of review of the company's software development process, security testing, and emergency response procedures. What's more, purchasing agreements should hold software vendors' feet to the fire to address security process gaps, fix vulnerabilities within a reasonable time frame, and respond to emergency situations with an appropriate level of urgency. No commitment, no purchase.
Software vendors have always focused their attention on functionality, eschewing security in many cases. For the PCI Security Standards Council, this lack of secure development oversight led to regulations in the form of the PA-DSS. Yes, companies like EMC, Microsoft, and Oracle have embraced secure software development methodologies but we are still buying a lot of vulnerable code from a plethora of vendors.
Since the rest of us don't have the PCI Security Standards Council to protect us, I strongly suggest more vigilant purchasing policies. Most vendors won't improve software security until they realize that this omission will go straight to the top and bottom line.
Jon Oltsik is a senior analyst at the Enterprise Strategy Group.
Whether your pilgrimage tour makes it to Bethlehem or ends up as Mediterranean fish bait may all depend on a credit-card-size keypad designed to prevent hijacked airliners from entering Israeli airspace.
Starting next year, Israel will require all airlines flying into its airports to use a new Security Code System device designed to prevent a 9/11-style attack by identifying commandeered planes before they enter the country's airspace, Reuters reported last week.
Elbit Systems, the company that developed the device, declined to go into technological and procedural detail. But judging by the keypad, it's possible that the pilot would be required to enter a numerical code. There is also something that looks like a microphone suggesting voice recognition, according to a Reuters reporter allowed in for a peek at Israel's Transport Ministry.
Whatever the test, pilots who flunk it or send a secret Mayday will be ordered to turn back. If they ignore the warning, they and everyone on board become fair game, which means-worst-case scenario-you and aunt Edna get splashed.
You can relax on at least one count. "You can't bluff this system," the Transportation Ministry's security chief told Reuters. "It provides a higher level of confidence that the aircraft is being controlled by the right people, which are a huge asset in terms of avoiding unnecessary security alerts."
He added the system knows the difference between a "classic hostage-taking hijacking and a 9/11-style hijacking."
So there's still a chance you'll deplane in one piece.
Of the companies I saw yesterday at the Under the Radar: Mobility conference (more stories), the most audacious, and therefore my favorite, was Zoove. This company makes a service and a technology that allows mobile phone users to dial a short code (preceded by **) and then receive information via SMS or e-mail.
Sounds like SMS short codes, right? But there's a big difference: to get data from the Zoove service, you dial your phone. That is you press a code, like "**coke," then the Talk key. It's just like making a call. Except that instead of talking to a person, you get sent the information you're requesting.
Sending a short code is a lot more involved: you have to go to your messaging window, address the message (the short code), and then, most likely, enter a message keyword. Only then can you send off your message. Zoove "StarStar" codes take no training and are faster to use. They'll work better on billboards.
Zoove has data showing how much more likely users are to complete the task of sending a StartStar code than competing a short code SMS message, and how much more satisfying the experience is. It is, undoubtedly, a better way to request information by mobile phone. But the beauty of the business is Zoove's lock on the technology. Getting Zoove implemented requires making deals with carriers, and according to CEO Tim Jemison, implementation by a carrier is not trivial. This is a good thing, since it's a barrier to competitors. Also, for patent and for technological reasons having to do with the way big phone switches work, Jemison says that once Zoove is installed by a carrier, it is even more difficult for it to adopt a competing short-dial-code provider in parallel.
So the first audacious part of this business is that it only really works when all (or nearly all) of the carriers in a market support the technology. Zoove doesn't have that part of its message locked up just yet. Currently, Zoove is running on Sprint, and talks are underway with AT&T and Verizon Communications, Jemison said. Without these (and other) carriers, selling StarStar codes will be tough. And ultimately, that's the business.
The other big part of the Zoove vision is that Zoove controls the StarStar "namespace." If GM wants to license **Vette, for example, only Zoove can enable it. That puts a lot of power in Zoove's hands, and it takes guts to sell a product through carriers that represents a revenue stream that they don't necessarily benefit from and could turn off in a heartbeat, leaving Zoove with no air to breathe.
Zoove is a big vision, and that's why I like it. Delivering on the vision will be very difficult, though, and that just makes it more interesting.
Minnesota authorities have missed a court-imposed deadline for turning over the source code for a breath-testing machine at the heart of a a high-profile dispute that recently made it to the state's Supreme Court.
That means now there's a greater chance that charges could be dropped against third-degree DUI defendant Dale Lee Underdahl.
The Intoxilyzer 5000EN is used in more than 20 states, according to the manufacturer.
(Credit: Connecticut Department of Public Safety)The next step is a court hearing scheduled for September 19, Underdahl's attorney, Jeffrey Sheridan, told CNET News.com in a phone interview on Tuesday. At the hearing, Sheridan is expected to ask the judge to throw out any evidence the state had obtained using the the Intoxilyzer 5000EN. If the judge agrees, at least one charge--that his client was driving with a blood alcohol concentration above the legal limit of .08--would likely be dismissed.
Sheridan had predicted in an interview with CNET News.com last month that the Minnesota state public safety commissioner would not supply him with the source code to the device, as ordered by the Minnesota Supreme Court, by the August 17 deadline.
Minnesota Department of Public Safety representatives declined to comment on the case on Tuesday, citing a policy not to comment on pending litigation. Sheridan said the government has made no legal filings explaining why it didn't comply with the deadline.
The state has previously argued it's not entitled to the code because of its confidential, copyrighted and proprietary nature. But the Minnesota Supreme Court in late July concluded that language in the contract between the device's manufacturer, Kentucky-based CMI, and the state indicates the source code belongs by extension to Minnesota. The justices suggested the state must do whatever it takes to enforce that contract, even if it means, for example, suing CMI.
CMI, which bills itself as a leading maker of alcohol-testing equipment, says law enforcement agencies in 40 states and in Canada use its products. Its resistance to giving up its code, however, has already led to charges being thrown out or blunted in recent cases in other states.
CMI representatives did not respond immediately to requests for comment.
Wow. Double wow. I haven't seen Steven J. Vaughan-Nichols this worked up since, well, ever. He could almost be writing for The Register with the way he smacks around Microsoft for its top-25 (most active, mind you) open-source projects on CodePlex. It makes for very fun reading.
It doesn't, however, accurately portray the projects--there are some that actually sound useful and interesting--but I don't want a little (just a little, mind you) accuracy get in the way of a good ol' cage match between Microsoft and SJVN.
My favorite (and probably most apt) comment:
... Read moreOn Monday, AMD released a proposal for "Lightweight Profiling" instructions (or LWP; download here), describing a new way for software developers to gather information on software while it runs.
I've only had a few minutes to check out the document, but it looks pretty interesting. Existing performance analysis tools, like Intel's VTune and AMD's CodeAnalyst, generally create significant overhead when gathering performance information. They usually need code that runs in supervisor mode, for example, and they're just for developer use--they aren't meant to be used in production systems.
LWP lets applications gather their own performance data in real time with new user-mode instructions. This should make it possible for applications to adapt their execution behavior to maximize performance from moment to moment even while other software is running.
I'll have to wait to see what software developers say about this proposal, but I suspect it'll be well received by the developer community. We'll also have to see if Intel accepts the proposal as-is, rejects it outright, or suggests some kind of alternative.
AMD scored big points by defining a practical 64-bit x86 instruction set before Intel could, which shut down Intel's parallel effort before it was ever announced. (Rumors persist that the "Prescott" version of Intel's Pentium 4 was initially designed with Intel-proprietary 64-bit extensions that gave way to an AMD64-compatible implementation later.)
LWP is a small thing by comparison, but AMD could regain a bit of that AMD64 luster if this proposal is accepted.
- prev
- 1
- next
