The demand for information security professionals, which already high, will surge in the next few years. Finding trained security professionals to meet the demand will be challenging, but businesses can ease the burden by training developers to write more secure code.
There are about 2.2 million people working as information security professionals today, says Hord Tipton, executive officer for security education and credentialing organization (ISC)2 and former CIO of the U.S. Department of the Interior. That number is expected to grow to 4.25 million by 2015--assuming there are enough skilled security professionals to meet demand.
Already, access to enough IT staff with security expertise is particularly tricky for organizations of all sizes. In a study released earlier this year, IT industry association CompTIA found 41 percent of organizations reported moderate or significant deficiencies in security expertise among IT staff. On average, CompTIA says, organizations were about 30 percent short of their headcount devoted to security.
And according to the U.S. Bureau of Labor Statistics (BLS), which added the category of Information Security Analyst in 2011, unemployment for people employed in the category stands at 0 percent.
"The demand for security people in organizations will be even higher," Tipton says. To meet the demand requires a multipronged approach in which not just (ISC)2 and security professionals but businesses and their executives have an important role, Tipton explains.
Write More Secure Code
One important preventative thing businesses can do to ease the pressure is to make sure developers write more secure code in the first place. Why are companies still producing software with vulnerabilities?" Tipton asks. "Why do we have to keep patching it?"
The answer, Tipton says, is that executives need to prioritize writing secure code upfront and make sure that developers are trained to do it. Additionally, organizations need to revise their lifecycle approach to give security professionals a seat at the table when project requirements get determined, not after.
"The business looks for functionality, user friendliness," Tipton says. "Security is an afterthought. People that are in the security portion of a company have a difficult time getting their recommendations in after the requirements are already set."
SQL Injection Still Highest Root Cause of Data Breaches
A study by research firm the Ponemon Institute of more than 800 IT security and development professionals earlier this year found that most organizations don't prioritize application security as a discipline, despite the fact that SQL injection attacks are the highest root cause of data breaches. The second-highest root cause is exploited vulnerable code in Web 2.0 and social media applications. These types of attacks have been around for years, and, in most cases, are relatively easy to defend against.
"Security, per se, is not a complex science," Tipton says. "Most of it is just the basic controls, the sound principles of security, which we have proven in 23 years of credentialing. They actually work and haven't changed very much. Eighty to 90 percent of breaches are caused by simple attacks, and 96 percent of those breaches could be prevented with basic security controls."
Despite the data breaches resulting from hacked or compromised applications and the lack of compliance with regulations, 38 percent of security practitioners and 39 percent of developers say less than 10 percent of the IT security budget is dedicated to application security, according to the Ponemon Institute's study.
"We set out to measure the tolerance to risk across the established phases of application security, and define what works and what hasn't worked, how industries are organizing themselves and what gaps exist," says Dr. Larry Ponemon, CEO of the Ponemon Institute. "We accomplished that, but what we also found was a drastic divide between the IT security and development organizations that is caused by a major skills shortage and a fundamental misunderstanding of how an application security process should be developed. This lack of alignment seems to hurt their business based on not prioritizing secure software, but also not understanding what to do about it."
"We basically found that developers were much more likely to think there was a lack of collaboration," Dr. Ponemon says. "The security folks, on the whole, thought the collaboration was OK. I think that one of the biggest problems is that the security folks think they're getting the word out on collaborating or helping, but they're not doing so effectively."
In other words, Dr. Ponemon says, the security organization writes its security policy and gives it to developers, but the developers, by and large, don't understand how to implement that policy. The security organizations think they've done their job, but they haven't managed to make their policy contextual for developers.
Application Security Training Required
"We find that process has no bearing whatsoever on the ability of an organization to write secure code," Dr. Ponemon says. "It doesn't take any longer to write a line of secure code than it does to write a line of insecure code. You just have to know which one to write."
But knowing which line of code to write seems to be a large part of the problem. The study found that only 22 percent of security practitioners and 11 percent of developers say their organization has a fully deployed application security training program. Fully 36 percent of security practitioners and 37 percent of developers say their organization had no application security training program and no plans to deploy one.
Ed Adams, CEO of security firm Security Innovation, says he believes providing that education will go a long way toward helping organizations secure their applications and minimize the risk. This is more of an education problem than anything else," Adams says. "In the late 90s, everybody was putting their applications on the web. But they kept on crashing. It was really a performance problem: The developers didn't know how to code for performance. Amazingly, that's what's happening in the world today. Organizations are buying application security tools before they get application security training. You have to get trained on the technique first."
Writing secure code the first time is also a good way to save a bundle of money, Tipton says. Write better applications," he says. "A company pays 30 times as much to bolt security on after the fact. IBM claims it's 100 times."
Opening the Door to Security Careers Is Childs Play
Meanwhile, in addition to its series of security certifications, (ISC)2 is doing its part to bring a new generation of security professionals into the field. "Kids coming into the workforce today know 10 times as much about computers as previous generations," Tipton says. "They are prime candidates for sophisticated work in security. We have to create a pipeline that starts in schools-from colleges to continuing education."
In fact, (ISC)2 is going well below the college level and is venturing into the grade school environment. Its Safe and Secure Online Program for children ages seven to 14 is primarily designed to help children experience the Internet in a safe and secure manner, but one important side effect is that it exposes them to the possibility of security as a career.
"It opens the door," he says. "We explain to the kids that this is a very, very viable career path. Salaries are high. Unemployment is zero. And it's challenging. So many of them like puzzles and games that it really resonates."
Thor Olavsrud covers IT Security, Big Data, Open Source, Microsoft Tools and Servers for CIO.com. Follow Thor on Twitter @ThorOlavsrud. Follow everything from CIO.com on Twitter @CIOonline and on Facebook. Email Thor at email@example.com
Read more about careers in CIO's Careers Drilldown.
Copyright 2009 IDG Magazines Norge AS. All rights reserved
Postboks 9090 Grønland - 0133 OSLO / firstname.lastname@example.org / Telefon 22053000
Ansvarlig redaktør Morten Kristiansen / Utviklingsansvarlig Ulf H. Helland / Salgsdirektør Jon Thore Thorstensen