Severe Vulnerabilities Discovered In GE Medical Devices

By   ISBuzz Team
Writer , Information Security Buzz | Jan 27, 2020 06:10 am PST

It has been reported that the US Cybersecurity and Infrastructure Agency (CISA) today issued an advisory for six high-severity security vulnerabilities in patient monitoring devices. These flaws could allow an attacker to make changes at the software level of a device and in doing so interfere with its functionality, render it unusable, change alarm settings, or expose personal health information.

Notify of
1 Expert Comment
Oldest Most Voted
Inline Feedbacks
View all comments
Jonathan Knudsen
Jonathan Knudsen , Senior Security Strategist
January 27, 2020 2:13 pm

Software is the critical infrastructure that is the foundation for nearly everything else in the modern world. In healthcare, vulnerabilities in software can expose devices and systems to attack or misuse, which ultimately could have adverse effects on patient health. Reducing risk is a matter of finding and fixing vulnerabilities. The way this happened with MDhex was that security researchers located vulnerabilities in existing products. The researchers did the right thing by discreetly notifying the manufacturer, allowing time for a coordinated disclosure to the public.

While security research is an important component of improving the overall state of the industry, it is not the most efficient way to keep risk low while building products. The best way to stamp out vulnerabilities is to find them as soon as possible by using a secure development life cycle (SDLC). At every stage of product development, vulnerabilities are identified and eradicated.

In the design phase, this takes the form of using threat modelling and other techniques to identify design vulnerabilities and the security controls that are necessary to reduce the risk of the system. During implementation, developers can use source code analysis tools to identify vulnerabilities as they are writing source code. Likewise, a software composition analysis tool can be used to manage the security and license compliance risks of the supply chain of open source components used in assembling the system. Traditional functional software testing must be augmented with fuzz testing and interactive application testing. Manual testing, such as that performed by security researchers, can be useful as another way to search for vulnerabilities, but automated tools should be used as much as possible first.

Security is a part of every phase of the SDLC. The resulting software products are safer, more secure, and more robust, which means they present lower risk for the builder and its customers. A proactive approach to software security results in lower risk and lower costs in the long run.

Last edited 4 years ago by Jonathan Knudsen

Recent Posts

Would love your thoughts, please comment.x