Liran Haimovitch – Managing Software Development in a High Compliance Environment: Getting to SOC-2

Do you have experience with security in your software development process, but not at all with compliance. You want to listen. And then as Liran Haimovitch of Rookout talks about managing software development and a high compliance environment and getting yourself to.

They had very little public documentation on how to become sort of compliant, but they still built up to procedures around agile software development and dev ops and attain certification in less than six months. Really worth listening to. Hi, everybody.

It's great being here at GitLab Commit. My name is Liran Haimovitch and I'm co-founder and CTO at Rookout today I'll be speaking about my journey with SOC 2 and other compliances. So to give you some background about myself before finding Rookout, I've been cyber security experts doing a lot of research and development of cyber security technologies, which was kind of how a transition to taking over security Rookout.

And as I found it, over the last three years, I've been speaking and writing a lot about modern software methodology, such as agile development. And today I want to discuss how the two can coexist. How can you go for DevOps?

How can you move fast and be agile while still meeting your compliance requirements? Now, to better understand, why is this such a big issue for Rookout? I want to show you a bit about what we're doing.

Rookout is a secure platform for data collection and debugging using Rookout non-breaking breakpoint, engineers can connect to their source code electronically in the cloud on prem staging evening production and collect any piece of data on the fly without tracking code, without redeploying, without restarting. Just click on the button and get your data. You need to do that.

You install Rookout SDK and you load your source code from GitLab or other source providers. Then just throw a nonbreaking breakpoint much like you would in your local ID and get the data you need. As I'm sure you know, and I'm sure you can understand, this requires a degree of trust.

I mean, when you start off in your production environments to allow us to collect data on your behalf, you have to trust us. And when we take security very, very seriously and we've done that from day one, we found that chilling compliance was critical for to allow organizations to adopt us. And so over the last two years, we've gone through HIPAA, SOC 2 type 2, ISA4701.

And we have also we are also providing DPAs for GDPR anticipate. This is quite a lot to achieve in that time frame, and it comes with not not without action between security and engineering and. Working with other organizations and other engineering leaders, I I'm saying that it's engineering leaders are worried about security usually coming from one of two angles.

The first, they are living a small organization that's growing. It needs to achieve more compliance. And so they are trying to learn about compliance and see how they can adopt it.

While maintaining the growing and agile the development team, the other approach is often from engineering in larger, more established firms or trying to adopt their devops and agile while still maintaining the existing compliance needs. And both cases are about figuring out how the two can coexist. Going back two and a half years, we were as we were just starting out our compliance processes.

I sat down with our head of DevOps at the time, and he shared with me his own personal story of going through SOC 1 Type two at the previous employer. And he actually said he almost quit his job, and that wasn't very encouraging for me. So together we went to meet a few friends who have gone through Soc 2 type 2 to talk to various companies.

And we've met with our auditors and we kind of came up with a plan of how can we make it? Both of them have been together. To give you some context, governance, compliance is mostly about governance, it's about proving that you engineering leaders know what's going on within your organization and can prove it to the auditors and to your customers.

Now, this may often clash with the DevOps as. As you can see in this quote by an excellent team from State of the devops report, our own research has found that in organizational culture that optimized for information, flow, trust, innovation and risk sharing is predictive of software development, organization performance. So if you want Dell for trust, should go for risk sharing.

But if you want governance, you might end up with this quote saying, In business we often use the more politically astute term governance instead of control. Now Reed Deshler goes on. To explain that governance is not quite all governance can be achieved through control, but in our case, we are trying to achieve governance without control.

We are trying to see how can we let trust live side by side with governance. And that might sound like a bit of a conundrum, because on the one hand, we want to tell our engineers we trust you. On the other hand, we want to tell our auditors we know exactly what our engineers are doing.

And to solve that issue, the DevOps Way. Let's take a quick look at some of the principles of Devops in this case, taking them home, see the whole block. And you can see that while trust is a big element in the social aspects of DevOps, there are also other principles, such as quality assurance and measurement that do allow us to know what's going on, even though we trust and empower individual contributors.

And to see how we facilitate governance through devops We've kind of built this framework with Rookout. And so whenever you go through it, whenever we go through a new compliance, whenever we go through a new set of requirements, we ask, we first of all ask ourselves, is this requirements currently being met through the process that we have in place? If so, then that's great document.

There is and document that solution all the effort, document the control and order process, you have that mitigating the risk. On the other hand, you might find that you do not currently have a control in place for mitigating that. This is a good opportunity to mention that, as you all know, DevOps is all about continuous learning.

And so you should think of this as a learning opportunity. And industry expert is letting you know that this is a significant risk and that you should go ahead and mitigated. Do you agree?

Is this truly a significant risk to your business or your customers, to the data you're processing? If so, then you should mitigate. But do it the DevOps way figure out how to empower your engineers, how to shift left, how to.

Help them prove that they are meeting the risk and then documented and we are going to go over some of those tools later. On the other end, you may find that you disagree. This is not a significant risk for your business at this time, for a variety of reasons, maybe are not processing that kind of data.

Maybe you are. Maybe it cannot be stolen. I don't know.

But if you feel this is not a significant risk, then you often can document it. Document, this is an acceptable risk and you can live with it and there is a good chance you can convince your auditors and other relevant. Stakeholders let you know what you're doing and this can be acceptable.

Now, going through this process, we ended up with three main pillars of compliance at Rookout, so I want to share with you them and share them with you. And go through them one by one. First, automation now this is a DevOps conference and you're going to be hearing a lot about automation through GitLab and other tools today.

But for now, we are focusing on the value of automation for security. And the value of automation for security is that unlike individual contributors, unlike engineers, we have much greater control over software with much greater control over applications. And so if you are asking a script to execute a specific task, we have a much greater degree of control, of governance, of visibility into it than if we were to ask an individual contributor.

The way we approach it, it Rookout is by building a portal which can be GitLab or another tool, we grant our employees access to that portal, each base zone, and then we implement with various tools that execute the tasks we need executed it can be and deploying staff to Kubernetes it can be changing our cloud configuration can be spinning machines up and down, whatever it is, implement those tools and then employees can invoke them as needed with the entire process audited into logs. So you know where this is, you know who access the system. You know what did you know what operate, what operation took place and if it was successful or not.

And best of all, you don't have to grant your employees access or administrator access or any kind of privileges to the actual production environments. Now, there are many automation candidates. Some of them include deployments and related, which we're going to talk about more in a bit, it includes provisions in the provision of environment.

It includes system integration, test maintenance and cleanup and backups in stores now and ultimately for security. You have to keep in mind the principle of least privilege. Which of those operations showing up, you or otherwise, are executed by many of your engineers?

Each of those operations required a lot of privileges, sensitive stuff. If you can find a handful of tasks that by automating you can reveal sensitive access from engineers and they no longer need it, then that those are excellent tasks to automate. And so it's much easier to prove, you know, what's going on because the engineers aren't accessing the environment directly they don't have access to.

And anything that's happening through the portal, through automation is, well, auditable. Now, the second pillar, greatly extending automation is CI/CD and GitOps. GitLab as many tools for a CI/CD GitOps and whether it's the GitLab CI GitLab CD tool, merge request and so on.

And then from a security perspective, it's all about shifting. It's all about making security into the process we already have so that we can and develop secure code, secure applications in the first place rather than trying to write applications first and then make them secure a second. Some of the benefits for taking this approach, for securing applications include that you get a single source of truth, everything gets deployed through CI/CD.

So you know what's deployed by going through the CI logs, by going through CD logs, by going through the git commit history. You know exactly what went where and when. You also get the benefit of shifting left are empowering your engineers.

To secure code, security becomes integral part of the system and you are achieving it much better. Now, this brings us to merge requests, merge requests are an existing gating mechanism within modern software development that your engineer is already familiar with. By.

Adding any compliance requirements you have to the merge request, you ensure that by the time the code makes it to the main or master branch, it's already secure, it's already compliance. So you can go ahead add dependency, checking, security screening, manual reviews, anything you need as prerequisites to the request. And then once the code is merged, once those checks pass, the code can be merged into compliance.

This connects well with existing law processes and controls, which means our engineers are already working to educate them on new tools and processes, and you're probably going to be seeing much less friction going through this process, achieving compliance without driving them crazy. And last but not least, everything going through this process is fully audited, you know exactly who did what, how was it tested and that the tests passed, that you can show it to auditors. And so, yeah, I'm governing everything that's going on through the CI/CD pipeline by defining the policy, by defining how the CI/CD pipeline look, by defining what's being tested through it, you achieve governance while still maintaining trust.

Over what your engineering is doing are doing within this process. Now, the last pillar is software monitoring and understandability, I'm sure you're are familiar with monitoring and monitoring is obviously a key factor in compliance is you have to prove, you know, what's going on. But software understandability tends to be more of a challenge.

A understandability is a term borrowed from the financial industry. And so it's measuring how hard or easy it is for an engineer to comprehend the system is working on so that they can efficiently and effectively fix bugs, add features and so on. And we are going to touch on why it's so critical in a bit.

Monitoring is the basis you once you deploy to production, once you deploy to other compliance environments, you should be monitoring your software, you should ensure it's OK, you should be sure ensure its operating, and you need to be able to show that to your auditors and in some cases, to your customers. There are many stakeholders within the organization who are looking for this data. It can be business folks such as sales and marketing looking to see how much revenue an application is generating.

How many sign ups you have and so on and so forth with product/UX we're looking to see which features are being used, how it's quite often and security, wanting to make sure the system is up and running and everything is running smoothly. And it's often the developers trying to better understand how the system is running so that they can adapt it to fix bugs, deliver new features refactoring, make it faster and so on and so forth. The tricky thing about the questions developers are asking is that those questions tend to be much more in-depth, going deeper into the business logic.

And so there are many more questions, questions that are about the interior of the software, not just about what's going on, but why and how is it going on. They tend to ask the different question every time they are working on different features, they are working on different parts of the system, and they're trying to achieve different tasks that have different questions. And if they have to redeploy a version of the application every time to get a new piece of data, it can be very tiresome, very annoying.

And we definitely don't want them SSHing into our servers just to get answers to those questions. The data they are looking for, the state information is often very sensitive, they might not need access to specifically the sensitive information, but those environments are containing sensitive information. And so we don't want developers wandering around poking, trying to get the data they need blindly just to on the one hand, we do want them to empower them to do their jobs, but we can't give them unlimited access to those environments.

And so it Rookout we found that important monitoring tools such as logging, including elasticsearch APM tools for metrics or tracing our tracking tools and business intelligence tools to feed and provide information all the stakeholders need. But it's also very useful. Have Rookout deployed.

So that we can collect additional data is needed to empower engineers to better understand the system and better know what's going on when they need to. Before we finish this talk, I want to share with you some additional thoughts and maybe some things that would be very helpful to you. As you're going through compliance, as you're going through security reviews, a big impact is on the data you're trying to collect on the data, your processing and on the access you're asking for.

Taking Rookout, for example, until early in the process, we found that there are two key factors organizations are worried about when discussing adopting Rookout. The first is our source code some organization don't want to provide Rookout the source code, while other organizations prefer to not provide Rookout with their application data. By finding ways to develop Rookout in a way that we don't require this data that we can operate without source code and without application data.

We avoided we avoid much of the resistance from our auditors and from the security departments at our customers. Because they don't have to trust us as much. The burden of proof is lower if you're not crossing as much sensitive data.

And so I encourage you to think of your own use cases. Which pieces of data can you do without which excess can you do without it might make your product just slightly less useful, make your product slightly less powerful, but it might make it 10 times easier to adopt. It might make it 10 times easier to get started with or to buy.

And so think of it. Is there anything I can do without? And is this piece of data that I can do without?

Something that's very sensitive to my stakeholders, so my customers will be doing without that piece of data, make everybody lives that much easier. Oh, that's all I had for the day, then, for you to reach out for me in the Q&A session on Twitter or check us out. Thank you very much.