search

chronic-care / mcc-project

MCC eCare Plan project planning and documentation
Apache License 2.0
0 stars 1 forks source link

HTTP response headers: #242

Open swmuir opened 1 year ago

swmuir commented 1 year ago

Matt – just checking in to see how things are going with this. I’ve rerun all scans. Static analysis of just the code revealed nothing new. Dynamic analysis returned the following:

Assuming that you can modify HTTP response headers:

Perhaps this is only present on the dev environment, but try to suppress this in the HTTP response headers in production: server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k

For HSTS (HTTP Strict Transport Security, these are the recommended directive settings: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (though one year for max-age is acceptable)

Current settings: strict-transport-security: max-age=17280000; includeSubDomains; preload

CSP is a tough to do without breaking things, but I would suggest trying the following: Content-Security-Policy: default-src 'self' .ohsu.edu .epic.com; frame-ancestors 'self' .epic.com .ohsu.edu; NOTE: dropped https from the fame-ancestors as HSTS should handle this

Current settings: content-security-policy: frame-ancestors 'self' https://*.epic.com https://*.ohsu.edu;

I can help test and refine this as needed.

JD has done some additional testing (please correct me if I’m wrong here, JD) and found little of consequence.

The recommendations from us would be that, once the application is deployed, to consider putting it behind the web application firewall.

We should also set up recurring scans of the code and the dev environment.

Please let us know if you have any questions about any of this.

Thanks,

Todd Bunce Application Security Technical Lead Information Technology Group | Cybersecurity Engineering & Architecture

savanahmueller commented 1 year ago

Might require more investigation and referring back to security team at OHSU.

This should not prevent OHSU from proceeding with soft-go-live. Need to follow up with OSHU on priority of this task.

Dan is requesting a copy of the scan. Sean will send an email requesting the following:

-Clarify the problem and desired solution. -What is the software? -Is this a blocker? -Can we get a copy of the scan?

swmuir commented 1 year ago

Sent email 1/20/2023 to matt

kbertodatti commented 1 year ago

Not a blocker preventing MyCarePlanner from going to production.

kbertodatti commented 8 months ago

Sent Matt a message 3/6/24 to see if this is still an issue.

mattStorer commented 8 months ago

@kbertodatti we just spoke about this on the tech call, I think perhaps this is still an open issue? not a critical one (indicated that it is not a blocker), but I don't know that anything has been done on it so that would imply that it is still open.

here is the full email thread and the scan report from the email, apologies in advance for the lack of formatting -

MyCarePlanner_ZAP_results_012323.pdf

Haha no worries, it’s all good :)

Matthew Storer (he/him) Research Engineer 2 OHSU Dept. of Medical Informatics and Clinical Epidemiology storer@ohsu.edu | 971-808-2102 (cell/sms)

From: Sean Muir [sean.muir@emiadvisors.net](mailto:sean.muir@emiadvisors.net) Sent: Tuesday, January 24, 2023 10:45 AM To: Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) Cc: Dave Carlson [dcarlson@xmlmodeling.com](mailto:dcarlson@xmlmodeling.com); Dan Brown [dbrown.se@gmail.com](mailto:dbrown.se@gmail.com) Subject: [EXTERNAL] Re: MyCarePlanner

Duh on my part thanks I did not see his response in the email

On Jan 24, 2023, at 10:43 AM, Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) wrote:

Todd said “no blockers,” so I’m presuming that we’re clear to move forward. That’s how I’m interpreting it.

So, something to address, but no stress.

Matt

Matthew Storer (he/him) Research Engineer 2 OHSU Dept. of Medical Informatics and Clinical Epidemiology storer@ohsu.edu | 971-808-2102 (cell/sms)

From: Sean Muir [sean.muir@emiadvisors.net](mailto:sean.muir@emiadvisors.net) Sent: Tuesday, January 24, 2023 10:42 AM To: Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) Cc: Dave Carlson [dcarlson@xmlmodeling.com](mailto:dcarlson@xmlmodeling.com); Dan Brown [dbrown.se@gmail.com](mailto:dbrown.se@gmail.com) Subject: [EXTERNAL] Re: MyCarePlanner

Thanks

Is this a real blocker ? Our resource working on this is out of the office this week

So currently we will not address until next week - if that is ok

Sean

On Jan 24, 2023, at 9:37 AM, Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) wrote:

Hey Dave, Sean –

Good morning. FYI please see below and attached for the requested information from ACC folks re: the security scan, etc., and let me know if you have any questions.

Thanks –

Matt

Matthew Storer (he/him) Research Engineer 2 OHSU Dept. of Medical Informatics and Clinical Epidemiology storer@ohsu.edu | 971-808-2102 (cell/sms)

From: Todd Bunce [cooperje@ohsu.edu](mailto:cooperje@ohsu.edu) Sent: Tuesday, January 24, 2023 9:16 AM To: Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu); JD Burchett [burcheja@ohsu.edu](mailto:burcheja@ohsu.edu) Subject: RE: [EXTERNAL] Re: MyCarePlanner

Morning Matt,

• Open Web Application Security (OWASP) ZAP; StackHawk • MyCarePlanner scan results (let me know if you can’t access) • no blockers

Todd

From: Matthew Storer Sent: Friday, January 20, 2023 11:28 AM To: Todd Bunce [cooperje@ohsu.edu](mailto:cooperje@ohsu.edu); JD Burchett [burcheja@ohsu.edu](mailto:burcheja@ohsu.edu) Subject: FW: [EXTERNAL] Re: MyCarePlanner

Hey Todd, JD –

Good morning, and happy Friday! I hope you’re both doing well.

Please see below for some questions from the app developers with respect to the recent request regarding the MyCarePlanner app.

I think you all were pretty clear about the desired solution, and I think I clarified that question of theirs, but if you can a) tell me the name of the software used to perform the scan, b) provide a copy of the scan report, and c) tell us if these issues constitute blockers for the app moving forward for our go-live next week, that would be very helpful.

Thanks, and please let me know if you have any questions.

Matt

Matthew Storer (he/him) Research Engineer 2 OHSU Dept. of Medical Informatics and Clinical Epidemiology storer@ohsu.edu | 971-808-2102 (cell/sms)

From: Sean Muir [sean.muir@emiadvisors.net](mailto:sean.muir@emiadvisors.net) Sent: Friday, January 20, 2023 10:02 AM To: Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) Cc: Dave Carlson [dcarlson@xmlmodeling.com](mailto:dcarlson@xmlmodeling.com); Puster, Eric [epuster@rti.org](mailto:epuster@rti.org); MJ Dunne [dunnem@ohsu.edu](mailto:dunnem@ohsu.edu); Dan Brown [dbrown.se@gmail.com](mailto:dbrown.se@gmail.com) Subject: [EXTERNAL] Re: MyCarePlanner

Hi Matt

We had a discussion on our team this morning on the issue and had some questions

Thanks

Sean

On Jan 17, 2023, at 8:49 AM, Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) wrote:

Hey Dave, Sean –

Good morning. I hope you’re both doing well.

FYI, I have some tasks that I believe fall under your collective purview that are requested to be addressed in the MyCarePlanner container by our security team. Please see the thread below for details (in particular the part that I highlighted), and let me know if you have any questions.

Thanks –

Matt

Matthew Storer (he/him) Research Engineer 2 OHSU Dept. of Medical Informatics and Clinical Epidemiology storer@ohsu.edu | 971-808-2102 (cell/sms)

From: JD Burchett [burcheja@ohsu.edu](mailto:burcheja@ohsu.edu) Sent: Tuesday, January 17, 2023 8:08 AM To: Todd Bunce [cooperje@ohsu.edu](mailto:cooperje@ohsu.edu); Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) Subject: RE: MyCarePlanner

Good morning Matt,

I ran StackHawk against the MyCarePlanner app and it did not identify anything that needs to be addressed in the application.

Regarding some of the other things Todd mentioned, I suspect those are settings that would need to be modified in the container image as they related to the Apache webserver.

Please let me know if you need any additional information on that.

Thanks,

--JD

JD Burchett System Engineer OHSU ITG Cybersecurity

From: Todd Bunce Sent: Friday, January 13, 2023 10:13 To: Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) Cc: JD Burchett [burcheja@ohsu.edu](mailto:burcheja@ohsu.edu) Subject: RE: MyCarePlanner

Unfortunately, I’m not sure how these things are handled within containers. I’ll make a note for myself to research this. JD- do you have any ideas?

Todd

From: Matthew Storer Sent: Friday, January 13, 2023 10:42 AM To: Todd Bunce [cooperje@ohsu.edu](mailto:cooperje@ohsu.edu) Cc: JD Burchett [burcheja@ohsu.edu](mailto:burcheja@ohsu.edu) Subject: RE: MyCarePlanner

Hi Todd –

Good morning. Thanks for reaching out about this.

I am guessing that, as browser resources are served from within a Docker container, that the changes will need to be made to the system serving those resources from the container. With that assumption, this sounds like a task I will need to pass on to the developers so that they can adjust how those resources are served. Does that sound right to you?

Your mention of CSP tagging OHSU and Epic specific domains, that sounds like that would not be something that is handled within the container. Perhaps that would be handled by the HTTP <-> HTTPS proxy that ACC set up for us?

Where should these changes be made? This is not my field of expertise.

Thoughts?

Thanks –

Matt

Matthew Storer (he/him) Research Engineer 2 OHSU Dept. of Medical Informatics and Clinical Epidemiology storer@ohsu.edu | 971-808-2102 (cell/sms)

From: Todd Bunce [cooperje@ohsu.edu](mailto:cooperje@ohsu.edu) Sent: Friday, January 13, 2023 9:08 AM To: Matthew Storer [storer@ohsu.edu](mailto:storer@ohsu.edu) Cc: JD Burchett [burcheja@ohsu.edu](mailto:burcheja@ohsu.edu) Subject: MyCarePlanner

Hi,

Matt – just checking in to see how things are going with this. I’ve rerun all scans. Static analysis of just the code revealed nothing new. Dynamic analysis returned the following:

Assuming that you can modify HTTP response headers:

Perhaps this is only present on the dev environment, but try to suppress this in the HTTP response headers in production: server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k

For HSTS (HTTP Strict Transport Security, these are the recommended directive settings: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (though one year for max-age is acceptable)

Current settings: strict-transport-security: max-age=17280000; includeSubDomains; preload

CSP is a tough to do without breaking things, but I would suggest trying the following: Content-Security-Policy: default-src 'self' .ohsu.edu .epic.com; frame-ancestors 'self' .epic.com .ohsu.edu; NOTE: dropped https from the fame-ancestors as HSTS should handle this

Current settings: content-security-policy: frame-ancestors 'self' https://*.epic.com https://*.ohsu.edu/;

I can help test and refine this as needed.

JD has done some additional testing (please correct me if I’m wrong here, JD) and found little of consequence.

The recommendations from us would be that, once the application is deployed, to consider putting it behind the web application firewall.

We should also set up recurring scans of the code and the dev environment.

Please let us know if you have any questions about any of this.

Thanks,

Todd Bunce Application Security Technical Lead Information Technology Group | Cybersecurity Engineering & Architecture