IAC (Infrastructure-As-Code) SAST - What's That?

um good afternoon everybody hope you're all well and having a good day i'm shaitra i'm a security engineer at yahoo the security team at yahoo is called the paranoid so i'm a paranoid yeah i've been a developer for a long time now i've spent more than 15 years coding debugging testing software in various technologies and domains and now i'm focusing full time on security so today i want to share with you some things that i have learned about iac sast hope you find it useful so i just want to get some definitions out of the way so i can start using this uh short form in my presentation right so what is iac iec is nothing but a

collection of machine readable definitions in the form of your code script policies or templates which are used to deploy and provision your infrastructure and sas as you may all be familiar with is nothing but static application security testing it's a methodology that analyzes your source code now your applications code in our case for the stock the infrastructure code to find and find any vulnerabilities in them the main objectives for this talk for me are today to introduce you to iscs give you some examples of ics as tools out there and to answer some obvious following on questions of why do we need iscs and where in our devops cycles would these ic sas tools fit in

who are any star wars fans here oh not many okay well if you would you would have enjoyed these imageries anyway so uh the next three slides are the tldr for my presentation so we are all on our cloud journeys on-prem uh private cloud public cloud does not matter and we are all in a rush to containerize our applications and we have been smart about it and we've used infrastructure as code to uh deploy and provision our infrastructure which is great i mean because that allows us to kind of deliver a fast software quickly so that's good and we are delivering our software faster than light which is great so what can go wrong well as it turns out quite a lot can so

if you have not made sure that your infrastructure code does not have any misconfigurations or it has if it has not been coded properly then all these mis configurations can lead to potential vulnerabilities in your infrastructure when it is deployed so then what do we do about this so we do want to use infrastructure as code because we do not want to deploy our infrastructure manually so we still want to use isc then how can we find these issues early on during the development cycle well as always yoda has an answer for this so yoda says ins install or implement icsas in your workflow and i think i agree with him that was basically the

nutshell my presentation in a nutshell so feel free to walk out and get a break but for those of you want to know more let's carry on so i'll briefly introduce to you what iac is before jumping on to introduce what uh iec sas does and to fully appreciate why we need icsast we need to first understand uh and i need to scare you a bit here we need to see what are the possible vulnerabilities that can happen in the infrastructure because of misconfigurations in our infrastructure code and then i'll show you some examples of icsas tools then we'll see how we can deploy this into our devops cycle and i'll conclude so i see woohoo yes we all need to ic is

the way to go about it we do not want to do stuff manually so we we need ise that's a smart thing to do so again briefly what is ise iic is a collection of your machine readable definitions for your infrastructure which you have coded which which is in the form of uh configuration files templates policy scripts now again these are all in the file format so which means this can be version control so all the goodness of the version controlling comes with it and there have to be some tools that understand uh how to and read these files and then go ahead and do what is necessary to deploy and provision your infrastructure that your likes of cloudformation

terraform kubernetes are some of the examples so these tools understand your code that you have written and go and deploy the infrastructure for you your network your security your storage application infrastructure here are some more examples of some ic tools out there in the market today this list is not complete or comprehensive by any means it's just to give you an idea of what an iec sas tool is you might be familiar with this um yeah so ise has a lot of benefits and that's why i said it's a smart thing to do so it helps you automate your workflows and because it's in the form of a file which means it you can repeat it you can use

the same file or the template to deploy your infrastructure and provision it in different regions or maybe you can hand it over to your other teams in your organization as a reference template and because there is no more hand cranking involved that means it's scalable and if you've ensured that your template is secure and there are no issues in them no security misconfigurations in them then you can be assured then when when that when these uh this code infrastructure code is deployed that your uh network that your network and your infrastructure is reasonably secure also right and as uh darth vader correctly points out here if you have not made sure that your security that your

infrastructure code is secure then all these benefits that i listed here can so easily turn into pitfalls i hope you can understand that so yes as i said to fully appreciate why we need icsast in our workflows we need to first understand what are the possible vulnerabilities that can happen in the deployed infrastructure because of the misconfigurations in your code right so let's see some of the dark side of iic now i have listed some potential misconfigurations that could lead to potential vulnerabilities in your infrastructure so in the first one here um network exposure could happen if you have not been careful about configuring your firewall properly if you've not made sure that your uh cloud storage

devices your databases are not available publicly which normally you don't need to make it publicly available and for whatever reason you've left your ssh ports open to the public right and yes unauthorized privilege escalations can happen if you have not stored your secrets your keys properly or maybe you're running your containers as root and yeah or maybe you've given too much permissions to your resources which could lead to improper access control or maybe you've not enabled logging at all on your um maybe on your s3 bucket or and maybe your locks are not encrypted so that's that's one of the over vulnerabilities of insufficient logging and insecure logging how do these misconfigurations in your infrastructure code happen they can

happen for a lot of reasons so it could be a simple oversight by an engineer or maybe the engineer who is coding this infrastructure file configuration file is new to iac uh the the developer is a comes from an application development land is not familiar with how to code an infrastructure file uh or maybe it's a complex iac configuration file and and it's code after all so no code is bug free or may and we have fast moving devops cycles these days there could be gaps in our testing or maybe we are depending too much on our pen testers and our dynamic testing tools to find issues in our deployed infrastructure and so not paying enough

attention on our testing testing our infrastructure code well i have some industry reports here to back up back me up on what i'm saying so in the first report here this is from um uh 2021 iec research report from sneak and what i want to highlight here is that about 45 of the mis configurations or vulnerabilities in your in the infrastructure was found after if it was deployed and according to the survey it took them more than a week to discover a security issue if that was discoverable i would say and more than a week to fix those issues when found so as you can understand how stressful it would be for an engineer first of all it's very expensive

to go about fixing these and then very stressful for the engineers who are fixing it here in the second report industry report this is from the security team of palo alto networks this is a cloud threat report where they do show you all the different types of vulnerabilities that were found in the publicly available infrastructure code templates but another thing that this is kind of very new this information what they're trying to say here is that it's very important to secure your infrastructure code in order to secure your supply chain so uh here they're taking example of terraform and they're saying that their num your chances of having uh misconfigurations in your iac file increases uh as the number of your

terraform modules that you're including in your code also increases and they're clearly pointing out here that these misconfigurations are not happening because of the public cloud provider you're using nor because of the uh iac 2 like in this case terraform that you're using but these are happening because of us the coders who are using these modules incorrectly coding them incorrectly so if i have not scared you enough let me make it more relatable to you and make it easier for you to understand how these can happen in your code right so let's see some examples of how these misconfigurations can happen in your code i've taken some these examples from the publicly available terra got project

this is from bridge crew terracotta project is a very interesting collection of files they have a collection of uh vulnerable infrastructure as code files so it's a great tool to use when you are in the process of selecting an iec sas tool for your organization say you want to evaluate a tool you want to benchmark a tool then i would say go check this out so yeah let's go through these examples um in the first case so as you i've highlighted there um so the ssh port 22 um was left open to the whole world and we know it's not a great idea at all in the second example the s3 bucket is not encrypted at rest

here in the third one there was no logging enabled on the s3 bucket and here in the fourth example there was no fine grained access control on your for your elastic search i hope i've scared you enough now so this would be a nice segue to introduce iec sas to you so let's try and see now how ise sas can rescue us right help us find out these misconfigurations in infrastructure code very early in our development cycle so what is icsast ics has a static analysis of your infrastructure as code to find any security misconfigurations in your code so ideally the the it should look like this so you have your configuration files your templates

scripts and policies and you have your ic sas tool the sas tool runs a scan on your configuration files and it reports a bunch of findings and these bunch of findings these findings should be fed back to your developers or production engineers who are whoever is working on it so they fix it and they fix this in your configuration file in your uh templates rather than fixing them in your infrastructure files so as you can see this is truly shift left this is so close to the developers you are fixing issues in your code even before the infrastructure is deployed right and another point i want to make here is that you might say you have um

dynamic testing tools or you have your pen testers testing your infrastructure so why would i need an ic sas tool but you see there's more information in your infrastructure code than you would normally have once your infrastructure is deployed two examples that come to my mind are improper access control i doubt any dynamic testing tool would find that and yeah maybe good pen testing would find that but you would need to have very good test cases bad test cases to find those improper access control issues and another one is unauthorized privilege access so again here um you would need really good say for example your containers running as root i don't know any tool out there that could find

this for you unless you have good pen testing now again how many of us do good pen testing that's that's yeah but these things can be found by your by just simply scanning your infrastructure code um i ran uh an ic sas scan on some of those vulnerable examples that i showed you previously i'm here taking a checo bridge cruise deco as an ic sas tool example again to point out these these are just examples i'm not promoting any tool this is just so you get an idea of how this can be done so when i ran the checkout scan on those vulnerable files in the first case where the ssh port was left open to the world uh it clearly

shows that what the issue is in the code and where in the file is the issue and how and it also provides some kind of guideline as to how can i go about fixing this issue um yeah in the second one it says it clearly says ensure all data stored in the s3 bucket is securely encrypted at rest here in the third one it says um ensure that s3 bucket has access logging enabled uh for the fourth one make sure ensure i am policies does not allow right access control access without constraints so i hope at this point you understand uh briefly like get an idea of what iic is what are the misconfigurations in the

isc that could lead to potential vulnerabilities in the infrastructure and how i see sassed by running scans on these infrastructure code you can find these vulnerabilities early on in your development cycle and now i'll show you some um examples of ics tools out there which you can use to run your scans uh on these configuration files um here are some popular iec sas tools in the market today um again this is not a complete or a comprehensive list at all just some examples and i'm not promoting any tool but i thought it was only fair to point out some of the tools that i have used and it is a very fast moving market this

one any big security company tool provider that i know is in a rush to also offer an iec sas offering so very hot topic very fast moving market so you go do your own research benchmarking um and evaluation of the tool to decide what tool would suit best for your organization and in order to do that here are some criteria according to me which are important when you go about selecting an iec sas tool for your organization first and foremost it should support the file types that your organization is going to use kubernetes um cloud formation terraform um or these days if the new kid on the block is pollumi i think so you have to

make sure that uh this tool supports all these file types and it would be nice if it could support some of the industry security standards like cis and nist and you do not want to run these tools manually that's not scalable at all so the tool should have the ability to integrate with your software control management systems like git git lab or github um and yeah output format may become important if you want to forward your findings uh from the tool to a dashboard for easy viewing metric and uh ability to understand the context and resolve references in your ise becomes important because you might be including other modules from other git repositories so if the tool

can also scan that and get a better context of the code then that would mean low false positives right yeah i missed a point that so high signals to noise ratio is good i've seen that some tools out of the box have better signal to noise ratio that is low false positives compared to some others some tools perform better in some areas and some others and something else so again go to your research and benchmarking to figure out what suits you best and if the if you could add your own custom rules custom checks um and maybe modify the existing checks that would be handy um of course um like every other tools you have the open source version

and the paid version and paid versions have some fancy dashboards available you they have integration with your github github app gitlab githubs app applications and they can report the issues to you so you can go and fix them or open a ticket so um and i've been saying static analysis but these static analysis tools can also also these days uh run a scan on your runtime environment and see what is the different difference what is the drift between your runtime environment and and your code so i think this is handy so that you once you find what the drift is you can go back and fix it in your infrastructure code well i would recommend never go and fix it in your

deployed infrastructure rather come back and fix it in your course so you come up with a secure template to deploy it again and again now that we've seen some examples of iec sas tools let's see how we can deploy it in our devsecop cycle here is a simple user flow diagram from a from a user's perspective a developer's perspective right so it would be ideal if uh the tool is integrated locally in the uh ide or maybe um in in the local git git right so that the developer as and when the developer is coding you the developer gets an immediate feedback and they can go and fix this issue then and there and uh integrate it with your git again

say on your code comment or add you get an instant uh report instant messages to say okay here is the issue and you can go and fix it this way or you can incorporate it into your ci cd pipeline wherein you say okay do an automatic scan on every pull request and then you can make the findings you can say you can make it gated or not before you deploy the code some tips for efficient integration of icsas tool this is not just for iec sas but true for any sas tool even your application sas tool so ability to integrate with your ide and sems like github github gitlab for immediate feedback and integration into your ci cd to

automate your workflows you do not want to run these things manually believe me they're not scalable at all and high signal to noise ratio is very important to keep the developers engaged and motivated to go look at those findings and fix them otherwise i'm telling you don't even bother with with the sas tool because it's not effective at all so uh how how can you go about doing this so i've seen that most of the ic sas tools true also for the application sas tools what you can do is you can pass in your customized configuration files where you can just focus on as a for we're talking about a security here so you can just focus on maybe

security issues first uh so i came up with such a configuration file for one of the tools uh i was using i'm using in my organization and then i just focused on the security issues and masked all the maybe high availability issues your best coding practices they are definitely not important in the first run we just want to find high value and meaningful findings to as i said so that the developer is motivated and engaged and they want to look at the findings and fix them not just throw an ic sas tool at them and which reports like hundreds of findings nobody's going to look at them try ask them and fix them so in one such example i found that by

just masking out the non-security related issues i could bring down the fine number of findings from 143 to 16. and effective false management is important so that um as when you find the issue and you see it's a false positive you can immediately go and say okay mark this as false positive so that it does not come up again and again in your scanning and low friction security experience is also very important neither the tool nor the security engineer i believe should become a bottleneck in your workflow we should trust our engineers and as security engineers all we can do is provide them a good tool provide them a good set of high value configuration

files and give them enough guidance and baseline so that when there's a reporting they can go check out the guideline of the baseline for that and go fix it themselves so we have to start trusting our engineers and take ourselves out of the workflow it's very important to find that balance between um the security risk and value flow um here is your typical devsec of cycles i'm not going to go into the details here um what i want to show you here is where in the difficult cycle would your ic sas tool fit in so um yeah it fits in with uh in the coding stage as i said like plug it into your ide or with your git

for immediate feedback and in your build cycle wherein on every pull request maybe you want to automate your scans to conclude um i hope you now see why we need ise sast and what are the different ics as tools out there and where in your dev secours cycle can you fit these icsas tools into um just to reiterate so i see sassed unlike your dynamic testing tools and your pen testing it finds issues very early on in your development cycle very close to the developers so that helps develop a secure mindset to the developers so as and when if they get the feedback saying okay oh you have not configured a user for your container

they're not going to repeat the same mistake again when they're coding so it helps develop a secure mindset and once you arrive at the uh to secure template it kind of becomes like a pave road approach you can hand these secure templates to other teams or you can use the same um template for deploying in other regions having peace of mind that this is a secure template and so i'm not going to find much many vulnerabilities in the infrastructure once it's deployed and the you the developers need not be security experts to run these scans find the issues and fix them as long as we've given them enough guidance and baselines to tell them how to go and fix it

again i'm not saying your iac sas tools are replacement for your dynamic testing tools or your pen testing but what i'm saying is complement your dynamic testing tools and your pen testing with iac sas to find issues very early on you during the development cycle so you can fix the issue in the code and this is truly shift left and we know shift left means less effort less money and less stress so we can never ensure that our infrastructure is fully secure 100 safe but what we can do is make sure that we have taken care of all the known vulnerabilities in our infrastructure and make it make it as hard and difficult as possible for

hackers to infiltrate our systems so why wait use the force and go deploy iscs in your workflow thank you

um any questions yeah so which tools are open source yeah in fact um yeah everybody from here i think as far as i know they have an open source version and they have an enterprise paid version so the in the the you have there's a trade-off right so in the open source version you'll have to uh make sure that you are using the latest greatest and you have to plug it into some kind of your your github gitlab or whatever and once you find the have the findings how do you report it how do you send it to a dashboard maybe so there's extra load work for you if you're using open source and then if you're using

paid version some somewhat you get all that uh you know because it's a great version so all of these tools have an open source version and a paid version any other question i uh how rude are those

yeah that's what i said so it depends on uh how well do they understand the context and if you can say you can you have to you can also pass in not just scan this directory or these files but also look at these other directories which could have other definitions right to understand the context better so depending on if the tools allows for it and i've seen most tools to allow for that but at the end of the day they're still still sas tools right they do their best but as i said if you pass in high value checks to your tools then you can make sure the false positives are low and you only find meaningful results

yeah thank you hi

um yeah for seas well it's not really related to assassin what i'm talking about you're talking about software composition analysis and vulnerabilities in the libraries that you've included or third party code for that you have a lot of tools out there my colleague here can tell you more about it um but yeah there are a lot of again tools out there which kind of scan your scan your code software and then the binaries to see what kind of vulnerabilities are there i can talk to you later or my colleague here can talk to you more on sca if you're interested any other questions

okay i think we're good thank you you can oh by the way um we're hiring if anybody's interested anybody wants to become a paranoid contact me later thank you