, , , ,

Beyond the fatal Tesla crash: Security and connected autonomous cars

Kitt-InteriorWas it a software failure? The recent fatal crash of a Tesla in Autopilot mode is worrisome, but it’s too soon to blame Tesla’s software. According to Tesla on June 30, here’s what happened:

What we know is that the vehicle was on a divided highway with Autopilot engaged when a tractor trailer drove across the highway perpendicular to the Model S. Neither Autopilot nor the driver noticed the white side of the tractor trailer against a brightly lit sky, so the brake was not applied. The high ride height of the trailer combined with its positioning across the road and the extremely rare circumstances of the impact caused the Model S to pass under the trailer, with the bottom of the trailer impacting the windshield of the Model S. Had the Model S impacted the front or rear of the trailer, even at high speed, its advanced crash safety system would likely have prevented serious injury as it has in numerous other similar incidents.

We shall have to await the results of the NHTSA investigation to learn more. Even if it does prove to be a software failure, at least the software can be improved to try to avoid similar incidents in the future.

By coincidence, a story that I wrote about the security issues related to advanced vehicles, “Connected and Autonomous Cars Are Wonderful and a Safety-Critical Security Nightmare,” was published today, July 1, on CIO Story. The piece was written several weeks ago, and said,

The good news is that government and industry standards are attempting to address the security issues with connected cars. The bad new is that those standards don’t address security directly; rather, they merely prescribe good software-development practices that should result in secure code. That’s not enough, because those processes don’t address security-related flaws in the design of vehicle systems. Worse, those standards are a hodge-podge of different regulations in different countries, and they don’t address the complexity of autonomous, self-driving vehicles.

Today, commercially available autonomous vehicles can parallel park by themselves. Tomorrow, they may be able to drive completely hands-free on highways, or drive themselves to parking lots without any human on board. The security issues, the hackability issues, are incredibly frightening. Meanwhile, companies as diverse as BMW, General Motors, Google, Mercedes, Tesla and Uber are investing billions of dollars into autonomous, self-driving car technologies.

Please read the whole story here.

, , , ,

Quantify the risk of automotive software failures: The SRR Warranty and Recall Report

Summary of Recall Trends. Source: SRR.

Summary of Recall Trends. Source: SRR.

The costs of an automobile recall can be immense for an OEM automobile or light truck manufacturer – and potentially ruinous for a member of the industry’s supply chain. Think about the ongoing Takata airbag scandal, which Bloomberg says could cost US$24 billion. General Motors’ ignition locks recall may have reached $4.1 billion. In 2001, the exploding Firestone tires on the Ford Explorer cost $3 billion to recall. The list goes on and on. That’s all about hardware problems. What about bits and bytes?

Until now, it’s been difficult to quantify the impact of software defects on the automotive industry. Thanks to a new analysis from SRR called “Industry Insights for the Road Ahead: Automotive Warranty and Recall Report 2016,” we have a good handle on this elusive area.

According to the report, there were 63 software- related vehicle recalls from late 2012 to June 2015. That’s based on data from the United States’ National Highway Traffic Safety Administration (NHTSA). The SRR report derived that count of 63 software-related recalls using this methodology (p. 22),

To classify a recall as a software component recall, SRR searched the “Defect Summary” and “Corrective Action” fields of NHTSA’s Recall flat file for the term “software.” SRR’s inquiry captured descriptions of software-related defects identified specifically as such, as well as defects that were to be fixed by updating or changing a vehicle’s software.

That led to this analysis (p. 22),

Since the end of 2012, there has been a marked increase in recall activity due to software issues. For the primary light vehicle makes and models we studied, 32 unique software-related recalls affected about 3.6 million vehicles from 2005–2012. However, in a much shorter time period from the end of 2012 to June 2015, there were 63 software-related recalls affecting 6.4 million more vehicles.

And continuing (p. 23),

From less than 5 percent of all recalls in 2011, software-related recalls have risen to almost 15 percent in 2015. Overall, the amount of unique campaigns involving software has climbed dramatically, with nine times as many in 2015 than in 2011…

No surprises there given the dramatically increased complexity of today’s connected vehicles, with sophisticated internal networks, dozens of ECUs (electronic control units with microprocessors, memory, software and network connections), and extensive remote connectivity.

These software defects are not occurring only in systems where one expects to find sophisticated microprocessors and software, such as engine management controls and Internet-connected entertainment platforms. Microprocessors are being used to analyze everything from the driver’s position and stage of alert, to road hazards, to lane changes — and offer advanced features such as automatic parallel parking.

Where in the car are the software-related vehicle recalls? Since 2006, says the report, recalls have been prompted by defects in areas as diverse as locks/latches, power train, fuel system, vehicle speed control, air bags, electrical systems, engine and engine cooling, exterior lighting, steering, hybrid propulsion – and even the parking brake system.

That’s not all — because not every software defect results in a public and costly recall. That’s the last resort, from the OEM’s perspective. Whenever possible, the defects are either ignored by the vehicle manufacturer, or quietly addressed by a software update next time the car visits a dealer. (If the car doesn’t visit an official dealer for service, the owner may never know that a software update is available.) Says the report (p. 25),

In addition, SRR noted an increase in software-related Technical Service Bulletins (TSB), which identify issues with specific components, yet stop short of a recall. TSBs are issued when manufacturers provide recommended procedures to dealerships’ service departments for fixing problematic components.

A major role of the NHTSA is to record and analyze vehicle failures, and attempt to determine the cause. Not all failures result in a recall, or even in a TSB. However, they are tracked by the agency via Early Warning Reporting (EWR). Explains the report (p. 26),

In 2015, three new software-related categories reported data for the first time:

• Automatic Braking, listed on 21 EWR reports, resulting in 26 injuries and 1 fatality

• Electronic Stability, listed on 6 EWR reports, resulting in 7 injuries and 1 fatality

• Forward Collision Avoidance, listed in 1 EWR report, resulting in 1 injury and no fatalities

The bottom line here, beyond protecting life and property, is the bottom line for the automobile and its supply chain. As the report says in its conclusion (p. 33),

Suppliers that help OEMs get the newest software-aided components to market should be prepared for the increased financial exposure they could face if these parts fail.

About the Report

Industry Insights for the Road Ahead: Automotive Warranty and Recall Report 2016” was published by SRR: Stout, Risius Ross, which offers global financial advisory services. SRR has been in the automotive industry for 25 years, and says, “SRR professionals have more automotive experience in these service areas than any other advisory firm, period.”

This brilliant report — which is free to download in its entirety — was written by Neil Steinkamp, a Managing Director at SRR. He has extensive experience in providing a broad range of business and financial advice to corporate executives, risk managers, in-house counsel and trial lawyers. Mr. Steinkamp has provided consulting services and has been engaged as an expert in numerous matters involving automotive warranty and recall costs. His practice also includes consulting services for automotive OEMs, suppliers and their advisors regarding valuation, transactions and disputes.

, ,

Remote exploits are coming to a car, truck or other vehicle near you

5D3_5453Connected cars are vulnerable due to the radios that link them to the outside world. For example, consider cellular data links, such as the one in the Mercedes M-class SUV that my family owned for a while, allow for remote access to more than diagnostics: Using the system, called mbrace, an authorized M-B support center can unlock the doors via that link. Owners can use the M-B mobile app to

Start your vehicle from anywhere, and heat or cool the interior of your vehicle to the last set temperature. You can also remotely lock or unlock, sound the horn or find your vehicle via the Mobile App or website.

Nearly all high-end car manufacturers offer remote access systems, also referred to as telematics. Other popular systems with door-unlock capability include General Motors’ OnStar, BMW’s Assist, Hyundai’s BlueLink and Infiniti’s Connection. Each represents a potential attack vector, as do after-market add-ons.

In a blog post on Car & Driver, Bob Sorokanich writes,

It’s been a busy summer for automotive hackers, and the latest development is bad news for luxury-car owners: Good-guy digital security researcher Samy Kamkar just revealed that BMW, Mercedes-Benz, Chrysler, and aftermarket Viper connected-car systems are all theoretically vulnerable to the same hack that allowed him to remotely control functions in OnStar-equipped vehicles.

Consider yourself warned. The Federal Bureau of Investigation released a public service announcement, “Motor Vehicles Increasing Vulnerable to Remote Exploits.” The PSA says:

Vulnerabilities may exist within a vehicle’s wireless communication functions, within a mobile device – such as a cellular phone or tablet connected to the vehicle via USB, Bluetooth, or Wi-Fi – or within a third-party device connected through a vehicle diagnostic port. In these cases, it may be possible for an attacker to remotely exploit these vulnerabilities and gain access to the vehicle’s controller network or to data stored on the vehicle. Although vulnerabilities may not always result in an attacker being able to access all parts of the system, the safety risk to consumers could increase significantly if the access involves the ability to manipulate critical vehicle control systems.

The PSA continues,

Over the past year, researchers identified a number of vulnerabilities in the radio module of a MY2014 passenger vehicle and reported its detailed findings in a whitepaper published in August 2015. The vehicle studied was unaltered and purchased directly from a dealer. In this study, which was conducted over a period of several months, researchers developed exploits targeting the active cellular wireless and optionally user-enabled Wi-Fi hotspot communication functions. Attacks on the vehicle that were conducted over Wi-Fi were limited to a distance of less than about 100 feet from the vehicle. However, an attacker making a cellular connection to the vehicle’s cellular carrier – from anywhere on the carrier’s nationwide network – could communicate with and perform exploits on the vehicle via an Internet Protocol (IP) address.

In the aforementioned case, the radio module contained multiple wireless communication and entertainment functions and was connected to two controller area network (CAN) buses in the vehicle. Following are some of the vehicle function manipulations that researchers were able to accomplish.

In a target vehicle, at low speeds (5-10 mph):

  • Engine shutdown
  • Disable brakes
  • Steering

In a target vehicle, at any speed:

  • Door locks
  • Turn signal
  • Tachometer
  • Radio, HVAC, GPS

(The whitepaper referenced above is “Remote Exploitation of an Unaltered Passenger Vehicle,” by IOActive Security Services.)

How can you protect yourself — and your vehicle? The FBI offers four excellent suggestions – read the PSA for more details on them:

  1. Ensure your vehicle software is up to date
  1. Be careful when making any modifications to vehicle software
  1. Maintain awareness and exercise discretion when connecting third-party devices to your vehicle
  1. Be aware of who has physical access to your vehicle

To those I would add: Choose security over convenience, and if possible, disable the remote-access capabilities of your vehicle. You may not be able to prevent every possible attack — some of those systems can’t be turned off, and if a hacker is able to get physical access to the vehicle’s ODB-II diagnostics port or other electronics, all bets are off. You can live without being able to use a mobile app to start your car, or without the manufacturer preforming remote engine diagnostics. Heck, our ’91 Honda doesn’t even have a clicker, we have to open the door with a key. Be safe!

, , , ,

Enterprise risks when an employee can’t find a BYOD phone

find-my-phoneThere are several types of dangers presented by a lost Bring Your Own Device (BYOD) smartphone or tablet. Many IT professionals and security specialists think only about some of them. They are all problematic. Does your company have policies about lost personal devices?

  • If you have those policies, what are they?
  • Does the employee know about those policies?
  • Does the employee know how to notify the correct people in case his or her device is lost?

Let’s say you have policies. Let’s say the employee calls the security office and says, “My personal phone is gone. I use it to access company resources, and I don’t think it was securely locked.” What happens?

Does the company have all the information necessary to take all the proper actions, including the telephone number, carrier, manufacturer and model, serial number, and other characteristics? Who gets notified? How long do you wait before taking an irreversible action? Can the security desk respond in an effective way? Can the security respond instantly, including nights, weekend and holidays?

If you don’t have those policies — with people and knowledge to make them effective — you’ve got a serious problem.

Read my latest story in NetworkWorld, “Dude, where’s my phone? BYOD means enterprise security exposure.” It discusses the four biggest obvious threats from a lost BYOD device, and what you can do to address those threats.

, ,

The legacy application decommissioning ceremony

mag-tapeI once designed and coded a campus parking pass management system for an East Coast university. If you had a faculty, staff, student or visitor parking sticker for the campus, it was processed using my green-screen application, which went online in 1983. The university used the mainframe program with minimal changes for about a decade, until a new client/server parking system was implemented.

Today, that sticker application exists on a nine-track tape reel hanging on my wall — and probably nowhere else.

Decommissioning the parking-sticker app was relatively straightforward for the data center team, though of course I hope that it was emotionally traumatic. Data about the stickers was stored in several tables. One contained information about humans: name, address, phone number, relationship with the university. The other was about vehicles: make, year and color; license plate number; date of sticker assignment; sticker type and serial number; expiration date; date of cancellation. We handled some interesting exceptions. For example, some faculty were issued “floating” stickers that weren’t assigned to specific vehicles. That sort of thing.

Fortunately, historical info in the sticker system was not needed past a year or two. While important for campus security (“Who does that car parked in a no-parking zone belong to?”), it wasn’t data that needed to be retained for any length of time for legal or compliance reasons. Shutting off the legacy application was as simple as, well, shutting off the legacy application.

It’s not always that simple. Other software on campus in the 1980s — and much of the software that your team writes — needed to be retained, sometimes according to campus internal regulations, other times due to government or industry rules. How long do you need to keep payroll data? Transaction data for sales from your website? Bids for products and services, and the documentation that explains how the bids were solicited?

Any time you get into regulated industries, you have this issue. Financial services, aerospace, safety-oriented embedded systems, insurance, human resources, or medical: Information must be retained for compliance, and must be produced on demand by auditors, queries from litigators during eDiscovery, regulatory investigations, even court subpoenas.

That can make it hard — very hard — to turn off an application you no longer need. Even if the software is recording no new transactions, retention policies might necessitate keeping it alive for years. Maybe even decades, depending on the type of data being retained, and on the regulatory requirements of your industry. Think about drug records from pharmaceutical companies, or component sourcing for automobile manufacturers.

Data and application retention has many enterprise implications. For example: Before you deploy an application and its data onto a cloud provider or SaaS platform, you should ask: Will that application and its data need to be retained? If so, will the provider still be around and provide access to it? If not, you need to make sure there’s a plan to bring the systems in-house (even if they are no longer needed) to archive the data outside the application in a way that conforms with regulatory requirements for retention and access, and then you can decommission the application.

A word of caution: I don’t know how long nine-track tapes last, especially if they are not well shielded. My 20-year-old tape was not protected against heat or magnetism — hey, it was thrown into a box. There’s a better-than-good chance it is totally unreadable. Don’t rely upon unproven technology or suppliers for your own data archive, especially if the data must be retained for compliance purposes.

, , ,

The glacial pace of cellular security standards: From 3GPP to 5G

mobile_everythingSecurity standards for cellular communications are pretty much invisible. The security standards, created by groups like the 3GPP, play out behind the scenes, embedded into broader cellular protocols like 3G, 4G, LTE and the oft-discussed forthcoming 5G. Due to the nature of the security and other cellular specs, they evolve very slowly and deliberately; it’s a snail-like pace compared to, say, WiFi or Bluetooth.

Why the glacial pace? One reason is that cellular standards of all sorts must be carefully designed and tested in order to work in a transparent global marketplace. There are also a huge number of participants in the value chain, from handset makers to handset firmware makers to radio manufacturers to tower equipment to carriers… the list goes on and on.

Another reason why cellular software, including security protocols and algorithms goes slowly is that it’s all bound up in large platform versions. The current cellular security system is unlikely to change significantly before the roll-out of 5G… and even then, older devices will continue to use the security protocols embedded in their platform, unless a bug forces a software patch. Those security protocols cover everything from authentication of the cellular device to the tower, to the authentication of the tower to the device, to encryption of voice and data traffic.

We can only hope that end users will move swiftly to 5G. Why? because 4G and older platforms aren’t incredibly secure. Sure, they are good enough today, but that’s only “good enough.” The downside is that everything is pretty fuzzy when it comes to what 5G will actually offer… or even how many 5G standards there will be.

Read more in my story in Pipeline Magazine, “Wireless Security Standards.”

, , ,

Paying a steep price in Bitcoins for security lapses, thanks to ransomware

ransomRansomware is a huge problem that causes real harm to businesses and individuals. Technology service providers are gearing up to fight these cyberattacks – and that’s coming none too soon.

Ransomware is a type of cyberattack where bad actors gain access to a system, such as a consumer’s desktop or a corporate server. The attack vector might be provided by downloading a piece of malware attached to an email, visiting a corrupted website that runs a script that installs the malware or by opening a document that contains a malicious macro that downloads the malware.

In most ransomware attacks, the malware encrypts the user’s data and then demands an untraceable ransom. When the ransom is paid, the hackers promise to either decrypt the data or provide the user with a key to decrypt it. Because the data is encrypted, even removing the malware from the computer will not restore system functionality; typically, the victim has to restore the entire system from a backup or pay the ransom and hope for the best.

As cyberattacks go, ransomware has proven to be extremely effective at both frustrating users and obtaining ransom money for the attackers.

I was asked to write a story for Telecom Ramblings about ransomware. The particular focus of the assignment was on how itaffects Asia-Pacific countries, but the info is applicable everywhere: “What We Can Do About Ransomware – Today and Tomorrow.”

, , , ,

A Seven-Point Plan for Automotive Cybersecurity

code-curmudgeon2I am hoovering directly from the blog of my friend Arthur Hicken, the Code Curmudgeon:

Last week with Alan Zeichick and I did a webinar for Parasoft on automotive cybersecurity. Now Alan thinks that cybersecurity is an odd term, especially as it applies to automotive and I mostly agree with him. But appsec is also pretty poorly fitted to automotive so maybe we should be calling it AutoSec. Feel free to chime-in using the comments below or on twitter.

I guess the point is that as cars get more complicated and get more “smart” parts and get more connected (The connected car) as part of the “internet of things”, you will start to see more and more automotive security breaches occurring. From taking over the car to stealing data to triggering airbags we’ve already had several high-profile incidents which you can see in my IoT Hall-of-Shame.

To help out we’ve put together a high-level overview of a 7-point plan to get you started. In the near future we’ll be diving into detail on each of these topics, including how standards can help you not only get quality but safety and security, the role of black-box, pen-test, and DAST as well as how to get ahead of the curve and harden your vehicle software using (SAST) and hybrid testing (IAST).

The webinar was recorded for your convenience, so be sure and check it out. If you have automotive software topics that are near and dear to your heart, but sure to let me know in the comments or on Twitter or Facebook.

Okay, the webinar was back in February, but the info didn’t appear on my blog then. Here it is now. My apologies for the oversight. Watch and enjoy the webinar!

, , ,

What you can do about ransomware

Have you done your backups lately? If not… now is the time, thanks to ransomware. Ransomware is a huge problem that’s causing real harm to businesses and individuals. Technology service providers are gearing up to fight these cyberattacks – and that’s coming none too soon.

In March 2016, Methodist Hospital reported that it was operating in an internal state of emergency after a ransomware attack encrypted files on its file servers. The data on those servers was inaccessible to the Kentucky-based hospital’s doctors and administrators unless the hackers received about $1,600 in Bitcoins.

A month earlier, a hospital in Los Angeles paid about $17,000 in ransom money to recover its data after a similar hack attack. According to the CEO of Hollywood Presbyterian Medical Center, Allen Stefanek, “The quickest and most efficient way to restore our systems and administrative functions was to pay the ransom and obtain the decryption key.”

As far as we know, no lives have been lost due to ransomware. Even so, the attacks keep coming – and consumers and businesses are often left with no choice but to pay the ransom, usually in untraceable Bitcoins.

The culprit in many of the attacks — but not all of them — is a sophisticated trojan called Locky. First appearing in 2013, Locky is described by Avast as using top-class features, “such as a domain generation algorithm, custom encrypted communication, TOR/BitCoin payment, strong RSA-2048+AES-128 file encryption and can encrypt over 160 different file types, including virtual disks, source codes and databases.” Multiple versions of Locky are on the Internet today, which makes fighting it particularly frustrating. Another virulent ransomware trojan is called CryptoLocker, which works in a similar way.

Ransomware is a type of cyberattack where bad actors gain access to a system, such as a consumer’s desktop or a corporate server. The attack vector might be provided by downloading a piece of malware attached to an email, visiting a corrupted website that runs a script that installs the malware or by opening a document that contains a malicious macro that downloads the malware. In most ransomware attacks, the malware encrypts the user’s data and then demands an untraceable ransom in order to either decrypt the data or provide the user with a key to decrypt it. Because the data is encrypted, even removing the malware from the computer will not restore system functionality; typically, the victim has to restore the entire system from a backup or pay the ransom and hope for the best.

As cyberattacks go, ransomware has proven to be extremely effective at both frustrating users and obtaining ransom money for the attackers. Beyond the ransom demands, of course, there are other concerns. Once the malware has access to the user or server data… what’s to prevent it from scanning for passwords, bank account information, or other types of sensitive intellectual property? Or deleting files in a way where they can’t be retrieved? Nothing. Nothing at all. And even if you pay the ransom, there’s no guarantee that you’ll get your files back. The only true solution to ransomware is prevention.

Read about how to prevent ransomware in my essay for Upgrade Magazine, “What we can do about ransomware – today and tomorrow.” And do your backups!

, , , ,

A Man, a Plan, a Canal – Panama Papers and Shadow IT

panamaThe Panama Papers should be a wake-up call to every CEO, COO, CTO and CIO in every company.

Yes, it’s good that alleged malfeasance by governments and big institutions came to light. However, it’s also clear that many companies simply take for granted that their confidential information will remain confidential. This includes data that’s shared within the company, as well as information that’s shared with trusted external partners, such as law firms, financial advisors and consultants. We’re talking everything from instant messages to emails, from documents to databases, from passwords to billing records.

Clients of Mossack Fonseca, the hacked Panamanian law firm, erroneously thought its documents were well protected. How well protected are your documents and IP held by your company’s law firms and other partners? It’s a good question, and shadow IT makes the problem worse. Much worse.

Read why in my column in NetworkWorld: Fight corporate data loss with secure, easy-to-use collaboration tools.

, , , , , ,

Sauron hacks the Internet of Rings as a state sponsor of cyberterrorism

sauronBarcelona, Mobile World Congress 2016—IoT success isn’t about device features, like long-life batteries, factory-floor sensors and snazzy designer wristbands. The real power, the real value, of the Internet of Things is in the data being transmitted from devices to remote servers, and from those remote servers back to the devices.

“Is it secret? Is it safe?” Gandalf asks Frodo in the “Lord of the Rings” movies about the seductive One Ring to Rule Them All. He knows that the One Ring is the ultimate IoT wearable: Sure, the wearer is uniquely invisible, but he’s also vulnerable because the ring’s communications can be tracked and hijacked by the malicious Nazgûl and their nation/state sponsor of terrorism.

Wearables, sensors, batteries, cool apps, great wristbands. Sure, those are necessary for IoT success, but the real trick is to provision reliable, secure and private communications that Black Riders and hordes of nasty Orcs can’t intercept. Read all about it in my NetworkWorld column, “We need secure network infrastructure – not shiny rings – to keep data safe.”

, , , , ,

Wearable IoT technology is getting under my skin, thanks to bodyhacking

HannesSjöblad

CeBIT Preview, Hannover, Germany — It looks like a slick Jedi move, but it’s actually the Internet of Things. When Hannes Sjöblad wants to pay for coffee, he waves his hand in front of the pay station. When he wants to open a door, he waves his hand in front of the digital lock. When he wants to start his car, he waves his hand in front of the ignition.

No, he’s not Obi-Wan Kenobi saving two rebel droids. Sjöblad is a famous Swedish bodyhacker who has implanted electronics, including a passive Near-Field Communications (NFC) transmitter, into his own hand. So, instead of using his smartphone or smartwatch to activate a payment terminal, a wave of the hand gets the job done.

Speaking to a group of international journalists at CeBIT Preview 2016 here in Hannover, Sjöblad explains that he sees bodyhacking as the next step of wearable computing. Yes, you could use a phone, watch, bracelet, or even a ring to host small electronics, he says, but the real future is embedded.

Read more about Sjöblad’s bodyhacking in my story in NetworkWorld, “Subdermal wearables could unlock real possibilities for enterprise IoT.”

, , , , ,

Big Security, Big Cloud and the Big Goodbye

ddjSoftware-defined networks and Network Functions Virtualization will redefine enterprise computing and change the dynamics of the cloud. Data thefts and professional hacks will grow, and development teams will shift their focus from adding new features to hardening against attacks. Those are two of my predictions for 2015.

Big Security: As 2014 came to a close, huge credit-card breaches from retailers like Target faded into the background. Why? The Sony Pictures hack, and the release of an incredible amount of corporate data, made us ask a bigger question: “What is all that information doing on the network anyway?” Attackers took off with Sony Pictures’ spreadsheets about executive salaries, confidential e-mails about actors and actresses, and much, much more.

What information could determined, professional hackers make off with from your own company? If it’s on the network, if it’s on a server, then it could be stolen. And if hackers can gain access to your cloud systems (perhaps through social engineering, perhaps by exploiting bugs), then it’s game over. From pre-released movies and music albums by artists like Madonna, to sensitive healthcare data and credit-card numbers, if it’s on a network, it’s fair game.

No matter where you turn, vulnerabilities are everywhere. Apple patched a hole in its Network Time Protocol implementation. Who’d have thought attackers would use NTP? GitHub has new security flaws. ICANN has scary security flaws. Microsoft released flawed updates. Inexpensive Android phones and tablets are found to have backdoor malware baked right into the devices. I believe that 2015 will demonstrate that attackers can go anywhere and steal anything.

That’s why I think that savvy development organizations will focus on reviewing their new code and existing applications, prioritizing security over adding new functionality. It’s not fun, but it’s 100% necessary.

Big Cloud: Software-defined networking and Network Functions Virtualization are reinventing the network. The fuzzy line between intranet and Internet is getting fuzzier. Cloud Ethernet is linking the data center directly to the cloud. The network edge and core are indistinguishable. SDN and NFV are pushing functions like caching, encryption, load balancing and firewalls into the cloud, improving efficiency and enhancing the user experience.

In the next year, mainstream enterprise developers will begin writing (and rewriting) back-end applications to specifically target and leverage SDN/NFV-based networks. The question of whether the application is going to run on-premises or in the cloud will cease to be relevant. In addition, as cloud providers become more standards-based and interoperable, enterprises will gain more confidence in that model of computing. Get used to cloud APIs; they are the future.

Looking to boost your job skills? Learn about SDN and NFV. Want to bolster your development team’s efforts? Study your corporate networking infrastructure, and tailor your efforts to matching the long-term IT plans. And put security first—both of your development environments and your deployed applications.

Big Goodbye: The tech media world is constantly changing, and not always for the better. The biggest one is the sunsetting of Dr. Dobb’s Journal, a website for serious programmers, and an enthusiastic bridge between the worlds of computer science and enterprise computing. After 38 years in print and online, the website will continue, but no new articles or content will be commissioned or published.

DDJ was the greatest programming magazine ever. There’s a lot that can be said about its sad demise, and I will refer you to two people who are quite eloquent on the subject: Andrew Binstock, the editor of DDJ, and Larry O’Brien, SD Times columnist and former editor of Software Development Magazine, which was folded into DDJ a long time ago.

Speaking as a long-time reader—and as one of the founding judges of DDJ’s Jolt Awards—I can assure you that Dr. Dobb’s will be missed.

, , ,

Innovate in the cloud, cheaply and securely

sony_pictures_logoFor development teams, cloud computing is enthralling. Where’s the best place for distributed developers, telecommuters and contractors to reach the code repository? In the cloud. Where do you want the high-performance build servers? At a cloud host, where you can commandeer CPU resources as needed. Storing artifacts? Use cheap cloud storage. Hosting test harness? The cloud has tremendous resources. Load testing? The scales. Management of beta sites? Cloud. Distribution of finished builds? Cloud. Access to libraries and other tools? Other than the primary IDE itself, cloud. (I’m not a fan of working in a browser, sorry.)

Sure, a one-person dev team can store an entire software development environment on a huge workstation or a convenient laptop. Sure, a corporation or government that has exceptional concerns or extraordinary requirements may choose to host its own servers and tools. In most cases, however, there are undeniable benefits for cloud-oriented development, and if developers aren’t there today, they will be soon. My expectation is that new projects and team launch on the cloud. Existing projects and teams will remain on their current dev platforms (and on-prem) until there’s a good reason to make the switch.

The economics are unassailable, the convenience is unparalleled, and both performance and scalability can’t be matched by in-house code repositories. Security in the cloud may also outmatch most organizations’ internal software development servers too.

We have read horror stories about the theft of millions of credit cards and other personal data, medical data, business documents, government diplomatic files, e-mails and so-on. It’s all terrible and unlikely to stop, as the recent hacking of Sony Pictures demonstrates.

What we haven’t heard about, through all these hacks, is the broad theft of source code, and certainly not thefts from hosted development environments. Such hacks would be bad, not only because proprietary source code contains trade secrets, but also because the source can be reverse-engineered to reveal attack vulnerabilities. (Open-source projects also can be reverse-engineered, of course, but that is expected and in fact encouraged.)

Even worse that reverse-engineering of stolen source code would be unauthorized and undetected modifications to a codebase. Can you imagine if hackers could infiltrate an e-commerce system’s hosted code and inject a back door or keylogger? You get the idea.

I am not implying that cloud-based software development systems are more secure than on-premises systems. I am also not implying the inverse. My instinct is to suggest that hosted cloud dev systems are as safe, or safer, than internal data center systems. However, there’s truly no way to know.

A recent report from the analyst firm Technology Business Research took this stance, arguing that security for cloud-based services will end up being better than security at local servers and data centers. While not speaking specifically to software development, a recent TBR report concluded, “Security remains the driving force behind cloud vendor adoption, while the emerging trends of hybrid IT and analytics, and the associated security complications they bring to the table, foreshadow steady and growing demand for cloud professional services over the next few years.”

Let me close by drawing your attention to a competition geared at startups innovating in the cloud. The Clouded Leopard’s Den is for young companies looking for A-series or B/C-series funding, and offers tools and resources to help them grow, attract publicity, and possibly even find new funding. If you work at a cloud startup, check it out!

, , , , , ,

Attack of the six-rotor quadracopter photo drones

quadracopter-droneDrones are everywhere. Literally. My friend Steve, a wedding photographer, always includes drone shots. Drones are used by the military, of course, as well as spy agencies. They are used by public service agencies, like fire departments. By real estate photographers who want something better than Google Earth. By farmers checking on their fences. By security companies to augment foot patrols. And by Hollywood filmmakers, who recently won permission from the United States Federal Aviation Authority (FAA) to operate drones on a movie sets.

Drones can also be used for mischief, as reported by Nick Wingfield in the New York Times. His story, “Now, Anyone Can Buy a Drone. Heaven Help Us” described how pranksters fly drones onto sports fields to disrupt games and infuriate fans, as well as animal-welfare activists using drones to harass hunters and scare away their prey.

Drones are everywhere. My son and I were shopping at Fry’s Electronics, a popular Silicon Valley gadget superstore. Seemingly every aisle featured drones ranging in price from under US$100 to thousands of dollars.

A popular nickname for consumer-quality drones is a “quadcopter,” because many of the models feature four separate rotors. We got a laugh from one line of inexpensive drones, which was promoting quadcopters with three, four and six rotors, such as this “Microgear 2.4 GHz. Radio Controlled RC QX-839 4 Chan 6 Axis Gyro Quadcopter Drones EC10424.” I guess they never thought about labeling it a hexcopter—or would it be a sextcopter?

As drones scale up from toys to business tools, they need to be smart and connected. Higher-end drones have cameras and embedded microprocessors. Platforms like Android (think Arduino or Raspberry Pi) get the job done without much weight and without consuming too much battery power. And in fact there are products and kits available that use those platforms for drone control.

Connectivity. Today, some drones are autonomous and disconnected, but that’s not practical for many applications. Drones flying indoors could use WiFi, but in the great outdoors, real-time connectivity needs a longer reach. Small military and spy drones use dedicated radios, and in some cases, satellite links. Business drones might go that path, but could also rely upon cellular data. Strap a smartphone to a drone, and you have sensors, connectivity, microprocessor, memory and local storage, all in one handy package. And indeed, that’s being done today too. It’s a bird! It’s a plane! It’s a Samsung Galaxy S4!

Programming drones is going to be an exciting challenge, leveraging the skills needed for building conventional mobile apps to building real mobile apps. When a typical iPhone or Android app crashes, no big deal. When a drone app crashes, the best-case scenario is a broken fan blade. Worst case? Imagine the lawsuits if the drone hits somebody, causes an automobile accident, or even damages an aircraft.

Drones are evolving quickly. While they may seem like trivial toys, hobbyist gadgets or military hardware, they are likely to impact many aspects of our society and, perhaps, your business. Intrigued? Let me share two resources:

InterDrone News: A just-launched newsletter from BZ Media, publisher of SD Times. It provides a unique and timely perspective for builders, buyers and fliers of commercial unmanned aerial vehicles. Sign up for free.

InterDrone Conference & Expo: Mark your calendar for the International Drone Conference and Exposition, Oct. 13-15, 2015, in Las Vegas. If you use drones or see them in your future, that’s where you’ll want to be.

, , , ,

Is the best place for data in your data center or in the cloud? Ask your lawyer

lawyer

Cloud-based storage is amazing. Simply amazing. That’s especially true when you are talking about data from end users that are accessing your applications via the public Internet.

If you store data in your local data center, you have the best control over it. You can place it close to your application servers. You can amortize it as a long-term asset. You can see it, touch it and secure it—or at least, have full control over security.

There are downsides, of course, to maintaining your own on-site data storage. You have to back it up. You have to plan for disasters. You have to anticipate future capacity requirements through budgeting and advance purchases. You have to pay for the data center itself, including real estate, electricity, heating, cooling, racks and other infrastructure. Operationally you have to pipe that data to and from your remote end users through your own connections to the Internet or to cloud application servers.

By contrast, cloud storage is very appealing. You pay only for what you use. You can hold service providers to service-level guarantees. You can pay the cloud provider to replicate the storage in various locations, so customers and end-users are closer to their data. You can pay for security, for backups, for disaster recovery provisions. And if you find that performance isn’t sufficient, you can migrate to another provider or order up a faster pipe. That’s a lot easier, cheaper and faster than ripping-and-replacing outdated storage racks in your own data center.

Gotta say, if I were setting up a new application for use by off-site users (whether customers or employees), I’d lean toward cloud storage. In most cases, the costs are comparable, and the operational convenience can’t be beat.

Plus, if you are at a startup, a monthly storage bill is easier to work with than a large initial outlay for on-site storage infrastructure.

Case closed? No, not exactly. On-site still has some tricks up its sleeve. If your application servers are on-site, local storage is faster to access. If your users are within your own building or campus, you can keep everything within your local area network.

There also may be legal advantages to maintaining and using onsite storage. For compliance purposes, you know exactly where the data is at all times. You can set up your own instruction detection systems and access logs, rather than relying upon the access controls offered by the cloud provider. (If your firm isn’t good at security, of course, you may want to trust the cloud provider over your own IT department.)

On that subject: Lawsuits. In her story, “Eek! Lawyers are Coming After Your Fitbit!,” Sharon Fisher writes about insurance attorneys issuing subpoenas against a client’s FitBit data to show that she wasn’t truly as injured as she claimed. The issue here isn’t only about wearables or healthcare. It’s also about access. “Will legal firms be able to subpoena your cloud provider if that’s where your fitness data is stored? How much are they going to fight to protect you?” Fisher asks.

Say a hostile attorney wants to subpoena some of your data. If the storage is in your own data center, the subpoena comes to your company, where your own legal staff can advise whether to respond by complying or fighting the subpoena.

Yet: If the data is stored in the cloud, attorneys or government officials could come after you, or try to get access by giving a subpoena to the cloud service provider. Of course, encryption might prevent the cloud provider from complying. Still, this is a new concern, especially given the broad subpoena powers granted to prosecutors, litigating attorneys and government agencies.

It’s something to talk to your corporate counsel about. Bring your legal eagles into the conversation.

, , , ,

Tomorrow’s forecast: Distributed Denial of Service

forecastMalicious agents can crash a website by implementing a DDoS—a Distributed Denial of Service Attack—against a server. So can sloppy programmers.

Take, for example, the National Weather Service’s website, operated by the United States National Oceanic and Atmospheric Administration, or NOAA. On August 29, the service went down, hard, as single rogue Android app overwhelmed the NOAA’s servers.

As far as anyone knows, there was nothing deliberately malicious about the Android app, and of course there is nothing specific to Android in this situation. However, the app in question was making service requests of the NOAA server’s public APIs every few milliseconds. With hundreds, thousands or tens of thousands of instances of that app running simultaneously, the NOAA system collapsed.

There is plenty of blame to go around. Let’s start with the app developer.

Certainly the app developer was sloppy, sloppy, sloppy. I can imagine that the app worked great in testing, when only one or two instances of the app were running at any one time on a simulator or on actual devices. Scale it up—boom! This is a case where manual code reviews may have found the problem. Maybe not.

Alternatively, the app developer could have checked to see if the public APIs it required (such as NOAA’s weather API) could handle the anticipated load. However, if the coders didn’t write the software correctly, load testing may not have sufficed. For example, say that the design of the app was to pull data every 10 seconds. If the programmers accidentally set up the data retrieval to pull the data every 10 milliseconds, the load would be 1,000x greater than anticipated. Every 10 seconds, no problem. Every 10 milliseconds, big problem. Boom!

This is a nasty bug, to be sure. Compilers, libraries, test systems, all would verify that the software ran correctly, because it did run correctly. In the scenario I’ve painted, it simply wasn’t coded to meet the design. The bug might have been spotted if someone noticed a very high number of external API calls, or again, perhaps during a manual code review. Otherwise, it’s not hard to see how it would slip through the crack.

Let’s talk about NOAA now. In 2004, the weather service beefed up its Internet loads in anticipation of Hurricane Charley, contracting with Akamai to host some of its busiest Web pages, using distributed edge caching to reduce the load. This worked well, and Akamai continued to work with NOAA. It’s unclear if Akamai also fronted public API calls; my guess is that those were passed straight through to the National Weather Service servers.

NOAA’s biggest problem is that it has little control over external applications that use its public APIs. Even so, Akamai was still in the circuit and, fortunately, was able to help with the response to the Aug. 29 accidental DDoS situation. At that time, the National Weather Service put out a bulletin on its NIDS messaging service that said:

TO – ALL CUSTOMERS SUBJECT – POINT FORECAST ISSUES. WE ARE PROVIDING NOTICE TO ALL THAT NIDS HAS IDENTIFIED AN ABUSING ANDROID APP THAT IS IMPACTING FORECAST.WEATHER.GOV. WE HAVE FORCED ALL SITES TO ZONES WHILE WE WORK WITH THE DEVELOPER. AKAMAI IS BEING ENGAGED TO BLOCK THE APPLICATION. WE CONTINUE TO WORK ON THIS ISSUE AND APPRECIATE YOUR PATIENCE AS WE WORK TO RESOLVE THIS ISSUE.

Kudos to NOAA for responding quickly and transparently to this issue. Still, this appalling situation—that a single DDoS attack could cripple such a vital service—is unacceptable. Imagine if this had been a malicious attack, rather than an accidental coding error, and if the attacker was able to modify the attack in real time to go around Akamai’s attempts to block the traffic.

What could NOAA have done differently? For best results, DDoS attacks must be blocked within the network before they reach (and overwhelm) the server. Therefore, DDoS detection and blocking systems should already have been in place.

For example, with the ability to detect potential attacks due to abnormally high volumes of requests from a specific app, raise alarms, and also drop such requests (which is fast and takes few resources), instead of servicing them (which is slow and takes more resources). Perfect? No. DDoS scenarios are nasty and messy. No matter how you slice it, though, a single misbehaving app should never be able to crash your server.

, , , ,

They want to steal your data

bankamericard“My name is Patricia from the Bank of America fraud prevention department. This important message is for Mr. Alan Zeichick. We are calling to verify some potentially suspicious activity on your account. It is very important that we speak with you.”

Tuesday’s voicemail from my bank was short and simple. Nobody had pilfered a credit-card receipt or hacked into my account, the representative told me during our conversation. Rather, BofA had been notified by Visa (the credit card clearinghouse) that a retailer had been hacked, and many credit card numbers were stolen. Including mine. As of right now, my card was frozen; the bank will issue me a new card with a new number.

Who was the merchant? According to the BofA representative, Visa didn’t divulge that information due to an ongoing investigation. Nor did the representative know how many credit card numbers were stolen; all she knew what was that BofA was given a list of their bank’s customers who were affected.

These stories are coming far too often. Millions of cards were stolen in 2014 from diverse merchants like P.F. Chang’s China Bistro (a restaurant chain), Michaels Stores (art supplies), Sally Beauty (cosmetics), and Shaws (grocery stores). And those are only a few of the major vendors. Who knows how many smaller card thefts are either never reported, or aren’t deemed sufficiently juicy by the news media?

Some of you might be thinking, “We don’t take credit card numbers on our websites, so there’s no potential risk exposure.” Wrong. I am frequently astonished by the number of companies that maintain lots of customer data, and have that data pilfered. The Payment Card Industry (PCI) standards say that you should never store customer payment information. We’ve all seen that those standards are not followed, sometimes intentionally through neglect, and sometimes through flawed architecture, bad coding or lousy testing.

Let’s be clear: Encrypting browser communications does not protect your customers’ personal or financial information. If you are storing that information anywhere—in your data center, in the cloud—it is at real risk. The threats are active. Are your countermeasures active?

What is even more astonishing is that many of these thefts are of personal information stored on employees’ laptops. You may recall a high-profile case in 2013, where nearly 840,000 Horizon Blue Cross Blue Shield customers had their information compromised when two laptops were stolen from the New Jersey-based health insurance company.

To quote from the Star Ledger’s story,

The stolen laptops were password-protected but had unencrypted data, Horizon said in a statement today. A subsequent investigation determined the computers may have contained files with personal information, including names, addresses, dates of birth, and, in some instances, Social Security numbers and limited clinical information, the insurer said.

How is that possible? No possible scenario should allow customer information to be downloaded onto a desktop or laptop or tablet or phone. Ever. Encrypted or not, the data should never leave the server.

Please tell me you aren’t storing credit card info in files that can be stolen. Please tell me  your company has actively sought to ensure that customer information can never ever ever be downloaded from servers.

Data theft is a nuisance, for cardholders like me, and for businesses like yours. Do you protect your customers’ information?

, , ,

It’s time to learn Swift

swift-chris-lattnerSAN FRANCISCO — I expected a new version of OS X, the operating system for Mac desktops and notebooks. I expected a new version of iOS, the operating system for iPhones and iPads. I did not expect a new programming language. Yet that’s what we got at Apple’s Worldwide Developers Conference, held here this week. And I’m delighted.

Along with the previews of OS X 10.10 “Yosemite” and iOS 8, Apple showed Swift, a language that runs inside its familiar Xcode integrated development environment.

Swift is designed primarily for safety. As Apple puts it:

Swift eliminates entire classes of unsafe code. Variables are always initialized before use, arrays and integers are checked for overflow, and memory is managed automatically. Syntax is tuned to make it easy to define your intent—for example, simple three-character keywords define a variable (var) or constant (let). The safe patterns in Swift are tuned for the powerful Cocoa and Cocoa Touch APIs. Understanding and properly handling cases where objects are nil is fundamental to the frameworks, and Swift code makes this extremely easy. Adding a single character can replace what used to be an entire line of code in Objective-C. This all works together to make building iOS and Mac apps easier and safer than ever before.

Obviously we have not had a chance to work with Swift directly. However, it appears to be a very easy language to learn, especially for developers who are used to Objective-C. It’s designed for Apple’s Cocoa and Cocoa Touch libraries, is built with the familiar and stable LLVM compiler, and creates the same runtime as Objective-C.

Apple says Swift programs are fast. The company claims that a complex object sort will run in Objective-C about 2.8x faster than in Python. But if you use Swift, it runs 3.9x faster.

Learn more about the Swift announcement, as well as a ton of new APIs, in Rob Marvin’s article, “Apple announces Swift programming language, new SDK and developer features at WWDC.”

A neat feature of Swift is what Apple calls “playgrounds,” where you can see how the code runs as you write it—without building a new version. That’s cool. Swift isn’t ready yet, but you can check out Apple’s preliminary documentation, including a tour and language guide.

Swift is a cross-platform language, if you define “cross platform” to mean “both of Apple’s platforms.” Yes, you can use Swift to write apps for OS X and for iOS, and because it creates the same runtimes as Objective-C, you should be able to run Swift applications on older versions of those operating systems, not only OS X 10.10 and iOS 8. What you can’t do, and probably never will do, is run Swift apps on competing platforms. No Android, no Windows Phone. Given that the language does target the Cocoa and Cocoa Touch libraries, that’s clearly no surprise.

Most mobile app developers already target iOS first, even though there are more Android devices than iPhones and iPads. Swift won’t change that, and in fact it will likely make iOS development even more attractive.

On the desktop/notebook side, developers writing native software probably target Windows first because of the huge installed base of machines. It’s unlikely that Swift will change behaviors there. But then again, writing desktop/notebook software truly is becoming a niche activity.

, , ,

Power down… or airplane mode?

Like many of you, I travel with a vast array of personal electronic devices – so much that my briefcase bulges with screens, batteries, cables and charging bricks. Some devices are turned off when I’m on an airplane – and some aren’t, often because I forget.

Take this week, for example. I am working out of SD Times’ New York headquarters, instead of my usual office near San Francisco. What did I bring? A 13-inch mid-2011 MacBook Air notebook, an iPad Mini with Logitech Ultrathin Keyboard, a Google Nexus 7 tablet, a Galaxy Nexus phone, a Virgin Mobile MiFi access point, Bose QuietComfort 15 noise-cancelling headphones, RocketFish RF-MAB2 Bluetooth stereo headset, a Microsoft Notebook Optical Mouse 3000, a USB hub, and an HP-15C calculator. Oh, let’s not forget the Canon PowerShot S100 digital camera. And my Pebble watch.

All that for a five-day trip. A bit excessive? Maybe.

I can guarantee that not every device is powered down during a flight. Yes, the flight attendants ask passengers to turn devices all the way off, and I have good intentions. But there’s a good chance that the laptop is sleeping, that some tablets and the phone might in airplane mode instead of off, I might have forgotten to slide the switch on the Logitech keyboard, and so-on.

Think about all the electronic noise from those electronics. Think about all the potential interference from the WiFi, cellular and Bluetooth radios, the GPSes in the phone and Google tablet… yet it doesn’t seem to make a tangible difference.

I’m not alone in failing to turn off every personal electronic device. According to a new study by the Consumer Electronics Association,

Almost one-third (30 percent) of passengers report they have accidently left a PED turned on during a flight. The study found that when asked to turn off their electronic devices, 59 percent of passengers say they always turn their devices completely off, 21 percent of passengers say they switch their devices to “airplane mode,” and five percent say they sometimes turn their devices completely off. Of those passengers who accidently left their PED turned on in-flight, 61 percent said the device was a smartphone.

At least I have good intentions. Many travelers intentionally keep playing games with their phones, hiding them when the flight attendant walks by, taking them out as soon as the uniformed crewmember stops looking.

That doesn’t change the reality that devices are left turned on — and the flights appear to be perfectly safe. It’s time for the U.S. Federal Aviation Administration, and the U.S. Federal Communications Commission, to stop the ban on using electronic devices during takeoff, landing, and flying at altitudes under 10,000 feet.

, , , ,

Coping with the data

As I write this on Friday, Apr. 19, it’s been a rough week. A tragic week. Boston is on lockdown, as the hunt for the suspected Boston Marathon bombers continues. Explosion at a fertilizer plant in Texas. Killings in Syria. Suicide bombings in Iraq. And much more besides.

The Boston incident struck me hard. Not only as a native New Englander who loves that city, and not only because I have so many friends and family there, but also because I was near Copley Square only a week earlier. My heart goes out to all of the past week’s victims, in Boston and worldwide.

Changing the subject entirely: I’d like to share some data compiled by Black Duck Software and North Bridge Venture Partners. This is their seventh annual report about open source software (OSS) adoption. The notes are analysis from Black Duck and North Bridge.

How important will the following trends be for open source over the next 2-3 years?

#1 Innovation (88.6%)
#2 Knowledge and Culture in Academia (86.4%)
#3 Adoption of OSS into non-technical segments (86.3%)
#4 OSS Development methods adopted inside businesses (79.3%)
#5 Increased awareness of OSS by consumers (71.9%)
#6 Growth of industry specific communities (63.3%)

Note: Over 86% of respondents ranked Innovation and Knowledge and Culture of OSS in Academia as important/very important.

How important are the following factors to the adoption and use of open source? Ranked in response order:

#1 – Better Quality
#2 – Freedom from vendor lock-in
#3 – Flexibility, access to libraries of software, extensions, add-ons
#4 – Elasticity, ability to scale at little cost or penalty
#5 – Superior security
#6 – Pace of innovation
#7 – Lower costs
#8 – Access to source code

Note: Quality jumped to #1 this year, from third place in 2012.

How important are the following factors when choosing between using open source and proprietary alternatives? Ranked in response order:

#1 – Competitive features/technical capabilities
#2 – Security concerns
#3 – Cost of ownership
#4 – Internal technical skills
#5 – Familiarity with OSS Solutions
#6 – Deployment complexity
#7 – Legal concerns about licensing

Note: A surprising result was “Formal Commercial Vendor Support” was ranked as the least important factor – 12% of respondents ranked it as unimportant.  Support has traditionally been held as an important requirement by large IT organizations, with awareness of OSS rising, the requirement is rapidly diminishing.

When hiring new software developers, how important are the following aspects of open source experience? Ranked in response order:

2012
#1 – Variety of projects
#2 – Code contributions
#3 – Experience with major projects
#4 – Experience as a committer
#5 – Community management experience

2013
#1 – Experience with relevant/specific projects
#2 – Code contributions
#3 – Experience with a variety of projects
#4 – Experience as a committer
#5 – Community management experience

Note: The 2013 results signal a shift to “deep vs. broad experience” where respondents are most interested in specific OSS project experience vs. a variety of projects, which was #1 in 2012.

There is a lot more data in the Future of Open Source 2013 survey. Go check it out. 

, , , ,

The complications of cloud adoption

Cloud computing is seductive. Incredibly so. Reduced capital costs. No more power and cooling of a server closet or data center. High-speed Internet backbones. Outsourced disaster recovery. Advanced edge caching. Deployments are lightning fast, with capacity ramp-ups only a mouse-click away – making the cloud a panacea for Big Data applications.

Cloud computing is scary. Vendors come and vendors go. Failures happen, and they are out of your control. Software is updated, sometimes with your knowledge, sometimes not. You have to take their word for security. And the costs aren’t always lower.

An interesting new study from KPMG, “The Cloud Takes Shape,” digs into the expectations of cloud deployment – and the realities.

According to the study, cloud migration was generally a success. It showed that 33% of senior executives using the cloud said that the implementation, transition and integration costs were too high; 30% cited challenges with data loss and privacy risks; 30% were worried about the loss of control. Also, 26% were worried about the lack of visibility into future demand and associated costs, 26% fretted about the lack of interoperability standards between cloud providers; and 21% were challenged by the risk of intellectual property theft.

There’s a lot more depth in the study, and I encourage you to download and browse through it. (Given that KPMG is a big financial and tax consulting firm, there’s a lot in the report about the tax challenges and opportunities in cloud computing.)

The study concludes,

Our survey finds that the majority of organizations around the world have already begun to adopt some form of cloud (or ‘as-a-service’) technology within their enterprise, and all signs indicate that this is just the beginning; respondents expect to move more business processes to the cloud in the next 18 months, gain more budget for cloud implementation and spend less time building and defending the cloud business case to their leadership. Clearly, the business is becoming more comfortable with the benefits and associated risks that cloud brings.

With experience comes insight. It is not surprising, therefore, that the top cloud-related challenges facing business and IT leaders has evolved from concerns about security and performance capability to instead focus on some of the ‘nuts and bolts’ of cloud implementation. Tactical challenges such as higher than expected implementation costs, integration challenges and loss of control now loom large on the cloud business agenda, demonstrating that – as organizations expand their usage and gain more experience in the cloud – focus tends to turn towards implementation, operational and governance challenges.

, , ,

Preying on human weakness with well-designed faux emails

This past week, I’ve started receiving messages from eFax telling me that I’ve received a fax, and to click on a link to download my document. As a heavy eFax user, this seemed perfectly normal… until I clicked one of the links. It took me to a malware site. Fortunately, the site was designed to target Windows computers, and simply froze my Mac’s browser.
The faux eFax messages were well designed. They had clean headers and made it through my email service provider’s malware filters.
Since then, six of those malicious messages have appeared. I have to look carefully at the embedded link to distinguish those from genuine eFax messages with links to genuine faxes.
The cybercrime wars continue unabated, with no end in sight. I’ve also received fake emails from UPS, asking me to print out a shipping label… which of course leads me to a phishing site.
Malicious email – whether it’s phishing, a “419”-style confidence scam, or an attempt to add your computers to someone’s botnet – is only one type of cybercrime. Most of the time, as software developers, we’re not focusing on bad emails, unless we’re trying to protect our own email account, or worrying about the design of emails sent into automated systems. SQL Injection delivered by email? That’s nothing I want to see.
Most of the attacks that we have to content with are more directly against our software – or the platforms that they are built upon. Some of those attacks come from outside; some from inside.
Some attacks are successful because of our carelessness in coding, testing, installing or configuring our systems. Other attacks succeed despite everything we try to do, because there are vulnerabilities we don’t know about, or don’t know how to defend against. And sometimes we don’t even know that a successful attack occurred, and that data or intellectual property has been stolen.
We need to think longer and harder about software security. SD Times has run numerous articles about the need to train developers and tester to learn secure coding techniques. We’ve written about tools that provided automated scanning of both source code and binaries. We’re talked about fuzz testers, penetration tests, you name it.
What we generally don’t talk about is the backstory – the who and the why. Frankly, we generally don’t care why someone is trying to hack our systems; it’s our job to protect our systems, not sleuth out perpetrators.
We are all soldiers in the cybercrime war – whether we like it or not. Please read a story by SD Times editor Suzanne Kattau, “Cybercrime: How organizations can protect themselves,” where she interviewed Steve Durbin, for the Information Security Forum. It’s interesting to see this perspective on the broader problem.
,

Can you trust the integrity of your chips?

A few weeks ago, in “Can you trust the integrity of your data,” I wrote about the potential for shenanigans with a new computer-controlled watt-hour meter that a local electric utility installed at my home. The worry: My bill might go up.

That, my friends, may only be the tip of the iceberg.

We’ve all heard about backdoors installed into software – secret root passwords, or overrides installed into payroll software. Many of those backdoors are urban legends, but I’ve encountered such things in real life. You probably have too.

What if backdoors are being installed into your nation’s defense systems at the hardware level – secretly – by your enemies? While that sounds like the topic of a good science-fiction movie, it’s not a far-fetched scenario at all.

On Oct. 26, John Markoff of the New York Times wrote a cyberwar story called “Old Trick Threatens the Newest Weapons.” He wrote that only about 2% of the chips used in American military equipment are manufactured in secure facilities, and that the other 98% might hide kill switches or backdoor access points.

“As advanced systems like aircraft, missiles and radars have become dependent on their computing capabilities, the specter of subversion causing weapons to fail in times of crisis, or secretly corrupting crucial data, has come to haunt military planners. The problem has grown more severe as most American semiconductor manufacturing plants have moved offshore.”

Could attempts to subvert those chips be detected? Not a chance. Markoff wrote chillingly,

“Cyberwarfare analysts argue that while most computer security efforts have until now been focused on software, tampering with hardware circuitry may ultimately be an equally dangerous threat. That is because modern computer chips routinely comprise hundreds of millions, or even billions, of transistors. The increasing complexity means that subtle modifications in manufacturing or in the design of chips will be virtually impossible to detect.”

The thought that an enemy of your country could shut down – or take over – one of your nation’s weapon systems is terrible to contemplate. The threat, however, isn’t merely to defense systems or military equipment. What would be the economic implications of secret kill switches built into business-grade network servers or network routers? How about remote subversion of consumer-grade mobile phones, laptop computers or automobile chips?

And to think I was worried about my electricity bills.

, ,

The Windows Malware Wars: Viruses 4, Alan 0

I fought the hackers, and the hackers won. Here’s the story: One of our employees had a nice Dell Latitude D610 laptop, and it was totally messed up – running super-slow, lots of crashes, adware popups in the browser, and so-on.

Because this was a huge productivity problem for a key employee, we solved it by buying her a new laptop this past summer. But what about the old laptop? It ended up on a shelf in my office. It’s a good machine: 1.7GHz Pentium M processor, 1400×1050 14-inch screen, 60GB hard drive, lots of RAM, DVD player, two batteries. Physically, it’s in great shape. It’s a shame not to put that laptop back into service.

It so happened that I currently need a Windows laptop for a specific project. I pulled the Latitude off the shelf yesterday morning, scurried around to find its power supply brick (which was buried) and decided to clean it up. This shouldn’t take long, I thought.

Big mistake, at least in terms of it being easy. After many hours of scrubbing, uninstalling software (the previous user had installed every free browser toolbar known to humanity) and running Microsoft Update a few dozen times, the machine was working. Sort of. It was still incredibly slow, and the browser still was being hijacked by adware.

I ran an anti-virus check, and it discovered oodles of infestations. Dozens. Most of which the Sophos software could delete. However, there were four that it couldn’t destroy. Two of them were instances of the Virtum-Gen trojan. The other two were spyware, called ClickStream and Virtumondo. As the saying goes, I tried scrubbing, I tried soaking, nothing seemed to help.

To make a long story short, after fighting with the malware last night for several hours, I’d had enough. It’s one thing to have a “project” laptop on my desk, and keep running Microsoft Update and rebooting while I do other work on my own machine. That’s not hard. It’s another to focus intensively on removing spyware and viruses. That takes a lot of time, patience and concentration, none of which this project could justify.

So, this morning I blew away the Latitude’s hard drive and installed a clean copy of Windows XP Professional. I hadn’t wanted to do this, since there were applications on the Latitude that I wanted to keep. However, at some point you just have to admit defeat and cut your losses.

The installation process for Win XP Pro itself was interminable. It’s been a while since I last did this, and I’d forgotten how long it takes. The installation disc I had was pre-Service Pack level, and it’s taken many hours to install Windows, add the service packs, and apply all the updates and security patches. But now, at least I have a cleanly configured Windows laptop that’s not infected, and runs fast, fast, fast.

I’m glad I don’t fix PCs for a living.

,

Consolidation, growth in software security

Yesterday, we learned that Fortify Software will be buying Secure Software. Each company makes source code analysis tools. Both are well-regarded in terms of the quality of their products, and in the expertise of their teams.

However, Secure Software had been undergoing a transformation, as the well-known security guru, John Viega, had already left the company (in March 2006) to join McAfee. This led to questions about the future of CLASP, the comprehensive, lightweight, application security process that Viega developed. The sale of Secure Software was no surprise.

What did surprise me, however, is that it was bought by another small security company. We’re certainly the point when bigger ALM companies, such as Borland, IBM Rational, Telelogic or Serena, should be adding security tools to their product portfolio. It’s not a question of if, but when, these specialist firms get snatched up.

This consolidation of the software security market is offset by the launch of a new player. The next issue of SD Times introduces us to a new player, Veracode, which was created out of the remnants of V0pht, a hacker collective in Boston. Look for Alex Handy’s story, coming out on Feb. 1st.

, , , ,

Greetings, Earthlings and Script Kiddies

cobra wheelWelcome to my blog. It has to start somewhere, and this is where it starts. And the trek had to start sometime; it should have started a long time ago, but it didn’t, so here we are.

This blog will be a spot to discuss topics of professional and personal interest to me, mainly focused on the realm of information technology, focusing on software development, security, enterprise computing, and the like.

Let me start with a story software hacking that begins, oddly enough, with an automotive service experience.

Earlier this week, I took my beloved 1993 Mustang GT to the Ford dealer for a routine maintenance, which includes a tire rotation. At about 11:00 am, I got a call from the service advisor: “Mr. Zeichick, I can’t find the key for your wheel locks. Where is it?”

I drove back to the shop, we searched high and we searched low. We couldn’t find the special key, so we skipped that part of the service.

But now I’ve got my mighty steed parked in the driveway, with a missing wheel lock key. What if I get a flat? I need to get those locks off pronto!

Wheel locks are a nuisance. However, I have expensive Ford Cobra rims, the dealer advised that their TTL (time to live) without locks would be less than a week. Ever since, I assumed that the wheel locks would do a decent job protecting the vehicle. How can I get them off without damaging the wheels? Gosh, this is going to be hard.

Time to ask an expert. I went to my local Sears hardware store with a spare lug nut, and asked my favorite salesman if he knew how to jury-rig sockets, wrenches, pry bars and other implements to get the wheel locks off. “Relax,” he laughed, and referred me to the “SK 2-Piece 1/2-Inch Drive Wheel Removal Kit” designed expressly for removing damaged lug nuts and wheel locks.

Five minutes after getting home, the lock nuts were removed, without damaging the wheels or bolts. And three of those five minutes were spent finding the half-inch socket set.

My confidence in Sears went up – while my confidence in wheels locks went down. If I could buy this tool “over the counter” at my local hardware store, then presumably anyone who wanted to lift wheels would already have one. Bottom line: those wheel locks wouldn’t have even slowed a thief down. Ignorance was bliss. My ignorance could have cost me, big-time, especially if those had been really expensive rims, or if the car was routinely parked on the street, instead of in my garage.

When it comes to people who want to break into your system, there are two types: technical experts, who will use their superior knowledge and experience to find and exploit your Web site or application vulnerabilities – and “script kiddies,” who will simply apply pre-existing hack techniques and use tools created by other people. Just like any petty thief could buy the wheel-lock removal kit at Sears, so any script kiddie can download hacking tools for free.

Now I’m hunting for a better grade of wheel lock… and you should be making sure that your own app-security measures won’t fall to the first script kiddie who decides to target your applications and data with an over-the-counter tool.