Important Update: Some Community URL Redirects are Under Maintenance. Learn More. .

cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

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.

 

pastedImage_4.png

 

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.

 

pastedImage_1.png

 

 

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:

pastedImage_3.png

 

 

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
NeilJordan
Collaborator III

This sounds absolutely awesome. Can't wait to try it! I have about a dozen Scheduled Tasks running PowerShell scripts that I could potentially replace with this. I'll have to brush up on my JavaScript though.

Anonymous
Not applicable

Neil,

 

Thanks for the feedback! We think it's pretty awesome too. Once you have had a chance to use it, let me know what you think. This area of custom integrations is something I'm personally passionate about and want to keep pursuing, so if there are changes or enhancements to be made to support that, I'm all ears!

syedtahir16
Advocate

Thank you for the article, Scott! This is awesome. Can't wait to begin writing the first integration using this transporter.

Anonymous
Not applicable

Syed,

 

Glad you like it! Once you've written your first one, let me know what you think. Lots of directions we can go from here, and feedback from the client base will help steer our direction.

 

Happy Archering!

arnab.nandy
Collaborator III

Awesome.

Thanks a lot Scott!

Anonymous
Not applicable

You're welcome. Happy Archering!

KyleCribbs1
Collaborator III

We are excited to use the JavaScript transporter. Since there are only a few libraries that are white listed, is there a way for us to add/whitelist additional libraries.

Anonymous
Not applicable

Kyle,

 

At this time, there is no way for Admins to specify a custom whitelist. We took a secure by default approach for the first iteration of this feature. If you'd like to request the ability to custom whitelist libraries for this feature, please check for the Idea over on RSA Ideas for the RSA Archer Suite" data-type="space‌ and vote for it, or create it.

KyleCribbs1
Collaborator III

Thanks for the quick reply Scott! I have some feedback regarding the Javascript Transport. It seems the sample file has some errors in it (i know its just a sample, but just a heads up). Also, if i run a Transport Only data feed the JavaScript runs forever. How do I successfully create a "Push" script that ends when it ends.

KyleCribbs1
Collaborator III

We kind of figured it out. a callback is required and the output had to be a buffer for it not to fault for us.

callback(null, {
    output: new Buffer("this is a test")
});

 

does console.log() display anywhere for troubleshooting a script?

Anonymous
Not applicable

Kyle,

 

The Sample file attached to the platform is intentionally non-functional. It is only meant to show you the basic structure of the script file Archer requires in order to run, and the basic methods for accessing different things like the whitelisted libraries, the custom variables, and the data feed tokens.

 

You are correct that a callback is required in order to tell Archer you are done. Please check out the following documentation that further details how these feeds operate:

 

The callback output should not need to be a buffer for the script to stop and the feed to complete. Archer should be more than happy with your output being null or a string as well.

 

Archer runs the script in a protected Sandbox, so console.log() is not available to you while Archer is running the script. You would need to use a different IDE to debug your script, then pass it on to Archer to run.

JamesByroads1
Contributor III

Hey Scott Hagemeyer‌.  Great feature add for sure!  I am the hack developer you speak of , but want to be clear on one point.  I'm making a call to an API that provides a response in JSON format (not enclosed in XML tags).  When I write my xslt, do I need to write it with the understanding that Archer is going to wrap the JSON in an XML <root> node?  I'm going off of this line in the admin guide:

For JSON that is not enclosed in the XML node, input is added inside the <root> node. Characters
are encoded according to the XML specifications.

So does that mean if my raw response is {"color":"red"}, then the xslt for Archer needs to be written for <root>{"color":"red"}</root>?  Hopefully this makes sense.

Anonymous
Not applicable

James,

 

Glad you like it. You have a couple of options here.

 

First, you could use the libraries provided within the JS Transporter to convert your JSON to XML and apply any other business logic before passing the data back to Archer, and then there would be no XSLT necessary.

 

Or, you can use an XSLT like you specified. We will put the JSON you send inside of a <root> node just like you specified.

 

Happy Archering!

HabtemichaelZel
Contributor

Hey Scott Hagemeyer‌  ,  Good feature! I'm new to Archer and trying to utilize this feature. But am getting "The script execution failed due to an un-expected error" message. Any idea why??

as hint:  I download the script template from Transporte--JavaScript Sample, then Added my part on it. 

I have also uncheck "Allow only digitally signed JavaScript files" check box to load unsigned JS file in RSA control panel.

 

Thanks!

Anonymous
Not applicable

This means your JavaScript experienced an error while running in the sandboxed job. Could be anything from accessing an empty variable, to syntax, or a bad HTTP web request. I would suggest validating your JavaScript in something like VS Code first, to ensure it will run to completion before you load it into Archer.

KrantiRanginen1
Collaborator II

Hey Scott Hagemeyer

 

I am trying to schedule an export of a report from Archer and push it as a CSV file into a particular location / folder as a daily batch file. Is this possible through the JavaScript Transporter data feed type? If yes, do you have any documentation around this for Archer v6.4?

JoyVanBuskirk
Collaborator II

Hi Scott,

I saw the mention of only a few libraries being whitelisted. I know JQuery is added into the structure of the Archer platform. Since it's not in the list of allowed libraries, should I assume it's not available for use in the Javascript feeds? Also, am I correct in thinking that we can't reference JS script files on the Archer server that we wrote (so as not to duplicate code in a bunch of different Archer JS feeds)? 

Anonymous
Not applicable

Joy VanBuskirk,

 

That is correct on both counts. Only the prescribed libraries allowed, and JST feeds have no access to jQuery or other files that may be present on the server.

JoyVanBuskirk
Collaborator II

Thank you for confirming! Now I won't spend any time trying to make something work that can't.