I recently spoke with a mobile developer who mentioned that he was developing a banking application. When I asked him if the platform he was working with provided him with the tools he needed to develop the application securely, he mentioned that there was little to no documentation on the secure application programming interface (API's) that were provided by the Operating System. Moreover, to keep the footprint small and meet deadlines, steps in the software development lifecycle were often done insecurely. The reality is that when it comes to secure coding, we face two different battles.
First, when we don't understand the need for secure coding, we don't know to look for the API's that may be needed. A lot gets lost in the requirements phase, which makes for inherently insecure applications. Second, even if the developers are very security-aware, they may not have access to the technologies and tools they need to incorporate security into the application development process.
The reality is that we often don't know what we need in the position next month, let alone next year.
This dilemma is exacerbated in the mobile world, where there are a multitude of different platforms. Often times, an organization has the staff who have skills in one of the platforms, but it then outsources the alternate platform - and possibly even all of the mobile apps - to third parties. These third parties are rarely vetted for their ability to create secure code and almost always work outside the standard development and secure software lifecycles, leaving us to contend with unknown quantities in the mobile world. This is one reason that as a security community, we need to reach out to and encourage these third-party developers to broaden their skill sets to include security and adopt secure coding practices.
Take the recent release of Java 7. We are sure to start seeing job descriptions that state organizations are looking for 10 years of Java 7 experience. How is this possible when the technology is so new? This is a perfect example of employers having a need that does not even come close to matching the skill sets available on the market. The reality is that we often don't know what we need in the position next month, let alone next year. We're only able to recruit for technologies that are relevant at the point in time in which the job description was written. Given the lightning speed with which applications are being developed and deployed, the skills that are needed most are adaptability, flexibility and the ability to pick things up quickly. As a prospective employee or contractor, your ability and desire to learn quickly can be your biggest asset.
Hiring managers look for folks with tons of experience in new technologies, but these technologies emerge daily, and upgrade cycles are escalating. How can we possibly keep pace and build these skills to manage these new technologies into the people we need? The holy grail of a broad-based expert on many of these technologies is very difficult to build. This takes historical knowledge, training, an interest in the broader scope, but it also demands an investment of time, which is the enemy of the release cycle. Most frequently, due to the aggressive timetable most developers work under, employers neglect to invest in skills development, resulting in critical security, architectural, performance and quality mistakes.
While experience and skills on hot technologies are shallow in the current development workforce and an education on security fundamentals is needed, many developers do seem to take responsibility for their skills growth and are happy when their employers invest in them and support their professional development. The lack of security education in training classes, colleges, and on the job is still an issue, but fortunately, the gap is slowly closing. Evangelism from the security community is critical to helping developers and employers alike realize that on the job training in emerging technologies is the only way to foster the staff they need and to bring security into their development process.
Glenn Leifheit, CISSP, CSSLP is a Security Architect at FICO. He has worked in developing, managing, architecting and securing large scale applications for over 15 years. His day is spent rolling out an Enterprise secure software development lifecycle and managing PCI requirements as well as secure software reviews. Glenn is active in the Technology community as the Co-Chair of (ISC)2 Application Security Advisory Board, President of TechMasters Twin Cities, as an active member of IASA (International Association of Software Architects) and OWASP (Open Web Application Security Project) as well as a regional speaker evangelizing secure software.