Merlin Labs Memo -- Week of April 24-28
Merlin Cyber
Merlin is your trusted source for best-in-class and innovative and emerging cyber solutions for the U.S. public sector.
CISA Unveils Secure by Design Principles
"The Cybersecurity and Infrastructure Security Agency, joined by key federal agencies and international partners,?released a highly anticipated set of principles and procedures?created to push responsibility for product security onto the shoulders of the global technology industry.??
The Biden administration is admonishing the world’s largest software makers to make sure these products have security built in as a key component during the design and production phase.
"Ensuring that software manufacturers integrate security into the earliest phases of design for their products is critical to building a secure and resilient technology ecosystem,"?CISA Director Jen Easterly?said in an emailed statement. "These secure by design and secure by default principles aim to help catalyze industrywide change across the globe to better protect all technology users."" – Via Cybersecurity Dive
Our Take: With the release of these secure by design principles, Easterly gave a talk at Carnegie Mellon University.?In the speech, Easterly noted what she considers the most important aspect of technology: people.?She goes on to say that history proves to us that we can—and indeed must—change the way we collectively value safety over other market incentives like cost, features, and speed to market.?As an analogy, she cited the automobile industry and the array of safety features that have become standard over the last few decades, things like seatbelts, airbags, anti-lock brakes, and so on.???
This is the perfect comparison as none of us would buy a car without these features today, and they do make us safer.?In fact, these safety standards have become the primary features that we look for in a new vehicle, with each automaker touting their breakthroughs. The new CISA guidance is an attempt to push the same mentality into the technology industry: security first!
People in technology, like any other industry, are driven by incentives.?Getting products to market the fastest and keeping costs low are often at the top of the list.?While the technology to make our products safer currently exists, and is outlined in the CISA guidance, it is often sacrificed in favor of getting to market more quickly, and thus postponed until the "next release."?So, this guidance from CISA is important for two reasons. First, it aims to change that mindset by setting a standard for security practices that technology providers can coalesce around.?Second, it will hopefully cause anyone purchasing technology to prioritize security, for example, by asking, "Does this product support multi-factor authentication?" Just as you might ask about side-impact airbags when purchasing a new car.?Lost revenue is the best way to hold technology providers accountable!
While the intention here is to shift more responsibility to technology providers, there is still a burden on users and always will be.?Even the best security features, like MFA, can be exploited by threat actors; they have their incentive structures as well!??Every new security feature which looks rock-solid when it is released will somehow be exploited in the future, so ongoing maintenance and diligence is required.?Just like it is important to drive at or under the speed limit and bring your vehicle in for regular maintenance, it is the responsibility of every technology user, whether enterprise or consumer, to maintain their technology investment by following security best practices and not relying solely on the providers of technology to keep them safe. – Joe DiMarcantonio, PMP
Additional Reading:
Connected IoT Devices Put Hospitals at Risk
Unpatched nurse call systems, infusion pumps, IP cameras and printers are just some of the devices routinely posing risks to hospitals, according to a recent study of connected medical devices. According to Data Breach Today, “Smart hospitals globally are expected to deploy over 7 million internet of medical things devices by 2026 - or more than 3,850 devices per smart hospital.” In some cases, devices were using sunsetted operating systems and other antiquated, un-supported technologies. In addition, IoT devices, with their often proprietary and embedded technologies can be difficult to monitor and patch, with some medical devices requiring the device makers themselves to provide updates as to not void a warranty or negate an FDA approval. And while there has been an increased focus from the FDA and others on improving the cybersecurity postures of medical devices, the adjacent connected devices that support broader healthcare operations and leverage the same networks as the medical devices are often under-prioritized or overlooked altogether. – Via Data Breach Today
Our Take: As a cybersecurity IT professional with a degree and experience in healthcare, stories about cyber risk in the healthcare arena always grab my attention – and should grab yours as well. At some point, we are all consumers of healthcare and trust our caregivers to provide that care in safe and secure environments. Hospital and healthcare-delivery operations absolutely rely on traditional IT and IoT devices throughout the care delivery lifecycle, from scheduling to patient admissions to authorizations, to in-patient and out-patient care delivery, to medical procedure execution to medical records retention to discharge planning and billing activities. And as building and facility operations get “smarter” and more inter-connected with healthcare-delivery devices – the potential attack surface grows and becomes even more complex. It's next to impossible to receive healthcare services without directly or indirectly interacting with IT-enabled systems, services and environments. While the answers to this conundrum may not be simple, the first step is recognizing and embracing the new reality facing healthcare delivery organizations.
领英推荐
IT is here to stay, it touches nearly everything, it stores our most sensitive information, and it must be maintained and operated in a way that recognizes and mitigates the risks. That means adopting a zero trust mentality when architecting, configuring and operating the IT systems, protecting patient data through end-to-end encryption, ensuring our cybersecurity operations take into account the cyber hygiene and cybersecurity posture of ALL connected IT and IoT devices, and avoiding devices whose software and activities cannot be easily monitored, updated and patched wherever possible. There are IoT device management platforms available that can help with this process. Combined with solid device lifecycle management policies and procedures, these management platforms can make an end-to-end cyber-secure operation more attainable. The cost of ignoring this new reality can have grave consequences for all of us, including but not limited to potentially threatening our physical safety, robbing us of receiving sound medical care, and exposing our most private medical and financial information. – Sarah Hensley
Additional Reading:
Understanding SBOMs
A Software Bill of Materials (SBOM) is a powerful concept in security that correctly implies that having a full inventory of the software building blocks that make up an application allows for faster resolution of security issues when vulnerabilities are discovered in one or more of those software building blocks. At a high level, we all want SBOMs for all our applications.
On a technical level, we have to overcome issues of readability, comprehensiveness, and usability. What format will the SBOM be in? Will the SBOM cover only open-source components? Is the SBOM part of application life-cycle risk management?
Our take: An SBOM must be more than a shopping list on a piece of paper. It needs to be available in a machine-readable format. Among vendors, the standards are closing in on SPDX and CycloneDX, so you’ll want to make sure your SBOMs arrive in one of those formats and that you get your vendors to offer you SBOMs in the format you’ve chosen as your standard. Having said that, if the SBOM itself is incomplete, its usefulness is limited.?
To that end, you’ll want to verify a vendor-supplied SBOM with your own application pen testing to validate that there aren’t other packages in the software that the vendor may have overlooked in preparing its SBOM. If your SBOMs list only open-source components, your organization faces unknown risks from the non-open-source code in your applications. An SBOM needs to cover all the parts of the application so that a comprehensive record can be maintained and referenced as vulnerabilities become known.
And that brings us to long-term usability. We should not be collecting SBOMs in a pile that itself collects dust. SBOMs need to be kept on hand as part of an application life-cycle risk review. They need to be accessible for general queries so that a new vulnerability means a quick, automated search instead of dozens of people-hours spent perusing documentation manually. SBOMs need to be integrated into threat intel systems, because we get dozens of vulnerability announcements every day, and we need an automatic reading of those announcements cross-referenced with our SBOMs. Finally, those SBOMs need to be able to be joined together to track overall vulnerabilities in end-to-end systems that are themselves made up of multiple software application components. – Dean Webb
Additional Reading:
Readers of our Newsletter:?What’s working, what’s not, and what’s on your mind? Leave a comment below or email?[email protected]. Thank you!??