With software becoming increasingly essential to today’s government and military, and digital transformation initiatives among the highest priorities within the IT departments of government organizations, there is a strong desire across the government to develop and implement new applications quickly.
However, both the military and civilian agencies – alike – must think about the current security landscape, where hackers are constantly working to compromise sensitive civilian data, encrypt systems in extortion schemes, or simply take down government systems.
In this environment, expediting the software delivery lifecycle (SDLC) simply cannot be at the expense of security. And, creating trusted, secure, hardened applications that can be implemented anywhere with a continuous Authority to Operate (ATO) is the goal for all development teams.
Thanks in large part to new technologies, advanced security testing solutions, and a new focus on training, that dream can be a reality. We recently sat down with Pete Chestna, the new CISO at Checkmarx, to talk about how a continuous ATO can be achieved, and which new solutions are making it possible.
GovDevSecOpsHub (GDSOH): You recently joined Checkmarx as CISO and have deep experience in cybersecurity. Do you see a difference between public and private sector security threats and needs?
Pete Chestna: They are certainly similar but the motivations and ability to execute are different. The public sector is under the heaviest and most sophisticated APT from nation-states. Vendors are similarly threatened with an emphasis on those that sell to the military.
The public sector is motivated to protect citizens and national interests. The private sector must be more cost-conscious and balance risks against the protection of its customers. These lines are blurring as the government makes more use of COTS as evidenced by the recent SolarWinds and Constant Contact incidents. These Trojan-type attacks will continue to grow in prevalence.
GDSOH: Today’s government agencies are pushing to get mission-critical applications out to users faster and faster. And we all know the old saying, “haste makes waste.” What cultural, organizational, and operational changes can government development teams and military software factories make to ensure they’re developing applications quickly, but also securely?
Pete Chestna: ATO or Certificate to Field (CtF) takes a long time to complete and delays mission capabilities. These controls should be applied and enforced differently. The use of pre-approved hardened containers would be a good example.
The government can look to the advanced practices in use in the private sector that allow for delivery speed while still assuring the security of the application. This includes enabling developers to be more autonomous and updating contractual language to allow the same for contractors. This also includes measuring based on well-defined demonstrable outcomes.
“Security tooling has matured greatly over the last 15 years. The time to results has been greatly reduced and new tools and capabilities are brought online regularly to help with newer risk vectors…” – Pete Chestna
They should lean into efforts such as the Army Soldier-led Software Factory and the USAF Digital University to upskill and empower existing personnel. From a practical point of view, leaning into a joint task force model is preferable to a ‘roll your own’ mentality. Leverage the best and brightest to develop one solution that can be leveraged by all.
Lastly, I would say that finding ways to build software that is resilient and anti-fragile and can be deployed in existing public clouds would reduce cost and complexity as well as boost the available capabilities offered by cloud vendors.
GDSOH: All the branches of the military and disparate military organizations seem to be establishing their own software factories tasked with creating applications in hardened containers with a continuous ATO and the ability to deploy anywhere on demand. But the military has always prized security and mission assurance above practically everything else when it comes to IT services and applications. What technologies are enabling the creation of these applications by software factories? What tools and solutions are necessary to ensure that these applications are secure and assured?
Pete Chestna: Open source, third party software, and shared source, second party code is a key enabler for rapid application development. Another is the growth of Infrastructure as Code (IaC). These cut down lead time and provide fundamental capabilities without reinvestment.
Security tooling has also matured greatly over the last 15 years. The time to results has been greatly reduced and new tools and capabilities are brought online regularly to help with newer risk vectors, such as IaC.
“The government can look to the advanced practices in use in the private sector that allow for delivery speed while still assuring the security of the application. This includes enabling developers to be more autonomous and updating contractual language to allow the same for contractors.” – Pete Chestna
Also, shifting the usage of the tooling left reduces the cost and complexity of secure software development.
GDSOH: Automated security testing has been touted by many government application development leaders as the key to shifting security left and baking security into the SDLC. What is preventing greater adoption of this approach to realize the value?
Pete Chestna: Some of the problems with adoption come from requirements that conflict with the available deployment models. There are many air-gapped environments that require on-premises installation of the tooling. In other cases, the data from the scan must also stay on-prem. There are now solutions available for many of these requirements.
Other adoption problems stem from long-held perceptions of the tooling slowing down the development cycles or having large numbers of false positives. The vendor community must do a better job communicating the vast improvements that have been made in tooling speed and fidelity in recent years.
GDSOH: What should government leaders be looking for in their security testing solutions? Are there characteristics or features that they should be looking for that could help make the SDLC faster and more secure?
Pete Chestna: The priority should be on actionable results from low false-positive rates. Developers do not want to waste time chasing ghosts. Secondly, deep and easy integration into the tools that developers use. Allowing the developer to remain head-down and working is critical.
Lastly, they should be looking for help in remediation efforts. Your vendor should provide solutions to help the developer quickly understand and address findings from a scan.
“Developer training is essential because traditionally they have not been taught how to code securely. That lack of training leads to mistakes that force rework. Prevention of rework is the key to speed.” – Pete Chestna
Integration with a training system with pointed remediation guidance from the results will also decrease the time to fix. This has the added benefit of training developers to not make the same mistakes into the future.
GDSOH: We recently attended an ATARC Webinar with several government software development leaders. One of the interesting takeaways was the role of culture and training in secure development and DevSecOps adoption. Why is security training essential for application developers? What types of training are most effective? Do developers – either in the public or private sector – currently receive the AppSec training that they should receive?
Pete Chestna: Developer training is essential because traditionally they have not been taught how to code securely. That lack of training leads to mistakes that force rework. Prevention of rework is the key to speed. The most effective types of training provide directed guidance to prevention and/or remediation. Additionally, the training should be short and sweet giving you what you need, when you need it.
To use developer training time effectively, use your scan results to inform the education plan. It is the clear indication of what developers struggle with. Once training has been assigned and taken, you can measure the effectiveness by looking at the feedback from downstream scans.
In many companies, training is a checkbox and not a tool. There are few organizations that are exceptional in this area.
Think about measuring the impact of your education program on the effectiveness of your developers. If you are training on the most important things, your developers should make less of those mistakes. If they are making less mistakes, then you are creating a very mature AppSec program.
Measure the savings in terms of rework and show that to your development leaders. They will lean hard into your efforts if you show them that it makes a difference in velocity.
