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, DevOps.com 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 DevOps.com 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.
