CISA Funded Institute Published Good Starting Point for Securing CI/CD Pipelines; Deadline for Government Agencies Securing Management Interfaces Was Not Met

The threat scenarios in this document are good starting points for tabletop exercises. CI/CD pipelines and DevOps processes are often tightly coupled with business processes and very different between organizations. A really good playbook to protect CI/CD for Business/Agency A might not work at all for Business/Agency B.

The report explains the conditions, threats, and issues in language that is easy to understand, and can help you build understanding of the issues without mentioning Log4-J or SolarWinds. The recommendations, including validation of code signatures, using accounts with limited lifespan, MFA, and keeping systems and services patched/updated are a conversation you can have with your teams to see where you can raise the bar as well as better understand your developers’ needs.

If adversaries gain access to a software developer’s environment, then undoubtably bad things can happen. The same is true if they gain access to any organization’s enterprise. The guidance published by CISA and NSA is useful, but first, adopt and implement an established cybersecurity framework (i.e., NIST CSF, NIST 800-53, CIS) for the entire enterprise.

BOD 23-02 had a short timeline, and the deadline went whizzing by on Tuesday. While CISA is circling the wagons to enforce the required change, make sure that you’ve covered this. Those exposed management interfaces are like candy to a baby, and when staff says something along the lines of them not being able to be found, remind them that with tools like Shodan, it’s very easy (trivial) to find them.

The Censys research highlights a gap between security directives issued, and action taken by FCEB agencies. The cause for this gap could be: 1) not knowing one’s environment; 2) mission impact; 3) other priorities; or 4) general indifference to the directive. Several of those causes have merit and a discussion should ensue between the FCEB agency and CISA. For the others, FCEB agency leadership should be held personally accountable for not implementing the BOD.

One "directs" Federal agencies; it is naive to believe that they can be "compelled." In this case, their ability to comply assumes that they know about all such controls. Many of them were installed in the absence of management direction or knowledge. Others are simply orphans.

The good news is that Medtronic is able to publicly state that “During routine monitoring, Medtronic identified a vulnerability in the optional Paceart Messaging Service…” before any attackers were able to exploit that vulnerability. Even better would have been if that routine monitoring and flaw detection had occurred during the pre-shipment testing of the software.

The best fix is to update to the newer version. An alternate mitigation is to disable the messaging feature both in the server and workstation. Review the business impact before disabling the service; it could be just applying the update will be far less disruptive.

Typically, most users install devices using the default configuration; it’s human nature. In this case, that’s a good thing as this vulnerability is in a feature that is not enabled by default. Given that, the likely number of users of this device that are vulnerable should be quite low. Regardless, they should heed the vendors risk mitigation guidance as an additional precaution.

Regardless of the amount of regression testing you’ve done, you will find yourself needing to roll back changes once in a while. The question is are the rollback plans in the change viable? How about your decision process which results in a rollback? Suggest adding actual rollback testing to your training regimen.

Change control applies as much to configuration as to changed code. If it ran yesterday, it should run today. If not, return to yesterday's state. Of course, this requires plans and procedures that make returning to a previous good state, not only possible, but easy.

The Homeland Security Systems Engineering and Development Institute is a Federally Funded R&D Center formed in 2009. Fourteen years later I’d like to see less focusing on enumerating well known weaknesses and more use of funding on reducing the frequency of them appearing in software bought by the US government.

Not really anything new here. Which means our approach is known, just hard to make SOP. For real, if you’re not actively doing dynamic and static analysis of code, that has to be done continuously. Make sure that your developers know they need to sanitize all input fields, regardless of how they are filled, not trusting the endpoint provided data without both guardrails and validation. Take a hard look at WAFs and get them into blocking mode rather than learning mode. Make sure that your scanning and testing of the app is done without the WAF inline so as not to obfuscate issues.

A useful compilation and prioritization of software bugs found in vulnerable products. That said, did much really change from 2022 to 2023? From 2021 to 2022 to 2023? Where’s the connection between this sort of list and teaching secure software development best practices to reduce or eliminate these sorts of bugs from being coded in the first place? Organizations like the non-profit SAFECode are a resource to understand and implement secure software development best practices as well as provide training. Use them.

These weaknesses are common, at least in part, because coders and programmers have not been trained to avoid them. The CERT at Carnegie-Mellon told us years ago that the number of instances is not going down.

Ransomware third-party impacts is not something we’ve thought about much, but if I have to shift a lot of my patients to your facility, and you’re already maxed out, this could end badly. If possible, sit-down with peer businesses where you would send customers during a ransomware attack and see what their capacity is to handle that. Include conversations about what happens if more than one of you are impacted.

The results of the study are not surprising. Healthcare is a delicate ecosystem where an impact in one area will affect other areas. Unfortunately, cyberattacks in this critical sector have only served to highlight this fact. Local, state, and federal government should pull together to support development of incident planning and response efforts for both cyber and natural disaster scenarios.

If you’ve got MOVEit, assume compromise, forensicate the heck out of that environment. You really don’t want to discover you’re a member of this group from a third-party. Have frank conversations about which patches were applied when as well as alternatives to that service. If you migrate off, make sure that it is not just turned off but also fully decommissioned (as in uninstall/deprovisioned, etc.)

If your enterprise uses this product, it is time to assume that you are compromised and begin mitigation.