Report: Building in security in government software
Fortify released a new report, “Building in Security in Government Software,” which describes the growing threat of application security attacks and key steps government agencies should take to implement a comprehensive Software Security Assurance (SSA) program. This report is intended to serve as a guide for all government entities to build security in and provides some best practices for addressing software security and implementing code reviews.
The report provides examples of how application security has been embraced within the private sector with mandates from the Federal Financial Institutions Examination Council (FFIEC) and the Payment Card Industry (PCI) Security Standard Council.
It also describes how the government has made some significant strides in implementing policies and processes to address application security with examples such as the Department of Homeland National Cyber Security Division’s Security Software Assurance Program and the National Institute of Standards and Technology (NIST) Software Assurance Metrics and Tools Evaluation (SAMATE) which has reviewed various application security technologies.
According to the report, to mitigate future software security threats, the federal government and individual agencies need to follow the example set by the Air Force and create an aggressive SSA initiative. The new CTO must require all government entities to build in security first, not layer it on later. This new “culture of security” should address software that is contracted, outsourced, Software-as-a-Service (SaaS), or open source as well as internally developed, and require a reallocation of resources and even a new way of thinking.
Some additional best practices outlined in the Fortify report include:
Organize effectively for security by appointing:
- A Leader: Someone must be accountable for the entirety of the security process, from the legal aspects of vendor contracts to education of staff, to vulnerability assessment of software.
- An Expert: Organizations should designate an application security expert who is directly accountable for security processes, technology, and staffing.
- A Gatekeeper: Organizations should also appoint a security expert to identify the risk-based security processes and vulnerability metrics that are expected, then inspect and enforce the appropriate software security standards. The Gatekeeper will set in place metrics and then maintain, monitor, and report on compliance with standards, even-and especially-if the security issue never gets fixed. Organizations should empower the Gatekeeper to halt the release of any product or deliverable that does not meet security minimums.
Implement preventative-not operational-security standards: Organizations not only need standards on how to use software but standards for how to develop, contract or procure new software. The various existing state and federal and private guidelines should be unified, and the best used as a baseline for all.
Define a secure acquisition process: Beyond choosing the platform or the specific role of the software in the organization, care must be given that third party software, be it purchased, contracted or open source, should undergo intense security scrutiny. Third party software vendors should spell out what its developers have done to secure the software. Vendors should be contractually accountable for all their software. Open source should not become a default choice because of its low cost-cheap does not make it low risk.
Conduct comprehensive training: Organizations should plan to hold project and computer language-specific training workshops necessary to enhance the project managers and developers understanding of software security and get the developers to adopt the security best practices. Education is key to addressing security issues in all phases of the software development process and organizations should train software development managers on what your metrics mean. Train developers on how to fix security problems, and leave no room for anyone to deny understanding security requirements.
Cleanse legacy systems: Organizations should also engage in a campaign to cleanse legacy applications of security issues, or replace them with more secure code.