IRS trains devs to build in security from the start
Connecting state and local government leaders
Code analysts at the IRS are stepping in to help train software developers and project managers to make their software more secure from the beginning of the coding process.
Government IT security shops find themselves in an untenable position: their security staff sees software only after it has been completed -- when programming flaws already have been built in.
The situation has led to a “crisis in cybersecurity proficiency” in the government’s software development process, said James Lindley, head of the Penetration Testing and Code Analysis (PCTA) team at the Internal Revenue Service. “We don’t build security in,” he said. “We just advise and audit.”
The reason? “There is no money for those who build software to build security,” Lindley said. Consequently, the government spends $6 billion a year on complying with the Federal Information Security Management Act, without actually improving cybersecurity.
The IRS is responding to the challenge by assembling a team of 600 code writers and educating them and the project managers in secure development practices. It is not just about including security in the code, it is about good development processes, Lindley said. “Poor quality software will be unsecure software.”
Lindley outlined his team’s work in fostering project management for secure software at the FOSE trade show in Washington. D.C., Thursday.
The task of educating developers and project managers is complicated by the fact that development is a complex process, requiring different skill sets at different stages, from developing initial requirements to actually writing code. There is too much for any one person or team to master, and the personnel in a large project should be constantly changing if it is being managed properly.
Security is the product of good practices at every stage in the process, and each phase is critical to the ones following. No amount of good coding can fix a flaw in the design of an application. If security is left out in the early stages, it becomes increasingly difficult to add back in as the project progresses. So secure development training is needed for each of the components of the team.
Lindley compared software development to skilled trades involved in building a house. No one person does it all. What begins with an architect passes on to engineers and eventually to carpenters, plumbers and brick layers.
In the same way, there is no single skill set for software development and no place to learn everything. A college degree can give a good overall background, but individual skills are learned on the job, Lindley said. This means security training must be provided for each separate trade.
One of the reasons security is not routinely included in the training of each software trade is that there is no body of law providing for liability and accountability for poor software, Lindley said. If there were standards and codes under which a developer could be taken to court, security would begin to be built in to software.