Req: Legal implications within cross-country deployments
Does anybody have information/knowledge on the subject of cross-country transports/processing of security related monitoring information in relation with legal aspects within Europe and how these legal implications are adressed within ArcSight?
I have read about fields obfuscation and know about role based access to certain data. Any thoughts?
It has to do with privacy in relation to country-to-country transports and processing within the EU.
Are there any legal implications and if yes, how should that be adressed with Arcsight in terms of deployment, encryption and/or fields obfuscation.
This is not the full or current end-all answer to this, with that in mind I once held the position "Worldwide BETA Release Manager"
for the first port of AT&T UNIX to a new Intel chip. There are three things I remember from those days.
1) Probably the Main issues we ran into were with regard to encryption algorithms. At that time we had developed an encryption
algorithms that one EU country couldn't crack, and since we (the US) were transmitting encrypted data across that country they
were mad because they could not decrypt it. For this reason (our privacy) we had to make sure that the algorythms weren't exposed.
2) Certain labels with certain words had to be on the boxes, basically stating that the encryption algorithms were not included, and that
"AT&T UNIX was the property of AT&T", now, in a sense pure UNIX no longer exists. These words would be very different now, and probably
3) Be aware that your Shipping and Receiving have probably been given strict instrutions on how to handle these kind of shipments, and may hold
your stuff and not notify you. We got numerous emails, which eventually became more and more agitated about not receiving these packages
until we figured out that Shipping and Receiving was holding the boxes hostage.
Again this is more of a history lesson, but it may provide some insights. Personally I would love to hear from an Arcsight Employee what restrictions are being employed to keep such a powerful and critical tool out of the wrong hands. I am sure this is a big issue that is well addressed by ARST.
Another source for info about current issues would be the DOD.
Thanks for your answer David, but I'm more looking for information on the data part.
So, if I deploy ArcSight ESM with connectors and loggers across several countries within one corporation in Europe and the data is crossing borders, are there any legal restrictions for this data in transit, storage and processing? If so, how are these legal issues to be adressed with Arcsight?
I understand your question, and what kind of experience you're trying to tap from this forum. Unfortunately I don't have that real experience myself, but while awaiting any other answers, I can just answer using the concept of the obfuscation and architecture.
AFAIK, the field obfuscation feature in the connectors was designed specifically for this requirement. Certain countries - Germany is often mentioned - require that Personally Identifiable Information is not transmitted outside the state borders. I suspect you're looking for the specifics on a case-by-case basis, including fields and countries - and that's what I don't have. I would have thought some people here do. However, since it's a generic question that applies to all products, maybe you can ask on a wider SIEM forum. I hope there would be some consultancy reports on this too.
Anyway - the general architectural approach is that you would have connectors and a Logger in, say, Germany, and an ESM in, say, the US. The connectors would have 2 destinations - the local Logger, and the US ESM. The local Logger would be unobfuscated, whereas the destination for the US ESM would have obfuscation for Target User Name, sometimes Attacker User Name, and probably quite a few others, dependant on device.... Probably message and raw fields, if used, in case these include the same data. Also watch for Custom Strings.
In deployment practice, you can likely step through the connector guides looking for PII fields, and obfuscate those. You could also set up a short-life temp storage group in the Local Logger for piloting, to receive the obfuscated stream as a duplicate feed for a couple of weeks, and after that time, do some searches for PII data within the events and ensure that nothing comes up (as it's obfuscated). Document this testing. Once you're comfortable that it's tested and working, you can redirect that connector to the remote ESM.
For operational use, the remote ESM analyst would have to contact a local security analyst in-country to look at those events, including the PII data. They would likely have cases created automatically and assigned to the German team, who can then query those in the local Logger (eg. using right-click in ESM Console) using their full access, and update the case with their findings. You could get a streamlined, fully compliant workflow this way.
Sorry if I'm stating the obvious - hopefully it might spur the discussion, and even if you're aware of this, I guess there are a few others here who might find it informative 🙂
I am in a similar situation to address abfuscation of fields,
I was happy to read that someone already talked about this matter, Also I got couple of doubts when I read your reply.
1. When you try to get information obfuscated (or regular ) fields from ESM Console would it not again send obfuscated information.
and if the sensitive fields are sent without obfuscation then the whole purpose fails.
2. Is there any deObfuscation kind of feature at the ESM end if not then how to achieve correlation on the obfuscated field.
You would be halping a lot if you can reply to this asap.
Thanks and Regards,
Yes, you're right, it would be obfuscated. You would have to use some unobfuscated field that you can use to search in Logger - I wonder if the rule ID could be used as a simple single field to link between the ESM and Logger events. Ah - actually I mean something like Vendor Name and vendor product's session ID, to identify the unique transaction/session on that device.
I have suggested in the past for us to support encryption rather than obfuscation, so that an authorised analyst could unencrypt the data fields using a privat key. If you would also like to see this, add a support ticket to request this.