So lets start this blog post off being super inflamitory, DevSecOps is broken and there is nothing that the security community can do to fix it.
Now that we have that out of the way… Here’s what I am actually trying to say. There is a fundamental problem with DevSecOps that it seems like a large part of the community is attempting to ignore.
The problem that we are facing is that fundamentally the problem with cybersecurity and application development isn’t the application, it’s the developer.
The solution that we are taking to solving this is like saying that we would like a gallon of milk so we drive to the middle of a cow pasture, stick our heads out the window and hope that a gallon of milk hits us in the hand. The root of the issue is that fundamentally isn’t how it works. The problem isn’t with the software, application, or the IoT device. The problem is at the development team and product manager level. The problem is that there is a lack of desire to do what it takes to make software development a success in this space. So we dump huge amounts of money into trying to solve the issue through the use of software to try to fix software. As an industry we have gotten to the point where we are adding layer upon layer trying to solve an issue without addressing the underlying problem.
I see this more and more being compounded as I talk through some of the conferences, the conversations can usually be broken down into a hand full of different categories:
But the interesting point of all of this is that the tools aren’t the problem and they really aren’t the solution. The base of the issue is that most of the development teams that I have interacted with do not have a fundamental understanding of what security is beyond the need to watchout for sql injection and cross site scripting. The problem is that they don’t know the why. Education is something that has to break through he static of the daily standup, there needs to be real integration of security as part of the development community and the conversations that spring out of that need to permeate to higher levels.
Part of this conversation goes back to my own frustration that I experienced working as a developer. The main problem that I would run into as a developer was the fact that I worked in complicated spaces, spaces where nuance matters. When you are dealing with a complex piece of code simplifying it will only get you so far before you start to destroy some of the value that is offered. There is a reason that complex business rules exist. Optimizations help recover something that’s lost.
So how do we turn this around? I think that the Infosec Color Wheel is a good start, because it places security and developers on a level playing field. It shows where they exist as part of the security community. The problem with the standard red and blue, is that when security starts talking about patching servers and adding firewalls, the development team checks out. Those aren’t part of their world for the most part. But from personal experience if you start talking to developers and developer management about resilience and code based issues you have far more involvement from the teams. Like I said before this isn’t something that the security community can solve, we have to get to the development teams and get them to the table, talk about relevant application based security, and get them thinking about topics like Threat Modeling.
File this under one of those super annoying issues that creap up because I haven’t kept up with things, but in my last training session I ran into an issue with the new virtual machines that I built up and I was having one hell of a time figuring it out. The problem that crept up was that we were trying to use firefox to work through DVWA, the machine that I use is selfcontained to make sure that all of the elements can be worked with without fear of getting banned on a corp network. But this time when we fired up the browser and pointed it to the localhost instance of DVWA we couldn’t get it to show up in ZAP. Perplexed it created more than a couple of issues, with us finally adding a record for it in the /etc/hosts file. But I didn’t like that solution becuase I didn’t know WHY it was happening.
Fast forward a month and I am working throught the process of auditing some of the ZeroNet sites looking for issues and I ran into the same issue all over again. This time I wasn’t in a class so I had time to hunt it down, it appears that the browser companies by default have decided to turn off localhost proxying by default.
To fix this in Firefox:
That will allow you to enable and disable localhost proxying in firefox.
I still can’t get chrome working, as they have chosen to weaken the security of their browser for the sake of advertising, I strongly suggest that you migrate to Firefox or a more security minded browser.
So it’s been another really long time since I have done any updating of the site, but here is some of the latest. I will be going again this year to Nebraska.Code() and will be doing a talk on Encryption for Developers. The point of the talk is to go over some of the specifics of the topic that I really wish that someone else had given to me. Hopefully there will be some more fun information to keep things engaged and interesting.
I was also accepted to Prairie.Code() this year but unfortunately I won’t be able to attend because I was asked to speak at an internal engagement, and at the end of the day I have to make sure that the job is happy. But I will be trying again next year.
On the other side of the coin the new job has me busy, I’m on the road a good portion of the time talking with interesting groups of developers about how to make software more secure. Seattle, Portland, MSP, Pune, Romania, Texas, Iowa, Belgium, it feels like it’s been a blur, and in some ways I think that it still is blurring past me. There are so many things that come up when you talk about all of the training that I’ve been running in all of the places, but at the end of it I really am amazed by the nature of developers. You intrinsicly know that there have smart developers everywhere across the world, but when you have the opertunity to travel to meet them it’s amazing the connection that we have.
Addtionally, I have passed the testing protion of my CISSP, although I am still working on the experince part. It’s tough to get all of the people together in one place to make sure that all of the documentation is good. But all things in good time.
Hopefully more before we hit the 6 month mark. But hopefully at that point I will have some new infromation to share about a project.
Yes. I know what it says, and I know that it’s technically incorrect, it should say that I am closing out the old year, but here is the thing. Things in my life have changed up so much in the last couple of months that I have a very hard time lining them up correctly. It feels like this year has been three years wrapped up into one. One for my time at 10-4, one in transition, and another figuring out what I am doing with the new one, combined with the changes in our family dynamic and the growth of my son.
I went from a job that I was very unsure about to an extension of that job to my parent company. I now get the chance to travel the world and help other developers learn about applciation security. Which is something that six months ago was beyond my thoughts. It also came with (and continues to supply an immense amount of) new stress. But in the course of this I have been to Romania, Belgium, and I am looking forward to India in the next couple of months. Every part of this has been surreal, I have been trying to make security a main part of my work for a very long time, it’s always been a part of it. But now I am looking at a situation where this is a part of my daily life.
This year I helped to get DC720 off the ground and hopefully in the new year there will be more skills and tasks that can be undertaken by the group.
As a final note, I’m never really sure who I am writing these posts to, in a lot of ways it feels very much like a message in the bottle. So if you are out there and you are reading this I hope you are well and that you get something of value from this.
So it’s been a little bit since there was an update but I have exciting news coming down the pipe… I will presenting three sessions this year at Nebraska.Code(). I decided that I would be branching out this year and attempting to add another conference to Prairie.Code(), that was until I found out that there wouldn’t be a Prairie.Code() this year. While I am sad to see it go I think that with the proximity of the two conferences it’s probably for the best.
The great news is that I managed to get three of my sessions accepted this year, one of the sessions is an 8 hour workshop. So without any further yapping from me, here are the presentations that will be presented at Nebraska.Code()
Software security isn’t a tool or a library, everyone knows that you should check your parameters, and watch out for SQL injection, but is that really enough? If you have never had the opportunity to spend time hacking your own applications, you are really doing yourself a disservice. More than ever, the web is becoming an increasingly hostile environment, and because of it developers really need to step up their game. In this session we will go over some of the methodologies that we use internally to test applications, helping developers to think more strategically about designing applications for general security. As part of this conversation I will go over active attacks that we have seen against production sites using sterilized examples.
Application developers are the first line in defending applications from attack, there are thousands of software and hardware solutions to attempt to make your software more safe and secure. In the end if the software isn’t developed properly and securely no amount of software or hardware is going to protect you. In this session I plan to go over, identifying weak code, testing for it, and fixing it.
In this session we will go over in-depth the process for doing application security testing on your own applications. As part of the session we will go through and identify all of the items on the OWASP top 10, how to test them using DVWA (the Damn Vulnerable Web Application), and talk about strategies to mitigate the.
Requirements: Students to the class must have:
This conversation is an indepth dive into the Important parts of GDPR for software developers. Even though GDPR is a European standard, there’s no denying that this is the direction that the software industry is going, more emphasis will be placed on protecting the data that customers and businesses rely on. In this conversation we will discuss the GDPR, the impacts of this law, and what can be done from the software development side to make sure we develop software that follow defense in depth practices.