Robservations on Black Hat 2018

One of the nice things about my current role is that I recently had the pleasure of attending my first Black Hat conference. Now, to be completely transparent, I was there primarily to support networking and interactive activities at a security booth, but even with those small limitations, it was obvious that there is a LOT of interest these days in cyber-security and the myriad of options and opinions available. Here are two of my “Robervations” from the few days that I spent there. Enjoy!

Everyone Recognizes the Need for Security as a Part of DevOps (or DevSecOps)

While not everyone was using the term “DevSecOps,” it was all over the discussions that I had with various attendees and vendors and that the notion of addressing and accounting for security needs earlier in the application development lifecycle is paramount to business success in today’s marketplace. Most vendors had some form of that messaging displayed prominently in their signage and/or present in their documentation. It’s clear that the industry recognizes how important this activity is. However, while many organizations have adopted some form of DevOps methodology, the reality is that the greatest barrier to achieving “DevSecOps” remains the culture of the organization, with most having security teams still essentially operating as separate silos. Additionally, it is not realistic to expect developers to become security experts and anticipate cyber-security needs as part of their day-to-day work, and we all realize that there is still a lot of opportunity for improvement. For these reasons, it is clear that having more tooling that allows security requirements to be incorporated as an integral part of application conception and design. This can be done in the same way that features and functions are handled — it is critical. I expect to see more tooling that supports greater collaboration and takes advantage of natural language and cognitive capabilities to provide deep learning and best practices into application security requirements.

Make It Easier for Developers to Test Security

One of the more interesting discussion topics in the cyber-security space is around the role of the developer within it — especially where DevOps is concerned. Ask several people what the goal of DevOps is, and you will likely hear various expressions of automation that allow for greater development speed while maintaining a high level of quality – all resulting in a shorter time to market. And while all that is true, isn’t is also true that the real goal of DevOps is rooted in successful business outcomes? This is the reason to perform DevOps; it isn’t so much about just going faster, but it’s about providing the best customer experience possible and as soon as possible? And today, aspects like containerization, microservices, machine learning, and AI are big parts of the overall experience. Bearing all that in mind, the role of the developer has never been more important. And, developers themselves are realizing the impact of their influence. In fact, the recent 2018 Stack Overflow Developer Survey indicated that nearly half of the respondents believe “that the creators and technologists behind the machine learning and AI algorithms are the ones who are ultimately most responsible for the societal issues surrounding artificial intelligence.¹

So, how do you help developers who are not security experts be able to better handle security vulnerabilities and risks associated with the code they are developing? You incorporate security testing into the same delivery pipeline that they are using as part of their DevOps approach. And, this can be done in several ways. For starters, a great idea is to perform quick static code scans at the time of check-in to identify obvious issues while they are still in the context of what the developer is doing. This is the same idea as running unit and functional tests and is especially helpful if your teams are following DevOps best practices and coding against a production-like environment. Beyond that, incorporating security testing as part of the continuous integration and continuous delivery processes will allow for greater overall feedback sooner and when they are easier to remediate.