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

cancel
Showing results for 
Search instead for 
Did you mean: 
JamesGriffith
Archer Employee
Archer Employee

One of the lesser known items in the RSA Archer 6.3 release is the introduction of the Diagnostics and System Data capability. This is a feature through which the Archer platform collects information about itself and makes this available to RSA for analytical purposes. Now, in an age where we grow increasingly alarmed about what is happening to our information, this might create questions, and so I wanted to publish this Archer Insight in order to explain a bit more about the data that is collected and why it will be valuable to everyone in the RSA Archer Community to know this is being done.

 

First, let me explain the mechanics of the data being collected. This is the sort of information which some of you may need to be able to talk about to IT Gatekeepers and Network Admins. Your Archer deployment is spread across a collection of servers in different roles: web, services (of various types) and database. The Diagnostics and System Data process runs within the Job Engine (the job is named TelemetryJobWorkflow) and collects its information from different parts of the system. Once it has collected this information, it does one of two things:

 

  • If automatic uploads are enabled, it connects to RSA, authenticates and then uploads an encrypted file containing the data to a Cloud Service.
  • If automatic uploads are disabled (or any errors are encountered in the automatic upload process) the unencrypted file is written to the Archer file repository. From there you can manually retrieve it so that you can submit it to RSA manually.

 

What data is being collected and why

Transparency is important. If RSA is to collect information about customer deployments of Archer, we need to be clear about what we are collecting and why we need it. One of the key things to be aware of is that the information being uploaded to RSA is also visible to the environment admins. The infrastructure which is capturing the data is closely related to the Archer Configuration Report (ACR) capability. The ACRs that have been generated are stored for a time in the database, and now, in 6.3 and up it is also possible see the data captured for the Diagnostic and System Data reports in the same location. Additionally, you can find a sample file from one of our test systems attached to this blog post.

 

The kind of data being captured is system level information. Think number of users, number of ODAs deployed, number of records and mix of OS’s that are being used. This information will help RSA to better understand what real world Archer deployments look like and when to extend support for certain versions of SQL Server or Windows or when to deprecate them. This in turn will enable us to accelerate our innovation to take advantage of new capabilities in the underlying software that powers Archer. As we become more sophisticated in understanding the data, we will be able to watch for trends and potential problems ahead of time. For instance, if we had an issue that was affecting a particular version of Windows, we could proactively reach out and warn affected customers about it. It will also enable RSA to improve the technical support experience for our customers: once this incoming information is fed into the support team's hands, they will be able to diagnose many configuration issues immediately, without lengthy troubleshooting or requests for files.

 

Data Security

It should be stressed that even though the sort of information which the Diagnostics and System Data feature is capturing does not contain personal identifiers of any users, it is still treated with great care. To this end, we have added additional obfuscation on the data before it is sent to us. So, for instance, while your Windows Administrator might open up the ACP and see that the queueing service was running on SERVERNAME.COMPANY.COM, and that that server existed at a particular IP address, we suppress that sort of information before uploading it. RSA will not receive server names, IP addresses or application names from customer systems. And once the data is received by our cloud service (in an encrypted file) it is removed from the cloud within 24 hours and loaded to a datastore within RSA’s corporate network where it is decrypted and to which only a controlled group of analysts have access.

 

The Long Haul

Fundamentally, the reason for introducing the Diagnostics and System Data capability is to enable the RSA Archer product team to make better decisions about new features and other improvements to the platform. This can be done best through collecting information about what the install base looks like. A recent project had several discussions around a question about how big the “average” OnPrem database was. We had to admit, we didn’t know. Getting closer to the customer-base and understanding the data better will improve the quality of the product, the effectiveness of new features and the speed at which we are able to introduce them into the market.

 

Which is what we all want to see 

 

RSA Archer Release 6.3 includes new use cases for Regulatory & Corporate Compliance Management, updates to existing Business Resiliency use cases and Public Sector Solutions use cases, and enhancements for usability and stability of the RSA Archer Platform. RSA Archer’s two newest use cases, RSA Archer Data Governance and RSA Archer Privacy Program Management, are designed to help support customer processes for data protection and addressing applicable privacy directives, such as GDPR. Updates to RSA Archer Business Resiliency use cases are designed to help improve organizations’ ability to manage disruptions and crises. Enhancements to the RSA Archer Platform include a system administration dashboard, bulk record operations, and direct to edit capabilities.