Flawless prevention of security issues at some point is truly impossible, but controlling how quickly we react is very possible. Software development and delivery processes should be long past the days of assigning low priority to security design and implementation. We have all heard horror stories about what happens when development projects fail to include […]
Flawless prevention of security issues at some point is truly impossible, but controlling how quickly we react is very possible. Software development and delivery processes should be long past the days of assigning low priority to security design and implementation. We have all heard horror stories about what happens when development projects fail to include security planning at the earliest stages. Still, zero-day and other security disasters occur at an alarming rate, and post-hoc investigations of such incidents clearly shows when Engineering teams ignored or paid only minimal attention to security considerations during development and delivery processes. This will be a multi-part discussion on High Security DevOps (HSDO) and how it can be achieved.
Your organization must consider security in the early stages of design, planning, and development for both new products and existing ones. This can be challenging, because there are many reasons why organizations fail to give security the necessary priority. This blog post identifies some of these considerations, along with some opportunities and goals for HSDO in improving the security of software development and delivery processes because HSDO can play a key role in facilitating, collaborating, and integrating security considerations in software development.
Development, Security and Operations (Dev, Ops, and Sec) each has their own priorities that can conflict with one another. Understanding how to apply their tools and processes to development workflows will improve collaboration and improve change as your product and organization grow. This will improve overall security posture, quality, and trust.
Security should be a habit that is naturally a part of how we do things. Perhaps in how we habitually look both ways when crossing an intersection. We should and can proactively work to prevent incidents, but how quickly we can react will also be a measure of success in preventing unforeseen challenges. In thinking about this, ask this question: “How fast can your teams respond to the next “Heartbleed” like zero-day vulnerability?” Remember, when you consider this, you must consider both public facing services and internal services. This is what secure DevOps is all about. The ability address such a zero day in hours to days, rather than weeks. At Excella we are very much about making an impact, but the impact of this scenario is one we want to be proactive in preventing.
Stay tuned for my next blog post, “No Budget Security for DevOps and Developers” that will explore how software developers and DevOps teams can best work together to enhance security, with minimal cost and disruption.
While writing this article, I conducted several personal interviews with the following experts:
Your company has invested in data science; you’ve created data teams, invested in expensive data...
Early this year, Amazon’s S3 service experienced a major service outage. For about 4-5 hours...
I’ve heard a lot of questions recently about how security, audit, and compliance fit into...