How can you stay one step ahead in security for the cloud?

So you ran the final build on that new Web-based order and inventory program and handed it over to the QA team. The tests look pretty good and you get the go ahead to deploy. Now all you have to worry about is the marketing department hounding you to create a smartphone app and maybe something for Facebook, and every time you go to a meeting with management, someone asks what you’re doing about that cloud thing.

Your deadlines are always looming, there are always a few pesky bugs still in the code, and you could really use a few more people on your team. But you roll up your sleeves and get started on the next project.

Two days later, your network crashes, the entire database has been trashed, and everyone starts running around frantically trying to figure out what happened. Was it the firewall? The server? Some rogue virus? In the back of your mind you wonder if it might even be your new application. Eventually, the network guys figure out that it was a SQL injection attack. That’s when management starts asking, “Don’t we have tons of security? How could something like this happen?”

Well, the odds are very good the problem was in your code.

Depending on whose numbers you believe, 60% to 90% of all security attacks come in through websites, and a good proportion of them are SQL injection attacks because they are remarkably easy to launch—if your code isn’t written correctly. (For a good article on how SQL injection attacks work and how to prevent them in your code, check out Colin Angus Mackay’s article “SQL Injection Attacks and Some Tips on How to Prevent Them.”) {http://www.codeproject.com/KB/database/SqlInjectionAttacks.aspx}

The growing list of security issues is long and seemingly insurmountable. Attacks can target programs, data, websites, cloud-based applications, even computer-controlled machinery. They can be viruses, worms, Trojans, denial-of-service attacks, SQL injection attacks, or highly sophisticated multi-pronged attacks. They can come in through poorly deployed firewalls, stolen or lost laptops or smartphones, sloppy programming practices—let’s say that again: sloppy programming practices—wireless networks, infected memory sticks, public-facing websites, easy-to-guess passwords, insecure APIs, outdated programming frameworks, operating systems, third-party software or components, infected media files, or even an unlocked window in your data center.

Attackers include everything from lone hackers, groups of hackers, disgruntled employees, simple employee mistakes, industrial espionage, cyberterrorists, even governments. (And just because you don’t work for the military doesn’t mean you are safe; you could become a casualty.)

The attacks can be targeted or indiscriminate, sophisticated or through sheer brute force. Their intent can be to steal, corrupt, destroy, subvert, or modify data, programs, or IP. They can also intend to disrupt, embarrass, or simply prove that it can be done.

But you aren’t a security expert, you’re a programmer. You get paid to write code, not to worry about security. The trouble is, like the scenario above, an amazing number of security vulnerabilities start with the code you’re writing (or the tools you are using, or the framework your code runs on, or even the security compliance standard you already have to adhere to). Now, even the tightest code is no guarantee that someone won’t leave their laptop at the gym or open an infected file or guess your boss’ password is ”bigcheeze,” but writing solid code can give your organization a better chance of defending against attacks.