DevOps probably isn't killing developers.
But it is changing how people think about development - from running projects to a focus on building and running services. And more importantly, DevOps is killing maintenance, or sustaining engineering, or whatever managers want to call it. And that's something that we should all celebrate.
High-bandwidth collaboration and rapid response to change in Agile put a bullet in the head of offshore development done by outsourced CMMI Level 5 certified development factories. DevOps, by extending collaboration between development teams and operations teams and by increasing the velocity of delivery to production (up to hundreds or even thousands of times per day), and by using real feedback from production to drive development priorities and design
In a previous post, we received a question asking, "what is a secure software development lifecycle"? This is an excellent question, and one that I receive quite often from organizations during an application security assessment.
Let's quickly review the Software Development Lifecycle, also known as the SDLC. The goal of an SDLC is to provide a process for project teams to follow when developing software. A series of steps are completed, each one with a different deliverable, eventually leading to the deployment of functioning software to the
Security researchers discovered and disclosed the Clickjacking attack (also known as a "UI Redress Attack") back in 2008. All major browsers were affected. Flash even had an interesting vulnerability that allowed control of a user's microphone and webcam. Yet, here we are 7 years later still citing this issue on nearly every security assessment of web applications that we do. During our report delivery, development teams typically have one of the following responses: "What's Clickjacking?", "What can someone really do with this?", or "So what?".
I'd like to take a minute to explain a little bit about this exploit, give a quick example, and talk about a few ways to mitigate this issue.
Clickjacking involves hosting a form from the application in an iframe and tricking the user into activating the form. A common way to do this is to set the opacity of the iframe to 0 (rendering it invisible) and placing a link over a button on the
In the previous post (What Topics To Cover), we laid the foundation for your developer security awareness-training program. Now let's talk about the metrics we can collect to help improve our program.
It's all about the metrics
As we previously mentioned, establishing a common baseline for the entire development team would be helpful. A comprehensive application security assessment should be performed before awareness training begins. For example, the SANS Software Security team has a free web based security assessment knowledge check: http://software-security.sans.org/courses/assessment. A knowledge check such as this allows you to create a baseline, establish core strengths and weaknesses, and steer the types
In our last post (Is Security Your Top Priority), we discussed improving the security of our organizations with security awareness training for development teams. Now let's talk about the security training we should provide.
What Topics To Cover
All team members have different knowledge levels of the various threats facing our applications. Some have received little or no application security training. Some may have taken a few courses in college that mentioned some common security issues. A few may have received in-depth application security training from a previous employer. The only way to guarantee everyone is on the same page is to establish a common baseline for all team members.
The first step is covering the fundamental aspects of application