To answer this question we would need to take a quick look at differences between DevOps, QA and Security when it comes to automation issues. I will have to write about things that are probably\u00a0obvious for any security engineer who was practically involved in traditional AppSec activities such as\u00a0penetration testing, dynamic or\u00a0static code analysis.<\/p>\n
The problem is that for some security executives who came to security from infrastructure, networking or development domains and have never run\u00a0a security scan, \u00a0it’s not obvious at all.<\/p>\n
Since situation when security execs are coming\u00a0from different non-security\u00a0domains is rather common (due shortage of security professionals), explanation below is\u00a0crucial to answer the original question. To put it short, the difference is that DevOps and QA are very much deterministic, while security is not<\/strong>. The picture below illustrates my thought.<\/p>\n Ops:<\/b> run_script(input) –>\u00a0$? (0, non-zero)<\/p>\n QA: <\/b>assert(condition) –> {true,false}<\/p>\n Security:<\/b> scan(app) –> {HML\u2026,false positive}<\/p>\n where H<\/b>igh\u00a0M<\/b>edium\u00a0L<\/b>ow and F<\/b>alse P<\/b>ositives\u00a0are really a human\u2019s decision<\/b><\/p>\n In the case of architecture review and threat modeling, which are two other important AppSec activities that\u00a0are often required by compliance standards\u00a0such as SOC 2, it becomes even more non-deterministic where the results of analysis could be absolutely unpredictable and very much determined by an assessor background.<\/p>\n Needless to say that automation is nowhere close for this type of activities. The best we can do here is to get rid of unnecessary complexity, pseudo-scientific approaches to evaluating risks (e.g. DREAD) and describe the threats in a simple threat table with severities that everybody would easily understand, i.e. “Low”, “Medium”, “High”.<\/p>\n Not understanding this simple truth leads to euphoria and to setting up wrong expectations, e.g. a CISO who came from networking domain can say that a good networking appliance is all we need to completely automate security, while a CISO with a developer’s background will say that writing a lot of code will make security just as fast as DevOps and CI\/CD. Needless to say that both are wrong and\u00a0will not last long\u00a0– they\u00a0will have to leave as soon as their CEO or CTO understand that those\u00a0promises will never materialize.<\/p>\n Does it mean that there is nothing we can do to automate security and make it faster? Of course not. As security engineers we can and we should, and this is what I’ve been talking about for almost three years by now: first at LASCON 2015<\/a>, then at AppSecCali 2016<\/a> and just recently at \u00a0RSA 2017 DevOps<\/a> event.<\/p>\n However, we should always take into consideration a\u00a0non-deterministic nature of security and set up expectations right when talk to our execs.<\/p>\n The bottom line, security is seen as an inhibitor to DevOps agility because it is<\/strong> an inhibitor in many ways, but there are always opportunities\u00a0to improve it by\u00a0researching new approaches of\u00a0doing it. In this regard, my big hope is a deeper penetration of AI and machine learning to the security domain. It won’t be easy, but the progress in IDS\/IPS space makes me think that it will eventually help automating traditional AppSec activities\u00a0as well.<\/p>\n","protected":false},"excerpt":{"rendered":" To answer this question we would need to take a quick look at differences between DevOps, QA and Security when it comes to automation issues. I will have to write about things that are probably\u00a0obvious for any security engineer who was practically involved in traditional AppSec activities such as\u00a0penetration testing, dynamic or\u00a0static code analysis. The […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=\/wp\/v2\/posts\/189"}],"collection":[{"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=189"}],"version-history":[{"count":10,"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=\/wp\/v2\/posts\/189\/revisions"}],"predecessor-version":[{"id":200,"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=\/wp\/v2\/posts\/189\/revisions\/200"}],"wp:attachment":[{"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=189"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=189"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/credelius.com\/credelius\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=189"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
\n