The Australian Signals Directorate includes Application Whitelisting in its 'Essential Eight' protective security framework. Other Five Eyes governments have similar recommendations.
In particular, DLLs must be whitelisted on secure networks and the whitelist should be on the DLL's hash. Since R makes heavy use of DLLs and since users may require thousands of DLLs (and ongoing updates), how should R users and ICT providers best handle these requirements, particularly on Windows?
Does the community know of any best practices for maintaining secure practices while still being workable? I'm particularly interested in using R on data classified up to PROTECTED, but I'm guessing that working with highly classified material may not be that different.
This is a really interesting question. I am unfamiliar with these types of security protocols (and much of Windows), but I presume you are talking about the DLLs downloaded from CRAN with binary versions of packages for Windows?
Do you get anything helpful with regards to these security protocols if you build the packages from source yourself? I.e. you download the source code for the package and build the DLL yourself?
Do you get anything helpful with regards to these security protocols if you build the packages from source yourself? I.e. you download the source code for the package and build the DLL yourself?
I don't think so. At the point of choosing whether or not to use a binary or source version, the DLL would already have been approved. My question is more about how ICT can usefully process what are effectively thousands of software requests (i.e. one per package per version) for approval / rejection when a user wants to use CRAN packages or write one's own. Is there something particular about CRAN or R that might limit how long a formal security approval process would need to run both at the outset and for package updates?
Relatedly, does the NSA or other national security agencies publish a list of approved R packages for use in classified or other environments?
I'm not sure what will be most helpful here - I unfortunately am unaware of any list of "approved R packages" for use in classified / other environments. Most organizations end up with their own somewhat varied classifications based on license, authorship, organization sponsorship, testing approaches, scope of testing coverage, did it go through a virus scanner, etc.
CRAN itself does have a rather stringent set of security requirements, and CRAN package approvals are maintained by humans (i.e. no auto-approval for a first time package submission, etc.). Many organizations trust the CRAN check / validation process as sufficient to limit the length of their own formal security process.
One of the focuses for RStudio Package Manager (enterprise software created by RStudio) is to give organizations the type of tooling that they need to marshal these conversations and review processes, approve a subset of packages / versions, and then serve those to users with minimal overhead.
In particular, what this flow might look like in an organization such as yours:
define some type of rules around excluding certain package sets
define rules around accepting certain package sets
build an "initial list" of packages as a proposal (Package Manager calls this a "curated repo" and will generate the list of information for you with the CLI)
review the proposal / review / modify / approve as necessary
serve only the approved packages to your internal infrastructure
have some process by which additions to the approved list can be requested and evaluated