response to RFC by M.Caughron

The summary report does not use the word "software" anywhere, but this is one of the highest risk pieces of Federal infrastructure. Application and software security has largely gone ignored for many years, with the exception of scan-and-patch cycles, whereas network-level mitigations have had billions spent on them with insufficient results. The need for software security and application-level mitigations is critical and this critical need is, I believe, underserved in this report to the president.

_What are major attributes that are missing from the targeted vision? (Appendix A, Appendix B)_

Appendix A should specifically call out the following:
1. the practice of creating attack trees
2. integration of abuse cases in agile development methodologies.
3. use of static analysis tools in all software development
4. fuzzing for any software that is accessible on the network and developed in any language that can directly address memory space

It would be nice if application whitelisting specifically mentioned code signing.

Technologies that address the above four areas should be fast-tracked in FedRAMP so that they can be made available without a 2+ year wait time.

_What are major attributes that should not be included in the targeted vision? (Appendix A, Appendix B)_

Zones in the cloud need to NOT be dependent on merely Amazon or a single-service provider but should be able to be hosted across multiple cloud providers. The need to get off of Amazon dependencies is significant and I believe that failure to load balance away from AWS is a threat to national security.

Discussions of EINSTEIN (1-3a) can be more effectively replaced with monitoring systems that are application-specific and run by each agency.

The phrase "separate their security stack from their application stack" is clearly not addressing software security, wherein logical controls are necessarily a part of each cloud component.

_Are there any missing or extraneous tasks in the plan for implementing network modernization & consolidation?_

The focus on networks in opposition to software is unfortunate.

Consider the "security" goals of a carrier such as AT&T versus the security needs of the companies or individuals who make use of their network. The security goals of privacy and confidentiality of the users of a network are at odds with the security goals of the network operators. More specifically, carriers merely want to keep the network up, whereas companies and individuals on the network actually want to safeguard their data! The network-centric nature of EINSTEIN and network-focus on the solutions proposed displays a carrier mindset which is not likely to be effective.

For years, companies have thrown technologies at networks - from VPN snake oil to log-everything-in-sight approaches, and yet we are still at a place where vulnerabilities in infrastructure are pervasive and largely unaddressed.

_Are there any missing or extraneous tasks in the plan for implementing shared services to enable future network architectures?_

Bug bounties and crowd-sourced vulnerability assessment programs are a nice start will need to be supplemented with direct technologies to systematically identify vulnerabilities.
Static analysis is an absolute requirement for software on any networked system and all software operating in the cloud.
Fuzzing is necessary to find exploitable flaws before hackers do.

Static analysis and fuzzing area areas where agencies can cooperate on shared technologies.

The clearance system needs to enable software security experts to freely exchange information related to vulnerabilities in a write-up, read-down fashion if necessary. Making the best technologists wait for months or years for clearances means we losing valuable expertise at a time it is needed most.

_What is the feasibility of the proposed acquisition pilot?_

Cooperation is network-centric and not focused on vulnerabilities and software.