In my article “Data Masking as Part of Your GDPR Compliant Security Posture” over on DEVOPSdigest, I talk about how to mitigate your application’s level of compliance by employing data masking or other pseudonymization techniques of personally identifiable information (PII) like names and email addresses. I suggest giving it a quick read to better understand how that strategy relates to GDPR.
Zenoss as an application does not require PII in order to function, and this compliance strategy is a good fit — however, implementation could be a much larger endeavor. If you are leveraging single sign-on (SSO) mechanisms like Lightweight Directory Access Protocol (LDAP) or Security Assertion Markup Language (SAML), a shift to data masking for user IDs or email addresses can be quite a large undertaking depending on your company’s existing security posture with those data sets. If you are simply managing your users directly in Zenoss, you have much more freedom to assign user IDs and leverage obfuscated email aliases or distribution lists instead.
Of course, when introducing a new application to your infrastructure, it is a perfect opportunity to employ data masking strategies as part of the implementation. Converting from a previous standard to a new one can be a challenge. One approach that I’ve seen be effective is implementing on a go-forward basis and through natural churn over a period of time, minimizing the gap and scope of compliance so a final push for compliance is less daunting.
If you’d like to learn more about Zenoss and how we secure the cloud and the perimeter as part of our ever-strengthening and evolving security posture, consider joining me at GalaxZ18.
