CAST - Response to Federal IT Modernization Report

[Inlining a best-effort version of the attached comment below. If there were links in the original, they are not maintained in the below version. Download the original attachment in the issue above to see the original comment.]

To: The American Technology Council

From: Lev Lesokhin, EVP Strategy & Analytics, CAST, Inc.

Re: Report to the President on Federal IT Modernization

Date: Wednesday, September 20, 2017

Dear Mr. Liddell, Honorable Duke, Honorable Mulvaney, Honorable Mattis, Honorable Ross, Mr Horne,

Thank you for the opportunity to comment on your implementation plan for Federal IT Modernization. This report provides a good framework for addressing the network and Cloud initiatives that the Federal government needs to undertake in order to modernize IT operations. There are some interesting architectural aspects to the proposal in the appendices. There are a just a couple of areas we would like to explore in this comment letter.

The fundamental focus of the report to the President is on network and Cloud, the modern-day version of infrastructure. The security industry has been focused on these layers of the OSI stack for years. In fact, Gartner reportedi recently that the spending across industry on perimeter security to application security has been 23:1. In the same report, we can learn that 84% of attacks now occur at the application layer. This has only increased over time, and has been confirmed by many unfortunate events that we’ve experienced of late.

While there is some mention of application and data security in Appendixes A and B, it feels that the focus of this effort is not adequately centered on application and data. This is especially true as one considers the fact that truly to modernize Federal IT, we must tackle the complex legacy applications that run on the network and infrastructure to provide services to citizens and warfighters. The intensive and growing complexity of these applications and the manner in which they are sourced, drives an overwhelming percent of IT budget towards sustainment, at the expense of new digital government initiatives.

Thus in this response, we would like to address the first question of the RFC, as to what’s missing in the targeted vision. We see four key areas missing adequate treatment:

1. Data Protection by Application Design

There is a section in Appendix B that describes a runtime data protection scheme that can be implemented for the HVAs being managed by the agencies. This is a legitimate approach that can be applied, though sometimes at the expense of performance, as the report also mentions. There is also an opportunity to build secure data management into the application directly, at the software architecture

level. This can be done in a more fundamental way, such that the performance tradeoff is not so great, if even present at all. By architecting data protection into the application, and then using automated architecture assessment to check that new releases conform to the target architecture, data can be secured at the application level.

This approach goes hand in glove with application modernization. A great deal of modernization activity has to do with either rewriting components of existing solutions, or rearchitecting them to fit into Web Services, Microservices, or at least in a newer technology. When rearchitecting legacy capabilities, it’s much easier to introduce new design concepts to ensure that sensitive data is treated securely at all levels.

2. Application Security Measurement

We do notice the mention of Application Security in Appendix A, alongside multiple other practices such as encryption, testing, and threat modeling. Turning Application Security into a true practice, beyond just a “paperwork exercise” is a formidable goal that we believe can only be accomplished through measurement. If attainment of security scores is a KPI that’s in management performance plans, this becomes a very real exercise indeed. Standard metrics can be used to track the security health of applications, and to benchmark the organization or at least a specific application to industry peers. The only specific standard to measure application security that we’re aware of is the one published by CISQii (The Consortium for IT Software Quality), which also publishes standards for reliability, performance efficiency and maintainability, in line with ISO 25000 definitions.

3. Thinking Beyond Security

The software assurance establishment, led by DHS, NSA, NIST, MITRE and SEI have long ago come to the conclusion that software security is highly related to overall software quality. Other quality characteristics, especially reliability, actually share common concerns (memory management, exception handling) that could either bring the application down inadvertently, or be used by malicious actors to the same effect. Reliability is also a large sustainment cost for Federal agencies. Any performance or stability issue in live use generates Sev 1 demands on the operations team, which often causes application developers to be pulled from current projects to fix old problems. Experience shows that this can be decreased significantly, while working hand in hand on security problems as well.

Further, the performance efficiency of software drives its scalability and how fast it responds to user inputs. We have seen some public-sector agencies save significant sustainment dollars by reducing MIPS load through making applications fundamentally more efficient. Inefficient applications moved to Cloud will also have a large CPU footprint, eventually running up the operations invoices for the government.

Lastly, maintainability of software is a direct driver of sustainment cost. The more maintainable the software, the easier it is to sustain, requiring fewer resources in that area. Also, with maintainability comes adaptability of software – ease with which it can be enhanced. The more maintainable the software, the easier it is to modernize, restructure, fix or simply replace. Modernization is not a onetime event, it’s an ongoing challenge. The ATC members would be well served to look at current actions that impact long term capabilities in Federal IT.

4. Application Assurance Through Acquisition

When it comes to software in Federal IT, it is almost exclusively acquired through third party vendors and contractors. Acquisition is driven by the Contracting Officer, COTR, and various other procurement stakeholders who support the agency CIO’s organization in specifying contract requirements for government contractors. Despite some bright and loud voices in the software assurance space in the Federal government, it is still very difficult to place explicit assurance requirements into contracts. It requires strong alignment between the CIO’s team and the acquisition team. Both need to understand the possibility of measuring software outcomes to a standard, and have to be motivated to push on their contractors to implement such standards.

If the ATC report is able to provide impetus to agencies to implement commercially available standards, such as CISQ, to measure the quality and security of the applications they are acquiring, this will go a long way to build security and flexibility into government IT. This is a fundamental “left shift,” in industry parlance, to specify the lowest technically acceptable level of software upfront, before a single developer cracks open their IDE on behalf of the US citizen.

I realize this is only a high-level treatment of the issues pertaining to Federal IT applications as we see them at CAST. Our specialization for 25 years has been in helping large organizations build better, more bulletproof, and more flexible software, so this is a topic of great passion for us. I remain at your disposal for any further questions or discussion you would like to have on the above referenced topics.

Respectfully submitted,

Lev Lesokhin Executive Vice President, Strategy and Analytics

CAST, Inc. 321 W44th Street New York, NY 10036 (212) 871-8330

i Gartner Research, 2014, Stop Protecting Your Apps; It’s Time for Apps to Protect Themselves

ii Consortium for IT Software Quality standards; http://it-cisq.org/standards/

GSA / modernization

CAST - Response to Federal IT Modernization Report #49