Tag Archives: Software security

Courtesy of firstpost.com

Why your security is worse than you think

Thoughts for Yom Kippur – the Jewish day of atonement – coming up next Wed.

Security on modern operating systems (Windows, OS/X, iOS, Android, Linux) is getting better all the time – but  Android using SELinux and MAC (mandatory access control) doesn’t make for catchy, social-media-sticky news items.

A client (a good one) once told me that people never remember your successes, only your failures. (He also believed that all software developers are innately incapable of telling the truth but that’s another story).

The corollary to this notion of failure-skew in the business (and security) world is media reporting. Consider media emphasis on reporting violent and/or negative events. It’s not a hot news item to say that 39% of Israeli Arabs are proud to be Israeli nor is it newsworthy to report that 29% are very proud. The world (Middle East included) is actually a much better place then it seems when not viewed through the lens of social media news reporting and re-purposing (I’m not sure what the correct term for the Huffington Post is so I’ll just use the word repurpose).

FB and Twitter create discussion threads, not examination-of-empirical data threads. Discussion is easier, more fun and cheaper than collecting data and examining it’s quality.

In addition, radical voices are far more interesting than statistics. Who cares that according to World Bank statistics, in 1990 there were 1.91 billion people who lived on less than $1.25 a day an in 2011 it was just one billion. Radical voices (amusingly adopted by the US President) will continue to blame poverty on the rise in Islamic and Iranian terror even though it emanates from the wealthiest countries in the world.

The Jews over the world are up to bat this coming Wed on Yom Kippur. We can bemoan how bad things are and what a terrible President or PM we all have and how our society is falling apart, or we can take a little piece of our own life and fix it. Send thank you notes to people.  Patch your systems once/week. That’s a good start. And pretty easy to do.

Now what does this have to do with software security you ask?

Everything.

Our clients read social media.  They read about zero-days and they get all excited and then do nothing.

Yet another serious Android security issue was publicized this week, with the latest exploit rendering devices “lifeless,” and said to affect more than half of units currently on the market.  Latest Android security exploit could leave more than half of current devices ‘dead’ & unusable

Now let’s check out that URL – its from Apple Insider. Hmm – somebody has an ax to grind I bet.

Security on modern operating systems (Windows, OS/X, iOS, Android, Linux) is getting better all the time – but  Android using SELinux and MAC (mandatory access control) doesn’t make for catchy, social-media-sticky news items.

So this year – I mean this Wednesday – don’t wring your hands.  Do a security assessment on your systems and prioritize 1 thing, find that one weakest link in your system and harden it up.

 

Tell your friends and colleagues about us. Thanks!
Share this
Security is not fortune telling

The importance of risk analysis for HIPAA compliance

A chain of risk analysis

The HIPAA Final Rule creates a chain of risk analysis and compliance from the hospital, downstream to the business associates who handle / process PHI for the hospital and sub-contractors who handle / process PHI for the business associate.

And so on.

The first thing an organization needs to do is a risk analysis.   How important is a risk analysis?  Ask Cancer Care Group who were just fined $750,000 for non-compliance with the Security Rule.

$750,000 HIPAA settlement emphasizes the importance of risk analysis and device and media control policies

Cancer Care Group, P.C. agreed to settle potential violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules with the U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR). Cancer Care paid $750,000 and will adopt a robust corrective action plan to correct deficiencies in its HIPAA compliance program. Cancer Care Group is a radiation oncology private physician practice, with 13 radiation oncologists serving hospitals and clinics throughout Indiana.

On August 29, 2012, OCR received notification from Cancer Care regarding a breach of unsecured electronic protected health information (ePHI) after a laptop bag was stolen from an employee’s car. The bag contained the employee’s computer and unencrypted backup media, which contained the names, addresses, dates of birth, Social Security numbers, insurance information and clinical information of approximately 55,000 current and former Cancer Care patients.

OCR’s subsequent investigation found that, prior to the breach, Cancer Care was in widespread non-compliance with the HIPAA Security Rule. It had not conducted an enterprise-wide risk analysis when the breach occurred in July 2012. Further, Cancer Care did not have in place a written policy specific to the removal of hardware and electronic media containing ePHI into and out of its facilities, even though this was common practice within the organization. For more information see the HHS Press Release from Sep 2, 2015 $750,000 HIPAA settlement emphasizes the importance of risk analysis and device and media control policies

Risk analysis is the first step in meeting Security Rule requirements

I have written here, here, here and here about the importance of risk analysis as a process of understanding the value of your assets, the impact of your threats and the depth of your vulnerabilities in order to implement the best security countermeasures.

The HIPAA Security Rule begins with the analysis requirement in § 164.308(a)(1)(ii)(A). Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is fundamental to the entire process of HIPAA Security Rule compliance, and must be understood in detail by the organization in order to specifically address safeguards and technologies that will best protect electronic health information. See Guidance on Risk Analysis Requirements under the HIPAA Security Rule. Neither the HHS Guidance nor NIST specify a methodology – we have been using the Practical Threat Analysis methodology for HIPAA Security risk analysis with Israeli medical device companies since 2009 and it works smoothly and effectively helping Israeli medical device vendors comply and implement robust security at the lowest possible cost.

§ 164.308(a)(1)(ii)(A) Risk Analysis (R1): As part of the risk management process, the company performs information security risk analysis for its services (see company procedure XYZ) analyzing software application  security, data security and human related vulnerabilities. Risk analysis is performed according to the Practical Threat Analysis methodology.

1 A refers to addressable safeguards, and R refers to required safeguards.

Do it.  Run Security like you Run your business

Tell your friends and colleagues about us. Thanks!
Share this
skin mounted medical devices

On Shoshin and Software Security

I am an independent software security consultant specializing in medical device security and HIPAA compliance in Israel.   I use the state-of-the art PTA – Practical Threat Analysis tool to perform quantitative threat analysis and produce  a bespoke, cost-effective security portfolio for my customers that fits their medical device technology.

There are over 700 medical device companies in Israel – all doing totally cool and innovative things from My Dario (diabetes management), to Syneron (medical esthetics),  to FDNA (facial dysmorphology  novel analysis at your fingertips) to Intendu (Brain Rehabilitation).

This is a great niche for me because I get to do totally cool projects and  work with a lot of really smart people at Israeli medical device vendors helping them implement cost-effective  security and privacy compliance + it’s fun learning all the time.

One thing I have learned is that there is very little connection between FDA medical device risk assessments and a software security risk assessments.   This somewhat counter-intuitive for people who come from the QA and RA (regulatory assurance) areas.

Security is an adversarial environment very unlike FDA regulatory oversight.

FDA medical device regulatory oversight is about complying in a reliable way with standard operating procedures and software standards.

FDA believes that conformance with guidance documents, when combined with the general controls of the Act, will provide reasonable assurance of safety and effectiveness…

FDA recognizes several software consensus standards. A declaration of conformity to these standards, in part or whole, may be used to show the manufacturer has verified and validated pertinent specifications of the design controls. The consensus standards are:

  • ISO/IEC 12207:1995 Information Technology – Software Life Cycle Processes
  • IEEE/EIA 12207.O-1996 Industry Implementation of International Standard ISO/IEC12207:1995 (ISO/IEC 12207) Standard for Information Technology – Software Life Cycle Processes

Barry Boehm succinctly expressed the difference between Verification and validation:

Verification: Are we building the product right?

Validation: Are we building the right product?

Building the right product right is no more a guarantee of security than Apple guaranteeing you that your Mac Book  Pro  will not be stolen off an airport scanner.

Medical device security is about attackers and totally unpredictable behavior

Medical device security is about anticipating  the weakest link in a system that can be exploited by an attacker who will do totally unpredictable things that were inconceivable last year by other hackers, let alone 20 years ago by an ISO standards body.

You cannot manage unpredictable behavior (think about a 2 year old) although you can develop the means for anticipating threats and responding quickly and in a focused way even when sleep-deprived and caffeine-enriched.

The dark side of security is often hubris and FUD.

For security consultants, there is often an overwhelming temptation to show clients how dangerous their security vulnerabilities are and use that as a lever to sell products and services.   I’ve talked about hubris and FUD here and here and here and here and here.   A good example of exploiting clients with security FUD are the specialty HIPAA-compliant hosting providers like Firehost that are masters of providing expensive services to clients that may or may not really need them.

However, I believe that intimidation is not necessarily a strategy guaranteed to win valuable long-term business with clients.

Instead of saying – “that is a really bad idea, and you will get hacked and destroy your reputation before your QA and RA departments get back from lunch“,  it is better to take a more nuanced approach like:

I see that you are transferring credentials in plain-text to your server in the cloud.   What do you think about the implications of that?“.   Getting a client to think like an attacker is better than dazzling and intimidating them which may result in  the client doing nothing, hunkering down into his current systems or if the client has money – going off and spending it badly.

How did I reach this amazing (slow drum roll…) insight?

About 3 years ago I read a book called Search Inside Yourself and I learned an idea called – “Don’t take action, let action take you“.    I try to apply this approach with clients as a way of helping them learn themselves and as a way of avoiding unnecessary conflict.  The next step in my personal evolution was getting acquainted with a Zen Buddhist concept  called Shoshin:

Shoshin (初心) means “beginner’s mind”. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

Shoshin means doing the exact OPPOSITE of what you (the high-powered, all-knowing, medical device security consultant) would normally do in the course of a security threat assessment:

  1. Let go of the need to add value – you do not have to provide novel security countermeasures all the time. Sometimes, doing the basics very well (like hashing and salting passwords) is all the value the client needs.
  2. Let go of the need to win every argument – you do not have to show the client why their RA (regulatory assurance) manager is making fatal mistakes in database encryption after she took some bad advice from Dr. Google.
  3. Ask the client to tell you more – ask what led them to a particular design decision.  You may learn something about their system design alternatives and engineering constraints. This will help you design some neat security countermeasures for their medical device and save them some money.
  4. Assume you are an idiot –  this is a corollary of not taking action.   By assuming you are an idiot, you disable your ego for a few moments and you get into a position of accepting new information  which in the end, may help you anticipate some threats and ultimately take your client out of potentially dangerous adversarial threat scenario.

Thank you to James Clear for his insightful post – Shoshin: This Zen Concept Will Help You Stop Being a Slave to Old Behaviors and Beliefs

Tell your friends and colleagues about us. Thanks!
Share this
dilbert-paradigm-intro1

10 ways to detect employees who are a threat to PHI

Software Associates specializes in software security and privacy compliance for medical device vendors in Israel.   One of the great things about working with Israeli medical device vendors is the level of innovation, drive and abundance of smart people.

It’s why I get up in the morning.

Most people who don’t work in security, assume that the field is very technical, yet really – it’s all about people.   Data security breaches happen because people or greedy or careless.    100% of all software vulnerabilities are bugs, and most of those are design bugs which could have been avoided or mitigated by 2 or 3 people talking about the issues during the development process.

I’ve been talking to several of my colleagues for years about writing a book on “Security anti-design patterns” – and the time has come to start. So here we go:

Security anti-design pattern #1 – The lazy employee

Lazy employees are often misdiagnosed by security and compliance consultants as being stupid.

Before you flip the bozo bit on customer’s employee as being stupid, consider that education and IQ are not reliable indicators of dangerous employees who are a threat to the company assets.

Lazy employees may be quite smart but they’d rather rely on organizational constructs instead of actually thinking and executing and occasionally getting caught making a mistake.

I realized this while engaging with a client who has a very smart VP – he’s so smart he has succeeded in maintaining a perfect record of never actually executing anything of significant worth at his company.

As a matter of fact – the issue is not smarts but believing that organizational constructs are security countermeasures in disguise.

So – how do you detect the people (even the smart ones) who are threats to PHI, intellectual property and system availability:

  1. Their hair is better organized then their thinking
  2. They walk around the office with a coffee cup in their hand and when they don’t, their office door is closed.
  3. They never talk to peers who challenge their thinking.   Instead they send emails with a NATO distribution list.
  4. They are strong on turf ownership.  A good sign of turf ownership issues is when subordinates in the company have gotten into the habit of not challenging the VP coffee-cup holding persons thinking.
  5. They are big thinkers.    They use a lot of buzz words.
  6. When an engineer challenges their regulatory/procedural/organizational constructs – the automatic answer is an angry retort “That’s not your problem”.
  7. They use a lot of buzz-words like “I need a generic data structure for my device log”.
  8. When you remind them that they already have a generic data structure for their device log and they have a wealth of tools for data mining their logs – amazing free tools like Elasticsearch and R….they go back and whine a bit more about generic data structures for device logs.
  9. They seriously think that ISO 13485 is a security countermeasure.
  10. They’d rather schedule a corrective action session 3 weeks after the serious security event instead of fixing it the issue the next day and documenting the root causes and changes.

If this post pisses you off (or if you like it),  contact danny Lieberman me.  I’m always interested in challenging projects with people who challenge my thinking.

Tell your friends and colleagues about us. Thanks!
Share this
risk-driven medical device security

Health Information Technology Patient Safety Action & Surveillance Plan

This is a quick update on two new documents released by the HHS and the IMDRF:

 Health Information Technology Patient Safety Action & Surveillance Plan

The US Department of Health and Human Services published on July 2, 2013 the Health Information Technology Patient Safety Action & Surveillance Plan. The FDA belongs to the HHS.

The plan defines several types of action in three categories: Learn, Improve, Lead.

·       Learn – focuses primarily on monitoring of safety of Health IT in the field.

·       Improve – includes investigating adverse events and taking corrective action. Also included are setting safety priorities and incorporating safety into certification criteria for Health IT.

·       Lead – encourages the private sector leadership for Health IT Safety and develops a risk-based regulatory framework for Health IT.

The plan is found at http://www.healthit.gov/sites/default/files/safety_plan_master.pdf .

 Standalone Medical Device Software: Key Definitions

The International Medical Device Regulators Forum, a medical device-focused regulators-only successor group to the Global Harmonization Task Force (GHTF), has released a new document for consultation regarding the definition of standalone software used for medical purposes.

The document, Standalone Medical Device Software: Key Definitions, was released on 1 July 2013 and is being coordinated by the FDA.

As the document explains, “Software for medical purposes is becoming increasingly important and … can appear in many forms and on many computing platforms.” For example, some software is embedded into a type of medical device, while others are sold as stand-alone software meant to work on a variety of devices (e.g. mobile devices) or settings (e.g. cloud-based computing or local networks).

A major issue with respect to regulators is the fast pace at which the technology is progressing. Accordingly, this leads to problems in understanding what is required and what is expected (note: what is required is not necessarily what is expected and what is expected is not necessarily what is required).

The document provides a detailed analysis and definition of standalone medical device software (SMDS). According to the IMDRF, medical device software – which is defined as a medical device — “may include but are not limited to” the following characteristics:

·       capable of running on general purpose (non-medical purpose) computing platforms

·       not necessary for a hardware medical device to achieve its intended medical purpose

·       may be used in combination (e.g., as a module) with other devices

·       may be interfaced with other medical devices, including hardware medical devices and other standalone medical devices software

Software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS.

The document is found at http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-sskd-130701.pdf.

If there are any questions, please contact us.

 

Tell your friends and colleagues about us. Thanks!
Share this

Are passwords dead?

A recent article on CSO online ponders the question of whether or not passwords are dead – since they are not much of a security countermeasure anyhow (or so the article intimates). The article quotes a person who seems to believe that SQL injection attacks have to do with password security.

Christopher Frenz, CTO at See-Thru and a faculty member at Mercy College, both in New York, says the problem is, “not because of passwords being obsolete, but because of the prevalence of bad passwords and bad password practices.”

He points to the 2009 SQL injection attack on the social media site RockYou that compromised 32 million user account passwords. “The only password security requirement was a password of at least five characters,” he says, “(which) resulted in people choosing passwords such as 12345, Password, rockyou, and abc123,” plus common dictionary words.

Besides that, the passwords were stored in plain text format, along with users’ email addresses.

Frenz says some websites (Hotmail recently among them) now require more complex passwords with multiple character types.

I’m speechless.

SQL injection attacks on Web sites are made possible because of poor coding practices that take input strings from forms or query strings and concatenate with SQL snippets like this:

2′;Update tbl_accountParent set Email=Email+’;obama@whitehouse.giv’;select * from  tbl_accountParent where ‘1’=’1

From now on, whenever any user asks for password reminder, Mr. Obama will get a nice email with his user name and password.

And frankly, I don’t understand programmers or Web site operators who tolerate storing passwords in plain text or encrypting them instead of using one-way hashes

Maybe a bunch of people should read the online introduction to cryptography by Dan Bernstein.

Tell your friends and colleagues about us. Thanks!
Share this

Free risk assessment of your web site

With all the news about credit card breaches, there are probably a lot of people scurrying about trying to figure out the cheapest and fastest way to reduce the risk of some Saudi hacker stealing credit cards or mounting a DDOS attack on their web site.

I have written here, here and here about how to reduce the risk of a data breach of a web site.

Not to rain on the media party, but the actual cost to a online marketer of a hacker breaching a web site or defacing the web site could be very low since card-holders are covered by the credit card issuers and as long as the online commerce site continues operation, a temporary revenue dip might be offset by additional visits to the publicity.

Then again, the cost of a data breach to your operation could be very high, especially if you scrimp on security.

So – what is the right answer?

The right answer is the right security for your web site at the right cost to your pocket, not what Symantec says or what Microsoft says but what your risk assessment says.

In order to implement the most cost-effective security for your web site, you need to do a risk assessment that takes into consideration the value of your assets, the probability of attacks,  current vulnerabilities of your web site and operation (don’t forget that trusted insiders may be the more significant vulnerability in your operation) and possible countermeasures, including the cost of said countermeasures.

Sounds complex, right?

Actually – performing a threat analysis of  your web site can be a fairly straightforward exercise using the free risk assessment software provided by PTA Technologies.

You can download the free risk assessment software here and start improving your security today.

Any questions – feel free to reach out to the professional software security consultants in Israel at Software Associates.

Tell your friends and colleagues about us. Thanks!
Share this

Build management and Governance

Don’t break the build.

There is absolutely no question that the build process is a pivot in the software quality process. Build every day, don’t break the build and do a smoke test before releasing the latest version.

This morning, I installed the latest build of an extremely complex network security product from one of our customers and lo and behold, one of the most basic functions did not work (and has not worked for about 3 revisions now apparently). Wrote a love letter to the customer service and QA managers and chided them for sloppy QA.

An article I saw recently, talks about the “confluence of compliance and governance” and the direct link to software quality. If you read Jim McCarthy’s classic – “Dynamics of Software Development” you will remember the chapter called Don’t break the build.

You may be using Linux make, Microsoft nmake or Apache Ant but in all cases, the build expertise of the person running the build is more important than the tool itself. the development team runs a daily build with a build-meister personally responsible for running the construction of a working system from all the components. If the build breaks he doesn’t go home.

It is better to have a non-programmer do the smoke-test before the final release to manufacturing. A person outside the engineering team does not have the blinders or personal interest to ignore basic functionality that gets broken ( not to mention having motivation to one-up the engineers).

Anyhow, maybe there is still hope if the compliance gurus have discovered software quality.

Tell your friends and colleagues about us. Thanks!
Share this

The ethical aspects of data security

Ethical breaches or data breaches.

I was standing in line at Ben Gurion airport, waiting for my bag to be x-rayed. A conversation started with a woman standing next to me in line. The usual sort – “Where are you traveling and what kind of work do you do?”. I replied that I was traveling to Warsaw and that I specialize in data security and compliance – helping companies prevent trusted insider theft and abuse of sensitive data.

She said, “well sure, I understand exactly what you mean – you help enforce ethical behavior of people in the organization”.

I stopped for a moment and asked her, hold on – “what kind of business are you in”? She said – “well, I worked in the GSS for years training teams tasked with protecting high echelon politicians and diplomats. I understand totally the notion of enforcing ethical behavior”. And now? I asked. Now, she said, ” I do the same thing, but on my own”.

Let’s call my new friend “Sarah”.

Sarah’s ethical approach was for me, a breath of fresh air. Until that point, I had defined our data security practice as an exercise in data collection, risk analysis and implementation of the appropriate technical security countermeasures to reduce the risk of data breach and abuse. Employees, competitors and malicious attackers are all potential attackers.  The objective is to implement a cost-effective portfolio of data security countermeasures – policies and procedures, software security assessments, network surveillance, data loss prevention (DLP) and encryption at various levels in the network and applications.

I define security as protecting information assets.

Sarah defines security as protecting ethical behavior.

In my approach to data security, employee behavior is an independent variable, something that might be observed but certainly, not something that can be controlled. Since employees, contractors and business partners tend to have their own weaknesses and problems that are not reported on the balanced score card of the company, my strategy for data security posits that it is more effective to monitor data than to monitor employees and prevent unauthorized transfer or modification of data instead of trying to prevent irrational or criminal behavior of people who work in the extended enterprise.

In Sarah’s approach to data security, if you make a set of rules and train and enforce ethical behavior with good management, sensing and a dosage of fear in the workplace; you have cracked the data security problem.

So – who is right here?

Well – we’re both right, I suppose.

The answer is that without asset valuation and analysis of asset vulnerabilities, protecting a single asset class (human resources, data, systems or network) while ignoring others, may be a mistake.

Let’s examine two specific examples in order to test the truth of this statement.

Consider a call center with 500 customer service representatives. They use a centralized CRM application, they have telephones and email connectivity. Each customer service representative has a set of accounts that she handles. A key threat scenario is leaking customer account information to unauthorized people – private investigators, reporters, paparazzi etc… The key asset is customer data but the key vulnerability is the people that breach ethical behavior on the way to breaching customer data.

In the case of customer service representatives breaching customer privacy, Sarah’s strategy of protecting ethical behavior is the best security countermeasure.

Now, consider a medical device company with technology that performs imaging analysis and visualization. The company deploys MRI machines in rural areas and uses the Internet to provided remote expert diagnosis for doctors and patients who do not have access to big city hospitals. The key asset transmitted from the systems for remote diagnosis is PHI (protected health information), and the key vulnerabilities are in the network interfaces, the applications software and operating systems that the medical device company uses.

In  the case of remote data transfer and distributed/integrated systems, a combined strategy of software security, judicious network design and operating system selection (don’t use Microsoft Windows…) is the correct way to protect the data.

My conversation with Sarah at the airport gave me a lot of food for thought.

Data loss prevention (DLP technology) is great  and  ethical employee behavior is crucial but they need to work hand in glove.

Where there are people, there is a need to mandate, monitor and reinforce ethical behavior using  a clearly communicated corporate strategy with employees and contractors. In an environment where users require freedom and flexibility in using applications such as email and search, the ethical behavior for protecting company assets starts with company executives who show from personal example that IT infrastructure is to be used to further the company’s business and improving customer service and not for personal entertainment, gain or gratification.

It’s the simple things in life that count.

Tell your friends and colleagues about us. Thanks!
Share this

Why outlawing Windows from embedded medical devices is a good idea

In a previous post The Microsoft Monoculture as a threat to national security, I suggested that the FDA might consider banning Windows as an operating system platform for medical devices and their accompanying information management systems.

One of my readers took umbrage at the notion of legislating one monoculture (Microsoft) with another (Linux) and how the Linux geeks are hooked on the CLI just like Windows users are hooked on a GUI.

The combination of large numbers of software vulnerabilities,  user lock in created by integrating applications with Windows,  complexity of Microsoft products and their code and Microsoft predatory trade practices are diametrically different than Linux and the FOSS movement.

One of the biggest threats to medical devices in hospitals is the widespread use of USB flash disk drives and Windows notebooks to update medical device software. With the infamous auto-run feature on Microsoft USB drives – flash memory is an easy attack vector for propagating malware via Windows based medical devices into a hospital network. This is one (and not the only) reason, why I am campaigning against use of Windows in medical devices.

This  has nothing to do with the CLI or GUI of the operating system and personal preferences for a user interface.

This has everything to do with manufacturing secure embedded medical devices that must survive in most demanding, heterogeneous and mission critical environment one can imagine – a modern hospital.

I never advocated mandating Linux by law for medical devices.

It might be possible to mandate a complex set of software security requirements instead of outlawing Windows in embedded medical devices as a more politically-correct but far more costly alternative for the the FDA and the US taxpayer.

Regardless of the politics involved (and they are huge…) – if the FDA were to remove Windows from an approved list of embedded medical device operating systems – the costs to the FDA would decrease since the FDA would need less Windows expertise for audits and the threat surface they would have to cover for critical events would be smaller.

Tell your friends and colleagues about us. Thanks!
Share this