Encryption and inbound emails

KB15
Giga Guru

We're looking to encrypt all of our attachments including any inbound messages that have attachments. We can get attachments encrypted if workers are making changes within the console however we've hit a wall in encrypting inbound emails. The crux of the issue issue seems to be the inability for the system to impersonate someone who has the ability to encrypt.

 

Has anyone attempted this level of security and was anyone successful in automating encryption for all attachments and inbound email attachments?

12 REPLIES 12

Hari,




I guess I was overthinking the backward compatability thing!   It worked!   Thank you so much.   For reference for others, this is my Busines RUle for automatically encrypting attachments - Pre-Calgary.




Thanx again - you've made my summer!




//Retrieve encryption context   -   Pre-Calgary release.


//   set security context on fields


encryptAttachment();


function encryptAttachment(){


    var encryptionID = getEncryptionID("pos_bus_partner");


    if (encryptionID == "") {


          gs.log("Failed to set ecryption context");


          return;


    }


    var sysAttachment = new Packages.com.glide.ui.SysAttachment();


sysAttachment.changeEncryptionContext(current.getValue("table_name"), current.getValue("table_sys_id"),current.sys_id, encryptionID);


}


function getEncryptionID(encryptionName) {


    var contextGR = new GlideRecord("sys_encryption_context");


    contextGR.addQuery("name", encryptionName);


    contextGR.query();


    if (!contextGR.next()) {


          gs.log("*********** No such encryption context " + encryptionContextName);


          return "";


    }


    return contextGR.getUniqueValue();


}


Glad to be of help


Hi Sandy,



You can check the below wiki article for "Packages Call Replacement Script Objects"


http://wiki.servicenow.com/index.php?title=Packages_Call_Replacement_Script_Objects



I hope this helps



Thanks,


Pradeep Sharma




At a very high level, the solution was found which involved the following. Note: I'm trying to do this all from memory otherwise, I would have shared the code. I no longer have access to the instance.



  • A dummy encryption user
  • A JavaScript function that would manually call the encryption command
  • A business rule that would check for any messages that had an attachment and initiate the encryption process
  • Encryption application that handled the settings: user account, to be used as well as which tables to encrypt from (i.e. knowledge, incident, change, etc), encryption context, etc.


As messages came in, any attachments were automatically encrypted using the dummy account that was setup specially with the encryption role.



One issue that we ran into was that our instance was blocked from external IP addresses including any internal SN servers. This actually broke the encryption process. To get around it, specific IPs or IP ranges needed to be added in order for the encryption to work. I'm sure that most wouldn't need to do that.



This is high impact on the system so attempting to run encryption across already existing attachments will take the instance down for a substantial period of time. Individual attachments, however, have minimal impact.


Michael Domke
Tera Guru

Was there any solution to overcome the impersonating issue with inbound emails? I'd like to encrypt attachments, but the person sending the email may not have a role with that encryption context.