After the wild card of 2020, it's no wonder we're all moving forward with a bit of hope, but also trepidation. And while we can't predict what will happen in the socio-economic sphere, Aptible does have some predictions when it comes to the security and compliance space.
Join us for a 45 minute webinar where we'll discuss our findings from the past year and what we believe 2021 will hold in terms of compliance automation, vendor management, GRC tooling, and more.
Chas Ballew (00:00):
All right. Awesome. Thank you Rebecca. Hi everyone, my name's Chas Ballew, I'm one of the co-founders along with Frank here, of Aptible. And we are here to talk about our view of the world in 2021 and what's going to happen. Frank, do you want to say a few words?
Yeah. So just really briefly, we're going to be talking about some of our predictions that we've seen, both from analyzing the market from our own customers, we're going to be talking about some technology trends. Hope to tell you a little bit more in the slides to come.
Chas Ballew (00:44):
Cool. All right, in terms of logistics, we have participants, and we can see the participants, but we don't know exactly who everybody is and it will really help us tailor ... Otherwise, it's just going to be Frank and I talking to each other for an hour. If you have questions, or if you have context, or if you have ideas, or comments, please do drop them in the Q&A. It'll really help us respond to make this just better and more informative, more useful for you, as we go. If you want to, as well, if you have anything that you're wondering, like what you would like to get out of this, you can drop that in as a question and we'll see it too.
Chas Ballew (01:29):
I appreciate it. We'll have specifically some time for Q&A at the end here, as well. We'll set aside some time for that. Okay, so the bulk of today is going to be some slides and some discussion around, we tried to pick three big themes, and three predictions in a sense, that we think are on the horizon and coming up in 2021. And for each of these we'll go through and we'll put a little detail on it, we'll kind of talk more and more about just our view of the world, that's really what people have asked for in this webinar, is what are ... If you were a founder of a 60 person Series A, Series B company in compliance and security, and you're working with all of these vendors and customers in the cloud, you're just in the middle of a security and compliance domain, what do you think about the market? What do you think about what's going on? What do you see? What are you hearing from the market?
Chas Ballew (02:36):
So this is Frank and I, and the Aptible's team take on what we're hearing from the market overall. The three predictions are around supply chains, basically. Vendor risk management and supply chains. The second risk is around compliance automation, which I think we'll talk about this, but it's kind of an overused term. Automation can mean a lot of things. We think compliance automation is finally coming into its own and becoming the best version of itself. And the last point here is around fragmentation that we see in the compliance and security industry and the emergence of platforms, I think a lot of companies out there are building features, not companies.
Chas Ballew (03:30):
So we'll get into each of these. Again, if any of these in particular resonate, or if there are particular issues or things you're wondering about as you go, your questions don't even need to be fully formed questions, they can be comments too. You can put anything in the chat and that works. Okay. Let's see. So this first prediction, we worded this as data networks decrease vendor risk. And it can take a bit to unpack. Here's some information to digest here. The title of the slide said, "Third-party cloud services are a growing risk." And I think it I don't know, Frank, how would you ... I'd say they're a risk, and they're growing. Is the risk growing? Is it? I think, I don't know.
I think it's a-
Chas Ballew (04:30):
What's your impression? What's the average quality in the bar for security? Are the vendors getting riskier? Or are we just using more of them?
I think it's that we're using more of them and that ... So I think there's three trends, that the first has been occurring since cloud adoption, which is that more and more services are moving to the cloud, so that means that customers of all sizes, especially enterprise companies, are using or depending on more cloud services. Those intermediate cloud services are themselves using more and more cloud services. And so the network of trust dependency between cloud services is just growing and becoming more interconnected. So whenever you're using one service, now there are dozens of cloud vendors backing that service that also impact your trust. So that's one of the trends.
And then I think the other is simply both greater visibility into breaches that are occurring in the supply chain as well as greater incentives to attack them. This is not something where its just a matter of trying to compromise financial data. There's a lot more data value across every industry that are the subject of attacks. And so I think that's what we're seeing here. It's not that the vendors are getting worse, it's that there's more interconnectedness, one vendor can create greater risk and attackers are leveraging that more.
Chas Ballew (06:07):
Yeah, I'm looking, the most important thing on this is the lower left-hand corner, to me, which is just the overall increase in companies who are suffering compromises through a third party or a vendor, and I expect that that total number will continue to increase as we see more adoptions.
Chas Ballew (06:31):
What to do about it? Raise your hand if you're watching and you empathize, you're in the 82%. Yeah, thanks Faizal. The state of vendor management is painful still today, and it's just state of the art. This is an RSA report from ... We tried to link, by the way, it may be tough to read. But we tried to link back to all of the research and the sources for a lot of these stats, and thank you to Jeff Lesser, who's our product marketing lead, he put this together and did all this research.
Chas Ballew (07:14):
But yeah, this is from 2020. This is a current number. And we won't go too much into this, just to say that it's fragile, it's full of friction. By fragile I mean error prone, and it's hard to tell if you're looking in a spreadsheet, it's hard to tell, is it up to date? Is it correct? Has it been updated? It's tough to get a picture of information across when you're a vendor management, your picture of that vendor security is kind of just stuffed in a Google Drive folder somewhere. But that's the way it is for almost everybody.
Chas Ballew (07:58):
Okay. This is a visualization, this is what I woke up thinking about. So I subscribed to a bunch of newsletters. The one I was reading today was The Washington Post has a cybersecurity newsletter called 202. And they've been reporting the SolarWinds breach, and following along with it, and the entire newsletter today was just about the impact and the fallout of SolarWinds here. What it'll mean for a Biden administration that has control of the legislature, whether there may be coming cybersecurity legislation. I haven't seen much analysis about this, but there's a much vastly improved chance that you're going to see a privacy legislation in the United States, which is just surprising, because I thought there would be political gridlock around that for a long time. But we'll see.
Chas Ballew (08:55):
The visualization here, or part of what this is intended to represent is that there's two stats here. There's two-thirds of security professionals think it's possible or definite that they suffered a breach through third parties, and 60% say they have experienced a data breach caused by a third party. And this is trying to get at the fact that you may be, or we may be affected by SolarWinds and we may not know it yes. We may be a vendor's vendor, or something like that. And there's a lot of attention in the media and for security attendees. I know, I'm sure pretty much everybody here probably had to do some kind of incident response and customer communications and analysis for SolarWinds and go through a plan. But once you get past that first order of, is SolarWinds a vendor? And then asking your vendors that, "Were you affected by this?" Pretty quickly it falls off. Pretty quickly you don't have much visibility into the supply chain after that.
Chas Ballew (10:09):
Frank, do you have any, I don't know, any maybe redacted stories of trying to track down vendors and trying to get responses from vendors and just experiences from the trenches around supply chain and trying to understand either before or after an event whether Aptible's at risk?
Yeah, and I mean, I think we can talk about this specific example of the Orion hack. So, for those of you who aren't familiar, SolarWinds Orion is a server monitoring software, so it's an agent that runs on servers. And that puts it in a position of having an extremely high degree of privilege, where if it's compromised, the attacker can laterally move and attack a lot more resources. So one of the first things that we heard with the SolarWinds hack was how vendors like Microsoft were compromised too. And there were plenty of Microsoft customers who were victims of the attack, who never even ... They had never heard of SolarWinds, they had never paid for a SolarWinds product.
And so similarly, we had to go to all of our vendors. Anybody who we were using to process sensitive data and ask them if they were impacted by the SolarWinds hack. And at that point, you're relying on a high degree of partial information and taking these vendors at their word. Taking really the best we could get is an attestation from the vendor saying, "No, we don't use Orion. And to our knowledge, none of our vendors use or used Orion." That's about the best you can do, and it's pretty challenging. It's very manual, doesn't give you a high degree of confidence. And we did this with SolarWinds, but there are many supply chain attacks that we've had to handle in a similar way.
Chas Ballew (12:12):
Yeah. I see this whole set of issues, it's going to keep happening, they're going to keep getting bigger, they're going to keep ... This is going to continue. Their internet is becoming even more adopted, cloud services and technologies, in a lot of ways. I haven't seen any research on this, but I think go through innovation and consolidation cycles. But I think we're going to still continue to see more and more and more vendors that hundreds, or thousands, or tens of thousands of companies use. And security is going to remain a challenge if a breach is going to happen it's, it's going to happen, and how bad will it be when it happens? And how fast can you recover?
Chas Ballew (13:07):
Yeah. Some stats here. Again, more sort of ... If you're feeling like this, and you don't have the resources to monitor security and privacy of vendors, you're not alone, you're in the majority here. A lot of times this kind of falls by the wayside and it's like, "Well, I mean, what could we do? We could pull a SOC 2 for every vendor, we could make them go through our vendor security questionnaire." Again, but each of these actions are often high friction for you. Who's going to do that? Are you going to hire an associate to do it? Or who's going to go ask for the SOC 2 from every vendor? Who's going to go chase down the security questionnaires?
Chas Ballew (13:49):
And you can buy software, and you can hire service providers to help with some of that stuff, but straight up, it still takes time and money, and most companies still don't have that time and money. Like as we were saying before, three quarters of people feel like they don't have visibility into where their data is going. I would be surprised if, this says data and personally identifiable information. Yeah, I could see, I mean, especially as the company gets bigger. It's like, "Do you know all the services? And what is the sales team hooked up to Salesforce? And where is your data potentially connected? What integrations do you have connected to which systems?" And feeling like you don't have a good handle on that.
Chas Ballew (14:45):
You have a known, say, often of what you think should be the case, what's approved at least, or what is supposed to be the case, but it's really tough to understand. What is the actual state of ... Where is your data actually versus where should it be? And the last one here is, again, all of this leads to, if you don't have the resources to get visibility and you know that you're operating in ... I don't know, I think of video games, the Fog of War, where there's only a certain distance that you can see beyond that, it's just blocked off but you know you're operating in this.
Chas Ballew (15:26):
And of course, it leads to a lot of uncertainty. I don't know if there's anything, I mean, around, I guess, in here, I'm going to turn off the slides for a sec and we'll talk about the prediction here. And the prediction is, just to remind everybody, it's that data networks increase vendor risk. So Frank, do you want to talk about ... We've talked a lot about the problems here. What's the opportunity here? What do we see opportunity for in the market right now?
Yeah, so as we were talking about, there is this interconnected network of cloud vendors who are providing services and it's kind of like just layers and layers of cloud services, all the way down. And it's tough to know when you hit the bottom. Privacy frameworks like GDPR introduce some better ways to analyze this. With GDPR every company ends up publishing a list of their sub-processors. And so you can actually dig in and understand if you navigate that data. Okay, if I'm using Twilio for SMS, what does that mean for the data that I'm sending to Twilio? Who is Twilio using to process that data? And you can start digging in.
So we're starting to inch towards this kind of world in which it's actually transparent to see how your data is being used by not only your vendors but by their vendors. And so we think that there's an enormous opportunity here to basically create greater transparency by giving vendors a way to represent what they're doing from a security and compliance perspective, propagate that to their customers, and allow their customers to repropagate that. So basically, everything now that is hidden can become more public if there's a good, consistent way to do this. That's going to have to be better than pdf SOC 2 reports, it's going to have to be better than navigating the texts of GDPR sub-processor directories.
But there is the opportunity for a technology powered way to do this. If you could think of it as kind of like contact tracing for vendor risk, right? So one of the most effective ways to track the propagation of viruses in the real world is to understand who comes into contact with whom. Right now, how data is used between cloud vendors doesn't exist. It easily could. And if that were to emerge on a platform, it would make vendor risk calculations a lot easier. So that's why we mention that.
Chas Ballew (18:21):
[crosstalk 00:18:21], there are companies that work on vendor risk management so there's a whole [inaudible 00:18:27] category of IT risk management. Sorry, I realized I drink from my coffee mug and my coffee mug has a ... It leaves coffee on my nose. So if I have coffee on my nose during this presentation-
Chas Ballew (18:41):
You can raise your-
I would tell you.
Chas Ballew (18:42):
Yeah. There is a whole category of IT vendor risk management software, what hasn't ... What we're talking about here is basically, it's almost like a version of LinkedIn, except for people, it's for companies, and except for career data, it's for security data, it's for being able to exchange documents and exchange security information. And one of the things that if you were able to build a network like that, that you're talking about here is that you could not only manage your vendors and get visibility over the vendors you know you have, but also without disclosing relationships between other companies you could get visibility into whether you were exposed to any other number of vendors. And then some indication of the riskiness of those vendors and your possible exposure, or something like that. That's kind of what we're talking about. Why doesn't that exist?
Well, most third party risk management or IT vendor risk management software doesn't have active participation from the vendors. They're not first class participants in those networks. And that's part of what you need here. The vendors are the ones who know what they're using. That's not something that you're going to be able to compile from the outside, from scanning, from asking, compiling answers to questionnaires. To get that data, you really need to have the vendors be participants. And so we see that as kind of a key requirement for this active vendor network.
Chas Ballew (20:20):
For those, I mean, if anybody's watching, have you ever answered a questionnaire through a portal or something like that? That experience, Frank, when you see not, we're making that a first class experience, or that it should be a first class experience. Can you explain a bit more?
Yeah. So what we're talking about is, we want the vendors who are being subject to risk assessments to be able to provide effectively, full disclosure of their risks. Now, it may not include all of the details, it may not include specifically which vendors they're using, but the point is, it's coming from them, and so the platform that we have in mind here facilitates both customer trust building by giving vendors a more direct way to communicate what they're doing for security and compliance than, say, sharing a SOC 2 report. And it gives customers a more direct way to ask questions about security.
Instead of, basically, trying to sift through a SOC 2 report, or sift through a vendor risk database to understand what a company is doing to secure its ... Basically, to perform host hardening on its infrastructure. What if a customer could ask that question directly, have it go straight to the vendor, the vendor could answer it directly, but not even on an ad hoc basis. The vendor could tie into their own systems to be able to answer that concretely. So whatever system the vendor is using to manage host hardening, they could plug that into this vendor network and communicate their security control directly to their customers.
If you expand that out and you get great adoption from all of the cloud vendors, you end up having all the data you need to be able to trace who's using whom, and what risks are present at each kind of node in this network. So that's what we're imagining here. The sort of functionality that this platform would provide would include vendor security questionnaire response, it would include submitting questionnaires and conducting vendor risk management. But the point is, it's both the customers and the vendors are actively using this to store important data that's relevant to them.
Chas Ballew (22:52):
Awesome. Thank you Frank, we're going to move on to the second prediction here. If anybody has other thoughts or ideas about the emergence of, yeah, social network but for companies and related to security, let us know. Prediction number two here is about automation. Frank, do you want to ... The next slide here is the Gartner Hype Cycle, what's the state of the world or compliance automation? This term. Do you want to talk a bit about, I don't know, the reputation, compliance automation has earned and the perceptions of when you read or see something that says compliance automation-
Yeah, for sure. Yeah, so automation is definitely a buzzword, and there's a spectrum in terms of what it implies. One way that we like to think about it is in terms of smart versus dumb automation. Where we are now is closer to what we would call dumb automation, and what that looks like is compliance software, like GRC, can integrate with software that you're using on the outside to help it you marginally ... Or to make it marginally easier to perform manual tasks.
So an example of how this could work is GRC software connects with Jira so that when you assign yourself a manual item to review the security groups in your AWS configuration, you can assign that ticket to yourself in Jira. So it's easier to get done. That's an example of where automation or compliance automation lives today. When we talk about smart automation, it's not about integrating with external systems to help kind of conduct manual work, but rather to automate the work that needs to be done.
So with that example in true compliance automation we're talking about integrating with AWS directly, or maybe integrating with a compliance oversight tool like Prisma Cloud, or Cloud Conformity, or even AWS's services, like AWS Config, collecting data to demonstrate that your security group rules are in conformance with your security controls, automatically logging that as evidence, tying it back to the controls and frameworks that you need to comply with. And then it's there and ready for you whenever you need to either use it in an audit or when there's any issue with the evidence and you need to be alerted in order to correct it.
But in this new world, that's what we talk about a smart automation, it's actually taking work off your plate as opposed to plugging into external systems to make it easier to do manual work. So what this means in terms of this chart, that Chas had, the Gartner, the Hype chart, we're probably somewhere past the peak of inflated expectations. So there's this innovation trigger, which is the adoption of both cloud services for running one's business, and cloud GRC software. So SAS GRC that enabled connectivity via APIs to enable some of these domain automations.
What happened is that we didn't actually make it easier to get compliance work done, or didn't automate the work away. And so what we're approaching onto is this world in which we're actually have these smart automations that take work away, where you have computers running your compliance program instead of humans running it. And that's where we see ourselves going over this next year and beyond.
Chas Ballew (26:55):
I think that they reason why Jeff put ... This is a joke, I think. This is also something that's used to represent the startup emotional roller coaster for startups. But the joke here is that, or the idea is that compliance automation sounds good in theory, but at least for the last couple of years, a lot of the companies that we've talked to ... And Frank was talking about this, a lot of the companies that we've talked to who have bought compliance automation or have looked at compliance automation have really just been sold a set of Slack reminders essentially, not real automation. And that's what we mean by disillusionment. It's like, "Wait, I thought this was actually going to do work for me, not just remind me to do manual data entry into a system."
Chas Ballew (27:46):
And I think where we're at right now is, there's recognition of that in the market. We've seen and talked to hundreds of teams, and the most advanced ones have been ... Over the last couple of years, investing in security engineering and beg, borrow, and stealing engineering resources to build scripts, or internal APIs, or evidence collection systems, or monitoring systems, especially for their internal architecture and their SaaS architecture. And I think we're finally starting to see enough credible competition, companies who are actually trying to build real useful automation, that this is going to get better in the next couple of years.
Chas Ballew (28:29):
There's a huge quote from Coalfire. Coalfire says ... This is from a report, I believe which is called the ... I think this is the Coalfire, Compliance in the Age of Digital Transformation Report which I thought I'll just share this. If you have not read this, I thought this was great, I thought it was really well done, I recommend you read it. This is commissioned through, I think a marketing company called [Amdia 00:29:02] or something, but Coalfire commissioned it.
Chas Ballew (29:04):
And it's consumable, it's interesting, it's well ... I think it's really digestible. It's a quick read, 25 pages. And I think this is one of the pull quotes from this. Now of course Coalfire would say this, "Everybody should invest in security." But I think the direction that this is an example did infographic from the report talking about the upcoming shift in the next couple of years, and this is likely, I know that for FedRAMP too, a lot of companies are talking and thinking about FedRAMP, NIS and GSA, and the folks who run FedRAMP are thinking about how do we make it easier and more automated and costs less, has a really nightmare reputation right now as to being something that takes a lot of time and resources to do.
Chas Ballew (30:06):
And I don't think that the federal government is necessarily ... They'd love to [inaudible 00:30:10] the barrier to security, but I think they want to make some of these services more accessible. And that's just one example of across the industry more and more awareness and the ability to get credit. That's the way to look at it between sticks and carrots. The carrot is you get credit for your compliance automation, and it's becoming easier to understand for the auditors and others, why your automation or what you're doing should be indicative of control over information. The stick is like in a couple of years, you're going to have to demonstrate the ability to continuously monitor and manage security controls over time. Okay. So this is around, when we talk about automation, Frank, you want to speak to some of these different use cases around those?
Yeah, for sure. So when we're talking about automating compliance and connecting to the other cloud services that you're using to run your business, the first two almost go hand in hand. The first item is collecting evidence on an ongoing basis. So you might, if you've been through an audit before ...
Chas Ballew (31:33):
And you know what? While I'm thinking about it, thank you so much, Faizal for your question. You said, "I'm a SISO for an AWS hosted healthcare SaaS. We have become HITRUST certified. How do you help minimize costs?" We do HITRUST. We use our own products and tooling. When you guys talk through this, also help talk through how this applies to reducing costs for HITRUST or how this helps with HITRUST.
Yeah, absolutely. So the way this works with Comply, so Comply, it has this principle of automate once, use many. And so what we have is we have a standard set of controls mapped across multiple frameworks. We, at Aptible undergo annual audits for HITRUST ISO 27001 and SOC 2. And so for the HITRUST audit, the auditor will expect certain pieces of evidence. And HITRUST is actually one of the more detailed and rigorous frameworks, where there are very specific controls and specific examples of the evidence that the auditor is going to ask for. So what happens is HITRUST has the software that they use to manage the audit called MyCSF. We plug that into Comply that tells Comply what sorts of evidence needs to be collected. Comply plugs into AWS, our other hosting product, Aptible Deploy, our mobile device management, our access provisioning and identity management solutions.
All of the services that we use, that help us to run our business, that need to be secured. And we collect evidence that we're doing so from each of these. So we collect evidence of security group rules being in place in conformance with HITRUST controls. We collect evidence of proper pull request approval, passing CI on our GitHub pull requests that we can then use to turn over to the auditor as a sample of our compliance on secure software development life cycle, and so on. And all of these are happening automatically, right? So you set up an integration once, you define the rules or you tweak the rules that we predefined to say what constitutes as evidence that you want to collect.
And then you set rules for when you want to be notified of a potential exception to your security controls. And that's the second piece and continuous system analysis and control monitoring. So if you're collecting evidence of what you're doing right on an ongoing basis, you can also set up notifications for when you're not doing something right. So that you can address this ahead of time. Now, I'm going to go out on a limb and I'll raise my own hand here. But I'm curious how many of you have been in an audit and realized that there was an exception or a non-conformity during the course of the audit. Now I'll raise my hand. I've been in that situation. And I would suspect that most have also been in that situation. And this is how it works, right? The status quo is to conduct evidence collection as part of an audit.
And so if that's the way you approach this reactively in response to an audit request, that's the only time that you're going to find out these issues. If you're collecting evidence continuously, you can also be alerted to issues continuously and address them before you go into an audit. And so those are the two parallel pillars of how we see compliance automation working. We also see there are specific details of compliance automation that tie into how we manage our own applications. Basically, defining our software development life cycle in our DevOps processes in terms of infrastructure as code having compliance and security built into our continuous integration and deployment. So that we're basically automating certain steps in what we run on our CI platform, documenting the steps that happen so that we have a record. These are all kind of what goes into automating our compliance activities proactively.
Chas Ballew (36:00):
Cool. Awesome. Yeah, I guess, the point I want to drive home here is that there are different capabilities. And Frank mentioned this around. Point number one here is, evidence collection. And when the audit comes, if it's HITRUST or something, and these are great questions. Thank you, Nick. Thank you Faisal. Nick has, out of interest, what's your annual audit bill? We do a SOC 2 Type II, ISO and HITRUST every year. We pay about 30K for SOC 2, 50K for ISO and 50 to 60K I think for HITRUST.
Chas Ballew (36:33):
So all told audits. We budget about 150,000 a year for audits, but we also have a bunch of other costs. We have pen testing, we have an internal compliance and security team. The total program, I think runs just under a million a year. So auditing is about 15% of the overall budget and security posture. I hope that helps Nick. Faizal, [inaudible 00:37:00] 650 controls or so how many do you handle through Comply and does Comply help with automating the CI/CD process? Yeah, it really depends on what. So your controls for something like HITRUST, depending on the systems that you're using, and for the amount of coverage that you get from something like Comply, it depends on well, what integrations, if you're trying to protect PHI it's like, where do you keep PHI? It really depends a lot on your business.
Chas Ballew (37:30):
So you may get a high amount of coverage, or you may have, if you have, I don't know, a lot of maybe you have an on-prem data center or something. And it's going to take a lot more work to get something like that HITRUST compliant. But if you're using typical core popular SaaS systems, you can get an enormous amount of coverage through Comply. Although that's probably a better for a separate webinar but great question. That is automating CAC. Frank, can you talk a bit too. So there's evidence collection, which is like, "Okay, it is February, everybody. It's time for you name it, like HITRUST recertification, let's go get the evidence." That's point number one, making that easier and making that more automated.
Chas Ballew (38:24):
Number two is, between audits, right? Like, "Okay, it's the middle of the summer, the audit's not till next ... But are we finding and preventing exceptions? Are we keeping things buttoned up." And then the last point here is specific to SDLC and specific to especially infrastructure. It's enough of a category that it gets its own-
So, I mean, this is maybe where there's the greatest maturity, there's a really good report and I'll grab a link. The Puppet's State of DevOps from 2020 it's about DevSecOps and building security and compliance controls into your CIC pipeline. And it talks about the maturity model there. And because there's so much intrinsic risk in the software that a SaaS company builds themselves as opposed to the software that they buy from their vendors, there's a special focus there. At Aptible, we have an entirely separate product called Deploy that helps manage that. Where Deploy, it basically puts guard rails on top of an AWS deployment in order to both manage the CI/CD process and then secure all of the interactions with those resources once they're hosted on AWS.
So I don't think we can go into all of the details of how folks secure CI and CD pipelines and how they use that to enforce controls around change management, infrastructure security. But I will drop a link to the Puppet's State of DevOps Report, which I would highly recommend like that Coalfire report. It's a really great read.
Chas Ballew (40:23):
I think it's interesting as a last note on ... Well, actually this is directly related to our last prediction. We can just go into it. What I was going to say is that I think it's interesting to see and encouraging to see AWS shipped like three or four new security products and monitoring products in the last year. And there's been more and more if you're looking at what's the story of ... I'm thinking like, I don't know, 2012 to 2015, it's like unsecured S3 buckets, dumping secrets and GitHub reposts, just like kind of dumb, sloppy stuff like that. And what you've seen is GitHub introduced Token scanning in the platform. You've seen AWS start to introduce more security tools and monitoring in the platform. And I think this is kind of ... I don't know, a broad theme that we're going to see more and more and more of today.
Chas Ballew (41:28):
So this is our third prediction, platforms overtake point solutions. I think we're going to see continued interest in platform adoption. And we'll explain a bit about what we mean. This is like all of the specifically around GRC in managing compliance, that kind of stuff. Often you see a lot of fragmentation, a lot of your security posture and the information that is represented and your ability to interpret information from that is blown across all these different systems. It's just the messages, this is like a ... I don't know what this is. This is a generic chat, but this is like, yeah, a text message. Okay.
Chas Ballew (42:20):
How many of you have conducted an audit over text message? This is a representation of what we see out there. We talked to a lot of companies who are like, "Yeah, we're using 10 different systems to collect all of our different logs and asset inventories and do workflows and collect evidence and manage vendors and on and on and on." And I think that the biggest pain that we see is these don't talk to each other. They don't integrate well, they don't talk to each other well, they're not aware of what you're trying to do. And the emergency, see, this is particular to GRC. Frank, do you want to talk a bit about ... I mentioned before, I think a lot of companies out there in this space are ultimately building features and not platforms. What do you think of them?
Yeah, so I mean, our approach here and what we believe in is that the core data that powers your compliance program should all live in one place. So an example here is so we take a risk-based approach to identifying new controls. Imagine a world in which you basically identify a risk. So a vulnerability is reported, this surfaced as a risk in the way that your system is built. And you define a risk treatment to track it. And if you're using point solutions, you might have one software that you use for risk management, where you document the risk. You might track the risk treatment in a totally separate system. Maybe you use Jira for that. If you want it to understand how this tied back to your assets, you might be using something like Asset Panda, another asset management system.
If you want to monitor what you're basically like after you've implemented this risk treatment, that it stays in place and you are not regressing. You probably have another system for doing that. Some sort of security monitoring. Ultimately, you have all of these systems and it's really hard to track whether you are actually meeting your security controls and objectives. And it's really hard to then easily communicate that to stakeholders like customers and auditors. And so that's why we believe that all of these core pieces, so the assets you care about, the vendors that you're using, the policies that you have in place and how that translates to security controls, the risks that motivate them. The evidence that you're collecting to prove that you're effectively managing your controls, having them all in one system connected together means that you can work much more effectively. And by effectively, I mean, not letting things slip through the cracks, which is really what happens when you're using this loosely connected mesh of point solutions.
Chas Ballew (45:29):
Yeah, [Moseley 00:45:30] great point here. Thank you for bringing that up. The visualization that would probably represent this, if I would do a V2 on this, but I'd represent as the solutions that you prefer to use would be connected to the central hub of a common platform. So if you want to use Loopio, or you want to use Asset Panda or Snipe, or for it like Jump, the device management or whatever, on and on and on. But right now, the biggest problem is not where those workflows occur, but that the data on the workflows aren't connected. So if you're using Loopio over here and something else over here, they don't talk to each other, rather than trying to, yeah, like you said, build, best in class, you can't build a platform that has best in class experiences for everything. And so that's where integration comes in really strong. But right now, most companies don't have that centralized system to connect things, to make connections, to associate stuff.
Chas Ballew (46:38):
So I have a couple questions here. I mean, one thing is more broadly, there is a shift. I think there's some platforms and we could discuss. I think AWS is interesting not specifically to GRC, but for a lot of the platform strategy that they're ... I mean, that's been pretty clear for decades. They've been working on a platform strategy. But I think in particular, the recent focus on security tooling is going to continue. I'm excited to see that. I think that there are other companies actually wanting to ... I think like OneTrust in particular, it has within GRC or within compliance management has been more forward-looking probably because they got a bunch of market adoption with GDPR and I think like the correct strategy is like, okay, you have a privacy management set of modules that work well, the natural extension of this is like, build out more functionality for companies to be able to do things that are privacy adjacent, like security, security monitoring, vendor monitoring, and they've done that.
Chas Ballew (47:56):
The strategy that they've taken has raised a lot of money and they'll not like the price. I don't know how many of you, raise your hand if you've used OneTrust Vendorpedia, or some of the other non privacy management products? You can render your own judgment. Your mileage may vary as the product quality and use case and stuff. It can be good if you're looking for a basic experience and it can break down pretty quickly if you're not.
Chas Ballew (48:25):
But I think what they've done is said, "This is all part of the vision, and we're going to build basic experiences for a bunch of different parts of this vision of a larger platform." I think the danger for them is which is that what Moseley had pointed out, which is that most of the experiences on OneTrust platform are not best in class at all by far. But if somebody can come along and build a set of platform experiences that either integrate better or somehow provide better experiences and more maturity and visibility, there's a big, big, big opportunity, I think.
Chas Ballew (49:06):
Okay. We have eight minutes left. I wanted to make sure we have time for any other questions or things like these. Yeah, if you want to learn more about Aptible and everything we're doing, all of these predictions basically relate to what we're building. We're building, these are our predictions because they are the biggest things we think are relevant opportunities over 2021. So over the course of 2021, we're going to be building and launching and being more open about the vendor risk management network that we are, is the core of our strategy at Aptible. We have a whole bunch of really interesting compliance automation work that's been released in the last six months, and is coming out in the next year or two. Especially around infrastructure and automating, monitoring and change management of your crown jewels.
Chas Ballew (50:14):
And in terms of platforms and point solutions, what I said before is ... What I meant I think that there's a case for having one system that can pull everything in from your various vendors or your various experiences and allow you to both become trustworthy and generate trust. And then also share that with customers and communicate it out better and faster as part of this network. Okay. Other questions here, let me see, I'm going back through and seeing if we missed anything. So we had questions about HITRUST and costs and audit costs. But if there's any other I don't know questions-
Chas Ballew (51:00):
Or things you're thinking about.
Moseley just asked one in the Q&A tool. Great question. Thanks for asking this. So Moseley asks, "You mentioned FedRAMP automation earlier that work will be based on OSCAL, the Open Security Controls Assessment Language. How important is a common taxonomy and language that is both human and machine readable to achieving the platform vision you outlined?" Since I read the question, I'll give my crack at an answer here. And then I'll let Chas weigh in. This is a great question, and I think it's very important. And one of the main reasons why you need this common taxonomy and language is so that customers and vendors can speak the same language and that whatever ... So OSCAL was primarily built so that auditors would have a common framework for understanding and assessing compliance with FedRAMP controls.
That same common language can be used for customers to ask specific questions of their vendors that are important to building trust, and vendors to answer them in a consistent way. If you think of the way that this works right now, the state of the art is still most companies use spreadsheets to conduct their vendor security questionnaires. Some use software. It's almost entirely freeform. There is very little in the way of customers and vendors meeting in the middle on a common set of basically control assessment questions and using that as the basis for building trust.
So if we can find a control assessment language, a taxonomy like this, that's used by both customers and vendors, it means that you could instantly get an answer to the questions that you have for your vendor. Because they've already prepared all of their security controls in line with that same framework. So if you want to know what your vendors are doing for background checks or what they're doing for secure software development life cycle and code approval. You can ask those questions according to control assessment language, like OSCAL and get the answers back instantly. You don't have to wait, there's no error in going back and forth. You don't have to spend time sifting through their text response to understand whether it meets your criteria. So I see this-
Chas Ballew (53:35):
Tell them they're humans, humans need to be able to understand what am I looking at and why should I trust you? And so that's a future state of compliance adoption and standardization that doesn't exist today. It's like, "How can I trust you?" It's like, "Have your computer talk to my computer. Have your vendor management API talk to our customer trust API." And you can find out quickly. We're pretty far from that still today. There's appetite for that, but in terms of execution, you still have to be able to sit a human being down, whether it's an auditor or a customer, and they have to understand, "Okay, what am I looking at? What are you saying? What does that mean? What are you representing, this control is? What does that mean in terms of the scope of your systems and risks? And how do I know what I'm looking at is accurate? How do I know that it's complete?" Whether it's evidence or an attestation or something like that. And that still takes human judgment and I think that's going to be the case for a while.
Chas Ballew (54:41):
I think you're going to see things like FedRAMP get sped up and OSCAL do a lot in terms of reducing the manual work required to build and maintain a system security plan and the ability to manage the administrative overhead of FedRAMP. There's still going to be a human being sitting down and saying to asking themselves, "Do I understand this? Does this make sense? Do I get it? Does this pass my test for reason?" Ideally, those who've been through vendor management and audits may not agree that reason is the highest currency in one of those processes. But yeah, that's the world I want to live in. Have your vendor management API talk to my customer trust API. More to come stay tuned. Aptible 2021.
Chas Ballew (55:39):
Thank you everybody. It's 9:00. We really appreciate you attending, carving out a chunk of your Monday morning. Here, there are, as Rebecca mentioned, other resources. And if you want a demo of any of our products or want to hear more about our roadmap or what we're working on just give us a holler, Rebecca.
Yep. Thanks so much. You summed it up nicely. Everyone will receive a link to the recording of this webinar, as well as some of the resources that we mentioned like the Coalfire report, et cetera. And if you have any questions, feel free to reach out to us, email@example.com or you can sign up for a demo on our website as well.
So thanks so much everyone, and have a great rest of your week.
Chas Ballew (56:23):