(AUDIT) `run.properties` : review infosec ramifications of information coming from asgs

[jasonfleming]

We produce and post a lot of information to open thredds servers that could be exploited to negatively affect our people, processes, systems, services, and products. This information should be reviewed to facilitate to identify and correct the leakage of sensitive information.

[wwlwpd]

Sounds good; I will produce an audit with this information plus some initial recommendations.

[wwlwpd]

@jasonfleming one thing that I think will make this difficult to some degree is that we use run.properties as a communication medium - i.e., any time a called script reads run.properties and gets values from it. This needs to be addressed I think before we can treat run.properties as a sink for sanitized data. Any thoughts or questions on? For this case, I'll sanitize what I can safely.

[wwlwpd]

Quick list of run.properties that contain $USER:

config.file
operator
path.adcircdir
path.scriptdir
path.inputdir
path.outputdir
path.scratchdir
monitoring.rmqmessaging.script
monitoring.rmqmessaging.scriptrp
monitoring.rmqmessaging.ncohome
monitoring.logging.file.syslog
post.file.sshkey
archive.path.archivebase
archive.path.archivedir
path.rundir
path.cycledir
path.scenariodir
monitoring.logging.file.cyclelog
monitoring.logging.file.scenariolog
asgs.path.advisdir
asgs.path.stormdir
path.advisdir
path.stormdir
directory
hpc.job.prep15.file.qscripttemplate
hpc.job.prep15.joblog

Email addresses are exposed in:

notification.opendap.email.opendapnotify
notification.email.asgsadmin

[wwlwpd]

@jasonfleming and @carolakaiser - can you both look at the above list of run.properties values, and tell me if redacting them (e.g., sanitizing $USER and email addresses) would break anything downstream of the ADCIRC results?

[carolakaiser]

@wwlwpd I went through the list and it seems that CERA would not be affected by any changes to these key/value pairs. Thanks.

[jasonfleming]

Hey @wwlwpd, the slide deck is the only downstream app that I can really check, I will do that now (it does use the run.properties file). The other use for posting the full run.properties file is for real time troubleshooting and peer review, although those are manual processes, and are not critical. I like the idea of a private run.properties file that is used internally by ASGS that gets filtered/redacted before being posted for opendap service.

[jasonfleming]

@wwlwpd I had a look at the list of properties above, and went through the slide deck workflow. It does not use any of those properties, which is great. However, we do not have a defined list of properties (i.e., a documented interface or "contract") with data consumers. Or an SOP for changing such an interface. I am in favor of redacting the properties you've listed whenever you are ready, but at a minimum, we should also announce it as publicly as possible, e.g., send an email to asgs-operators to give a heads up.

[wwlwpd]

I agree, maybe we can slate this for post-season?

[jasonfleming]

I agree.

[wwlwpd]

I think the best result out of this issue is to:

1. have a set of best practices for minimizing personal information on public files/locations
2. some standard developer practices to help mitigate this

Simply listing these things and doing our best here, coupled with making users aware of the very public nature of this repo and activity sounds sufficient to me.

[jasonfleming]

This does not seem to be resolved. I think it is resolved in the status files but not the run.properties.

[wwlwpd]

Yeah, this is a very hard to define target. I think doing it by file (like run.properties) and just making it a best effort is all we can do.

[wwlwpd]

I added run.properties as the target for this, maybe once this is done we can identify another file to clean up.