Continuing the RSA Archer Platform 6.4 feature series of blog posts and Free Friday Tech Huddles, and piggybacking off my blog yesterday https://community.rsa.com/community/products/archer-grc/archer-customer-partner-community/blog/2018/04/30/xslt-30-support-with-rsa-archer-64?sr=search&searchId=6b2abb75-f257-495a-9c2e-99c2a5ca7e38&searchIndex=1, I want to provide a closer look at another one of the several enhancements to Data Feed Manager that is included in RSA Archer Platform 6.4.
JavaScript Transporter represents both the first substantial enhancement to the Data Feed Manager in many years (well, right behind XSLT 3.0 anyway!) as well as a fundamental paradigm shift in how you should think about Data Feed Manager and it's role in your environment. No longer is that data sitting behind an API requiring multiple calls out of reach. No more should you have to write and host middle-ware to bridge the data gap between Archer and another system. Never again should Data Feed Manager be thought of as purely an ingest only engine limited to a single file.
Excited?! Me too. Let's dive in.
The JavaScript Transporter allows RSA Archer Admins to attach JavaScript files to RSA Archer data feeds for execution of the script and consumption of the resultant data set (if there is one, but more on that later). I know what the security folks are thinking right now: "You've enabled RSA Archer to run JavaScript files from any hack developer who can piece together enough Stack Overflow snippets to get something functional?!". So before we get to the gooey center of this delicious chocolate truffle and talk about what this feature can enable you to accomplish, let me first take a few paragraphs to address the shrewdness of apes pounding their chests and hollering about security (figuratively, of course, security folks 
) that has undoubtedly entered the room.
By design, this feature is entirely inoperable until one of two changes is made in the Archer Control Panel (ACP) for the instance: Providing one or more trusted certificate thumbprints in the whitelist, or disabling the signing check. For details on how to configure JavaScript Transporter, please review the RSA Archer 6.4 Platform Administrator's Guide section for "JavaScript Data Feeds" and the ACP Help section "Configuring JavaScript Transporter Settings". I'll explain high level what the safety checks are below.
First, to prevent untrusted JavaScript from being executed in your environment, we provide the ability to enforce digital signatures on the JavaScript files be validated against an approved whitelist. If enabled (which is the default), signature validation is done against the JavaScript file on every upload and execution attempt. If the check fails, the file is immediately blocked and removed from the system.
Additionally, we've sandboxed the execution of the script, which enables us to put limits on what libraries are available for access, as well as set limits on how much memory a JavaScript Transporter feed can consume and how long it can execute. The approved libraries list also takes a whitelist approach, with the currently approved modules being request, xpath, xmldom, and xml2js. The memory limit and timeout values default to 2 Gb and 6 hours, respectively, but are configurable as low as 1 Gb and 5 minutes, respectively, with no maximum.
Finally, the script execution job runs as its own job type within the system. Making use of the Job Engine filters, you could then direct this job to only execute on a specific server in your environment, and that server could contain whatever isolation and/or additional security measures your company feels is necessary to support execution of the job.
If none of these safeguards are up to snuff, please tell us about it so we can decide how best to update the feature to get it there! If desired, the transporter type can be disabled altogether on the Data Feed Settings tab of the instance settings.
Now, about that truffle... JavaScript is an incredibly powerful, and popular, scripting language, so it makes sense for the RSA Archer platform to embrace it. You can already use it today in Custom Objects and Custom Type iViews to control what you see on the screen, so the next extension was to enable its use for your data and systems. If you can write the script to do it, Archer will now process that script on your behalf. Let's take a look at an example to illustrate the power.
The Rapid7 vulnerability scanner contains a lot of data that one doesn't necessarily want to just "dump" over to RSA Archer in raw format, and getting the owners of the scanner to produce an extract you can use or writing an XSLT to transform what they will give you into something usable has been a fruitless endeavor. Now, with JavaScript Transporter, you can write JavaScript to perform all of the necessary API calls out to Rapid7 to login, pass that session back to request data, filter and collect the returned data, issue subsequent calls for details, and finally aggregate the data to be passed back to Archer. Visually, JavaScript executed by Archer facilitates this process:
But this is just one example of how JavaScript transporter can be used. Remember how I said it fundamentally shifts the paradigm of Data Feed Manager as a single file, out to in system to something else? That's because the result of the executed script does not have to be a data set. Archer is perfectly happy with the script returning an empty data set, or only interacting with external systems, or only pushing data out of Archer somewhere else. This piece of JavaScript Transporter, that your data feed does not have to procure data or even interact with Archer at all, is what really unlocks the Data Feed Manager.
With JavaScript Transporter, all of the below scenarios, and more, are valid uses:
- Push Archer data to an external system or systems, return nothing and exit
- Pull data from multiple external systems all at once, aggregate together and return final data set to Archer
- Both pull and push data to and from Archer and external systems in one process
- Interact with several external systems to move data from ExtSys1 to ExtSys2, but not involve Archer, return nothing and exit
- Create data feed "middle-ware" that provides a timer-based (feed frequency) integration with an external system, such an EMNS tool
I hope you are as excited about this feature as I am, and additionally hope you'll join us on the upcoming Free Friday Tech Huddle sessions to see this, and other, features in action, as well as stay tuned to the blog for more updates on these exciting features of RSA Archer Platform 6.4!
Happy Archering, everyone!
UPDATE: The slides from the Free Friday Tech Huddle where this was covered are available here: FFTH - May 4, 2018 - Integration Improvements
19 Comments
