devopsy.kinsta.cloud

Tag: GDPR

  • Building Continuous Compliance into DevOps

    Building Continuous Compliance into DevOps

    “Continuous” is one of the operative words of DevOps. A major goal of DevOps is to make all processes continuous, which means having them proceed smoothly and constantly to avoid delays or pauses within the software delivery process.

    You’ve probably already heard of the importance of continuous integration and continuous delivery. But the importance of continuousness doesn’t end there. It extends to every component of the software delivery process, including compliance.

    To illustrate the point, let’s take a look in this article at what continuous compliance means and how to achieve it.

    Defining Regulations and Compliance

    Regulations and compliance are two sides of the same coin. Regulatory bodies put in place regulatory laws and policies that are aimed at the benefit of the broader economy and end consumers. Organizations under the purview of these regulatory bodies must put a compliance framework in place to meet regulatory requirements.

    Here are three of the most widely applicable regulatory requirements that organizations commonly need to adhere to today:

    HIPAA

    HIPAA, or Health Insurance Portability and Accountability Act, is applicable to healthcare organizations. It concerns the handling and protection of PHI data (Protected Health Information). The costs for mishandling healthcare data are steep for users. According to research done by Accenture, 26% of healthcare consumers were subject to data breaches, and it cost each victim an average of $2,500. Stats such as this make a strong case for HIPAA compliance.

    PCI DSS

    The PCI DSS (Payment Card Industry Data Security Standard) is a regulation for the financial services sector. It governs the use and handling of users’ financial data, such as credit card information and bank account information.

    GDPR

    The GDPR (General Data Protection Regulation Act) went live in the European Union in mid-2018. It defines policies related to how organizations handle data of users in the European Union. This includes giving customers the right to erase all their data from a company to ensure the organization doesn’t have indefinite possession of the data and to ensure confidentiality of users’ private information.

    Why Continuous Compliance?

    Cloud-native computing brings new complexities to how applications are delivered and how they handle user data. For starters, the scale of data flowing through the system at any given time is now much higher. How organizations and their applications manage this data is critical to compliance.

    Audits can be outdated the very next day when dealing with such dynamic systems. For example, when new releases are deployed continuously, it’s easy for one release to expose an endpoint to a third-party application and leave sensitive data accessible to outsiders.

    The regulatory requirements themselves change every few months. It’s important to keep track of these changes and adapt your systems to still be compliant. In light of this, it’s necessary to adopt continuous compliance as part of any DevOps workflow.

    Achieving Continuous Compliance

    Two Goals: Security and Speed

    It’s easy to think of compliance as being about simply meeting regulatory requirements. However, this is far from true. When done properly, compliance also empowers your organization to operate at a pace that encourages innovation. Every organization that adopts DevOps wants to be secure and move fast at the same time. Continuous compliance is the way to achieve both these goals.

    Compliance from Day One

    Usually, compliance is an afterthought. However, continuous compliance requires that DevOps teams start their design and development with compliance in mind. This includes having clarity on the exact requirements, down to the fine details. With this in mind, the team can move forward to build applications that meet these requirements. To have this kind of clarity, the various teams, including business leaders, need to speak a common language and have common terms to describe the different parts of compliance.

    Continuous Testing

    Testing is essential to compliance. In the DevOps world, testing has undergone numerous changes. The good thing is that these changes all support continuous compliance. First, testing has shifted to the left of the development pipeline. With testing happening earlier, it’s easier to catch errors and vulnerabilities before they reach production. Second, tests are increasingly automated. This makes them predictable, measurable, repeatable and compliance-friendly.

    Automated Compliance

    Your compliance verification and enforcement process should be as automated as possible. Toward this end, integrating compliance checks into the CI/CD pipeline is a best practice. For example, make vulnerability scanning part of the CI/CD process by integrating it with your CI server so that checks are performed at build time automatically.

    The Right Data Hierarchy

    All data isn’t equally important. Some data is more sensitive. This is why you need to organize and categorize all the data in your systems. Once categorized, you can define policies to govern different types of data. This includes encrypting data at the appropriate level—and not just in transit, but also when data is at rest.

    Track Access Control

    In the effort to achieve control over compliance, identity and access management (IAM) plays a critical role. It helps define who is allowed to access data and what changes they’re allowed to make. When assigning access, it’s important to assign it according to teams or roles and not according to individuals. This makes IAM policies scalable and easier to control. Putting in place streamlined IAM policies negates the need to share passwords and other sensitive information. Every user can access only the data they need, and not more. This is the principle of least privilege in action.

    Track Change History

    Beyond IAM policies, it’s essential to maintain a change history for all users and parts of the system. The best way to implement this is to use log data as the source of truth. It delivers deeper visibility than mere monitoring events and help to troubleshoot incidents. Logs have always been a cornerstone of good compliance, and in today’s cloud era, they continue to play a key role.

    Conclusion

    Achieving compliance is challenging in any environment, but when you embrace DevOps, compliance presents special difficulties due to the speed at which workflows move and the importance of making processes continuous. Implementing continuous compliance takes effort, but the rewards justify it. Not only will your organization stay on top of regulatory requirements, but it will be better positioned to move quickly and innovate.

    To put continuous compliance into practice, you need the right tool for the job. Symantec Cloud Workload Assurance (CWA) can help. Learn more about CWA features in this data sheet, and sign up for a free trial to see how CWA can help secure your cloud.

    This sponsored article was written on behalf of Symantec.

    — Twain Taylor

  • DevOps Ethics: The Danger of Unethical Code

    DevOps Ethics: The Danger of Unethical Code

    The accident could not have come at a worse time for Uber. Already under scrutiny following several high-profile lawsuits for sexual harassment, intellectual property theft and other accusations that played at least as significant role in founder and former CEO Travis Kalanick’s departure, the ride-hailing firm’s driverless test vehicle was involved in a fatal pedestrian accident earlier this year. It was later revealed the test driver, who was paid to take over driving in case of an emergency, was watching an episode of “The Voice” and thus too distracted to notice a pedestrian who suddenly appeared out of the darkness directly into the car’s path.

    Pending the final verdict of the National Transportation Safety Board (NTSB) investigation, it remains to be seen whether the Uber test driver could or should have been able to avoid the pedestrian or had time to apply the brakes to lessen the impact. However, the Uber SUV’s self-drive sensor system reportedly failed to detect and react to the pedestrian due to software failings—in other words, the system failure likely can be attributed to just plain bad code.

    Prior to the accident, Uber software developers and engineers were already struggling with ethical concerns regarding algorithms they created that, among other things, allegedly were designed to exploit underpaid drivers, deny services to passengers and skirt governmental regulations. A former software engineer, Susan Fowler, also described a toxic culture when filing a sexual harassment legal complaint against Uber.

    However, the allegations levied against the company, even if true, can be seen as an anomaly in software development and DevOps culture in general. One can suppose, for example, that basic human decency dictates most software developers refrain from engaging in unethical behavior and designing code for nefarious reasons. Data from recent studies supports this assumption.

    According to a recently published meta study by Stack Overflow, only a fraction of more than 100,000 developers surveyed said they would write unethical code or “that they have no obligation to consider the ethical implications of code.” When asked what they would they do if asked to write code for an unethical purpose, 58.5 percent reported they would not, while 36.6 percent said it depended on what it was. Only 4.8 percent said they would.

    However, the report describes a lot of “ethical gray.” “Developers are not sure how they would report ethical problems and have differing ideas about who ultimately is responsible for unethical code,” Stack Overflow said in a statement.

    Meanwhile, the fact that many of Uber’s arguably poor ethical choices originated from upper management and its DevOps team points up how, conversely, it is up to DevOps to instill ethical guidelines for organizations to follow. To that end, DevOps must create, among other things, “full audit trails showing who developed what code and when and a culture that enables developers to voice ethics concerns without fear,” said Torsten Volk, an analyst for Enterprise Management Associates (EMA).

    “Knowing that a full audit trail is in place will make DevOps more likely to raise a red flag with their team leads,” Volk said. “Then, ideally, the outcome of this discussion should be documented in a source code management system.”

    In addition to sending the message to their developers that following ethical principles during code creation is the right thing to do, organizations should support an ethical culture for software development—as well as for the entire enterprise.

    “It is critical for the entire business to understand the net positive impact of ethical conduct in development on the businesses risk profile and overall bottom line,” Volk said. “Similar to GDPR compliance, there should be awards for outstanding ethical conduct in coding that can be published to the outside, showing customers the value of doing business with this company.”

    — B. Cameron Gain

  • GDPR and Data Leakage: How Semantic Graphing Can Help

    GDPR and Data Leakage: How Semantic Graphing Can Help

    Many of the hallmarks of modern application development that drive efficiencies in the software development life cycle (agile, CI/CD, microservices, cloud infrastructure, open source libraries and third-party APIs) also create significant data leakage risks. Meanwhile, the EU’s General Data Protection Regulation (GDPR), which took effect May 25, creates a need to protect more types of data than ever before and comes with the strongest penalties for non-compliance: €20 million or up to 4 percent of a company’s global revenue.

    Preventing Data Leakage Getting More Difficult

    There are three primary reasons why data leakage has become more challenging for developers: complexity, speed and external services.

    Applications themselves have become more complex as organizations adopt microservices architectures. While this enables developers to be more efficient, it also often leads to more siloed views of the application while the data flows become more complex. For example, how many organizations understand  every entry point, exit point and handling of variables across every microservice in their broader application? And, organizations that adopt open source to increase efficiency by not having to reinvent non-differentiating code often fail to comprehensively understand the third-party code in depth. This makes understanding data flows even more difficult.

    The increasing pace of releases exacerbates complexity issues. Many organizations now release monthly, weekly or even daily. With less time to focus on anything beyond meeting feature deadlines, mapping data flows often becomes an afterthought. Furthermore, even if an organization is able to thoroughly map their data flows for any given point in time, the rate of change makes it impossible to stay on top.

    As organizations adopt third-party services for key functions such as code repositories, logging, databases and analytics, the consequences of leaking data become severe. For example, Uber leaked AWS credentials into GitHub, from which bad actors were able to initiate an attack that lead to 57 million records being compromised—simply by logging in.

    Why GDPR is Different

    GDPR is a significant expansion of previous data protection regulations in a number of ways. Unlike the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS) in the United States, GDPR applies globally and across industries. Any company that holds or processes data on an EU resident is subject to the regulation. Cloud-based software is inherently more global, and many U.S. or Asian-based organizations have users that are EU residents.

    GDPR expands the definition of what needs to be protected in a big way. HIPAA and PCI DSS formalized rules around protecting healthcare and credit card data. However, GDPR expands data that must be protected to include anything that can be used to identify a person—anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information or a computer IP address.

    And GDPR has real teeth. Companies can be fined up to 4 percent of their annual global revenue or €20 million for major breaches and 2 percent of their global revenue for minor breaches. Given the global nature of modern cloud applications, the potential impact of GDPR is far-reaching.

    Traditional Approaches to Preventing Data Leakages

    Traditional approaches to preventing data leakage have been focused primarily on acting as a proxy between the application and the rest of the world. In such a position, the proxy can attempt to filter data and look for patterns. These approaches are outside-in. They do not attempt to understand the application itself; rather, they inspect traffic flowing from the application without context.

    First, let’s clarify that despite the similar sounding name, preventing data leakage is not the same as data loss prevention (DLP). Traditional DLP vendors such as Vontu (now Symantec) and cloud access security brokers (CASBs) are solving a different problem. They are an IT-centric solution to preventing malicious or accidental data breaches that are typically driven by end-users moving documents via email or file sharing. These tools aren’t designed to prevent the applications themselves leaking data and they are of little use to developers.

    The more application-specific attempts to identify data leakage have been via web application firewalls (WAFs). As proxies, WAFs often employ pattern matching techniques such as looking for 16-digit numbers on the assumption it may be a payment card, keyword matching, fingerprinting and other statistical content analysis techniques. In practice, these methods are ineffective because they create far too many false positives. Furthermore, encryption is problematic in that the WAF either can’t inspect the data or a man in the middle decryption must be set up, which is computationally expensive and can add latency. Latency may not matter for traditional DLP solutions monitoring email, but it’s vitally important to developers managing cloud applications.

    One traditional method for identifying data leakage that does take and inside-out approach is taint tracking, which evaluates pre-existing binaries. In reality, taint tracking is impractical because of excessive performance costs and numerous false positives due to taint proliferation (transitively from application to web framework to kernel).

    Taint and information-flow analysis approaches track the flow of data through the program, assuming that the data originated from untrusted sources. Sources are where such data flows enter the program, and sinks are where they leave the program.

    Several publications define sinks informally as “data that leaves the system,” which is too imprecise to train a machine-learning based classifier; such classifiers are only as good as their training data.

    Dynamic taint tracking by plain instrumented emulation is extremely expensive and tend to slow systems. Such a slowdown is unacceptable in practice and significantly hinders the adoption of dynamic taint tracking systems for everyday use. Such taint proliferation can substantially impair the performance of the running system.

    Mapping Data Flows with Semantic Graphing

    To truly prevent data leakage, you must first map data flows. You must understand the building blocks of the application, including its security DNA. However, the difficulty comes from balancing comprehensiveness with speed. Simply put, to account for all possible leakages in a rapidly evolving application you must automate.

    Semantic graphing is based on a simple observation: There are many different graph representations of code, and patterns in code often can be expressed as patterns in these graphs. It is a graph of graphs that, for the first time, enables automatically creating profiles that understand the context of an application. Semantic graphing is language-neutral intermediary representation designed for code querying, which focuses on what the program is designed to do, what it is not supposed to do and how it functions. Because semantic graphing identifies which variables are sensitive and how they flow across each microservice, it then becomes possible to visually represent data paths and identity leakage/violations.

    In this instance, we seek to understand data flows and prevent leakages. However, the ability to understand an application’s context in code is fundamentally the foundation for DevSecOps. AppSec remains manual primarily because humans must apply the application’s context either through configuring rulesets or wading through false positives, both of which are impossible tasks. Beyond just data leakage, semantic graphing has the potential to deliver security at the speed of DevOps.

    — Chetan Conikee

  • DevOps Chat: DOES London Session, ‘Compliance and Audit Readiness: The DevOps Killer?’

    DevOps Chat: DOES London Session, ‘Compliance and Audit Readiness: The DevOps Killer?’

    The DevOps Enterprise Summit (DOES) is coming to London at the end of June. DOES London boasts an incredible lineup of speakers and presenters. One DOES London speaker is Ann Marie Fred, who will be presenting, “Compliance and Audit Readiness: The DevOps Killer?” In this DevOps Chat we caught up with Ann Marie to find out more about her presentation.

    As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation:

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud and we’re here for another DevOps Chat. Today’s DevOps Chat is one of a few we’re doing as a run up into the DevOps Enterprise Summit in London coming up later in June.

    Our guest today is a featured speaker at the DevOps Enterprise Summit (DOES London). It’s Ann Marie Fred of IBM, and Ann Marie, of course, I’ve forgotten your title because it happens but would you mind sharing with our audience?

    Ann Marie Fred: Sure. I’m a Senior Engineering Manager and I work in the commerce platform so that’s IBM’s commerce engine for selling things online.

    Shimel: Fantastic. And Ann Marie this is not your first time speaking at a DOES event, correct?

    Fred: That’s right. I spoke in 2016 in San Francisco and I really loved the conference: I had a great time and I learned quite a lot there so I’m definitely looking forward to London.

    Shimel: Fantastic. So Ann Marie you know I always ask this of people who if you haven’t been to a DOES event and you’re into DevOps or you want to be into DevOps or so forth it really is such a great camaraderie – it’s a great place to be. And for me it’s really about two reasons. Number one, I think the presenters or the speakers at DOES are second to none. You get really, you know, really great insight into real DevOps transformations at organizations throughout the world and whether it be a so-called vendor like IBM or even Electric Cloud or Tasktop or one of these or a practitioner in a large – as Gene calls them – horse – you know a large enterprise, not a unicorn – it’s fascinating to see.

    Because even organizations like IBM so much of their own DevOps offerings are based on eating their own dog food – on their own DevOps transformation, if you will. You know what I’m saying?

    Fred: Absolutely. So yeah, we teach other people how to adapt DevOps but we’re also constantly learning ourselves and it’s great to sort of be together at a conference with people from other large companies who are running into similar problems.

    Shimel: Yep. And you just hit the second thing. Beyond the great speakers the camaraderie of being able to network with people who have similar problems to you. And I think that goes right to the nitty-gritty of human nature, right? You know, not misery loves company but we like to understand we’re not the only one who are facing these challenges or thinking about these particular ways of doing it and it’s great to hear from other people who in similar situations are doing really interesting things.

    And I think that’s really – that really is what I think makes DOES I think a special conference.

    Shimel: Yep. That being said though Ann Marie your talk in London this year is entitled “Compliance and Audit Readiness the DevOps Killer.”

    Fred: That’s right. It does have a question mark after that but –

    Shimel: You know, I’m sorry. The DevOps Killer? I’m giving my inflection. But tell us what exactly do you mean with this one?

    Fred: Yeah, well, you know we always had compliance and audit readiness as a thing that we care about but with the run up to GDPR we had to put a lot of focus on it. And in addition to GDPR we sort of took that as an opportunity to make sure that we had our ducks in order with other things like accessibility, IT security, open-source checks.

    You know, the thing that we always tell people they should do – they wanted us to get to the point where we’d actually documented in a consistent way how we were doing them. And so it was a lot of work.

    Shimel: Well, I mean just – we have some folks on listening who are not up on GDPR but obviously GDPR is the privacy and personally identifiable information rule that is EUI but really when we say EUI because the world is so interconnected it’s going to affect almost everyone. And it goes into affect May 25, so by the time you present at DOES London we’ll already be one month into the official rollout of GDPR.

    So to be fair Ann Marie people have known about GDPR and when it was going to go into affect and what was in it for going on two-plus years now, correct?

    Fred: Mm-hmm. Yep. Yeah, I was going to say I think it took a good year for us to start to figure out what the implications of the thing were.

    Shimel: And you’re not alone – you know, a good year. I think, believe it or not – you know we cover a lot of DevSecOps whether it be on devopsy.kinsta.cloud or on our Security Boulevard site and I think there are a lot of people who even right now are a month out and are saying, “Gee, we better get serious about this,” you know? So a year isn’t so bad.

    But let’s talk about – first of all – let me back up a second. You know what? Some people still view compliance and readiness almost as separate and apart from traditional security, let’s call it, and as we were talking about it off mic in my mind I’d love for us as a whole – as a world – to move to the point where compliance readiness, cybersecurity are really intertwined with quality, right? If you’re releasing quality software, quality applications, quality services it’s compliant by design and compliant by practice. It’s secure by design and secure in fact. And until we get to the point when this stuff is part of our quality I don’t know if we’ll ever be successful. What do you think about that statement?

    Fred: For us? Yeah, exactly. For us part of this whole initiative was – I mean we use exactly those terms, right – secure by design – and what does it mean to be secure by design and what is an example of what you would do to be secure by design and are you doing that and would you sign a document stating that you feel like you’ve done what you need to do to be secure by design?

    So we’ve done a lot of prep work, I would say, and like best practices sharing to make sure that we’re not all inventing the wheel here, you know?

    Shimel: Well, let’s be fair. I don’t want to take credit for the term “Secure by Design” either. I think that comes right out of the GDPR and your reference to people having to sign off that it is secure by design that’s also in the GDPR, correct?

    Fred: Yep. Yep. And you know you have to have it documented somewhere so we all have these compliance folders. Yeah, so a lot of my talk is about how do we get from knowing nothing about GDPR and having pretty poor documentation in some cases to a state where we’re confident as a company signing legal agreements with other companies saying that we’re GDPR compliant ourselves, right?

    Shimel: Yep. So Ann Marie we’re talking about ten minutes and its time to really now – let’s zero in on this talk you’re giving. The DevOps Killer. Why is it the DevOps Killer?

    Fred: Well, it takes time to document all of these things and it takes a lot of manual effort the first time you do it. And one of the challenges that’s unique to DevOps and continuous delivery is that unless you make a special effort you might not even know what all the services are in your organization, right?

    Shimel: Mm-hmm.

    Fred: If people can just spin up a service in the cloud without a second thought have they told anybody that that service exists so that you can ensure it’s compliant, right? So that’s kind of step one. And then it’s almost inevitable that it’s going to be manual the first time but how do we make sure that we don’t have to rerun the entire manual check every single time we deploy the software? You know, how much of this can we actually automate?

    In some cases we can actually write tests for these things, so – because nobody really wants to keep paying that manual price.

    Shimel: No, for sure not. For sure not. So one of the things – I was talking to someone yesterday or the day before and I mentioned that one of the things we seemed to have moved away from in DevOps – and I’m glad we did – was the frequency of release and the speed, right?

    So, “I release 12 times a day,” “Oh, I’ve got you beat. I release 25 times a day,” “I release 100 times a day. And somehow the more releases I did a day the better at DevOps I was.” Right? And always said speed kills, you know? And what’s the right speed or the right release rate for your organization – whatever it is, right? And that is very different than the next organization.

    So in my mind it – yes, not just compliance but security in general can be a drag on release velocity, if you will. But there are good drags and bad drags, right, and it’s interesting, we did a survey a while back Ann Marie and you know developers – when we filtered it by developers – developers said, “What’s the biggest drag on getting your releases out faster?” They said, “Security,” overwhelmingly.

    And then the next question was, “Do you want that drag? Or in essence is that drag the right thing to do or what do you count on to ensure the quality?” And they said, “Security.” So sometimes being the drag but making sure things are done right and compliant and no one’s going to wind up – you know, the fines on GDPR are pretty stiff – is just part of the business cycle that we need to figure into things.

    Fred: Yeah. I mean we compared – internally we compared GDPR to __2K problem – the Y2K problem – that’s what I mean.

    Shimel: Yeah, __2K is another one.

    Fred: Yeah. But the Y2K problem. And we had to investigate every single service that we have and figure out which ones process personal data – and it’s a pretty broad definition of personal data – and then for each one of them make sure we’re compliant. And then now that we’ve done that once how can we still continue to deliver changes to production? I mean, yeah, some services are managed to deploy several times a day and some are every other week but nobody wants to redo the entire audit every time, so what processes can we put into place to make sure that we just don’t break things?

    You know, usually it’s a combination of every time you have a new feature here are the questions you have to ask yourself. And every time you do a code review here are the questions you have to consider, right? And then that combined with some regular reviews – maybe annually, for example – is I think the most pragmatic way to ensure that you’re actually doing what you need to do.

    Shimel: Absolutely. And you know that’s a good word to use when we think about compliance and audit and time drag – it’s about being pragmatic. Another concept Ann Marie that I heard – where the heck was I? – I think it might have been – I was out at the RSA conference about two weeks ago and we were doing a panel on Dev Sec Ops and stuff and the concept was sort of minimal MVP, right – Minimally Viable Product – Minimally Viable Security – so, look, there’s a pragmatic balance to be struck in terms of how much testing, how much security we do prior to release but we’ve got to at least define what’s the minimum that is going to keep us above water and understanding that in a DevOps way even after we release we can iterate feedback loop and iterate and continue to improve our security and compliance and audit readiness, you know, and that’s part of DevOps too, right? It’s never fully baked: you’re always continuously improving.

    And so the concept of a minimal viable compliance and audit readiness posture that would allow you to green light something being deployed versus 100 percent is something to consider. What do you think about that?

    Fred: Right, exactly. I mean you could take this to the extreme and you could say, “Every single place where an IP address – which is by the way personal data – shows up in my system it has to be encrypted in a way that the data can never be decrypted again.” You could say that but then you wouldn’t be able to maintain your system, right?

    Shimel: Yeah. It would be a monster.

    Fred: Right. So, okay, that’s not the right answer. So now it’s about, “Okay, what controls do we need to put in place to make sure that a random person off the street can’t get our logs?” and that that information is protected enough that we don’t think we’re going to get hacked and if there was an attack on our system that the scope of it would be very limited and they wouldn’t be able to do much with the data that they got, right?

    So yeah, it’s all very – there’s a lot of judgment involved in this and what’s your risk tolerance?

    Shimel: Agreed. So Ann Marie believe it or not – I told you the time goes really quickly – we’re coming up on – well, we’re probably past our 15 minutes – so we’re going to need to kind of start tying a bow on this.

    For people listening – and they’re listening to this before GDPR is in affect – it’s not too late. But for those who have just procrastinated too long what’s the best advice you can give them right now?

    Fred: Whoa. Well, I guess I would say don’t be afraid to start, right?

    Shimel: Right.

    Fred: It’s better to do the best you can –

    Shimel: Than do nothing at all.

    Fred: – than to be completely overwhelmed and say, “I can’t even think about how to start on it.”

    Shimel: And you know what? That is excellent advice though because that is the problem. So many people get paralysis by analysis, right, or they’re just so – you know, they look at this monolithic GDPR and all the articles and everything and they’re like, “Oh my goodness, we’ve got so much to do.” But it all starts with the first step. And from what I’ve been told Ann Marie no one – the E_U is not levying any fines or anything any time soon but you’ve got to start somewhere.

    Fred: Yeah. If I were to say, you know, two things that we expect quickly – I think just basic IT security – like having basic IT security processes will cover you for quite a lot of it. And the other thing we expect to be hit with very quickly is the data subject access request –

    Shimel: Yep.

    Fred: and deciding how you’re going to handle those requests because they’re going to come in fast and furious I think.

    Shimel: Yeah, I agree with you. And, you know, I think you’ve just got to get started with it.

    Anyway, so we’ve got that Ann Marie. You are speaking – in case anyone going to DOES is interested they can find it – I think DOES has published the entire schedule now – but you’re speaking on Tuesday, June 26?

    Fred: Yep. That’s right.

    Shimel: And I think it’s out in – at 2:35 PM which is 14:35 over in the UK and in Breakout Room B as in boy. So anyone listening who’s going to DOES come check out Ann Marie’s talk at DOES London and maybe say hello afterwards or before.

    Ann Marie I’m sure it’s going to be a great talk. We’ve heard you speak before. And thanks for joining us today on DevOps Chat.

    Fred: Yeah, thank you Alan, it’s been fun talking to you.

    Shimel: Absolutely. Ann Marie Fred, IBM and a DOES London speaker here on DevOps Chat. You’ve just listened to another chat. We’ll see you soon. Until then, have a great day everyone.

    — Alan Shimel

  • How DevOps Helped One Firm Get GDPR Right

    How DevOps Helped One Firm Get GDPR Right

    There has been a lot of press about how many, if not most, enterprises are still unprepared to comply with the European Union’s (EU) General Data Protection Regulation (GDPR) just days before it takes effect.

    However, executives from Cybric, a security platform provider, said their company has been ready for some time—and they thank DevOps for that. Their case study also shows how firms that are still struggling to get started before GDPR takes effect can do what is necessary as they integrate compliance with their operations.

    As soon as GDPR appeared on Cybric’s radar screen more than a year ago, the firm began to prepare. GDPR quickly became a compliance and data management process discussed among others on a regular basis and, as part of its DevOps, it involved the participation of all the stakeholders involved.

    “One core part of the culture of DevOps is about collaboration, sharing and communications and making sure you have automated processes in place,” said Mike D. Kail, chief innovation officer at Cybric. “That is, in part, how we were able to do what had to be done for GDPR.”

    Standard Procedure

    Before GDPR was announced, Cybric already had its data flow management processes in order, Kail said. This included keeping transparent records of data sources and the corresponding geographic locations of the individuals in the databases. “We were already analyzing how we processed our data and knew where it was going,” he noted. “We were also always looking at all the ways we could automate how we handled data flows.”

    The different infrastructure, development and business teams, of course, have also played a collaborative role in Cybric’s data flow management processes and resulting GDPR compliance. “Each team figures out how they how they can help, which goes back to the collaborative culture of DevOps,” Kail said. “It’s everybody’s responsibility and not just one team’s concern in the company. In the case of GDPR, the fines and levies can be significant, so everybody should take this seriously and not put it off and say ‘that’s not my problem.’”

    In this way, Cybric was in a position to respond to the demands of GDPR compliance long before the deadline.

    “One result of DevOps is you always take care of where the data is and how it’s being processed in an automated way,” Kail said. “The wrong way consists of manual, out-of-bound efforts for processes and tasks that people ultimately screw up or forget to do on a regular basis. And when that happens, you now have potential compliance issues.”

    GDPR’s Long Arm

    Some firms may be led to believe they are not concerned by GDPR if they do not store customer data from European customers. What they may not realize is that any data—whether it’s personal data for vendors, sales leads or general third-party business contacts for individuals based in a EU country—is protected by the GDPR mandate.

    Cybric, for example, outsourced its customers’ personal data. However, the firm still must comply for individuals who visit its website and submit personal information to download marketing collateral.

    “I think marketing is an area that a lot of people don’t think about too much,” Kail said. “They are like, ‘I don’t have any personal data directly,’ but indirectly, they do have personal data and must be GDPR-compliant.”

    Many organizations have not yet prepared for GDPR since they have not fully understood the regulation and whether it applies to them or not. But although some of GDPR’s terms are opaque, organizations still should not delay compliance just because they do not completely understand what is involved. “I think a lot of people are trying to delay their compliance even though the GDPR deadline is just three weeks away,” Kail said. “And sadly, their databases are just not ready since they have not thought about the complexity of GDPR compliance and certainly not in a DevOps way.”

    Small-to-medium-sized enterprises should also not be concerned about having to invest a disproportionate amount of resources to become compliant compared to what large firms will have to spend. Cybric’s small size—with fewer than 20 full time employees—has actually played to its advantage, Kail said. Additionally, Cybric’s story offers a look at how a small-to-medium-sized enterprise can use DevOps for GDPR.

    “As a small company, putting together a collaborative process with all of the different departments made it much easier for us,” Kail said. “That is also the approach people have to take.”

    — B. Cameron Gain

  • Despite DevOps, Firms Unprepared for GDPR

    Despite DevOps, Firms Unprepared for GDPR

    Most organizations are not fully compliant with the European Union’s (EU) General Data Protection Regulation (GDPR) before it takes effect in May, analysts report.

    While DevOps certainly gives organizations the mean to turbo charge the compliance process, stakeholders outside of IT departments often are failing to greenlight this necessary project ahead of the deadline, due largely to uncertainties about the regulation.

    Not being in compliance could hit organizations hard, with fines up to 4 percent of their annual revenues or €20 million.

    The Cloud Security Alliance (CSA) and Netskope, for example, recently released the results of a survey of more than 1,000 respondents about their organizations’ GPDR readiness. The survey revealed a full 83 percent were not very prepared for GDPR. While 85 percent had taken steps for compliancy, only 31 percent had well-defined plans for meeting the provisions of GDPR.

    The GDPR’s “right to erasure,” (53 percent) “data protection by design and by default,” (42 percent), and “records of processing activities” (39 percent) were deemed the biggest stumbling blocks for compliancy, according to the study.

    A separate survey of 700 network security and IT professionals by Enterprise Strategy Group (ESG) showed only 11 percent of firms were completely ready for GDPR ahead of the May 25 deadline. Thirty-three percent said they were prepared to publicly disclose data breaches within the GDPR-mandated 72-hour period, and 33 percent and 44 percent percent of the firms surveyed were mostly or somewhat prepared, respectively.

    Most organizations ESG surveyed also reported they are investing in GDPR, reflecting the seriousness in which they are regarding the mandate. While only 10 percent said they had made or were planning to make major investments in GDPR, 63 percent said they would make or had made incremental investments.

    Analyst firm Varonis made similar findings after completing a survey of 500 IT security experts in the United States and Europe in October, out of which 200 were in the United States and the rest of those surveyed were equally split between the UK, France and Germany.

    Varonis also found 60 percent in the EU and 50 percent in the United States faced serious challenges before they could be GDPR-compliant. However, 70 percent of the firms represented were also convinced GDPR compliancy would give them a competitive edge.

     

    IM000302.JPG

    Where Is the Data?

    Much of the uncertainty about GDPR reflects how organizations often fail to understand where exactly their data is located. While not specific to GDPR, Varonis found many organizations lacked fundamental data-protection protocols. Those surveyed revealed, for example, 21 percent of their organizations’ electronic folders were “open to everyone.” The survey also revealed 54 percent of the firms’ data was stale. Effectively tracking data extending from on-premises servers to across the cloud was often cited as an issue, making it difficult to track the exact origins of customer data and to determine whether it might be subject to GDPR protection or not.

    “We live in a hybrid world in which data isn’t stored entirely on-premises or completely in the cloud. The hybrid model creates additional challenges and potential risk from a security and data governance standpoint,” Ken Spinner, vice president of global field engineering at Varonis, said. “You can’t assume your data is safe in the cloud. If your cloud environment isn’t secure, your data won’t just be in danger of being exposed to your entire organization—it could be accessible to the world.”

    Uncertainties Abound

    A lack of understanding about what GDPR compliance involves is often cited an impediment to making necessary changes for compliancy. Much has been reported, for example, about whether EU citizens, residents, or simply those who are only temporarily on European soil are protected by GDPR. How the EU will impose fines against non-EU organizations also remains murky.  According to ESG data, less than one-third of the respondents of the organizations that took part in its survey fully understand all the GDPR’s requirements.

    These questions, of course, largely need to be resolved by legal counsel. Meanwhile, many legal departments are waiting for more guidance from the EU about uncertainties mentioned above, as well as other remaining questions about the GDPR’s scope.

    In other words, DevOps is ready to do the necessary, while legal and other stakeholders who fully understand what needs to be done must pull the trigger first. Only then can DevOps, consisting of IT operations, QA, InfoSec and development teams take over. When that happens, DevOps’ role will remain critical for making compliance more agile, automated and, ultimately, reliable.

    “DevOps can assist companies in complying with regulations like GDPR by ensuring that key regulatory requirements are part of the initial design criteria, and taken into account when applications are updated,” Varonis’ Spinner said. “GDPR, manual methods of enforcing data policy aren’t realistic solutions because large organizations could have millions of files. DevOps can support GDPR requests with processes and solutions that ensure personal data that falls under the new regulations is protected and used appropriately.”

    — B. Cameron Gain

  • Google Analytics Adapts to GDPR, But Questions Remain

    Google Analytics Adapts to GDPR, But Questions Remain

    The  General Data Protection Regulation (GDPR) will have an effect on how Google Analytics collects and processes data and how DevOps uses the tool—at least, that is what is known for sure at this time. These changes also should almost certainly impact DevOps for any organization that relies on the tool to collect and analyze user data. It is also known DevOps teams will have to reconfigure their Google Analytics implementations, even if an organization has no users based in the European Union (EU).

    However, while Google has recently offered some guidance about modifications to Google Analytics that impact DevOps, the company has yet to clarify some key points about changes ahead of when the new mandate takes effect May 25. In the immediate, here are some changes Google has communicated so far and actions DevOps will need to take ahead of the regulation’s deadline.

    Immediate Action Required

    The GDPR’s “right to be forgotten” provision offers users options to demand the deletion of personal data third parties store and share. To meet the terms of this provision, Google Analytics will allow organizations to manage how long their users’ data remains on Google’s servers. In this way, Google Analytics will automatically delete user and event data older than the date specified. Organizations can specify that the data remains on Google Analytic servers for 14 months, 26 months, 38 months and so on, for a maximum 50 months. It is also possible to opt for data to not expire automatically. Google Analytics says it will not delete information based on aggregate user data.

    Google Analytics also will allow organizations to delete data for individual users in an EU country that can be used to identify them under the GDPR’s “right be forgotten” clause. This data will include common identifiers that Google Analytics stores—including standard Google Analytics first-party cookies, user ID or App Instance ID.

    However, Google Analytics has yet to specify details about how organizations will be able to delete user data. While the process will be animated, Google says more information “will be available shortly,” presumably ahead of the GDPR deadline.

    Google says it is also drafting a new “EU User Consent Policy” ahead of GDPR. This policy that customers will have to agree covers organizations’ “responsibilities for making disclosures to, and obtaining consent from, end users of your sites and apps in the EU.”

    Another key modification Google has yet to reveal is the interfaces Google Analytics will offer that will allow organizations to make changes to how their users’ data is stored. Whether DevOps will be able to automate these processes or not will depend largely on whether Google Analytics will offer a GUI, an API or both.

    “If Google Analytics offers a GUI with no API, there is not much a DevOps team can do to automate it outside the existing functionality, since you need a person to do that. But if it’s an API, DevOps teams can weave the controls into their existing frameworks,” said John L. Myers, an analyst for Enterprise Management Associates (EMA). “If both are available, then you’ve got the best of both worlds.”

    Additionally, an API would allow the retention and deletion tools to work within existing DevOps frameworks and to become automated as part of business processes, Myers noted.

    The DevOps Challenge

    DevOps will obviously need to be prepare for GDPR in other ways outside of the scope of changes to Google Analytics or face fines up to 4 percent of their annual revenues or €20 million ($25 million), whichever is greater. Indeed, GDPR applies to all organizations worldwide that collect data from users in EU countries. In fact, it is often incorrectly reported the new privacy mandate applies to just EU citizens, while instead, the regulation concerns data collected from any user who is physically located in an EU country, regardless of nationality. Regardless, it is also obviously impossible to determine whether user data protected by GDPR including cookies, names, email addresses, social media posts and other information belongs to a user with an EU IP address who might just be visiting the region or is a full-fledged EU national.

    Given the far-reaching provision of GDPR that places strict controls on how third parties store and share data and protect their online privacy, GDPR likely will fall under an urgent DevOps project category, requiring the input of the change advisory board (CAB), as well an organization’s IT operations, QA, InfoSec and development teams. The degree to which GDPR will change code deployments and processes will depend on the organization’s business model, of course. GDPR compliance should also require review of qualified legal counsel.

    Meanwhile, Google Analytics says its tools can help organizations to comply with GDPR for data collection policies. These features include cookie settings, privacy controls, data sharing settings, data deletion on account termination and IP anonymization.

    However, as mentioned above, Google still need to provide DevOps with more clarification about certain changes to Google Analytics affecting organization ahead of the May 25 deadline. Many in the DevOps community are also very likely waiting to learn about other ways DevOps can use Google Analytics for GDPR compliance.

    — B. Cameron Gain

  • DevOps to the Rescue as GDPR Deadline Looms

    DevOps to the Rescue as GDPR Deadline Looms

    The stakes are high: Organizations failing to comply with the European Union’s (EU) strict General Data Protection Regulation (GDPR) face fines up to 4 percent of their annual revenues or €20 million ($25 million), whichever is greater.

    But while the threat of what happens if organizations ignore the mandate when it takes effect at the end of May is clear, how DevOps teams will lay the groundwork to comply is less cut and dry.

    At the same time, DevOps can allow organizations to meet the regulation in an agile and relatively quick way by integrating the working efforts of an organization’s stakeholders, IT operations, QA, InfoSec and development teams.

    “GDPR is the new boogeyman in tech, kind of like Y2K was years ago,” said John L. Myers, an analyst for Enterprise Management Associates (EMA). “Ideally, all of this will be handled with automation and DevOps.”

    The Right to Disappear

    An especially strict GDPR provision is any individual user’s right to both opt out of having their data collected by a private enterprise as well as their right to be forgotten. The so-called “Right to Erasure” Provision gives EU-based individuals the right to demand the removal of access to their personal data on an organization’s servers, either on-premises or the cloud. An individual’s right to have personal data “forgotten” also applies to personal information an organization may communicate to third parties.

    “The challenge lies with tracing personally identifiable information spread across multiple platforms, including third parties and CRM, ERP, payments, ordering, etc.,” Myers said. “Most organizations don’t have that level of visibility and transparency.”

    The challenge is thus understanding where all the instances of a person are within a data landscape, he said. If an individual in the EU decides to be forgotten and to opt out, an organization must know all the places where that person is identified within data management platforms and files, such as spreadsheets. For organizations that have a relatively small number of places where they store data, the process is easier, of course.

    However, there is one important footnote in the right-to-be-forgotten provision: Organizations do not have to actually delete personal data and records if individuals choose to be forgotten, Myers said. Rather, DevOps can encrypt their information, allowing organizations to keep transactions, customer counts, inventory, etc., but without identifying the individuals. DevOps also can be used to rapidly deploy code and processes to validate requests to be forgotten and to “unforget” individuals who later opt in.

    “With encryption, DevOps keeps one key for the company and sends or stores the other key for the EU individual in case they change their mind,” Myers said.

    However, using DevOps to automate compliance might be delayed in some cases, as organizations may first have to improve their data inventory management practices to better visualize the often-various places where individuals’ data is stored, Myers said.

    “Without an inventory of all the ‘wheres’ of customer, partner or supplier data that might be listed in the various data platforms, it will be difficult to automate out of the gate in May or even June,” Myers said. “As organizations get a better understanding of the inventory of their data landscape, they can add DevOps automation to the process. But at the earlier stages, it might be a manual process that is monitored, managed and standardized so that DevOps can take over and make it a reality.”

    Some Good with the Bad

    Discussions about GDPR tend to focus on the associated pain and potential costs organizations face to meet the mandate. But with every change comes opportunity. With respect to the GDPR clause giving individuals the right to be forgotten, for example, DevOps will have the freedom to deploy code and processes to boost their organization’s transparency for individual data storage, both in-house and what third parties access.

    “Having this inventory or visibility into all the components of a data landscape is a key for digital transformation,” Myers said. “Companies can use it as a good reason or excuse to move toward a more standardized and transparent environment that will accelerate those initiatives.”

    Some DevOps team members may also take pride in knowing achieving compliance for GDPR could also arguably be a step in the right direction to improve data protection for the common good of society.

    “There is the issue with actually securing the data that is collected to keep others from obtaining and exploiting it. Since identity theft is a raging problem, protecting personal information is paramount,” said David Monahan, an EMA analyst. “If we had usable federal legislation in the U.S. like GDPR, we would have had a much likelier outcome of Equifax being severely fined or even closed down for its poor data-protection practices. Credit bureaus are predatory when it comes to data, and since individuals have no right to refuse collection, all of that information is bought and sold without our consent.”

    — B. Cameron Gain

  • How DevOps Startups Can Deal with GDPR in 2018

    How DevOps Startups Can Deal with GDPR in 2018

    Data protection is not a new issue. There have been numerous high-profile data hacks in recent years, with sensitive customer information released into the public domain, causing widespread condemnation and fury. Trust is a big issue. When Equifax revealed hackers had stolen the personal information of 145 million people, there was an uproar. The problem is that we are increasingly moving our lives online. Criminals have been quick to realize that data equals serious money. For this reason, DevOps startups need to pay close attention to the new GDPR data privacy regulation changes that are set to come into effect May 25.

    What is GDPR?

    The General Data Protection Regulation (GDPR) is an EU Data Protection Directive. It has been carefully designed to shape the way businesses deal with data privacy and has been described as “the biggest change to data protection law for a generation.”

    The new directive will apply to all startups and businesses operating in the EU, and any company that holds data related to EU citizens. So, if your CFD trading startup is based in the United States, but you retain data on customers who reside in France or Germany, you are bound by the GDPR.

    Data compliance is a huge issue. Cyberthreats are common and criminals are happy to take advantage of businesses that have left a backdoor wide open. Secure data management is not something DevOps startups can ignore. Any data stored in the cloud or on a server must always be protected.

    Many tech startups hold significant amounts of information. This helps them deliver a software solution more effectively. However, even if your company holds no customer data, if any of your development team are EU citizens you still must adhere to the regulations. And with many DevOps startups recruiting remote employees from far and wide, this is not as unlikely as it may first appear. So, if Carlos from Barcelona is a key player on your development team, GDPR will apply to your startup.

    Company and Customers

    GDPR is split between company data and customer data. For a small startup, it may be a case that employee data is more of an issue, but if you hold customer data, it is time to look at how you manage this data. A good way to do this is through an internal audit.

    Create a data flow diagram (DFD) that maps all the data that enters, is processed and stored and exits your systems. Provided with a good overview, you should be able to spot any data that isn’t required or needs modifying so you can remove or adapt certain funnels to save time attempting to meet compliance measures for data you don’t use.

    Planning and Preparation

    GDPR is a big step up from the Data Protection Act, so you can’t sit around and wait for May 25 to come and go. It’s vital that you examine the GDPR in detail to see how and if it applies to your organization. If it does, you will need to make organizational changes to the way you deal with data.

    Create a compliance checklist to be adequately prepared, based on the requirements from the National Institute of Standards and Technology (NIST) and Cloud Security Alliance (CSA), combined with any state or regional regulation.

    Hire a Governance Trainer

    Legal language used in compliance can be difficult for those from an engineering and IT background to comprehend. Hiring an external compliance by design practitioner or trainer will help in this respect. Ensure they have a good technical as well as legal knowledge so that they understand both sides and are able to accurately review processes, make suggestions and make sure that GDPR compliance is met.

    Task this person with downloading the Control Objectives for Information and Related Technologies and CSA requirements. They can then work with program management to put such company directives into play, alongside working with your checklist. This checklist can be used to create an open source tool for scrubbing applications and determining whether they should be onboarded or pushed back, depending on whether they meet the compliance policies.

    Notifying Employees/Customers of a Breach

    If customer or employee data is breached, accidentally or otherwise, you have 72 hours to notify them. Sticking your head in the sand and hoping it all “goes away” will not cut it. There are two tiers of fines for non-compliance: up to 10 million Euros or 2 percent of turnover, or up to 20 million Euros or 4 percent of annual turnover.

    To ensure this risk is minimized, hold everyone accountable and put in place consequences. Decide on what these will be and how they will be enforced to best implement GDPR compliance in your startup, as such hefty finance can be especially damaging for small businesses.

    Data Consent

    You must let individuals know if their data is collected. Consent is a major issue in the GDPR and ambiguous tick-boxes are not acceptable. Privacy notices must be crystal clear and written in Plain English. Clients must have the option to opt-in or opt-out if you collect data from them.

    The Right to Data Erasure

    All individuals have the right to request that their data is permanently deleted. So, if Carlos from Barcelona decides to jump ship to another DevOps startup, he can legitimately request that you delete his HR file. He can also ask you to send his file to his new employers.

    Data Protection Officer

    Companies that process large amounts of data or are involved in the monitoring of individuals—this is applicable if you track online behavioural patterns for marketing purposes—must appoint a data protection officer. This person can be anyone, but they must have knowledge of data protection practices and the law related to data protection.

    Not everything has to cost in meeting GDPR data compliance, though; there are many free resources your startup can use as well.

    Speed

    One concern is the impact on speed that GDPR will bring. Eighty-one percent of IT operations professionals believe information security policies slow them down. Avoid this for your startup by doing the DevOps yourself as it will make software deployment faster. However, insecure system changes could then be shipped through. Automation can offer a solution.

    Automation

    Treating compliance through continuous automation means your DevOps startup will put code-based controls through the normal development process: test, version, apply and modify. This makes such controls easy to collaborate on and running compliance scans will become a common feature in the development stage, testing environments and production systems.

    The average idle time before identifying a system breach is believed to be 200 days. Continuous automation means that such an issue could be detected on the engineering team’s development workstation, before it reaches production and ensuring it is dealt with to make things safe and guarantee GDPR compliance.

    What Not to Do

    The thing you absolutely shouldn’t do is ignore GDPR on the basis that it doesn’t apply to you, “because who’s going to know if Carlos from Barcelona works for my startup and so what if one of my computers is struck with ransomware and everyone’s bank details are leaked onto the Dark Web?”

    The GDPR will affect millions of businesses, so all startups need to be aware of how it will affect their operations. If you don’t comply with the directive, it could prove to be a costly mistake. Ignorance is never a legitimate defense in the eyes of the law, so check out the EU GDPR website and get informed. If GDPR doesn’t affect you, great; but if it does, think like a Boy Scout and Be Prepared.

    — Murray LeClair

  • What GDPR Means to You, and Other Important Questions

    What GDPR Means to You, and Other Important Questions

    The EU’s General Data Protection Regulation (GDPR). It seems that everyone has questions about it, and for very good reason—GDPR goes into effect May 25. You may be too overwhelmed to even think about developing a knock-out action plan to move your organization toward compliance, or maybe you’ve had your head in the sand. CA Technologies’ Jeff Hughes, senior principal product marketing manager, and devopsy.kinsta.cloud founder Alan Shimel recently discussed a number of questions regarding this upcoming legislation and how companies like yours, should prepare for the May deadline.

    Here are the Top 10 GDPR questions from their Jan. 11 Live Chat:
    [su_list][su_list icon=”icon: circle”]

    • What is GDPR, in a nutshell?
    • What is the biggest thing that companies need to know about GDPR, especially those companies outside of the European Union?
    • What are some of the differences between data privacy in the United States and data privacy in the European Union?
    • How are companies going to need to structure their communications with end users when discussing their personal data?
    • What kinds of tools are needed to address GDPR?
    • How prepared for GDPR are companies?
    • Will fines for non-compliance be levied?
    • How should companies approach GDPR from a management standpoint?
    • Do companies need to appoint a data protection officer?
    • What strategy is recommended to address GDPR?

    [/su_list]
    Sound familiar? Click here to watch Jeff and Alan’s interactive GDPR discussion and hear the answers to these Top 10 questions (and more) about GDPR.

    GDPR is one of the biggest changes to hit the digital privacy landscape in 20 years. Make sure your organization has a knock-out action plan to prepare for GDPR. Don’t let GDPR give your company the Left Hook!

    Links to additional information:

    CA GDPR Webpage

    — BeckyArenson