GSA / GSA/modernization

Comment from email: Comments re: IT Modernization

Open
#93 0 comments 0 reactions 0 assignees View on GitHub
Public comment
Dominant language
CSS
Stars
59
Forks
8
PR merge metrics
No merged PRs in 30d

Description

_[Editor's note: The original richly formatted email didn't translate well to text/Markdown, so I have also attached a .docx version based on a copy/paste of the email's original formatting. The comment author did not create the .docx, but it best replicates the formatting and is the most readable.]_

[Jerome Kemp - Comments re- IT Modernization.docx](https://github.com/GSA/modernization/files/1323157/Jerome.Kemp.-.Comments.re-.IT.Modernization.docx)

ATC,

Great (draft) report! Once the (final) version is approved, the planned actions should help agencies make considerable strides towards more cost-effectively managing their systems and improving their security posture.

Responses to Key Questions:
1. What are major attributes that are missing from the targeted vision? (Appendix A, Appendix B)

How about advocating that system development activities seek only web-based solutions? The thought behind this is that the users (i.e., agencies or public) wouldn’t need to run a particular platform (hardware/software) to access the functionality being provided. Applications that are platform agnostic could be utilized by a larger audience.

On a related note, how about encouraging agencies to utilize IT platforms, especially at the enterprise level, that are different from the platforms their users run on their desktops. As an example, if the users run MS-Windows, having the enterprise systems run something other than MS-Windows (e.g., Unix, Linux, etc.) provides understated protections to the organization. For example, malware a user’s computer might contract cannot easily propagate throughout the agency if the enterprise-level systems (e.g., file servers, print servers, domain controllers, etc.) are a totally different platform.

Was any thought given to recommending the use of Open Source software? In some circles there seems to be an aversion to using software that, in some instances, does not have a specific vendor supporting it; however, Open Source software has its advantages, too:
-no license costs/limitations
-flexibility for agencies to build upon the Code to tailor software to address their specific needs
-all Code is open for detailed security reviews (versus COTS applications that have already been compiled)

I understand that this Report focuses on the technical aspects of Federal IT; however, one component that seems to be largely absent is the ‘people factor.’ The people who use and maintain the Federal IT infrastructure are the most valuable resources we have. By the same token, these individuals can also be our weakest link when it comes to cybersecurity. For Federal IT to rapidly modernize, the IT workforce must keep up. At a minimum, personnel who design, develop, test, deploy and maintain Federal IT systems must have the necessary training and industry-recognized credentials (appropriate for their field). OPM has been making headway on initiatives to ‘professionalize’ the Federal IT workforce, especially with regards to cybersecurity skillsets. Perhaps OPM’s efforts/program should be cited in this Report so the hardware/software activities and workforce activities are kept in sync?

2. What are major attributes that should not be included in the targeted vision? (Appendix A, Appendix B)

I view these Appendices as a good baseline; however, it is a bit disheartening that these basic concepts need to be viewed as a ‘vision’ (i.e., something agencies should strive to achieve). There will be a number of agencies who view these particular targets as child’s play, because they have already achieved that level of maturity. Unfortunately, there are many agencies that will take years (even with careful hand-holding) to re-architect their systems to adhere to these baseline objectives.

3. Are there any missing or extraneous tasks in the plan for implementing network modernization & consolidation?

It was not clear which specific portion of the Report this question was referring to – no one section/appendix had that specific title.

4. Are there any missing or extraneous tasks in the plan for implementing shared services to enable future network architectures?

It was not clear if this question was referring to Section 3 (page 24) of the Report or Appendix C. The latter did not really appear to be a plan, but rather just an explanatory document. The former seemed like a good starting point, but not something that will really have a far-reaching impact on the Federal IT infrastructure. Minimally, I would have expected to see at least references to the Shared Services that DHS presently has oversight for – the Information Systems Security Line of Business (ISSLoB) designees (as designated by OMB) for Risk Management Framework (RMF) services and Security & Awareness Training. These Shared Services have been available from these OMB-designated agencies for almost a decade.

“CDM Phase 3 will … implement ongoing assessment and authorization” (page 25, 1st paragraph). We cybersecurity professionals have heard this statement before in sales pitches from vendors. The reality is that, as wonderful as some of those tools may be, only a small portion of the minimum security controls NIST mandates for Federal information systems can actually be monitored/evaluated via automation. There will always be a need for independent, objective, human evaluation of Federal IT systems, to include evaluations of the CDM infrastructure itself. It would be more accurate if that sentence read as follows: “CDM Phase 3 will report “what is happening on the network” and provide capabilities to identify and assess anomalies that may indicate a cybersecurity compromise while also providing inputs into each system’s ongoing assessment and authorization.”

5. What is the feasibility of the proposed acquisition pilot?

This pilot is definitely low-hanging fruit – a good way to chalk up quick wins amongst agencies. I think what will be most critical will be what comes after this pilot. If the ‘next steps’ are not spelled out at the onset, once the email acquisition pilot wraps up, momentum may be lost that could have been used to tackle the ‘next’ initiative. What are those next initiatives?


Potential Spelling/Grammatical Errors:
Since this Report is a draft, below are some items you may want to look at for potential corrections. The Page Numbers referenced are from the PDF version of the Report.

Page 5, 3rd Paragraph, Last Sentence: Between “…impediments surfaced…”, consider adding the word ‘that’ or ‘which’.

Page 10, 3rd Paragraph, Last Sentence: Perhaps change the word “alight” to ‘align’?

Page 17, Last full Paragraph, 3rd Sentence: Between “…with same…”, consider adding the word ‘the’.

Page 17, Last full Paragraph, 4th Sentence: Add the letter ‘s’ to “variance” (to make it plural).

Page 19: It’d make sense to use the ‘SaaS’ and ‘IaaS’ acronyms here as these are very commonly used in the Cloud computing world.

Page 24, 2nd Paragraph, 1st Sentence: Consider changing “should” to ‘will’ to align with the verbiage used in the other sections.

Page 25, Last full Sentence: Consider changing “DHS ATO” to ‘CDM ATO’ or ‘CDM SSP ATO’. Labeling it “DHS” is perhaps a bit too broad.

Page 35, Intro to Figure 3: Consider changing “…low-security system…” to ‘…low security impact system…’ or ‘…low impact system…’.

Page 41, Last Bullet: Change “manufacturer’s agreement” to ‘Manufacturer’s Agreement’ (to match the case usage that appears on Page 42).

Page 46, Actions #1 and #4: Standardize on either “The President” or “POTUS”, but don’t utilize both.

Page 48, Action #16: Change “spring” to ‘sprint’.

Page 48, Action #17: Change “do” to ‘does’.

Page 51, Action #38: Consider changing “DHS ATO” to ‘CDM ATO’ or ‘CDM SSP ATO’. Labeling it “DHS” is perhaps a bit too broad.

Page 51, Action #41: Strike the 2nd occurrence of the word “to”.


Other Commentary:
Duplicate Systems
While I agree that this Report will bring about positive change, I believe it may not go far enough to really bring about huge benefits to the Federal government. The planned actions seek to address what are mainly symptoms of high costs and lackluster security while not addressing root causes. The biggest pitfall to cost effective and secure management of information systems in the Federal space is that everybody is “doing their own thing.” Each agency keeps reinventing the wheel over and over again. My organization performs independent security evaluations for many Federal agencies. Time and time again we see very similar, if not identical, systems. The quantity of duplicate systems/functionality, even internal to some agencies, is staggering. Simply forklifting all of those systems to the Cloud will just perpetuate the duplication/redundancy problem. Perhaps a Data Call could be issued to identify potentially duplicate systems?

Shock and Awe
Want to really accelerate IT modernization? Establish a ‘Department of Information Technology’ and let that new Department handle all IT needs, as a service, for all Federal civilian agencies. Mere mention of this would likely illicit unpleasant responses, to put it mildly, from many agencies, but the eventual results would be undeniable. Establishing such a Department would:
-Reduce instances of redundant systems/functionality in IT systems
-Eliminate redundancies in some ‘overhead’ functions in agencies related to the management of IT systems
-Minimize occurrences of commercial vendors utilizing the divide & profit approach (i.e., selling the same software/licenses to multiple agencies)
-Ensure all systems truly follow best practices (versus each agencies’ interpretation of NIST/DHS requirements)
-Permit agencies to still retain Risk Management oversight for their data
-Permit agencies to focus on their core missions (HINT: No agencies were established to create/deploy/maintain IT systems)
-Prevent agencies from poaching IT talent, especially Cybersecurity professionals, from each other
-Permit the IT Department to treat other agencies as customers (i.e., be held accountable to established performance metrics)
-Minimize agencies from developing/deploying systems off in the shadows. (If new functionality was needed, they’d approach the IT Department.)
-Greatly streamline IT acquisitions
-Enable spectacular cost savings from bulk purchases of hardware, software and licensing
-Deploy (matrixed) IT support personnel across the Federal enterprise to provide onsite support (where needed)

Shared Service Centers
The Report makes many references to Shared Services, but only elaborates on (a future) one – SOCaaS. My organization has OMB designations under the Financial Management Line of Business (FMLoB) and Information Systems Security Line of Business (ISSLoB). The 1st paragraph, 1st sentence on Page 17 does not even mention OMB’s Information Systems Security (ISS) shared services. If agencies are being encouraged to leverage Shared Services, then agencies really need to know more about what is available. In all honesty, the OMB-designated Shared Services Centers (SSC’s) rarely ‘market’ their Fed-to-Fed services. Why? The SSC’s usually remain at capacity; bringing on additional workload from more agencies is challenging. What makes it challenging is that the missions of the SSC’s are not necessarily well understood by their parent organizations. When an SSC attempts to grow to accommodate workload from additional agencies, SSC’s often struggle to get permission to hire personnel, even though funding exists to do so. Oftentimes the parent organizations are undergoing budget cuts and hiring freezes, whereas the embedded SSC’s are attempting to grow, but get ‘painted’ by the same broad brush and get hamstrung by those same hiring freezes. As such, SSC’s are placed between a rock and a hard place – the SSC’s want to grow to accommodate new workload, but policies implemented by their parent organizations inadvertently prevent them from doing so. We SSC’s would love to see something (e.g., a clarification to M-17-22, an Executive Order or even text in this Report) encouraging parent organizations to give OMB-designated SSC’s the latitude to hire the personnel they need to accommodate funded workload. The full benefits of having SSC’s cannot be realized until SSC’s have the flexibility they need to do what OMB has designated them to do.


Feel free to contact me if you have any questions regarding my comments. Thanks!

Jerome Kemp, CISSP, CISA, CRISC
Manager, Security Assessment Support
OMB designated ISSLoB RMF Shared Service Center
GSA accredited FedRAMP 3PAO

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.