Security Compliance as Code

so again we're going to be talking about Security compliances Source card and basically try and see if we can you know kind of do and solve the problem a little bit so one thing we did at Adobe primarily before we went on this journey was to create something in which we called internally as a common controls framework and in short CCF and basically you you'll be hearing a lot about common controls across the industry now if you're associated with security compliance in any way but when we started this journey in 2012 2013 there weren't too many Frameworks out there so we basically decided to create something that would work for our engineering product and security teams and that

teams could resonate with and anytime we had to go and achieve a new certification we didn't have to go and repeat all of the requirements so that was step one was to build a unified common controls framework so the next two minutes I'm going to just quickly Breeze through you know what that means what's the kind of work we did and just move on from there most of you should already be aware of adobe so basically you know this is just a quick snapshot of the organization so we primarily have three Marquee products I mean we have much more but these are ones that we are most famous for out there in the industry we have

the Creative Cloud which is your photoshops the lightrooms and all the goodness that comes with Creative Suite we have the document Cloud which is you know Adobe sign PDF and a lot of the folks in the industry out there use it and then finally we have the experience Cloud which is our our business Suite of you know marketing and other solutions to basically help promote the Enterprise marketing space so with that um let me just this is a lot of clicking yeah so with the common controls one thing what we did was um we created something which was known as when we first started you know talking about this problem we basically had something which we called as a

compliant soup so back in 2012 2013 you know as Adobe is migrating towards the cloud there were a lot of questions on how do we basically meet with regulatory and security compliance topics such as sock 2 ISO any other certifications such as fedramp and others and what we famously called back then you know internally was a compliance soup like how do we go meet with access change management a lot of these good requirements and go talk to Engineers without them basically you know getting upset with us and trying to make sure that the organization complies with a lot of this so the concept of the CCF was we took about 2500 or 3000 industry requirements which you see on the left

we built the magic funnel internally and then we that funnel basically just distilled out about 300 350 crisp requirements that we had that we could basically go back to engineering teams with and product teams and security teams and say okay if you want to meet with ISO or sock or fedramp you know this is that one Chris requirement you need on access or this is the one crisp requirement you need on configuration management or change management so we started with kind of creating a lot of these requirements in a manner that engineering and operations teams and product teams could understand easily versus just giving them a raw transcript of the framework and saying go decipher

this yourself and you know go and implement it so we started kind of doing a lot of that translation we started building those common controls and we went from about 2500 to about 350 400 requirements and in 2018 we basically open source that framework as well so that our peers in the industry could actually leverage that and and you know as they were building their own common controls we just wanted to share that common knowledge and that goodness so others could also use it so from there we basically what we did is we devised a baseline like which was okay what do we do to meet with sock to ISO PCI and others and what we did is we

built an incremental roadmap so we said if you have the Baseline level set of controls which was about 100 140 controls you automatically can you know try and you know achieve a sock 2 and an ISO and within stock to stock to security availability and confidentiality particularly and then obviously there's privacy and others too but you know and then we kind of tagged on ISO 27001 17 18 and a few other Frameworks and we built that as a baseline so then you know as you know with Adobe we accept like payment card data on our on our on our on our creative site or you know on our on adobe.com so if there were certain

products or services that required like payment card workflows to be enabled and making sure that we meet with PCI DSS requirements so what we did is we just added on those 10 or 20 additional controls instead of having that product team go through the entire fire spaces controls because we'd already established a step Baseline so at that point it was an additional 20 then our our sum of our government Cloud Solutions were required to meet with the stringent requirements of federal moderate so you're like okay we have the Baseline we have these core set of controls this is an additional 40-year additional 50 that we need to kind of meet with our gov Cloud obligation so we

kind of started to continue build on that and build that muscle memory and basically have those inherent controls and those extra controls that we had to build so so from there we basically reached a level of maturity where there was any new industry framework we would rationalize it we would take it through a magic funnel build the common controls and make sure that we were complying with them consistently across various parts of the business unit once we achieve that state we obviously wanted to see what can we do next and we started going and reaching out to our engineering communities internally as externally and one thing we often heard about was challenges with you know

ongoing effectiveness of compliance and how do you kind of go meet with that so our security and our engineering teams were spending anywhere between 40 to 80 hours a quarter I'm trying to meet with the quarterly compliance obligations or these compliance obligations that are repetitive once you get the certification requirements so the Big Challenge in front of us was how can we streamline that and make that easier given that we've already kind of built this framework around common controls so what we did is we basically started thinking of compliances source code or S code and started building these requirements on an engineering front and trying to see what can we do to kind of implement these early into the life

cycle instead of it being an afterthought and then also trying to see how we can reduce compliance fatigue which is often the term used in the industry but taking away the need of screenshots for evidence and you know kind of building more completeness and accuracy in our checks rather than having an engineer go and take like 50 screenshots of a source code repository or of an access management tool um but rather writing like source code checks that they could basically run scripts off or internal platform could pull that off and then we could use that and Supply that as evidence for an auditor so the way we thought about this was we had a three-fold vision the first one

was what can we do to reduce compliance fatigue the second one was what can we do to bring near real-time dashboards so one thing when you're in the security compliance space there's always these concept of audits now audits are usually like point in time and you basically have your either your internal audit team or internal assessment team and then your external audit team that comes and then obviously in certain cases does a look back and in other cases there's a point in time testing but by the time the audit is conducted it's usually it could be anywhere between a two month to a four month exercise well guess what if there was a risk that was introduced

because of a control failure that risk had continued to exist for that duration of time so our goal was what can we do to build near real-time dashboards so as and when a control is failing engineering and product teams and and security teams have easy access to those control failures and they're able to kind of detect those earlier into the life cycle instead of waiting for a manual order to happen and the last aspect was how can we self-service a lot of these requirements and move to complete control automation so one of our goals was to make sure that if an engineering team today you know understands that they have a use case around sensitive uh personal data

or you know Health Data then they should be able to self-service a lot of those requirements and the controls instead of waiting for a team to come to them and kind of explain to them what the gaps are and those Gap exercises would take anywhere between 8 to 16 hours to even longer depending on the use case instead of that we kind of started building modules internally where an engineering team could come in they could self-service they could put in what their use case was their business case was obviously we do have a little bit of manual intervention at that point to really extrapolate on the business use case but then they'll be able to

generate tickets and they'll be able to generate their list of controls that they need to implement with Claire and crisp guidance on how to do that so we had four stages during this journey the first stage was how do we build a data catalog because with any of this work that's required and if you need a platform to come and talk to you and to talk to your engineering and product teams the platform needs to know who to go talk to so the first one was how do we build a data catalog and at Adobe we've always had a level of like a product catalog and a data catalog but then we had to make sure that it spoke

to our automation platform or our internal platform and how can we make sure that that data could be leveraged when or Source a code based check is being run and if it identifies say a control failure which product team does it need to go to which Cloud account does it need to hit and then where does the ticket or the corresponding Alert in a dashboard needs to be created so the first thing we did is we created a data catalog that could speak to our internal compliance platform our step two was as I mentioned earlier a lot of these activities are annual or they are you know longer time based so what we did is

we started you know kind of dissecting these activities into more quarterly or more real-time activities so for example we created something which is called quarterly compliance review so instead of doing a lot of these reviews on an annual basis we started doing them like quarterly or even lesser to make sure that we were able to kind of build these into repetitive tasks that can be provided once we basically did that our stage three was to build more self-service modules which was to make sure that platform and Engineering teams can easily leverage a lot of this information readily by themselves and be able to kind of Leverage them while they were building the product and not as an

afterthought after they built the product to come and talk to the compliance team and the last stage was obviously moving from a completely manual effort to a state of automation where a lot of these checks and and you know these notifications can be built into a rules engine that we can take forward to the product team so with that architecturally this is a quick visualization of how we went about this so we had some shift left activities as well where we were kind of building them into the product teams you know backlog and and when they were building the code instead of coming as an afterthought but then we built a whole automation platform where what we did is we had

these four layers um the first layer was obviously the infrastructure layer which was okay how can we build a platform that can speak to engineering teams and their systems and be able to kind of Leverage information the second layer was the integration layer so we had a lot of these Security Solutions and and you know solutions that engineering teams use today our goal was that our platform can actually talk to them rather than to talk to the engineering teams and get manual screenshots to be able to build Integrations to a lot of these Solutions and be able to pull in data as needed for compliance and audit reviews the third layer which was the most important

layer is what we call it the rules engine so we started building rules within the source code to be able to kind of Leverage a lot of this data articulated with the data catalog and whenever there was a rule failure it would basically just identify that rule failure and then it would pop up as a notification into the fourth layer which is the visualization layer so once the visualization layer would catch on to something it would relay that information back to the engineering teams mostly it was uh uh uh detective control in some ways in some cases it could also be a preventive control so depending on the nature of the control you could build the platform in that

manner um so here is just another illustration so as you can see when we have our uh the product team you know control area or the product team environment you have a lot of these checks that we need from a compliance perspective whether that's configuration management change management a lot of that what that translates into is more vulnerability scanning more pen tests uh you know getting access logs and getting other logs we were able to pull all of this later build it into a source code based uh platform be able to get a lot of that back build a data catalog that can speak to a lot of these checks to identify where the platform failure is happening

or the or the failures happening make it talk to a rules engine which would identify when a rule would be triggered that would cause that and then finally through our log aggregation solution and our ticketing solution be able to relay a lot of that information back into a streamlined uh visualized dashboard so with that we were able to kind of take out a lot of the the need for manual evidences or repetitive exercises that we unfortunately had to have our engineering teams do in the past but make it more code driven and basically be able to help them give them crucial hours back so they can continue to build the Great products that they always do

so here are some you know visualizations of how our engineering teams see our platform today so when they have to go and do access reviews they no longer have to go to like multitude of systems all of that is linked into a system that they can basically easily leverage um they don't have to go take manual screenshots they see us uh sorry I think PDF uh Google is messing up the view but basically they see a list of all users the users of course has been redacted but you'll see their you know various access rights and you'll see everything there they simply have to go and just perform the access review right within the platform itself because of the

Integrations it relates this information back to various systems and those changes happen where needed and in a lot of cases they do and what they have to do is when because it's a quarterly exercise or more repetitive um over time they don't even have to do this exercise because the tool automatically does a diff for them identifies what those changes are shares a summary they simply have to attest to it in certain cases saying that this is good and then it can go and perform the changes as needed so moving on another thing that was very apparent during the pandemic was you know a lot of our customers and even in Industry everyone wanted to find out

like how are you more resilient like what happens if you know unfortunately one of the GEOS has an an issue and you know we never thought about we always thought about issues as like fires and earthquakes and other aspects of calamities but no one ever like with the pandemic it was just more widespread it was across the all Geo across the world and everybody was going through the same challenges and we continue to brace them a little bit even today so with that we started getting a lot of questions on how are you you know performing your resilient activity such as business impact assessments Disaster Recovery exercises and others so what we did is we went from a manual you know effort

where we would teams would come in they would perform their impact assessments manually so we built like an in-house platform again we built some checks into the platform so as teams were defining during the Bia say the recovery time objective or your recovery Point objective when they were doing actual Dr our drills um the platform would be able to kind of ask them those values and be able to tell them nope you already defined something on your business impact assessment and your actual recovery exercise took longer so it does those automatic calculations itself and then points those out it also defines a list of critical vendors that the other teams can then leverage for you know say

uh vendor risk management and other areas so we've been trying to kind of holistically capture a lot of that data and make it you know be able to communicate with one another so this data can be repetitive versus like when you go into manual evidence Gathering it's it's all a lot of screenshot based it's all manual and cannot be repurposed year over year so our goal was to basically capture this data make it talk to various systems so that you know we have one consistent set of data source that we can leverage for a lot of our activities so with that um you know given that we're coming closer time I did want to share some

resources we have our open source framework as I said you're more than welcome to leverage it or at least take a look we also we've written a few blogs on our automation Journey so feel free to kind of go through those but with that I'd love to you know since I said it's going to be more conversation based thought-provoking base so I'd love to hear questions or if anyone has any and we'll get our steps up foreign so I'm gonna run around with a mic I see one person with their hand up if you have questions please put your hand up and I will come around to you hold on one second hold on one second I want to

make sure I get you on the mic yeah yeah so how does uh CCF compare to say you know nist 853 because that's what we're doing right now basically using that as a common framework as we go along you know getting like you know fed ramp and state rampants exactly yeah so if anybody can hear the question the question was how does CCF compare to nist 853 so as I said at the start of my talk there are a lot of like firstly common controls out there so when we started in 2012 uh there weren't too many out there but you know when we built our framework obviously Nest 853 has been ever present and is one of the

gold standards to leverage so definitely a good idea to leverage that even when we were building a common controls framework we did take that as one of the inputs and you know ref4 is what a lot of the organizations use today for federal moderate and higher but obviously with ref fight coming in you will see some changes there but it's it's a good idea to leverage that and we also did Leverage this as one of our inputs into our common controls uh next question is first row in the middle so I noticed a lot of the applications you were talking about are basically management of people and business practices more than management of actual requirements like when you say

compliance is code I'm thinking of open S cap or compliance Frameworks where you literally run them against the technology and it tells you whether or not it passes the tests can you tell us more about what you did at Adobe related to that yeah so that's where basically where the rule engine comes in and that's more for our internal our internal assessment team so when we are actually running these exercises and these audits instead of like going and manually kind of attesting to those evidences and reviewing them we basically are able to pull that data from our rules engine and you know kind of make it run through it and to be able to tell us where those

control failures are and then you know also for the engineering teams as I said one of our goals is to get them a near real-time dashboard so those checks are constantly running teams have access to it so the data that we see is what the product teams and Engineering teams see so if they're kind of deploying an insecure configuration or something else that does not mean the sense of an operating effectiveness of control they are able to get access to that you know immediately as well so some of the examples I did I shared were more on the access review in those sites because that's where it's a lot of pain and fatigue for teams and they have to kind

of do those repetitively and it's never fun but then we do have certain Rule and Rule engine and you know we are kind of trying to mature it as we go to build more use cases where we can get that out up front before even an assessment starts next question is right in front of you in the front row yeah I mean I love this whole concept but like my first question is is like what other GRC tools for example have like the automated API stuff where they can pull a lot of data in and like why didn't you use like some off-the-shelf GRC and then do you guys specifically did you create your own uh with that

being said and then um did you guys use like the security Matrix in order to figure out how to cross all these particular uh compliances and then with that being said is do you guys do compliance back to back to back to back so you don't have to gather so much more evidence uh versus you know putting them out through the entire year yeah so I'll there are a lot of questions so I'll try and remember all the time but if I did Skip any feel free to kind of repeat um so I think the first one was uh did we look at off-the-shelf Solutions we absolutely did and when we first started our journey um we were leveraging a GRC

solution internally as we were part of the internal audit group we were leveraging you know a GRC solution but one thing we noticed is again nothing against any GRC solution out there I'm sure there are use cases that it works for um in our use case our our biggest you know constraint that we had was um you know trying to keep up with organizational changes and making sure that the data continues to stay rich and relevant and that's something that we saw as a huge shortcoming when we were kind of working with those Solutions and the other thing was we would go to these engineering teams with those uh Solutions and they would tell us why do

we have to go to now a third platform or a fourth platform or a fifth platform to do the work that we do why can't you bake something with our own ticketing solution and our own source code management solution to others and that's where we saw certain uh you know know constraints when we were doing that and we decided that okay building from scratch and leveraging so when we build the common controls framework we built something that was called driver subscribers so what we did is we had driver teams out there that we felt confident in their control implementation and we asked the rest of the companies to subscribe to those driver controls once that was done we

felt more confident as we were building these checks and balances to rely on the data that these driver teams were capturing and then relay it back so that's one of the reasons why you know we didn't go off the shelf but obviously we continue to evaluate that and if there's a solution that would work for our engineering and and platform and product teams we would absolutely love to leverage it but in the meanwhile you know we continue to build on ours to bring in more efficiency and scalability because obviously we can build up modules a lot faster last question is up to your right got one more up here to your ride okay hi uh great talk by the way thank you my

question is around the rules engine um I'm sure every dog is a very big company and you have different systems having different compliance requirements so how does a rule Engine account for such different systems and do you let your compliance analysts or Engineers modify those rules as per changing landscapes okay great question by the way thank you so we do uh obviously you know Adobe is is a is a big enough organization where there is a little bit of you know uh different implementations as you would say but as I was referring to the gentleman here uh one thing you know before we even went on this journey was the whole driver's driver approach where

we wanted to make sure that we had mostly centralized aware control is implemented and then encouraging these teams to kind of adopt that and one easy conversation to do that was like hey we have this driver control and we feel fairly confident in this but if we saw a pushback from an engineering team it was just a sit-down conversation to make them realize if you don't inherit this goodness you have to go and perform your own security monitoring which means these extra 20 controls and guess what no one loves these extra compliance activities so a lot of that Journey was streamlined but to your point there are always that one-off use cases that continue to exist so we are tweaking a

rules engine as we go but we are going after that 80 or 90 so that there is more scalability and flexibility and for the odd 10 person sometimes either we default to a manual review or we basically eventually build a roadmap for a team to move over to the central process but it can never be perfect

I'm I'm so sorry but we are actually overtime at this point so yeah yeah you're welcome to take them outside uh and one final round of applause thank you so much for our speaker thank you [Applause]