- My Forums
- Tiger Rant
- LSU Recruiting
- SEC Rant
- Saints Talk
- Pelicans Talk
- More Sports Board
- Fantasy Sports
- Golf Board
- Soccer Board
- O-T Lounge
- Tech Board
- Home/Garden Board
- Outdoor Board
- Health/Fitness Board
- Movie/TV Board
- Book Board
- Music Board
- Political Talk
- Money Talk
- Fark Board
- Gaming Board
- Travel Board
- Food/Drink Board
- Ticket Exchange
- TD Help Board
Customize My Forums- View All Forums
- Show Left Links
- Topic Sort Options
- Trending Topics
- Recent Topics
- Active Topics
Started By
Message
Any IT security experts on this board?
Posted on 4/3/18 at 10:01 am
Posted on 4/3/18 at 10:01 am
I work for a medical company and decided to take on a project to help our development understand the "on the street" security pushback that we get when installing our products in hospitals etc. We have always been very behind the curve in having up to date standards for our PC's and servers mainly because of FDA validation and the process for getting this done for each release of Windows etc. I am trying to do some research on how I can help us to build a future looking product to mitigate how much pushback we get for installations.
To give you an example of what I deal with every day when talking to customers:
Products:
1: Server based system Windows 2012 R1 which has browser based kiosk's which runs Windows 7 professional. System contains PHI.
2: Server based analysis (FDA approved algorithms) running Windows 2008 R2. PC running an instrument Win 7 pro which contains PHI.
3: Axeda is the only remote connectivity solution supported by our company
Objections:
1: Bitlocker: Even on the kiosk's I have a healthcare system insisting that they run bitlocker.
2: More up to date Windows versions: Especially with product 2, I feel like an idiot telling IT that we are only validated on 2008.
3. IT groups have their own preferred remote connectivity solutions which often causes a stalemate.
My question is, what is the best way for me to help development with a more proper proactive instead of reactive approach to building our systems? Are there any roadmaps for where systems (especially medical systems) are moving over the next 5 years in security technology? How would you suggest I gather information that is pertinent?
To give you an example of what I deal with every day when talking to customers:
Products:
1: Server based system Windows 2012 R1 which has browser based kiosk's which runs Windows 7 professional. System contains PHI.
2: Server based analysis (FDA approved algorithms) running Windows 2008 R2. PC running an instrument Win 7 pro which contains PHI.
3: Axeda is the only remote connectivity solution supported by our company
Objections:
1: Bitlocker: Even on the kiosk's I have a healthcare system insisting that they run bitlocker.
2: More up to date Windows versions: Especially with product 2, I feel like an idiot telling IT that we are only validated on 2008.
3. IT groups have their own preferred remote connectivity solutions which often causes a stalemate.
My question is, what is the best way for me to help development with a more proper proactive instead of reactive approach to building our systems? Are there any roadmaps for where systems (especially medical systems) are moving over the next 5 years in security technology? How would you suggest I gather information that is pertinent?
3
Posted on 4/3/18 at 10:18 am to flyAU
I'm not a security "expert" but I play one on TD. I'd say your dev team kinda sucks.
We are dealing with PII and PHI, and therefor HIPPA. FedGov does NOT frick around in these cases, neither do class action lawyers. As for the specific objections:
1) Bitlocker. Your customers are right to expect data at rest to be encrypted, even on kiosks. There is no argument against it.
2) Server 2008 R2 gets EoL in Jan 2020. It lost mainstream support 3 years ago. Once a platform loses mainstream support I would expect developers to move on, while supporting updates/fixes for the legacy system until full EoL. There is a ZERO percent chance I'd recommend your product if you told me its got to run on a Server08 with a W7 console in 2018. Thats a pitch that would get shut down right then and there. These aren't SCADA systems for fricks sake.
3)Every dept likes to standardize their toolset. I don't want to integrate your specific remote tool. This should be the easiest objection to get over, but also the easiest objection for your company to eliminate.
The real question is, what are your competitors doing? What platforms are they validated on? What challenges do they have?
If they are similar to your issues, then its an industry problem. If all their tools will run on at least a Server 2012 R2 box - then its your problem.
We are dealing with PII and PHI, and therefor HIPPA. FedGov does NOT frick around in these cases, neither do class action lawyers. As for the specific objections:
1) Bitlocker. Your customers are right to expect data at rest to be encrypted, even on kiosks. There is no argument against it.
2) Server 2008 R2 gets EoL in Jan 2020. It lost mainstream support 3 years ago. Once a platform loses mainstream support I would expect developers to move on, while supporting updates/fixes for the legacy system until full EoL. There is a ZERO percent chance I'd recommend your product if you told me its got to run on a Server08 with a W7 console in 2018. Thats a pitch that would get shut down right then and there. These aren't SCADA systems for fricks sake.
3)Every dept likes to standardize their toolset. I don't want to integrate your specific remote tool. This should be the easiest objection to get over, but also the easiest objection for your company to eliminate.
The real question is, what are your competitors doing? What platforms are they validated on? What challenges do they have?
If they are similar to your issues, then its an industry problem. If all their tools will run on at least a Server 2012 R2 box - then its your problem.
Posted on 4/3/18 at 10:31 am to jcole4lsu
jcole4lsu is spot-on about everything so I'm not going to comment on what he said.
My only question is how expensive is getting your product FDA validated? If you're hesitant to do it, it must be prohibitive.
My only question is how expensive is getting your product FDA validated? If you're hesitant to do it, it must be prohibitive.
Posted on 4/3/18 at 10:42 am to jcole4lsu
quote:
I'd say your dev team sucks.
FIFY
I am the sales engineer that goes in to have IT talks with their IT pre-sale. All of what you said is correct and I am not defending it in the least. My job is made much more difficult in having to discuss these older system models. I have raised the flag to upper management which seems to go only so far. FDA validation for specific systems do run behind current tech many times as it takes a lot of time to validate newer platforms.
That is why I am wanted to create a better roadmap for development on so that while they are building new systems that they take into account where the industry is going. I feel that they get trapped in a dev bubble and miss some critical pieces in where the industry is going. I was more asking for advice on how you would build a system roadmap in the medical field for a server as well as host PC environment.
(OH and don't even get me started on us not supporting VM environments for that 2008 product)
This post was edited on 4/3/18 at 10:46 am
Posted on 4/3/18 at 10:47 am to flyAU
quote:
(OH and don't even get me started on us not supporting VM environments for that 2008 product)
Wait - i have to run 08 as a physical machine?
Posted on 4/3/18 at 10:51 am to jcole4lsu
Oh trust me. All I can do after I say this to a client is. “I know...”
Granted most medical IT shops have to deal with quirky systems like this. Because of the FDA most medical systems are steps behind other industries.
Granted most medical IT shops have to deal with quirky systems like this. Because of the FDA most medical systems are steps behind other industries.
Posted on 4/3/18 at 11:02 am to flyAU
My advice:
1) support virtualization
2) support end to end encryption, including data in use and at rest
3) The M$ life cycle for standalone products isn't going to change. New server product every 4ish years. EoL in 10-11 years. Even if the FDA drags their feet on validation, I doubt there is any reason for all of your products to not be validated on Server2012R2 by the time Server2016 came out. Certainly by 2018.
4) polish that resume up
1) support virtualization
2) support end to end encryption, including data in use and at rest
3) The M$ life cycle for standalone products isn't going to change. New server product every 4ish years. EoL in 10-11 years. Even if the FDA drags their feet on validation, I doubt there is any reason for all of your products to not be validated on Server2012R2 by the time Server2016 came out. Certainly by 2018.
4) polish that resume up
Posted on 4/3/18 at 11:18 am to jcole4lsu
quote:
1) support virtualization
Will be supported at end of the year for all products
quote:
2) support end to end encryption, including data in use and at rest
So I get the bitlocker piece for at rest information. Are you suggesting SSL for the traffic? I am not too knowledgeable in every place encryption would be needed.
quote:
3) The M$ life cycle for standalone products isn't going to change. New server product every 4ish years. EoL in 10-11 years. Even if the FDA drags their feet on validation, I doubt there is any reason for all of your products to not be validated on Server2012R2 by the time Server2016 came out. Certainly by 2018.
So I am shooting for a roadmap for a 2022 product release. This would most likely put us on track for 2016 validation. You assuming 2020 will be the next release? How about workstations? Are IT shops in other industries bringing on 10? Or is 7 still the preferred?
quote:
4) polish that resume up
I work for one of the largest medical companies in the world and am specialized in IT which they are moving their focus to. I am in the drivers seat for the next decade, and this project could help me be a pretty important aspect of the companies future in the IT piece of business. We have been hamstrung by development which I am hellbent on changing.
Posted on 4/3/18 at 1:10 pm to flyAU
Obviously I dont know the ins and out of your product, but if SSL/TLS encryption is supported for transit then thats a good start.
How long does it take for validation? Is the FDA validating your product, the OS, both individually or both as a combination? 2022 release would be ideally validated for Server2016 and Server2019. Sever2012R2 will EoL in 2023, making it nonviable for a product released in 2022. Server2016 scheduled to EoL in 2027.
How long does it take for validation? Is the FDA validating your product, the OS, both individually or both as a combination? 2022 release would be ideally validated for Server2016 and Server2019. Sever2012R2 will EoL in 2023, making it nonviable for a product released in 2022. Server2016 scheduled to EoL in 2027.
Posted on 4/3/18 at 1:28 pm to jcole4lsu
Appreciate your insight. We do support SSL although we leave that up to the customer IT.
Validation is a tricky situation with varying times of processing. For example that 2008 product gives an actual score back to doctors on the score of cancer a patient has (what type and severity). Changes to the platform that may alter the performance of the algorithms being run could cause year's long re-validation. Internal validation as well as support also become overhead which causes these lags.
I do have a question for anyone who may know the networking aspect of things. If I am running 10 instruments (they have Windows PC's running them), would it help to segment off all of our PC's behind a firewall provided by us or a VLAN in order to add additional security from Wannacry, viruses etc. if we are lagging behind the main networks security requirements? Is this a palatable design?
Validation is a tricky situation with varying times of processing. For example that 2008 product gives an actual score back to doctors on the score of cancer a patient has (what type and severity). Changes to the platform that may alter the performance of the algorithms being run could cause year's long re-validation. Internal validation as well as support also become overhead which causes these lags.
I do have a question for anyone who may know the networking aspect of things. If I am running 10 instruments (they have Windows PC's running them), would it help to segment off all of our PC's behind a firewall provided by us or a VLAN in order to add additional security from Wannacry, viruses etc. if we are lagging behind the main networks security requirements? Is this a palatable design?
This post was edited on 4/3/18 at 1:32 pm
Posted on 4/3/18 at 2:32 pm to flyAU
Network security is like a chain, only as strong as its weakest link. If you have a set of machines that aren't up to snuff then they should be segmented off in their own vlan.
Posted on 4/4/18 at 8:41 am to jcole4lsu
no need to provide additional comments... jcole4lsu has summed it up to a T
Posted on 4/4/18 at 10:26 am to gmrkr5
So no real way for me to try to forward look at emerging technologies/architectures that could possibly impact a long lifecycle system? I know this is a very subjective topic on how I should try to approach this, but figured I am not the first. Keeping up with specific instances of Windows versions should be easier to rectify (constant validation of new versions). Security and the philosophy of it is ever changing and if there are future theories of how to build a more future looking system, I would love to read about that or hear opinions.
Posted on 4/4/18 at 4:37 pm to flyAU
quote:
future theories of how to build a more future looking system
you need one of these for that
Posted on 4/4/18 at 6:21 pm to flyAU
Is your dev team and systems team the same group?
Does management balk at spending money on sending them to conferences and training? If you have a dev team one step behind thats often the case.
Is your system web based on client server?
Does management balk at spending money on sending them to conferences and training? If you have a dev team one step behind thats often the case.
Is your system web based on client server?
This post was edited on 4/4/18 at 6:26 pm
Posted on 4/4/18 at 6:34 pm to flyAU
Data at rest is best handled on a SAN and encrypted at the hardware level.
Anything forward thinking would likely involve moving to cloud based architecture. But you deal with the federal government. If your auditors are anything like FDIC then I can say it wont happen.
If you are going to downvote at least explain yourself.
Anything forward thinking would likely involve moving to cloud based architecture. But you deal with the federal government. If your auditors are anything like FDIC then I can say it wont happen.
If you are going to downvote at least explain yourself.
This post was edited on 4/5/18 at 8:07 am
Posted on 4/4/18 at 9:10 pm to flyAU
#2 and #3 really are not for IT experts. Basic level 3 hardware can accomplish any network segmentation and security and firewalling and should likely be part of your terminal packages. Im sure in house IT questions WTF are yall thinking a lot.
For #3 why is any math or algorithym or other black box computation platform dependent. It seems there could be a database driven solution (which allows easy updating if diagnostic protocols change) coupled with scripting
Maybe its a bit more complex, i dunno
For #3 why is any math or algorithym or other black box computation platform dependent. It seems there could be a database driven solution (which allows easy updating if diagnostic protocols change) coupled with scripting
Maybe its a bit more complex, i dunno
Posted on 4/5/18 at 7:43 am to flyAU
quote:
How about workstations? Are IT shops in other industries bringing on 10? Or is 7 still the preferred?
I just found out having HH with some IT guys that we will be transitioning to 10 soon. Arghhh
quote:
I am in the drivers seat for the next decade, and this project could help me be a pretty important aspect of the companies future in the IT piece of business.
I'm in a similar position. Fun times. Make sure your boss has your back, and willing to sidebar.
Posted on 4/5/18 at 7:54 am to jcole4lsu
quote:
Network security is like a chain, only as strong as its weakest link.
This is the simplest, and most difficult concept. Crazy.
Just takes that one dumbass sales guy that doesnt follow protocal. Why we have [EXTERNAL] in the subject line from all external emails coming in. BUT STILL...arghhhh ha
Posted on 4/5/18 at 8:37 am to Doubledown11
Depending on their algorithm complexity the OS can definitely cause issues. So can CPU architecture due to cpu security model. Binaries compiled on one system architecture can be very different when compiled on another system.
In most cases its about liability. They dont want to get sued because x=4.999996 instead of x=4.999997.
But if they are regulated by government bodies it changes as well.
In most cases its about liability. They dont want to get sued because x=4.999996 instead of x=4.999997.
But if they are regulated by government bodies it changes as well.
Page 1 of 2
Popular
Back to top
Follow TigerDroppings for LSU Football News