Security Is Everybody's Job (Part 2)

DZone 's Guide to

Security Is Everybody's Job (Part 2)

This article will define application security, to line up the audience for the rest of this series on DevSecOps.

· DevOps Zone ·
Free Resource
Application Security is every action you take towards ensuring the software that you (or someone else) create is secure. 

This can mean a formal secure code review, hiring someone to come in and perform a penetration test, or updating your framework because you heard it has a serious security flaw. It doesn't need to be extremely formal, it just needs to have the goal of ensuring your systems are more secure.

Now that we know AppSec is, why is it important?

For starters, insecure software is (unfortunately), the #1 cause of data breaches (according to the Verizon Breach Reports, 2016, 2017, 2018 and 2019). This is not a list that anyone wants to be #1 on. According to the reports, insecure software causes 30-40% of breaches, year after year, yet 30-40% of the security budget is certainly not being spent on AppSec. This is one part of the problem.

The graph above is from the Verizon Breach Report 2017. Hats off to Verizon for creating and freely sharing such a helpful report, year after year.

If the problem is that insecure software causes breaches, and one of the causes is that security budgets don't appear to prioritize software, what are some of the other root causes of this issue?

For starters, universities, colleges, and programming boot camps are not teaching the students how to ensuring that they are creating secure software. Imagine electricians when to trade school, but they didn't teach them safety? They twist two cables together and then just push them into the wall, unaware that they need two more layers of safety (electrical tape, and then a marrett). This is what we are doing with our software developers, we teach them from their very first lesson how to make insecure code.

Hello (insecure) World

Lesson #1 for every bootcamp or programming course: Hello World.
Step 1) Output "Hello World" to screen
Step 2) Output "What is your name?" to screen
Step 3) Read the user's input into a variable ( note: we skip teaching input validation)
Step 4) Output the user's input to the screen with a hello message ( note: we skip output encoding)

The above lesson teaches new programmers the best possible recipe for including reflected Cross-Site Scripting (XSS) in their application. As far as I know, there is not a follow-up lesson usually on how to ensure the code is secure.

"Hello World" is the most-taught lesson for starting a new programming language, I'm sure you've seen it everywhere. More like "Hello Insecure World".

Although there has been some headway in universities and colleges recently, most of them barely scratch the surface in regards to application security.

Another issue that contributes to this problem is that security training for developers is costly. While this is true for all types of professional training, security training is significantly more expensive than other forms of technical training. A single course at the SANS Institute (a well-respected training establishment that specializes in all things cyber), could cost an attendee as much as $5000-$6000, for one week of training. 

There are other less-pricey options, such as taking a course when attending a conference, which usually ranges from $2000-$5000, however, those are of varying quality, and there is no standardized curriculum, making them a bit of a gamble. I've taken several pieces of training when attending various conferences over the years, and I'd say about 1/2 were good.

There are much cheaper alternatives to the options above, and they are of very varying quality levels. I've seen both good free courses and somewhere I wish I could have my time back they were so bad. 

Most of them do not provide a curriculum to follow either, meaning it is often unclear to the student which other courses they should take to get the specific job they want. It is very easy to waste quite a bit of time; I know, that is how I started my AppSec career... Although I was quite lucky to have a professional mentor guiding me, which made it a lot easier. But I digress.

Before I continue this article I must do a tiny bit of marketing: my website, SheHacksPurple.dev, provides training. We just released our first course; Application Security 101, for $99. I'm biased, but if you want to learn about how to create secure software you should check it out. Sign up for it here: Application Security 101.

See how lonely she looks? She's the ENTIRE security team! #WOCTechChat

Another cause of insecure software is that the security team is usually grossly outnumbered. According to several sources, there are usually 100 software developers for every 10 operations employees for every single (1) security professional.

Let me repeat that. There are 100/10/1, Dev/Ops/Sec. With numbers like that, you can't work harder, you have to work smarter. Which is where we are going with this series.

Now we know the problem and several of the causes, what can we do about it? The short answer is DevSecOps, and the long answer is 'read the rest of the blog series'.

For now, though, let's define DevSecOps before we dive into what DevOps is, The Three Ways, and so much more, in the next article.

DevSecOps: performing AppSec, adjusted for a DevOps Environment. The same goals, but with different tactics and strategies to get us there. Changing the way we do things, so that we weave ourselves into the DevOps culture and processes.
application security, appsec, data breach, devops, devsecops, it security

Published at DZone with permission of Tanya Janca . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}