Let's Chat About SOC 2s, Baby

so very excited about this next talk uh from wendy knox everett who is noteworthy for a couple of reasons one she's a lawyer working at leviathan security and it's always great to meet a lawyer at a security firm because they'll actually keep your stuff straight second she's going to tackle uh something that is surprisingly relevant to a lot of us which is sock two right this is the compliance model that we all need to do so we all spend our days and nights thinking about security but at the end of the day someone has to show whether or not we're doing what we have to and wendy's going to dive into that security assurance and third and

something that i'm the most proud of is that wendy once upon a time was my intern at ntia and she kind of broke the mold for all other following interns uh she's just a bloody rock star in fact she's better than a rock star she's a willie nelson so i think you'll find this is going to be one of the more interesting compliance oriented talks you'll ever see so take it away wendy hi and welcome to our exploration of all things sock 2 at besides lv 2021 so you might be saying what i may have heard that term before but i have no idea what it means well you're in the right talk to learn

some more sock 2 audits are designed to provide a way for organizations to demonstrate to customers that they have at least a minimal set of security controls and some oversight in place many companies have built software as a service or web hosted software tools seek out a sock 2 audit to provide a security maturity signal to their potential customers and hi i'm wendy i'm a senior security advisor at leviathan security group i work with startups to help build their security programs and grow their enterprise sales as part of that i often help them go through their first sock 2 audits so today i'm going to share some of that knowledge with you this talk is really designed as an

introduction to sock stock2 audits we're going to walk through what it would cover and discuss preparing for your first audit and how to make sure your company is set up for success so what even are we talking about there are several types of security program audits like iso 27001 bedram or high trust each of these at a really high level tries to check whether the audited company has functional security controls in place some of these like fedramp are required before the company can sell their software to a particular type of customer like federal agencies in the case of fedramp but some are voluntary like stock 2 and iso audits usually are but if it's voluntary why would any

company willingly undergo a security audit well in this age of storing your sensitive information and systems that you haven't built and don't operate yourself like using salesforce or aws or jira you want somebody to ensure that these tools will protect your proprietary data and in turn if you're selling a tool that will hold sensitive data from your enterprise customers they want insurances from you the sock 2 certification is one way that you can demonstrate that you're capable of protecting sensitive data understand of course that while audits can demonstrate a certain level of organizational maturity and require some evidence of some security safeguards it don't really mean that a site is unhackable and indeed really nothing can

let's pause here to know an important distinction between audits and assessments assessments can be thought of as more informal check checkups using a control set to generate a list of gaps for an organization audits are a little more formal and usually require the auditing firm have a certain set of credentials so for a sock 2 audit the auditing firm for instance must be a licensed cpa heard also note that these audits do not cover technical security controls such as protections against sql injection or cross-site scripting to check for those you will need to book a penetration test of your application and so let's jump on into discussing sock 2 audits and how you can prepare

for one every audit will check your program against a set of rules that we refer to as a control set for a sock 2 audit your program will be checked against at least one of the five trust services criteria those are as we see security availability processing integrity confidentiality and privacy out of all these five only security is mandatory and you can pick which other ones you might like to include the security principle verifies that your information and systems are protected against unauthorized access auditors will look for processes to prevent or detect security issues like breakdowns and circumventions of segregation of duty controls detections of system failures theft or any other unauthorized access or removal of information

the availability principle meanwhile covers checks to ensure that information systems are available for use the sock 2 availability principle doesn't actually mandate a particular sla like 5 9's instead it requires that you have monitoring and operating processes to support your defined slas if you're running on a cloud platform like aws some of the implementation of this principle is just inherited from aws's sock too however you do still need to set up monitoring and alerting for your vms or processes that run within aws you'll need to do some other things like disaster recovery testing the confidentiality principle checks to see the organization has a way to check information that's designated as sensitive can you limit its access to it you limit the use and

retention and restrict disclosure only to people authorized to view it again if you're running on a cloud platform a lot of the implementation of this principle can be inherited from that cloud platform stock too if they have one although you will still need some things like a data classification policy and if your user laptops are in scope you need to have an end of life procedure to protect the data on those disks so those three principles security availability and confidentiality are the three most common ones included in the esoc 2 audit but there are also two other ones you might want to include if they need sense for your platform the processing integrity principle verifies your organization has controls

to ensure completeness accuracy timeliness and authorization of systems processing it looks to see if you set up procedures and systems to ensure that information processing is free from error delay emission and unauthorized or inadvertent manipulation meanwhile privacy principle checks whether personal information or pii is usually refer to it that is collected used and retained is managed according to a few points that are very similar to other privacy regimes like the gdpr or ccpa there are notice and consent verifications that check whether your organization tells users what information they collect and what they're going to do with it the auditor also will check if organization limits the use and retention of the pii if you have procedures to notify users

in case of a data breach finally as with most of these controls the auditor will look to see if you have monitoring and enforcement of these controls so you might have noticed that two of these confidentiality and privacy are really similar they're actually two distinct concepts confidentiality checks to see if you protect data deem sensitive by your organization perhaps including things like your source code meanwhile privacy looks at the controls around shielding pii from accidental disclosure or misuse so for each of these broad categories we need to build a set of policies and procedures for your program that will implement the principles in each category and which will be our control set that we are audited against

the controls that we build could be custom to our program and so this is a way in which sock 2 is a little bit different from a more prescriptive program like fedramp so long as they fully implement all the relevant principles under each category that we are going to be auditing against so this sounds pretty generic and fuzzy so let's jump on in to some specifics the trust services criteria are the foundation and most stock 2 audits under each section there are several coso principles and call outs directing auditors for what to look for you can find each of these in a pdf that's hosted online at this url and i will tweet out my slides later if you

need to grab this so let's take a look at one here's one under the security category cc 1.3 tells us we need management to work with their independent oversight which is usually the board of directors to develop a security organization that has a charter and clear lines of reporting and responsibility so note that some audit firms would give you a set of controls that they're used to working with that implement the tsps however we found that smaller companies is often better to create your own control wording that aligns with how you have implemented each of these tsps so for instance if you use a federated identity management or cicd pipelines let's make sure the control wording

reflects that so let's take a look at two example controls that implement this principle here we want to write a control for our control set but what's the idea of authorizing and defining our recording structure into action an org chart is one way that you can embody your organization's structure and so first we'll write a control that will use an art chart to track who reports to who and who is in which department don't forget to account for any contractors trump employees or interns who work for you and here we have a second control reflecting that you also need to make sure that you have all of your policies created and approved by management you will need an overarching information

security policy that sets up your program and includes information about who your security officers are and what their charter is other policies should cover areas like access control and risk management that we'll look at very soon so some stock 2 audits need to collect evidence to show that you're following your controls keep in mind that we need to create evidence artifacts that show that they are operating within our organization we'll dig a little more into that shortly so let's first have a look at a couple of the main areas that we will be responsible for implementing in particular under the security and availability principles remember you need to develop policies for each of these areas

access control is a really big area for sock 2 audits like most security control implementations and getting this right can make your other checks much easier of course using a federated identity management system like octa can simplify this a lot it's actually not absolutely necessary here's one of our principles cc 6.1 there are several kosovo principles that touch on access control but this is the one that usually most of the technical processes will fit under in that pdf there are several relevant points that tell the auditors what to check for when assessing your access controls and here's an example control we would put in place to implement these checks within our organization for all the systems in our audit scope

you want to have a control to capture how users authenticate into that system we also want to address the least privileged access to cc 6.1 for using aws a control like this is a great way to capture this other things you need to set up procedures for and right controls to cover will be security basics like onboard offboarding user access control reviews you'll want someone who owns each of those processes for startup it might just be one person but in a larger company it will probably be several people you also need to make sure you're implementing security awareness training and track who received the training and when this really doesn't need to be anything fancy

you can build a simple training yourself to cover how to say securely use your email system how to configure mfa and teach users how to escalate potential security problems and then track who you give the training to and when another critical area is change management aka ensuring only modifications to software systems that we expect to be implemented are implemented here's one of the principles that covers this area it pretty much says that we verify and that we track modifications so if you're using a rigid waterfall development flow it can be pretty obvious how to implement this and many times the control sets that others come with assume that you're using a formal sdlc in a waterfall flow

however you can also meet this principle in agile environments that deploy hundreds of times per day using automated testing and ci cd pipelines note that these are some of the points the auditor will look for and we can do each one of these in that agile cloud environment so for example here are two controls showing how we can meet this principle without that formal waterfall splc note how we capture some of the points the auditors look for documenting and testing changes in a way that shows how our cloud-based system handles them another area that we need to cover is patching and updates we'll need a policy stating what our patching timeline is so for example

critical fixes may be fixed within 24 hours less critical ones that we rate medium within a week and we will need to retain logs to show in our security patches that we've installed on in-scope systems we also need to perform regular security testing such as getting an annual penetration test and then show that we've remediated any issues found during that test one area where a lot of smaller companies are unsure how to begin is risk management you want to make sure you think about and write down all the risks to your business especially any areas that are vulnerable to fraud you will document each risk and its severity impact and likelihood rating such as low

medium and high into a risk register which you can store in a tool like jira or spreadsheet you can certainly use very complicated custom risk management tools but spreadsheets are also fine for your first few years in a sock too you definitely want to make sure you document an annual review of each risk as well as compensating controls that you've implemented a sock 2 auditor will definitely want to make sure that you have a way to be notified of system outages or security incidents for this area you might want to show how you use guard duty capture screenshots availability alerting you've configured do a screen share walkthrough of your sim or your other security tools

and to show post-mortem write-up a past availability or security incidents particularly if you can tie them to patches that you need to correct the root causes being able to track improvements you need as a result of these postmortem reviews will definitely help show that you have a mature program in place so once we've implemented various policies and processes to meet all these sections of the security section how do we ensure that the processes are being followed within our company a sock 2 auditor will ensure that you've verified everything is running smoothly there are a couple different ways to do this some of the nice ones are involved the use of automated tooling like turning on branch protection github

to ensure that code reviews are being done your team will also want to meet regularly to perform some checks to ensure policies are being followed were all access control reviews finished last quarter do all production systems still have appropriate monitoring implemented and alerting the right teams if you do these checks monthly or on some other regular cadence you should then write up short minutes documenting what you verified and any corrections you put in place congrats you now have a lightweight internal audit process here's one example that we've set up that breaks down various internal task checks by month but you can use any schedule that works for your company note here that for each section

including access control review and workstation controls here we have both the security controls that security or it or developers should be doing and our second meta level of internal audit review that we will be doing in order to verify our controls are correctly being followed so now we've reviewed a couple of the areas that sock 2 audits generally cover we want to look at how we would show that our organization is implementing and following all of these controls throughout our period these are two controls we discussed earlier to implement cc 1.3 in our organization but how would we prove to an auditor that we're following these here are two possible types of evidence we could use for this control

good evidence is generated by a system your employees use all the time not something you need to remember to backfill so something like gusto which you may be using to manage payroll or benefits is a great tool to lean on for evidence generation it should already be up to date and give us accurate evidence and also here are two types of tools we could use to show that contractors have defined managers within an organization and remember as you gather this evidence you can redact sensitive information like salary information and a screenshot of the payroll system what about these other controls for these we would likely be taking screenshots of the cicd pipeline or the security group configuration

files auditors need to authenticate the evidence that you provide and so they may ask that you do a screen share or project in a conference room as you log into the system to run the tools and take these screenshots or capture these logs so you might have heard that there are two types of sock 2 audits a sock 2 type 1 and the sock 2 type 2. when you go to have your sock 2 audit performed you'll have to choose which one you want done both a type 1 and a type 2 look at the same principles and you would use the same control set for both the difference is what sort of evidence you would

provide and the time period the audit looks at

a sac two type one a little more of a proof of concept on it it checks to see if your controls if implemented correctly would fulfill the principles you're being audited against if you've never done a stock 2 audit before it's a very good idea to start with a type 1 during the type 1 the auditor will look at your policy documentation you'll often ask to see screenshots and other evidence of the implementation of your controls but for each control you need only show that was exercised once so for example your hr onboarding controls you may be able to pick a recent employee and show that this chosen employee signed an nda and receive security

awareness training and show their onboarding checklist for a type 2 you will need to show that all of your controls operated over everything over the entire period of the audit populations are requested on your auditor for all the the people who worked in your company or perhaps all the jira tickets for code that was deployed to your production system full list of your releases or your versions from github or perhaps all the end points in your inventory or all the subscriptions in your cloud each one of these lists will be then used to request specific pieces of evidence to show control operation if you are doing a type 1 audit this is a little bit less important

an auditor might ask for a list of your employees and type 1 just to ensure you're tracking the information could generate it but they likely won't select particular items from that list to ask for evidence about however in a type 2 an auditor will want to authenticate your population polls which might be done with screen sharing and then we would want to simply so if you're doing a type 2 audit the auditor will want to make sure that your control is always operated during the test period they do this with sampling the auditor will randomly select the subset of items from your populations and ask you to provide evidence that you control operated on those samples so for example

they may ask for the full list of all your employees hired during the test period such as over the last six months or over last year from that they may select a set of employees and ask you to provide the signed nda's onboarding checklist evidence that a permission group owner granted permission for each permission type they have such as access to an aws environment or github permissions you would do that for every employee selected in that sample so as you build your controls and procedures think about how you routine artifacts that show that the procedure was followed also think about retention if you have a control that says that you run automated tasks on every production

release make sure that you retain logs from all the test runs during that test period if your test period is one year long but you only keep two weeks of test rent logs you have no way to prove to the auditor that the tests ran for the other 50 weeks and this can lead to a control failure so the best types of evidence are those that are created by the system used to do the action and which require users to have logged in or otherwise authenticated themselves to it so that you know who did the action ideally also with a time stamp with our automated test control your ci cd pipeline should automatically create a test log

it's great just make sure that they're being retained on a disk somewhere if you have a control that says that you do access control reviews try to use a tool that logs if the review happened so for example you could build a tool that generates newly populated google spreadsheet with all the members of each aws security group and email that to the group owners each quarter they could then add a note to the spreadsheet about whether the member should still have access or whether they removed them now you have authenticated evidence in that google sheet with timestamps showing that the access control reviews happened audit scope by the way is something we referred to a few times here

it is a definition of what systems are actually reviewed in the audit for a stock 2 report the auditor will help you with a system description that goes into the beginning of your audit report in which describes the scope of the system is covered do you want to restrict your sock 2 to just your aws or gcp environment our user laptops and scope as well your auditor will probably have input on that but you should think ahead of time about the advantages and disadvantages of various scopes so we've talked a lot about what audit firms will look for during your sock 2 audit let's also chat a little bit about how you can select the firm to do your audit

this can be a really big scary choice if you want a reputable firm who you can work well with if you've built your control set to match your company's security program and how you operate as a company and you might want to find a farm that can audit you against your own control set some firms will be able to check that your control set fully implements esp's and they may then have slight adjustments to ensure that you're correctly implementing the tsps often they will add supplementary controls at this point or they may point out that you have duplicate controls that can be merged together but some firms may only be able to audit you against their standard set of

controls these controls could be overly cumbersome for smaller or agile shops you should have a very frank discussion with the audit firm about what control set they will use and what evidence they will expect you to provide for each of these discuss with them how much flexibility there might be in their control set and any gaps that they see in any controls that you bring to the table

similarly each firm will collect evidence in a different way it's a very good idea to ask to see a screen share of how this tool works for the firm and you're going to spend a lot of time interfacing with it is it clear to you how you will tie uploaded evidence to a particular control definitely make sure you discuss how they handle situations where one piece of evidence addresses many controls how do they let you know if a piece of evidence is inadequate and you need to provide a different screenshot or log finally can you easily communicate status through the platform do you know when they have done done an initial sign off on a control or when

they need more information or more screenshots or better screenshots of timestamps in them from you those pandemic a lot of audits have shifted from a few people squeezed into a conference room for a week more virtual events perhaps some kickoff video conferencing and screen sharing walkthroughs but otherwise a little bit more asynchronous rounds of evidence collection and review facilitated by the audit firm's evidence collection tool you will want to ensure that the firm understands what your application does during the kickoff and schedule time for walkthroughs of things like monitoring and alerting systems including appropriate technical subject matters so that the auditors can see how you have implemented your controls also note that you'll need a way to

track your status internally i'm a big fan of syncing every evidence request into the company's jira and then tracking evidence within there closed uploading his attachments and closing the jira ticket and we believe that the control has been satisfied but note that you should use your own system whatever works with how you usually work at the end of the audit you'll receive a report with your audit result with luck this will be an unqualified opinion and state that the firm was able to verify that all of your controls operated across all of the samples that they checked throughout the entire period it is possible however that the control or that's report will note that some

controls did not operate in a tiny startup for instance it's possible to have a note saying that for example off-boarding controls did not operate and that might simply be because no one left the company during the audit period this sort of control did not operate is fine you don't want too too many of them but people will understand that especially a small company people may not join with the company and people may not switch roles however if you are not able to provide evidence of a particular control operating for the full period you may receive an exception on that control for example if we have that ci cd pipeline that only retains two weeks worth

of logs and we had a year-long audit period you may find that the audit firm has put an exception in the report explaining they could not verify that all releases during the year were verified by automated tests before being released to production if you don't have the logs anymore the audit firm cannot just take your word for it so qualified disclaimer or adverse opinions mean that the audit firm is not able to verify that your control is operated during the test period and essentially are feeling opinions in the case of a sock 2 type 1 it is highly unlikely you would get one of these the audit firm will instead work with you on implementing each of the control set

until you have a full control set that is adequate to fulfill the tsps however in a sock 2 type 2 with a defined time period you must be able to show to the audit firm that every control operated across every item in your environment throughout the entire period if you receive a qualified disclaimer or adverse opinion you need to work at the audit firm understand what caused the failure and how best to correct the gas for the next audit so after your first successful type 1 audit you'll want to roll into a test period that would conclude with your first type 2 audit and after each type 2 audit you should begin another test period to

end with your next annual type 2 audit at the end of each audit however you should sit down with everyone involved in your program and discuss what went well and where you can improve your processes it's possible that your auditor may provide suggestions for better ways to generate evidence or improvements in your procedures flagging opportunities for automation or fine-tuning your processes will make each next audit cycle go much easier at the same time an audit firm will often accept expect to see some growth maturity of your processes you may receive recommendations from the audit firm about tweets you can make in areas for growth you want to take these under consideration particularly areas like risk management

where you can show that you have a more sophisticated understanding of the risks facing your business and better ways to implement compensating controls and to address them year after year and so we've now covered the basics of a soc2 audit hopefully this information has set your security program up for a successful social prep and audit i'm happy to answer questions in our q a period or come by our discord please tweet me at 1dck and i will have these slides up so that you can grab things like the url to the trust services criteria later thank you all right dive in i will uh i have the discord absence so if you guys are not hearing me please yell

loudly in discord i would say that the question about can a company use the controls to define the scope of the sock 2 report is a great question one of the first things that we like to talk about with people is whether you want to restrict your scope just to your cloud environment or whether you're also going to include your user laptops and your office and so forth and so obviously if you start bringing in physical security controls um that does change the scope of it here if you're restricted to the cloud environment the physical security controls are basically all inherited from aws or from gcp wherever you guys are running as soon as we start talking about

cameras and so forth in the office that becomes in scope and one of the things i like to tell people is sure we could restrict it just to your cloud environment but if you have confidential customer information on your user laptops or people are doing things on the mobile devices those need to be in scope because really people are concerned about getting your sock to report and finding out are you going to protect my information and so if we have a ton of customer data on user laptops but it's not in scope then that can be an issue and that actually is something if i see a report from a company that is just restricted to

the cloud environment i'm going to look for data classification so the controls that says that you can't put customer data on user laptops and if not i'm going to follow up with them with questions um so yes that is sort of one way that you can use controls to define the scope of your report that's one of the questions you should uh address with your audit team you know this is what we'd like this scope to be and so let's make sure that the controls meet it um i would say there was also a question that went blind before we dive in because there's so decaf has a fun point which is saying hey does that mean that we should think

about scope as following where the data goes yeah if you're beating the spirit of the sock too which i'm going to understand i hate to say this when people play compliance games very much and people play scope games a lot if they're following this correctly then yes um you should think in terms of anything that has the customer confidential data which is what we care about protecting from most of the software reports when we're talking about a cloud sas that yes there should be controls that cover everything in there and they should have a very strong data classification policy that says you know customer pii is this particular level some of our ip is this other less sensitive level um

you know and there are controls that address where each one of them can go and controls that say how you secure the data on each of those places like that jim chimes in that says data mapping is now actually one of those controls yeah yeah you pretty much are going to have a very hard time trying to do a sock too without a data classification i think providing architecture diagrams and so forth to the auto team they will want to see how that flow goes the answer just can't be it goes everywhere uh you're going to have an extremely difficult time doing a sock 2 with a reputable audit firm with that kind of answer

yeah so wendy that actually gets to one of the questions that someone raised earlier which is hey what do i look for when i'm sort of poking around to say this and and i guess there are two ways right let's let's answer the if i want to actually show i'm secure and and then maybe you could give us the uh venal bad answer which is what do i look for if i just want to pass if you just want to pass oh man so let's answer the correct one first um you should talk to the auditors when you're interviewing them and make sure uh since we're talking about cloud sasses and so forth if they

even understand what aws is and what gcp is there's a lot of auditors have been out there are much more used to um you know data centers um sort of the 90s architecture and so forth and they're probably great auditors but for that sort of environment and so we want to make sure they understand our technology and looking at around the audit firm's website do their auditors have certifications and of course you know certifications do not mean everything but they can be a little bit of a ground for looking to see if the auditor's gone um and published you know talks or written blog posts or stuff that sounds credible and also um if you're

doing vendor security reviews for companies a lot of times you are seeing a lot of sock chews come in and i sometimes make note of like hey you know the intro to the sock to report sounds pretty good the notes um and the controls here sound like the auditor understands what's going on and like okay audit firm probably has at least a little bit of a clue um on it and so you sort of get used to audit firms that you know are pretty good in the cod area if you just want to scrape by and pass um you want auditors where basically i hate to say this but if an auditor doesn't understand the

technology it's sometimes easier to push over uh things too it's happening behind the magic screen here don't dig in too deeply um you know go for the ones where if you say we use blockchain they'll be like oh that's good yeah yeah um i hate to say but i've had arguments with auditors about why i don't have av in my lambdas and i'm like i let me sit down and attempt to explain to you how why it's super unlikely to have malware sitting in my lambdas and talk about why that's a really dumb thing to be asking me like you know what's level set and what's going on here um and that's happened with auditors who

are pretty up on aws but maybe not all of the newest stuff

fun is there a question that you had in mind or we can we can there was the uh one that was asked a little bit ago about is there a typical set of controls available for a small startup or do you have to start with the controls provided by the auditor and then customize from there um a lot of times if you don't have any controls at all the auditor should be able to come in and give you a fairly good set of controls some of them are more flexible than others about how much modification they will allow some of them a lot of times due to the nature of how they run their audits and

how they collect their evidence really uh struggled to change the control set um and my advice is if you're a small startup that runs on aws unless that is a really good control set for that you may want to stay away from working with them just because it's gonna be a lot of struggle for you as a company as a need to suck too um but yeah so i really don't want to come in and be like well i'm a consultant and i can do this um i have a set of controls that i often start with with a company but then i interview them and talk about like okay how are you actually doing this and so

you can also do the same thing you can sit down like okay i'm going to look at the trust services criteria that says that i need to secure access to customer data how are we doing this how are we gaining access into aws well let's write a control to say what we do and you don't need to worry about perfectly refining that control that is something the auditor can work with you if you say we use multi-factor and you need to assume a security role within aws or we you know use multi-factor and gcp the auditor can help you sort of clean that up to be the appropriate language for it and one of the things that

people sometimes get stumped about with sock 2 when they start it is that there's essentially a many-to-many relationship one control can fulfill many trust services principles and also you have many controls that fulfill a signal trust services principles it's not like you need to write one mega control to meet a trust services principle you're going to be fulfilling different aspects of different controls and so that many to many could be a little weird when you start out but that is essentially how you know we work with folks to meet it we're basically trying to capture what their processes actually are and obviously there's gaps in those processes if we say okay you know you have all these really great

controls for aws but you also allow people to put data on your endpoints so we need to talk about your laptop controls let's talk about how you're ensuring that people are updating the software on there and requiring file vault for bitlocker and so forth and an auditor can do the same thing they can catch those gaps and work with you to address them yeah i like that well are there other questions i really like jim's about using grc platforms to manage stock 2 and compliance frameworks i got to be honest i use jira extensively there's a jira plug-in called recurring tasks that you can buy in the jira marketplace and it allows you to set up

templates and it will fire as often as you tell them so i run access control reviews through that i run a lot of internal audit through that like you have an annual one that will fire to do go schedule our pen test and annual and a few months later to make sure that we have tracked things that came out of the pen test and we're addressing them and then also google sheets i don't use a lot of custom grc software mostly because i work with startups that are already usually paying for google docs and i don't want to be like oh you need to go buy this thirty thousand dollar tool um i do risk registers in uh google

sheets most of the time or within jira and those tools um can be flexed especially things like jira recurring task plug-in in order to meet most of the needs for a small company doing this talk to you obviously if you're a really big huge enterprise and you're also doing photographs and so forth you're in a whole another level of maturity and you probably already have uh grc platforms in place which you know would that make sense to do that yeah cool so you talked about uh sort of automation and how that could scale are there things that you see are there new tools coming on the marketplace or even the open source that you think are

really exciting um oh well that's a good question uh dependable has made our lives so so so much easier on the vulnerability managing thing if we set up branch protection within github and we set up kendabot and whatever those two things alone can get rid of a lot of problems that we've had in the past and making sure that all the changes that get merged in have been reviewed and making sure that we're on top of getting uh patches fixed uh some other kind of automation um the jira recurring task is one of my favorite things i've seen people do stuff with uh you know scripting against the octa api and so forth some of that usually i will provide

advice on like hey i see us struggling in the sock 2 every year for this particular thing like you're um do you have sres or other folks who are able to go in and do it as a consultant i often don't end up writing it myself for them but definitely doing code reviews on things and so forth to make sure that you know whatever we put in place is not too brittle fun and yeah and i'd like your super well i'd like your approach and say hey you know it's often google docs is going to help us as well yeah yeah uh flagging uh your gaps with different conditional formatting and things just those very simple things will go a

very long way to help you sort of see at a glance what your status is for these and for me that's really important because a lot of times i'm running uh three or four different sock two audits at the same time and so there's a lot to sort of track through there uh so let's see um there's a question about how do you get your auditors comfortable with ci cd uh if you're looking for right if your auditors are a little more classic big industry how do you sort of help them understand that they want to see that a lot of times it's getting the sres or other engineers in there who have written the tests and we talk about you know

here's what the gates are we don't deploy until certain tests go some folks still are using ci cd but they hold things at you know maybe a five percent deploy to a canary and then require someone just use a slack bot or something to approve it to go beyond that and so if you have auditors who are really uncomfortable with things you can do that sort of uh last gate to push things out um but yeah they're usually once we talk through like uh here's the checks that we're doing and it's not just you know a bunch of really stupid print out uh within the test it works i remember there was a recruiting ad for a

giant tech company maybe 10 years ago and it was someone saying i've only been here three weeks i'm already pushing code i'm like i don't know if that's a good thing it is a good thing though that means that you have really strong unit tests and you have a really mature framework um and you're rolling out to canary and making sure errors aren't spiking and then approving your release to go out further yeah so that's a very important sign i love it that's fantastic so uh we only have a few more minutes and when i wanted to you could speculate you know this isn't necessarily heavy aware but as you look towards the future of this

kind of compliance regime what are some of the things that you think maybe aren't going to be in the certification today but you have a hunch we're going to need to think about in the future um let's see i have not yet had any auditors asking me about s-bomb and i think that that's really something that's kind of important coming up um yes yeah i mean i would really love to see auditors just getting more comfortable with understanding what security groups are and working with the tools that azure and so forth make available aws and azure have a ton of really great compliance tools available and so maybe making it easier for those to connect directly to

audit firm evidence collection things so i don't have to do the manual seeking between them excellent well wendy one of the things i'm always blown away by all your presentations you take things that are sort of dry and obscure and legal and make them not only accessible but really interesting so thank you so much for doing that again uh you're just gonna have to work to find more boring topics to get us all really excited about because i know a lot of us are now more excited about sock too well thank you so much everybody