And once it is important for them they will just ask their normal IT people to add it as an 'extra' task, or they will just ask their current IT outsourcing companies to provide them this service.
As I posted in other threads. In the future, programmers will be much more programming 'secure' and Operating Systems will catch the problems with the installed applications, same for the webserver software. It's not going to be a fix in 6 months, but in a couple of years I see this happening. I already see a much bigger awerness with programmers than couple of years ago.
Which is a good thing. But the funny thing is. When we try to spread the word to be more infosec oriented, we're killing our own industry :-) So I would absolutely put infosec as an 'extra' skill. Just don't make it your 'only' skill.
I disagree with the latter points entirely. What OS/programming protection mechanisms are you referring to?
Compiler buffer overflow protection? That's been in GCC since 1997 and Visual Studio since 2003. Even in VS2012, this only detects some buffer overflow conditions:
http://msdn.microsoft.com/en-us/library/8dbf701c.aspx and there are always people that disable these safeguards.
DEP and ASLR? Check out the Corelan tutorials and course and/or the OffSec CTP and AWE courses. These make things more difficult, but they aren't complete solutions. There are utilities (i.e. mona.py) that automate a lot of the tedious, time-consuming work involved.
UAC? Users either disable it because it's annoying, and there's various ways to circumvent it already. I saw a new technique was released just a few days ago, and it's still on the front page Exploit-DB.
AV? Not even worth discussing.
And that's only "traditional" exploitation. From Windows 3.1, it’s taken 20+ years to get to a point where things can be described as "not completely broken" (at best). Do you follow Exploit-DB or lists such as Bugtraq? Vulnerabilities and exploits are hardly slowing down. Look at the recent Java problems, and there are regularly issues with Acrobat Reader and Flash, as well as a plethora of other third-party software.
There are also many other attack vectors that aren't even close to being remedied. Few organizations have controls such as NAC or DIA/DHCP Snooping that will prevent basic ARP Poisoning attacks. Windows hashes are still thoroughly broken:
http://passing-the-hash.blogspot.com/ And now it looks like the password hints can be grabbed along with the hashes, so Windows 8 actually makes cracking hashes easier:
http://blog.spiderlabs.com/2012/08/all-your-password-hints-are-belong-to-us.html The list goes on and on.
Additionally, those protections don’t do anything for logic flaws. Say a program runs as root/administrator and can issue system commands. If I find a way to execute arbitrary commands, none of those controls are going to prevent me from doing something like adding a new admin user. Blank SA and xp_cmdshell is a perfect example of this, and I’ve seen that on about a quarter of my engagements this year. The same thing goes with obtaining Tomcat Manager access (roughly the same frequency too).
You are also completely disregarding legacy systems and applications. These aren't going to be off of anyone's network in a couple years. I believe every internal penetration test I've done this year has had Windows 2000, and about a third of them have still had Windows NT4. Any issue that is present today could linger on for another 5, 10, 15, or more years. I’ve also seen instances where critical applications are stuck on unsupported OSes because the source code has been lost, and there’s no way to move on unless they recode from scratch. Ouch.
I think mobile and web applications are exploding and vastly outpacing security oversight. These are also introducing new vulnerabilities and attack vectors that aren’t nearly as well understood as traditional operating systems and thick-client applications.
The barrier to entry for those technologies is now lower than ever too. Pretty much anyone can get a web or mobile application going with minimal effort. Even if some novice developers have an interest in security, it’ll take them years before they understand it thoroughly. Most won’t care at all and will just focus on getting their app to work the way they want it to.
In general, the developers I’ve worked with (well into the triple-digits) are far from what you’re describing. I meet many that can’t even have a high-level conversation about buffer overflows, SQLi, XSS, etc. That’s not to say they’re not good at what they do. They could run circles around me when it comes to enterprise software architecture, algorithms, etc.; they just don’t intrinsically care about security.
Oh, and those blank SA and Tomcat manager systems? Usually developers. Thanks for not standing up an isolated/host-only VM to test on. I also love the fact that you have to run as administrator in order to code, and by “code,” I mean install unapproved software with weak configurations. Secure code aside, I regularly see developers weaken the internal security posture.
The security-conscious developers that have the knowledge and resources to code in a secure manner are a ridiculously small minority. The best applications I’ve seen are from small teams that have a very focused niche. They do one thing, and they do it well. On the other hand, I still regularly find SQLi, XSS, LFI, etc. in large, complex applications.
However, simply having “awareness” of vulnerabilities and exploitation is far from sufficient. Unless developers are willing to train, educate themselves, and stay current, it’s not ultimately going to be effective. That’s a lot of work for something that rarely factors into their annual performance reviews.
More importantly, getting developers on-board isn’t even the primary hurdle. Management still dictates the process. If they’re given deadlines that do not allow them to follow a proper SDLC or incorporate secure coding practices, security functional testing, etc., it’s simply not going to happen. I’ve seen places with huge development teams that couldn’t even run a quarterly fortify scan, let alone analyze it and actually correct the deficiencies. Until there’s an organizational/management shift in priorities and perspective, this situation just isn’t going to improve.
In conclusion, there’s simply no way everything is going to be magically secure in a couple years. Or 5. Or 10. Or the foreseeable future. If such magic bullet technologies were on the horizon, there would be a mass exodus of infosec professionals. No one would be willing to invest the time and money into increasing their knowledge and skills if they were going to be worthless in the near future. Instead, there is an insatiable demand for qualified workers, and many organizations are having a great deal of difficulty filling just one or two open positions. Everyone I know and have worked with feels like they’re scrambling to keep up and there is no end in sight.