(Wall Street Journal) Militants in Iraq have used $26 off-the-shelf software to intercept live video feeds from U.S. Predator drones, potentially providing them with information they need to evade or monitor U.S. military operations. Senior defense and intelligence officials said Iranian-backed insurgents intercepted the video feeds by taking advantage of an unprotected communications link in some of the remotely flown planes' systems. Shiite fighters in Iraq used software programs such as SkyGrabber -- available for as little as $25.95 on the Internet -- to regularly capture drone video feeds.
This silly security breach got a chuckle but is deadly serious business. It could literally cost some soldiers their lives. One wonders about the deadlines and contraints that lead some project manager to say "We don't have time for that fancy security stuff the designer wants to include, and what backwoods dirty militant is going to have the brains to do go after our drones. We'll worry about security in the next version."
SOA and Web Services allows quick and easy exposure of important system and application functionality. Integration can be fast and easy. Security and control are seen as overhead, and frequently avoided by the development team just trying to get the job done (under tight time and budget constraints).
An example: A major annuities (insurance) application for a top 10 insurance company needed to be connect to the customer service web site. A series of web services were quickly created, adhereing to standards for transaction and data formats. But, SSL was avoided because of concerns over processing overhead. Basic clear text security was placed on the services, mostly to prevent accidental connection between test and production servers.
Two years later the application was moved from one outside hosting vendor to inside the company network, but the web servers were placed into the DMZ (the network zone allowing access from the internet). Because web services commonly route through the web server, this meant that the unencrypted clear-text password services were now routing out from the company network to the internet, then back in to the DMZ. Meaning company business traffic was traveling unencrypted over the internet.
- Encrypt your data! Encryption overhead is (with today's processors) minimal, and you can never be sure exactly what path your service may travel (now and in the future). Even further, much hacking (sniffing) occurs from inside the network, from an employee or accessing a company network port.
- Service access control is critical! Obscurity is not security.
- Validating the source of requests is also important!
Security doesn't happen accidentally or by itself. It has to be planned, will require some tools (such as Amberpoint or IBM Datapower or Intel SOA Expressway), time and budget.
After all, you don't want the enemy watching your survellience video. Or the hackers accessing your business transactions.
This silly security breach got a chuckle but is deadly serious business. It could literally cost some soldiers their lives. One wonders about the deadlines and contraints that lead some project manager to say "We don't have time for that fancy security stuff the designer wants to include, and what backwoods dirty militant is going to have the brains to do go after our drones. We'll worry about security in the next version."
SOA and Web Services allows quick and easy exposure of important system and application functionality. Integration can be fast and easy. Security and control are seen as overhead, and frequently avoided by the development team just trying to get the job done (under tight time and budget constraints).
An example: A major annuities (insurance) application for a top 10 insurance company needed to be connect to the customer service web site. A series of web services were quickly created, adhereing to standards for transaction and data formats. But, SSL was avoided because of concerns over processing overhead. Basic clear text security was placed on the services, mostly to prevent accidental connection between test and production servers.
Two years later the application was moved from one outside hosting vendor to inside the company network, but the web servers were placed into the DMZ (the network zone allowing access from the internet). Because web services commonly route through the web server, this meant that the unencrypted clear-text password services were now routing out from the company network to the internet, then back in to the DMZ. Meaning company business traffic was traveling unencrypted over the internet.
- Encrypt your data! Encryption overhead is (with today's processors) minimal, and you can never be sure exactly what path your service may travel (now and in the future). Even further, much hacking (sniffing) occurs from inside the network, from an employee or accessing a company network port.
- Service access control is critical! Obscurity is not security.
- Validating the source of requests is also important!
Security doesn't happen accidentally or by itself. It has to be planned, will require some tools (such as Amberpoint or IBM Datapower or Intel SOA Expressway), time and budget.
After all, you don't want the enemy watching your survellience video. Or the hackers accessing your business transactions.